[Bug tree-optimization/116973] FAIL: gcc.dg/vect/pr52252-st.c with forced SLP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116973 --- Comment #6 from Richard Biener --- While recovering the absymal code-generation of gcc.dg/vect/pr52252-st.c is likely not of uttermost priority the missing opportunity is for the case of single element interleaving that can be vectorized by loading exactly one scalar element from each vector and building up the vector. This is what we'd code-generate by using VMAT_ELEMENTWISE but I have not yet made up my mind if we want to classify it as such. Lowering this to an interleaving scheme (which is what we do without SLP) is going to generate worse code.
[Bug c++/117501] [14/15 Regression] Consteval constructor does not initialize the variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117501 Marek Polacek changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Mine then.
[Bug libgcc/117537] [15 regression] Failed cross build for aarch64_be-unknown-linux-gnu (libgcc/config/libbid/bid_conf.h:847:25: error: missing braces around initializer [-Werror=missing-braces])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117537 --- Comment #1 from Sam James --- Created attachment 59577 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59577&action=edit build.log.xz
[Bug libgcc/117537] [15 regression] Failed cross build for aarch64_be-unknown-linux-gnu (libgcc/config/libbid/bid_conf.h:847:25: error: missing braces around initializer [-Werror=missing-braces])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117537 --- Comment #2 from Sam James --- (In reply to Sam James from comment #0) > > I assume this started with the libgcc change a little while ago from the arm > folks to enable -Werror for arm. If that's right, it's not respecting --disable-werror.
[Bug rtl-optimization/117191] [avr][dse2][lra] wrong dead store elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117191 --- Comment #9 from denisc at gcc dot gnu.org --- Created attachment 59576 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59576&action=edit pro_and_epilogue pass dump file (pre dse2)
[Bug target/117538] New: Tracebacks don’t include the load address of PIE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117538
Bug ID: 117538
Summary: Tracebacks don’t include the load address of PIE
executables
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: simon at pushface dot org
Target Milestone: ---
MacOS can only create position-independent executables (PIE). Other OSs may
be able to.
When an unhandled exception occurs, the traceback report includes the load
address, which is necessary in order to decode the error. On the other hand,
the
report output by GNAT.Traceback.Symbolic (a renaming of
System.Traceback.Symbolic)
doesn’t, as this test program shows:
with Ada.Exceptions;
with Ada.Exceptions.Traceback;
with Ada.Text_IO; use Ada.Text_IO;
with GNAT.Traceback.Symbolic;
procedure Traceback is
begin
raise Constraint_Error;
exception
when E : others =>
Put_Line ("--- Ada.Exceptions.Exception_Information ---");
Put_Line (Ada.Exceptions.Exception_Information (E));
Put_Line ("--- GNAT.Traceback.Symbolic.Symbolic_Traceback ---");
Put_Line
(GNAT.Traceback.Symbolic.Symbolic_Traceback
(Ada.Exceptions.Traceback.Tracebacks (E)));
end Traceback;
$ ./traceback
--- Ada.Exceptions.Exception_Information ---
raised CONSTRAINT_ERROR : traceback.adb:7 explicit raise
Load address: 0x1045e4000
Call stack traceback locations:
0x1045e5dcd 0x1045e5d41
--- GNAT.Traceback.Symbolic.Symbolic_Traceback ---
0x0001045E5DCD 0x0001045E5D41
I have a patch for this, which I’ll post to gcc-patches.
With the patch (on a different run, of course, so the addresses are
different), the output is
--- Ada.Exceptions.Exception_Information ---
raised CONSTRAINT_ERROR : traceback.adb:7 explicit raise
Load address: 0x10ff88000
Call stack traceback locations:
0x10ff8ab0f 0x10ff8b267
--- GNAT.Traceback.Symbolic.Symbolic_Traceback ---
Load address: 0x10FF88000
0x10FF8AB0F 0x10FF8B267
Further tests at https://github.com/simonjwright/traceback .
[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819
--- Comment #13 from anlauf at gcc dot gnu.org ---
Returning to this PR, I found that passing NULL() to character pointer dummies
exhibits a wrong translation of the function call, despite the declaration
appearing fine:
program p
implicit none
character(10), pointer :: c => NULL()
character(:), pointer :: d => NULL()
! these are incorrectly translated and may crash at runtime:
call foo (null(c))
call bla (null(c))
call bar (null(d))
call bla (null())
call bar (null())
! correctly translated function calls:
call foo (c)
call bla (c)
call bar (d)
contains
subroutine foo (x)
character(len=*), pointer, intent(in) :: x
if (associated (x)) stop 1
end
subroutine bla (x)
character(len=10), pointer, intent(in) :: x
if (associated (x)) stop 2
end
subroutine bar (x)
character(len=:), pointer, intent(in) :: x
if (associated (x)) stop 3
end
end
The dump of the relevant part of the main is:
void p ()
{
static void bar (character(kind=1) * &, integer(kind=8) *);
static void bla (character(kind=1)[1:10] * &, integer(kind=8));
static void foo (character(kind=1)[1:] * &, integer(kind=8));
static character(kind=1)[1:10] * c = 0B;
static integer(kind=8) _F.d;
static character(kind=1) * d = 0B;
foo (0B);
bla (0B);
bar (0B);
{
static void * C.4802 = 0B;
bla (&C.4802);
}
{
static void * C.4803 = 0B;
bar (&C.4803);
}
foo (&c, 10);
bla (&c, 10);
bar (&d, &_F.d);
}
[Bug driver/81358] libatomic not automatically linked with C11 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 John Scott changed: What|Removed |Added CC||jscott at posteo dot net --- Comment #16 from John Scott --- I'm an Austin Group member who's been watching the C11 integration closely, so I'd like to share what I've observed for the requirements on conforming compiler drivers (which, unless gcc is installed under the name 'c17', it doesn't technically purport to be). ISO C makes atomics optional and POSIX/SUS does *not* strengthen this. However, IEEE 1003.1-2024 does specify the header and the atomic functions as an option group in the "System Interfaces" section. If one refers to [the part of the standard for the c17 command](https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c17.html#tag_20_11_13_01), it says that conforming implementations must expose symbols for all of the standard System Interfaces with a few exceptions (like ). No exception was added for atomics, so I believe conforming systems must not require the addition of a flag like -latomic in order for the symbols to be linked with. I would like to affirm what Adrian Bunk said too in that this is not merely a theoretical issue: I think (maybe?) riscv64-linux-gnu has even been hit by this and packages are failing to build. Thus this is an area where adhering to the letter of the standard will benefit applications greatly.
[Bug c/117490] Invalid TBAA for structures without tag and compatible definition in C.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117490
--- Comment #8 from uecker at gcc dot gnu.org ---
Some tests for pointers to struct w and w/o tag and also with one incomplete
struct.
https://godbolt.org/z/ePcoTTeMq
#if 1
#define tag
#endif
int f2(void *x, void *y)
{
typedef struct tag { int i1; } s1;
s1 **s1p = x;
{
#if 0
typedef struct tag /*{ int i1; }*/ s2;
#else
typedef struct tag { int i1; } s2;
#endif
s2 **s2p = y;
*s1p = &(s1){ 2 };
*s2p = (void*)&(s1){ 3 };
return (*s1p)->i1 * 3;
}
}
int main()
{
struct tag { int i1; } *a;
return f2(&a, &a);
}
[Bug c/117020] [C2y] Implement N3366, Restartable Functions for Efficient Character Conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117020 --- Comment #4 from Joseph S. Myers --- Yes, it's about the exec-charset / wide-exec-charset.
[Bug fortran/117539] New: Pure procedure and intent(out) polymorphic pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117539 Bug ID: 117539 Summary: Pure procedure and intent(out) polymorphic pointer argument Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gronki at gmail dot com Target Milestone: --- ``` module bugmod implicit none type value_t end type contains pure subroutine fetch_ptr(ptr) class(value_t), intent(out), pointer :: ptr end subroutine end module ``` gfortran (but also ifx 2025) fails to compile this code with: Error: INTENT(OUT) argument ‘ptr’ of pure procedure ‘fetch_ptr’ at (1) may not be polymorphic The restriction was imposed specifically to prevent the possibility of non-pure finalizers being invoked when the actual argument to intent(out) is being deallocated. But in case of the pointer, no automatic deallocation happens due o intent(out), therefore for pointers this restriction should not be imposed. Related read: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59103 Have a good day! Dominik
[Bug ipa/117540] New: ICE on x86_64-linux-gnu: verify_cgraph_node failed at -Os.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117540
Bug ID: 117540
Summary: ICE on x86_64-linux-gnu: verify_cgraph_node failed at
-Os.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/hvnrGEnnK
***
gcc version:
Using built-in specs.
COLLECT_GCC=/home/software/gcc-trunk/bin/gcc
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-bootstrap --enable-checking=yes
--prefix=/home/software/gcc-trunk --enable-sanitizers --enable-languages=c,c++
--disable-werror --enable-multilib --enable-coverage
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241107 (experimental) (GCC)
***
Program:
$ cat mutant.C
enum _Ios_Openmode {};
struct ios_base {};
struct basic_istream : virtual ios_base {};
struct basic_ifstream : basic_istream {
basic_ifstream(char *, _Ios_Openmode);
_Ios_Openmode basic_ifstream___mode;
template
basic_ifstream(_Path &__s)
: basic_ifstream(__s.c_str(), basic_ifstream___mode) {}
};
struct Trans_NS___cxx11_path {
using value_type = char;
value_type *c_str();
};
struct Trans_NS___cxx11_directory_entry {
Trans_NS___cxx11_path &path();
};
struct Trans_NS___cxx11_recursive_directory_iterator {
Trans_NS___cxx11_directory_entry *operator->();
};
int __attribute__((flatten)) main() {
Trans_NS___cxx11_recursive_directory_iterator it;
basic_ifstream(it->path());
}
***
Command Lines:
$ gcc -Os mutant.C
mutant.C:24:1: error: calls_comdat_local is set outside of a comdat group
24 | }
| ^
mutant.C:24:1: error: invalid calls_comdat_local flag
main/0 (int main())
Type: function definition analyzed
Visibility: externally_visible semantic_interposition public
References:
Referring:
Availability: available
Function flags: count:1073741824 (estimated locally) body
only_called_at_startup calls_comdat_local executed_once optimize_size
Called by:
Calls: _ZN14basic_ifstreamC1I21Trans_NS___cxx11_pathEERT_/3 (inlined)
(1073741824 (estimated locally),1.00 per call) (can throw external)
_ZN32Trans_NS___cxx11_directory_entry4pathEv/12 (1073741824 (estimated
locally),1.00 per call) (can throw external)
_ZN45Trans_NS___cxx11_recursive_directory_iteratorptEv/11 (1073741824
(estimated locally),1.00 per call) (can throw external)
during IPA pass: inline
mutant.C:24:1: internal compiler error: verify_cgraph_node failed
0x5cdf4f4 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:518
0x19e824c cgraph_node::verify_node()
../../gcc/gcc/cgraph.cc:3960
0x19ba49e symtab_node::verify()
../../gcc/gcc/symtab.cc:1363
0x19babb4 symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.cc:1483
0x1a04e00 symtab_node::checking_verify_symtab_nodes()
../../gcc/gcc/cgraph.h:689
0x210d189 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/gcc/ipa.cc:680
0x582f086 ipa_inline
../../gcc/gcc/ipa-inline.cc:2886
0x5830be6 execute
../../gcc/gcc/ipa-inline.cc:3277
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476 --- Comment #23 from Sam James --- *** Bug 117531 has been marked as a duplicate of this bug. ***
[Bug c/117531] [15 Regression] Miscompile with -O2 and -O0/1/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117531 Sam James changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Sam James --- Dupe. *** This bug has been marked as a duplicate of bug 117476 ***
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 Sam James changed: What|Removed |Added See Also||https://github.com/oneapi-s ||rc/oneTBB/issues/1533, ||https://github.com/oneapi-s ||rc/oneDPL/pull/1589 --- Comment #6 from Sam James --- (In reply to Sam James from comment #5) > But if you're interested in trying a patch, he might be able to give you > advice if you want to learn (which is welcome). Ah, sorry, I see you already did -- maybe submit it formally?
[Bug c++/117534] New: internal compiler error: Segmentation fault at check_explicit_specialization(tree_node*, tree_node*, int, int, tree_node*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117534
Bug ID: 117534
Summary: internal compiler error: Segmentation fault at
check_explicit_specialization(tree_node*, tree_node*,
int, int, tree_node*)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yihan4845 at gmail dot com
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/f9Wq36qeb
The following valid program:
```cpp
template
void j(int i = 0, Ts... ts) {}
template <>
void j(int i, int j, int *p, int *q) {}
```
will trigger segmentation fault for gcc trunk.
Stack dump:
```
0x289aac5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x28b14b5 internal_error(char const*, ...)
???:0
0xd04cae check_explicit_specialization(tree_node*, tree_node*, int, int,
tree_node*)
???:0
0xb7389c grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0xb7683a start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
???:0
0xca0a8a c_parse_file()
???:0
0xdfab89 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 --- Comment #5 from Sam James --- Jonathan already self-assigned it which indicates he's planning to work on it soon, FWIW (that doesn't happen for all libstdc++ bugs automatically). But if you're interested in trying a patch, he might be able to give you advice if you want to learn (which is welcome).
[Bug c++/69585] [C++ 11] parser errors mixing alignas, C++ 11 and GNU attributes on class declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69585 --- Comment #9 from Marek Polacek --- (In reply to David Seifert from comment #8) > Marek Polacek, could we please get this backported to GCC 12 too? Sorry, this doesn't look like a candidate for backporting to GCC 12 to me.
[Bug c++/117535] New: Segmentation fault signal terminated program cc1plus with recursive lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117535
Bug ID: 117535
Summary: Segmentation fault signal terminated program cc1plus
with recursive lambda
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yihan4845 at gmail dot com
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/3vazW8dq9
The following program:
```cpp
template void f(T a, int = f([] {}));
void g() { f(0); }
```
will trigger segmentation fault for gcc trunk.
Stack dump:
```
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug c++/69585] [C++ 11] parser errors mixing alignas, C++ 11 and GNU attributes on class declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69585 --- Comment #10 from Sam James --- FWIW, Jason said it seemed reasonable on IRC, but ofc if you're not comfortable with it, that's fine (just saying it wasn't out of nowhere).
[Bug libstdc++/111861] ranges::min/max should not use `auto __result = *__first;`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111861 --- Comment #2 from 康桓瑋 --- (In reply to Patrick Palka from comment #1) > Interesting, I guess 'auto x = *iter;' should never be done in generic code > then? Yap, even 'range_value_t x = *iter;'.
[Bug target/117525] [15 Regression] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952 since r15-2890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117525 Andrew Pinski changed: What|Removed |Added Summary|[15 Regression] |[15 Regression] |canvas.cc:1675:1: internal |canvas.cc:1675:1: internal |compiler error: in |compiler error: in |expand_fix, at |expand_fix, at |optabs.cc:5952 |optabs.cc:5952 since ||r15-2890 Keywords|needs-bisection | --- Comment #8 from Andrew Pinski --- And yes this is definitely since r15-2890 .
[Bug ipa/103819] [12/13/14/15 Regression] ICE in redirect_callee, at cgraph.c:1389 with __attribute__((flatten)) and -O2 since r11-7940-ge7fd3b783238d034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103819 Andrew Pinski changed: What|Removed |Added CC||iamanonymous.cs at gmail dot com --- Comment #9 from Andrew Pinski --- *** Bug 117540 has been marked as a duplicate of this bug. ***
[Bug ipa/117540] ICE on x86_64-linux-gnu: verify_cgraph_node failed at -Os with flatten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117540 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Known to fail||10.5.0 --- Comment #1 from Andrew Pinski --- Same underlying issue as PR 103819. *** This bug has been marked as a duplicate of bug 103819 ***
[Bug tree-optimization/117510] Inner loop with static trip count breaks vectorization of outer loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117510 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed for GCC 15.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 117510, which changed state. Bug 117510 Summary: Inner loop with static trip count breaks vectorization of outer loop https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117510 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/117510] Inner loop with static trip count breaks vectorization of outer loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117510 --- Comment #2 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:da64698159fe69b68f5264b54cebcb67c501b3cf commit r15-5082-gda64698159fe69b68f5264b54cebcb67c501b3cf Author: Richard Biener Date: Mon Nov 11 09:40:20 2024 +0100 tree-optimization/117510 - fix guard hoisting validity check For the loop in the testcase we currently fail to hoist the guard check of the inner loop (m > 0) out of the outer loop because find_loop_guard checks all blocks of the outer loop for side-effects, including those that are skipped by the guard. This usually is harmless as the guard does not skip any blocks in the outer loop but in this case store-motion was applied to the inner loop and thus there's now a skipped store in the outer loop. The following properly skips blocks that are dominated by the entry to the skipped region. PR tree-optimization/117510 * tree-ssa-loop-unswitch.cc (find_loop_guard): Only check not skipped blocks for side-effects. * gcc.dg/vect/vect-outer-pr117510.c: New testcase.
[Bug c/117531] New: Miscompile with -O2 and -O0/1/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117531
Bug ID: 117531
Summary: Miscompile with -O2 and -O0/1/3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yunboni at smail dot nju.edu.cn
Target Milestone: ---
When I compiled this code with -O2, it triggered SIGKILL. With -O0/1/3, it
returned 0:
```c
int a;
unsigned b;
char c = 228;
int f(int g) {
int d = g ? g - 1 : 1, e = 113 - d;
return e & 65535;
}
void h() {
for (; f(c + 115) + b > 40;)
for (;;)
;
}
int main() {
h();
}
```
Details can be found here: https://godbolt.org/z/fjG69eqoq
[Bug c/117020] [C2y] Implement N3366, Restartable Functions for Efficient Character Conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117020
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
I'm afraid I don't understand when exactly the predefined macros should be
defined.
Shall __STDC_LITERAL_UTF8__ be defined when narrow character set is UTF-8 and
__STDC_WIDE_LITERAL_UTF{16,32}__ when the wide character set is UTF-16/32
(depending on
wchar_precision)?
Something else?
If yes, checking for the default cases might be easier than when user uses
-fexec-charset=/-fwide-exec-charset=, because with user specified charsets
figuring out from whatever iconv groks if it is UTF-8/16/32 compatible might be
harder.
[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600 --- Comment #22 from Uroš Bizjak --- (In reply to Li Pan from comment #21) > Looks the f2 can vectorized to sat_add from upstream now, may be impacted by > recent changes. Let me add one test for this target x86. Unfortunately, I still get the same code as in Comment #18. Tried "-O2 -ftree-vectorize" and -O3. gcc version 15.0.0 2024 (experimental) [master r15-5078-g42a2df0b798] (GCC)
[Bug target/117455] Nested function use gives a ld warning about executable stack, after binutils 2.39
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455 --- Comment #10 from rguenther at suse dot de --- On Mon, 11 Nov 2024, iains at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455 > > --- Comment #9 from Iain Sandoe --- > (In reply to rguent...@suse.de from comment #8) > > On Sat, 9 Nov 2024, iains at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455 > > > > > > Iain Sandoe changed: > > > > > >What|Removed |Added > > > > > > Summary|ld warning about executable |Nested function use > > > gives a > > >|stack, follows from PR |ld warning about > > > executable > > >|117434 |stack, after binutils > > > 2.39 > > > Depends on|117434 | > > >Keywords||diagnostic > > > Component|fortran |target > > > Target||x86_64-linux > > >See Also| > > > |https://gcc.gnu.org/bugzill > > >||a/show_bug.cgi?id=117434 > > > > > > --- Comment #7 from Iain Sandoe --- > > > Actually, > > > > > > * this is not specifically a fortran issue - the effect repeats complete > > > with > > > a standard C nested function test: > > > > > > > > But local to gfortran, you have some immediate options: > > > > > > 1. You could just add the appropriate flags to the test-case(s) to > > > suppress > > > the warning (having decided, perhaps that fixing it is outside the > > > purview of > > > gfortran). > > > > > > 2. you could decide to do (1) for every Fortran build by adding the > > > relevant > > > option to the gfortran link specs. (would have to to be a > > > configure-determined > > > action). > > > > > > 3. you could apply -ftrampoline-impl=heap instead of suppressing the > > > warning > > > (on platforms that support it) - again this would need some configure-time > > > discovery if you wanted to add it to the link spec. [either to specific > > > tests > > > or generally for gfortran]. > > > > With LTO there might be the need to support mixed operation - ideally > > we'd have a per-call way of specifying the trampoline type. The ABI > > on the callee side isn't necessarily the same between the two though > > (is it on x86?), so it might be more like a function attribute of the > > nested function [type] itself. > > AFAIU, we do not allow a nested function pointer to escape from the function > in > which it is defined - to do so would break the assumptions of nested model, I > think, right? Right. > So the model used would be Tu-local already; if there's a way in which LTO > could cause the nested fn ptr to effectively escape from its containing fn > then that needs some extra thinking? I was thinking of inlining the callers of nested functions from two TUs into the same function. Dependent of whether the choice of stack vs. heap trampoline is already reflected into the IL during nested function lowering or only at RTL expansion time this might or might not be an "interesting" setup (we can of course chose to not inline functions with nested function call ABI differences into the same function). That is, I was wondering whether having a per-function -ftrampoline-impl= flag would work without any other changes - currently it's a TU wide flag but we do not enforce it to be the same during LTO options processing (lto-wrapper.cc:merge_and_complain), so the "first" TU wins in setting the LTRANS stages flag. Richard.
[Bug fortran/116388] [13/14/15 regression] Finalizer called on uninitialized components of intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116388 --- Comment #5 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:42a2df0b7985b2a4732ba1c29726ac7aabd5eeae commit r15-5078-g42a2df0b7985b2a4732ba1c29726ac7aabd5eeae Author: Paul Thomas Date: Mon Nov 11 09:01:11 2024 + Fortran: Suppress invalid finalization of artificial variable [PR116388] 2024-11-11 Tomas Trnka Paul Thomas gcc/fortran PR fortran/116388 * class.cc (finalize_component): Leading underscore in the name of 'byte_stride' to suppress invalid finalization. gcc/testsuite/ PR fortran/116388 * gfortran.dg/finalize_58.f90: New test.
[Bug fortran/116388] [13/14 regression] Finalizer called on uninitialized components of intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116388 Paul Thomas changed: What|Removed |Added Summary|[13/14/15 regression] |[13/14 regression] |Finalizer called on |Finalizer called on |uninitialized components of |uninitialized components of |intent(out) argument|intent(out) argument --- Comment #6 from Paul Thomas --- 13- and 14-branches to do shortly. Paul
[Bug tree-optimization/117510] Inner loop with static trip count breaks vectorization of outer loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117510 --- Comment #4 from Freddie Witherden --- (In reply to Richard Biener from comment #3) > Fixed for GCC 15. Thanks! If I have cases which, when m is a compile time constant, vectorize for m small but not m large is that likely to be a separate issue?
[Bug fortran/109345] [12/13/14/15 Regression] class(*) variable that is a string array is not handled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345 --- Comment #3 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:e22d80d4f0f8d33f538c1a4bad07b2c819a6d55c commit r15-5083-ge22d80d4f0f8d33f538c1a4bad07b2c819a6d55c Author: Paul Thomas Date: Mon Nov 11 12:21:57 2024 + Fortran: Fix elemental array refs in SELECT TYPE [PR109345] 2024-11-10 Paul Thomas gcc/fortran PR fortran/109345 * trans-array.cc (gfc_get_array_span): Unlimited polymorphic expressions are now treated separately since the span need not be the same as the element size. gcc/testsuite/ PR fortran/109345 * gfortran.dg/character_workout_1.f90: Cut trailing whitespace. * gfortran.dg/pr109345.f90: New test.
[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600 --- Comment #23 from Li Pan --- (In reply to Uroš Bizjak from comment #22) > (In reply to Li Pan from comment #21) > > > Looks the f2 can vectorized to sat_add from upstream now, may be impacted by > > recent changes. Let me add one test for this target x86. > > Unfortunately, I still get the same code as in Comment #18. Tried "-O2 > -ftree-vectorize" and -O3. > > gcc version 15.0.0 2024 (experimental) [master r15-5078-g42a2df0b798] > (GCC) Oh, I see. Seems I called the scalar sat_add instead of sat_add2 from loop, let me have a try.
[Bug target/29838] should an option to disable use of TLS for -fstack-protector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Segher Boessenkool --- Fixed many years ago.
[Bug target/29838] should an option to disable use of TLS for -fstack-protector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #16 from Segher Boessenkool --- I implemented this for rs6000 in 1b3254e4bbe8. As machine options, since that is the only thing that makes sense. Some other archs have followed suit since then (aarch64, riscv, x86), all slightly differently, and that makes actual sense, so -m was a good choice :-) Closing this PR now, other targets that want this need to do a machine option just as well.
[Bug target/117455] Nested function use gives a ld warning about executable stack, after binutils 2.39
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455 --- Comment #12 from Richard Biener --- (In reply to Iain Sandoe from comment #11) > Tentatively (absent a way to test this) so long as we continue to link > libgcc, and libgcc provides the heap support, I'd say that's probably OK - > we do not revisit nested lowering later AFAIK. I suppose that if a platform > decided to implement the builtins in a CRT instead of libgcc, then having > the right flag on the link line might matter? Definitively - if the link spec looks at a flag LTO becomes "difficult" and we'd have to enforce the same setting across TUs. Back to the Fortran issue - give that nested functions are standard there, as opposed to C, using heap trampolines by default where supported makes sense. I'm not sure what Ada does here for example, it might just enable execstack explicitly when linking with the Ada driver and thus avoid the diagnostic. > Iain
[Bug tree-optimization/117510] Inner loop with static trip count breaks vectorization of outer loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117510 --- Comment #5 from Richard Biener --- (In reply to Freddie Witherden from comment #4) > (In reply to Richard Biener from comment #3) > > Fixed for GCC 15. > > Thanks! If I have cases which, when m is a compile time constant, vectorize > for m small but not m large is that likely to be a separate issue? I guess it's the same issue if for the small M we unroll but for the large M is not. I've checked that with m constant 234 we now vectorize the outer loop.
[Bug fortran/109345] [12/13/14 Regression] class(*) variable that is a string array is not handled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345 Paul Thomas changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12/13/14 Regression] |class(*) variable that is a |class(*) variable that is a |string array is not handled |string array is not handled |correctly |correctly --- Comment #4 from Paul Thomas --- A good fix turned out to be a bit more involved than the attachment! Pushed to mainline - 13- and 14- branches to follow in a week. Thanks for the report. Paul
[Bug c/117532] New: Miscompile with -Os and -O0/1/2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117532
Bug ID: 117532
Summary: Miscompile with -Os and -O0/1/2/3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yunboni at smail dot nju.edu.cn
Target Milestone: ---
When I compiled this code with -Os, its output is -256. But with -O0/1/2/3, its
output is 0:
```c
int printf(const char *, ...);
int a, c = -1;
int main() {
a = ~c;
printf("%d\n", (unsigned char)a);
}
```
Details can be found here: https://godbolt.org/z/o77dorWzr
[Bug rtl-optimization/117532] [15 Regression] Miscompile with -Os and -O0/1/2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117532 Richard Biener changed: What|Removed |Added Summary|Miscompile with -Os and |[15 Regression] Miscompile |-O0/1/2/3 |with -Os and -O0/1/2/3 Ever confirmed|0 |1 Priority|P3 |P1 Component|c |rtl-optimization Target Milestone|--- |15.0 Last reconfirmed||2024-11-11 Known to work||14.2.0 Target||x86_64-*-* Keywords||needs-bisection, wrong-code Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed. GIMPLE IL is the samme, possibly a target issue though. xorb$-1, %sil while this properly inverts the 'char' it fails to invert the higher bits (or properly zero extends it).
[Bug c/117531] [15 Regression] Miscompile with -O2 and -O0/1/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117531 Richard Biener changed: What|Removed |Added Last reconfirmed||2024-11-11 Ever confirmed|0 |1 Summary|Miscompile with -O2 and |[15 Regression] Miscompile |-O0/1/3 |with -O2 and -O0/1/3 Target Milestone|--- |15.0 Keywords||needs-bisection, wrong-code Status|UNCONFIRMED |NEW Known to work||14.2.0 --- Comment #1 from Richard Biener --- Confirmed.
[Bug middle-end/117352] [15 Regression] switch bit test conversion makes comparison code worse on aarch64 and x86_64 with APX due to not generating ccmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117352 Filip Kastl changed: What|Removed |Added CC||pheeck at gcc dot gnu.org --- Comment #3 from Filip Kastl --- I've investigated Andi's patch today and I think that I have a fix for this. Basically, the patch calls is_beneficial() with number of values covered by a bit test cluster as an argument. But is_beneficial() should be called with number of cases covered by the cluster as an argument. I have checked that if I modify this part of the patch, the issue described in this PR doesn't happen. I plan to submit a modification of Andi's patch to the mailing list on Wednesday.
[Bug rtl-optimization/117532] [15 Regression] Miscompile with -Os and -O0/1/2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117532 Jakub Jelinek changed: What|Removed |Added CC||alexey.merzlyakov at samsung dot c ||om, jakub at gcc dot gnu.org, ||law at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Jakub Jelinek --- Started with r15-4991-g69bd93c167fefbdff0cb88614275358b7a2b2941
[Bug rtl-optimization/117532] [15 Regression] Miscompile with -Os and -O0/1/2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117532
--- Comment #3 from Jakub Jelinek ---
Modified testcase for testsuite:
int a, c = -1;
__attribute__((noipa)) void
foo (int x)
{
if (x)
__builtin_abort ();
}
int
main ()
{
a = ~c;
foo ((unsigned char) a);
}
[Bug rtl-optimization/117532] [15 Regression] Miscompile with -Os and -O0/1/2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117532 Alexander Monakov changed: What|Removed |Added Resolution|--- |DUPLICATE CC||amonakov at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #4 from Alexander Monakov --- In all likelihood a dup of PR 117476. *** This bug has been marked as a duplicate of bug 117476 ***
[Bug rtl-optimization/117532] [15 Regression] Miscompile with -Os and -O0/1/2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117532 --- Comment #5 from Sam James --- Given the # of dupes, I recommend that fuzzers revert that commit locally for now.
[Bug rtl-optimization/117532] [15 Regression] Miscompile with -Os and -O0/1/2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117532 --- Comment #6 from Yunbo Ni --- (In reply to Sam James from comment #5) > Given the # of dupes, I recommend that fuzzers revert that commit locally > for now. Thanks for your advice. I'll revert it.
[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476 --- Comment #22 from Alexander Monakov --- *** Bug 117532 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/117529] Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117529 --- Comment #5 from Kang-Che Sung --- Sorry again. My mind wasn't cleaned up when I wrote the comment. It's (x == 0 || y == 0) and the logic is not equivalent to ((x & y) == 0).
[Bug target/117455] Nested function use gives a ld warning about executable stack, after binutils 2.39
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455 --- Comment #9 from Iain Sandoe --- (In reply to rguent...@suse.de from comment #8) > On Sat, 9 Nov 2024, iains at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455 > > > > Iain Sandoe changed: > > > >What|Removed |Added > > > > Summary|ld warning about executable |Nested function use gives a > >|stack, follows from PR |ld warning about executable > >|117434 |stack, after binutils 2.39 > > Depends on|117434 | > >Keywords||diagnostic > > Component|fortran |target > > Target||x86_64-linux > >See Also||https://gcc.gnu.org/bugzill > >||a/show_bug.cgi?id=117434 > > > > --- Comment #7 from Iain Sandoe --- > > Actually, > > > > * this is not specifically a fortran issue - the effect repeats complete > > with > > a standard C nested function test: > > > > But local to gfortran, you have some immediate options: > > > > 1. You could just add the appropriate flags to the test-case(s) to suppress > > the warning (having decided, perhaps that fixing it is outside the purview > > of > > gfortran). > > > > 2. you could decide to do (1) for every Fortran build by adding the > > relevant > > option to the gfortran link specs. (would have to to be a > > configure-determined > > action). > > > > 3. you could apply -ftrampoline-impl=heap instead of suppressing the > > warning > > (on platforms that support it) - again this would need some configure-time > > discovery if you wanted to add it to the link spec. [either to specific > > tests > > or generally for gfortran]. > > With LTO there might be the need to support mixed operation - ideally > we'd have a per-call way of specifying the trampoline type. The ABI > on the callee side isn't necessarily the same between the two though > (is it on x86?), so it might be more like a function attribute of the > nested function [type] itself. AFAIU, we do not allow a nested function pointer to escape from the function in which it is defined - to do so would break the assumptions of nested model, I think, right? So the model used would be Tu-local already; if there's a way in which LTO could cause the nested fn ptr to effectively escape from its containing fn then that needs some extra thinking?
[Bug tree-optimization/117510] Inner loop with static trip count breaks vectorization of outer loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117510 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2024-11-11 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- The issue is that we fail to hoist the m > 0 check out of the outer loop: t.c:4:23: note: Considering guard 7 -> 6 in loop 1 t.c:4:23: missed: Block 5 has side effects [local count: 105119324]: # _10 = PHI <_8(4)> *_3 = _10; I think the logic in find_loop_guard is a bit flawed and it checks too many blocks for side-effects. I'm testing a fix.
[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600 --- Comment #21 from Li Pan --- (In reply to Li Pan from comment #20) > (In reply to Li Pan from comment #19) > > interesting, I will take a look for f2 after some more sat_* supported. > > RISC-V backend works well for all of above pattern but x86 failed on f2, let > me dig more details for this. Looks the f2 can vectorized to sat_add from upstream now, may be impacted by recent changes. Let me add one test for this target x86.
[Bug other/117409] ASAN issues compiling gfortran.dg/diagnostic-format-sarif-pr105916.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117409 Sam James changed: What|Removed |Added Target Milestone|--- |15.0 Last reconfirmed||2024-11-11 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Sam James --- $ valgrind -q --track-origins=yes /usr/libexec/gcc/x86_64-pc-linux-gnu/15/f951 gcc/testsuite/gfortran.dg/diagnostic-format-sarif-pr105916.f90 -quiet -dumpbase diagnosti c-format-sarif-pr105916.f90 -dumpbase-ext .f90 -mtune=generic -march=x86-64 -O2 -O -Wfatal-errors -fdiagnostics-color=never -fdiagnostics-urls=never -fdiagnostics-path-format=separate-ev ents -fdiagnostics-text-art-charset=none -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-path-format=separate-events -fdiagnostics-text-art-charset=none -fno -diagnostics-show-event-links -fdiagnostics-format=sarif-file -fmax-errors=1 -o diagnostic-format-sarif-pr105916.s -fintrinsic-modules-path /usr/lib/gcc/x86_64-pc-linux-gnu/15/finclude - fpre-include=/usr/include/finclude/math-vector-fortran.h ==4096545== Invalid read of size 1 ==4096545==at 0x5002810: __strcmp_avx2 (strcmp-avx2.S:249) ==4096545==by 0x1A9E050: file_cache::lookup_file(char const*) (input.cc:325) ==4096545==by 0x1A9DFDF: file_cache::lookup_or_add_file(char const*) (input.cc:539) ==4096545==by 0x19275DD: file_cache::get_source_file_content(char const*) (input.cc:1051) ==4096545==by 0x1927672: sarif_builder::maybe_make_artifact_content_object(char const*) const (diagnostic-format-sarif.cc:3201) ==4096545==by 0x192771B: sarif_artifact::populate_contents(sarif_builder&) (diagnostic-format-sarif.cc:1030) ==4096545==by 0x192791F: sarif_builder::make_run_object(std::unique_ptr >, std::unique_ptr >) (diagnostic-format-sarif.cc:2972) ==4096545==by 0x1927B9A: sarif_builder::make_top_level_object(std::unique_ptr >, std::unique_ptr >) (diagnostic-format-sarif.cc:2926) ==4096545==by 0x1927C56: sarif_builder::flush_to_object() (diagnostic-format-sarif.cc:1802) ==4096545==by 0x1927CC0: sarif_builder::flush_to_file(_IO_FILE*) (diagnostic-format-sarif.cc:1814) ==4096545==by 0x1927DA7: sarif_file_output_format::~sarif_file_output_format() (diagnostic-format-sarif.cc:3546) ==4096545==by 0x1927DCB: sarif_file_output_format::~sarif_file_output_format() (diagnostic-format-sarif.cc:3547) ==4096545== Address 0x523edc0 is 0 bytes inside a block of size 63 free'd ==4096545==at 0x484BE2F: free (vg_replace_malloc.c:989) ==4096545==by 0x267F70E: UnknownInlinedFun (scanner.cc:297) ==4096545==by 0x267F70E: UnknownInlinedFun (misc.cc:383) ==4096545==by 0x267F70E: gfc_finish() [clone .lto_priv.0] (f95-lang.cc:302) ==4096545==by 0x21FEF08: UnknownInlinedFun (toplev.cc:2118) ==4096545==by 0x21FEF08: UnknownInlinedFun (toplev.cc:2225) ==4096545==by 0x21FEF08: toplev::main(int, char**) (toplev.cc:2376) ==4096545==by 0x21FDF6A: main (main.cc:39) ==4096545== Block was alloc'd at ==4096545==at 0x4848BD3: malloc (vg_replace_malloc.c:446) ==4096545==by 0x26451DC: UnknownInlinedFun (xmalloc.c:149) ==4096545==by 0x26451DC: UnknownInlinedFun (xstrdup.c:34) ==4096545==by 0x26451DC: UnknownInlinedFun (scanner.cc:2056) ==4096545==by 0x26451DC: load_file(char const*, char const*, bool) (scanner.cc:2610) ==4096545==by 0x26466FC: gfc_new_file() (scanner.cc:2784) ==4096545==by 0x267F612: gfc_init() [clone .lto_priv.0] (f95-lang.cc:289) ==4096545==by 0x21FECD7: UnknownInlinedFun (toplev.cc:1903) ==4096545==by 0x21FECD7: UnknownInlinedFun (toplev.cc:2201) ==4096545==by 0x21FECD7: toplev::main(int, char**) (toplev.cc:2376) ==4096545==by 0x21FDF6A: main (main.cc:39) I see similar (but a bit different) with 13+14.
[Bug tree-optimization/117529] Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117529
--- Comment #3 from Kang-Che Sung ---
The func4 example that Andrew Pinski provided makes me realize that this func5
should optimize to the same code:
```c
bool func5(unsigned long long x, unsigned long long y)
{
if ((x | y) == 0) return 0;
unsigned long long res;
return __builtin_umulll_overflow(x, y, &res);
}
```
[Bug c++/117511] [12/13/14/15 Regression] internal compiler error: Segmentation fault at mark_used(tree_node*, int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117511 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Version|unknown |14.2.1
[Bug c++/117516] [12/13/14/15 Regression] compile time hog figuring out has flexarrays since r6-5791-g7e9a3ad30076ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117516 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/117529] Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117529
--- Comment #4 from Kang-Che Sung ---
Oops. Correction. I mean this:
```c
bool func5(unsigned long long x, unsigned long long y)
{
/* (x == 0 || y == 0) */
if ((x & y) == 0) return 0;
unsigned long long res;
return __builtin_umulll_overflow(x, y, &res);
}
```
[Bug c++/117530] [14/15 Regression] Mismatch of lambda type with itself in recursive alias declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117530 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/117519] [12/13/14/15 regression] LTO ICE when building gloox: lto1: internal compiler error: symtab_node::verify failed since r9-5035-g4611c03d2b0ede
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117519 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-11-11 Keywords||ice-on-valid-code CC||hubicka at gcc dot gnu.org Priority|P3 |P2 Target Milestone|--- |12.5 Status|UNCONFIRMED |NEW --- Comment #4 from Richard Biener --- Maybe.
[Bug rtl-optimization/117506] [15 Regression] ICE: in decompose, at wide-int.h:1049 with -O3 -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117506 Richard Biener changed: What|Removed |Added Last reconfirmed||2024-11-11 Ever confirmed|0 |1 Target Milestone|--- |15.0 Priority|P3 |P1 Status|UNCONFIRMED |NEW
[Bug target/117455] Nested function use gives a ld warning about executable stack, after binutils 2.39
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455 --- Comment #8 from rguenther at suse dot de --- On Sat, 9 Nov 2024, iains at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455 > > Iain Sandoe changed: > >What|Removed |Added > > Summary|ld warning about executable |Nested function use gives a >|stack, follows from PR |ld warning about executable >|117434 |stack, after binutils 2.39 > Depends on|117434 | >Keywords||diagnostic > Component|fortran |target > Target||x86_64-linux >See Also||https://gcc.gnu.org/bugzill >||a/show_bug.cgi?id=117434 > > --- Comment #7 from Iain Sandoe --- > Actually, > > * this is not specifically a fortran issue - the effect repeats complete with > a standard C nested function test: > > ./gcc/xgcc -Bgcc ../../test/nested/nest.c -o nc > /home/iains/gcc-master/gcc-15-0-0/x86_64-pc-linux-gnu/bin/ld: warning: > /tmp/ccyi2jqH.o: requires executable stack (because the .note.GNU-stack > section > is executable) > > * neither does it depend on 117434. although that does show the effect (I > would expect other fortran tests could quite easily use nested function > support). > > = > > To make heap-based trampolines the default for a platform needs the platform > maintainers to agree that's the right course of action (and support to be > written if it's not already there). Apart from Darwin, where we had no > choice, > that's also out of my pay grade. > > == > > But local to gfortran, you have some immediate options: > > 1. You could just add the appropriate flags to the test-case(s) to suppress > the warning (having decided, perhaps that fixing it is outside the purview of > gfortran). > > 2. you could decide to do (1) for every Fortran build by adding the relevant > option to the gfortran link specs. (would have to to be a configure-determined > action). > > 3. you could apply -ftrampoline-impl=heap instead of suppressing the warning > (on platforms that support it) - again this would need some configure-time > discovery if you wanted to add it to the link spec. [either to specific tests > or generally for gfortran]. With LTO there might be the need to support mixed operation - ideally we'd have a per-call way of specifying the trampoline type. The ABI on the callee side isn't necessarily the same between the two though (is it on x86?), so it might be more like a function attribute of the nested function [type] itself.
[Bug debug/117508] [12/13/14/15 Regression] Weird debug location info for C++ std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117508 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/117455] Nested function use gives a ld warning about executable stack, after binutils 2.39
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
--- Comment #11 from Iain Sandoe ---
(In reply to rguent...@suse.de from comment #10)
> On Mon, 11 Nov 2024, iains at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
> >
> > --- Comment #9 from Iain Sandoe ---
> > (In reply to rguent...@suse.de from comment #8)
> > > On Sat, 9 Nov 2024, iains at gcc dot gnu.org wrote:
> I was thinking of inlining the callers of nested functions from two TUs
> into the same function. Dependent of whether the choice of stack vs.
> heap trampoline is already reflected into the IL during nested function
> lowering or only at RTL expansion time this might or might not be
> an "interesting" setup (we can of course chose to not inline functions
> with nested function call ABI differences into the same function).
I think we're (probably) OK even for this - the nested lowering contains the
trampoline model and nested lowering is very early on (007) - long before
streaming.
The callee ABI is unchanged by the mechanism for the trampoline - so that so
long as the STATIC_CHAIN reg is setup properly it should not be able to tell
how it was called.
the nested lowering looks like:
stack:
```
D.2837 = __builtin_dwarf_cfa (0);
FRAME.2.FRAME_BASE.PARENT = D.2837;
FRAME.2.i = i;
__builtin_init_trampoline (&FRAME.2.bar, bar, &FRAME.2);
D.2829 = 10;
FRAME.2.counter = D.2829;
D.2834 = __builtin_adjust_trampoline (&FRAME.2.bar);
D.2835 = (void (*) (void)) D.2834;
```
heap:
```
try
{
D.2836 = __builtin_dwarf_cfa (0);
FRAME.2.FRAME_BASE.PARENT = D.2836;
FRAME.2.i = i;
__builtin___gcc_nested_func_ptr_created (&FRAME.2, bar, &FRAME.2.bar);
D.2829 = 10;
FRAME.2.counter = D.2829;
D.2833 = FRAME.2.bar;
D.2834 = (void (*) (void)) D.2833;
D.2830 = D.2834;
FRAME.2.f = D.2830;
D.2831 = FRAME.2.f;
D.2831 ();
}
finally
{
__builtin___gcc_nested_func_ptr_deleted ();
}
```
> That is, I was wondering whether having a per-function
> -ftrampoline-impl= flag would work without any other changes
I don't see why not - but it's more likely that a user or organisation would
set policy wider than that (i.e. I'm not sure what perceived security issue
would be solved at a single function boundary) - perhaps just not thinking
about it for long enough...
> - currently
> it's a TU wide flag but we do not enforce it to be the same during
> LTO options processing (lto-wrapper.cc:merge_and_complain), so the
> "first" TU wins in setting the LTRANS stages flag.
Tentatively (absent a way to test this) so long as we continue to link libgcc,
and libgcc provides the heap support, I'd say that's probably OK - we do not
revisit nested lowering later AFAIK. I suppose that if a platform decided to
implement the builtins in a CRT instead of libgcc, then having the right flag
on the link line might matter?
Iain
[Bug libstdc++/117520] C++26 std::text_encoding: == should be =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117520 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |14.3 Last reconfirmed||2024-11-11 Ever confirmed|0 |1
[Bug target/117525] [15 Regression] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952 since r15-2890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117525 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > `-O3 -fno-trapping-math` is enough to reproduce the ICE. I should mention without `-fno-trapping-math`, the ifcvt thinks (correctly) that the pattern cause a trap/exception/signal.
[Bug c++/117512] [14/15 Regression] ICE on x86_64-linux-gnu: in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with aligned on a field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117512 Marek Polacek changed: What|Removed |Added Summary|ICE on x86_64-linux-gnu: in |[14/15 Regression] ICE on |cp_gimplify_expr, at|x86_64-linux-gnu: in |cp/cp-gimplify.cc:911 with |cp_gimplify_expr, at |aligned on a field |cp/cp-gimplify.cc:911 with ||aligned on a field Priority|P3 |P2 Target Milestone|--- |14.3
[Bug c++/117512] ICE on x86_64-linux-gnu: in cp_gimplify_expr, at cp/cp-gimplify.cc:911 with aligned on a field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117512 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org, ||nshead at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Seems like this one started with r14-4771: commit 1d260ab0e39ea63644e3af3ab2e0db946026b5a6 Author: Nathaniel Shead Date: Thu Oct 12 19:53:55 2023 +1100 c++: indirect change of active union member in constexpr [PR101631,PR102286]
[Bug c++/117533] internal compiler error: Segmentation fault signal terminated program cc1plus with incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117533 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-11-11 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed. #1 0x00feba85 in dump_function_decl (pp=0x4ba3c60 , t=, flags=8193) at /home/mpolacek/src/gcc/gcc/cp/error.cc:1862 #2 0x00fe3d44 in dump_scope (pp=0x4ba3c60 , scope=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:357 #3 0x00fe6d18 in dump_aggr_type (pp=0x4ba3c60 , t=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:928 #4 0x00fe561c in dump_type (pp=0x4ba3c60 , t=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:696 #5 0x00fe3d04 in dump_scope (pp=0x4ba3c60 , scope=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:352 #6 0x00fe6d18 in dump_aggr_type (pp=0x4ba3c60 , t=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:928 #7 0x00fe561c in dump_type (pp=0x4ba3c60 , t=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:696 #8 0x00fedad9 in dump_parameters (pp=0x4ba3c60 , parmtypes=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:2034 #9 0x00fe73a6 in dump_aggr_type (pp=0x4ba3c60 , t=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:952 #10 0x00fe561c in dump_type (pp=0x4ba3c60 , t=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:696 #11 0x00fe3d04 in dump_scope (pp=0x4ba3c60 , scope=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:352 #12 0x00fe6d18 in dump_aggr_type (pp=0x4ba3c60 , t=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:928 #13 0x00fe561c in dump_type (pp=0x4ba3c60 , t=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:696 #14 0x00fedad9 in dump_parameters (pp=0x4ba3c60 , parmtypes=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:2034 #15 0x00fe73a6 in dump_aggr_type (pp=0x4ba3c60 , t=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:952 #16 0x00fe561c in dump_type (pp=0x4ba3c60 , t=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:696 #17 0x00fe3d04 in dump_scope (pp=0x4ba3c60 , scope=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:352 #18 0x00fe6d18 in dump_aggr_type (pp=0x4ba3c60 , t=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:928 #19 0x00fe561c in dump_type (pp=0x4ba3c60 , t=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:696 #20 0x00fedad9 in dump_parameters (pp=0x4ba3c60 , parmtypes=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:2034 #21 0x00fe73a6 in dump_aggr_type (pp=0x4ba3c60 , t=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:952 #22 0x00fe561c in dump_type (pp=0x4ba3c60 , t=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:696 #23 0x00fe3d04 in dump_scope (pp=0x4ba3c60 , scope=, flags=1) at /home/mpolacek/src/gcc/gcc/cp/error.cc:352 #24 0x00fe6d18 in dump_aggr_type (pp=0x4ba3c60 , t=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:928 #25 0x00fe561c in dump_type (pp=0x4ba3c60 , t=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:696 #26 0x00fedad9 in dump_parameters (pp=0x4ba3c60 , parmtypes=, flags=0) at /home/mpolacek/src/gcc/gcc/cp/error.cc:2034
[Bug libstdc++/117520] C++26 std::text_encoding: == should be =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117520 --- Comment #1 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:128f6a6d7af9cf187d59c1dbd9e59f5b782e17c8 commit r15-5107-g128f6a6d7af9cf187d59c1dbd9e59f5b782e17c8 Author: Jonathan Wakely Date: Mon Nov 11 11:54:00 2024 + libstdc++: Fix typos in iterator increment for std::text_encoding [PR117520] The intended behaviour for std::text_encoding::aliases_view's iterator is that it incrementing or decrementing too far sets it to a value-initialized state, or fails an assertion when those are enabled. There were typos that used == instead of = which meant that instead of becoming singular or aborting, an out-of-range increment just did nothing. This meant erroneous operations were well-defined and didn't produce any undefined behaviour, but were not diagnosed with assertions enabled, as had been intended. This change fixes the bugs and adds more tests to verify the intended behaviour. libstdc++-v3/ChangeLog: PR libstdc++/117520 * include/std/text_encoding (aliases_view:_Iterator::operator+=): Fix typos that caused == to be used instead of =. (aliases_view::_Iterator): Fix friend declaration. * testsuite/std/text_encoding/members.cc: Adjust expected behaviour of invalid subscript. Add tests for other erroneous operations on iterators.
[Bug c++/117463] [12/13/14/15 Regression] internal compiler error: Segmentation fault at is_nondependent_constant_expression(tree_node*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117463 --- Comment #4 from GCC Commits --- The master branch has been updated by Simon Martin : https://gcc.gnu.org/g:f32e7339871beec0e4d49698f7e34d77ee882088 commit r15-5110-gf32e7339871beec0e4d49698f7e34d77ee882088 Author: Simon Martin Date: Mon Nov 11 20:22:32 2024 +0100 c++: Fix another crash with invalid new operators [PR117463] Even though this PR is very close to PR117101, it's not addressed by the fix I made through r15-4958-g5821f5c8c89a05 because cxx_placement_new_fn has the very same issue as std_placement_new_fn_p used to have. As suggested by Jason, this patch changes both functions so that cxx_placement_new_fn leverages std_placement_new_fn_p which reduces code duplication and fixes the PR. PR c++/117463 gcc/cp/ChangeLog: * constexpr.cc (cxx_placement_new_fn): Implement in terms of std_placement_new_fn_p. * cp-tree.h (std_placement_new_fn_p): Declare. * init.cc (std_placement_new_fn_p): Add missing checks to ensure that fndecl is a non-replaceable ::operator new. gcc/testsuite/ChangeLog: * g++.dg/init/new54.C: New test.
[Bug c++/117463] [12/13/14/15 Regression] internal compiler error: Segmentation fault at is_nondependent_constant_expression(tree_node*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117463 Simon Martin changed: What|Removed |Added Target Milestone|12.5|15.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Simon Martin --- Fixed in GCC 15.
[Bug target/117525] [15 Regression] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952 since r15-2890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117525 --- Comment #10 from John David Anglin --- (In reply to Andrew Pinski from comment #7) > The way most other targets represent this is just (fix:SI (reg)) without the > inner most `fix:DF/SF` Thanks Andrew. Will test.
[Bug c++/117536] New: -Wshadow generates an incorrect warning with some usages of immediately invoked lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117536
Bug ID: 117536
Summary: -Wshadow generates an incorrect warning with some
usages of immediately invoked lambdas
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: justus at opentransactions dot org
Target Milestone: ---
struct my_type {};
my_type get_value();
void init_value(my_type&);
int main()
{
const auto my_var = [] {
auto my_var = get_value();
init_value(my_var);
return my_var;
}();
return 0;
}
: In lambda function:
:9:14: error: declaration of 'my_var' shadows a previous local
[-Werror=shadow]
9 | auto my_var = get_value();
| ^~
This is a bogus warning because neither usage of my_var is in scope at the same
time.
The scope for the other my_var doesn't begin until the scope of all the
variables in the immediately-invoked lambda ends.
[Bug middle-end/117525] [15 Regression] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117525 Andrew Pinski changed: What|Removed |Added Known to work||14.2.0 Keywords|needs-reduction | Known to fail||15.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |15.0 Last reconfirmed||2024-11-11 Summary|canvas.cc:1675:1: internal |[15 Regression] |compiler error: in |canvas.cc:1675:1: internal |expand_fix, at |compiler error: in |optabs.cc:5952 |expand_fix, at ||optabs.cc:5952 --- Comment #6 from Andrew Pinski --- Confirmed.
[Bug middle-end/117525] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117525 --- Comment #5 from Andrew Pinski --- Created attachment 59578 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59578&action=edit Reduced testcase
[Bug libgcc/117537] New: [15 regression] Failed cross build for aarch64_be-unknown-linux-gnu (libgcc/config/libbid/bid_conf.h:847:25: error: missing braces around initializer [-Werror=missing-braces])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117537
Bug ID: 117537
Summary: [15 regression] Failed cross build for
aarch64_be-unknown-linux-gnu
(libgcc/config/libbid/bid_conf.h:847:25: error:
missing braces around initializer
[-Werror=missing-braces])
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
CC: jsm28 at gcc dot gnu.org
Target Milestone: ---
Following some discussion on IRC today, I finally changed my various cross
builds to use trunk.
Anyway, this fell out:
```
/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/build/./gcc/xgcc
-B/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/build/./gcc/
-B/usr/aarch64_be-unknown-linux-gnu/bin/
-B/usr/aarch64_be-unknown-linux-gnu/lib/ -isystem
/usr/aarch64_be-unknown-linux-gnu/include -isystem
/usr/aarch64_be-unknown-linux-gnu/sys-include-g -O2 -O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-error=narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -fno-stack-clash-protection -Werror -Wno-prio-ctor-dtor
-fPIC -I. -I. -I../.././gcc
-I/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc
-I/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/.
-I/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/../gcc
-I/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/../include
-I/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -o bid128_to_uint64.o -MT
bid128_to_uint64.o -MD -MP -MF bid128_to_uint64.dep -c
/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/config/libbid/bid128_to_uint64.c
In file included from
/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/config/libbid/bid_internal.h:27,
from
/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/config/libbid/bid128_to_uint64.c:24:
/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/config/libbid/bid128_to_uint64.c:
In function '__bid128_to_uint64_rnint':
/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/config/libbid/bid_conf.h:847:25:
error: missing braces around initializer [-Werror=missing-braces]
847 |UINT128 arg_name={ bid_##arg_name.w[1], bid_##arg_name.w[0]};
| ^
/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/config/libbid/bid_conf.h:871:8:
note: in expansion of macro 'COPY_ARG_VAL'
871 |COPY_ARG_VAL(arg_name)
|^~~~
/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/config/libbid/bid_conf.h:1050:6:
note: in expansion of macro 'PROLOG_VAL'
1050 | PROLOG_VAL(arg_name) \
| ^~
/var/tmp/portage/cross-aarch64_be-unknown-linux-gnu/gcc-15.0.0_pre20241110/work/gcc-15-20241110/libgcc/config/libbid/bid128_to_uint64.c:30:1:
note: in expansion of macro 'BID128_FUNCTION_ARG1_NORND_CUSTOMRESTYPE'
30 | BID128_FUNCTION_ARG1_NORND_CUSTOMRESTYPE (UINT64,
| ^~~~
```
I assume this started with the libgcc change a little while ago from the arm
folks to enable -Werror for arm.
[Bug middle-end/117525] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117525 --- Comment #4 from John David Anglin --- (In reply to Andrew Pinski from comment #1) > convert_optab tab = unsignedp ? ufix_optab : sfix_optab; > libfunc = convert_optab_libfunc (tab, GET_MODE (to), GET_MODE (from)); > gcc_assert (libfunc); libfunc for sfix_optab for DFmode to DFmode is not found. I think this happens because target was NULL in first call to force_operand and 'to' mode is taken from 'value'.
[Bug gcov-profile/116743] [12/13/14/15 regression] Commit r12-5817-g3d9e6767939e96 causes ~10% perf regression w AutoFDO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116743 --- Comment #15 from Rama Malladi --- (In reply to Rama Malladi from comment #14) > Thanks Eugene. Were you able to review the repro and propose a fix? Hi Eugene, checking again. It would be great if you can look into it. Thanks.
[Bug target/117525] [15 Regression] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117525
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |target
--- Comment #7 from Andrew Pinski ---
(insn 14 13 15 3 (set (reg:SI 97 [ _11 ])
(fix:SI (fix:DF (reg/v:DF 99 [ width ] "t.cc":5:7 106
{fix_truncdfsi2}
(expr_list:REG_DEAD (reg/v:DF 99 [ width ])
(nil)))
/* With fixed-point machine mode:
Conversion of floating point operand to fixed point value.
Value is defined only when the operand's value is an integer.
With floating-point machine mode (and operand with same mode):
Operand is rounded toward zero to produce an integer value
represented in floating point. */
DEF_RTL_EXPR(FIX, "fix", "e", RTX_UNARY)
`-O3 -fno-trapping-math` is enough to reproduce the ICE.
The way most other targets represent this is just (fix:SI (reg)) without the
inner most `fix:DF/SF`
[Bug c++/117533] New: internal compiler error: Segmentation fault signal terminated program cc1plus with incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117533
Bug ID: 117533
Summary: internal compiler error: Segmentation fault signal
terminated program cc1plus with incomplete type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yihan4845 at gmail dot com
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/bzPojo1W4
The following program:
```cpp
class Empty {};
void use() {
[](volatile class Empty ;) {};
}
```
will trigger segmentation fault for gcc trunk.
Stack dump:
```
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 --- Comment #4 from Oliver Schönrock --- Is there anything I can do to help move this forward?
[Bug bootstrap/80677] LIMITS_H_TEST is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-11-11 Status|UNCONFIRMED |NEW --- Comment #6 from Sam James --- I hit this as well today and the patch helps.
[Bug tree-optimization/117502] Fail to SLP gcc.target/aarch64/sve/pr95199.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117502 --- Comment #1 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0b27a7dd050262a7d64d87863201e4ebbde88386 commit r15-5117-g0b27a7dd050262a7d64d87863201e4ebbde88386 Author: Richard Biener Date: Fri Nov 8 13:06:07 2024 +0100 tree-optimization/117502 - VMAT_STRIDED_SLP vs VMAT_ELEMENTWISE when considering gather The following treats both the same when considering to use gather or scatter for single-element interleaving accesses. This will cause FAIL: gcc.target/aarch64/sve/sve_iters_low_2.c scan-tree-dump-not vect "LOOP VECTORIZED" where we now vectorize the loop with VNx4QI, I'll leave it to ARM folks to investigate whether that's OK and to adjust the testcase or to see where to adjust things to make the testcase not vectorized again. The original fix for which the testcase was introduced is still efffective. PR tree-optimization/117502 * tree-vect-stmts.cc (get_group_load_store_type): Also consider VMAT_STRIDED_SLP when checking to use gather/scatter for single-element interleaving access. * tree-vect-loop.cc (update_epilogue_loop_vinfo): STMT_VINFO_STRIDED_P can be classified as VMAT_GATHER_SCATTER, so update DR_REF for those as well.
[Bug libgcc/117537] [15 regression] Failed cross build for aarch64_be-unknown-linux-gnu (libgcc/config/libbid/bid_conf.h:847:25: error: missing braces around initializer [-Werror=missing-braces])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117537 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0
[Bug tree-optimization/117484] [15 Regression] ICE: segfault during GIMPLE pass: vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117484 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed (finally).
[Bug tree-optimization/117484] [15 Regression] ICE: segfault during GIMPLE pass: vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117484 --- Comment #6 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:61cd1c43b82dc9d4c3edf122d22887fdce340223 commit r15-5118-g61cd1c43b82dc9d4c3edf122d22887fdce340223 Author: Richard Biener Date: Fri Nov 8 09:43:26 2024 +0100 tree-optimization/117484 - issue with SLP discovery of permuted .MASK_LOAD When we do SLP discovery of a .MASK_LOAD for a dataref group with gaps the discovery for the mask will have gaps as well and this was unexpected in a few places. The following re-organizes things slightly to accomodate for this. PR tree-optimization/117484 * tree-vect-slp.cc (vect_build_slp_tree_2): Handle gaps in mask discovery. Fix condition to release the load permutation. (vect_lower_load_permutations): Assert we get no load permutation for the unpermuted node. * tree-vect-slp-patterns.cc (linear_loads_p): Properly identify loads (without permutation). (compatible_complex_nodes_p): Likewise. * gcc.dg/vect/pr117484-1.c: New testcase. * gcc.dg/vect/pr117484-2.c: Likewise.
[Bug tree-optimization/113583] Main loop in 519.lbm not vectorized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
Li Pan changed:
What|Removed |Added
CC||pan2.li at intel dot com
--- Comment #20 from Li Pan ---
Add a macro expanded version of example that cannot vectorized with option
"riscv64-unknown-elf-gcc -Ofast -ffast-math -march=rv64gcv -c -S test.c -o -".
1 │ #define SX 100
2 │ #define SY 100
3 │ #define SZ 130
4 │ #define NN 20
5 │ #define OMEGA 0.123
6 │ #define LAMBDA (1.0 / (0.5 + 3.0 / (16.0 * (1.0 / OMEGA - 0.5
7 │ #define CST1 (1.0 / 3.0)
8 │ #define FEQS (CST1 * (1.0 + 4.5 * 1.0 * 1.0))
9 │
10 │ void
11 │ foo (double *src, double *dst)
12 │ {
13 │ double avg_diff;
14 │
15 │ for (unsigned i = 0; i < SX * SY * SZ * NN; i += NN)
16 │ {
17 │ avg_diff = 0.5 * (src[i + 1] + src[i + 2]) - FEQS;
18 │
19 │ dst[i] = src[i] - OMEGA * (src[i] - CST1 * 1.0);
20 │ dst[i + 1] = src[i + 1] - OMEGA * avg_diff - LAMBDA * (0.1 -
0.2);
21 │ }
22 │ }
[Bug middle-end/117542] Missed loop vectorization for truncate from float to __bf16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117542 Richard Biener changed: What|Removed |Added Blocks||53947 CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #1 from Richard Biener --- It doesn't even unambiguously specify whether the mode is that of the source or the destination. The original idea was of course that the size unambiguously specifies the destination mode and thus specifying it would be redundant. Making all those optabs conversion optabs has some overhead and is useless in 99% of the cases. Can you combine both destination mode variants in vec_pack_trunc_VnSF and use predicates to select? Or is HF/BF mode support not always both present or not present? You could implement truncVnSFVnBF which helps in some cases. I would expect aarch64 has the same issue. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476 --- Comment #25 from Alexey Merzlyakov --- Updates on GCC regression testing: Locally checked the GCC make check with enable-languages=all before the patching vs. r15-4991-g69bd93c167fefb + fix we are discussing in this ticket. Testing was performed natively on x86_64 and in cross-toolchain targeted for aarch64, riscv64 and mips32 under qemu-user simulation. The results are as follows: component x86_64 aarch64 riscv64 mips32 gcc.sum No regrsNo regrsNo regs No regs gfortran.sumNo regrsNo regrsNo regs No regs gm2.sum No regrsNo regrsNo regs No regs go.sum No regrsNo regrsNo regs No regs gotools.sum No regrsSkipSkipSkip g++.sum No regrsNo regrsNo regs No regs libatomic.sum No regrsNo regrsNo regs No regs libffi.sum No regrsNo regrsNo regrsNo regs libgomp.sum No regrsSkipSkipSkip libgo.sum No regrsSkipSkipSkip libitm.sum No regrsNo regrsNo regrsSkip libstdc++.sum No regrsNo regrsNo regrsNo regrs obj-c++.sum No regrsNo regrsNo regrsNo regrs objc.sumNo regrsNo regrsNo regrsNo regrs In this testing: * No regressions were detected on the above architectures * "image*" tests from libgo are confirmed to pass with latest fix on x86_64 (on other architectures GCC failed to compile testsuite in cross-mode) * Some thread-specific tests (like g++.dg/asan/deep-thread-stack-1.C or g++.dg/tls/thread_local4g.C) were detected to behave flaky on both: w/o r15-4991-g69bd93c167fefb patch and (patch + fix) cases. So, there is most likely not to be treated as regression. My apologies for long reply, testing took some time to check both cases and gather the results.
[Bug libstdc++/117541] New: vector::insert_range should not use ranges::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117541
Bug ID: 117541
Summary: vector::insert_range should not use ranges::copy
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Unlike vector::assign_range which requires assignable_from> is true, this means that ranges::copy is not
necessarily well-formed for vector::insert_range:
#include
struct Int {
void operator=(int) = delete;
Int(int);
};
int main() {
std::vector v;
v.insert_range(v.begin(), std::vector{42});
}
https://godbolt.org/z/jo3vjjo5b
[Bug c++/117280] Accessing a reference member of a volatile-qualified class glvalue is misinterpreted as volatile read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117280 --- Comment #2 from Jiang An --- https://cplusplus.github.io/CWG/issues/2957.html Let's suspend this. If it's determined that evaluating a reference member is an access, GCC's current behavior should be correct.
[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476 --- Comment #24 from Jeffrey A. Law --- My plan is to revert the problematic change tomorrow unless Alexey has a patch ready. There's no sense in having folks keep stumbling over this while Alexey is cobbling together a fix. It's not a reflection on Alexey, just trying to keep from wasting folks' time.
[Bug middle-end/117542] New: Missed loop vectorization for truncate from float to __bf16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117542
Bug ID: 117542
Summary: Missed loop vectorization for truncate from float to
__bf16.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
For loop vectorization, GCC relies on optab vec_pack_trunk_m to check if
backend supports that or not.
But the optab is already used by truncate from float to _Float16 and can't be
overloaded. The document only mention the dest has 2*N elements of size S/2,
but doesn't specify the dest mode and there're 2 kinds of half-precision
floating-point.
--
‘vec_pack_trunc_m’
Narrow (demote) and merge the elements of two vectors. Operands 1 and 2
are vectors of the same mode having N integral or floating point elements of
size S. Operand 0 is the resulting vector in which 2*N elements of size S/2 are
concatenated after narrowing them down using truncation.
--
void
foo (__bf16* a, float* b)
{
for (int i = 0; i != 1; i++)
a[i] = b[i];
}
couldn't vectorize loop
not vectorized: no vectype for stmt: _4 = *_3;
