[Bug target/115949] [SH] unrecognized insn in postreload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115949 --- Comment #4 from Oleg Endo --- The issue seems to be that the 'movsi_ie' pattern allows 'mem(reg+disp) <-> fp-reg' load/stores through the predicates 'general_movdst_operand' and 'general_movsrc_operand' but then disallows it via the constraints. I guess once the whole thing arrives at this impossible operand combination, it has cornered itself -- it would require another register to compute the 'stack (r15) + offset' address, which it doesn't have. Perhaps it would be better to split out the FP-regs related things from the movsi_ie pattern. Another questionable point is why RA decides to use an FP reg for an SImode variable. The resulting code will be probably just terrible.
[Bug fortran/59104] 15 Regression - Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #17 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #16) > Created attachment 58717 [details] > Fix for the regression > > The mechanism in the original fix was OK but the use of the locus location > was not. I will investigate why this is the case but the attached works and > is very close to the first thing that I tried for the PR! > > It regtests fine. I will dejagnu-ify the testcase and will commit to > mainline in 24 hours, if I don't hear objections. I've just tested that fix and it works here. Fixes also the full module where I extracted the reproducer from. OK from my side. Thanks, Paul!
[Bug target/58416] Incorrect x87-based union copying code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #12 from Richard Biener --- I have two variants of a fix, one that for the testcase in comment#5 avoids scalarization on i?86-*-* and one that scalarizes into unsigned:96 which exposes that we fail to constant fold MEM[""]; On x86-64 with sizeof(long double) == 16 (instead of == 12 with -m32) we scalarize with uint128_t. I'm going to test the variant that avoids creating an unsigned:96 integer type since I think that's safer.
[Bug target/58416] Incorrect x87-based union copying code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416 --- Comment #13 from Richard Biener --- Created attachment 58718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58718&action=edit patch I am testing Paul - can you test if this patch resolves the emacs issue?
[Bug tree-optimization/93271] [12/13/14/15 regression] SRA producing wrong code on denormals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #19 from Richard Biener ---
My patch for PR58416 doesn't fix this because here the issue is we are creating
a load/store "no-op" move based on accesses that are never executed at runtime
since we're doing the re-materialization at places not related to the
scalar accesses.
I'll note this also causes UB by accessing a.b after a store to a.a (GCC
allows this as an extension).
If SRA would know we need to re-materialize an object at the time we do
analyze_access_subtree we could fix-up similar to PR58416, but I think
we don't know this.
So instead SRA should chose more optimal placement for the re-materializing
loads and stores using LCM. Note to be fully correct (never access when
it wasn't accessed in the untransformed code) it might need to emit multiple
copies for this.
We end up with
Access trees for a (UID: 2999):
access { base = (2999)'a', offset = 0, size = 32, expr = a.b, type = float,
reverse = 0, grp_read = 1, grp_write = 1, grp_assignment_read = 1,
grp_assignment_write = 1, grp_scalar_read = 1, grp_scalar_write = 1,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 1,
grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0}
while there's grp_assignment_read/write there's not the opposite
(grp_call_read/write), a flag to note we need re-materialization
after a store or before a read.
Note without a target hook telling whether we have a "true" FP load/store
instruction not SRAing in this case might pessimize quite some code(?)
[Bug target/116021] New: Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
Bug ID: 116021
Summary: Ada build on Darwin: gen_il-main: Symbol not found:
___builtin_nested_func_ptr_created
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: egallager at gcc dot gnu.org
CC: iains at gcc dot gnu.org
Target Milestone: ---
I was trying to figure this out with Iain on IRC the other day, but we never
managed to solve it, so I'm putting it here so it doesn't get lost:
Lately (as of r15-1899-g2b3027bea3f218) when I've been trying to build GCC with
Ada, I've been getting errors like the following:
mkdir -p ada/gen_il
cd ada/gen_il; gnatmake -q -g -gnata -gnat2012 -gnatw.g -gnatyg -gnatU
-I/Users/ericgallager/gcc_newgit/gcc/ada gen_il-main
# Ignore errors to work around finalization issues in older compilers
cd ada/gen_il; ./gen_il-main
dyld: lazy symbol binding failed: Symbol not found:
___builtin_nested_func_ptr_created
Referenced from:
/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build/gcc/ada/gen_il/./gen_il-main
Expected in:
/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build/./prev-gcc/libgcc_s.1.1.dylib
dyld: Symbol not found: ___builtin_nested_func_ptr_created
Referenced from:
/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build/gcc/ada/gen_il/./gen_il-main
Expected in:
/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build/./prev-gcc/libgcc_s.1.1.dylib
raised PROGRAM_ERROR : unhandled signal
make[3]: [ada/stamp-gen_il] Error 1 (ignored)
/Users/ericgallager/gcc_newgit/gcc/../move-if-change
ada/gen_il/seinfo_tables.ads ada/seinfo_tables.ads
mv: rename ada/gen_il/seinfo_tables.ads to ada/seinfo_tables.ads: No such file
or directory
make[3]: *** [ada/stamp-gen_il] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2
Apparently __builtin_nested_func_ptr_created has been renamed to
__gcc_nested_func_ptr_created in recent revisions, so I don't get why the build
process is still looking for the old name? Here's what shows up when I search
the repo for the common part shared between those strings:
$ git grep _nested_func_ptr_created
gcc/ChangeLog:rename the library fallbacks to
__gcc_nested_func_ptr_created and
gcc/ChangeLog:* doc/invoke.texi: Rename these to
__gcc_nested_func_ptr_created
gcc/builtins.def:DEF_EXT_LIB_BUILTIN (BUILT_IN_GCC_NESTED_PTR_CREATED,
"__gcc_nested_func_ptr_created", BT_FN_VOID_PTR_PTR_PTR, ATTR_NOTHROW_LIST)
gcc/config/darwin.h: -U ___gcc_nested_func_ptr_created \
gcc/config/darwin.h: -exported_symbol ___gcc_nested_func_ptr_created \
gcc/doc/invoke.texi:@code{__gcc_nested_func_ptr_created} and
gcc/tree.cc: local_define_builtin
("__builtin___gcc_nested_func_ptr_created", ftype,
gcc/tree.cc:"__gcc_nested_func_ptr_created",
ECF_NOTHROW);
libgcc/ChangeLog:(__gcc_nested_func_ptr_created): Implement a basic
trampoline
libgcc/ChangeLog:* libgcc2.h (__gcc_nested_func_ptr_created): Change
type of last
libgcc/ChangeLog:* config/i386/heap-trampoline.c
(__gcc_nested_func_ptr_created):
libgcc/ChangeLog:* config/aarch64/heap-trampoline.c
(__gcc_nested_func_ptr_created):
libgcc/ChangeLog:(__gcc_nested_func_ptr_created): Likewise.
libgcc/ChangeLog:(__gcc_nested_func_ptr_created): Likewise.
libgcc/ChangeLog:__builtin_nested_func_ptr_created to
__gcc_nested_func_ptr_created and
libgcc/ChangeLog:__gcc_nested_func_ptr_created and
libgcc/ChangeLog:* libgcc2.h (__builtin_nested_func_ptr_created):
Declare.
libgcc/config/aarch64/heap-trampoline.c:void __gcc_nested_func_ptr_created
(void *chain, void *func, void *dst);
libgcc/config/aarch64/heap-trampoline.c:__gcc_nested_func_ptr_created (void
*chain, void *func, void *dst)
libgcc/config/i386/heap-trampoline.c:void __gcc_nested_func_ptr_created (void
*chain, void *func, void *dst);
libgcc/config/i386/heap-trampoline.c:__gcc_nested_func_ptr_created (void
*chain, void *func, void *dst)
libgcc/libgcc-std.ver.in: __gcc_nested_func_ptr_created
libgcc/libgcc2.h:extern void __gcc_nested_func_ptr_created (void *, void *,
void *);
$
So, none of the Ada source files used to build gen_il-main contain references
to it... I'm wondering if it might be due to the version of gnatmake I'm using
to bootstrap? Here's its version info:
$ /usr/local/bin/gnatmake --version
GNATMAKE 14.0.0 20231204 (experimental) [master 2fde54ad7be]
Copyright (C) 1995-2023, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$
(and yes, I've al
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #1 from Iain Sandoe --- The problem with fixing this is that I cannot reproduce it; we are still trying to determine if there's some dependency on environment - or maybe something bizarre like the installed version of some utility like gawk etc. I can bootstrap and test all languages including Ada (on x86_64 darwin) using GCC-7.5, 10.5 and 11.4 - results on testresults@ (I've just done r15-2183-g58b78cf068b3 on x86_64-darwin21 under rosetta2 and on x86_64 darwin 23, 21 and 19 native). NOTE: my compiler builds and tests do not include any macports or homebrew components. The only additional content in my PATH is 1) texinfo-6.7 2) dejagnu and the bootstrap GCC installation (obv. needed for Ada). I would really like to resolve this before we issue 14.2-darwin (it's likely too late to fix anything on the release branch).
[Bug target/58416] Incorrect x87-based union copying code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416 --- Comment #14 from Richard Biener --- (In reply to Richard Biener from comment #13) > Created attachment 58718 [details] > patch I am testing > > Paul - can you test if this patch resolves the emacs issue? Using root->grp_same_access_path doesn't seem to be a perfect fit. For gcc.dg/tree-ssa/sra-6.c we're now doing Changing the type of a replacement for b offset: 0, size: 64 to an integer. But maybe that's OK or we need a different flag to tell whether the access paths are the same or just the tail of the access path, so 's' and 's.a' would be OK for a root 's.a.f', allowing aggregate (sub-)copies but that would assume we copy field-wise which we don't do - we RTL expand to (inlined) memcpy which is also not semantically the same for x87 float fields (but would it have to be?)
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #2 from Iain Sandoe --- (In reply to Iain Sandoe from comment #1) > NOTE: my compiler builds and tests do not include any macports or homebrew > components. The only additional content in my PATH is 1) texinfo-6.7 2) > dejagnu and the bootstrap GCC installation (obv. needed for Ada). FAOD: my dejagnu install is self-contained (it includes tcl+expect)... however it seems extremely unlikely that this is in any way related to a build issue.
[Bug c++/115434] Post contracts are ignored on functions with no return statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434 --- Comment #3 from Iain Sandoe --- fixed on trunk, not sure if we need to back port - but leaving open for now.
[Bug c++/110871] coroutine precondition should be evaluated before the initial suspend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871 --- Comment #2 from Iain Sandoe --- fixed on trunk, not sure if we need to back port, leaving open for now.
[Bug c++/110872] coroutine postcondition is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872 --- Comment #2 from Iain Sandoe --- fixed on trunk, not sure if we need to back port, leaving open for now.
[Bug c++/104981] [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981 Arsen Arsenović changed: What|Removed |Added CC||arsen at gcc dot gnu.org --- Comment #4 from Arsen Arsenović --- the latter seems OK to me - mind proposing a patch?
[Bug debug/96635] Feature request: PDB/Codeview support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635 --- Comment #4 from Mark Harmstone --- (In reply to Andrew Pinski from comment #2) > The patches to support CodeView is being added (and improved) for GCC 15. I > am not sure how much will be finished by the release of GCC 15. Support for C is very nearly finished. I hope to get all the C++ stuff (namespaces, templates, class member functions) done for GCC 15 too.
[Bug tree-optimization/116022] New: complete (early) unrolling foils vectorizer for vector initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116022
Bug ID: 116022
Summary: complete (early) unrolling foils vectorizer for vector
initialization
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amylaar at gcc dot gnu.org
Target Milestone: ---
#define LENGTH 4
typedef unsigned uint32v_t __attribute ((vector_size (LENGTH * 4)));
uint32v_t vdup_u32(uint32v_t a, unsigned b)
{
uint32v_t r;
int i;
for (i = 0; i < LENGTH; i++)
r[i] = b;
return r;
}
For x86_64-pc-linux-gnu, with -O1 -ftree-vectorize, we get:
vdup_u32:
.LFB0:
.cfi_startproc
movd%edi, %xmm1
pshufd $0, %xmm1, %xmm0
ret
which is fine.
However, with -O3, the complete unroller is run before the vectorizer, and
instead we get:
vdup_u32:
.LFB0:
.cfi_startproc
movd%edi, %xmm0
movd%edi, %xmm1
pshufd $225, %xmm0, %xmm0
movss %xmm1, %xmm0
pshufd $225, %xmm0, %xmm0
pshufd $198, %xmm0, %xmm0
movss %xmm1, %xmm0
pshufd $198, %xmm0, %xmm0
pshufd $39, %xmm0, %xmm0
movss %xmm1, %xmm0
pshufd $39, %xmm0, %xmm0
ret
making the code both larger and slower.
According to https://gcc.gnu.org/projects/tree-ssa/vectorization.htm , this was
supposed
to be handled by SLP, but apparently that is not happening.
See dump files produced by -fdump-tree-rebuild_frequencies -fdump-tree-cunrolli
-fdump-tree-vect
for details.
[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 --- Comment #9 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:91e468b72dafc9dcd5dcf7915f1d0ef172264d53 commit r15-2185-g91e468b72dafc9dcd5dcf7915f1d0ef172264d53 Author: Jeff Law Date: Sun Jul 21 07:36:37 2024 -0600 [PR rtl-optimization/115877] Fix livein computation for ext-dce So I'm not yet sure how I'm going to break everything down, but this is easy enough to break out as 1/N of ext-dce fixes/improvements. When handling uses in an insn, we first determine what bits are set in the destination which is represented in DST_MASK. Then we use that to refine what bits are live in the source operands. In the source operand handling section we *modify* DST_MASK if the source operand is a SUBREG (ugh!). So if the first operand is a SUBREG, then we can incorrectly compute which bit groups are live in the second operand, especially if it is a SUBREG as well. This was seen when testing a larger set of patches on the rl78 port (builtin-arith-overflow-p-7 & pr71631 execution failures), so no new test for this bugfix. Run through my tester (in conjunction with other ext-dce changes) on the various cross targets. Run individually through a bootstrap and regression test cycle on x86_64 as well. Pushing to the trunk. PR rtl-optimization/115877 gcc/ * ext-dce.cc (ext_dce_process_uses): Restore the value of DST_MASK for reach operand.
[Bug tree-optimization/116023] New: Failure to optimize (x+x)*(y+y) to (x*y)*4 when intermediate result is cast to larger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116023
Bug ID: 116023
Summary: Failure to optimize (x+x)*(y+y) to (x*y)*4 when
intermediate result is cast to larger type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int32_t mulx32(int32_t x, int32_t y)
{
uint64_t r1 = (uint64_t)(x + x) * (uint64_t)(y + y);
return r1;
}
This can be optimized to `return (x * y) * 4`. When compiling with `-O3`, this
transformation is done by LLVM, but not by GCC.
This seems related to the 64-bit casts and the use of a temporary variable, as
either changing the code to `return (uint64_t)((uint64_t)(x + x) * (uint64_t)(y
+ y))` or replacing all occurrences of `uint64_t` with `uint32_t` makes it so
the function is appropriately optimized.
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #3 from Andreas Schwab --- You need to use an older Ada compiler (13 or older) for bootstrapping, not any of the broken intermediate versions between Aug 2023 and Jan 2024.
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #43 from cqwrteur --- (In reply to Andrew Pinski from comment #42) > (In reply to frankhb1989 from comment #41) > > I ran into exact the same trouble of C23 missing symbols on old systems. In > > my case it is a custom build (with tailored source) of libfreeimage which > > has some calls to `sscanf` pulling the unwanted symbol references (to > > `__isoc23_sscanf@GLIBC_2.38`) into the library > > That is not a glibc issue but rather you are thinking glibc will be forwards > compatible; glibc is not and never can be; this is true for almost all OS > out there (Mac OS has a similar issue though they provide sysroots with all > needed headers/libraries so it is slightly easier to handle rather than you > need to go out and find one). It is definitely backwards compatiable. If you > want to build a program that runs on older systems you 100% need to use the > earliest version of glibc to link (and use headers from) against rather than > the newest version. This is completely BS. Old libc cannot build with the latest gcc since the script messed up. People end up stuck with old versions of C++ standards, which is unacceptable. If GNU folks continue f things up, I can guarantee you everyone will move to LLVM
[Bug ipa/116024] New: [14/15 Regression] unnecessary integer comparison(s) for a simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116024
Bug ID: 116024
Summary: [14/15 Regression] unnecessary integer comparison(s)
for a simple loop
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: artemiy at synopsys dot com
CC: jh at suse dot cz
Target Milestone: ---
Target: riscv32-unknown-elf
gcc 14 and later emits unnecessary instructions when compiling the i() function
in the following code:
$ cat test.i
# 0 "test.c"
# 0 ""
# 0 ""
# 1 "test.c"
typedef enum { a, b } c;
extern char d, e;
c f()
{
if (d)
return a;
d = e;
return b;
}
void i()
{
int l = 2;
while (l <= 2)
if (f() == a)
l++;
}
$ riscv32-unknown-elf-gcc test.i -S -O3 -fno-inline -Wall -Wextra
$ cat test.s
[snip]
i:
addisp,sp,-16
sw s0,8(sp)
sw s1,4(sp)
sw ra,12(sp)
li s1,3
li s0,2
.L6:
callf
sub a0,s1,a0
beq a0,s0,.L6
[snip]
gcc 13.2.0 doesn’t load any immediates and just emits a branch-if-not-zero:
[snip]
i:
addisp,sp,-16
sw ra,12(sp)
.L6:
callf
bne a0,zero,.L6
[snip]
I have bisected the introduction of this behavior down to:
commit 53ba8d669550d3a1f809048428b97ca607f95cf5
Author: Jan Hubicka
Date: Mon Nov 20 19:35:53 2023 +0100
inter-procedural value range propagation
I can't be too sure, but I think what ends up happening is that the ipa-cp pass
propagates the range of return values of f() ({0,1}), then later on phiopt2
uses this to expand the PHI node to something like 3 - f() == 2:
[local count: 955630224]:
# DEBUG BEGIN_STMT
_1 = f ();
_6 = (int) _1;
_8 = 3 - _6;
[local count: 1073741824]:
# l_2 = PHI <_8(3), 2(2)>
# DEBUG l => l_2
# DEBUG BEGIN_STMT
if (l_2 == 2)
goto ; [89.00%]
else
goto ; [11.00%]
And the aforementioned expression never gets simplified back to f() != 0,
resulting in more complicated assembly code. Indeed, specifying -fno-ipa-vrp
(or -fno-ssa-phiopt) works as a temporary workaround.
godbolt for convenience: https://godbolt.org/z/xr1oTrW51
gcc -v output:
$ riscv32-unknown-elf-gcc -v
Using built-in specs.
COLLECT_GCC=riscv32-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/home/art/work/install/riscv-gnu-toolchain/libexec/gcc/riscv32-unknown-elf/15.0.0/lto-wrapper
Target: riscv32-unknown-elf
Configured with: /home/art/work/src/gcc/configure --target=riscv32-unknown-elf
--prefix=/home/art/work/install/riscv-gnu-toolchain --disable-shared
--disable-threads --enable-languages=c,c++ --with-pkgversion=g80c37335baf
--with-system-zlib --enable-tls --with-newlib
--with-sysroot=/home/art/work/install/riscv-gnu-toolchain/riscv32-unknown-elf
--with-native-system-header-dir=/include --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libgomp --disable-nls
--disable-tm-clone-registry --src=/home/art/work/src/gcc --enable-multilib
--with-abi=ilp32 --with-arch=rv32gc --with-tune=rocket --with-isa-spec=20191213
'CFLAGS_FOR_TARGET=-Os' 'CXXFLAGS_FOR_TARGET=-Os'
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240721 (experimental) (g80c37335baf)
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #44 from cqwrteur --- (In reply to Andrew Pinski from comment #42) > (In reply to frankhb1989 from comment #41) > > I ran into exact the same trouble of C23 missing symbols on old systems. In > > my case it is a custom build (with tailored source) of libfreeimage which > > has some calls to `sscanf` pulling the unwanted symbol references (to > > `__isoc23_sscanf@GLIBC_2.38`) into the library > > That is not a glibc issue but rather you are thinking glibc will be forwards > compatible; glibc is not and never can be; this is true for almost all OS > out there (Mac OS has a similar issue though they provide sysroots with all > needed headers/libraries so it is slightly easier to handle rather than you > need to go out and find one). It is definitely backwards compatiable. If you > want to build a program that runs on older systems you 100% need to use the > earliest version of glibc to link (and use headers from) against rather than > the newest version. https://github.com/trcrsired/glibc/commit/4a724a45761fe27000247267d6ea02cb64b17b3c#diff-e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 My patch just works perfectly. Don't know what's your opposition. I am not even suggest an ABI lock down or something
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #45 from Andrew Pinski --- .
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|UNCONFIRMED --- Comment #46 from cqwrteur --- (In reply to Andrew Pinski from comment #45) > . Even Microsoft does this right with _WIN32_WINNT and _WIN32_WINDOWS macros etc, I don't know what's wrong with adding the similar mechanism for glibc.
[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 --- Comment #10 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:9d8ef2711dfecd093077aef6123d9e93ea23454e commit r15-2186-g9d8ef2711dfecd093077aef6123d9e93ea23454e Author: Jeff Law Date: Sun Jul 21 08:41:28 2024 -0600 [PR rtl-optimization/115877][2/n] Improve liveness computation for constant initialization While debugging pr115877, I noticed we were failing to remove the destination register from LIVENOW bitmap when it was set to a constant value. ie (set (dest) (const_int)). This was a trivial oversight in safe_for_live_propagation. I don't have an example of this affecting code generation, but it certainly could. More importantly, by making LIVENOW more accurate it's easier to debug when LIVENOW differs from expectations. As with the prior patch this has been tested as part of a larger patchset with the crosses as well as individually on x86_64. Pushing to the trunk, PR rtl-optimization/115877 gcc/ * ext-dce.cc (safe_for_live_propagation): Handle RTX_CONST_OBJ.
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #47 from Andrew Pinski --- Apple provides different sysroots for each (major) version of their OS to solve this issue. This is NOT a GCC issue nor this is a glibc issue. You can buld gcc against majority of old sysroot just fine. I have built against the trunk of gcc against a centos 6 sysroot before (actually I have built on the trunk after it started to require C++11 on a centos 6 machine too).
[Bug ipa/116024] [14/15 Regression] unnecessary integer comparison(s) for a simple loop since r14-5628-g53ba8d669550d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116024 --- Comment #1 from Andrew Pinski --- It is VRP which is going funny.
[Bug middle-end/116024] [14/15 Regression] unnecessary integer comparison(s) for a simple loop since r14-5628-g53ba8d669550d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116024 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org Component|ipa |middle-end --- Comment #2 from Sam James --- sorry, I hadn't seen you'd changed component
[Bug c++/116015] ICE in replace_placeholders_r for simple default member initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116015
--- Comment #3 from Pieter P ---
A temporary workaround is to wrap the default value in an immediately invoked
lambda:
struct Widget {
int n = 5;
Matrix A = [this] { return Matrix{{.rows = n}}; }();
};
[Bug rtl-optimization/115877] [15 Regression] wrong code at -Os (missing zero extension)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877 Sam James changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/116024] [14/15 Regression] unnecessary integer comparison(s) for a simple loop since r14-5628-g53ba8d669550d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116024 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Blocks|85316 | Last reconfirmed||2024-07-21 CC|hubicka at gcc dot gnu.org,|pinskia at gcc dot gnu.org |jh at suse dot cz | Component|middle-end |tree-optimization Target Milestone|--- |14.2 --- Comment #3 from Andrew Pinski --- Note I don't think IPA is the issue of exporting (correctly) the return value range. The problem is VRP decides to create `a == 0 ? 2 : 3` which gets converted into `3 - a` (which then vrp again converts into `a == 0 ? 2 : 3`). But then `(3 - a) == 2` is never optimized to just `a == 0` by match or something else. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #48 from Arsen Arsenović --- Please stop resetting the bug status. You create unneeded churn. This bug is invalid. (In reply to cqwrteur from comment #43) > This is completely BS. Old libc cannot build with the latest gcc since the > script messed up. People end up stuck with old versions of C++ standards, > which is unacceptable. If GNU folks continue f things up, I can guarantee > you everyone will move to LLVM Fix the build script then, rather than breaking the compiler. (In reply to cqwrteur from comment #44) > https://github.com/trcrsired/glibc/commit/ > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff- > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 > > My patch just works perfectly. Don't know what's your opposition. I am not > even suggest an ABI lock down or something "WFM" is a dangerous and broken mindset that cannot be applied here. The patch above is a nonsense hack in the libc.
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #49 from cqwrteur --- (In reply to Andrew Pinski from comment #47) > Apple provides different sysroots for each (major) version of their OS to > solve this issue. This is NOT a GCC issue nor this is a glibc issue. You can > buld gcc against majority of old sysroot just fine. I have built against the > trunk of gcc against a centos 6 sysroot before (actually I have built on the > trunk after it started to require C++11 on a centos 6 machine too). I need to do Canadian compilation. I cannot install centos and I don't want eithert
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #50 from cqwrteur --- (In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS. Old libc cannot build with the latest gcc since the > > script messed up. People end up stuck with old versions of C++ standards, > > which is unacceptable. If GNU folks continue f things up, I can guarantee > > you everyone will move to LLVM > Fix the build script then, rather than breaking the compiler. > > (In reply to cqwrteur from comment #44) > > https://github.com/trcrsired/glibc/commit/ > > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff- > > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 > > > > My patch just works perfectly. Don't know what's your opposition. I am not > > even suggest an ABI lock down or something > "WFM" is a dangerous and broken mindset that cannot be applied here. The > patch above is a nonsense hack in the libc. How is that a nonsense hack? It just works by forcing the version to be stabilized as 2.34.
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #51 from cqwrteur --- (In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS. Old libc cannot build with the latest gcc since the > > script messed up. People end up stuck with old versions of C++ standards, > > which is unacceptable. If GNU folks continue f things up, I can guarantee > > you everyone will move to LLVM > Fix the build script then, rather than breaking the compiler. > > (In reply to cqwrteur from comment #44) > > https://github.com/trcrsired/glibc/commit/ > > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff- > > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 > > > > My patch just works perfectly. Don't know what's your opposition. I am not > > even suggest an ABI lock down or something > "WFM" is a dangerous and broken mindset that cannot be applied here. The > patch above is a nonsense hack in the libc. Again I do not do native compilation for linux. Do you understand? I do not native compile linux binaries. I always build linux binaries on windows
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #52 from cqwrteur --- (In reply to Andrew Pinski from comment #47) > Apple provides different sysroots for each (major) version of their OS to > solve this issue. This is NOT a GCC issue nor this is a glibc issue. You can > buld gcc against majority of old sysroot just fine. I have built against the > trunk of gcc against a centos 6 sysroot before (actually I have built on the > trunk after it started to require C++11 on a centos 6 machine too). Apple? No wonder why apple bs cannot take over windows because only Microsoft does this right
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #53 from cqwrteur --- (In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS. Old libc cannot build with the latest gcc since the > > script messed up. People end up stuck with old versions of C++ standards, > > which is unacceptable. If GNU folks continue f things up, I can guarantee > > you everyone will move to LLVM > Fix the build script then, rather than breaking the compiler. > > (In reply to cqwrteur from comment #44) > > https://github.com/trcrsired/glibc/commit/ > > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff- > > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 > > > > My patch just works perfectly. Don't know what's your opposition. I am not > > even suggest an ABI lock down or something > "WFM" is a dangerous and broken mindset that cannot be applied here. The > patch above is a nonsense hack in the libc. https://news.ycombinator.com/item?id=32471624 Everyone disagrees with gnu's policy here. Even linus torvalds disagrees
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #54 from cqwrteur --- (In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS. Old libc cannot build with the latest gcc since the > > script messed up. People end up stuck with old versions of C++ standards, > > which is unacceptable. If GNU folks continue f things up, I can guarantee > > you everyone will move to LLVM > Fix the build script then, rather than breaking the compiler. > > (In reply to cqwrteur from comment #44) > > https://github.com/trcrsired/glibc/commit/ > > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff- > > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 > > > > My patch just works perfectly. Don't know what's your opposition. I am not > > even suggest an ABI lock down or something > "WFM" is a dangerous and broken mindset that cannot be applied here. The > patch above is a nonsense hack in the libc. https://www.youtube.com/watch?v=5PmHRSeA2c8&t=283s
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #55 from Andrew Pinski --- https://en.wikipedia.org/wiki/Forward_compatibility
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|UNCONFIRMED --- Comment #56 from cqwrteur --- (In reply to Andrew Pinski from comment #55) > https://en.wikipedia.org/wiki/Forward_compatibility This has nothing to do with forward compatibility. This is about satisfying C++ standard.
[Bug c/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930 Sam James changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||14.1.1, 15.0 --- Comment #10 from Sam James --- .
[Bug c/115502] [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227) since r15-934-gd2cfe8a73b3c41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115502 Sam James changed: What|Removed |Added Known to work||14.1.1, 15.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Sam James --- .
[Bug c/115502] [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227) since r15-934-gd2cfe8a73b3c41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115502 Bug 115502 depends on bug 114930, which changed state. Bug 114930 Summary: [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Arsen Arsenović changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #57 from Arsen Arsenović --- (In reply to cqwrteur from comment #51) > Again I do not do native compilation for linux. Do you understand? I do not > native compile linux binaries. I always build linux binaries on windows I do not see the relevance of this. You need to link and compile against some libraries and headers whereever you compile. Just use older libraries and headers. (In reply to cqwrteur from comment #49) > I need to do Canadian compilation. I cannot install centos and I don't want > eithert Nor do you need to. This was said to point out that you can use quite old systems to build GCC. Nothing about CentOS in particular is relevant. (In reply to cqwrteur from comment #50) > How is that a nonsense hack? It just works by forcing the version to be > stabilized as 2.34. No, it doesn't. It happens to coincidentally work by removing a feature test macro. The fact the result is non-obvious from the patch body corroborates what I said. (In reply to cqwrteur from comment #53) > This has nothing to do with forward compatibility. This is about satisfying > C++ standard. It has only to do with forwards compatibility. You're downgrading a library and expecting it to work. It will not without forwards compatibility. Nobody provides forwards compatibility for libraries for obvious reasons. Please stop spamming the bug tracker now.
[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007 A. Wilcox (awilfox) changed: What|Removed |Added CC||awilfox at adelielinux dot org --- Comment #9 from A. Wilcox (awilfox) --- There is no musl that supports IBM double-double, and there is no plan to ever support this upstream. There is a patch set circulating around for musl that adds IEEE binary128 support (requiring ISA 3.0), but it is not yet upstream because they are deciding what to name the ABI. (the proposed name as powerpc64_f128 but it wasn't accepted that way.) I have just run into this trying to build trunk on ppc64-musl without explicitly passing --enable-libquadmath: * /bin/sh /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure --host=powerpc64-gentoo-linux-musl --build=powerpc64-gentoo-linux-musl --prefix=/usr --bindir=/usr/powerpc64-gentoo-linux-musl/gcc-bin/15 --includedir=/usr/lib/gcc/powerpc64-gentoo-linux-musl/15/include --datadir=/usr/share/gcc-data/powerpc64-gentoo-linux-musl/15 --mandir=/usr/share/gcc-data/powerpc64-gentoo-linux-musl/15/man --infodir=/usr/share/gcc-data/powerpc64-gentoo-linux-musl/15/info --with-gxx-include-dir=/usr/lib/gcc/powerpc64-gentoo-linux-musl/15/include/g++-v15 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/powerpc64-gentoo-linux-musl/15/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --disable-libunwind-exceptions --enable-checking=yes,extra --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo Hardened 15.0. p, commit b1a31eaaeae90d7b7774bfb45f9954dc586f4dea --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-multilib --disable-fixed-point --with-abi=elfv2 --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --without-isl --disable-libsanitizer --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes [...] /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libquadmath/math/../../libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF' 69 | typedef float TFtype __attribute__ ((mode (TF))); | ^~~ make[3]: *** [Makefile:984: math/sqrtq.lo] Error 1 Does --disable-libquadmath need to be explicitly passed on ppc64-musl systems that are not using the musl "f128" patches?
[Bug fortran/59104] 15 Regression - Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #18 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:838999bb23303edc14e96b6034cd837fa4454cfd commit r15-2187-g838999bb23303edc14e96b6034cd837fa4454cfd Author: Paul Thomas Date: Sun Jul 21 17:48:47 2024 +0100 Fortran: Fix regression caused by r14-10477 [PR59104] 2024-07-21 Paul Thomas gcc/fortran PR fortran/59104 * gfortran.h : Add decl_order to gfc_symbol. * symbol.cc : Add static next_decl_order.. (gfc_set_sym_referenced): Set symbol decl_order. * trans-decl.cc : Include dependency.h. (decl_order): Replace symbol declared_at.lb->location with decl_order. gcc/testsuite/ PR fortran/59104 * gfortran.dg/dependent_decls_3.f90: New test.
[Bug tree-optimization/116024] [14/15 Regression] unnecessary integer comparison(s) for a simple loop since r14-5628-g53ba8d669550d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116024
--- Comment #4 from Andrew Pinski ---
So the missed optimizations that VRP/PHIopt/match expose are:
```
unsigned f(void);
int i1(void)
{
int l = 2;
l = 3 - (int)f();
return l <= 2; // f() > 0
}
int i2(void)
{
unsigned l = 2;
l = 3 - (unsigned)f();
return l <= 2; // f() - 1 < 3
}
int i3(void)
{
unsigned l = 2;
l = 3 + (unsigned)f();
return l <= 2; // f() > -4u
}
int i4(void)
{
int l = 2;
l = 3 + (int)f();
return l <= 2; // f() < 0
}
```
This can be done even without knowing the range of `f()` here. and these is
done by clang already. Note GCC does handle i4 is already.
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 Paul Thomas changed: What|Removed |Added Summary|15 Regression - Wrong |Wrong result with SIZE |result with SIZE|specification expression |specification expression| --- Comment #19 from Paul Thomas --- OK the regression is fixed - thanks for the green light, Harald. It's a pity that I have missed the 4.2 release :-( Paul
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #20 from Paul Thomas --- OK the regression is fixed - thanks for the green light, Harald. It's a pity that I have missed the 4.2 release :-( Paul
[Bug tree-optimization/116022] complete (early) unrolling foils vectorizer for vector initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116022 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 93237. *** This bug has been marked as a duplicate of bug 93237 ***
[Bug tree-optimization/93237] vector defined using inserts is not converted into constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93237 Andrew Pinski changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 116022 has been marked as a duplicate of this bug. ***
[Bug c++/104981] [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981 --- Comment #5 from Iain Sandoe --- (In reply to Arsen Arsenović from comment #4) > the latter seems OK to me - mind proposing a patch? I am planning on doing some rework on the ramp code-gen in the (very) near future - so can pick this up on the way (unless Patrick has already done it ... )
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #21 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #20) > OK the regression is fixed - thanks for the green light, Harald. > > It's a pity that I have missed the 4.2 release :-( > > Paul It is more important that 14.2 gets regression-free out of the door. Unfortunately I test my codes less with trunk than with the latest release branch, otherwise I would have discovered the issue in comment#12 earlier. It takes too much time to regularly rebuild a larger software stack with trunk on my notebook, so I normally do this later in the development cycle. Just did that, and it seems to look good. :-) Anyway, the complete fix for this PR still looks like a candidate for 14-branch to me, maybe for a more quiet time with sufficient distance to release dates... Thanks for the quick reaction and the fix on trunk! Harald
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 --- Comment #18 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:ae6d5dc35735168c13f4599e7cf3f32fbb3c06c9 commit r13-8930-gae6d5dc35735168c13f4599e7cf3f32fbb3c06c9 Author: Harald Anlauf Date: Thu Jul 18 21:15:48 2024 +0200 Fortran: character array constructor with >= 4 constant elements [PR103115] gcc/fortran/ChangeLog: PR fortran/103115 * trans-array.cc (gfc_trans_array_constructor_value): If the first element of an array constructor is deferred-length character and therefore does not have an element size known at compile time, do not try to collect subsequent constant elements into a constructor for optimization. gcc/testsuite/ChangeLog: PR fortran/103115 * gfortran.dg/string_array_constructor_4.f90: New test. (cherry picked from commit c93be1606ecf8e0f65b96b67aa023fb456ceb3a3)
[Bug fortran/116025] New: Experimental implementation of unsigned integers for Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116025 Bug ID: 116025 Summary: Experimental implementation of unsigned integers for Fortran Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- https://j3-fortran.org/doc/year/24/24-116.txt has a proposal, accepted by J3, to implement unsigned integers for Fortran. I'll try to work on this a bit, probably on a development branch, and see how far I get.
[Bug fortran/116025] Experimental implementation of unsigned integers for Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116025 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Last reconfirmed||2024-07-21
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 --- Comment #19 from GCC Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:ecc80e18f05b77a773c6d894871572029d4fc579 commit r12-10631-gecc80e18f05b77a773c6d894871572029d4fc579 Author: Harald Anlauf Date: Thu Jul 18 21:15:48 2024 +0200 Fortran: character array constructor with >= 4 constant elements [PR103115] gcc/fortran/ChangeLog: PR fortran/103115 * trans-array.cc (gfc_trans_array_constructor_value): If the first element of an array constructor is deferred-length character and therefore does not have an element size known at compile time, do not try to collect subsequent constant elements into a constructor for optimization. gcc/testsuite/ChangeLog: PR fortran/103115 * gfortran.dg/string_array_constructor_4.f90: New test. (cherry picked from commit c93be1606ecf8e0f65b96b67aa023fb456ceb3a3)
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #20 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15, and backported to all open branches. Closing. Thanks for the report!
[Bug tree-optimization/116023] Failure to optimize (x+x)*(y+y) to (x*y)*4 when intermediate result is cast to larger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116023 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug sanitizer/116026] New: Copying or moving a std::variant that can be a vector causes a maybe-uninitialized warning with -fsanitize=address -Og -finline-functions-called-once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116026
Bug ID: 116026
Summary: Copying or moving a std::variant that can be a vector
causes a maybe-uninitialized warning with
-fsanitize=address -Og -finline-functions-called-once
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.r.gracia at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
How to reproduce:
> cat code.cpp
#include
#include
extern "C" int printf(const char *, ...);
using node = std::variant, int>;
int main() {
int a{15};
[[maybe_unused]] node b = a;// line 1
// printf("%d", std::get(b)); // line 2
}
> g++ -Werror=maybe-uninitialized -fsanitize=address -Og
> -finline-functions-called-once code.cpp
In file included from /usr/include/c++/14.1.1/vector:66,
from code.cpp:2:
In destructor ‘std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp = int;
_Alloc = std::allocator]’,
inlined from ‘std::vector<_Tp, _Alloc>::~vector() [with _Tp = int; _Alloc =
std::allocator]’ at /usr/include/c++/14.1.1/bits/stl_vector.h:738:7,
inlined from ‘constexpr void std::_Destroy(_Tp*) [with _Tp = vector]’
at /usr/include/c++/14.1.1/bits/stl_construct.h:151:22,
inlined from ‘std::__detail::__variant::_Variant_storage >, int>::_M_reset()::
mutable [with auto:1 = std::vector&]’ at
/usr/include/c++/14.1.1/variant:498:19,
inlined from ‘constexpr _Res std::__invoke_impl(__invoke_other, _Fn&&,
_Args&& ...) [with _Res = void; _Fn =
__detail::__variant::_Variant_storage >,
int>::_M_reset()::; _Args = {vector >&}]’
at /usr/include/c++/14.1.1/bits/invoke.h:61:36,
inlined from ‘constexpr std::enable_if_t<((bool)is_invocable_r_v<_Res,
_Callable, _Args ...>), _Res> std::__invoke_r(_Callable&&, _Args&& ...) [with
_Res = void; _Callable = __detail::__variant::_Variant_storage >, int>::_M_reset()::; _Args =
{vector >&}]’ at
/usr/include/c++/14.1.1/bits/invoke.h:111:28,
inlined from ‘static constexpr decltype(auto)
std::__detail::__variant::__gen_vtable_impl, std::integer_sequence >::__visit_invoke(_Visitor&&, _Variants ...) [with _Result_type
= void; _Visitor = std::__detail::__variant::_Variant_storage >, int>::_M_reset()::&&;
_Variants = {std::variant >, int>&}; long
unsigned int ...__indices = {0}]’ at /usr/include/c++/14.1.1/variant:1064:40,
inlined from ‘constexpr decltype(auto) std::__do_visit(_Visitor&&,
_Variants&& ...) [with _Result_type = void; _Visitor =
__detail::__variant::_Variant_storage >,
int>::_M_reset()::; _Variants = {variant >, int>&}]’ at /usr/include/c++/14.1.1/variant:1816:5,
inlined from ‘constexpr void
std::__detail::__variant::_Variant_storage::_M_reset() [with
_Types = {std::vector >, int}]’ at
/usr/include/c++/14.1.1/variant:496:23,
inlined from ‘std::__detail::__variant::_Variant_storage::~_Variant_storage() [with _Types = {std::vector
>, int}]’ at /usr/include/c++/14.1.1/variant:506:17,
inlined from ‘std::__detail::__variant::_Copy_ctor_base >, int>::~_Copy_ctor_base()’ at
/usr/include/c++/14.1.1/variant:581:12,
inlined from ‘std::__detail::__variant::_Move_ctor_base >, int>::~_Move_ctor_base()’ at
/usr/include/c++/14.1.1/variant:618:12,
inlined from ‘std::__detail::__variant::_Copy_assign_base >, int>::~_Copy_assign_base()’ at
/usr/include/c++/14.1.1/variant:656:12,
inlined from ‘std::__detail::__variant::_Move_assign_base >, int>::~_Move_assign_base()’ at
/usr/include/c++/14.1.1/variant:708:12,
inlined from ‘std::__detail::__variant::_Variant_base >, int>::~_Variant_base()’ at
/usr/include/c++/14.1.1/variant:762:12,
inlined from ‘std::variant<_Types>::~variant() [with _Types =
{std::vector >, int}]’ at
/usr/include/c++/14.1.1/variant:1435:28,
inlined from ‘int main()’ at code.cpp:12:1:
/usr/include/c++/14.1.1/bits/stl_vector.h:369:31: error:
‘*(std::_Vector_base >*)((char*)&b +
offsetof(std::node, std::variant >,
int>::.std::__detail::__variant::_Variant_base >,
int>::.std::__detail::__variant::_Move_assign_base >,
int>::.std::__detail::__variant::_Copy_assign_base >,
int>::.std::__detail::__variant::_Move_ctor_base >,
int>::.std::__detail::__variant::_Copy_ctor_base >,
int>::.std::__detail::__variant::_Variant_storage >, int>::_M_u)).std::_Vector_base >::_M_impl.std::_Vector_base
>::_Vector_impl::std::_Vector_base
>::_Vector_impl_data.std::_Vector_base
>::_Vector_impl_data::_M_end_of_storage’ may be used uninitialized
[-Werror=maybe-uninitialized]
369 | _M_impl._M_end_of_storage - _M_impl._M_start);
| ^
code.cpp: In function ‘int main()’:
code.cpp:10:27: note: ‘b’ declared here
10
[Bug sanitizer/116026] Copying or moving a std::variant that can be a vector causes a maybe-uninitialized warning with -fsanitize=address -Og -finline-functions-called-once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116026 --- Comment #1 from Andrew Pinski --- Note the documentation warns about this case https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Instrumentation-Options.html#index-fsanitize_003daddress Note that sanitizers tend to increase the rate of false positive warnings, most notably those around -Wmaybe-uninitialized. We recommend against combining -Werror and [the use of] sanitizers.
[Bug debug/96635] Feature request: PDB/Codeview support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635 --- Comment #5 from Eric Gallager --- (In reply to Mark Harmstone from comment #4) > (In reply to Andrew Pinski from comment #2) > > The patches to support CodeView is being added (and improved) for GCC 15. I > > am not sure how much will be finished by the release of GCC 15. > > Support for C is very nearly finished. I hope to get all the C++ stuff > (namespaces, templates, class member functions) done for GCC 15 too. OK to put you as the assignee for this?
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #4 from Eric Gallager --- (In reply to Andreas Schwab from comment #3) > You need to use an older Ada compiler (13 or older) for bootstrapping, not > any of the broken intermediate versions between Aug 2023 and Jan 2024. I wonder if maybe there could be a configure check added for whether the Ada compiler is broken or not? Maybe one of the Ada maintainers could chime in?
[Bug debug/96635] Feature request: PDB/Codeview support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635 --- Comment #6 from Mark Harmstone --- (In reply to Eric Gallager from comment #5) > OK to put you as the assignee for this? Of course
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Why? The development versions isn't something meant for long time use, one should be prepared to upgrade that to newer snapshots and/or upcoming stable release. There can be major bugs in those, ABI incompatibilities like this, ...
[Bug debug/96635] Feature request: PDB/Codeview support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mark at harmstone dot com Last reconfirmed||2024-07-22 Ever confirmed|0 |1
[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #10 from Rich Felker --- musl uses ld64 for all powerpc targets because the ABI was designed when compiler support for IEEE quad was not widespread, with an intent of supporting existing compilers rather than requiring recent ones. Since presumably libquadmath builds fine on other targets where ld is not ieee quad or IBM double-double, I'm assuming it must be target-specific code that's failing. Could libquadmath just fallback to using generic arch-agnostic code on targets (including musl) where ld is not one of the currently supported ones?
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andrew Pinski --- This is a won't fix. Using an unreleased compiler before the ABI change to do a bootstrap is not supported. There was a flag day in this case where it would break. any before that date but after the day which added the option to use heap based trampolines is not supported for bootstrap after that day. Only ones without heap based trampolines and the ones with the supported ABI.
[no subject]
สำหรับเจ้าของกิจการ ที่มี Project ต่อยอดเพิ่มกำไรให้ธุรกิจ แต่ยังหาทุนทรัพย์ไม่ทัน ✔️เจ้าของธุรกิจที่มีการจดทะเบียน ใบประกอบกิจการ ✔️อนุมัติสูงสุด 5,000,000 บาท ✔️ไม่เช็คเครดิต บูโรเอกสารไม่ยุ่งยาก ไม่ต้องมีบุคคลค้ำประกัน ✔️อัตราดอกเบี้ยเริ่มต้น1.5% ✔️ตัดต้นลดดอกเบี้ยทันที ถ้าท่านสนใจบริการของเรา โทรด่วนหาเรา ☎️ 0936782499 คุณตะวัน ☎️ 0825928519 คุณเอก Line ID : esc.credit (ให้เราเป็นส่วนหนึ่งในครอบครับท่านนะครับ)
[Bug target/108699] gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108699 --- Comment #10 from GCC Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:913bab282d95e842907fec5a552a74ef64a6d4f6 commit r15-2190-g913bab282d95e842907fec5a552a74ef64a6d4f6 Author: Sam James Date: Sun Jul 21 20:36:08 2024 -0500 testsuite: powerpc: fix dg-do run typo 'dg-run' is not a valid dejagnu directive, 'dg-do run' is needed here for the test to be executed. PR target/108699 gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr108699.c: Fix 'dg-run' typo. Signed-off-by: Sam James
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #7 from Eric Gallager --- Well ok, could someone send me a binary x86_64 build of GCC for darwin20 with Ada support that they can bootstrap with successfully, then, so that I can get back to bootstrapping, too? Either that, or send me the files that gen_il-main generates...
[Bug rtl-optimization/116027] New: Redundant backup and restore of register with -flive-range-shrinkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116027
Bug ID: 116027
Summary: Redundant backup and restore of register with
-flive-range-shrinkage
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: user202729 at protonmail dot com
Target Milestone: ---
Code:
__attribute__((pure)) long f(long a, long b);
long x;
long g(){
long y=x;
long z=f(0, 0);
return f(y, z);
}
long h(){
long z=f(0, 0);
long y=x;
return f(y, z);
}
Resulting assembly:
g():
pushrbx
xor esi, esi
xor edi, edi
callf(long, long)
mov rdi, QWORD PTR x[rip]
pop rbx
mov rsi, rax
jmp f(long, long)
h():
xor esi, esi
xor edi, edi
callf(long, long)
mov rdi, QWORD PTR x[rip]
mov rsi, rax
jmp f(long, long)
In function g, the push rbx/pop rbx pair is redundant.
Godbolt: https://godbolt.org/z/os4EYP916
Without -flive-range-shrinkage then both generates optimal code.
The reason for the suboptimal code can be partially traced to the following
code in gcc/ira.cc:
/* Don't move insns if live range shrinkage or register
pressure-sensitive scheduling were done because it will not
improve allocation but likely worsen insn scheduling. */
if (optimize
&& !flag_live_range_shrinkage
&& !(flag_sched_pressure && flag_schedule_insns))
combine_and_move_insns ();
Without the flag specified, the load of x is moved to after the function call
(which is optimal).
With the flag specified, the move is not done in that pass (but it is optimized
in a subsequent pass anyway, that pass is probably after the pass that removes
redundant stack backup/restores).
[Bug target/115982] [15 Regression] ICE: unrecognizable insn in ira_remove_insn_scratches with -mavx512vl since r15-1742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115982 Hongtao Liu changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |liuhongt at gcc dot gnu.org --- Comment #4 from Hongtao Liu --- I'll take a look
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #21 from Rama Malladi --- Thank you Hubicka@ and rsandifo@ for reviewing this feature request and supporting it. Could we go ahead and dispose this as accepted or rejected? Accordingly action the PR https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655506.html? Thanks.
[Bug rtl-optimization/116027] Redundant backup and restore of register with -flive-range-shrinkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116027 --- Comment #1 from Andrew Pinski --- -O2 -mpreferred-stack-boundary=3 -flive-range-shrinkage
[Bug fortran/106089] false positives with -Wuninitialized for allocation on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- I am closing this PR, since it is fixed on mainline by pr108889 and will be backported in due course. Paul
[Bug fortran/77504] [12/13/14 Regression] "is used uninitialized" with allocatable string and array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504 Bug 77504 depends on bug 106089, which changed state. Bug 106089 Summary: false positives with -Wuninitialized for allocation on assignment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/108889] [12/13/14 Regression] (Re)Allocate in assignment shows used uninitialized memory warning with -Wall if LHS is unallocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108889 Bug 108889 depends on bug 106089, which changed state. Bug 106089 Summary: false positives with -Wuninitialized for allocation on assignment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 106089, which changed state. Bug 106089 Summary: false positives with -Wuninitialized for allocation on assignment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/77504] [12/13/14 Regression] "is used uninitialized" with allocatable string and array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504 --- Comment #35 from Paul Thomas --- Closing since it is fixed on mainline and the remedy will be backported in due course by the fix for pr10889. Paul
[Bug fortran/83209] [12/13/14/15 Regression] [Coarray] Failure of allocation of a coarray with a pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83209 Andre Vehreschild changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Bug 83700 depends on bug 83209, which changed state. Bug 83209 Summary: [12/13/14/15 Regression] [Coarray] Failure of allocation of a coarray with a pointer component https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83209 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME
[Bug rtl-optimization/116027] Redundant backup and restore of register with -flive-range-shrinkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116027
--- Comment #2 from user202729 ---
Maybe this is a less artificial example.
__attribute__((pure)) long f(__int128 a, long b);
__int128 x;
long g(){
__int128 y=x;
long z=f(0, 0);
x=1;
return f(y, z);
}
long h(){
long z=f(0, 0);
__int128 y=x;
x=1;
return f(y, z);
}
Compile with -O2.
Assembly:
g():
pushr14 // <-- redundant
xor edx, edx
xor edi, edi
xor esi, esi
pushrbx // <-- redundant
sub rsp, 8
callf(__int128, long)
mov rdi, QWORD PTR x[rip]
mov rsi, QWORD PTR x[rip+8]
mov QWORD PTR x[rip], 1
mov QWORD PTR x[rip+8], 0
add rsp, 8
mov rdx, rax
pop rbx // <-- redundant
pop r14 // <-- redundant
jmp f(__int128, long)
h():
sub rsp, 8
xor edx, edx
xor edi, edi
xor esi, esi
callf(__int128, long)
mov rdi, QWORD PTR x[rip]
mov rsi, QWORD PTR x[rip+8]
mov QWORD PTR x[rip], 1
mov QWORD PTR x[rip+8], 0
mov rdx, rax
add rsp, 8
jmp f(__int128, long)
Godbolt: https://godbolt.org/z/E1cnrEWzs
[Bug fortran/115997] Findloc does not find the result of a function with a deferred-length character return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115997 --- Comment #2 from martin --- Thanks for checking and looking up. I have not been able to use gfortran-14 due to bug 114874 (a regression which has been resolved after release). Strangely, the search box of bugzilla does not show relevant findloc issues, so I missed bug 110288.
