[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Iain Sandoe --- fixed on open branches (needed on earlier if maintained).
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #19 from GCC Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:a1b0ace9737a40957bfb298de22066d8ee9a6603 commit r11-11385-ga1b0ace9737a40957bfb298de22066d8ee9a6603 Author: Iain Sandoe Date: Sat Jan 6 10:52:38 2024 + Darwin: Fix constant CFString code-gen [PR105522]. Although this only fires for one of the Darwin sub-ports, it is latent elsewhere, it is also a regression c.f. the Darwin system compiler. In the code we imported from an earlier branch, CFString objects (which are constant aggregates) are constructed as CONST_DECLs. Although our current documentation suggests that these are reserved for enumeration values, in fact they are used elsewhere in the compiler for constants. This includes Objective-C where they are used to form NSString constants. In the particular case, we take the address of the constant and that triggers varasm.cc:decode_addr_constant, which does not currently support CONST_DECL. If there is a general intent to allow/encourage wider use of CONST_DECL, then we should fix decode_addr_constant to look through these and evaluate the initializer (a two-line patch, but I'm not suggesting it for stage-4). We also need to update the GCC internals documentation to allow for the additional uses. This patch is Darwin-local and fixes the problem by making the CFString constants into regular variable but TREE_CONSTANT+TREE_READONLY. I plan to back-port this to the open branches once it has baked a while on trunk. Since, for Darwin, the Objective-C default is to construct constant NSString objects as CFStrings; this will also cover the majority of cases there (this patch does not make any changes to Objective-C NSStrings). PR target/105522 gcc/ChangeLog: * config/darwin.c (machopic_select_section): Handle C and C++ CFStrings. (darwin_rename_builtins): Move this out of the CFString code. (darwin_libc_has_function): Likewise. (darwin_build_constant_cfstring): Create an anonymous var to hold each CFString. * config/darwin.h (ASM_OUTPUT_LABELREF): Handle constant CFstrings. Signed-off-by: Iain Sandoe (cherry picked from commit aecc0d4ba73d0810334b351da1e67232cea450d3)
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #18 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:b9ee0c8830592212678c402aed8a6b11ef8d2640 commit r12-10348-gb9ee0c8830592212678c402aed8a6b11ef8d2640 Author: Iain Sandoe Date: Sat Jan 6 10:52:38 2024 + Darwin: Fix constant CFString code-gen [PR105522]. Although this only fires for one of the Darwin sub-ports, it is latent elsewhere, it is also a regression c.f. the Darwin system compiler. In the code we imported from an earlier branch, CFString objects (which are constant aggregates) are constructed as CONST_DECLs. Although our current documentation suggests that these are reserved for enumeration values, in fact they are used elsewhere in the compiler for constants. This includes Objective-C where they are used to form NSString constants. In the particular case, we take the address of the constant and that triggers varasm.cc:decode_addr_constant, which does not currently support CONST_DECL. If there is a general intent to allow/encourage wider use of CONST_DECL, then we should fix decode_addr_constant to look through these and evaluate the initializer (a two-line patch, but I'm not suggesting it for stage-4). We also need to update the GCC internals documentation to allow for the additional uses. This patch is Darwin-local and fixes the problem by making the CFString constants into regular variable but TREE_CONSTANT+TREE_READONLY. I plan to back-port this to the open branches once it has baked a while on trunk. Since, for Darwin, the Objective-C default is to construct constant NSString objects as CFStrings; this will also cover the majority of cases there (this patch does not make any changes to Objective-C NSStrings). PR target/105522 gcc/ChangeLog: * config/darwin.cc (machopic_select_section): Handle C and C++ CFStrings. (darwin_rename_builtins): Move this out of the CFString code. (darwin_libc_has_function): Likewise. (darwin_build_constant_cfstring): Create an anonymous var to hold each CFString. * config/darwin.h (ASM_OUTPUT_LABELREF): Handle constant CFstrings. Signed-off-by: Iain Sandoe (cherry picked from commit aecc0d4ba73d0810334b351da1e67232cea450d3)
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #17 from GCC Commits --- The releases/gcc-13 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:bd760ac35d792683cd82f6b665516528fe11752a commit r13-8537-gbd760ac35d792683cd82f6b665516528fe11752a Author: Iain Sandoe Date: Sat Jan 6 10:52:38 2024 + Darwin: Fix constant CFString code-gen [PR105522]. Although this only fires for one of the Darwin sub-ports, it is latent elsewhere, it is also a regression c.f. the Darwin system compiler. In the code we imported from an earlier branch, CFString objects (which are constant aggregates) are constructed as CONST_DECLs. Although our current documentation suggests that these are reserved for enumeration values, in fact they are used elsewhere in the compiler for constants. This includes Objective-C where they are used to form NSString constants. In the particular case, we take the address of the constant and that triggers varasm.cc:decode_addr_constant, which does not currently support CONST_DECL. If there is a general intent to allow/encourage wider use of CONST_DECL, then we should fix decode_addr_constant to look through these and evaluate the initializer (a two-line patch, but I'm not suggesting it for stage-4). We also need to update the GCC internals documentation to allow for the additional uses. This patch is Darwin-local and fixes the problem by making the CFString constants into regular variable but TREE_CONSTANT+TREE_READONLY. I plan to back-port this to the open branches once it has baked a while on trunk. Since, for Darwin, the Objective-C default is to construct constant NSString objects as CFStrings; this will also cover the majority of cases there (this patch does not make any changes to Objective-C NSStrings). PR target/105522 gcc/ChangeLog: * config/darwin.cc (machopic_select_section): Handle C and C++ CFStrings. (darwin_rename_builtins): Move this out of the CFString code. (darwin_libc_has_function): Likewise. (darwin_build_constant_cfstring): Create an anonymous var to hold each CFString. * config/darwin.h (ASM_OUTPUT_LABELREF): Handle constant CFstrings. Signed-off-by: Iain Sandoe (cherry picked from commit aecc0d4ba73d0810334b351da1e67232cea450d3)
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #16 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #15) > (In reply to Peter Bergner from comment #12) > > (In reply to Sergey Fedorov from comment #11) > > > (In reply to GCC Commits from comment #10) > > > > The master branch has been updated by Iain D Sandoe : > > > > > > Iain, thank you very much for addressing this! > > > > If this is fixed for you, can you please move this to RESOLVED / FIXED? > > I will need to rebuild gcc13 and try it out, allow me some time please. it is only fixed on trunk so far - I am currently working on back ports to earlier branches and this will be one of them - so please leave open for now.
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #15 from Sergey Fedorov --- (In reply to Peter Bergner from comment #12) > (In reply to Sergey Fedorov from comment #11) > > (In reply to GCC Commits from comment #10) > > > The master branch has been updated by Iain D Sandoe : > > > > Iain, thank you very much for addressing this! > > If this is fixed for you, can you please move this to RESOLVED / FIXED? I will need to rebuild gcc13 and try it out, allow me some time please.
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #14 from Sergey Fedorov --- (In reply to Iain Sandoe from comment #13) > fixed on trunk, intending to backport it. Great! Once it is on your branches, hopefully Macports borrows the patch as well.
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #13 from Iain Sandoe --- fixed on trunk, intending to backport it.
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #12 from Peter Bergner --- (In reply to Sergey Fedorov from comment #11) > (In reply to GCC Commits from comment #10) > > The master branch has been updated by Iain D Sandoe : > > Iain, thank you very much for addressing this! If this is fixed for you, can you please move this to RESOLVED / FIXED?
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #11 from Sergey Fedorov --- (In reply to GCC Commits from comment #10) > The master branch has been updated by Iain D Sandoe : Iain, thank you very much for addressing this!
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #10 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:aecc0d4ba73d0810334b351da1e67232cea450d3 commit r14-8232-gaecc0d4ba73d0810334b351da1e67232cea450d3 Author: Iain Sandoe Date: Sat Jan 6 10:52:38 2024 + Darwin: Fix constant CFString code-gen [PR105522]. Although this only fires for one of the Darwin sub-ports, it is latent elsewhere, it is also a regression c.f. the Darwin system compiler. In the code we imported from an earlier branch, CFString objects (which are constant aggregates) are constructed as CONST_DECLs. Although our current documentation suggests that these are reserved for enumeration values, in fact they are used elsewhere in the compiler for constants. This includes Objective-C where they are used to form NSString constants. In the particular case, we take the address of the constant and that triggers varasm.cc:decode_addr_constant, which does not currently support CONST_DECL. If there is a general intent to allow/encourage wider use of CONST_DECL, then we should fix decode_addr_constant to look through these and evaluate the initializer (a two-line patch, but I'm not suggesting it for stage-4). We also need to update the GCC internals documentation to allow for the additional uses. This patch is Darwin-local and fixes the problem by making the CFString constants into regular variable but TREE_CONSTANT+TREE_READONLY. I plan to back-port this to the open branches once it has baked a while on trunk. Since, for Darwin, the Objective-C default is to construct constant NSString objects as CFStrings; this will also cover the majority of cases there (this patch does not make any changes to Objective-C NSStrings). PR target/105522 gcc/ChangeLog: * config/darwin.cc (machopic_select_section): Handle C and C++ CFStrings. (darwin_rename_builtins): Move this out of the CFString code. (darwin_libc_has_function): Likewise. (darwin_build_constant_cfstring): Create an anonymous var to hold each CFString. * config/darwin.h (ASM_OUTPUT_LABELREF): Handle constant CFstrings. Signed-off-by: Iain Sandoe
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
--- Comment #9 from Sergey Fedorov ---
Just to update, GCC 12.3.0 exhibits the same error:
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2-snowleopard/libsdl2-snowleopard/work/SDL2-2.0.22/src/hidapi/mac/hid.c:
In function 'create_usage_match':
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2-snowleopard/libsdl2-snowleopard/work/SDL2-2.0.22/src/hidapi/mac/hid.c:407:21:
internal compiler error: in decode_addr_const, at varasm.cc:3083
407 | const void *keys[2] = { (void *)
CFSTR(kIOHIDDeviceUsagePageKey), (void *) CFSTR(kIOHIDDeviceUsageKey) };
| ^~~~
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See for instructions.
make: *** [build/SDL_hidapi.lo] Error 1
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #8 from Sergey Fedorov --- (In reply to Iain Sandoe from comment #6) > it seems to fail "forever" (at least back to 5.5) Any chance of fixing this before the next update of GCC?
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
--- Comment #7 from Sergey Fedorov ---
(In reply to Iain Sandoe from comment #6)
> it seems to fail "forever" (at least back to 5.5)
>
> minimal reproducer:
>
> typedef const struct __CFString * CFStringRef;
>
> static void
> create_usage_match(const unsigned int page, const unsigned int usage, int
> *okay)
> {
>
> const void *keys[2] =
>{ (void *) ((CFStringRef) __builtin___CFStringMakeConstantString (""
> "DeviceUsagePage" ""))
>, (void *) ((CFStringRef) __builtin___CFStringMakeConstantString (""
> "DeviceUsage" ""))
>};
>
> }
Oh wow. Surprising that it never got caught until gcc11.
P. S. Thank you very much for dealing with this!
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
--- Comment #6 from Iain Sandoe ---
it seems to fail "forever" (at least back to 5.5)
minimal reproducer:
typedef const struct __CFString * CFStringRef;
static void
create_usage_match(const unsigned int page, const unsigned int usage, int
*okay)
{
const void *keys[2] =
{ (void *) ((CFStringRef) __builtin___CFStringMakeConstantString (""
"DeviceUsagePage" ""))
, (void *) ((CFStringRef) __builtin___CFStringMakeConstantString (""
"DeviceUsage" ""))
};
}
