[Bug tree-optimization/114682] const_array[i].b where i is PHI<0,1,2> is not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114682 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Andrew Pinski --- .
[Bug tree-optimization/114682] const_array[i].b where i is PHI<0,1,2> is not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114682 --- Comment #3 from Andrew Pinski --- Mine, similar to PR 102138 but slightly different because this becomes a load which is more similar to what phiprop does.
[Bug target/116833] [12/13/14/15 Regression] Symbian: incorrect configuration for crtfastmath.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116833 --- Comment #5 from Fiodar --- (In reply to Andrew Pinski from comment #1) > More likely Symbian os support should be removed as I highly doubt anyone > has tested it in the last 10 years. I build ScummVM for Symbian with selfbuilded GCC ≥ 5.4.0. And it worked much faster than build with Codesourcery's build 4.4.1. Which tests you need to run? P.S. ScummVM collection of reimplementing game engines for old adventures. Acts as universal executable not emulator.
[Bug target/116078] [15 Regression] 10-12% slowdown of 436.cactusADM on AMD Zen2 since r15-2187-g838999bb23303e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116078 --- Comment #2 from Andrew Pinski --- So this does not make much sense, maybe before there was something being miscompiled.
[Bug target/116078] [15 Regression] 10-12% slowdown of 436.cactusADM on AMD Zen2 since r15-2187-g838999bb23303e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116078 --- Comment #3 from Andrew Pinski --- or rather the order of some operations for the arguments cause some other missing optimizations. I doubt there is not much to be done from the front-end side of things either.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #21 from Iain Sandoe --- (In reply to Mark Mentovai from comment #20) > Created attachment 59189 [details] > Patch for macOS 14/Xcode 16 > > (In reply to GCC Commits from comment #19) > > The master branch has been updated by Iain D Sandoe : > > > > https://gcc.gnu.org/g:d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 > > > > commit r15-3839-gd9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 > > Author: Iain Sandoe > > Date: Sun Sep 22 11:43:32 2024 +0100 > > > > libgcc, Darwin: Drop the legacy library build for macOS >= 15 > > [PR116809]. > > Unfortunately, this doesn’t resolve the bug in every place that it might be > encountered. > > The bootstrapping problem occurs when targeting x86_64 and using the macOS > 15 SDK. The macOS 15 SDK ships in Xcode 16, which also runs on macOS 14. > libgcc_s.1 can no longer be built on macOS 14 using Xcode 16 by the same > logic that the above change disabled it for macOS 15. Thta is quite surprising - since the SDK should reflect the symbols exported by the libraries installed on the target system. Therefore, they should be present when the target is macOS 14; Perhaps something not conditional in the way it should be - or it is depending on support for attribute ((availability)) which is only currently committed on darwin branches. If we build a compiler targeting macOS 15, but using xcode 16 on macOS 14 - then we should still eliminate the library.
[Bug target/112116] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (VMULCD)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112116 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-09-25 --- Comment #1 from Oleg Endo --- This is probably the same issue as PR 112115. I haven't checked the details, but the eventual ICE looks the same. Compiling the reproducer (lcd.i) with sh-elf-gcc -c -std=c2x -O2 -ml -m4-single -ffast-math -mfsrra -mfsca -matomic-model=soft-imask -ftls-model=local-exec -mlra -fomit-frame-pointer -fno-builtin on current gcc15 master branch fails with internal compiler error: maximum number of generated reload insns per insn achieved (90) 0x1c7ed6e internal_error(char const*, ...) ../../gcc/gcc/diagnostic-global-context.cc:517 0xd910e7 lra_constraints(bool) ../../gcc/gcc/lra-constraints.cc:5404 0xd7abc2 lra(_IO_FILE*, int) ../../gcc/gcc/lra.cc:2445 0xd30de7 do_reload ../../gcc/gcc/ira.cc:5976 0xd30de7 execute ../../gcc/gcc/ira.cc:6164 The issue goes away when using devel/sh-lra branch.
[Bug other/116834] New: "warning: null format string" false positive with UBSAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116834
Bug ID: 116834
Summary: "warning: null format string" false positive with
UBSAN
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: kasper93 at gmail dot com
Target Milestone: ---
Hello,
I got the following warning:
test.c: In function 'foo':
test.c:7:5: warning: null format string [-Wformat-truncation=]
7 | vsnprintf(NULL, 0, fmt, ap);
| ^~~
When compiling the code with `gcc -fsanitize=undefined -Wformat -O2`
#include
#include
#include
void foo(const char *fmt, va_list ap)
{
vsnprintf(NULL, 0, fmt, ap);
if (!fmt)
abort();
}
This issue only occurs with UBSAN. The example provided is minimized and may
not make much sense. The main point is that if there is a check for the `fmt`
value after the `vsnprintf()` call, it will trigger a warning like the one
above. This warning is incorrect because the compiler cannot determine whether
the value is null at compile time in this case.
[Bug target/116822] [15 regression] RISC-V: ICE in compute_nregs_for_mode, at config/riscv/riscv-vector-costs.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116822 --- Comment #1 from Edwin Lu --- Bisected down to r15-3794-g2c04f175de4 as the first bad commit
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #22 from Mark Mentovai ---
(In reply to Iain Sandoe from comment #21)
> Thta is quite surprising - since the SDK should reflect the symbols exported
> by the libraries installed on the target system. Therefore, they should be
> present when the target is macOS 14;
For the purposes of having appropriate declarations available for compiling,
the declarations in the SDK’s headers generally are annotated with availability
and obsolescence annotations. Apple is fairly good about this.
For the purposes of linking, the SDK simply exposes the set of global symbols
exported by loadable modules, previously in stripped-down Mach-O format
containing little more than a symbol table, but nowadays (since SDK 10.11) in
.tbd format. Neither the Mach-O symbol table nor the .tbd format have a way to
express partial availability. The .tbd files are produced as a simple export of
the source Mach-O’s symbol table.
Because the libunwind symbols in question were never intended for user
consumption, but were part of a loose contract with toolchains, there weren’t
any viable declarations for them in SDK headers. The double-underscore prefix
is a hint of this (the third underscore added as “C” name decoration). Where
there were declarations (since SDK 10.7, in ), they were decorated
with __attribute__((unavailable)). This is as good as there being no
declaration at all. In fact, this still appears in SDK 15:
#if defined(__APPLE__)
#define LIBUNWIND_UNAVAIL __attribute__ (( unavailable ))
#else
#define LIBUNWIND_UNAVAIL
#endif
[…]
// Mac OS X 10.4 and 10.5 had implementations of these functions in
// libgcc_s.dylib, but they never worked.
/// These functions are no longer available on Mac OS X.
extern void __register_frame_info_bases(const void *fde, void *ob, void *tb,
void *db) LIBUNWIND_UNAVAIL;
[…]
(from
https://github.com/llvm/llvm-project/blob/1187d8a62ba288e2221731f1795fa184571cd854/libunwind/include/unwind.h#L169)
But we’re not concerned with writing user code and calling these functions by
#including in libgcc_s.1. We’re simply concerned with re-exporting
these symbols from libunwind, via the libSystem umbrella. That’s strictly a
linker concern, and again, the input to the linker carries no information about
availability, including partial availability or unavailability. If a symbol is
present in a macOS runtime, whether the header annotates it as
partially-available or unavailable or (absent an annotation) available without
qualification, it will also appear in that same macOS version’s SDK, as the
.tbd files are produced from the Mach-O files present in the runtime. So when
the runtime drops a symbol entirely, as is the case in macOS 15 for these
libunwind symbols, they disappear from the SDK as well. And when you build
against the macOS 15 SDK to target macOS 14 or an earlier version, you lose
access to the symbols dropped by macOS 15.
Largely, this is working as intended. The only reason that Apple felt
comfortable dropping these symbols from the runtime at all was that they
believed they were entirely unused. I explained this and provided further
justification in comment 10 (although I felt you kind of brushed that off—no
offense taken, though) in support of the idea that libgcc_s.1 could feasibly
drop the symbols as well, as I proposed in attachment 59179. If anyone had been
using those symbols, and successfully linked against a previous SDK, that code
would not have run on macOS 15, because the symbols are no longer part of the
runtime. They’re only safe to remove from the runtime if no code references
them, and if no code references them, then they’re also safe to remove from the
SDK.
> Perhaps something not conditional in the way it should be - or it is
> depending on support for attribute ((availability)) which is only currently
> committed on darwin branches.
Do Not Adjust Your Set. Availability is working as it should. This example is
iains/gcc-14-branch gcc-14-2-darwin:
mark@arm-and-hammer zsh% gcc -x c -c -o /dev/null - <<< 'void U()
__attribute__((unavailable)); void F() { U(); }'
: In function 'F':
:1:1: error: 'U' is unavailable
:1:6: note: declared here
> If we build a compiler targeting macOS 15, but using xcode 16 on macOS 14 -
> then we should still eliminate the library.
Yes. But it’s difficult to cleanly detect what Xcode version you’re using, or
perhaps more directly, whether libSystem exposes any of these symbols. You
could do it with a configure check, but that seems like a little much for a
handful of symbols that nobody’s using.
Another option is to eliminate them from macOS 14 regardless of the SDK in use
(attachment 59189).
[Bug other/116834] "warning: null format string" false positive with UBSAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116834
--- Comment #2 from Kacper Michajłow ---
static inline struct bstr bstr0(const char *s)
{
return (struct bstr){(unsigned char *)s, s ? strlen(s) : 0};
}
void bstr_xappend_vasprintf(void *talloc_ctx, bstr *s, const char *fmt,
va_list ap)
{
int size;
va_list copy;
va_copy(copy, ap);
size_t avail = talloc_get_size(s->start) - s->len;
char *dest = s->start ? s->start + s->len : NULL;
size = vsnprintf(dest, avail, fmt, copy);
va_end(copy);
if (size < 0) {
bstr_xappend(talloc_ctx, s, bstr0("format error: "));
bstr_xappend(talloc_ctx, s, bstr0(fmt));
return;
}
if (avail < 1 || size + 1 > avail) {
resize_append(talloc_ctx, s, size + 1);
vsnprintf(s->start + s->len, size + 1, fmt, ap);
}
s->len += size;
}
If you want whole thing
https://github.com/mpv-player/mpv/blob/ad7012284eaaaf2064e52668d9243465f5188dd2/misc/bstr.c
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #322 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #316) > (In reply to Oleg Endo from comment #314) > > Can you please add the patch to your github branch? > > I would like to ask some Dreamcast folks to try and test the GCC LRA branch > > with some bigger real-world software. For that we need to have a "known > > good state" of a branch on github. > > I've pushed the sfunc patch with lengthy sfunc patterns using > hard_reg_r[456] + the patch in c#312 on the top of > > [59157] a revised patch to movsf issue which splits movesf_ie_ra > [59158] a revised patch to QIHI extend/move > [59153] Alex's patch works magically for call_pcrel* issue. > > as sh-lra-take3 branch of https://github.com/kazkojima/gcc.git. Hope this > helps. Thanks! I've also created a branch with your patches here: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/sh-lra I've retouched the commits a little bit here and there, mainly in the comments and commit messages. If you have more patches or make a new branch, I will gradually merge them over and try to keep the devel/sh-lra branch in a useful state. With the current state, some open issues like PR 112115 are resolved. But others like PR 115949 or PR 113193 still remain. Although those cases have been also problematic before LRA as well. I might be wrong, but I've got this feeling that whenever LRA hits the "reload limit" it's an indicator that something is running in circles in the move-insn pattern definitions. I've noticed one thing. The patch 'SH: pin input args to hard-regs via predicates for sfuncs' skips the change for the patterns 'udivsi3_i4_int' and 'block_move_real_i4'. Is this intentional or by accident?
[Bug target/113193] [SH] ICE in gen_reg_rtx, at emit-rtl.cc:1177 with -mfcsa -funsafe-math-operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113193 --- Comment #2 from Oleg Endo --- I've tried compiling this case with sh-elf-gcc -m4-single -O3 -std=c++20 -c -mfsca -funsafe-math-optimizations on devel/sh-lra branch -- the issue still persists
[Bug target/115949] [SH] unrecognized insn in postreload (movsi_ie gets wrong fp reg operand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115949 --- Comment #6 from Oleg Endo --- I've tried this on the devel/sh-lra branch with sh-elf-gcc -c -O3 -m4-single -mfsrra -mfsca -ffast-math The issue still persists.
[Bug tree-optimization/116835] New: phiprop will prop back into a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116835
Bug ID: 116835
Summary: phiprop will prop back into a loop
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Blocks: 116821, 116824
Target Milestone: ---
Take:
```
struct Foo {
int **p;
int **q;
};
struct Foo1 {
int t[4];
};
int
bar (int b, int c, int d, struct Foo1 *aa)
{
int *p = &c;
for (int j = 0; j < 4; ++j)
{
p = &aa->t[j];
}
return *p;
}
```
phiprop1 does:
```
Inserting PHI for result of load _6 = *p_1;
for edge defining &c inserting load _4 = c;
for edge defining p_8 inserting load _3 = *p_8;
_6 = PHI <_4(2), _3(3)>
Removing dead stmt:p_1 = PHI <&c(2), p_8(3)>
```
But this is moving the load into the loop which seems wrong and might cause
other issues.
I am running into a regression due to this when fixing PR 116821 .
PR 116824 will cause this to show up more too.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116821
[Bug 116821] phiprop could be improved to handle PHI<&a, ssa_name>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116824
[Bug 116824] phiprop gets confused with vop phi
[Bug other/116834] "warning: null format string" false positive with UBSAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116834 --- Comment #1 from Andrew Pinski --- Jump threading introduces the code: ``` [local count: 1073741824]: if (fmt_2(D) == 0B) goto ; [0.00%] else goto ; [100.00%] [local count: 1073741824]: # .MEM_8 = VDEF <.MEM_1(D)> vsnprintf (0B, 0, fmt_2(D), ap); [tail call] # VUSE <.MEM_8> return; [count: 0]: # .MEM_6 = VDEF <.MEM_1(D)> __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data0); # .MEM_3 = VDEF <.MEM_6> vsnprintf (0B, 0, 0B, ap); # .MEM_4 = VDEF <.MEM_3> abort (); ``` Obvious if you place the check for fmt before the vsnprintf there will be no warning. Can you provide the original case?
[Bug target/116836] New: [SH] Unknown FPU mode switch state for inline-asm blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116836 Bug ID: 116836 Summary: [SH] Unknown FPU mode switch state for inline-asm blocks Product: gcc Version: 14.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- Currently the FPU mode-switching does not take into account inline-asm blocks. As a result it's difficult to make sure that the FPU is in a known particular state when it his the inline-asm blocks. It makes inline-asm cumbersome to use, in particular with LTO, which can automatically inline functions and break the FPU mode assumptions at function entry. What people are currently doing is forcing those functions to be no-inline to avoid those issues. It would be better to have a way to control the FPU mode at inline-asm entry/exit somehow.
[Bug tree-optimization/116835] phiprop will prop back into a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116835 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-09-25 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- . Working on a patch.
[Bug tree-optimization/102138] t = a==0 and a = PHI<0, t> should be done earlier than PRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102138 --- Comment #5 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2017-November/489192.html
[Bug fortran/116025] Experimental implementation of unsigned integers for Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116025 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- Thomas, shall we close this one?
[Bug fortran/116040] [13 regression] New test case gfortran.dg/pr113363.f90 from r13-8926-g7c81ff02a943cd ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116040 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle --- I can revert this for you if this will get it off your list. Let me know.
[Bug tree-optimization/102138] t = a==0 and a = PHI<0, t> should be done earlier than PRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102138 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > https://gcc.gnu.org/pipermail/gcc-patches/2017-November/489192.html Review from Richard B.: https://gcc.gnu.org/pipermail/gcc-patches/2018-May/498001.html
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #323 from Oleg Endo --- I've tried getting some code size numbers from CSiBE comparision for 'sh-elf-gcc -m4-single -O2' with the devel/sh-lra branch. The numbers are code size in bytes with -mno-lra and -mlra OpenTCP-1.0.4 total: 29498 -> 29470 -28 / -0.094922 % bzip2-1.0.2total: 65894 -> 67010 +1116 / +1.693629 % cg_compiler_opensrctotal:129771 -> 130147 +376 / +0.289741 % compiler total: 27603 -> 27767 +164 / +0.594138 % flex-2.5.31total:244507 -> 243955 -552 / -0.225760 % jikespg-1.3total:214135 -> 213427 -708 / -0.330633 % jpeg-6btotal:125100 -> 125784 +684 / +0.546763 % libmspack total: 63369 -> 63525 +156 / +0.246177 % libpng-1.2.5 total:108836 -> 108840 +4 / +0.003675 % linux-2.4.23-pre3-testplatform total:956603 -> 956920 +317 / +0.033138 % lwip-0.5.3.preproc total: 83129 -> 8 +204 / +0.245402 % mpeg2dec-0.3.1 total: 51046 -> 50954 -92 / -0.180230 % mpgcut-1.1 total: 19576 -> 19740 +164 / +0.837761 % replaypc-0.4.0.preproc total: 57206 -> 57518 +312 / +0.545397 % teem-1.6.0-src total: 1120729 -> 1123341+2612 / +0.233063 % ttt-0.10.1.preproc total: 15344 -> 15356 +12 / +0.078206 % unrarlib-0.4.0 total: 14152 -> 14192 +40 / +0.282646 % zlib-1.1.4 total: 34326 -> 34162 -164 / -0.42 %
[Bug fortran/116828] Gfortran 14.0.1 thinks that [ 1 + 1 = 0 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116828 --- Comment #4 from Jordan <8e3g6jay6 at mozmail dot com> --- thanks
[Bug c/116735] ICE in build_counted_by_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116735 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- For the testsuite, the testcase needs to use __SIZE_TYPE__ instead of the unsigned long in the prototype, or just use __builtin_malloc.
[Bug target/116830] pubtypes-{2,3,4}.c test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116830 Andrew Pinski changed: What|Removed |Added Target||*darwin* --- Comment #1 from Andrew Pinski --- Darwin changed: r11-3035-g84e9fc470f57c9
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug 98940 depends on bug 107637, which changed state. Bug 107637 Summary: [C++23] P2718R0 - Final Fix of Broken Range‐based for Loop https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107637 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/107637] [C++23] P2718R0 - Final Fix of Broken Range‐based for Loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107637 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Implemented for GCC 15.
[Bug c++/107637] [C++23] P2718R0 - Final Fix of Broken Range‐based for Loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107637
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:650e91566561870f3d1c8d5b92e6613296ee1a8d
commit r15-3840-g650e91566561870f3d1c8d5b92e6613296ee1a8d
Author: Jakub Jelinek
Date: Tue Sep 24 20:19:50 2024 +0200
c++: Implement C++23 P2718R0 - Wording for P2644R1 Fix for Range-based for
Loop [PR107637]
The following patch implements the C++23 P2718R0 paper
- Wording for P2644R1 Fix for Range-based for Loop.
The patch introduces a new option, -f{,no-}range-for-ext-temps so that
user can control the behavior even in older C++ versions.
The option is on by default in C++23 and later (-fno-range-for-ext-temps
is an error in that case) and in the -std=gnu++11 ... -std=gnu++20 modes
(one can use -fno-range-for-ext-temps to request previous behavior in that
case), and is not enabled by default in -std=c++11 ... -std=c++20 modes
but one can explicitly enable it with -frange-for-ext-temps.
As all the temporaries from __for_range initialization should have life
extended until the end of __for_range scope, this patch disables (for
-frange-for-ext-temps and if !processing_template_decl) CLEANUP_POINT_EXPR
wrapping
of the __for_range declaration, also disables -Wdangling-reference warning
as well as the rest of extend_ref_init_temps (we know the __for_range
temporary
is not TREE_STATIC and as all the temporaries from the initializer will be
life
extended, we shouldn't try to handle temporaries referenced by references
any
differently) and adds an extra push_stmt_list/pop_stmt_list before
cp_finish_decl of __for_range and after end of the for body and wraps all
that into CLEANUP_POINT_EXPR.
I had to repeat that also for OpenMP range loops because those are handled
differently.
2024-09-24 Jakub Jelinek
PR c++/107637
gcc/
* omp-general.cc (find_combined_omp_for, find_nested_loop_xform):
Handle CLEANUP_POINT_EXPR like TRY_FINALLY_EXPR.
* doc/invoke.texi (frange-for-ext-temps): Document. Add
-fconcepts to the C++ option list.
gcc/c-family/
* c.opt (frange-for-ext-temps): New option.
* c-opts.cc (c_common_post_options): Set flag_range_for_ext_temps
for C++23 or later or for C++11 or later in !flag_iso mode if
the option wasn't set by user.
* c-cppbuiltin.cc (c_cpp_builtins): Change __cpp_range_based_for
value for flag_range_for_ext_temps from 201603L to 202212L in C++17
or later.
* c-omp.cc (c_find_nested_loop_xform_r): Handle CLEANUP_POINT_EXPR
like TRY_FINALLY_EXPR.
gcc/cp/
* cp-tree.h: Implement C++23 P2718R0 - Wording for P2644R1 Fix for
Range-based for Loop.
(cp_convert_omp_range_for): Add bool tmpl_p argument.
(find_range_for_decls): Declare.
* parser.cc (cp_convert_range_for): For flag_range_for_ext_temps
call
push_stmt_list () before cp_finish_decl for range_temp and save it
temporarily to FOR_INIT_STMT.
(cp_convert_omp_range_for): Add tmpl_p argument. If set, remember
DECL_NAME of range_temp and for cp_finish_decl call restore it
before
clearing it again, if unset, don't adjust DECL_NAME of range_temp
at
all.
(cp_parser_omp_loop_nest): For flag_range_for_ext_temps range for
add
CLEANUP_POINT_EXPR around sl. Call find_range_for_decls and adjust
DECL_NAMEs for range fors if not processing_template_decl. Adjust
cp_convert_omp_range_for caller. Remove superfluous backslash at
the
end of line.
* decl.cc (initialize_local_var): For flag_range_for_ext_temps
temporarily clear stmts_are_full_exprs_p rather than set for
for_range__identifier decls.
* call.cc (extend_ref_init_temps): For flag_range_for_ext_temps
return
init early for for_range__identifier decls.
* semantics.cc (find_range_for_decls): New function.
(finish_for_stmt): Use it. For flag_range_for_ext_temps if
cp_convert_range_for set FOR_INIT_STMT, pop_stmt_list it and wrap
into CLEANUP_POINT_EXPR.
* pt.cc (tsubst_omp_for_iterator): Adjust tsubst_omp_for_iterator
caller.
(tsubst_stmt) : For flag_range_for_ext_temps if there
are any range fors in the loop nest, add push_stmt_list starting
before the initializations, pop_stmt_list it after the body and
wrap
into CLEANUP_POINT_EXPR. Change DECL_NAME of range for temps from
NULL to for_range_identifier.
gcc/testsuite/
* g++.dg/cpp23/range-for1.C: New test.
* g++.dg/cpp23/range-for2.C: New test.
* g++.dg/cpp2
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #19 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 commit r15-3839-gd9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 Author: Iain Sandoe Date: Sun Sep 22 11:43:32 2024 +0100 libgcc, Darwin: Drop the legacy library build for macOS >= 15 [PR116809]. We have been building a legacy libgcc_s.1 DSO to support code that was built with older compilers. From macOS 15, the unwinder no longer exports some of the symbols used in that library which (a) cuases bootstrap fail and (b) means that the legacy library is no longer useful. No open branch of GCC emits references to this library - and any already -built code that depends on the symbols would need rework anyway. PR target/116809 libgcc/ChangeLog: * config.host: Build legacy libgcc_s.1 on hosts before macOS 15. * config/i386/t-darwin: Remove reference to legacy libgcc_s.1 * config/rs6000/t-darwin: Likewise. * config/t-darwin-libgccs1: New file. Signed-off-by: Iain Sandoe
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #6 from Francois-Xavier Coudert --- (In reply to Jonathan Wakely from comment #5) > > #if defined(__has_feature) && __has_feature(modules) > > This is a bug. If __has_feature is _not_ define, then __has_feature(modules) > would not compile Definitely agree, I had missed that, thanks for highlighting it. Every year some more examples crop up into the SDKs, and every year I report them. Reported the examples in macOS 15.0 SDK as FB15255066 A copy of that report is available there: https://gist.github.com/fxcoudert/1e3ed3470febf220a392152189c143a3 > It looks like the header now assumes that if __has_feature(modules) is true, > then they're compiling with Clang. Which is not true because GCC supports > __has_feature now. Before I report this to Apple, I want to have an opinion: Iain, what do you think is the best fix there? Do we want to suggest Apple not bypass USE_CLANG_TYPES on GCC?
[Bug tree-optimization/116785] [15 Regression] RAJAPerf REDUCE_SUM regresses with r15-792-gf0a02467bbc35a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785 --- Comment #10 from kugan at gcc dot gnu.org --- Created attachment 59186 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59186&action=edit reduced test (second attempt) Sorry about the test case. Here is another attempt at reducing.
[Bug tree-optimization/116821] phiprop could be improved to handle PHI<&a, ssa_name>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116821 --- Comment #4 from Andrew Pinski --- So looking into why this does not work but PR 57380 does. The testcase in PR 57380 again has an ADDR_EXPR which just happens to be a pointer plus (with a multiply). _1 = &b.data[i_5]; _2 = &a.data[i_5]; vs: _3 = b_15(D) + _2; ... _6 = a_16(D) + _5;
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #320 from John Paul Adrian Glaubitz --- Full command line is: /home/glaubitz/gcc-kaz/build/./gcc/xgcc -B/home/glaubitz/gcc-kaz/build/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem /usr/local/sh4-unknown-linux-gnu/include -isystem /usr/local/sh4-unknown-linux-gnu/sys-include-c -g -O2 -fpic -fno-lto -W -Wall -gnatpg -nostdinc a-nscefu.ads -o a-nscefu.o which is run from the build/gcc/ada/rts subfolder. The problem goes away with -O0 or -mno-lra.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #321 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #320) > Full command line is: > > /home/glaubitz/gcc-kaz/build/./gcc/xgcc > -B/home/glaubitz/gcc-kaz/build/./gcc/ > -B/usr/local/sh4-unknown-linux-gnu/bin/ > -B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem > /usr/local/sh4-unknown-linux-gnu/include -isystem > /usr/local/sh4-unknown-linux-gnu/sys-include-c -g -O2 -fpic -fno-lto > -W -Wall -gnatpg -nostdinc a-nscefu.ads -o a-nscefu.o > > which is run from the build/gcc/ada/rts subfolder. The problem goes away > with -O0 or -mno-lra. Adding -fno-split-wide-types to the command line fixes the problem.
[Bug testsuite/116683] new test g++.dg/ext/pragma-unroll-lambda-lto.C from r15-3585-g9759f6299d9633 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116683 --- Comment #2 from seurer at gcc dot gnu.org --- I tried adding -munroll-only-small-loops and it still fails. spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/pragma-unroll-lambda-lto.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++26 -O2 -flto -fdump-rtl-loop2_unroll -munroll-only-small-loops -L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/experimental/.libs -B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libitm/ -L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libitm/.libs -lm -o pragma-unroll-lambda-lto.exe PASS: g++.dg/ext/pragma-unroll-lambda-lto.C -std=gnu++26 (test for excess errors) g++.dg/ext/pragma-unroll-lambda-lto.C -std=gnu++26 : pattern found 2 times FAIL: g++.dg/ext/pragma-unroll-lambda-lto.C -std=gnu++26 scan-ltrans-rtl-dump-times loop2_unroll "Unrolled loop 3 times" 1
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #324 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #322) > I've also created a branch with your patches here: > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/sh-lra > > I've retouched the commits a little bit here and there, mainly in the > comments and commit messages. > > If you have more patches or make a new branch, I will gradually merge them > over and try to keep the devel/sh-lra branch in a useful state. > > With the current state, some open issues like PR 112115 are resolved. But > others like PR 115949 or PR 113193 still remain. Although those cases have > been also problematic before LRA as well. Thanks! > I might be wrong, but I've got this feeling that whenever LRA hits the > "reload limit" it's an indicator that something is running in circles in the > move-insn pattern definitions. You are right. I have not seen any other cases yet. > I've noticed one thing. The patch 'SH: pin input args to hard-regs via > predicates for sfuncs' skips the change for the patterns 'udivsi3_i4_int' > and 'block_move_real_i4'. Is this intentional or by accident? It's intentional. Those sfunc's don't clobber r4, r5 and r6. sdivsi3_* and other are in the similar situation.
[Bug target/112115] SH4 ICE: in extract_constrain_insn, at recog.cc:2692 with -mlra (VMUBEEP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112115 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-09-25 --- Comment #8 from Oleg Endo --- This issue seems to be resolved on the devel/sh-lra branch.
[Bug fortran/116828] New: Gfortran 14.0.1 thinks that [ 1 + 1 = 0 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116828 Bug ID: 116828 Summary: Gfortran 14.0.1 thinks that [ 1 + 1 = 0 ] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: 8e3g6jay6 at mozmail dot com Target Milestone: --- I don't know what else to really say about this. Here's the whole program: program oh_no use, intrinsic :: iso_c_binding implicit none integer(c_int) :: i, w w = 1 do i = 1,1000 w = w + w end do ! IT'S 0?! print*,w end program oh_no
[Bug tree-optimization/116819] [15 Regression] ICE in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116819 --- Comment #6 from Richard Biener --- So we end up with t.c:10:22: note: ==> examining statement: _24 = MEM[(const long long unsigned int &)_5]; t.c:10:22: note: irrelevant. in the SLP tree as it is part of the DR group but it's really a dead stmt with no uses. Unfortunately we pick it as representative but that makes the whole SLP node irrelevant (we should weed out those checks). The dead stmt is left behind by loop if-conversion which already performs some DCE but not enough: Removing dead stmt prephitmp_50 = 0; Delete dead stmt in bb#3 _38 = (char) _37; Delete dead stmt in bb#3 _37 = _24 > 69; Delete dead stmt in bb#3 _31 = (char) _51; Delete dead stmt in bb#3 _51 = _24 <= 69; Delete dead stmt in bb#3 _49 = (char) _47; Delete dead stmt in bb#3 _47 = _24 == 0; for some reason the ifcvt local DCE considers stores live... I have a mitigation in the vectorizer for this particular case.
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #4 from Francois-Xavier Coudert --- Simple reproducer without any libstdc++ indeed: $ cat a.cpp #include $ g++ a.cpp -fmodule-header
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
--- Comment #5 from Jonathan Wakely ---
(In reply to Francois-Xavier Coudert from comment #3)
> where that new USE_CLANG_TYPES macro is defined at the top of the file:
>
>
> #if defined(__has_feature) && __has_feature(modules)
This is a bug. If __has_feature is _not_ define, then __has_feature(modules)
would not compile:
hf.c:1:44: error: missing binary operator before token "("
1 | #if defined(__has_feature) && __has_feature(uhoh)
|^
This needs to be reported to Apple. Either they should just assume
__has_feature works and not bother checking if it's defined, or check for it
properly.
> #define USE_CLANG_TYPES 1
> #else
> #define USE_CLANG_TYPES 0
> #endif
It looks like the header now assumes that if __has_feature(modules) is true,
then they're compiling with Clang. Which is not true because GCC supports
__has_feature now.
So I think this needs a fixincludes change for GCC to be able to use these new
SDK headers.
> I'm thoroughly confused by this series of includes, especially as
> __need_ptrdiff_t is never used anywhere in the SDK.
GCC's stddef.h uses it.
[Bug tree-optimization/116819] [15 Regression] ICE in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116819 --- Comment #7 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:cef29936c6b6773bff1939f94fb629760725bd82 commit r15-3831-gcef29936c6b6773bff1939f94fb629760725bd82 Author: Richard Biener Date: Tue Sep 24 13:47:04 2024 +0200 tree-optimization/116819 - SLP with !STMT_VINFO_RELEVANT representative Under some circumstances we can end up picking a not relevant stmt as representative of a SLP node. Instead of skipping stmt analysis and declaring success we have to either ignore relevancy throughout the code base or fail SLP operation verification. The following does the latter. PR tree-optimization/116819 * tree-vect-stmts.cc (vect_analyze_stmt): When the SLP representative isn't relevant signal failure instead of success.
[Bug tree-optimization/116819] [15 Regression] ICE in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116819 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Richard Biener --- Fixed.
[Bug target/116830] New: pubtypes-{2,3,4}.c test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116830
Bug ID: 116830
Summary: pubtypes-{2,3,4}.c test failure
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
Created attachment 59187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59187&action=edit
Generated asm
FAIL: gcc.dg/pubtypes-2.c scan-assembler long+[ t]+0x14d+[ t]+[#;]+[
t]+Pub Info Length
FAIL: gcc.dg/pubtypes-3.c scan-assembler long+[ t]+0x14d+[ t]+[#;]+[
t]+Pub Info Length
FAIL: gcc.dg/pubtypes-4.c scan-assembler long+[ t]+0x184+[ t]+[#;]+[
t]+Pub Info Length
These three failures exist on darwin23 and darwin24 (at least). For
pubtypes-2.c, for example, we expect the asm to match:
/* { dg-final { scan-assembler {long+[ \t]+0x14d+[ \t]+[#;]+[ \t]+Pub Info
Length} } } */
but instead we have:
$ grep 'Pub Info Length' pubtypes-2.s
.long 0x2e# Pub Info Length
.long 0x12e # Pub Info Length
The full asm is attached.
[Bug middle-end/116814] [15 Regression] ICE on libjack2-1.9.22: in expand_fn_using_insn, at internal-fn.cc:263 since r15-1671-gf2476a2649e997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116814
--- Comment #3 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:de6fe690db32689ba5e5c6f551672a19e6cae5d4
commit r15-3832-gde6fe690db32689ba5e5c6f551672a19e6cae5d4
Author: Pan Li
Date: Mon Sep 23 22:37:58 2024 +0800
Widening-Mul: Fix one ICE for SAT_SUB matching operand checking
This patch would like to fix the following ICE for -O2 -m32 of x86_64.
during RTL pass: expand
JackMidiAsyncWaitQueue.cpp.cpp: In function 'void DequeueEvent(unsigned
int)':
JackMidiAsyncWaitQueue.cpp.cpp:3:6: internal compiler error: in
expand_fn_using_insn, at internal-fn.cc:263
3 | void DequeueEvent(unsigned frame) {
| ^~~~
0x27b580d diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*,
__va_list_tag (*) [1], diagnostic_t)
???:0
0x27c4a3f internal_error(char const*, ...)
???:0
0x27b3994 fancy_abort(char const*, int, char const*)
???:0
0xf25ae5 expand_fn_using_insn(gcall*, insn_code, unsigned int, unsigned
int)
???:0
0xf2a124 expand_direct_optab_fn(internal_fn, gcall*, optab_tag, unsigned
int)
???:0
0xf2c87c expand_SAT_SUB(internal_fn, gcall*)
???:0
We allowed the operand convert when matching SAT_SUB in match.pd, to
support
the zip benchmark SAT_SUB pattern. Aka,
(convert? (minus (convert1? @0) (convert1? @1))) for below sample code.
void test (uint16_t *x, unsigned b, unsigned n)
{
unsigned a = 0;
register uint16_t *p = x;
do {
a = *--p;
*p = (uint16_t)(a >= b ? a - b : 0); // Truncate after .SAT_SUB
} while (--n);
}
The pattern match for SAT_SUB itself may also act on below scalar sample
code too.
unsigned long long GetTimeFromFrames(int);
unsigned long long GetMicroSeconds();
void DequeueEvent(unsigned frame) {
long long frame_time = GetTimeFromFrames(frame);
unsigned long long current_time = GetMicroSeconds();
DequeueEvent(frame_time < current_time ? 0 : frame_time - current_time);
}
Aka:
uint32_t a = (uint32_t)SAT_SUB(uint64_t, uint64_t);
Then there will be a problem when ia32 or -m32 is given when compiling.
Because we only check the lhs (aka uint32_t) type is supported by ifn
instead of the operand (aka uint64_t). Mostly DImode is disabled for
32 bits target like ia32 or rv32gcv, and then trigger ICE when expanding.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
* The x86 bootstrap test.
* The x86 fully regression test.
PR middle-end/116814
gcc/ChangeLog:
* tree-ssa-math-opts.cc (build_saturation_binary_arith_call): Make
ifn is_supported type check based on operand instead of lhs.
gcc/testsuite/ChangeLog:
* g++.dg/torture/pr116814-1.C: New test.
Signed-off-by: Pan Li
[Bug tree-optimization/116826] New: Optimise log (1.0 / x) into -log (x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116826
Bug ID: 116826
Summary: Optimise log (1.0 / x) into -log (x)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
float
foo (float a)
{
return __builtin_logf (1.0f / a);
}
We can avoid the division by folding it into -__builtin_logf (a);
under the usual -funsafe-math-optimizations group for all the various standard
logs.
More generally, log (CST / a) could be folded into log (CST) - log (a).
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #18 from Francois-Xavier Coudert --- I can confirm that the patch posted by Iain at https://gcc.gnu.org/bugzilla/attachment.cgi?id=59176 applied on top of (now pushed) https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=43eab54939d37d4e634a692910d31adafc053e38 does restore bootstrap on macOS Sequoia Intel and has no negative impact on the testsuite. It can be pushed.
[Bug libstdc++/116827] New: New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 Bug ID: 116827 Summary: New C++ failures in macOS 15 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- I am seeing a lot of new C++ failures in the testsuite when I test on macOS 15 (Sequoia), that aren't there for macOS 14. I believe it is probably due to SDK incompatibilities. The list of new failures is: +XPASS: c-c++-common/analyzer/flex-with-call-summaries.c +FAIL: c-c++-common/analyzer/flex-with-call-summaries.c +XPASS: c-c++-common/analyzer/flex-with-call-summaries.c +FAIL: c-c++-common/analyzer/flex-with-call-summaries.c +FAIL: c-c++-common/analyzer/flex-without-call-summaries.c +FAIL: c-c++-common/analyzer/strndup-1.c +FAIL: g++.dg/modules/binding-1_a.H +FAIL: g++.dg/modules/binding-1_b.H +FAIL: g++.dg/modules/binding-1_c.C +UNRESOLVED: g++.dg/modules/contracts-1 +FAIL: g++.dg/modules/contracts-1_a.C +FAIL: g++.dg/modules/contracts-1_b.C +UNRESOLVED: g++.dg/modules/contracts-2 +FAIL: g++.dg/modules/contracts-2_a.C +FAIL: g++.dg/modules/contracts-2_b.C +FAIL: g++.dg/modules/contracts-2_c.C +UNRESOLVED: g++.dg/modules/contracts-3 +FAIL: g++.dg/modules/contracts-3_a.C +FAIL: g++.dg/modules/contracts-3_b.C +UNRESOLVED: g++.dg/modules/contracts-4 +FAIL: g++.dg/modules/contracts-4_a.C +FAIL: g++.dg/modules/contracts-4_b.C +FAIL: g++.dg/modules/contracts-4_c.C +FAIL: g++.dg/modules/contracts-4_d.C +UNRESOLVED: g++.dg/modules/global-2 +FAIL: g++.dg/modules/global-2_a.C +FAIL: g++.dg/modules/global-2_b.C +UNRESOLVED: g++.dg/modules/global-3 +FAIL: g++.dg/modules/global-3_a.C +FAIL: g++.dg/modules/global-3_b.C +UNRESOLVED: g++.dg/modules/hello-1 +FAIL: g++.dg/modules/hello-1_a.C +FAIL: g++.dg/modules/hello-1_b.C +UNRESOLVED: g++.dg/modules/hello-2 +FAIL: g++.dg/modules/hello-2_a.C +FAIL: g++.dg/modules/hello-2_b.C +UNRESOLVED: g++.dg/modules/iostream-1 +FAIL: g++.dg/modules/iostream-1_a.H +FAIL: g++.dg/modules/iostream-1_b.C +FAIL: g++.dg/modules/part-5_c.C +FAIL: g++.dg/modules/pr99023_b.X +FAIL: g++.dg/modules/pr99166_a.X +FAIL: g++.dg/modules/pr99166_b.C +FAIL: g++.dg/modules/pr99166_c.C +FAIL: g++.dg/modules/pr99166_d.C +FAIL: g++.dg/modules/pr99425-2_b.X +UNRESOLVED: g++.dg/modules/stdio-1 +FAIL: g++.dg/modules/stdio-1_a.H +FAIL: g++.dg/modules/stdio-1_b.C +FAIL: g++.dg/modules/string-1_a.H +FAIL: g++.dg/modules/string-1_b.C +FAIL: g++.dg/modules/string-view1.C +UNRESOLVED: g++.dg/modules/target-aarch64-1 +FAIL: g++.dg/modules/target-aarch64-1_a.C +FAIL: g++.dg/modules/target-aarch64-1_b.C +FAIL: g++.dg/modules/using-26_a.C +FAIL: g++.dg/modules/using-26_b.C +FAIL: g++.dg/modules/using-26_c.C +FAIL: g++.dg/modules/xtreme-header-1_a.H +FAIL: g++.dg/modules/xtreme-header-1_b.C +FAIL: g++.dg/modules/xtreme-header-1_c.C +FAIL: g++.dg/modules/xtreme-header-2_a.H +FAIL: g++.dg/modules/xtreme-header-2_b.C +FAIL: g++.dg/modules/xtreme-header-2_c.C +FAIL: g++.dg/modules/xtreme-header-3_a.H +FAIL: g++.dg/modules/xtreme-header-3_b.C +FAIL: g++.dg/modules/xtreme-header-3_c.C +FAIL: g++.dg/modules/xtreme-header-4_a.H +FAIL: g++.dg/modules/xtreme-header-4_b.C +FAIL: g++.dg/modules/xtreme-header-4_c.C +FAIL: g++.dg/modules/xtreme-header-5_a.H +FAIL: g++.dg/modules/xtreme-header-5_b.C +FAIL: g++.dg/modules/xtreme-header-5_c.C +FAIL: g++.dg/modules/xtreme-header-6_a.H +FAIL: g++.dg/modules/xtreme-header-6_b.C +FAIL: g++.dg/modules/xtreme-header-6_c.C +FAIL: g++.dg/modules/xtreme-header-7_a.H +FAIL: g++.dg/modules/xtreme-header-7_b.C +FAIL: g++.dg/modules/xtreme-header_a.H +FAIL: g++.dg/modules/xtreme-header_b.C I've looked at a number of them, and the common pattern is: spawn -ignore SIGHUP /Users/fx/ibin-20240923/gcc/testsuite/g++/../../xg++ -B/Users/fx/ibin-20240923/gcc/testsuite/g++/../../ /Users/fx/gcc-darwin-arm64/gcc/testsuite/g++.dg/modules/binding-1_a.H -fdiagnostics-plain-output -nostdinc++ -I/Users/fx/ibin-20240923/aarch64-apple-darwin24/libstdc++-v3/include/aarch64-apple-darwin24 -I/Users/fx/ibin-20240923/aarch64-apple-darwin24/libstdc++-v3/include -I/Users/fx/gcc-darwin-arm64/libstdc++-v3/libsupc++ -I/Users/fx/gcc-darwin-arm64/libstdc++-v3/include/backward -I/Users/fx/gcc-darwin-arm64/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -fmodule-header -S -o binding-1_a.s In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/machine/_types.h:34, from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:33, from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_types.h:27, from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_wchar.h:70, from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/wchar
[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 --- Comment #44 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9a795b3a5b6a0d8b4b4f38a66ab9782aabead92e commit r15-3824-g9a795b3a5b6a0d8b4b4f38a66ab9782aabead92e Author: Richard Biener Date: Tue Sep 24 12:53:11 2024 +0200 tree-optimization/114855 - more update_ssa speedup The following tackles another source of slow bitmap operations, namely populating blocks_to_update. We already have that in tree view around PHI insertion but also the initial population is slow. There's unfortunately a conditional inbetween list view requirement and the bitmap API doesn't allow opportunistic switching but rejects tree -> tree or list -> list transitions. So the following patch wraps the early population in a tree view section with possibly one redundant tree -> list -> tree view transition. This cuts tree SSA incremental from 228.25s (21%) to 65.05s (7%). PR tree-optimization/114855 * tree-into-ssa.cc (update_ssa): Use tree view for the initial population of blocks_to_update.
[Bug libstdc++/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #3 from Francois-Xavier Coudert --- I thought the dependence on -fmodule-header was indicative of an issue with the libstdc++ compatibility with the macOS SDK, but maybe I'm wrong. I've made it component == target. Looking at the macOS /usr/include/arm/_types.h header, in previous versions it was defining __darwin_ptrdiff_t as: #if defined(__PTRDIFF_TYPE__) typedef __PTRDIFF_TYPE____darwin_ptrdiff_t; /* ptr1 - ptr2 */ #elif defined(__LP64__) typedef long__darwin_ptrdiff_t; /* ptr1 - ptr2 */ #else typedef int __darwin_ptrdiff_t; /* ptr1 - ptr2 */ #endif /* __GNUC__ */ and now it is: #if USE_CLANG_TYPES typedef ptrdiff_t __darwin_ptrdiff_t; /* ptr1 - ptr2 */ #elif defined(__PTRDIFF_TYPE__) typedef __PTRDIFF_TYPE____darwin_ptrdiff_t; /* ptr1 - ptr2 */ #elif defined(__LP64__) typedef long__darwin_ptrdiff_t; /* ptr1 - ptr2 */ #else typedef int __darwin_ptrdiff_t; /* ptr1 - ptr2 */ #endif /* __GNUC__ */ where that new USE_CLANG_TYPES macro is defined at the top of the file: #if defined(__has_feature) && __has_feature(modules) #define USE_CLANG_TYPES 1 #else #define USE_CLANG_TYPES 0 #endif #if USE_CLANG_TYPES #include #include #include #include #endif So -fmodule-header makes USE_CLANG_TYPES defined. Similarly, /usr/include/sys/_types/_ptrdiff_t.h used to be relatively straightforward: #ifndef _PTRDIFF_T #define _PTRDIFF_T #include /* __darwin_ptrdiff_t */ typedef __darwin_ptrdiff_t ptrdiff_t; #endif /* _PTRDIFF_T */ but now it has more complex logic: #if defined(__has_feature) && __has_feature(modules) #define USE_CLANG_STDDEF 1 #else #define USE_CLANG_STDDEF 0 #endif #if USE_CLANG_STDDEF #ifndef __PTRDIFF_T #define __PTRDIFF_T #define __need_ptrdiff_t #include #undef __need_ptrdiff_t #endif /* __PTRDIFF_T */ #else #ifndef _PTRDIFF_T #define _PTRDIFF_T #include /* __darwin_ptrdiff_t */ typedef __darwin_ptrdiff_t ptrdiff_t; #endif /* _PTRDIFF_T */ #endif I'm thoroughly confused by this series of includes, especially as __need_ptrdiff_t is never used anywhere in the SDK.
[Bug fortran/116828] Gfortran 14.0.1 thinks that [ 1 + 1 = 0 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116828 --- Comment #1 from Jordan <8e3g6jay6 at mozmail dot com> --- Here's a simplified version that does the same: program oh_no use, intrinsic :: iso_c_binding implicit none integer(c_int) :: w w = 1 do w = w + w ! IT'S 0?! print*,w end do end program oh_no
[Bug fortran/116829] New: Missing default initialization of finalizable non-polymorphic intent(out) arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116829 Bug ID: 116829 Summary: Missing default initialization of finalizable non-polymorphic intent(out) arguments Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com Target Milestone: --- When a derived type dummy argument with intent(out) is finalizable (e.g. has a final subroutine), gfortran (at least as far back as GCC 9) triggers finalization on function entry but fails to default-initialize the argument afterwards, leaving it in the state where finalization left it. This is in violation of the Fortran standard, which specifies that subcomponents of intent(out) arguments should be default-initialized as usual (F2018 8.5.10 paragraph 3) and that finalization should occur right before that (7.5.6.3 paragraph 7). The following testcase reproduces the issue, printing the invalid value "42" instead of the expected "0" defined by the initializer: --- module MinimalIntentOutTestModule implicit none type :: AapType integer :: i = 0 contains final :: Finalizer end type contains subroutine Finalizer(self) type(AapType), intent(inout) :: self write(*,*) "in Finalizer:", self%i self%i = 42 ! Nobody should ever see this value after finalization end subroutine end module program uninit_intent_out_minimal use MinimalIntentOutTestModule implicit none type(AapType) :: aap aap%i = 1 call MakeAap(aap) contains subroutine MakeAap(a) type(AapType), intent(out) :: a write(*,*) "in MakeAap: ", a%i end subroutine end program - This only affects type(X) intent(out) dummy arguments; class(X) intent(out) arguments are initialized correctly. The bug seems to be in init_intent_out_dt(), which for non-polymorphic (DT_DERIVED) arguments forgets to call gfc_init_default_dt() if the symbol is finalizable. The initialization code is stored in sym->value by resolve_fl_variable_derived() called from resolve_symbol(), but without a call to gfc_init_default_dt() it is never assigned to the actual variable. Polymorphic arguments are unaffected because they use a slightly different path. Instead of resolve_fl_variable_derived() setting sym->value, resolve_symbol() will call apply_default_init() because sym->value is unset, which produces a GFC_INIT_ASSIGN. This is later translated to a memcpy of _def_init in the function body. init_intent_out_dt() then goes through the else-if branch and only adds a finalizer call because initialization is already taken care of.
[Bug fortran/101100] [12/13/14/15 Regression] ICE in trans_caf_token_assign, at fortran/trans-expr.c:9433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101100 --- Comment #7 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:0c0d79c783f5c289651d76aa697b48d4505e169d commit r15-3827-g0c0d79c783f5c289651d76aa697b48d4505e169d Author: Andre Vehreschild Date: Wed Sep 18 15:55:28 2024 +0200 Fortran: Allow to nullify caf token when not in ultimate component. [PR101100] gcc/fortran/ChangeLog: PR fortran/101100 * trans-expr.cc (trans_caf_token_assign): Take caf-token from decl for non ultimate coarray components. gcc/testsuite/ChangeLog: * gfortran.dg/coarray/proc_pointer_assign_1.f90: New test.
[Bug fortran/101100] [12/13/14/15 Regression] ICE in trans_caf_token_assign, at fortran/trans-expr.c:9433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101100 Andre Vehreschild changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED
[Bug fortran/116828] Gfortran 14.0.1 thinks that [ 1 + 1 = 0 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116828 --- Comment #2 from Jordan <8e3g6jay6 at mozmail dot com> --- I have actually examined this further and it seems like it's managing to perfectly overflow back to 0 somehow. I am not sure if there is supposed to be some sort of error or any kind of protection on overflowing integers though. I was wondering why I was so confused by this because I am running in debug mode and I was receiving 0 as my output. But I have checked and I have been getting warnings about integer limits and overflow protection in certain scenarios. But I am wondering why this is not causing an error stop or anything in this horrible scenario I have created. If there is a flag to error out and I have simply missed it, please, let me know.
[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 --- Comment #45 from Richard Biener --- I noticed that get_bitmask_from_range(tree_node*, generic_wide_int const&, generic_wide_int const&) is quite high on the profile accumulating profile hits on wide_int_storage::operator=(wide_int_storage const&) I wonder if irange_bitmask::irange_bitmask can be micro-optimized somehow for the case of a wi::zero 'value'? Likewise whether ::set_unknown in using assigns instead of inits like : m_value (..) makes a difference.
[Bug tree-optimization/116826] Optimise log (1.0 / x) into -log (x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116826 Jennifer Schmitz changed: What|Removed |Added Last reconfirmed||2024-09-24 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||jschmitz at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jschmitz at gcc dot gnu.org --- Comment #1 from Jennifer Schmitz --- .
[Bug middle-end/116815] Make better use of overflow flags in codegen of min/max(a, add/sub(a, b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116815 --- Comment #2 from ktkachov at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) > The easiest way to fix this is transform (late in gimple): > _1 = a_2(D) + b_3(D); > _5 = MAX_EXPR <_1, a_2(D)>; > > into: > _tmp = .ADD_OVERFLOW (a_2(D), b_3(D)); > _tmp1 = IMAGPART_EXPR <_tmp>; > _tmp2 = _tmp1 != 0; > _tmp3 = REALPART_EXPR <_tmp>; > _5 = _tmp2 ? _tmp3 : a_2(D); > > If we have addc support. > > Likewise the others. Which should be too hard to add to > tree-ssa-math-opts.cc with the other ADD_OVERFLOW optimizations. Did you meant to say "shouldn't be too hard" here?
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #316 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #314) > Can you please add the patch to your github branch? > I would like to ask some Dreamcast folks to try and test the GCC LRA branch > with some bigger real-world software. For that we need to have a "known > good state" of a branch on github. I've pushed the sfunc patch with lengthy sfunc patterns using hard_reg_r[456] + the patch in c#312 on the top of [59157] a revised patch to movsf issue which splits movesf_ie_ra [59158] a revised patch to QIHI extend/move [59153] Alex's patch works magically for call_pcrel* issue. as sh-lra-take3 branch of https://github.com/kazkojima/gcc.git. Hope this helps.
[Bug fortran/84870] [12/13/14/15 Regression][Coarray] ICE in gfc_trans_structure_assign, at fortran/trans-expr.c:7651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84870 --- Comment #11 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:f5035d7d015ebd4a7f5df5831cfc1269f9567e06 commit r15-3825-gf5035d7d015ebd4a7f5df5831cfc1269f9567e06 Author: Andre Vehreschild Date: Thu Sep 19 15:09:52 2024 +0200 Fortran: Assign allocated caf-memory to scalar members [PR84870] Allocating a coarray required an array-descriptor. For scalars a temporary descriptor was created. Assigning the allocated memory from the temporary descriptor back to the scalar is now added. gcc/fortran/ChangeLog: PR fortran/84870 * trans-array.cc (duplicate_allocatable_coarray): For scalar allocatable components the memory allocated is now assigned to the component's pointer. gcc/testsuite/ChangeLog: * gfortran.dg/coarray/alloc_comp_10.f90: New test.
[Bug tree-optimization/116819] [15 Regression] ICE in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116819 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Richard Biener --- I will have a look.
[Bug target/116822] [15 regression] RISC-V: ICE in compute_nregs_for_mode, at config/riscv/riscv-vector-costs.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116822 Richard Biener changed: What|Removed |Added Target||riscv Target Milestone|--- |15.0
[Bug fortran/84870] [12/13/14/15 Regression][Coarray] ICE in gfc_trans_structure_assign, at fortran/trans-expr.c:7651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84870 Andre Vehreschild changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Bug 83700 depends on bug 84870, which changed state. Bug 84870 Summary: [12/13/14/15 Regression][Coarray] ICE in gfc_trans_structure_assign, at fortran/trans-expr.c:7651 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84870 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #317 from John Paul Adrian Glaubitz --- (In reply to Kazumoto Kojima from comment #316) > (In reply to Oleg Endo from comment #314) > > Can you please add the patch to your github branch? > > I would like to ask some Dreamcast folks to try and test the GCC LRA branch > > with some bigger real-world software. For that we need to have a "known > > good state" of a branch on github. > > I've pushed the sfunc patch with lengthy sfunc patterns using > hard_reg_r[456] + the patch in c#312 on the top of > > [59157] a revised patch to movsf issue which splits movesf_ie_ra > [59158] a revised patch to QIHI extend/move > [59153] Alex's patch works magically for call_pcrel* issue. > > as sh-lra-take3 branch of https://github.com/kazkojima/gcc.git. Hope this > helps. Thanks. I'm going to test this now. It seems that the untested patch from comment #312 didn't fix the Ada bootstrap for me.
[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #43 from Richard Biener ---
Thanks for the work sofar. It seems the back_jt_path_registry::update_cfg
has a "dead" guard against un-adjust_paths_after_duplication paths with
its tracking visited_starting_edges, so for the purpose of limiting
complexity we can do sth like
diff --git a/gcc/tree-ssa-threadupdate.cc b/gcc/tree-ssa-threadupdate.cc
index c88cc1d6aac..88e7290db61 100644
--- a/gcc/tree-ssa-threadupdate.cc
+++ b/gcc/tree-ssa-threadupdate.cc
@@ -2292,8 +2292,11 @@ back_jt_path_registry::adjust_paths_after_duplication
(unsigned curr_path_num)
{
vec *curr_path = m_paths[curr_path_num];
- /* Iterate through all the other paths and adjust them. */
- for (unsigned cand_path_num = 0; cand_path_num < m_paths.length (); )
+ /* Iterate through all the other paths and adjust them.
+ ??? Limit the linear search so we do not run into quadratic
+ behavior (see PR114855). */
+ for (unsigned cand_path_num = 0;
+ cand_path_num < std::min (m_paths.length (), 1024u);)
{
if (cand_path_num == curr_path_num)
{
I measured no difference from disabling the merging (didn't try even
larger limits).
As for addressing the problem with "sorting", I think we should see to
order the jump threads in optimal order which should generally be RPO
of the entry edges and in case of multiple paths with the same entry
(the case adjust_paths_after_duplication is concerned with), we should
order those longest-to-shortes.
I believe all other order issues should be non-existent but we can end
up cancelling paths when we do the order wrong for same-entry paths.
Eventually adjusting the path_commpare sort function in your patch to
further order paths after e->dest->index and .length () would fix the
observed regressions.
Oddly your patch-set increases DOM time two-fold?
[Bug target/116076] 4.5% slowdown of 433.milc on AMD Zen4 since r15-2054-g1e3aa9c9278db6 shows faster operation with non-sensical target tuning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116076 Richard Biener changed: What|Removed |Added Target Milestone|15.0|--- Summary|[15 Regression] 4.5%|4.5% slowdown of 433.milc |slowdown of 433.milc on AMD |on AMD Zen4 since |Zen4 since |r15-2054-g1e3aa9c9278db6 |r15-2054-g1e3aa9c9278db6|shows faster operation with ||non-sensical target tuning --- Comment #5 from Richard Biener --- Let's keep it open as non-regression with amended Summary.
[Bug c++/116775] C++20 Coroutine await_suspend is unexpectedly executed when using in __builtin_constant_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116775 Jakub Jelinek changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- On the other side, perhaps completely ignoring CO_AWAIT_EXPR in there (dunno about others) might not be correct either, I guess the function is supposed to be still considered a coroutine. So perhaps it needs to be treated more like 0 && co_await ... or if (false) co_await ... or something similar. Also note there are other functions which ignore their argument side-effects, I think e.g. __builtin_classify_type does. And wonder about [[assume (co_await ...)]];
[Bug fortran/116828] Gfortran 14.0.1 thinks that [ 1 + 1 = 0 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116828 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- This is just user error, the program is invoking undefined behavior. If you build with -fsanitize=undefined, it is even diagnosed at runtime: /tmp/pr116828.f90:10:13: runtime error: signed integer overflow: 1073741824 * 2 cannot be represented in type 'integer(kind=4)' 0
[Bug ada/116832] New: Code after a select-then-abort in an abortable part executes when the outer select-then-abort completes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116832
Bug ID: 116832
Summary: Code after a select-then-abort in an abortable part
executes when the outer select-then-abort completes
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: liam at liampwll dot com
CC: dkm at gcc dot gnu.org
Target Milestone: ---
As shown by the code below, code after a select-then-abort in an abortable part
executes when the outer select-then-abort completes. This only occurs when B is
a protected object rather than a task. This is potentially related to bug
52280, which is still reproducible. This occurs on trunk, 14.2.1, and 8.2.
Other versions are untested.
with Ada.Text_IO; use Ada.Text_IO;
procedure Example is
task A is
entry A;
end A;
protected B is
entry B;
end B;
task body A is
begin
delay 3.0;
accept A;
end A;
protected body B is
entry B when False is
begin
Ada.Text_IO.Put_Line ("This correctly never executes.");
end B;
end B;
begin
select
A.A;
then abort
select
B.B;
then abort
B.B;
end select;
Ada.Text_IO.Put_Line ("This should be unreachable but it executes.");
end select;
end Example;
[Bug ada/116832] Code after a select-then-abort in an abortable part executes when the outer select-then-abort completes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116832 --- Comment #1 from Liam Powell --- s/bug 52280/bug 43485
[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 --- Comment #46 from jeremy rutman --- I don't know if this is relevant but a certain gcc I was using lately seems to do fine compiling one of the autogenerated files in question (an AES128 encrypt file) , but quits unexpectedly when I try compiling a second (the corresponding AES128 decrypt) version: gcc.exe (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project) 5.1.0 Copyright (C) 2015 Free Software Foundation, Inc. $ C\:/Program\ Files/ANSYS\ Inc/v241/SCADE/contrib/Msys64/mingw64/bin/gcc.exe -v -pedantic -Wall -Wextra -Wwrite-strings -g3 -I"C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\libraries\SC65\libmathext" -I"..\cryptol_aes" -I"..\cryptol_aes\dec" -I"..\cryptol_aes\enc" -I"." -I"C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\." -I"C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\include" -I"C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\include\C" -I"C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\include\Ada" -I"C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\lib\Ada" -pedantic -DBUILD_DLL -DSIM -DWIN32 -D_CONSOLE -D_MBCS -c -ansi -std=c99 -m64 "..\cryptol_aes\dec\aesDecrypt.c" -o "win64\aesDecrypt.o" Using built-in specs. COLLECT_GCC=C:\Program Files\ANSYS Inc\v241\SCADE\contrib\Msys64\mingw64\bin\gcc.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-5.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw510/x86_64-510-win32-sjlj-rt_v4-rev0/mingw64 --with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --enable-targets=all --enable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch-32=i686 --with-arch-64=nocona --with-tune-32=generic --with-tune-64=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw510/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw510/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw510/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw510/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-win32-sjlj-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw510/x86_64-510-win32-sjlj-rt_v4-rev0/mingw64/opt/include -I/c/mingw510/prerequisites/x86_64-zlib-static/include -I/c/mingw510/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw510/x86_64-510-win32-sjlj-rt_v4-rev0/mingw64/opt/include -I/c/mingw510/prerequisites/x86_64-zlib-static/include -I/c/mingw510/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw510/x86_64-510-win32-sjlj-rt_v4-rev0/mingw64/opt/lib -L/c/mingw510/prerequisites/x86_64-zlib-static/lib -L/c/mingw510/prerequisites/x86_64-w64-mingw32-static/lib ' Thread model: win32 gcc version 5.1.0 (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project) COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-Wwrite-strings' '-g3' '-I' 'C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\libraries\SC65\libmathext' '-I' '..\cryptol_aes' '-I' '..\cryptol_aes\dec' '-I' '..\cryptol_aes\enc' '-I' '.' '-I' 'C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.' '-I' 'C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\include' '-I' 'C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\include\C' '-I' 'C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\include\Ada' '-I' 'C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\lib\Ada' '-Wpedantic' '-D' 'BUILD_DLL' '-D' 'SIM' '-D' 'WIN32' '-D' '_CONSOLE' '-D' '_MBCS' '-c' '-ansi' '-std=c99' '-m64' '-o' 'win64\aesDecrypt.o' '-mtune=core2' '-march=nocona' C:/Program Files/ANSYS Inc/v241/SCADE/contrib/Msys64/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/cc1.exe -quiet -v -I C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\libraries\SC65\libmathext -I ..\cryptol_aes -I ..\cryptol_aes\dec -I ..\cryptol_aes\enc -I . -I C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\. -I C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\include -I C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\include\C -I C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\include\Ada -I C:\Program Files\ANSYS Inc\v241\SCADE\SCADE\.\lib\Ada -iprefix C:/Program Files/ANSYS Inc/v241/SCADE/contrib/Msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/ -dD -U_REENTRANT -D BUILD_DLL -D SIM -D WIN32 -D _CONSOLE -D _MBCS ..\cryptol_aes\dec\aesDecrypt.c -quiet -dumpbase aesDecrypt.c -m64 -mtune=core2 -march=nocona -auxbase-strip win64\aesDecrypt.o -g3 -Wall -Wextra -Wwrite-strings -Wpedantic -ansi -std=c99 -version -o C:
[Bug ada/116832] Code after a select-then-abort in an abortable part executes when the outer select-then-abort completes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116832
--- Comment #2 from Liam Powell ---
Here is another example I have found. In this case just one accept triggers
both selects. All Puts here are executed.
with Ada.Text_IO; use Ada.Text_IO;
with System;
procedure Example is
task A is
entry A;
end A;
task body A is
begin
delay 3.0;
accept A;
Ada.Text_IO.Put ("A");
end A;
begin
select
A.A;
Ada.Text_IO.Put ("B");
then abort
select
A.A;
Ada.Text_IO.Put ("C");
then abort
A.A;
end select;
Ada.Text_IO.Put ("D");
A.A;
end select;
end Example;
[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 --- Comment #47 from Sam James --- > gcc.exe (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project) 5.1.0 GCC 5 is long EOL, unfortunately.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #20 from Mark Mentovai --- Created attachment 59189 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59189&action=edit Patch for macOS 14/Xcode 16 (In reply to GCC Commits from comment #19) > The master branch has been updated by Iain D Sandoe : > > https://gcc.gnu.org/g:d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 > > commit r15-3839-gd9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 > Author: Iain Sandoe > Date: Sun Sep 22 11:43:32 2024 +0100 > > libgcc, Darwin: Drop the legacy library build for macOS >= 15 [PR116809]. Unfortunately, this doesn’t resolve the bug in every place that it might be encountered. The bootstrapping problem occurs when targeting x86_64 and using the macOS 15 SDK. The macOS 15 SDK ships in Xcode 16, which also runs on macOS 14. libgcc_s.1 can no longer be built on macOS 14 using Xcode 16 by the same logic that the above change disabled it for macOS 15.
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #7 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #6) > (In reply to Jonathan Wakely from comment #5) > > > #if defined(__has_feature) && __has_feature(modules) > > > > This is a bug. If __has_feature is _not_ define, then __has_feature(modules) > > would not compile > > Definitely agree, I had missed that, thanks for highlighting it. Every year > some more examples crop up into the SDKs, and every year I report them. > > Reported the examples in macOS 15.0 SDK as FB15255066 > A copy of that report is available there: > https://gist.github.com/fxcoudert/1e3ed3470febf220a392152189c143a3 > > > It looks like the header now assumes that if __has_feature(modules) is > > true, then they're compiling with Clang. Which is not true because GCC > > supports __has_feature now. > > Before I report this to Apple, I want to have an opinion: Iain, what do you > think is the best fix there? Do we want to suggest Apple not bypass > USE_CLANG_TYPES on GCC? At this point (with no other evidence) it would seem to me to be best if clang-specific stuff used __clang__ in the tests (we do _not_ set that in GCC, whereas testing __GNUC__ needs other checks to disambiguate). We might well want to reconcile or add pp defines to match the clang ones if that is creating problems - but I'd expect the underlying types to be unchanged (since that's going to break ABI otherwise). It's not clear to me yet why the change has been made (sorry this is not probably very helpful)
[Bug libgcc/116833] New: Symbian: incorrect configuration for crtfastmath.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116833
Bug ID: 116833
Summary: Symbian: incorrect configuration for crtfastmath.o
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: fedor_qd at mail dot ru
Target Milestone: ---
Here config from libgcc/config.host:
565 arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
566 tmake_file="${tmake_file} arm/t-arm arm/t-elf t-fixedpoint-gnu-prefix"
567 tm_file="$tm_file arm/bpabi-lib.h"
568 case ${host} in
569 arm*-*-eabi* | arm*-*-rtems*)
570 tmake_file="${tmake_file} arm/t-bpabi arm/t-sync t-crtfm"
571 extra_parts="crtbegin.o crtend.o crti.o crtn.o"
572 ;;
573 arm*-*-symbianelf*)
574 tmake_file="${tmake_file} arm/t-symbian t-slibgcc-nolc-override"
575 tm_file="$tm_file arm/symbian-lib.h"
576 # Symbian OS provides its own startup code.
577 ;;
578 esac
579 tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl arm/t-softfp t-softfp"
580 extra_parts="$extra_parts crtfastmath.o"
581 unwind_header=config/arm/unwind-arm.h
582 ;;
At line 570 t-crtfm says where look for crtfastmath.o. But it matters for
arm*-*-eabi* and arm*-*-rtems* targets only.
At line 580 declared additional dependency - crtfastmath.o without t-crtfm pair
in Symbian part.
That cause build error because location for crtfastmath.o not set.
As temporal solution I change line 580 to ‘ extra_parts="$extra_parts" ’ and
error gone. Builds was fine. Even libstdc++.a builded.
Pattern at line 580 widely used in libgcc/config.host. It’s was usual
copy-paste mistake. I notice that by accident.
I look closely at libgcc\config\arm\crtfastmath.c. It compiled if macro
__SOFTFP__ not defined. Symbian use softfp ABI for float numbers.
I build simple helloword with default options and some code:
#if __SOFTFP__
#pragma message "__SOFTFP__"
#endif
I got:
note: '#pragma message: __SOFTFP__'
Does GCC have crtfastmath.c for softfp ABI?
Proposed fix: change line 571 to
extra_parts="crtbegin.o crtend.o crti.o crtn.o crtfastmath.o"
and line 580 to:
extra_parts="$extra_parts"
[Bug target/116833] Symbian: incorrect configuration for crtfastmath.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116833 Andrew Pinski changed: What|Removed |Added Component|libgcc |target --- Comment #1 from Andrew Pinski --- More likely Symbian os support should be removed as I highly doubt anyone has tested it in the last 10 years.
[Bug target/116833] Symbian: incorrect configuration for crtfastmath.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116833
--- Comment #2 from Jonathan Wakely ---
On IRC rearnshaw said that t-crtfm should have been added to tmake_file when
crtfasthmath.o was added to extra_parts i.e.
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -579,7 +579,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
tm_file="$tm_file arm/bpabi-lib.h"
case ${host} in
arm*-*-eabi* | arm*-*-rtems*)
- tmake_file="${tmake_file} arm/t-bpabi arm/t-sync t-crtfm"
+ tmake_file="${tmake_file} arm/t-bpabi arm/t-sync"
extra_parts="crtbegin.o crtend.o crti.o crtn.o"
;;
arm*-*-symbianelf*)
@@ -588,7 +588,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
# Symbian OS provides its own startup code.
;;
esac
- tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl arm/t-softfp
t-softfp"
+ tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl arm/t-softfp
t-softfp t-crtfm"
extra_parts="$extra_parts crtfastmath.o"
unwind_header=config/arm/unwind-arm.h
;;
[Bug target/116833] Symbian: incorrect configuration for crtfastmath.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116833 --- Comment #3 from Andrew Pinski --- https://fedor4ever.wordpress.com/2024/09/22/gcc-14-1-0-for-symbian-out/
[Bug libstdc++/45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45896
--- Comment #13 from Jonathan Wakely ---
I noticed that time_get::_M_extract_via_format just ignores any O or E
modifier:
if (__c == 'E' || __c == 'O')
__c = __ctype.narrow(__format[++__i], 0);
So we treat %Ec exactly like %c and only use the D_T_FMT string, instead of
ERA_D_T_FMT:
case 'c':
// Default time and date representation.
const char_type* __dt[2];
__tp._M_date_time_formats(__dt);
__beg = _M_extract_via_format(__beg, __end, __io, __tmperr,
__tm, __dt[0], __state);
We should use __dt[1] when the modifier was 'E'.
The commit msg for Jakub's patch mentions these other unfixed things:
1) seems %j, %r, %U, %w and %W aren't handled (not sure if all of them
are already in POSIX 2009 or some are later)
2) I haven't touched the %y/%Y/%C and year handling stuff, that is
definitely not matching what POSIX 2009 says:
C All but the last two digits of the year {2}; leading zeros
shall be permitted but shall not be required. A leading '+' or '−' character
shall be permitted before
any leading zeros but shall not be required.
y The last two digits of the year. When format contains neither
a C conversion specifier nor a Y conversion specifier, values in the range
[69,99] shall refer to
years 1969 to 1999 inclusive and values in the range [00,68]
shall refer to years 2000 to 2068 inclusive; leading zeros shall be permitted
but shall not be re‐
quired. A leading '+' or '−' character shall be permitted before
any leading zeros but shall not be required.
Note: It is expected that in a future version of this
standard the default century inferred from a 2-digit year will change. (This
would apply to all commands
accepting a 2-digit year as input.)
Y The full year {4}; leading zeros shall be permitted but shall
not be required. A leading '+' or '−' character shall be permitted before any
leading zeros but
shall not be required.
I've tried to avoid making changes to _M_extract_num for these as well
to keep current status quo (the __len == 4 cases). One thing is what
to do for things with %C %y and/or %Y in the formats, another thing
is what to do in the methods that directly perform _M_extract_num
for year
3) the above question what to do for leading whitespace of any numbers
being parsed
4) the %p%I issue mentioned above and generally what to do if we
pass state and have finalizers at the end of parsing
5) _M_extract_via_format is also inconsistent with its callers on handling
the non-whitespace characters in between format specifiers, the caller
follows https://eel.is/c++draft/locale.time.get#members-8.6 and does
case insensitive comparison:
// TODO real case-insensitive comparison
else if (__ctype.tolower(*__s) == __ctype.tolower(*__fmt) ||
__ctype.toupper(*__s) == __ctype.toupper(*__fmt))
while _M_extract_via_format only compares exact characters:
// Verify format and input match, extract and discard.
if (__format[__i] == *__beg)
++__beg;
(another question is if there is a better way how to do real
case-insensitive comparison of 2 characters and whether we e.g. need
to handle the Turkish i/İ and ı/I which have different number of bytes
in UTF-8)
6) _M_extract_name does something weird for case-sensitivity,
// NB: Some of the locale data is in the form of all lowercase
// names, and some is in the form of initially-capitalized
// names. Look for both.
if (__beg != __end)
and
if (__c == __names[__i1][0]
|| __c == __ctype.toupper(__names[__i1][0]))
for the first letter while just
__name[__pos] == *__beg
on all the following letters. strptime says:
In case a text string (such as the name of a day of the week or a month
name) is to be matched, the comparison is case insensitive.
so supposedly all the _M_extract_name comparisons should be case
insensitive.
[Bug target/116833] [12/13/14/15 Regression] Symbian: incorrect configuration for crtfastmath.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116833 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|Symbian: incorrect |[12/13/14/15 Regression] |configuration for |Symbian: incorrect |crtfastmath.o |configuration for ||crtfastmath.o Last reconfirmed||2024-09-24 Target Milestone|--- |12.5 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Looks to be broken since r6-519-g5a0ff57c48cbae which is over 9 years ago.
[Bug target/116078] [15 Regression] 10-12% slowdown of 436.cactusADM on AMD Zen2 since r15-2187-g838999bb23303e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116078 Filip Kastl changed: What|Removed |Added CC||pault at gcc dot gnu.org Keywords|needs-bisection | Summary|[15 Regression] 10-12% |[15 Regression] 10-12% |slowdown of 436.cactusADM |slowdown of 436.cactusADM |on AMD Zen2 |on AMD Zen2 since ||r15-2187-g838999bb23303e --- Comment #1 from Filip Kastl --- Bisected to r15-2187-g838999bb23303e. Cc-ing the author.
[Bug middle-end/116815] Make better use of overflow flags in codegen of min/max(a, add/sub(a, b))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116815 --- Comment #3 from Andrew Pinski --- (In reply to ktkachov from comment #2) > Did you meant to say "shouldn't be too hard" here? Yes it should have been "Shouldn't be too hard". That is what you get for re-reading the comment 3 times and still not noticing the "not" missing.
[Bug target/116615] Investigate LOGICAL_OP_NON_SHORT_CIRCUIT for RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116615 --- Comment #13 from Andrew Pinski --- (In reply to Andrew Pinski from comment #12) > *** Bug 106724 has been marked as a duplicate of this bug. *** I forgot I had filed PR 106724 until I was looking for a different issue :).
[Bug target/106724] logical-op-non-short-circuit maybe should be 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106724 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 116615 ***
[Bug target/116615] Investigate LOGICAL_OP_NON_SHORT_CIRCUIT for RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116615 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #12 from Andrew Pinski --- *** Bug 106724 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/116826] Optimise log (1.0 / x) into -log (x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116826 --- Comment #2 from Andrew Pinski --- Note PR 86710 lists the opposite (except without being a CST for the division). Just like PR 86710, this applies for log, log10 and log2 too (and the type variants too).
[Bug c++/116775] C++20 Coroutine await_suspend is unexpectedly executed when using in __builtin_constant_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116775 --- Comment #6 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #4) > So, e.g. co_await_find_in_subtree/await_statement_expander/find_any_await > and maybe other coroutines.cc cp_walk_tree callbacks could use some helper > for CALL_EXPR and in that case if it is a BUILT_IN_CONSTANT_P call and the > argument has TREE_SIDE_EFFECTS, set *walk_subtrees = 0. that seems reasonable. (In reply to Jakub Jelinek from comment #5) > On the other side, perhaps completely ignoring CO_AWAIT_EXPR in there (dunno > about others) might not be correct either, I guess the function is supposed > to be still considered a coroutine. > So perhaps it needs to be treated more like 0 && co_await ... or if (false) > co_await ... or something similar. > Also note there are other functions which ignore their argument > side-effects, I think e.g. __builtin_classify_type does. > And wonder about [[assume (co_await ...)]]; A lot of these interactions are not spelled out (and were probably not really throught about much, I guess). I am not sure that an await_expression can be BUILT_IN_CONSTANT_P because its value is the output of awaiter.await_resume() - so that, even if awaiter.await_ready() is always true - there is still a function call to obtain the result. Having said that ... I wonder about constexpr on await_resume () [coroutines cannot be constexpr, but thay can contain constexpr].
[Bug c++/116490] ICE in build_contract_condition_function, at cp/contracts.cc:1463 for explicitly instantiated Function Contracts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116490 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ae57e52754ca6c96145a1b7504c2c7613a9e54d9 commit r15-3837-gae57e52754ca6c96145a1b7504c2c7613a9e54d9 Author: Nina Dinka Ranns Date: Fri Aug 30 13:49:07 2024 +0100 c++/contracts: ICE in build_contract_condition_function [PR116490] We currently do not expect comdat group of the guarded function to be set at the time of generating pre and post check function. However, in the case of an explicit instantiation, the guarded function has been added to a comdat group before generating contract check functions, which causes the observed ICE. Current assert removed and an additional check for comdat group of the guarded function added. With this change, the pre and post check functions get added to the same comdat group of the guarded function if the guarded function is already placed in a comdat group. PR c++/116490 gcc/cp/ChangeLog: * contracts.cc (build_contract_condition_function): added a check for comdat group of the guarded function. If set, the condition check function is added to the same comdat group. gcc/testsuite/ChangeLog: * g++.dg/contracts/pr116490.C: New test. Signed-off-by: Nina Ranns
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #318 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #317)
> Thanks. I'm going to test this now. It seems that the untested patch from
> comment #312 didn't fix the Ada bootstrap for me.
The issue unfortunately persists:
a-ngcefu.adb: In function 'Ada.Numerics.Complex_Elementary_Functions.Arccos':
a-ngcefu.adb:177:8: error: unable to find a register to spill
a-ngcefu.adb:177:8: error: this is the insn:
(insn 105 605 587 10 (parallel [
(set (reg:SF 499 [orig:184 _24 ] [184])
(reg:SF 513))
(use (reg:SI 154 fpscr0))
]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
(expr_list:REG_DEAD (reg:SF 513)
(nil)))
during RTL pass: reload
I'll try to get the preprocessed source.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #319 from John Paul Adrian Glaubitz --- Created attachment 59188 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59188&action=edit Preprocessed source from from comment #318
[Bug c++/115361] "possibly dangling reference to a temporary" when object is_empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115361 Jason Merrill changed: What|Removed |Added Known to work||15.0 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Last reconfirmed||2024-09-24 Ever confirmed|0 |1 Depends on||115987 Status|UNCONFIRMED |ASSIGNED Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115987 [Bug 115987] False "possibly dangling reference" false positive when having an extra template parameter
[Bug tree-optimization/116831] New: [15 Regression] ICE with trunk mod vectorising for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116831
Bug ID: 116831
Summary: [15 Regression] ICE with trunk mod vectorising for SVE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
long a;
int b, c;
void d(int e[][5], short f[][5][5][5]) {
for (short g; g; g += 4)
a = c ?: e[6][0] % b ? 0 : f[0][0][0][g];
}
-O3 -march=armv9-a
0x252429b internal_error(char const*, ...)
$SRC/gcc/diagnostic-global-context.cc:517
0x80fbff fancy_abort(char const*, int, char const*)
$SRC/gcc/diagnostic.cc:1512
0x7fdd1f poly_int<2u, unsigned long>::to_constant() const
$SRC/gcc/poly-int.h:592
0x158c287 poly_int<2u, unsigned long>::to_constant() const
$SRC/gcc/poly-int.h:590
0x158c287 nunits_for_known_piecewise_op
$SRC/gcc/tree-vect-generic.cc:96
0x158c287 expand_vector_piecewise
$SRC/gcc/tree-vect-generic.cc:290
0x158ee13 expand_vector_operation
$SRC/gcc/tree-vect-generic.cc:1257
0x158fdf7 expand_vector_operations_1
$SRC/gcc/tree-vect-generic.cc:2366
0x158fdf7 expand_vector_operations
$SRC/gcc/tree-vect-generic.cc:2400
0x158fdf7 execute
$SRC/gcc/tree-vect-generic.cc:2454
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/116831] [15 Regression] ICE with trunk mod vectorising for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116831 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |15.0 CC||jschmitz at gcc dot gnu.org Known to work||14.2.0 Known to fail||15.0
[Bug c/116735] ICE in build_counted_by_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116735 Sam James changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/116839] New: $fs:(%reg32) is used as memory operand for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116839
Bug ID: 116839
Summary: $fs:(%reg32) is used as memory operand for x32
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: lili.cui at intel dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-tgl-3 src]$ cat x.c
typedef long mpfr_prec_t;
typedef long mpfr_exp_t;
typedef struct {
mpfr_prec_t _mpfr_prec;
} __mpfr_struct;
typedef __mpfr_struct mpfr_t[1];
extern _Thread_local mpfr_exp_t __gmpfr_emax;
static _Thread_local mpfr_exp_t previous_emax;
static _Thread_local mpfr_t bound_emax;
extern const mpfr_t __gmpfr_const_log2_RNDD;
extern const mpfr_t __gmpfr_const_log2_RNDU;
typedef enum {
MPFR_RNDN=0,
MPFR_RNDZ,
MPFR_RNDU,
MPFR_RNDD,
MPFR_RNDA,
MPFR_RNDF,
MPFR_RNDNA=-1
} mpfr_rnd_t;
typedef __mpfr_struct *mpfr_ptr;
typedef const __mpfr_struct *mpfr_srcptr;
void mpfr_mul (mpfr_ptr, mpfr_srcptr, mpfr_rnd_t);
void
foo (void)
{
mpfr_exp_t saved_emax;
if (__gmpfr_emax != previous_emax)
{
saved_emax = __gmpfr_emax;
bound_emax->_mpfr_prec = 32;
mpfr_mul (bound_emax, saved_emax < 0 ?
__gmpfr_const_log2_RNDD : __gmpfr_const_log2_RNDU,
MPFR_RNDU);
previous_emax = saved_emax;
__gmpfr_emax = saved_emax;
}
}
[hjl@gnu-tgl-3 src]$ gcc -mtls-dialect=gnu2 -mx32 -O2 -fPIC -DPIC -S x.c
[hjl@gnu-tgl-3 src]$ grep cmp x.s
cmpl%fs:previous_emax@dtpoff(%eax), %r12d
[hjl@gnu-tgl-3 src]$
On x32, since address override works only on the (reg32) part in fs:(reg32),
we can't use it as memory operand.
[Bug c++/116838] Problem with warming c23, c++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116838 --- Comment #2 from Jamaika --- Thanks for the answer I don't know who's to blame. I created ffmpeg correcting the errors as best I could. FFmpeg is unstable. Obsolete codecs to be deleted in c23/c++23 aom/avm/open264/xvid Changing gcc 11.5.0 to 15.0.0 wasn't good idea but there is 'module' function in gnu++23. https://www.sendspace.com/file/qvcnac
[Bug tree-optimization/116826] Optimise log (1.0 / x) into -log (x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116826 --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #2) > Note PR 86710 lists the opposite (except without being a CST for the > division). > > Just like PR 86710, this applies for log, log10 and log2 too (and the type > variants too). Thanks for the reference. Yeah, splitting up one log call to two log calls is not a good idea for variable arguments, but when we can calculate the log (CST) at compile-time it should be a win.
