[Bug rtl-optimization/85941] Zero extend from QI->SI lost if QI is referred to via subreg:HI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85941 --- Comment #2 from Jozef Lawrynowicz --- Created attachment 44192 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44192=edit correct assembly output
[Bug rtl-optimization/85941] Zero extend from QI->SI lost if QI is referred to via subreg:HI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85941 --- Comment #1 from Jozef Lawrynowicz --- Created attachment 44191 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44191=edit incorrect assembly output
[Bug rtl-optimization/85941] New: Zero extend from QI->SI lost if QI is referred to via subreg:HI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85941 Bug ID: 85941 Summary: Zero extend from QI->SI lost if QI is referred to via subreg:HI Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jozef.l at mittosystems dot com Target Milestone: --- Created attachment 44190 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44190=edit testcase In the combine RTL stage, (zero_extend:SI (subreg:HI (reg:QI 28) 0))) becomes (zero_extend:SI (reg:HI 12 R12))) at -O1 and above. A reduced test case based on pr39240.c is attached, observed with msp430-elf. It fails on execution with current trunk as the necessary instruction to zero extend R12 (AND #0xff, R12) is lost. On native x86_64, a subreg expression is not used to reference the QI reg, so this problem isn't seen. See zero_extendqisi2 in gcc/config/msp430/msp430.md: (define_insn "zero_extendqisi2" [(set (match_operand:SI 0 "nonimmediate_operand" "=r") (zero_extend:SI (subreg:HI (match_operand:QI 1 "nonimmediate_operand" "rm") 0)))] If the subreg:HI expression is removed from the insn pattern, the zero extension from QI->SI is present in the output assembly, and the test case executes correctly: (define_insn "zero_extendqisi2" [(set (match_operand:SI 0 "nonimmediate_operand" "=r") (zero_extend:SI (match_operand:QI 1 "nonimmediate_operand" "rm")))] I am not aware of why the first pattern would be incorrect, so is this a bug in combine rather than the insn pattern? Observed with 7.3.1 and current trunk 9.0.0.
[Bug rtl-optimization/85941] Zero extend from QI->SI lost if QI is referred to via subreg:HI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85941 Jozef Lawrynowicz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jozef Lawrynowicz --- Right, yes of course. Given that combine isn't at fault, I'll close this as invalid, and submit a patch with the msp430 insn pattern fixed. Thanks.
[Bug middle-end/86705] [7/8/9 Regression] pr45678-2.c ICE with msp430-elf -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86705 Jozef Lawrynowicz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jozef Lawrynowicz --- Fixed on gcc-7-branch, gcc-8-branch and trunk.
[Bug target/86662] [7/8/9 Regression] msp430-elf segfault with -flto and -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86662 --- Comment #2 from Jozef Lawrynowicz --- Started with r242888, observed in GCC 7, 8 and 9.
[Bug middle-end/86705] [7/8/9 Regression] pr45678-2.c ICE with msp430-elf -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86705 --- Comment #1 from Jozef Lawrynowicz --- Untested patch diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c index d6e3c38..573324a 100644 --- a/gcc/cfgexpand.c +++ b/gcc/cfgexpand.c @@ -1258,9 +1258,12 @@ set_parm_rtl (tree parm, rtx x) pointer. ??? We've got a pseudo for sure here, do we actually dynamically allocate its spilling area if needed? ??? Isn't it a problem when POINTER_SIZE also exceeds -MAX_SUPPORTED_STACK_ALIGNMENT, as on cris and lm32? */ +MAX_SUPPORTED_STACK_ALIGNMENT, as on cris and lm32? +POINTER_SIZE may not be a power of 2 e.g. for msp430-elf with the large +data model, so align to the largest power of 2 that is +<= POINTER_SIZE. */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) - align = POINTER_SIZE; + align = (unsigned)1 << floor_log2(POINTER_SIZE); record_alignment_for_reg_var (align); } @@ -1381,7 +1384,7 @@ expand_one_ssa_partition (tree var) /* If the variable alignment is very large we'll dynamicaly allocate it, which means that in-frame portion is just a pointer. */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) -align = POINTER_SIZE; +align = (unsigned)1 << floor_log2(POINTER_SIZE); record_alignment_for_reg_var (align); @@ -1608,7 +1611,7 @@ expand_one_var (tree var, bool toplevel, bool really_expand) /* If the variable alignment is very large we'll dynamicaly allocate it, which means that in-frame portion is just a pointer. */ if (align > MAX_SUPPORTED_STACK_ALIGNMENT) - align = POINTER_SIZE; + align = (unsigned)1 << floor_log2(POINTER_SIZE); } record_alignment_for_reg_var (align);
[Bug middle-end/86705] New: [7/8/9 Regression] pr45678-2.c ICE with msp430-elf -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86705 Bug ID: 86705 Summary: [7/8/9 Regression] pr45678-2.c ICE with msp430-elf -mlarge Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jozef.l at mittosystems dot com Target Milestone: --- ./build/gcc/xgcc -B./build/gcc/ -mlarge -S gcc/testsuite/gcc.dg/torture/pr45678-2.c during RTL pass: expand gcc/testsuite/gcc.dg/torture/pr45678-2.c: In function 'main': gcc/testsuite/gcc.dg/torture/pr45678-2.c:12:3: internal compiler error: in emit_block_move_hints, at expr.c:1608 __builtin_memcpy (, , sizeof (d)); ^ 0x812fa1 emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods, unsigned int, long, unsigned long, unsigned long, unsigned long) ../../gcc/expr.c:1608 0x6b706b expand_builtin_memory_copy_args ../../gcc/builtins.c:3700 0x6c3075 expand_builtin_mempcpy_args ../../gcc/builtins.c:3726 0x6c3075 expand_builtin_mempcpy ../../gcc/builtins.c:3623 0x6c3075 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ../../gcc/builtins.c:7286 0x808c19 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10911 0x6e82e5 expand_expr ../../gcc/expr.h:279 0x6e82e5 expand_call_stmt ../../gcc/cfgexpand.c:2687 0x6e82e5 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3575 0x6e8933 expand_gimple_stmt ../../gcc/cfgexpand.c:3734 0x6e9a6b expand_gimple_basic_block ../../gcc/cfgexpand.c:5769 0x6ef3c6 execute ../../gcc/cfgexpand.c:6372 Works with current gcc-6-branch, ICE observed with gcc-7-branch, gcc-8-branch and trunk.
[Bug target/86662] [7/8/9 Regression] msp430-elf segfault with -flto and -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86662 Jozef Lawrynowicz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jozef Lawrynowicz --- Fixed on all branches, marking resolved.
[Bug target/86662] New: msp430-elf segfault with -flto and -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86662
Bug ID: 86662
Summary: msp430-elf segfault with -flto and -mlarge
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
Segfault after endless recursion in gimple_get_alias_set, caused by canonical
type for __int20 being set to the unsigned variant, rather than signed variant
as expected.
testcase.i
int main(void)
{
__int20 n = 5;
}
./build/gcc/xgcc -B./build/gcc -nostdlib testcase.i -mlarge -flto
xgcc: internal compiler error: Segmentation fault signal terminated program
lto1
[Bug target/86662] msp430-elf segfault with -flto and -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86662
--- Comment #1 from Jozef Lawrynowicz ---
Untested patch
diff --git a/gcc/tree.c b/gcc/tree.c
index bace9c8..54384ad 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -9802,8 +9802,7 @@ build_common_tree_nodes (bool signed_char)
int_n_trees[i].signed_type = make_signed_type (int_n_data[i].bitsize);
int_n_trees[i].unsigned_type = make_unsigned_type
(int_n_data[i].bitsize);
- if (int_n_data[i].bitsize > LONG_LONG_TYPE_SIZE
- && int_n_enabled_p[i])
+ if (int_n_enabled_p[i])
{
integer_types[itk_intN_0 + i * 2] = int_n_trees[i].signed_type;
integer_types[itk_unsigned_intN_0 + i * 2] =
int_n_trees[i].unsigned_type;
[Bug middle-end/87173] -Walloc-size-larger-than= silently fails for operands/size values larger than __SIZE_MAX__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87173
--- Comment #2 from Jozef Lawrynowicz ---
Right, thanks.
I'll just submit a patch for gcc.dg/Walloc-size-larger-than-{4,5,6,7}.c to
require "size32plus" then.
[Bug target/82624] [msp430] Target must allow for NULL pointer dereferences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82624 Jozef Lawrynowicz changed: What|Removed |Added CC||jozef.l at mittosystems dot com --- Comment #2 from Jozef Lawrynowicz --- This was fixed in r253921, could someone close this please.
[Bug target/78818] msp430 persistent attribute is not applied correctly in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78818 Jozef Lawrynowicz changed: What|Removed |Added CC||jozef.l at mittosystems dot com --- Comment #3 from Jozef Lawrynowicz --- This has been fixed, could someone close this PR please.
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #1 from Jozef Lawrynowicz --- The issue is that the union is considered to have size of 32 bits (the in-memory size of __int20), so unless mode_for_size as called by compute_record_mode (both in stor-layout.c) is explicitly told to look for a mode of class MODE_PARTIAL_INT, then a size of 32 will always return MODE_INT. In this case, the union will have TYPE_MODE of SImode, but its field is PSImode, so transparent_union has no effect. As was explained on the GCC mailing list (https://gcc.gnu.org/ml/gcc/2018-05/msg00218.html), in general we want to ensure that the class of a union is MODE_INT, as some ABIs mandate that unions be passed in integer registers. For msp430, it is fine to relax this constraint and allow unions to have PSImode, as all general purpose registers are 20-bits (and msp430 doesn't pass structs/unions by value anyway). The attached patch fixes the issue by requesting a mode of class MODE_PARTIAL_INT when calling mode_for_size in compute_record_mode. However, since other targets which support MODE_PARTIAL_INT may want unions to always have class MODE_INT, I wonder if the attached patch is not appropriate. Should there perhaps be a target hook which allows/disallows MODE_PARTIAL_INT structs/unions?
[Bug c/87691] New: transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691
Bug ID: 87691
Summary: transparent_union attribute does not work with
MODE_PARTIAL_INT
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
msp430-elf uses the partial int type __int20 for pointers in the large memory
model. __int20 has PSImode, with bitsize of 20.
A few DejaGNU tests fail when built with -mlarge for msp430-elf, when
transparent unions are used containing pointers.
These are:
- gcc.c-torture/compile/pr34885.c
- gcc.dg/transparent-union-{1,2,3,4,5}.c
Consider the following C source code:
typedef union {
__int20 a;
} union_a __attribute__ ((__transparent_union__));
Compiling produces a warning:
> msp430-elf-gcc -S testcase.c
> warning: 'transparent_union' attribute ignored [-Wattributes]
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #2 from Jozef Lawrynowicz --- Created attachment 44880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44880=edit transparent_union.patch
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #3 from Jozef Lawrynowicz --- Perhaps it is sufficient to check targetm.pass_by_reference, i.e. if the struct/union with the given mode would be passed by reference, then it is ok to give the struct/union a mode outside the MODE_INT class.
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #5 from Jozef Lawrynowicz --- (In reply to Richard Biener from comment #4) Thanks for the pointers. > What happens if you make the attribute work for a MODE_INT union with a > MODE_PARTIAL_INT first field that has MODE_SIZE of the union mode? > > Is there > a generic way to query SImode for PSImode as defined in > > PARTIAL_INT_MODE (SI, 20, PSI); > > ? Or does one need to compare MODE_SIZE? I believe you just have to compare MODE_SIZE as I did below. > Can there be multiple non-partial integer modes with the same size? Currently for the targets using PARTIAL_INT_MODE there is only a one-to-one mapping from the "full" mode to the partial mode. But where it can get tricky is when examining the BITSIZE of a partial int mode, as depending on the context, the bitsize could be the bitsize of the SI mode or the true bitsize of the PSImode i.e. the precision. I tried this (there may well be a neater way): diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c index 4416b50..74f6a76 100644 --- a/gcc/c-family/c-attribs.c +++ b/gcc/c-family/c-attribs.c @@ -1280,7 +1280,11 @@ handle_transparent_union_attribute (tree *node, tree name, tree first = first_field (type); if (first == NULL_TREE || DECL_ARTIFICIAL (first) - || TYPE_MODE (type) != DECL_MODE (first)) + || (TYPE_MODE (type) != DECL_MODE (first) + && !(GET_MODE_CLASS (TYPE_MODE (type)) == MODE_INT + && GET_MODE_CLASS (DECL_MODE(first)) == MODE_PARTIAL_INT + && known_eq (GET_MODE_BITSIZE (TYPE_MODE (type)), + GET_MODE_BITSIZE (DECL_MODE (first)) goto ignored; } It fixes most of those failing DejaGNU tests, except pr34885.c ends up ICE-ing at "-O3 -g". during RTL pass: final^M /home/jozef/msp430/gcc/gcc/testsuite/gcc.c-torture/compile/pr34885.c: In function 'send':^M /home/jozef/msp430/gcc/gcc/testsuite/gcc.c-torture/compile/pr34885.c:9:1: internal compiler error: Segmentation fault^M 0xb58f4f crash_signal^M ../../gcc/toplev.c:325^M 0x7bf92d gen_subprogram_die^M ../../gcc/dwarf2out.c:23270^M 0x7c1c5b gen_decl_die^M ../../gcc/dwarf2out.c:26197^M 0x7c3f9e dwarf2out_decl^M ../../gcc/dwarf2out.c:26765^M 0x7d707e dwarf2out_function_decl^M ../../gcc/dwarf2out.c:26780^M 0x83e757 rest_of_handle_final^M ../../gcc/final.c:4681^M 0x83e757 execute^M ../../gcc/final.c:4723^M I haven't investigated the above ICE as the below alternative approach fixes the issue and offers codegen benefits. diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c index 58a3aa3..6449f16 100644 --- a/gcc/stor-layout.c +++ b/gcc/stor-layout.c @@ -1844,10 +1844,15 @@ compute_record_mode (tree type) } /* If we only have one real field; use its mode if that mode's size - matches the type's size. This only applies to RECORD_TYPE. This - does not apply to unions. */ + matches the type's size. This generally only applies to RECORD_TYPE. + As an exception, if the union will be passed by reference then it is + acceptable to use the mode of the widest field for the mode of the + union. */ poly_uint64 type_size; - if (TREE_CODE (type) == RECORD_TYPE + if (((TREE_CODE (type) == RECORD_TYPE) + || (TREE_CODE (type) == UNION_TYPE + && targetm.calls.pass_by_reference (pack_cumulative_args (NULL), + mode, type, 0))) && mode != VOIDmode && poly_int_tree_p (TYPE_SIZE (type), _size) && known_eq (GET_MODE_BITSIZE (mode), type_size)) The codegen benefits are that the target might have instructions to specifically operate on the partial int mode, which it can use if the mode of the union is set to this partial int mode. So for msp430 if the widest type in a union is __int20 (PSImode), then allowing the union mode to be PSImode results in fewer instructions being used to manipulate the union, compared to if the union mode was SImode. I'll go ahead and test the second patch, unless there is a reason not to allow non-MODE_INT unions. If, for example, we'd rather not have unions be MODE_FLOAT I could always restrict the above logic further to only allow the union mode to be set to a MODE_PARTIAL_INT in addition to the currently allowable MODE_INT.
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691
--- Comment #7 from Jozef Lawrynowicz ---
(In reply to Richard Biener from comment #6)
>
> I think it's better to, at this place, simply allow MODE_INT or
> MODE_PARTIAL_INT
> for unions. Allowing MODE_INT is what we'd fall back to anyways and you
> want to allow MODE_PARTIAL_INT which is already allowed for RECORD_TYPEs.
>
> What I'm not sure is if the target is happy about, say,
>
> union U { float f; __int20 i; };
>
> float foo()
> {
> union U u;
> u.i = 10;
> return u.f;
> }
>
> iff we were to put u into a MODE_PARTIAL_INT register are targets to be
> expected to be able to extract a MODE_FLOAT from it or are we going
> to spill here anyways?
I tweaked the above source a little:
float foo(union U u)
{
u.i = u.i + 10;
return u.f;
}
For this, GCC fills u.i then spills after modifying it. I therefore assume in
general that if u.f is alive then modifications to u.i will always be spilled
after.
> How is TYPE_SIZE / GET_MODE_BITSIZE of this union anyways? The loop
> in stor-layout checks TYPE_SIZE vs. DECL_SIZE - is DECL_SIZE always
> matching GET_MODE_BITSIZE?
It actually depends on the order of the fields in the union, which is not good.
Since __int20 and float have the same BITSIZE, the mode of the last field in
the union will be used for the mode of the union. So for the above code with my
current patch, the union TYPE_MODE is PSImode. This causes wrong code to be
generated, as the function foo starts by only pushing the __int20 value of the
union onto the stack, rather than the full 32-bits.
I had the following additional patch which didn't seem to affect the
testresults, but fixes this issue so is clearly beneficial:
diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index 6449f16..3bb0bbc 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -1834,7 +1834,13 @@ compute_record_mode (tree type)
/* If this field is the whole struct, remember its mode so
that, say, we can put a double in a class into a DF
register instead of forcing it to live in the stack. */
- if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field)))
+ if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field))
+ /* Partial int types (e.g. __int20) may have TYPE_SIZE equal to
+wider types (e.g. int32), despite precision being less. Ensure
+that the TYPE_MODE of the struct does not get set to the partial
+int mode if there is a wider type also in the struct. */
+ && known_gt (GET_MODE_PRECISION (DECL_MODE (field)),
+ GET_MODE_PRECISION (mode)))
mode = DECL_MODE (field);
/* With some targets, it is sub-optimal to access an aligned
This fixes the above issue, so the union TYPE_MODE is always SFmode, regardless
of the ordering of the fields.
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #9 from Jozef Lawrynowicz --- Patch submitted: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01459.html
[Bug middle-end/87854] New: [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87854 Bug ID: 87854 Summary: [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jozef.l at mittosystems dot com Target Milestone: --- The constant string in this test is 2 * (10^7) long (a 25-bit number), on these 16-bit targets, size_t is an unsigned 16-bit int. The test starts ICE'ing with r264292. The test successfully compiles for both msp430 and avr with r264291. > internal compiler error: in get_constant_size, at varasm.c:3310 > 17 | printf (S7 "\n"); >| > 0xe7342c get_constant_size > ../../gcc/varasm.c:3309 > 0xe7b6e7 assemble_constant_contents > ../../gcc/varasm.c:3478 > 0xe84178 output_constant_def_contents > ../../gcc/varasm.c:3528 > 0xe80d28 maybe_output_constant_def_contents > ../../gcc/varasm.c:3466 > 0xe80d28 output_constant_def(tree_node*, int) > ../../gcc/varasm.c:3432 > 0x82027e expand_expr_constant > ../../gcc/expr.c:7821 > 0x82027e expand_expr_addr_expr_1 > ../../gcc/expr.c:7848 > 0x81ffd0 expand_expr_addr_expr_1 > ../../gcc/expr.c:7966 > 0x813f1a expand_expr_addr_expr > ../../gcc/expr.c:8042 > 0x813f1a expand_expr_real_1(tree_node*, rtx_def*, machine_mode, > expand_modifier, rtx_def**, bool) > ../../gcc/expr.c:11174 > 0x6da659 expand_normal > ../../gcc/expr.h:285 > 0x6da659 precompute_register_parameters > ../../gcc/calls.c:976 > 0x6da659 expand_call(tree_node*, rtx_def*, int) > ../../gcc/calls.c:3990 > 0x6c929d expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) > ../../gcc/builtins.c:8136 > 0x814128 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, > expand_modifier, rtx_def**, bool) > ../../gcc/expr.c:10943 > 0x6ef055 expand_expr > ../../gcc/expr.h:279 > 0x6ef055 expand_call_stmt > ../../gcc/cfgexpand.c:2694 > 0x6ef055 expand_gimple_stmt_1 > ../../gcc/cfgexpand.c:3582 > 0x6ef683 expand_gimple_stmt > ../../gcc/cfgexpand.c:3741 > 0x6f07ab expand_gimple_basic_block > ../../gcc/cfgexpand.c:5777 The ICE then moves to expr.c with r264300 > internal compiler error: in string_constant, at expr.c:11415 > 0x811c13 string_constant(tree_node*, tree_node**, tree_node**, tree_node**) > ../../gcc/expr.c:11414 > 0x846d7b c_getstr(tree_node*, unsigned long*, unsigned long*) > ../../gcc/fold-const.c:14579 > 0x8b5da2 gimple_fold_builtin_printf > ../../gcc/gimple-fold.c:3366 > 0x8afd19 gimple_fold_builtin > ../../gcc/gimple-fold.c:3755 > 0x8b1c44 gimple_fold_call > ../../gcc/gimple-fold.c:4146 > 0x8b320a fold_stmt_1 > ../../gcc/gimple-fold.c:4811 > 0x8eb5b0 gimplify_call_expr > ../../gcc/gimplify.c:3422 > 0x8d9518 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), > int) > ../../gcc/gimplify.c:11576 > 0x8ddc26 gimplify_stmt(tree_node**, gimple**) > ../../gcc/gimplify.c:6614 > 0x8df035 gimplify_bind_expr > ../../gcc/gimplify.c:1331 > 0x8d9181 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), > int) > ../../gcc/gimplify.c:11805 > 0x8ddc26 gimplify_stmt(tree_node**, gimple**) > ../../gcc/gimplify.c:6614 > 0x8dfd96 gimplify_body(tree_node*, bool) > ../../gcc/gimplify.c:12799 > 0x8e0314 gimplify_function_tree(tree_node*) > ../../gcc/gimplify.c:12943 > 0x732497 cgraph_node::analyze() > ../../gcc/cgraphunit.c:669 > 0x73596a analyze_functions > ../../gcc/cgraphunit.c:1122 > 0x7367a2 symbol_table::finalize_compilation_unit() > ../../gcc/cgraphunit.c:2760 Rather than ICE'ing should there be some error message about object size being too large?
[Bug target/87883] New: [ARM] ICE: Segmentation fault in arm_regno_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87883
Bug ID: 87883
Summary: [ARM] ICE: Segmentation fault in arm_regno_class
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
Querying REGNO_REG_CLASS, from reginfo.c init_reg_sets, with an argument > 15
causes a segfault for arm-unknown-eabi.
For example, after applying the following contrived patch, a build of GCC seg
faults when running self-tests.
diff --git a/gcc/reginfo.c b/gcc/reginfo.c
index 33befa5..3fce076 100644
--- a/gcc/reginfo.c
+++ b/gcc/reginfo.c
@@ -165,6 +165,8 @@ init_reg_sets (void)
if (int_reg_class_contents[i][j / 32]
& ((unsigned) 1 << (j % 32)))
SET_HARD_REG_BIT (reg_class_contents[i], j);
+ else
+ gcc_assert (REGNO_REG_CLASS (j) > -1);
}
/* Sanity check: make sure the target macros FIXED_REGISTERS and
> ./gcc/xgcc -B./gcc/ -xc -nostdinc /dev/null -S -o /dev/null
> -fself-test=../../gcc/testsuite/selftests
> cc1: internal compiler error: Segmentation fault
> cc1: internal compiler error: Segmentation fault
> 0xc33ebf crash_signal
> ../../gcc/toplev.c:325
> 0xc33ebf crash_signal
> ../../gcc/toplev.c:325
> 0xfc3fba bitmap_check_index
> ../../gcc/sbitmap.h:105
> 0xfc3fba bitmap_bit_p
> ../../gcc/sbitmap.h:120
> 0xfc3fba arm_regno_class(int)
> ../../gcc/config/arm/arm.c:23757
> 0xfc3fba bitmap_check_index
> ../../gcc/sbitmap.h:105
> 0xfc3fba bitmap_bit_p
> ../../gcc/sbitmap.h:120
> 0xfc3fba arm_regno_class(int)
> ../../gcc/config/arm/arm.c:23757
> 0xb986a3 init_reg_sets()
> ../../gcc/reginfo.c:169
> 0x616b7d general_init
> ../../gcc/toplev.c:1171
This can also be observed when debugging the failing self-test invocation in
GDB
> ./gcc/xgcc -B./gcc/ -xc -nostdinc /dev/null -S -o /dev/null \
> -fself-test=../../gcc/testsuite/selftests -wrapper gdb,--args
Breakpoint 2, init_reg_sets () at ../../gcc/reginfo.c:153
153 {
(gdb) call arm_regno_class(15)
$1 = NO_REGS
(gdb) call arm_regno_class(16)
Program received signal SIGSEGV, Segmentation fault.
arm_regno_class (regno=16) at ../../gcc/config/arm/arm.c:23757
23757 if (IS_VFP_REGNUM (regno))
Observed on current trunk, gcc-8-branch and gcc-7-branch.
Bootstrap for x86_64-pc-linux-gnu, and a regular build for msp430-elf complete
successfully with the above patch.
[Bug c/87927] ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87927 Jozef Lawrynowicz changed: What|Removed |Added Attachment #44968|0 |1 is obsolete|| --- Comment #2 from Jozef Lawrynowicz --- Created attachment 44969 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44969=edit proposed patch (fixed) Fixed wrong ordering of new elements in "struct asm_int_op"
[Bug c/87927] ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87927
--- Comment #1 from Jozef Lawrynowicz ---
Created attachment 44968
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44968=edit
proposed patch
In default_print_patchable_function_entry, integer_asm_op is passed
POINTER_SIZE_UNITS. For msp430-elf -mlarge, this is 3, which is not handled in
integer_asm_op, so it returns NULL.
fputs is directly writing out the return value of integer_asm_op, so when this
is NULL we are segfaulting.
Attached is a proposed patch which implements
TARGET_ASM_{,UN}ALIGNED_P{S,D,T}I_OP, so integer_asm_op will not return NULL
for values < 16.
This fixes the c-c++-common/patchable_function_entry* tests but is otherwise
untested.
[Bug c/87927] New: ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87927
Bug ID: 87927
Summary: ICE: segmentation fault with patchable_function_entry
attribute for msp430-elf -mlarge
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
Use of the patchable_function_entry attribute with msp430-elf in the large
memory model causes a segfault on trunk.
For example in c-c++-common/patchable_function_entry-decl.c:
> extern int a;
>
> int f3 (void) __attribute__((patchable_function_entry(2)));
>
> int
> __attribute__((noinline))
> f3 (void)
> {
> return 5*a;
> }
> gcc -mlarge -fpatchable-function-entry=3,1 -S
> gcc/testsuite/c-c++-common/patchable_function_entry-decl.c
> gcc/testsuite/c-c++-common/patchable_function_entry-decl.c: In function 'f3':
> gcc/testsuite/c-c++-common/patchable_function_entry-decl.c:18:1: internal
> compiler error: Segmentation fault
> 0xb5e4af crash_signal
> ../../gcc/toplev.c:325
> 0xb59d41 default_print_patchable_function_entry(_IO_FILE*, unsigned long,
> bool)
> ../../gcc/targhooks.c:1816
> 0xe94d2c assemble_start_function(tree_node*, char const*)
> ../../gcc/varasm.c:1903
> 0x84188f rest_of_handle_final
> ../../gcc/final.c:4645
> 0x84188f execute
> ../../gcc/final.c:4723
[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87854 --- Comment #4 from Jozef Lawrynowicz --- Thanks, the patch fixes the ICE on msp430-elf and the test now outputs: > gcc.c-torture/compile/pr46534.c:17:3: error: size of string literal is too > large
[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87854 --- Comment #6 from Jozef Lawrynowicz --- (In reply to Jakub Jelinek from comment #5) > Yeah, that is the goal. And you should either add msp430-*-* to dg-skip-if, > or do we have some effective targets for all targets with 16-bit size_t (or > perhaps < 32-bit), so that we could skip them all at once? Effective target "size32plus" checks if an array with 24-bit size compiles successfully so would cover this test. I wonder if it would be better to add a dg-error directive (which references this PR) for these targets rather than skipping the test?
[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87854 --- Comment #8 from Jozef Lawrynowicz --- (In reply to Jakub Jelinek from comment #7) > For some yes. I assume not e.g. for nvptx as it has 64-bit size_t but can't > compile it for other reasons. Ok, I'll make sure to check that. The new error catches gcc.dg/concat2.c and g++.dg/parse/concat1.C which previously passed for msp430-elf. In these tests it is a 16-bit string (10^5) which is rightly too large for this target, but there is a note in the test: > The fact that the string isn't actually used in the resulting program > should allow this to compile for any target. So just want to make sure that it is ok that this assumption can no longer be made. I'll then add the relevant dg-error directives for these tests and pr46534.
[Bug target/87927] ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87927 --- Comment #4 from Jozef Lawrynowicz --- Submitted patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01192.html
[Bug c++/87996] New: [8/9 Regression] "size of array is negative" error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87996
Bug ID: 87996
Summary: [8/9 Regression] "size of array is negative" error
when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
Created attachment 44992
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44992=edit
tester.ii
In GCC 7.3, declaring an array of size SIZE_MAX results in an error because
the size of the array is too large.
tester.c:
#include
char array[SIZE_MAX];
gcc tester.c
> tester.c:3:6: error: size of array 'array' is too large
> char array[SIZE_MAX];
g++ tester.c
> tester.c:3:19: error: size of array 'array' is too large
> char array[SIZE_MAX];
In GCC 8.1 and current trunk, the error message when compiling C code is
the same, but for C++, the size of the array is reported to be negative.
gcc tester.c
> tester.c:3:6: error: size of array ‘array’ is too large
> 3 | char array[SIZE_MAX];
g++ tester.c
> tester.c:3:19: error: size of array ‘array’ is negative
> 3 | char array[SIZE_MAX];
For G++ I tried with -std=c++{98,11,14} and the behaviour was the same.
For SIZE_MAX/2, compilation completes succesfully, and the same errors occur
for (SIZE_MAX/2+1)
According to cppreference (https://en.cppreference.com/w/cpp/language/array)
the array size initializer (i.e. the value within []), is either an integral
constant expression (until C++14), or a constant expression of type size_t.
So in none of these cases should the size of the array be considered to be
negative as SIZE_MAX will always fit in a integral constant expression, or
size_t, so should never wrap to a negative value.
I've attached the pre-processed source applicable for 64-bit size_t.
Observed with x86_64-pc-linux-gnu and msp430-elf
[Bug c++/87996] [8/9 Regression] "size of array is negative" error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87996 Jozef Lawrynowicz changed: What|Removed |Added Attachment #44992|0 |1 is obsolete|| --- Comment #1 from Jozef Lawrynowicz --- Created attachment 44993 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44993=edit tester.ii
[Bug middle-end/87173] New: -Walloc-size-larger-than= silently fails for operands/size values larger than __SIZE_MAX__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87173
Bug ID: 87173
Summary: -Walloc-size-larger-than= silently fails for
operands/size values larger than __SIZE_MAX__
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
Created attachment 44640
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44640=edit
testcase.c
Exposed by gcc.dg/Walloc-size-larger-than-{4,5,6,7}.c for msp430-elf, on
latest trunk.
- If the operand to the allocation function being checked is larger than
__SIZE_MAX__, no warning is emitted.
- If the value passed to -Walloc-size-larger-than= is larger than or equal to
__SIZE_MAX__, no warning is emitted.
e.g. for msp430-elf, where __SIZE_MAX__ is 65535. testcase.c attached.
> msp430-elf-gcc -O -ftrack-macro-expansion=0 -Walloc-size-larger-than=65534
> testcase.c -S
> testcase.c: In function 'f':
> testcase.c:6:3: warning: argument 1 value '65535' exceeds maximum object size
> 65534 [-Walloc-size-larger-than=]
> 6 | T (__builtin_malloc (a));
> | ^
> testcase.c:6:3: note: in a call to built-in allocation function
> '__builtin_malloc'
The expected warning for 65536 (__SIZE_MAX__ + 1) exceeding maximum object size
is missing.
Again, with __SIZE_MAX__ as the parameter to -Walloc-size-larger-than=
> msp430-elf-gcc -O -ftrack-macro-expansion=0 -Walloc-size-larger-than=65535
> testcase.c -S
No warnings output.
[Bug target/78849] ICE on initialization of global struct containing __int20 array at varasm.c:4968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78849 Jozef Lawrynowicz changed: What|Removed |Added CC||jozef.l at mittosystems dot com --- Comment #4 from Jozef Lawrynowicz --- This bug is fixed, but I cannot close the PR, could someone else please resolve it?
[Bug c/88237] __extension__ in function declaration argument list causes error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88237 --- Comment #1 from Jozef Lawrynowicz --- For C++ the errors are: > g++ -S tester.c > > tester.c:11:10: error: variable or field 'foo' declared void >11 | void foo (__extension__ int a); > | ^ > tester.c:11:25: error: expected primary-expression before 'int' >11 | void foo (__extension__ int a);
[Bug c/88237] New: __extension__ in function declaration argument list causes error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88237 Bug ID: 88237 Summary: __extension__ in function declaration argument list causes error Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jozef.l at mittosystems dot com Target Milestone: --- The following code errors on trunk: void foo (__extension__ int a); > gcc -S tester.c > > tester.c:11:11: error: expected declaration specifiers or '...' before > '__extension__' >11 | void foo (__extension__ int a);
[Bug target/87883] [ARM] ICE: Segmentation fault in arm_regno_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87883 --- Comment #2 from Jozef Lawrynowicz --- Created attachment 45074 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45074=edit reg class checking patch Hi Mihail, Thanks for the info. I fixed a bug for msp430-elf caused by REGNO_REG_CLASS and REG_CLASS_CONTENTS being out of sync i.e. REGNO_REG_CLASS[reg] reported one class, but the bit for that reg in that class was not set in REG_CLASS_CONTENTS. So I was trying to add some generic warning to the middle-end which would catch these cases for other targets (see attached patch). However, there were some other issues with my proposal so I've parked it for now. Given that I'm not going to proceed with my patch in its current state, it's up to you whether to close this PR or not. Kind regards, Jozef
[Bug libstdc++/88111] libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88111 --- Comment #3 from Jozef Lawrynowicz --- (In reply to Jonathan Wakely from comment #2) > Does it even make sense to have pools for objects of 1024 bytes on a 16-bit > target? Is anybody really going to dynamically-allocate lots of 1kb objects? > > It certainly seems unnecessary to support objects of size 1<<14 bytes. I would agree, your change to limit the object size below the theoretical max object size makes sense. For the largest 20-bit address space MSP430 devices, RAM can be almost 2^18, but that would still only allow space for 64 2^12 objects, so the limitation for "__SIZE_WIDTH__ > 16" also seems to be at a good number. > I'd prefer to fix this for any 16-bit targets, not just msp430, so I don't > want the fix to check __MSP430X_LARGE__. > > So taking all the above into account, and assuming __SIZE_WIDTH__ is set > correctly, something like this seems preferable: Ah, I wasn't aware of the __SIZE_WIDTH__ builtin, that's a much better way to handle it. Your patch fixes the build, thanks.
[Bug libstdc++/88111] libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88111 --- Comment #8 from Jozef Lawrynowicz --- Created attachment 45068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45068=edit testsuite_abi.cc __int20 hack
[Bug libstdc++/88111] libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88111
--- Comment #7 from Jozef Lawrynowicz ---
(In reply to Jonathan Wakely from comment #6)
> This should be fixed now.
>
> If you're able to run the tests for these components that would be very much
> appreciated. To run just the tests, run the following in
> the $objdir/$target/libstdc++-v3 directory:
>
> make check RUNTESTFLAGS=conformance.exp=20_util/*_resource/*
Most of the memory_resource tests are too large for the default MSP430
configuration and fail at link time due to memory region overflows.
> PASS: 20_util/memory_resource/1.cc (test for excess errors)
> PASS: 20_util/monotonic_buffer_resource/1.cc (test for excess errors)
>
>=== libstdc++ Summary ===
>
> # of expected passes2
> # of unexpected failures 11
> # of unresolved testcases 11
> # of unsupported tests5
Running the tests with -mlarge doesn't currently work, as testsuite_abi.cc
won't compile. Since size_t is __int20, instances of "cout << (size_t)" cause
an error:
> util/testsuite_abi.cc:501: error: ambiguous overload for 'operator<<' in
> 'std::cout.std::basic_ostream::operator<<(std::endl std::char_traits >) <<
> added_names.std::vector >::size()' (operand
> types are 'std::basic_ostream::__ostream_type' {aka
> 'std::basic_ostream'} and 'std::vector
> >::size_type' {aka '__int20 unsigned'})
A quick hack (attached) of casting usage of size_t with cout to (unsigned long)
gets testsuite_abi.cc building so the tests can be run.
The -mlarge/-mcode-region=either/-mdata-region=either configuration makes the
best use of the 20-bit address space, so most of the tests do actually link and
pass now.
> make check RUNTESTFLAGS="conformance.exp=20_util/*_resource/*
> --target_board=msp430-sim/-mlarge/-mdata-region=either/-mcode-region=either"
> === libstdc++ Summary ===
>
> # of expected passes21
> # of unexpected failures3
> # of unsupported tests 5
One failure is at compile time, due to a couple of warnings in
allocate-max-chunks.cc. This is also present in the default configuration, but
obscured among all the relocation overflows.
> Excess errors:
> libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate-max-chunks.cc:39:
> warning: integer overflow in expression of type 'int' results in '0'
> [-Woverflow]
> libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate-max-chunks.cc:67:
> warning: left shift count >= width of type [-Wshift-count-overflow]
The allocate-max-chunks execution tests subsequently fails:
> unsynchronized_pool_resource/allocate-max-chunks.cc:67: void test01():
> Assertion 'opts.max_blocks_per_chunk <= (1 << 19)' failed.
The third and final failure is at execution:
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): std::bad_alloc
> FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
I've seen many "terminate called after..." failures in the G++ testsuite being
caused by stack overrunning into heap, so I'm not sure at this point if this is
a real failure.
Testsuite .log is attached.
Should I file separate PRs for these errors?
I'll look at the "cout << (__int20)" issue a bit more as well.
[Bug libstdc++/88111] libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88111 --- Comment #9 from Jozef Lawrynowicz --- Created attachment 45069 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45069=edit mlarge memory_resource tests libstdc++.log
[Bug libstdc++/88111] libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88111 --- Comment #1 from Jozef Lawrynowicz --- Created attachment 45043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45043=edit patch untested fix
[Bug libstdc++/88113] New: Woverflow warning in memory_resource.cc (struct bitset), for 16-bit size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88113
Bug ID: 88113
Summary: Woverflow warning in memory_resource.cc (struct
bitset), for 16-bit size_t
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
In the definition of struct bitset in
libstdc++-v3/src/c++17/memory_resource.cc, "size_type" (using uint32_t), and
size_t appear to be used interchangeably.
However, for some targets size_t != uint32_t, for example msp430-elf uses
uint16_t for size_t in the small memory model, and "unsigned __int20" in the
large memory model.
This results in a warning:
> ../../../../../libstdc++-v3/src/c++17/memory_resource.cc: In static member
> function 'static constexpr std::size_t
> std::pmr::{anonymous}::bitset::max_blocks_per_chunk()':
> ../../../../../libstdc++-v3/src/c++17/memory_resource.cc:401:39: warning:
> conversion from 'long long unsigned int' to 'std::size_t' {aka 'unsigned
> int'} changes value from '524287' to '65535' [-Woverflow]
> 401 | { return (1ull << _S_size_digits) - 1; }
> | ~^~~
"_S_size_digits" uses "size_type" to calculate the number of digits, whilst
"max_blocks_per_chunk" returns "size_t".
[Bug libstdc++/88111] New: libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88111
Bug ID: 88111
Summary: libstdc++-v3 FTB for 16-bit int: memory_resource.cc
pool_sizes expects >16-bit int/size_t
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
Building libstdc++-v3 for msp430-elf (16-bit int/size_t) results in the
following errors/warnings on current trunk:
> ../../../../../libstdc++-v3/src/c++17/memory_resource.cc: At global scope:
> ../../../../../libstdc++-v3/src/c++17/memory_resource.cc:825:38: warning:
> left shift count >= width of type [-Wshift-count-overflow]
> 825 | 1<<12, 1<<13, 1<<14, 1<<15, 1<<16, 1<<17,
> | ^~
> ../../../../../libstdc++-v3/src/c++17/memory_resource.cc:825:45: warning:
> left shift count >= width of type [-Wshift-count-overflow]
> 825 | 1<<12, 1<<13, 1<<14, 1<<15, 1<<16, 1<<17,
> | ^~
> ../../../../../libstdc++-v3/src/c++17/memory_resource.cc:826:10: warning:
> left shift count >= width of type [-Wshift-count-overflow]
> 826 | 1<<20, 1<<21, 1<<22 // 4MB should be enough for anybody
> | ^~
> ../../../../../libstdc++-v3/src/c++17/memory_resource.cc:826:17: warning:
> left shift count >= width of type [-Wshift-count-overflow]
> 826 | 1<<20, 1<<21, 1<<22 // 4MB should be enough for anybody
> | ^~
> ../../../../../libstdc++-v3/src/c++17/memory_resource.cc:826:24: warning:
> left shift count >= width of type [-Wshift-count-overflow]
> 826 | 1<<20, 1<<21, 1<<22 // 4MB should be enough for anybody
> |^~
> ../../../../../libstdc++-v3/src/c++17/memory_resource.cc:827:3: error:
> narrowing conversion of '-32768' from 'int' to 'std::size_t' {aka 'unsigned
> int'} [-Wnarrowing]
> 827 | };
> | ^
> ../../../../../libstdc++-v3/src/c++17/memory_resource.cc: In function
> 'std::pmr::pool_options
> std::pmr::{anonymous}::munge_options(std::pmr::pool_options)':
> ../../../../../libstdc++-v3/src/c++17/memory_resource.cc:860:29: error:
> non-constant condition for static assertion
> 860 | static_assert(std::__ispow2(pool_sizes[0]));
> |~^~~
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 Jozef Lawrynowicz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Jozef Lawrynowicz --- Fixed on trunk.
[Bug target/87927] ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87927 Jozef Lawrynowicz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jozef Lawrynowicz --- Fixed on trunk.
[Bug rtl-optimization/89575] LRA for msp430 - Max. number of generated reload insns - frame pointer subreg simplification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89575 --- Comment #1 from Jozef Lawrynowicz --- Created attachment 45882 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45882=edit ira dump
[Bug rtl-optimization/89575] LRA for msp430 - Max. number of generated reload insns - frame pointer subreg simplification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89575 --- Comment #2 from Jozef Lawrynowicz --- Created attachment 45883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45883=edit reload dump
[Bug rtl-optimization/89575] New: LRA for msp430 - Max. number of generated reload insns - frame pointer subreg simplification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89575
Bug ID: 89575
Summary: LRA for msp430 - Max. number of generated reload insns
- frame pointer subreg simplification
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jozef.l at mittosystems dot com
Target Milestone: ---
Created attachment 45881
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45881=edit
testcase
When enabling LRA for msp430, libgcc fails to build, specifically _muldi3.o.
> gcc -S tester.i -O2
> during RTL pass: reload
> ../../../../libgcc/libgcc2.c: In function '__muldi3':
> ../../../../libgcc/libgcc2.c:558:1: internal compiler error: Max. number of
> generated reload insns per insn is achieved (90)
>
> 558 | }
> | ^
> 0xa2ab20 lra_constraints(bool)
> ../../gcc/lra-constraints.c:4875
> 0xa12b84 lra(_IO_FILE*)
> ../../gcc/lra.c:2461
> 0x9c68f1 do_reload
> ../../gcc/ira.c:5516
> 0x9c68f1 execute
> ../../gcc/ira.c:5700
The cycling reload occurs because IRA assigns hard register R4 (also
FRAME_POINTER_REGNUM, but not fixed for this use) to a pseudo reg, but when LRA
goes to simplify a subreg of the pseudo, it disallows simplification of this
subreg.
Specifically, simplify_subreg_regno (rtlanal.c):
> /* We shouldn't simplify stack-related registers. */
> if ((!reload_completed || frame_pointer_needed)
> && xregno == FRAME_POINTER_REGNUM)
> return -1;
This is in an output reload, so a new set of mov insns are generated to load
the value back into the original, problematic pseudo of R4. Once again
simplify_subreg_regno is called to simplify the pseudo of R4, but it is
disallowed and the cycle continues.
From the IRA dump:
> Disposition:
> 0:r28 l0 82:r30 l0 41:r31 l0 4
> ...
> (insn 2 6 3 2 (set (subreg:HI (reg/v:DI 30 [ arg1 ]) 0)
> (reg:HI 12 R12 [ arg1 ])) "tester.c":16:1 12 {movhi}
> (expr_list:REG_DEAD (reg:HI 12 R12 [ arg1 ])
> (nil)))
From the reload dump:
> Creating newreg=37 from oldreg=30, assigning class NO_REGS to subreg reg
> r37
> 2: r37:DI#0=R12:HI
> ...
> Inserting subreg reload after:
> 42: r30:DI#0=r37:DI#0
> ...
> Creating newreg=38 from oldreg=30, assigning class NO_REGS to subreg reg
> r38
> 42: r38:DI#0=r37:DI#0
> ...
> Inserting subreg reload after:
> 52: r30:DI#0=r38:DI#0
And so on.
Is it OK to allow simplification of a subreg of FRAME_POINTER_REGNUM
when lra_in_progress is true? After all, constraints on the allocation of hard
regs shouldn't get more resitrictive as compilation progresses?
e.g.
diff --git a/gcc/rtlanal.c b/gcc/rtlanal.c
index 3873b4098b0..9700928ff4e 100644
--- a/gcc/rtlanal.c
+++ b/gcc/rtlanal.c
@@ -3971,7 +3971,7 @@ simplify_subreg_regno (unsigned int xregno, machine_mode
xmode,
return -1;
/* We shouldn't simplify stack-related registers. */
- if ((!reload_completed || frame_pointer_needed)
+ if ((!(reload_completed || lra_in_progress) || frame_pointer_needed)
&& xregno == FRAME_POINTER_REGNUM)
return -1;
This fixes the cycling reload for insn 2, as the frame pointer is not needed,
but there are further separate issues building the test case.
I've attached a reduced test case, and the IRA and reload dumps.
> gcc -v
> Target: msp430-elf
> Configured with: ../configure --target=msp430-elf --disable-nls
> --enable-languages=c,c++
> Thread model: single
> gcc version 9.0.1 20190301 (experimental) (GCC)
[Bug testsuite/89258] [9 Regression] verify_gimple failed in gimple test pr80887 for 16-bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89258 Jozef Lawrynowicz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jozef Lawrynowicz --- (In reply to Jakub Jelinek from comment #1) > So you just want to guard this test with int32plus. Thanks, applied. Closing this PR.
[Bug testsuite/89258] New: [9 Regression] verify_gimple failed in gimple test pr80887 for 16-bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89258 Bug ID: 89258 Summary: [9 Regression] verify_gimple failed in gimple test pr80887 for 16-bit target Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: jozef.l at mittosystems dot com Target Milestone: --- Created attachment 45649 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45649=edit pr80887.c gcc.dg/tree-ssa/pr80887.c ICEs for msp430-elf on trunk. xgcc gcc/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c -fgimple -msim -S gcc/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c: In function 'f': gcc/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c:6:1: error: type mismatch in binary expression 6 | f() | ^ unsigned int unsigned int long unsigned int u_9 = _4 + 4294967295; gcc/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c:6:1: error: type mismatch in binary expression unsigned int unsigned int long unsigned int t2_12 = _6 + 4294967294; during GIMPLE pass: omplower gcc/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c:6:1: internal compiler error: verify_gimple failed 0xbd430d verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.c:5094 0xacfd0a execute_function_todo ../../gcc/passes.c:1979 0xad0c02 execute_todo ../../gcc/passes.c:2031 --- The test passes on gcc-8-branch (less strict gimple checking in GCC8?). int size is 16-bits for msp430, the constants use in this test assume at least 32-bit int.
[Bug target/78838] msp430 option -mcode-region=either, -ffunction-sections, and interrupt function attributes cause incorrect section to be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78838 Jozef Lawrynowicz changed: What|Removed |Added CC||jozef.l at mittosystems dot com --- Comment #5 from Jozef Lawrynowicz --- (In reply to Martin Liška from comment #4) > Nick: Can the bug be marked as resolved? Yes, the test case passes on trunk - ISRs are not put in .either.lowtext when compiling with -ffunction-sections and -mcode-region=either.
[Bug target/78554] Internal Compiler Error in msp430 target with -mlarge, -O{s123}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78554 Jozef Lawrynowicz changed: What|Removed |Added CC||jozef.l at mittosystems dot com --- Comment #1 from Jozef Lawrynowicz --- The test case no longer ICEs on trunk, can someone please close this. Thanks, Jozef
