[Bug target/100241] internal compiler error: in curr_insn_transform, at lra-constraints.c:4133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100241 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99787 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2022-01-01 --- Comment #8 from Andrew Pinski --- Let me add the testcase for this one and PR 99787
[Bug target/100241] internal compiler error: in curr_insn_transform, at lra-constraints.c:4133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100241 --- Comment #9 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:5fa4f982636e7e66eee6a9b45cc0939ae95b4659 commit r12-6164-g5fa4f982636e7e66eee6a9b45cc0939ae95b4659 Author: Andrew Pinski Date: Sat Jan 1 08:44:48 2022 + Committed: Add testcases for a few PRs These were fixed as part of the fix for PR 99766, I thought it would be useful to add a few testcases for the other cases that were failing. Committed as obvious after running the tests to make sure they work. PR rtl-optimization/100241 PR rtl-optimization/99787 gcc/testsuite/ChangeLog: * gcc.c-torture/compile/pr100241-1.c: New test. * gcc.c-torture/compile/pr99787-1.c: New test.
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code since r11-7807-gbe70bb5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766 --- Comment #11 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:5fa4f982636e7e66eee6a9b45cc0939ae95b4659 commit r12-6164-g5fa4f982636e7e66eee6a9b45cc0939ae95b4659 Author: Andrew Pinski Date: Sat Jan 1 08:44:48 2022 + Committed: Add testcases for a few PRs These were fixed as part of the fix for PR 99766, I thought it would be useful to add a few testcases for the other cases that were failing. Committed as obvious after running the tests to make sure they work. PR rtl-optimization/100241 PR rtl-optimization/99787 gcc/testsuite/ChangeLog: * gcc.c-torture/compile/pr100241-1.c: New test. * gcc.c-torture/compile/pr99787-1.c: New test.
[Bug target/99787] [11 Regression] ICE in curr_insn_transform, at lra-constraints.c:4133 since r11-7807-gbe70bb5e4babdf9d3d33e8f4658452038407fa8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99787 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:5fa4f982636e7e66eee6a9b45cc0939ae95b4659 commit r12-6164-g5fa4f982636e7e66eee6a9b45cc0939ae95b4659 Author: Andrew Pinski Date: Sat Jan 1 08:44:48 2022 + Committed: Add testcases for a few PRs These were fixed as part of the fix for PR 99766, I thought it would be useful to add a few testcases for the other cases that were failing. Committed as obvious after running the tests to make sure they work. PR rtl-optimization/100241 PR rtl-optimization/99787 gcc/testsuite/ChangeLog: * gcc.c-torture/compile/pr100241-1.c: New test. * gcc.c-torture/compile/pr99787-1.c: New test.
[Bug target/100241] internal compiler error: in curr_insn_transform, at lra-constraints.c:4133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100241 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Andrew Pinski --- testcases added so marking this as a dup of bug 99766. *** This bug has been marked as a duplicate of bug 99766 ***
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code since r11-7807-gbe70bb5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766 Andrew Pinski changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #12 from Andrew Pinski --- *** Bug 100241 has been marked as a duplicate of this bug. ***
[Bug fortran/100183] Segmentation fault at runtime when passing an internal procedure as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183 Andrew Pinski changed: What|Removed |Added Status|WAITING |NEW See Also||https://github.com/iains/gc ||c-darwin-arm64/issues/26
[Bug fortran/100183] Segmentation fault at runtime when passing an internal procedure as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #7 from Andrew Pinski --- Yes this was a the nested functions being passed to another function issue where executable stack was needed for aarch64-darwin, there is no executable stack. Anyways this was tracked as https://github.com/iains/gcc-darwin-arm64/issues/26 and was just fixed so closing as moved as aarch64-darwin is not supported yet in the FSF sources (Ians and FX are planning on merging it upstream sometime this year).
[Bug middle-end/100755] Error with fortran object (v11.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Andrew Pinski --- Dup of bug 100283. *** This bug has been marked as a duplicate of bug 100283 ***
[Bug fortran/100283] [11/12 Regression] Call to MIN0 with integer(8) arguments raises an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100283 Andrew Pinski changed: What|Removed |Added CC||afernandez at odyhpc dot com --- Comment #6 from Andrew Pinski --- *** Bug 100755 has been marked as a duplicate of this bug. ***
[Bug c/84903] internal compiler error: in convert_move, at expr.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84903 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 84687. *** This bug has been marked as a duplicate of bug 84687 ***
[Bug tree-optimization/84687] [8 Regression] error: invalid conversion in gimple call with -O3 and -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84687 Andrew Pinski changed: What|Removed |Added CC||marcin.krotkiewski at gmail dot co ||m --- Comment #7 from Andrew Pinski --- *** Bug 84903 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/90087] Suboptimal codegen for x < 0 ? x - INT_MIN : x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90087 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- Mine.
[Bug fortran/103828] Type generated for CHARACTER(C_CHAR), VALUE arguments is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |12.0 --- Comment #6 from Francois-Xavier Coudert --- Fixed in https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=906b4e15ce84790c7657405238d61358e0893676
[Bug lto/88925] address of static string changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88925 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||lto, wrong-code Last reconfirmed||2022-01-01 --- Comment #3 from Andrew Pinski --- Confirmed. For what I think should happen is there should be a CONST_DECL which contains the string and is able to be pulled in and that is the address which gets put into _ZL12typeDerived2, etc. Note even with -fno-merge-constants on elf targets, strings are still put into the .rodata.str1.1 section so the linker is going to merge them anyways.
[Bug middle-end/67452] [5/6 Regression] LTO ICE with -fopenmp-simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67452 Andrew Pinski changed: What|Removed |Added Known to fail||5.1.0, 5.2.0 Summary|LTO ICE with -fopenmp-simd |[5/6 Regression] LTO ICE ||with -fopenmp-simd Target Milestone|--- |5.3 Known to work||4.9.4, 5.3.0, 6.1.0
[Bug lto/66835] C++ openMP test failed after switching to C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66835 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Andrew Pinski --- Even though this bug is older than PR 67452, PR 67452 has the commit which fixed the bug already referenced so closing this bug as a dup of bug 67452. *** This bug has been marked as a duplicate of bug 67452 ***
[Bug middle-end/67452] [5/6 Regression] LTO ICE with -fopenmp-simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67452 Andrew Pinski changed: What|Removed |Added CC||evstupac at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 66835 has been marked as a duplicate of this bug. ***
[Bug lto/43786] ICE in lto_get_pickled_tree with fshort-double on one of the TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43786 --- Comment #4 from Andrew Pinski --- -fshort-enum or -funsigned-char/-fsigned-char might cause a smilar ICE. -fshort-double was removed in GCC 6 by r6-6819 (aka PR 60410 ).
[Bug lto/49697] read permission of LTO intermediate files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49697 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- lo->fd = open (fname, (writable ? O_WRONLY | O_CREAT | O_BINARY : O_RDONLY | O_BINARY), 0666); Every other file that gets created by GCC is fopen which according to the man page: Any created file will have the mode S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH (0666), as modified by the process's umask value (see umask(2)). I would assume umask modifies open's mode too ... Let me try to dig into this slightly more tomorrow.
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #12 from Andrew Pinski --- Since GCC does work but not with gold, the bug is in gold. I am going to close this as moved. https://sourceware.org/bugzilla/show_bug.cgi?id=24415 records the binutils/gold bug.
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 --- Comment #6 from Jose Silva --- Yes, noipa does help. (In reply to Andrew Pinski from comment #3) > Oh that is because there is some IPA Register allocation going on. Anyways > this is still not a bug. You need to mark a0 as a clobber in the inline-asm > to let GCC know that a0 is touched. As I said I simplified the example, the original code had a syscall which I have no idea which registers will be clobbered. Before upgrading compilers I was using GCC 3.2 which produces the following code with `-nostdlib -Os`: ``` a0020060 : a0020060: 27bdfff0addiu sp,sp,-16 a0020064: ffb0sd s0,0(sp) a0020068: ffbf0008sd ra,8(sp) a002006c: 0c008016jal a0020058 a0020070: 0080802dmoves0,a0 a0020074: 0200202dmovea0,s0 a0020078: dfbf0008ld ra,8(sp) a002007c: dfb0ld s0,0(sp) a0020080: 08008012j a0020048 a0020084: 27bd0010addiu sp,sp,16 ``` I'm quite confused on why you say "Anyways this is still not a bug". IPA RA is making assumptions on procedures where it does not have enough information to do so, i.e functions with asm statements. It is disabled when a function pointer is used, why shouldn't it be for when a function with ASM statement is encountered? The code inside the `fail()` function is valid and does not break the ABI, GCC does not have enough information to perform IPA RA but does so(wrongly), to me that's a bug.
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 --- Comment #7 from Jakub Jelinek --- (In reply to Jose Silva from comment #6) > Yes, noipa does help. > > (In reply to Andrew Pinski from comment #3) > > Oh that is because there is some IPA Register allocation going on. Anyways > > this is still not a bug. You need to mark a0 as a clobber in the inline-asm > > to let GCC know that a0 is touched. > > As I said I simplified the example, the original code had a syscall which I > have no idea which registers will be clobbered. The compiler has no idea either (it has intentionally no idea what the inline asm does, it is a black box to the compiler), so that is why you need to specify it. Look at C library sources, or kernel and find out what is and what isn't clobbered and add the clobbers. > I'm quite confused on why you say "Anyways this is still not a bug". IPA RA > is making assumptions on procedures where it does not have enough > information to do so, i.e functions with asm statements. It is disabled when > a function pointer is used, why shouldn't it be for when a function with ASM > statement is encountered? Inline asms need to tell the compiler what registers they are setting, which they are using and what they are clobbering, otherwise the shouldn't set, use or clobber anything... You can still e.g. save and restore the registers yourself in the inline asm...
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 --- Comment #8 from Jakub Jelinek --- BTW, all this is documented in the gcc documentation (on Basic Asm and Extended Asm).
[Bug modula2/93575] the modula2 frontend fails to build with a profiled bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93575 Gaius Mulley changed: What|Removed |Added CC||gaiusmod2 at gmail dot com --- Comment #1 from Gaius Mulley --- I've git pushed fixes to the devel/modula-2 branch (gcc-12) which now allows gm2 to be built using: MAKEFLAGS=profiledbootstrap-lean CONFIGFLAGS=--with-build-config=bootstrap-lto-lean I'm also seeing all regression tests pass on the amd64 platform and aarch64 platform after the lto build.
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 --- Comment #9 from Jose Silva --- (In reply to Jakub Jelinek from comment #7) > The compiler has no idea either (it has intentionally no idea what the > inline asm does, it is a black box to the compiler), so that is why you need > to specify it. Look at C library sources, or kernel and find out what is > and what isn't clobbered and add the clobbers. It seems weird that GCC puts the sole responsibility on the programmer when dealing with ASM. In my honest opinion, the compiler should be cautious when interacting with hand-written ASM, the same way when interacting with function pointers. It does allow for more optimization opportunities but it implies the programmer knows a lot about the underlying architecture and system. I'd like to implement a feature that automatically sets a function as noipa when containing ASM statements, could you please point me in the codebase where I could start?
[Bug c++/103885] New: ICE in capturing lambda for certain constexpr/auto combination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103885
Bug ID: 103885
Summary: ICE in capturing lambda for certain constexpr/auto
combination
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cbcode at gmail dot com
Target Milestone: ---
ICE on the line indicated below.
void test() {
constexpr int N = 1;
constexpr auto a1 = [](auto){
static_assert(N == 1); //OK
return 2;
}(3);
constexpr auto a2 = [=](auto){
static_assert(N == 1); //OK
return 2;
}(3);
constexpr auto a3 = [&](int){
static_assert(N == 1); //OK
return 2;
}(3);
constexpr auto a4 = [&](auto){
static_assert(N == 1); //ICE in tsubst_copy, at cp/pt.c:16780
return 2;
}(3);
}
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 --- Comment #10 from Jakub Jelinek --- That is just a total misunderstanding why the compiler needs to know (be told) the observable side-effects of the inline asm. Interprocedural optimizations are just one of the many reasons, much more important is that it needs to know what the inline asm does for code generation within the function, it needs to know in which registers or memory it can spill values live across the inline asm etc. Don't use inline asm if you are unable or not willing to tell the compiler how it behaves.
[Bug libstdc++/103879] error: accessing value of variant::_Copy_ctor_base through a 'const variant' glvalue in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103879 --- Comment #4 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > clang rejects it also (with their libc++): Libc++ doesn't support constexpr std::string, and I think it's missing some DRs to std::variant as well. So I wouldn't use it to confirm anything like this.
[Bug c++/103885] [9/10/11 Regression] ICE in capturing lambda for certain constexpr/auto combination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103885 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5
[Bug c++/103885] [9/10/11 Regression] ICE in capturing lambda for certain constexpr/auto combination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103885 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #1 from Andrew Pinski --- Looks to be fixed on the trunk.
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 Jose Silva changed: What|Removed |Added Resolution|INVALID |WONTFIX --- Comment #11 from Jose Silva --- > much more important is that it needs to know what the inline asm does for > code generation within the function, it needs to know in which registers or > memory it can spill values live across the inline asm etc. > if you are unable or not willing to tell the compiler how it behaves Read the title of issue. This problem only manifests with O2/Os/O3, O0 and O1 don't exhibit it because IPA RA doesn't kick in. So no, the compiler doesn't need to be told how it behaves if it takes precautions. The only reason to tell a compiler something is to further optimize something, in any other circumstance it should treat the piece of code as a black-box as you said. What we're arguing here is about sensible compiler defaults. By default a compiler should be cautious about asm statements and protect the surrounding code by respecting the ABI. The programmer should be able to override this behavior, not the other way around like GCC does. There is absolutely no need to tell the compiler something he could've easily accounted for. > Don't use inline asm Wish I didn't need to, but there's no way of doing syscalls without it. On the other hand, since you avoided answering my question regarding modifying GCC I suppose you're not familiar with the codebase. Please refrain from polluting this discussion with unnecessary noise if you don't wish to help.
[Bug libfortran/103886] New: Use 64-bit time_t on 32-bit glibc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886 Bug ID: 103886 Summary: Use 64-bit time_t on 32-bit glibc targets Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- In order to solve the Y2038 problem glibc now supports 64-bit time_t on 32-bit platforms. As this is an ABI change, it has to be explicitly enabled through setting the _TIME_BITS=64 preprocessor macro (similar to _FILE_OFFSET_BITS=64 to enable support for files larger than 2 GB). See https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html and https://sourceware.org/glibc/wiki/Y2038ProofnessDesign I don't think any time_t (or structs containing time_t members) are part of the libgfortran ABI, so this should be an internal change not requiring any ABI bumping. Some other 32-bit targets already have 64-bit time_t; At least NetBSD, OpenBSD and Linux with musl libc 1.2+, https://musl.libc.org/time64.html .
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 Andreas Schwab changed: What|Removed |Added Resolution|WONTFIX |INVALID
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 --- Comment #12 from Jakub Jelinek --- That is solely because you didn't write anything else in the function, try to put some code around the inline asm and you'll see how it will misbehave even with noipa attribute. Your code is invalid as documented in GCC documentation, the behavior is undefined, it can do anything, break with different optimization levels, different compiler versions or revisions, it can appear to work in some cases the way you intended, but it is still broken.
[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886 --- Comment #1 from Andrew Pinski --- Is there anything to be done as the time_t is now defaults to 64bit on the trunk of glibc?
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #14 from Andrew Pinski --- Dup of bug 46820. *** This bug has been marked as a duplicate of bug 46820 ***
[Bug lto/46820] toplevel ASM statements being moved away from the functions in the TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46820 Andrew Pinski changed: What|Removed |Added CC||mliska at suse dot cz --- Comment #14 from Andrew Pinski --- *** Bug 57703 has been marked as a duplicate of this bug. ***
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 Bug 57208 depends on bug 57703, which changed state. Bug 57703 Summary: Assembler function definition moved to a different ltrans then call https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886
--- Comment #2 from Janne Blomqvist ---
(In reply to Andrew Pinski from comment #1)
> Is there anything to be done as the time_t is now defaults to 64bit on the
> trunk of glibc?
AFAIU it's not the default, you need to explicitly opt-in by setting the
_TIME_BITS preprocessor macro to 64 (64-bit time_t is the default on musl, and
{Net,Open}BSD ).
Or are you saying that since the _TIME_BITS thing was introduced (with glibc
2.34), the upcoming 2.35/trunk has changed the default?
[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886
--- Comment #3 from Andrew Pinski ---
(In reply to Janne Blomqvist from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Is there anything to be done as the time_t is now defaults to 64bit on the
> > trunk of glibc?
>
> AFAIU it's not the default, you need to explicitly opt-in by setting the
> _TIME_BITS preprocessor macro to 64 (64-bit time_t is the default on musl,
> and {Net,Open}BSD ).
>
> Or are you saying that since the _TIME_BITS thing was introduced (with glibc
> 2.34), the upcoming 2.35/trunk has changed the default?
Yes, the upcoming 2.35 has changed the default:
https://sourceware.org/pipermail/libc-alpha/2021-December/134576.html
Sorry I was not clear about that.
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 --- Comment #5 from sandra at gcc dot gnu.org --- Created attachment 52107 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52107&action=edit -fdump-tree-original output from second test case Well, this is nuts. Unmodified code is generating 3 copies of the loop to compute "a + b" in the previous example, as well as the invalid copy-out code. I've got a patch to fix this now, just doing a few more experiments with it.
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 Jose Silva changed: What|Removed |Added Resolution|INVALID |WONTFIX --- Comment #13 from Jose Silva --- At this point I believe you're purposely misinterpreting the problem at hand and justifying it with a bad implementation by waving the terrible GCC documentation. I didn't write anything around the ASM statement because I'm doing a syscall. Even if I wasn't doing a syscall the code posted on the original post is valid according to the ABI. The default behavior for a function composed of a single ASM statement should be the same as if it was compiled separately with the assembler. When writing the assembly code you don't need to tell the assembler/compiler which registers were clobbered because there's an ABI - you follow it? good. else enjoy UB. Clobber information should be *only* for optimization purposes, else the compiler should just stick to the ABI. I'm talking about ~sensible defaults~, IPA shouldn't assume the best case scenario(no clobber) when no information is provided to it, but the worst(spill every caller-saved register in use). You've avoided answering my question twice and the only contribution to the thread has been spamming me with insane amounts of copium regarding the terrible GCC's IPA RA - bad defaults are not a feature. Unless you'd like to help my modifications of GCC with something like giving me the contact of someone that actually knows what they're talking about and has experience with the codebase, refrain from posting.
[Bug lto/50483] lto turns visibility from HIDDEN to DEFAULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50483 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- So what is happening is bar is being coming localized to the newly produced assembly file which is the same as being hidden really. If we do: void bar() __attribute((visibility( "hidden" ), externally_visible)); The new assembly file in both cases produces: .globl _Z3barv .hidden _Z3barv Without the externally_visible, the function does not have a .globl to it. This is also why in both with and without -flto dynsym does not have the symbol there. There is no bug to be fixed, LTO is doing the localizing rather than the linker doing it.
[Bug middle-end/102380] [meta-bug] visibility (fvisibility=* and attributes) issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102380 Bug 102380 depends on bug 50483, which changed state. Bug 50483 Summary: lto turns visibility from HIDDEN to DEFAULT https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50483 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug lto/50483] lto turns visibility from HIDDEN to DEFAULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50483 --- Comment #4 from Andrew Pinski --- Note I looked at both with and without the LTO plugin too to make sure it would work in both cases.
[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886
--- Comment #4 from Janne Blomqvist ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Janne Blomqvist from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Is there anything to be done as the time_t is now defaults to 64bit on the
> > > trunk of glibc?
> >
> > AFAIU it's not the default, you need to explicitly opt-in by setting the
> > _TIME_BITS preprocessor macro to 64 (64-bit time_t is the default on musl,
> > and {Net,Open}BSD ).
> >
> > Or are you saying that since the _TIME_BITS thing was introduced (with glibc
> > 2.34), the upcoming 2.35/trunk has changed the default?
>
> Yes, the upcoming 2.35 has changed the default:
> https://sourceware.org/pipermail/libc-alpha/2021-December/134576.html
I'm not super-familiar with glibc, but it seems that this changes the default
(in ./bits/timesize.h) to 64 for targets not overriding it, however it
adds/modifies a number of target-specific overrides to retain the previous
behavior? In particular for x86 there is
./sysdeps/unix/sysv/linux/x86/bits/timesize.h which says:
#if defined __x86_64__ && defined __ILP32__
/* For x32, time is 64-bit even though word size is 32-bit. */
# define __TIMESIZE 64
#else
/* For others, time size is word size. */
# define __TIMESIZE __WORDSIZE
#endif
If my reading of the above is correct, on 32-bit x86 __TIMESIZE is set to
__WORDSIZE, that is, 32.
Similarly for ./sysdeps/unix/sysv/linux/arm/bits/timesize.h it says
#define __TIMESIZE 32
[Bug c/103887] New: -fsanitize=shift affects constness of an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103887
Bug ID: 103887
Summary: -fsanitize=shift affects constness of an expression
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: m...@mk-sys.cz
Target Milestone: ---
This simplified testcase
---
#include
#define ASSERT_ON_COMPILE_SELECTOR_SIZE(e)\
_Static_assert(((__builtin_constant_p(e) && ((e) >> 16) == 0)) || \
(sizeof(e) <= 2), "problem")
int f(uint16_t tr)
{
ASSERT_ON_COMPILE_SELECTOR_SIZE(tr);
return 0;
}
---
builds cleanly with "-O2" but fails with "-O2 -fsanitize=shift":
---
mike@lion:/tmp/gcc> gcc-11 -Wall -Wextra -O2 -c foo.c
mike@lion:/tmp/gcc> gcc-11 -Wall -Wextra -O2 -fsanitize=shift -c foo.c
foo.c: In function ‘f’:
foo.c:4:72: error: expression in static assertion is not constant
4 | _Static_assert(((__builtin_constant_p(e) && ((e) >> 16) == 0))
|| \
|
^~~~
5 |(sizeof(e) <= 2), "problem")
|
foo.c:9:9: note: in expansion of macro ‘ASSERT_ON_COMPILE_SELECTOR_SIZE’
9 | ASSERT_ON_COMPILE_SELECTOR_SIZE(tr);
| ^~~
---
I was able to reproduce the same with various gcc version from gcc7 to gcc12.
[Bug target/99783] relocation truncated to fit: R_OR1K_GOT16 on OpenRISC, building libgeos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99783 Stafford Horne changed: What|Removed |Added Resolution|--- |MOVED Status|ASSIGNED|RESOLVED --- Comment #10 from Stafford Horne --- Closing this as its a binutils issue. I have opened: https://sourceware.org/bugzilla/show_bug.cgi?id=28735
[Bug c/103887] -fsanitize=shift affects constness of an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103887
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
The problem is rather __builtin_constant_p not resolving to a constant. This is
a dup of bug 79482.
As shown by:
#include
uint16_t f1(void);
#define ASSERT_ON_COMPILE_SELECTOR_SIZE(e)\
_Static_assert(__builtin_constant_p(e) ? ((f1()) >> 16) == 0 : \
(sizeof(f1()) <= 2), "problem")
int f(uint16_t tr)
{
ASSERT_ON_COMPILE_SELECTOR_SIZE(tr);
return 0;
}
*** This bug has been marked as a duplicate of bug 79482 ***
[Bug c/79482] _Static_assert(__builtin_constant_p(x)):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79482 Andrew Pinski changed: What|Removed |Added CC||m...@mk-sys.cz --- Comment #7 from Andrew Pinski --- *** Bug 103887 has been marked as a duplicate of this bug. ***
[Bug c/103887] -fsanitize=shift affects constness of an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103887 --- Comment #2 from Michal Kubecek --- (In reply to Andrew Pinski from comment #1) > The problem is rather __builtin_constant_p not resolving to a constant. This > is a dup of bug 79482. There is a difference: your modified testcase fails to compile regardless of -fsanitize=shift while mine fails only with this option and succeeds without it. If __builtin_constant_p(tr) not being handled as constant were the problem, the result should not depend on presence of "-fsanitize=shift".
[Bug c/103887] -fsanitize=shift affects constness of an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103887
--- Comment #3 from Andrew Pinski ---
(In reply to Michal Kubecek from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > The problem is rather __builtin_constant_p not resolving to a constant. This
> > is a dup of bug 79482.
>
> There is a difference: your modified testcase fails to compile regardless of
> -fsanitize=shift while mine fails only with this option and succeeds without
> it. If __builtin_constant_p(tr) not being handled as constant were the
> problem,
> the result should not depend on presence of "-fsanitize=shift".
Right, but the problem is __builtin_constant_p is not resolved to 0 forcing
what is inside the static_assert to be non-constant in both cases.
Even take a look at this:
#include
#define ASSERT_ON_COMPILE_SELECTOR_SIZE(e)\
_Static_assert(((__builtin_constant_p(e) && ((e) >> 16) == 0)) || \
(sizeof(e) <= 2), "problem")
int f(uint32_t tr)
{
ASSERT_ON_COMPILE_SELECTOR_SIZE(tr);
return 0;
}
The static assert fails but fails because the expression is non-constant at -O2
and above. This is similar to your original case except without using
-fsanitize=shift even.
[Bug c/103887] -fsanitize=shift affects constness of an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103887 --- Comment #4 from Michal Kubecek --- It's probably even more complicated as #define ASSERT_ON_COMPILE_SELECTOR_SIZE(expr) \ _Static_assert( \ __builtin_choose_expr(__builtin_constant_p(expr), \ ((expr) >> 16) == 0, \ sizeof(expr) <= 2), \ "problem") works as expected (tested with "uint16_t tr", "uint32_t tr", 6 and 7) even if the documentation says first argument of __builtin_choose_expr() has to be a constant expression. As this is nicer than the original code, I guess I'll use it and hope it is not just a happy coincidence that it works.
[Bug c/103887] -fsanitize=shift affects constness of an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103887 --- Comment #5 from Andrew Pinski --- (In reply to Michal Kubecek from comment #4) > As this is nicer than the original code, I guess I'll use it and hope it is > not just a happy coincidence that it works. It is not, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19449#c6 (since GCC 4.9.0) for the commit which fixed the issue with __builtin_choose_expr and __builtin_constant_p. Basically __builtin_constant_p(x) is forced to false if x was not a constant expression. _Static_assert folding should be handled the same way and that is what PR 79482 is about really.
[Bug lto/56532] valgrind errors with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56532 --- Comment #2 from Andrew Pinski --- The only messages from valgrind I get these days are from IRA and LRA: ==15092== Command: ./cc1plus pr46984.C -O -fipa-cp -fno-early-inlining -flto -quiet --param=ggc-min-expand=0 --param=ggc-min-heapsize=0 -ffat-lto-objects ==15092== ==15092== Conditional jump or move depends on uninitialised value(s) ==15092==at 0x1526474: sparseset_bit_p(sparseset_def*, unsigned int) (sparseset.h:146) ==15092==by 0x1526F2A: mark_pseudo_regno_live(int) (ira-lives.c:326) ==15092==by 0x15271D4: mark_pseudo_reg_live(rtx_def*, unsigned int) (ira-lives.c:410) ==15092==by 0x1527242: mark_ref_live(df_ref_d*) (ira-lives.c:424) ==15092==by 0x1529ED2: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1434) ==15092==by 0x14FC954: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1806) ==15092==by 0x152AD38: ira_create_allocno_live_ranges() (ira-lives.c:1734) ==15092==by 0x15012FE: ira_build() (ira-build.c:3433) ==15092==by 0x14F6809: ira(_IO_FILE*) (ira.c:5752) ==15092==by 0x14F71AC: (anonymous namespace)::pass_ira::execute(function*) (ira.c:6075) ==15092==by 0x168E8E5: execute_one_pass(opt_pass*) (passes.c:2637) ==15092==by 0x168EC76: execute_pass_list_1(opt_pass*) (passes.c:2737) ==15092== Uninitialised value was created by a heap allocation ==15092==at 0x52B1B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==15092==by 0x30557BC: xmalloc (xmalloc.c:149) ==15092==by 0x17C76C7: sparseset_alloc(unsigned int) (sparseset.c:33) ==15092==by 0x152ACAC: ira_create_allocno_live_ranges() (ira-lives.c:1727) ==15092==by 0x15012FE: ira_build() (ira-build.c:3433) ==15092==by 0x14F6809: ira(_IO_FILE*) (ira.c:5752) ==15092==by 0x14F71AC: (anonymous namespace)::pass_ira::execute(function*) (ira.c:6075) ==15092==by 0x168E8E5: execute_one_pass(opt_pass*) (passes.c:2637) ==15092==by 0x168EC76: execute_pass_list_1(opt_pass*) (passes.c:2737) ==15092==by 0x168ECA7: execute_pass_list_1(opt_pass*) (passes.c:2738) ==15092==by 0x168ECFF: execute_pass_list(function*, opt_pass*) (passes.c:2748) ==15092==by 0x110B4A2: cgraph_node::expand() (cgraphunit.c:1834)
[Bug c++/103888] New: ICE with global register definition after use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103888 Bug ID: 103888 Summary: ICE with global register definition after use Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: accepts-invalid, ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- The following should be rejected but currently is not: extern long unsigned int sub_0 ( const char * ) ; extern void * sub_1 ( long unsigned int ) ; extern int var_0 ; void * var_1 = & var_0 ; register int var_0 asm ( "%ecx" ) ; CUT This is similar to PR 93160 for the C++ front-end since the front-ends don't share merge_decl sources I thought it would be best if we had two bug reports.
[Bug middle-end/29209] ICE optimizing passing long double to abstract method while in other abstract's impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29209 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=40505 --- Comment #13 from Andrew Pinski --- (In reply to Martin Michlmayr from comment #9) > paer% gcc-4.2 -c -O2 basematrix.cc > basematrix.cc: In member function ‘void S_BaseMatrix > >::_ZTv0_n12_N12S_BaseMatrixI7complexIdEE12MultTransAddES1_(Complex)’: > basematrix.cc:33: internal compiler error: in expand_expr_addr_expr_1, at > expr.c:6554 > Please submit a full bug report, > with preprocessed source if appropriate. This one is reported as PR 40505 now.
[Bug c++/103783] Ambiguous overload between constrained static member and unconstrained non-static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103783 Fedor Chelnokov changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #2 from Fedor Chelnokov --- I think this code is invalid per https://timsong-cpp.github.io/cppwp/n4861/class.static.mfct#2: > There shall not be a static and a non-static member function with the same > name and the same parameter types ([over.load]). So GCC just prints confusing diagnostics here, while it shall reject the definition of `struct` with static and not-static `f`.
[Bug fortran/101762] ICE with "Every subscript of the target specification must be a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101762 Andrew Pinski changed: What|Removed |Added Summary|ICE in ix86_push_argument, |ICE with "Every subscript |at config/i386/i386.c:4203 |of the target specification ||must be a constant ||expression" Last reconfirmed||2022-01-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Note ifort rejects it with: /app/example.f90(4): error #8817: Every subscript of the target specification must be a constant expression. [A] integer, pointer :: x => a(n()) ^ compilation aborted for /app/example.f90 (code 1) ASM generation compiler returned: 1 Confirmed.
[Bug c/33193] slopiness in __real/__imag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|REOPENED|ASSIGNED Keywords||documentation --- Comment #7 from Andrew Pinski --- (In reply to Chris Lattner from comment #6) > http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex still does not > document what arguments are accepted to __real and __imag. I think the documentation is clear here though: "a complex-valued expression exp". This means the type that is accepted is "_Complex type", which can be prompted from type. Maybe we should add that scalar types can be prompted to _Complex types just to make it fully clear what is allowed. Let me take a stab at that.
