[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210 Jozef Lawrynowicz changed: What|Removed |Added Resolution|--- |WONTFIX Status|REOPENED|RESOLVED --- Comment #10 from Jozef Lawrynowicz --- I think its best to close this as WONTFIX. GCC will only erroneously enable SHF_GNU_RETAIN support if a Binutils version between: > commit 99fabbc9739a87ba3433e66792e93b773896790e > Author: Jozef Lawrynowicz > Date: Wed Nov 18 11:51:13 2020 + > >Support SHF_GNU_RETAIN ELF section flag and > commit ff4bc37d77a0ca7286883a477adcb3aa145fc782 > Author: Cary Coutant > Date: Mon Dec 14 15:46:47 2020 -0800 > > Keep input SHF_GNU_RETAIN sections and strip output SHF_GNU_RETAIN for > GNU/FreBSD ELFOSABIs. is being used. There's no Binutils release in this range.
[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210 --- Comment #9 from Jozef Lawrynowicz --- I believe this PR only relates to the fact that GCC support for SHF_GNU_RETAIN was available before GOLD supported that section flag. My proposed patch was to turn off GCC support for SHF_GNU_RETAIN if an unsupported GOLD is detected. I think at this point, the GOLD functionality was only broken for such a narrow period of time in development (not corresponding to a concrete version of Binutils), there's no point adding a configure test to try and catch that now. (In reply to Jakub Jelinek from comment #8) > Isn't this problem gone with > r11-7284-g6347f4a0904fce17eedf5c071be6f3c118680290 ? > I mean, attribute used now means what it used to mean before, and retain > attribute is not used in whatever is emitted into .init_array section at > least in existing code. Yes, one might use it in user code, but the answer > can be don't do it then. And yes, since none of the libraries using the "used" attribute will implicitly create SHF_GNU_RETAIN sections any more, even if you used the Binutils version with broken GOLD, it won't cause any problems.
[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210 --- Comment #6 from Jozef Lawrynowicz --- I've posted a patch where the HAVE_GAS_SHF_GNU_RETAIN configure test has been extended to check for SHF_GNU_RETAIN gold support: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562100.html
[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210 --- Comment #4 from Jozef Lawrynowicz --- Since gold is not built by default, should we just disable SHF_GNU_RETAIN support if gold has been built at all, for Binutils versions without the gold patch. There's 2 weeks between the GCC "used" implying SHF_GNU_RETAIN patch and gold being fixed, so the real fix if you want SHF_GNU_RETAIN support but are using a Binutils version in this timeframe is to just upgrade. Meanwhile we should just completely turn off SHF_GNU_RETAIN if GCC can spot that a broken gold is available.
[Bug target/98121] [11 Regression] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121 Jozef Lawrynowicz changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #11 from Jozef Lawrynowicz --- I'm going to resolve this as WONTFIX since we're not going to change the fact that the "used" attribute applies SHF_GNU_RETAIN. There are no section flag conflicts when a declaration that has the "used" attribute applied interfaces with a section defined in assembler code. The assembler will keep sections with different SHF_GNU_RETAIN states separate. There was a GCC bug causing section flag conflicts in one specific situation, that is tracked in PR target/98146.
[Bug target/98146] New: [11 Regression] section type conflict when "used" attribute is applied to decl with specific section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98146
Bug ID: 98146
Summary: [11 Regression] section type conflict when "used"
attribute is applied to decl with specific section
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jozefl at gcc dot gnu.org
Target Milestone: ---
For targets that support the SHF_GNU_RETAIN ELF section flag, the "used"
attribute will set the internal GCC SECTION_RETAIN flag on the section
containing the "used" decl.
If a "used" decl, and a decl without "used" both specify the same section with
the "section" attribute, GCC will emit an error:
$ cat tester.c
int __attribute__((section(".data.foo"))) foo1 = 1;
int __attribute__((used,section(".data.foo"))) foo2 = 2;
$ gcc -S tester.c
tester.c:2:48: error: 'foo2' causes a section type conflict with 'foo1'
2 | int __attribute__((used,section(".data.foo"))) foo2 = 2;
|^~~~
tester.c:1:43: note: 'foo1' was declared here
1 | int __attribute__((section(".data.foo"))) foo1 = 1;
| ^~~~
This was originally reported in glibc PR 27002, but is actually a GCC bug.
[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121
--- Comment #8 from Jozef Lawrynowicz ---
(In reply to Jozef Lawrynowicz from comment #7)
> (In reply to Florian Weimer from comment #6)
> > (In reply to Jozef Lawrynowicz from comment #4)
> > > GAS merges the "R" flag state in .section declarations, silently, and with
> > > logical OR, and GCC should do the same. So if you have:
> > >
> > > int __attribute__((section(".data.foo"))) foo1 = 1;
> > > int __attribute__((used,section(".data.foo"))) foo2 = 2;
> > >
> > > .data.foo should have SECTION_RETAIN set within GCC. The addition of the
> > > "used" attribute to the second declaration of section(".data.foo") should
> > > not cause any warning/error messages to be emitted either. So option 3
> > > from
> > > above.
> > >
> > > Just need to do something similar to what is already done for
> > > SECTION_NOTYPE
> > > in varasm.c:get_section.
> >
> > I don't now the details, but I think foo1 should not implicitly be marked as
> > “used”. The difference matters for static functions, for example. GCC should
> > still drop them if they are not referenced, even if they are located in a
> > retained section. So free_slotinfo in comment 5.
>
> With the suggested approach, GCC would still drop foo1 if it is not used,
> since it is only the section being marked with SECTION_RETAIN, and this only
> affects whether the "R" flag is output in the .section directive for the
> decl.
>
> GCC will only keep an unreferenced decl if it has DECL_PRESERVE_P and we
> haven't changed that with the "used" applies SHF_GNU_RETAIN functionality.
>
> If foo1 somehow makes it into the assembler code, it will be kept, even if
> it is not used, since we lose the ability to remove individual decls once
> they are put in sections.
Sorry, in my foo1/foo2 example they are not static so will not be dropped by
GCC.
For the free_slotinfo example, it would be dropped by GCC if unused, even
though another function with the same section was marked "used" and has
SECTION_RETAIN.
[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121
--- Comment #7 from Jozef Lawrynowicz ---
(In reply to Florian Weimer from comment #6)
> (In reply to Jozef Lawrynowicz from comment #4)
> > GAS merges the "R" flag state in .section declarations, silently, and with
> > logical OR, and GCC should do the same. So if you have:
> >
> > int __attribute__((section(".data.foo"))) foo1 = 1;
> > int __attribute__((used,section(".data.foo"))) foo2 = 2;
> >
> > .data.foo should have SECTION_RETAIN set within GCC. The addition of the
> > "used" attribute to the second declaration of section(".data.foo") should
> > not cause any warning/error messages to be emitted either. So option 3 from
> > above.
> >
> > Just need to do something similar to what is already done for SECTION_NOTYPE
> > in varasm.c:get_section.
>
> I don't now the details, but I think foo1 should not implicitly be marked as
> “used”. The difference matters for static functions, for example. GCC should
> still drop them if they are not referenced, even if they are located in a
> retained section. So free_slotinfo in comment 5.
With the suggested approach, GCC would still drop foo1 if it is not used, since
it is only the section being marked with SECTION_RETAIN, and this only affects
whether the "R" flag is output in the .section directive for the decl.
GCC will only keep an unreferenced decl if it has DECL_PRESERVE_P and we
haven't changed that with the "used" applies SHF_GNU_RETAIN functionality.
If foo1 somehow makes it into the assembler code, it will be kept, even if it
is not used, since we lose the ability to remove individual decls once they are
put in sections.
[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121
--- Comment #4 from Jozef Lawrynowicz ---
(In reply to H.J. Lu from comment #2)
> The issue here is that what should happen when definitions marked with used
> attribute and unmarked definitions are put in the same section. It has
> nothing
> to do with .retain.
This bug report doesn't mention that. It looks to me that Florian was looking
to discuss the conceptual issue of whether the "used" attribute should apply
SHF_GNU_RETAIN.
I assume you're referring to the glibc bug 27002 with though.
(In reply to H.J. Lu from comment #3)
> If we cant to use SHF_GNU_RETAIN on used attribute, compiler can do
>
> 1. Issue an error.
> 2. issue a warning and mark the unmarked definition as used.
> 3. Silently mark the unmarked definition as used.
GAS merges the "R" flag state in .section declarations, silently, and with
logical OR, and GCC should do the same. So if you have:
int __attribute__((section(".data.foo"))) foo1 = 1;
int __attribute__((used,section(".data.foo"))) foo2 = 2;
.data.foo should have SECTION_RETAIN set within GCC. The addition of the "used"
attribute to the second declaration of section(".data.foo") should not cause
any warning/error messages to be emitted either. So option 3 from above.
Just need to do something similar to what is already done for SECTION_NOTYPE in
varasm.c:get_section.
[Bug target/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121 jozefl at gcc dot gnu.org changed: What|Removed |Added CC||jozefl at gcc dot gnu.org --- Comment #1 from jozefl at gcc dot gnu.org --- The feedback after I originally submitted a patch that implements a "retain" attribute to apply SHF_GNU_RETIAN, was that "used" should instead apply SHF_GNU_RETAIN: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557097.html The discussions went on about other aspects of the implementation in other threads, but there were no objections to the idea of "used" applying SHF_GNU_RETAIN. I think the logic is sound that a declaration marked with the "used" attribute should not be removed by the compiler, or garbage collected by the linker. Basically, if you mark a declaration as "used", it should be retained in the final program, even if it was not referenced. The issue lies in the fact that the "used" attribute has been around for so long, that the change in behavior has the potential to affect existing applications that make use of it. However, the new behavior is only enabled when using the latest GCC and latest Binutils. Some change in behavior can be expected when using the latest versions of the tools. This new behavior should really be documented in the release notes though. I didn't want to have "used" change section attributes in assembler directives, the original plan was to use a separate assembler ".retain" directive to apply SHF_GNU_RETAIN. This would mean we could leave .section assembler directives for a particular "used" declaration untouched, and just emit a ".retain " directive. The assembler therefore handles the application of the SHF_GNU_RETAIN flag to a particular section, instead of forcing the compiler to have to make these additional considerations about section attributes. I even did a patch for that, but there was staunch objection from H.J. on this, on multiple occasions, I realized we weren't going to get anywhere: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557931.html https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558400.html https://sourceware.org/pipermail/binutils/2020-November/114077.html I would be more than happy to add the .retain attribute to Binutils, but we would need a Binutils global maintainer to approve that, and no one gave the OK for my original ".retain " patch the first time round. I could then change the GCC implementation to use the ".retain" directive, which would ensure that section attributes in assembler code output by GCC are not contaminated with the "R" flag when the "used" attribute is applied. Thanks, Jozef
[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798 --- Comment #23 from jozefl at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #22) > I tested the patches on x86_64-linux and confirmed that the branches can > bootstrap msp430-elf, so I went ahead and pushed them. > > If you're not going to release anything from the gcc-8 branch, is it OK to > leave that unfixed? If so, I think we can close this. Fine by me, thanks!
[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798 --- Comment #19 from jozefl at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #18) > The patch will apply cleanly to gcc-10 but not gcc-9. Let me know if you > want me to prepare a patch for the gcc-9 branch. If it's not too much work, it would be great if you could. I'm actually just finalizing the MSP430-GCC release that TI will distribute, and it's the last one based off GCC 9, and the last one to be released for a while, so getting it in there would be great. Let me know if I can help, thanks.
[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798 --- Comment #16 from jozefl at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #15) > Hmm, I get the same error for a out-of-tree binutils built from today's git > sources: > > GNU assembler (GNU Binutils) 2.35.50.20201112 > Copyright (C) 2020 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or later. > This program has absolutely no warranty. > This assembler was configured for a target of `msp430-elf'. Sigh, that's a different bug. I removed a GAS option that doesn't do anything, but is automatically passed by MSP430 GCC 10 ASM_SPEC when certain other options aren't present. And my GCC 10 tester explicitly uses Binutils 2.34 rather than master, so it went undetected. Pushed a Binutils fix. gcc-10 branch now builds with latest Binutils. Thanks for reporting this.
[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798 --- Comment #14 from jozefl at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #13) > I tried a bootstrap of gcc-10 and I get this error during libgcc/configure > > conftest.s: Assembler messages: > conftest.s:168: Error: unknown pseudo-op: `.mspabi_attribute' > conftest.s:169: Error: unknown pseudo-op: `.mspabi_attribute' > conftest.s:170: Error: unknown pseudo-op: `.mspabi_attribute' > > This is using the same binutils that I used to successfully bootstrap trunk: > > GNU assembler (GNU Binutils) 2.32.51.20190613 > Copyright (C) 2019 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or later. > This program has absolutely no warranty. > This assembler was configured for a target of `msp430-elf'. .mspabi_attribute was only supported since Binutils 2.34. Until GCC commit b75863a88ec, the preprocessor conditional that tries to switch off .mspabi_attribute emission wasn't implemented correctly, and didn't switch it off. The conftest was also wrong, and always fails for an out of tree Binutils. So if you're using an out of tree Binutils version < 2.34, the conftest fails, but GCC will still generate the assembler directive that is unsupoprted. An in-tree Binutils < 2.34 or >= 2.34 always works fine. I should really backport this fix to GCC 10.
[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798 --- Comment #12 from jozefl at gcc dot gnu.org --- Thanks! I've set off a full msp430-elf build and regtest. I'll look at backporting it to GCC8/9/10 branches after testing.
[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798 --- Comment #9 from jozefl at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #8) > My attempt to build msp430 fails with: > > In file included from > /home/jwakely/gcc/msp430-elf/msp430-elf/include/stdint.h:13, > from > /home/jwakely/src/gcc/build-16bit/gcc/include/stdint.h:9, > from > /home/jwakely/src/gcc/build-16bit/msp430-elf/large/libstdc++-v3/include/bits/ > align.h:36, > from > /home/jwakely/src/gcc/build-16bit/msp430-elf/large/libstdc++-v3/include/ > memory:72, > from > /home/jwakely/src/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h:82: > /home/jwakely/gcc/msp430-elf/msp430-elf/include/sys/_intsup.h:68:2: error: > #error "Unable to determine type definition of intptr_t" >68 | #error "Unable to determine type definition of intptr_t" > | ^ > > > Is that related? Newlib is required for MSP430. Symlink the newlib/ and libgloss/ subdirs into the GCC tree root.
[Bug c++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798 --- Comment #2 from jozefl at gcc dot gnu.org --- Created attachment 49547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49547&action=edit tester.ii (In reply to Marek Polacek from comment #1) > Would it be possible to provide a preprocessed source file? (Large) testcase attached. I can run it through a reducer and re-upload if required. Reproduces with: > $ msp430-elf-gcc -mlarge -std=gnu++20 tester.ii -S -w Thanks, Jozef
[Bug c++/97798] New: FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798 Bug ID: 97798 Summary: FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jozefl at gcc dot gnu.org Target Milestone: --- GCC fails to build for msp430-elf since: commit c2856ceec2e7542fe9b0bf104afb57d6996d Author: Marek Polacek Date: Thu Oct 29 15:19:51 2020 -0400 c++: Tweaks for value_dependent_expression_p. There is an error building libstdc++ for the -mlarge multilib, which uses __int20 pointers: > In file included from > /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/sstream:38, > from > ../../../../../../libstdc++-v3/src/c++20/sstream-inst.cc:30: > /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream: > In function 'std::basic_istream<_CharT, _Traits>& > std::operator>>(std::basic_istream<_CharT, _Traits>&, _CharT (&)[_Num])': > /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:840:26: > error: non-constant condition for static assertion > 840 | static_assert(_Num <= > __gnu_cxx::__numeric_traits::__max); > | > ~^ > /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:840:26: > error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is > not usable in a constant expression > In file included from > /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/bits/stl_algobase.h:63, > from > /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/bits/char_traits.h:39, > from > /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/ios:40, > from > /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/istream:38, > from > /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/sstream:38, > from > ../../../../../../libstdc++-v3/src/c++20/sstream-inst.cc:30: > /home/jozef/msp430/gcc/build-msp430/msp430-elf/large/libstdc++-v3/include/ext/numeric_traits.h:78:27: > note: '__gnu_cxx::__numeric_traits_integer<__int20>::__max' was not > initialized with a constant expression >78 | static const _Value __max = __glibcxx_max(_Value); > | ^ > make[9]: *** [Makefile:550: sstream-inst.lo] Error 1 Configured with: > ../configure --target=msp430-elf --enable-languages=c,c++ --disable-nls > --disable-no-exceptions --disable-full-memory-range
[Bug tree-optimization/96458] New: [10/11 Regression] internal compiler error: in expand_expr_addr_expr_1, at expr.c:8075 for msp430-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96458
Bug ID: 96458
Summary: [10/11 Regression] internal compiler error: in
expand_expr_addr_expr_1, at expr.c:8075 for msp430-elf
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jozefl at gcc dot gnu.org
Target Milestone: ---
Created attachment 48993
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48993&action=edit
lambda-generic-variadic20.ii
g++.dg/cpp1y/lambda-generic-variadic20.C ICEs for msp430-elf on trunk and the
gcc-10 branch.
> ./gcc/xg++ -v
> Configured with: ../configure --target=msp430-elf --enable-languages=c,c++
> ./gcc/g++ -B./gcc lambda-generic-variadic20.ii -std=c++14 -S
during RTL pass: expand
lambda-generic-variadic20.ii: In static member function 'static decltype
(((const fooV<{const char*, int, double, char, float, short int, unsigned
int}>::*)0)->operator()(static_cast(fooV::._anon_2::_FUN::) ...)) fooV<{const
char*, int, double, char, float, short int, unsigned int}>_FUN(auto:1 ...) [with auto:1 = {fooV<{const char*, int, double, char,
float, short int, unsigned int}>::, const char*, int,
double, char, float, short int, unsigned int}]':
lambda-generic-variadic20.ii:2:12: internal compiler error: in
expand_expr_addr_expr_1, at expr.c:8186
2 | auto L = [](auto ... a) {
|^~~~
3 | auto M = [](decltype(a) ... b) -> void {
|
4 | };
| ~~
5 | return M;
| ~
6 | };
| ~
0x6a07f5 expand_expr_addr_expr_1
../../gcc/expr.c:8186
0xc26ebd expand_expr_addr_expr
../../gcc/expr.c:8299
0xc26ebd expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11468
0xaeb9a0 expand_normal
../../gcc/expr.h:288
0xaeb9a0 precompute_register_parameters
../../gcc/calls.c:982
0xaf48c7 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:4323
0xc27d76 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11240
0xc32490 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.c:5852
0xc345f6 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5588
0xc345f6 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5130
0xb0a093 expand_call_stmt
../../gcc/cfgexpand.c:2701
0xb0a093 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3682
0xb0a093 expand_gimple_stmt
../../gcc/cfgexpand.c:3847
0xb0af2a expand_gimple_basic_block
../../gcc/cfgexpand.c:5888
0xb0c9f6 execute
../../gcc/cfgexpand.c:6572
Since the following commit:
commit a3a4f6be0c7ac1536c4d1def14217840b04dd488
Author: Patrick Palka
Date: Mon Apr 20 18:34:00 2020 -0400
c++: Recursive unification with packs and explicit targs [PR94628]
Although, prior to that commit, the test didn't still didn't work:
> lambda-generic-variadic20.ii: In instantiation of 'int fooV(Ts ...) [with Ts
> = {const char*, int, double, char, float, short int, unsigned int}]':
> lambda-generic-variadic20.ii:16:65: required from here
> lambda-generic-variadic20.ii:6:14: error: expansion pattern 'decltype
> ('nontype_argument_pack' not supported by dump_expr)'
> contains no parameter packs
I presume the above commit fixed the behaviour in general, but underlying
issues for msp430-elf mean it still doesn't work on that target.
[Bug ipa/96430] New: internal compiler error: in verify_range, at value-range.cc:354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96430 Bug ID: 96430 Summary: internal compiler error: in verify_range, at value-range.cc:354 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: jozefl at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- The GCC selftest "range_tests" is failing for msp430-elf since commit 4ba9fb0a3e65254cb5d8cb0a3bc67bbef8ed2fcf Author: Aldy Hernandez Date: Thu Jul 30 11:30:18 2020 +0200 Multi-range implementation for value_range (irange). > ./gcc/xgcc -B./gcc/ -v > Target: msp430-elf > Configured with: ../configure --target=msp430-elf --enable-languages=c,c++ ./gcc/xgcc -B./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=../../gcc/testsuite/selftests In function 'test_fn': cc1: internal compiler error: in verify_range, at value-range.cc:354 0x6cbc39 irange::verify_range() ../../gcc/value-range.cc:354 0xffdb2b irange::irange_set(tree_node*, tree_node*) ../../gcc/value-range.cc:157 0xffdb2b irange::set(tree_node*, tree_node*, value_range_kind) ../../gcc/value-range.cc:211 0x141200b int_range<255u>::int_range(tree_node*, tree_node*, value_range_kind) ../../gcc/value-range.h:412 0x141200b operator_rshift::op1_range(irange&, tree_node*, irange const&, irange const&) const ../../gcc/range-op.cc:1635 0x1414223 operator_tests ../../gcc/range-op.cc:3534 0x1419556 selftest::range_tests() ../../gcc/range-op.cc:3826 0x135513c test_ranges ../../gcc/function-tests.c:582 0x135513c selftest::function_tests_c_tests() ../../gcc/function-tests.c:690 0x14265ce selftest::run_tests() ../../gcc/selftest-run-tests.c:108 0xd19922 toplev::run_self_tests() ../../gcc/toplev.c:2391
[Bug rtl-optimization/66156] [msp430] wrong code generated with -O2 -mlarge (zero extension HI -> SI)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66156 jozefl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jozefl at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from jozefl at gcc dot gnu.org --- Fixed since GCC 6.
[Bug libstdc++/71133] msp430-elf -mlarge FTBFS in libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71133 jozefl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jozefl at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from jozefl at gcc dot gnu.org --- Fixed by Support unsigned __int20 in checks for size_t mangling 2017-01-20 Joe Seymour * acinclude.m4 (GLIBCXX_CHECK_SIZE_T_MANGLING): Support uint20_t. * configure: Regenerate.
[Bug target/70320] msp430 asm volatile does not accept lower-case register names in clobber list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70320 jozefl at gcc dot gnu.org changed: What|Removed |Added CC||jozefl at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from jozefl at gcc dot gnu.org --- Fixed since GCC 10.
[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58507 jozefl at gcc dot gnu.org changed: What|Removed |Added CC||jozefl at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from jozefl at gcc dot gnu.org --- Fixed.
[Bug target/78554] Internal Compiler Error in msp430 target with -mlarge, -O{s123}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78554 jozefl at gcc dot gnu.org changed: What|Removed |Added CC||jozefl at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from jozefl at gcc dot gnu.org --- Fixed.
[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 jozefl at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||jozefl at gcc dot gnu.org --- Comment #6 from jozefl at gcc dot gnu.org --- Fixed.
[Bug target/91306] [MSP430] libgcc/crtstuff.c: Alignment of frame_dummy .init_array entry is too big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91306 --- Comment #5 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Fri Aug 23 09:21:26 2019 New Revision: 274846 URL: https://gcc.gnu.org/viewcvs?rev=274846&root=gcc&view=rev Log: 2019-08-23 Jozef Lawrynowicz PR target/91306 * crtstuff.c (__CTOR_LIST__): Align to the "__alignof__" the array element type, instead of "sizeof" the element type. (__DTOR_LIST__): Likewise. (__TMC_LIST__): Likewise. (__do_global_dtors_aux_fini_array_entry): Likewise. (__frame_dummy_init_array_entry): Likewise. (__CTOR_END__): Likewise. (__DTOR_END__): Likweise. (__FRAME_END__): Likewise. (__TMC_END__): Likewise. Modified: trunk/libgcc/ChangeLog trunk/libgcc/crtstuff.c
[Bug target/70320] msp430 asm volatile does not accept lower-case register names in clobber list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70320 --- Comment #1 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Mon Jul 29 19:21:18 2019 New Revision: 273883 URL: https://gcc.gnu.org/viewcvs?rev=273883&root=gcc&view=rev Log: Allow both upper and lower case 'r' in register names 2019-07-29 Jozef Lawrynowicz PR target/70320 * config/msp430/msp430.h: Define ADDITIONAL_REGISTER_NAMES. 2019-07-29 Jozef Lawrynowicz PR target/70320 * gcc.target/msp430/asm-register-names-lower-case.c: New test. * gcc.target/msp430/asm-register-names-upper-case.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/msp430/asm-register-names-lower-case.c trunk/gcc/testsuite/gcc.target/msp430/asm-register-names-upper-case.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/msp430/msp430.h trunk/gcc/testsuite/ChangeLog
[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 --- Comment #2 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Fri Feb 8 16:47:28 2019 New Revision: 268704 URL: https://gcc.gnu.org/viewcvs?rev=268704&root=gcc&view=rev Log: 2019-02-08 Jozef Lawrynowicz PR testsuite/89258 * gcc.dg/tree-ssa/pr80887.c: Require int32plus. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr80887.c
[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 #11 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Sat Nov 17 00:45:43 2018 New Revision: 266230 URL: https://gcc.gnu.org/viewcvs?rev=266230&root=gcc&view=rev Log: 2018-11-17 Jozef Lawrynowicz PR middle-end/87854 * g++.dg/parse/concat1.C: Add dg-error for targets with size_t < 32 bits. Update comment. * gcc.dg/concat2.c: Likewise. * gcc.c-torture/compile/pr46534.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/concat1.C trunk/gcc/testsuite/gcc.c-torture/compile/pr46534.c trunk/gcc/testsuite/gcc.dg/concat2.c
[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 #5 from jozefl at gcc dot gnu.org ---
Author: jozefl
Date: Fri Nov 16 23:53:30 2018
New Revision: 266226
URL: https://gcc.gnu.org/viewcvs?rev=266226&root=gcc&view=rev
Log:
2018-11-16 Jozef Lawrynowicz
PR target/87927
* target-def.h: Initialize TARGET_ASM_{,UN}ALIGNED_P{S,D,T}I_OP.
Add them to the TARGET_ASM_{,UN}ALIGNED_INT_OP structs.
* target.def: Enumerate TARGET_ASM_{,UN}ALIGNED_P{S,D,T}I_OP in
the byte_op hook.
* target.h: Add psi, pdi, pti to struct asm_int_op definition.
* targhooks.c (default_print_patchable_function_entry): Assert
asm_int_op does not return a NULL string.
* varasm.c (integer_asm_op): Return the op for a partial int type
when the requested size does not correspond to an integer type.
* config/msp430/msp430.c: Initialize TARGET_ASM_{,UN}ALIGNED_PSI_OP.
* doc/tm.texi: Regenerate.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/msp430/msp430.c
trunk/gcc/doc/tm.texi
trunk/gcc/target-def.h
trunk/gcc/target.def
trunk/gcc/target.h
trunk/gcc/targhooks.c
trunk/gcc/varasm.c
[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691 --- Comment #10 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Wed Nov 7 22:06:26 2018 New Revision: 265894 URL: https://gcc.gnu.org/viewcvs?rev=265894&root=gcc&view=rev Log: 2018-11-07 Jozef Lawrynowicz PR c/87691 gcc/ChangeLog: * stor-layout.c (compute_record_mode): Set TYPE_MODE of UNION_TYPE to the mode of the widest field iff the widest field has mode class MODE_INT, or MODE_PARTIAL_INT and the union would be passed by reference. gcc/testsuite/ChangeLog: * gcc.target/msp430/pr87691.c: New test. Added: trunk/gcc/testsuite/gcc.target/msp430/pr87691.c Modified: trunk/gcc/ChangeLog trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog
[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 #5 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Sat Aug 25 12:10:28 2018 New Revision: 263853 URL: https://gcc.gnu.org/viewcvs?rev=263853&root=gcc&view=rev Log: Backport from mainline PR target/86662 * gcc/tree.c (build_common_tree_nodes): Initialize integer_types array with all enabled __intN types. * gcc/testsuite/gcc.target/msp430/pr86662.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/msp430/pr86662.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/tree.c
[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 #4 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Sat Aug 25 11:52:15 2018 New Revision: 263852 URL: https://gcc.gnu.org/viewcvs?rev=263852&root=gcc&view=rev Log: Backport from mainline PR target/86662 * gcc/tree.c (build_common_tree_nodes): Initialize integer_types array with all enabled __intN types. * gcc/testsuite/gcc.target/msp430/pr86662.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/msp430/pr86662.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/tree.c
[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 #3 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Mon Aug 6 10:29:17 2018 New Revision: 263332 URL: https://gcc.gnu.org/viewcvs?rev=263332&root=gcc&view=rev Log: PR target/86662 * gcc/tree.c (build_common_tree_nodes): Initialize integer_types array with all enabled __intN types. * gcc/testsuite/gcc.target/msp430/pr86662.c: New test. Added: trunk/gcc/testsuite/gcc.target/msp430/pr86662.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c
[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 #4 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Thu Aug 2 20:54:02 2018 New Revision: 263279 URL: https://gcc.gnu.org/viewcvs?rev=263279&root=gcc&view=rev Log: 2018-08-02 Jozef Lawrynowicz Backport from mainline 2018-07-31 Jozef Lawrynowicz PR middle-end/86705 * gcc/cfgexpand.c (set_parm_rtl): Use the alignment of Pmode when MAX_SUPPORTED_STACK_ALIGNMENT would otherwise be exceeded by the requested variable alignment. (expand_one_ssa_partition): Likewise. (expand_one_var): Likewise. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/cfgexpand.c
[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 #3 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Thu Aug 2 20:36:14 2018 New Revision: 263277 URL: https://gcc.gnu.org/viewcvs?rev=263277&root=gcc&view=rev Log: 2018-08-02 Jozef Lawrynowicz Backport from mainline 2018-07-31 Jozef Lawrynowicz PR middle-end/86705 * gcc/cfgexpand.c (set_parm_rtl): Use the alignment of Pmode when MAX_SUPPORTED_STACK_ALIGNMENT would otherwise be exceeded by the requested variable alignment. (expand_one_ssa_partition): Likewise. (expand_one_var): Likewise. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/cfgexpand.c
[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 #2 from jozefl at gcc dot gnu.org --- Author: jozefl Date: Tue Jul 31 18:17:00 2018 New Revision: 263177 URL: https://gcc.gnu.org/viewcvs?rev=263177&root=gcc&view=rev Log: PR middle-end/86705 * gcc/cfgexpand.c (set_parm_rtl): Use the alignment of Pmode when MAX_SUPPORTED_STACK_ALIGNMENT would otherwise be exceeded by the requested variable alignment. (expand_one_ssa_partition): Likewise. (expand_one_var): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c
