[Bug target/112092] RISC-V: Suboptimal RVV code produced for vsetvl-11.c and vsetvlmax-8.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092 --- Comment #18 from Maciej W. Rozycki --- Any fix will have to be based on valid code though and the lone presence of inline asm is not supposed to prevent optimisations from being used, e.g. I may have to insert a memory barrier into my code f

[Bug target/117759] Alpha: Data races with 8-bit/16-bit stores

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117759 Maciej W. Rozycki changed: What|Removed |Added Summary|Alpha: `_Atomic' keyword|Alpha: Data races with

[Bug target/112092] RISC-V: Suboptimal RVV code produced for vsetvl-11.c and vsetvlmax-8.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092 --- Comment #16 from Maciej W. Rozycki --- As I say GCC doesn't know the inline asm makes use of the vector unit, so the compiler is free to make any optimisations that it can see fit based on vector code it has produced itself. Actually in thi

[Bug target/112092] RISC-V: Suboptimal RVV code produced for vsetvl-11.c and vsetvlmax-8.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092 --- Comment #14 from Maciej W. Rozycki --- This is invalid code, because you haven't told GCC your inline assembly makes use of v8 or v24. You need to specify inputs and outputs correctly or otherwise the compiler will consider these registers

[Bug target/117759] Alpha: `_Atomic' keyword not respected for !BWX and 8-bit/16-bit stores

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117759 --- Comment #1 from Maciej W. Rozycki --- I need to withdraw the fix for this PR, it is a red herring that has misled me. While there is a data race here it is not within access to the atomic data object, it comes from the *outside*. Consider

[Bug target/117759] Alpha: `_Atomic' keyword not respected for !BWX and 8-bit/16-bit stores

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117759 Maciej W. Rozycki changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug target/117759] New: Alpha: `_Atomic' keyword not respected for !BWX and 8-bit/16-bit stores

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117759 Bug ID: 117759 Summary: Alpha: `_Atomic' keyword not respected for !BWX and 8-bit/16-bit stores Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: major

[Bug target/115526] [14/15 regression] invalid assember emitted for alpha, "Error: duplicate !tlsgd!62" since r14-5109-ga291237b628f41

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526 --- Comment #20 from Maciej W. Rozycki --- Created attachment 58687 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58687&action=edit Test case modified to use scan-assembler-times instead (In reply to Uroš Bizjak from comment #17) > (In r

[Bug target/115526] [14/15 regression] invalid assember emitted for alpha, "Error: duplicate !tlsgd!62" since r14-5109-ga291237b628f41

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526 --- Comment #15 from Maciej W. Rozycki --- (In reply to Uroš Bizjak from comment #13) > CC Maciej if he can test the patch on his Alpha system. It takes about a day to complete and I had to rerun the libstdc++3 subdirectory due to an intermitte

[Bug rtl-optimization/115565] [11/12/13/14/15 Regression] CSE: Comparison incorrectly evaluated as constant causing optimization to produce wrong code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115565 Maciej W. Rozycki changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |macro at orcam dot me.uk

[Bug rtl-optimization/115565] [4.0/4.1/4.2/4.3/4.4/4.5/4.6/4.7/4.8/4.9/5/6/7/8/9/10/11/12/13/14/15 Regression] CSE: Comparison incorrectly evaluated as constant causing optimization to produce wrong c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115565 --- Comment #2 from Maciej W. Rozycki --- Created attachment 58475 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58475&action=edit Reduced reproducer and incorrect code + RTL dumps produced with commit 08a692679fb8

[Bug rtl-optimization/115565] [4.0/4.1/4.2/4.3/4.4/4.5/4.6/4.7/4.8/4.9/5/6/7/8/9/10/11/12/13/14/15 Regression] CSE: Comparison incorrectly evaluated as constant causing optimization to produce wrong c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115565 --- Comment #1 from Maciej W. Rozycki --- Created attachment 58474 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58474&action=edit Reduced reproducer and correct code + RTL dumps produced with commit 4cd26879f758

[Bug rtl-optimization/115565] New: [4.0/4.1/4.2/4.3/4.4/4.5/4.6/4.7/4.8/4.9/5/6/7/8/9/10/11/12/13/14/15 Regression] CSE: Comparison incorrectly evaluated as constant causing optimization to produce wr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115565 Bug ID: 115565 Summary: [4.0/4.1/4.2/4.3/4.4/4.5/4.6/4.7/4.8/4.9/5/6/7/8/9/10/ 11/12/13/14/15 Regression] CSE: Comparison incorrectly evaluated as constant causing optimization to pro

[Bug middle-end/115459] [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115459 --- Comment #4 from Maciej W. Rozycki --- (In reply to Andrew Pinski from comment #3) > Alpha really should move to LRA too. I can certainly have a look once I'm done with the VAX target unless someone beats me to it. Or maybe even before, as

[Bug middle-end/115459] New: [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115459 Bug ID: 115459 Summary: [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5 Product: gcc

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 79646, which changed state. Bug 79646 Summary: Typos in vax.opt https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646 What|Removed |Added ---

[Bug target/79646] Typos in vax.opt

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646 Maciej W. Rozycki changed: What|Removed |Added CC||macro at orcam dot me.uk

[Bug target/114083] Possible word play on conditional/unconditional

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083 --- Comment #7 from Maciej W. Rozycki --- (In reply to Roland Illig from comment #6) > There's a problem with the wording though. On a platform that doesn't > support conditional-move operations, it's not possible to _use_ > conditional-move ope

[Bug target/114083] Possible word play on conditional/unconditional

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083 --- Comment #4 from Maciej W. Rozycki --- The flag enables the use of the conditional-move operations even with hardware that has no support for such operations, hence unconditionally. Such operations, where unavailable, are then synthesized as

[Bug target/113949] Switch vax to LRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113949 Maciej W. Rozycki changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |macro at orcam dot me.uk

[Bug c++/113454] [14 regression] "assignment of read-only member" error with 483.xalancbmk from SPEC CPU 2006

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113454 --- Comment #2 from Maciej W. Rozycki --- (In reply to Sam James from comment #1) > Didn't help this time ;) Well, now it mentions 483.xalancbmk, which the other bug does not (and which I searched for specifically, finding only a bunch of old r

[Bug c++/113454] New: [14 regression] "assignment of read-only member" error with 483.xalancbmk from SPEC CPU 2006

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113454 Bug ID: 113454 Summary: [14 regression] "assignment of read-only member" error with 483.xalancbmk from SPEC CPU 2006 Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815 Maciej W. Rozycki changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug modula2/111956] Many powerpc platforms do _not_ have support for IEEE754 long double

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 --- Comment #9 from Maciej W. Rozycki --- Hmm, the host check for `__frexpieee128' in gcc/ will surely not do what's intended: even if the host is `powerpc*-*-linux*', the target will often be something else and vice versa (libgm2's host is GCC'

[Bug modula2/111956] Many powerpc platforms do _not_ have support for IEEE754 long double

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956 --- Comment #5 from Maciej W. Rozycki --- Hmm, this seems awkward to me. It won't work AFAICT with the usual native bootstrap environment, where you just run: $ /path/to/configure && make bootstrap and it won't work where you have an old vers

[Bug target/112092] RISC-V: Suboptimal RVV code produced for vsetvl-11.c and vsetvlmax-8.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092 Maciej W. Rozycki changed: What|Removed |Added Keywords|wrong-code |missed-optimization Sever

[Bug target/112295] New: RISC-V: Short forward branch pessimisation for ALU operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112295 Bug ID: 112295 Summary: RISC-V: Short forward branch pessimisation for ALU operations Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimizat

[Bug target/112092] RISC-V: Wrong RVV code produced for vsetvl-11.c and vsetvlmax-8.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092 --- Comment #7 from Maciej W. Rozycki --- Thank you for all your explanations. I think I'm still missing something here, so I'll write it differently (and let's ignore the tail-agnostic vs tail-undisturbed choice for the purpose of this conside

[Bug target/112092] RISC-V: Wrong RVV code produced for vsetvl-11.c and vsetvlmax-8.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092 --- Comment #3 from Maciej W. Rozycki --- Maybe I'm missing something, but the RVV spec has this for VSETVLI: "The application specifies the total number of elements to be processed (the application vector length or AVL) as a candidate value fo

[Bug target/112092] New: RISC-V: Wrong RVV code produced for vsetvl-11.c and vsetvlmax-8.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092 Bug ID: 112092 Summary: RISC-V: Wrong RVV code produced for vsetvl-11.c and vsetvlmax-8.c Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code

[Bug modula2/112091] New: rs6000: redefinition of 'constexpr long double std::abs(long double)', while building libgm2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112091 Bug ID: 112091 Summary: rs6000: redefinition of 'constexpr long double std::abs(long double)', while building libgm2 Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815 --- Comment #1 from Maciej W. Rozycki --- Created attachment 56120 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56120&action=edit Reduced testcase This triggers the same ICE in `p'. Preincrements are required so that their results land

[Bug target/85152] VAX ICE with -O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85152 Maciej W. Rozycki changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug target/111815] VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815 Maciej W. Rozycki changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|---

[Bug target/111815] New: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815 Bug ID: 111815 Summary: VAX: ICE in 'print_operand_address' while building 'elf_zstd_decompress' from libbacktrace/elf.c Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug modula2/111530] New: Unable to build GM2 standard library on BSD due to a `getopt_long_only' GNU extension dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111530 Bug ID: 111530 Summary: Unable to build GM2 standard library on BSD due to a `getopt_long_only' GNU extension dependency Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug target/110632] New: RISC-V: SLP optimisation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110632 Bug ID: 110632 Summary: RISC-V: SLP optimisation Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target A

[Bug tree-optimization/110630] New: Missed optimization: bb-slp-pr95839.c not vectorised with V2SF targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110630 Bug ID: 110630 Summary: Missed optimization: bb-slp-pr95839.c not vectorised with V2SF targets Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: enhance

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 --- Comment #18 from Maciej W. Rozycki --- Well, according to the assertion triggered `typeof (EM_MAX_SLOTS)' will yield a data type of a different width depending on the compiler version. Even if this GNU extension does not constitute a part of

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 --- Comment #15 from Maciej W. Rozycki --- If in older C standard versions such enums are invalid, then I think this should be a hard error rather than a silent ABI change for the code produced. Not all code out there will have sanity checks su

[Bug c/107756] New: Change in sizeof(enum) with -std=gnu11 breaks Linux kernel code compilation (PR c/36113 change regression)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107756 Bug ID: 107756 Summary: Change in sizeof(enum) with -std=gnu11 breaks Linux kernel code compilation (PR c/36113 change regression) Product: gcc Version: 13.0 Status: UNC

[Bug ipa/107044] New: internal compiler error: in dump_possible_polymorphic_call_targets, at ipa-devirt.cc:3456

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107044 Bug ID: 107044 Summary: internal compiler error: in dump_possible_polymorphic_call_targets, at ipa-devirt.cc:3456 Product: gcc Version: 13.0 Status:

[Bug tree-optimization/106705] New: Expensive constant load replicated throughout switch statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106705 Bug ID: 106705 Summary: Expensive constant load replicated throughout switch statement Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug c++/104865] Wrong code for conditional expression on VAX or with -ffast-math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104865 --- Comment #7 from Maciej W. Rozycki --- Well, it's not clear to me whether the reserved operand as defined by the VAX floating-point architecture ought be considered an sNaN given that there is no qNaN. Also a reserved operand causes a fault

[Bug c++/104865] Wrong code for conditional expression on VAX or with -ffast-math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104865 --- Comment #5 from Maciej W. Rozycki --- Wrong question then. Should `__builtin_nan' even compile on non-IEEE-754 FP targets that don't have a qNaN? And I'll reply to myself. According to our manual: "-- Built-in Function: double __builtin_

[Bug c++/104865] Wrong code for conditional expression on VAX or with -ffast-math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104865 Maciej W. Rozycki changed: What|Removed |Added CC||macro at orcam dot me.uk --- Commen

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #49 from Maciej W. Rozycki --- *** Bug 98724 has been marked as a duplicate of this bug. ***

[Bug ada/98724] [11/12 Regression] gnat build failure on alpha-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98724 Maciej W. Rozycki changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug middle-end/103059] [12 regression][VAX] ICE in postreload with the ASHIFT form of scaled indexed addressing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103059 Maciej W. Rozycki changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug middle-end/103059] [10 regression][VAX] ICE in postreload with the ASHIFT form of scaled indexed addressing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103059 Maciej W. Rozycki changed: What|Removed |Added Last reconfirmed||2021-11-03 Status|UNCON

[Bug middle-end/103059] New: [10 regression][VAX] ICE in postreload with the ASHIFT form of scaled indexed addressing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103059 Bug ID: 103059 Summary: [10 regression][VAX] ICE in postreload with the ASHIFT form of scaled indexed addressing Product: gcc Version: 12.0 Status: UNCONFIRMED