Actions
Bug #9559
closedC back-end incorrectly prints wide character strings
Added by Evgeny Novikov about 5 years ago. Updated about 5 years ago.
Start date:
03/21/2019
Due date:
% Done:
0%
Estimated time:
Detected in build:
svn
Platform:
Published in build:
Description
Instead of, say, L"Hello" it prints just "Hello" that results in invalid code.
Updated by Evgeny Novikov about 5 years ago
- Status changed from New to Closed
Implemented in 936ef2a.
Updated by Evgeny Novikov about 5 years ago
- Status changed from Closed to Open
On many Linux kernel loadable modules CIF started to fail with exceptions after the suggested bug fix.
Updated by Evgeny Novikov about 5 years ago
- Status changed from Open to Closed
I fixed 4 different issues in 1517e57. Now everything seems to work.
Updated by Evgeny Novikov about 5 years ago
- Related to Bug #9574: Fix support of wide character strings added
Updated by Evgeny Novikov about 5 years ago
- Status changed from Closed to Open
About 2% of compiler commands corresponding to Linux 3.14, 3.16 fail due to incorrect implementation (I do not think that the first implementation has not such the issue):
Couldn't find string in the hash table
};
^
0x6a2229 ldv_convert_str_literal
../../aspectator/gcc/c-family/ldv-convert.c:4921
0x6a4535 ldv_convert_primary_expr
../../aspectator/gcc/c-family/ldv-convert.c:4379
0x6a4d06 ldv_convert_postfix_expr
../../aspectator/gcc/c-family/ldv-convert.c:4278
0x6a5170 ldv_convert_unary_expr
../../aspectator/gcc/c-family/ldv-convert.c:5722
0x6a5384 ldv_convert_cast_expr
../../aspectator/gcc/c-family/ldv-convert.c:1125
0x6a53e7 ldv_convert_cast_expr
../../aspectator/gcc/c-family/ldv-convert.c:1108
0x6a5499 ldv_convert_multiplicative_expr
../../aspectator/gcc/c-family/ldv-convert.c:3822
0x6a55d6 ldv_convert_additive_expr
../../aspectator/gcc/c-family/ldv-convert.c:324
0x6a57b8 ldv_convert_shift_expr
../../aspectator/gcc/c-family/ldv-convert.c:4661
0x6a58f8 ldv_convert_relational_expr
../../aspectator/gcc/c-family/ldv-convert.c:4496
0x6a5a18 ldv_convert_equality_expr
../../aspectator/gcc/c-family/ldv-convert.c:2503
0x6a5af8 ldv_convert_and_expr
../../aspectator/gcc/c-family/ldv-convert.c:381
0x6a5c18 ldv_convert_exclusive_or_expr
../../aspectator/gcc/c-family/ldv-convert.c:2551
0x6a5d58 ldv_convert_inclusive_or_expr
../../aspectator/gcc/c-family/ldv-convert.c:3039
0x6a5e28 ldv_convert_logical_and_expr
../../aspectator/gcc/c-family/ldv-convert.c:3646
0x6a5f38 ldv_convert_logical_or_expr
../../aspectator/gcc/c-family/ldv-convert.c:3694
0x6a60f0 ldv_convert_cond_expr
../../aspectator/gcc/c-family/ldv-convert.c:1232
0x6a6269 ldv_convert_assignment_expr(tree_node*, unsigned int)
../../aspectator/gcc/c-family/ldv-convert.c:909
0x6afebf ldv_convert_and_print_assignment_expr(tree_node*)
../../aspectator/gcc/c-family/ldv-pretty-print.c:3862
0x6b56bf ldv_convert_initializer_to_internal(tree_node*)
../../aspectator/gcc/ldv-converter.c:332
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Aspectator failed at '3' stage.
Updated by Evgeny Novikov about 5 years ago
- Blocks Feature #9599: Support basic verification of drivers of Linux 3.14.79, 3.16.65, 4.4.178, 4.9.168, 4.14.111, 4.19.34, 5.0.7 added
Updated by Evgeny Novikov about 5 years ago
Here is a minimal example where CIF fails (I could not reduce it further :)):
static char *texts_ports_raydat_ss[] = {
"ADAT1.1", "ADAT1.2", "ADAT1.3", "ADAT1.4", "ADAT1.5", "ADAT1.6",
"ADAT1.7", "ADAT1.8", "ADAT2.1", "ADAT2.2", "ADAT2.3", "ADAT2.4",
"ADAT2.5", "ADAT2.6", "ADAT2.7", "ADAT2.8", "ADAT3.1", "ADAT3.2",
"ADAT3.3", "ADAT3.4", "ADAT3.5", "ADAT3.6", "ADAT3.7", "ADAT3.8",
"ADAT4.1", "ADAT4.2", "ADAT4.3", "ADAT4.4", "ADAT4.5", "ADAT4.6",
"ADAT4.7", "ADAT4.8",
"AES.L", "AES.R",
"SPDIF.L", "SPDIF.R"
};
static char *texts_ports_raydat_ds[] = {
"ADAT1.1", "ADAT1.2", "ADAT1.3", "ADAT1.4",
"ADAT2.1", "ADAT2.2", "ADAT2.3", "ADAT2.4",
"ADAT3.1", "ADAT3.2", "ADAT3.3", "ADAT3.4",
"ADAT4.1", "ADAT4.2", "ADAT4.3", "ADAT4.4",
"AES.L", "AES.R",
"SPDIF.L", "SPDIF.R"
};
static char *texts_ports_raydat_qs[] = {
"ADAT1.1", "ADAT1.2",
"ADAT2.1", "ADAT2.2",
"ADAT3.1", "ADAT3.2",
"ADAT4.1", "ADAT4.2",
"AES.L", "AES.R",
"SPDIF.L", "SPDIF.R"
};
static char *texts_ports_aio_in_ss[] = {
"Analogue.L", "Analogue.R",
"AES.L", "AES.R",
"SPDIF.L", "SPDIF.R",
"ADAT.1", "ADAT.2", "ADAT.3", "ADAT.4", "ADAT.5", "ADAT.6",
"ADAT.7", "ADAT.8",
"AEB.1", "AEB.2", "AEB.3", "AEB.4"
};
static char *texts_ports_aio_out_ss[] = {
"Analogue.L", "Analogue.R",
"AES.L", "AES.R",
"SPDIF.L", "SPDIF.R",
"ADAT.1", "ADAT.2", "ADAT.3", "ADAT.4", "ADAT.5", "ADAT.6",
"ADAT.7", "ADAT.8",
"Phone.L", "Phone.R",
"AEB.1", "AEB.2", "AEB.3", "AEB.4"
};
Updated by Evgeny Novikov about 5 years ago
I observe the failure when the number of strings exceeds 97. It seems that neither a string content nor their usage context influences. So, the issue seems to be with a hash table that fails to keep a big number of strings.
Updated by Evgeny Novikov about 5 years ago
- Status changed from Open to Closed
I fixed the issue in 405fbb8.
Actions