[Bug tree-optimization/116518] GCC does not optimize-out useless operations. Clang does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116518
--- Comment #3 from Richard Biener ---
(In reply to Andrew Pinski from comment #1)
> ```
> __builtin_memcpy (_25, &MEM[(const struct array *)&D.94502]._M_elems, 3);
> D.94502 ={v} {CLOBBER(eos)};
> operator delete (_25, 3);
> ```
>
> The memcpy here is not deleted even though it is dead.
it's because 'operator delete' doesn't kill the storage, at least DSE
doesn't know about DECL_IS_OPERATOR_DELETE_P yet.
[Bug tree-optimization/116518] GCC does not optimize-out useless operations. Clang does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116518
--- Comment #4 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > ```
> > __builtin_memcpy (_25, &MEM[(const struct array *)&D.94502]._M_elems, 3);
> > D.94502 ={v} {CLOBBER(eos)};
> > operator delete (_25, 3);
> > ```
> >
> > The memcpy here is not deleted even though it is dead.
>
> it's because 'operator delete' doesn't kill the storage, at least DSE
> doesn't know about DECL_IS_OPERATOR_DELETE_P yet.
But also -fsane-operator-delete - delete could inspect memory contents
though its fnspec already says it doesn't.
[Bug ipa/116526] [12/13/14/15 Regression] ICE: in get_partitioning_class, at symtab.cc:2190 with -O -fopenacc -fprofile-generate -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116526 Richard Biener changed: What|Removed |Added Component|lto |ipa Target Milestone|--- |12.5 Keywords||lto
[Bug testsuite/116522] [15 regression] gcc.dg/ipa/ipa-icf-38.c: error executing dg-final after r15-3254-g3f51f0dc88ec21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116522
--- Comment #2 from Richard Biener ---
I also see with libgomp testing:
=== libgomp tests ===
Running target unix/
ERROR: (DejaGnu) proc "scan-not ltrans-tree {f04 \\(x}
{[0-9][0-9][0-9]t.optimiz
ed} .ltrans0.ltrans" does not exist.
ERROR: libgomp.c/declare-variant-1.c: error executing dg-final: invalid command
name "scan-not"
[Bug tree-optimization/116520] Multiple condition lead to missing vectorization due to missing early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||tnfchris at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2024-08-29 Ever confirmed|0 |1 Version|unknown |15.0 --- Comment #2 from Richard Biener --- The issue seems to be that if-conversion isn't done: Can not ifcvt due to multiple exits maybe my patched dev tree arrives with a different CFG here (no switches into ifcvt). I don't think if-conversion was adjusted when the vectorizer gained early exit vectorization - if-conversion shouldn't for example predicate with the exit condition and it should leave those conditions and exits around.
[Bug testsuite/116522] [15 regression] gcc.dg/ipa/ipa-icf-38.c: error executing dg-final after r15-3254-g3f51f0dc88ec21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116522 Alex Coplan changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org --- Comment #3 from Alex Coplan --- Apologies for the breakage, I think this is the usual problem of dg-cmp-results.sh not reporting new ERRORs (which is why I didn't see this in my regression testing). I need to work out a better way of comparing test results. I'll take a look.
[Bug tree-optimization/116520] Multiple condition lead to missing vectorization due to missing early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520 --- Comment #3 from Tamar Christina --- (In reply to Richard Biener from comment #2) > The issue seems to be that if-conversion isn't done: > > Can not ifcvt due to multiple exits > > maybe my patched dev tree arrives with a different CFG here (no switches > into ifcvt). I don't think if-conversion was adjusted when the vectorizer > gained early exit vectorization it was adjusted only to deal with bitfield lowering which was one of the scenarios we had on the roadmap. > - if-conversion shouldn't for example > predicate with the exit condition and it should leave those conditions > and exits around. How would if-cvt recover what reassoc did here though? [local count: 1044213920]: # s_15 = PHI _1 = *s_15; if (_1 > 63) goto ; [50.00%] else goto ; [50.00%] [local count: 522106960]: goto ; [100.00%] [local count: 522106960]: _14 = (int) _1; _17 = 9223372036854785024 >> _14; _18 = _17 & 1; _19 = _18 == 0; _12 = ~_19; [local count: 1044213920]: # prephitmp_4 = PHI <_12(4), 0(11)> _10 = _1 == 92; _13 = prephitmp_4 | _10; if (_13 != 0) goto ; [8.03%] else goto ; [91.97%] is the relevant block, wouldn't BB4 need to be fully predicated to be able to vectorize this? That also pushes this loop to only be vectorizable when fully masked where the original input doesn't require masking. As a side note, it looks like it's reassoc that's transforming and merging the conditions, i.e. https://godbolt.org/z/9Kfafvava I wonder if this transformation is really beneficial on modern cpus though. Seems like the compares are independent so the entire thing executes quite parallel?
[Bug c++/116506] [15 Regression] Destructors of temporary awaitables are executed too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116506 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-08-29 --- Comment #1 from Iain Sandoe --- thanks for the report, confirmed (I am working on a fix).
[Bug tree-optimization/116520] Multiple condition lead to missing vectorization due to missing early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520 --- Comment #4 from Tamar Christina --- (In reply to Tamar Christina from comment #3) > (In reply to Richard Biener from comment #2) > > The issue seems to be that if-conversion isn't done: > > I wonder if this transformation is really beneficial on modern cpus though. > Seems like the compares are independent so the entire thing executes quite > parallel? and with this I mean, the vector result from vectoring the unreassociated code, the scalar is obviously still a long dependency chain.
[Bug testsuite/116522] [15 regression] gcc.dg/ipa/ipa-icf-38.c: error executing dg-final after r15-3254-g3f51f0dc88ec21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116522 --- Comment #4 from Alex Coplan --- Testing a fix.
[Bug target/116086] RISC-V: Hash mismatch with vectorized 557.xz_r at zvl128b and LMUL=m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116086 --- Comment #10 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:4ff4875a79ccb302dc2401c32fe0af2187b61b99 commit r15-3282-g4ff4875a79ccb302dc2401c32fe0af2187b61b99 Author: Robin Dapp Date: Tue Aug 27 10:25:34 2024 +0200 RISC-V: Fix subreg of VLS modes larger than a vector [PR116086]. When the source mode is potentially larger than one vector (e.g. an LMUL2 mode for VLEN=128) we don't know which vector the subreg actually refers to. For zvl128b and LMUL=2 the subreg in (subreg:V2DI (reg:V4DI)) could actually be the a full (high) vector register of a two-register group (at VLEN=128) or the higher part of a single register (at VLEN>128). As the subreg is statically ambiguous we prevent such situations in can_change_mode_class. The culprit in PR116086 is _12 = BIT_FIELD_REF ; which can be expanded with a vector-vector extract (from V4DI to V2DI). This patch adds a VLS-mode vector-vector extract that handles "halving" cases like this one by sliding down the source vector, thus making sure the correct part is used. PR target/116086 gcc/ChangeLog: * config/riscv/autovec.md (vec_extract): Add vector-vector extract for VLS modes. * config/riscv/riscv.cc (riscv_can_change_mode_class): Forbid VLS modes larger than one vector. * config/riscv/vector-iterators.md: Add vector-vector extract iterators. gcc/testsuite/ChangeLog: * lib/target-supports.exp: Add effective target checks for zvl256b and zvl512b. * gcc.target/riscv/rvv/autovec/pr116086-2-run.c: New test. * gcc.target/riscv/rvv/autovec/pr116086-2.c: New test. * gcc.target/riscv/rvv/autovec/pr116086.c: New test.
[Bug target/116086] RISC-V: Hash mismatch with vectorized 557.xz_r at zvl128b and LMUL=m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116086 Robin Dapp changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Robin Dapp --- Fixed. As a reminder for posterity here: Richi called for a unified subreg handling and also argued (I agree) that LMUL > 1 VLS modes that are larger than a minimum-sized vector need to be treated like VLA modes. I don't think we do that everywhere already but let's fix things as they arise.
[Bug target/116242] [meta-bug] Tracker for zvl issues in RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242 Bug 116242 depends on bug 116086, which changed state. Bug 116086 Summary: RISC-V: Hash mismatch with vectorized 557.xz_r at zvl128b and LMUL=m2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116086 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug testsuite/116522] [15 regression] gcc.dg/ipa/ipa-icf-38.c: error executing dg-final after r15-3254-g3f51f0dc88ec21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116522
--- Comment #5 from Alex Coplan ---
The following should fix it:
diff --git a/gcc/testsuite/lib/scanltranstree.exp
b/gcc/testsuite/lib/scanltranstree.exp
index a7d4de3765f..3d85813ea2f 100644
--- a/gcc/testsuite/lib/scanltranstree.exp
+++ b/gcc/testsuite/lib/scanltranstree.exp
@@ -24,7 +24,7 @@ load_lib scandump.exp
foreach ir { tree rtl } {
foreach modifier { {} -not -dem -dem-not } {
eval [string map [list @NAME@ scan-ltrans-$ir-dump$modifier \
- @SCAN@ scan$modifier \
+ @SCAN@ scan-dump$modifier \
@TYPE@ ltrans-$ir \
@SUFFIX@ [string index $ir 0]] {
proc @NAME@ { args } {
will submit the above if testing goes OK.
[Bug c++/116531] New: Forward declaration with std::vector does not compile with -O on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116531
Bug ID: 116531
Summary: Forward declaration with std::vector does not compile
with -O on arm
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: homar at riseup dot net
Target Milestone: ---
Created attachment 59025
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59025&action=edit
Preprocessed source
The following minimal program does not compile on armel/armhf with -O. It
however *does* compile without the optimization flag, and with or without -O on
amd64 and other architectures.
$ cat fwdecl.cc
#include
class Elem;
struct List : std::vector {
List() {}
};
struct Elem {};
$ g++ -std=c++23 fwdecl.cc -c # works
$ g++ -std=c++23 fwdecl.cc -c -O -v# doesn't
Using built-in specs.
COLLECT_GCC=g++
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 14.2.0-2'
--with-bugurl=file:///usr/share/doc/gcc-14/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-14
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-sjlj-exceptions --with-arch=armv7-a+fp --with-float=hard
--with-mode=thumb --disable-werror --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.0 (Debian 14.2.0-2)
COLLECT_GCC_OPTIONS='-std=c++23' '-c' '-O' '-v' '-shared-libgcc'
'-mfloat-abi=hard' '-mtls-dialect=gnu' '-mthumb' '-mlibarch=armv7-a+fp'
'-march=armv7-a+fp'
/usr/libexec/gcc/arm-linux-gnueabihf/14/cc1plus -quiet -v -imultilib .
-imultiarch arm-linux-gnueabihf -D_GNU_SOURCE fwdecl.cc -D_TIME_BITS=64
-D_FILE_OFFSET_BITS=64 -quiet -dumpbase fwdecl.cc -dumpbase-ext .cc
-mfloat-abi=hard -mtls-dialect=gnu -mthumb -mlibarch=armv7-a+fp
-march=armv7-a+fp -O -std=c++23 -version -o /tmp/ccASUFF5.s
GNU C++23 (Debian 14.2.0-2) version 14.2.0 (arm-linux-gnueabihf)
compiled by GNU C version 14.2.0, GMP version 6.3.0, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP
GGC heuristics: --param ggc-min-expand=97 --param ggc-min-heapsize=127238
ignoring duplicate directory "/usr/include/arm-linux-gnueabihf/c++/14"
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabihf/14/include-fixed/arm-linux-gnueabihf"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabihf/14/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabihf/14/../../../../arm-linux-gnueabihf/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/14
/usr/include/arm-linux-gnueabihf/c++/14
/usr/include/c++/14/backward
/usr/lib/gcc/arm-linux-gnueabihf/14/include
/usr/local/include
/usr/include/arm-linux-gnueabihf
/usr/include
End of search list.
Compiler executable checksum: a94e6b605e56d9c12d47731d81ae510f
In file included from /usr/include/c++/14/vector:66,
from fwdecl.cc:1:
/usr/include/c++/14/bits/stl_vector.h: In instantiation of 'constexpr
std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp = Elem; _Alloc =
std::allocator]':
/usr/include/c++/14/bits/stl_vector.h:531:7: required from here
531 | vector() = default;
| ^~
/usr/include/c++/14/bits/stl_vector.h:369:49: error: invalid use of incomplete
type 'class Elem'
369 | _M_impl._M_end_of_storage - _M_impl._M_start);
| ~~^~
fwdecl.cc:2:7: note: forward declaration of 'class Elem'
2 | class Elem;
| ^~~~
[Bug c++/116531] Forward declaration with std::vector does not compile with -O on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116531 Richard Biener changed: What|Removed |Added Target||arm-linux-gnueabihf Keywords||rejects-valid --- Comment #1 from Richard Biener --- Works on x86_64-linux.
[Bug libstdc++/114298] std::lazy_split_view constructor is currently not explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114298 --- Comment #4 from Jonathan Wakely --- I think we decided we would backport them to '20
[Bug libstdc++/114298] std::lazy_split_view constructor is currently not explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114298 --- Comment #5 from Jonathan Wakely --- because LWG 3714 is an issue, and we treat most issues as DRs
[Bug libstdc++/116531] Forward declaration with std::vector does not compile with -O on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116531
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-08-29
--- Comment #2 from Jonathan Wakely ---
The error comes from the std::vector destructor, which does require the Elem
type to be complete. So the question is why List() { } requires the vector
destructor, and only for arm (an EABI difference?) and only for C++20 not
C++17.
I tried adding 'noexcept' to the List() constructor but that didn't change
anything.
I also tried commenting out the r14-9635-g142cc4c223d695 change adding a
requires-clause to a vector base class (which is a difference between C++17 and
C++20) but that didn't change it.
[Bug libstdc++/116529] Construction of unique_ptr with reference type is rejected because of auto_ptr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116529 --- Comment #1 from Jonathan Wakely --- -D_GLIBCXX_USE_DEPRECATED=0 allows it to compile
[Bug c++/116532] New: GCC accepts invaild static int iarr2 alignas(16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116532 Bug ID: 116532 Summary: GCC accepts invaild static int iarr2 alignas(16) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jlame646 at gmail dot com Target Milestone: --- GCC accepts invalid program shown below. https://godbolt.org/z/df95YbKW1 ``` static int iarr2 alignas(16); //accepted by all gcc,clang and msvc ``` This is not allowed by current grammar as explained here https://stackoverflow.com/questions/42692058/why-doesnt-alignas-compile-when-used-in-a-static-declaration-with-clang
[Bug target/116138] [15 regression] PGO+LTO bootstrap broken on aarch64 since r15-2196-g88d16194d0c8a6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116138 Andreas Schwab changed: What|Removed |Added Component|middle-end |target --- Comment #3 from Andreas Schwab --- This has been "fixed" by r15-3036-gb8ea13ebf12117 which means this is really a backend bug.
[Bug libstdc++/116529] Construction of unique_ptr with reference type is rejected because of auto_ptr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116529
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-08-29
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely ---
And this fixes it:
diff --git a/libstdc++-v3/include/backward/auto_ptr.h
b/libstdc++-v3/include/backward/auto_ptr.h
index 271a64d1de0..9e1318a9d9d 100644
--- a/libstdc++-v3/include/backward/auto_ptr.h
+++ b/libstdc++-v3/include/backward/auto_ptr.h
@@ -329,7 +329,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#endif // HOSTED
template
- template
+ template
inline
unique_ptr<_Tp, _Dp>::unique_ptr(auto_ptr<_Up>&& __u) noexcept
: _M_t(__u.release(), deleter_type()) { }
diff --git a/libstdc++-v3/include/bits/unique_ptr.h
b/libstdc++-v3/include/bits/unique_ptr.h
index 0f600db32f9..167136fe890 100644
--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -379,8 +379,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
/// Converting constructor from @c auto_ptr
- template, is_same<_Dp, default_delete<_Tp
+ template::type,
+ typename = _Require,
+ is_same<_Dp, default_delete<_Tp
unique_ptr(auto_ptr<_Up>&& __u) noexcept;
#pragma GCC diagnostic pop
#endif
[Bug libstdc++/116529] Construction of unique_ptr with reference type is rejected because of auto_ptr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116529 --- Comment #3 from Jonathan Wakely --- (In reply to Halalaluyafail3 from comment #0) > haven't seen any restrictions on using a unique_ptr with a reference type so > I assume that this is OK (since C++17). I'm not sure if that's actually intended, it's probably just an accident that it works.
[Bug c++/116533] New: Possibly missing SAVE_EXPR in get_member_function_from_ptrfunc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116533
Bug ID: 116533
Summary: Possibly missing SAVE_EXPR in
get_member_function_from_ptrfunc()
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This came up during the discussion of PR 116449.
get_member_function_from_ptrfunc() generates a statement with repeated
expressions, but the repeated expressions are not wrapped into SAVE_EXPRs.
This code
class C
{
public:
void P(int);
void IP();
int parr[16];
};
typedef void (C::*fp)();
typedef struct arr_t
{
fp func;
} arr_t;
static arr_t farr[1] =
{
{ &C::IP },
};
void C::P(int c)
{
((*this).*farr[parr[c]].func)();
}
results in this statement for C::P() in .original:
parr[c]].func.__delta)
+ (sizetype) ((long int) farr[((struct C *) this)->parr[c]].func.__pfn +
-1))
: farr[((struct C *) this)->parr[c]].func.__pfn
((struct C *) this + (sizetype) farr[((struct C *)
this)->parr[c]].func.__delta) >;
As you can see the terms "farr[((struct C *) this)->parr[c]].func" and
"farr[((struct C *) this)->parr[c]].func.__pfn" are used everywhere (condition
and both arms of the ternary).
Compiling results in the following .gimple:
void C::P (struct C * const this, int c)
{
void C:: (struct C *) * iftmp.0;
# DEBUG BEGIN_STMT
_1 = this->parr[c];
_2 = farr[_1].func.__pfn;
_3 = (long int) _2;
_4 = _3 & 1;
if (_4 != 0) goto ; else goto ;
:
_5 = this->parr[c];
_6 = farr[_5].func.__delta;
_7 = (sizetype) _6;
_8 = this + _7;
_9 = *_8;
_10 = this->parr[c];
_11 = farr[_10].func.__pfn;
_12 = (long int) _11;
_13 = _12 + -1;
_14 = (sizetype) _13;
_15 = _9 + _14;
iftmp.0 = *_15;
goto ;
:
_16 = this->parr[c];
iftmp.0 = farr[_16].func.__pfn;
:
iftmp.1_17 = iftmp.0;
_18 = this->parr[c];
_19 = farr[_18].func.__delta;
_20 = (sizetype) _19;
_21 = this + _20;
iftmp.1_17 (_21);
}
Now with this tentative patch:
@@ -4191,11 +4191,10 @@ get_member_function_from_ptrfunc (tree
*instance_ptrptr, tree function,
if (TREE_SIDE_EFFECTS (instance_ptr))
instance_ptr = instance_save_expr = save_expr (instance_ptr);
- if (TREE_SIDE_EFFECTS (function))
- function = save_expr (function);
+ function = save_expr(function);
/* Start by extracting all the information from the PMF itself. */
- e3 = pfn_from_ptrmemfunc (function);
+ e3 = save_expr(pfn_from_ptrmemfunc (function));
delta = delta_from_ptrmemfunc (function);
idx = build1 (NOP_EXPR, vtable_index_type, e3);
switch (TARGET_PTRMEMFUNC_VBIT_LOCATION)
results in this statement:
.__pfn> & 1) != 0)
? (void C:: (struct C *) *) *(*((int (*) () * *) this
+ (sizetype) SAVE_EXPR parr[c]].func>.__delta)
+ (sizetype) ((long int) SAVE_EXPR parr[c]].func>.__pfn> + -1))
: SAVE_EXPR parr[c]].func>.__pfn>
((struct C *) this + (sizetype) SAVE_EXPR parr[c]].func>.__delta) >;
and gimple like this:
void C::P (struct C * const this, int c)
{
void C:: (struct C *) * iftmp.0;
struct
{
void C:: (struct C *) * __pfn;
long int __delta;
} D.2853;
void C:: (struct C *) * D.2854;
# DEBUG BEGIN_STMT
_1 = this->parr[c];
D.2853 = farr[_1].func;
D.2854 = D.2853.__pfn;
_2 = (long int) D.2854;
_3 = _2 & 1;
if (_3 != 0) goto ; else goto ;
:
_4 = D.2853.__delta;
_5 = (sizetype) _4;
_6 = this + _5;
_7 = *_6;
_8 = (long int) D.2854;
_9 = _8 + -1;
_10 = (sizetype) _9;
_11 = _7 + _10;
iftmp.0 = *_11;
goto ;
:
iftmp.0 = D.2854;
:
iftmp.1_12 = iftmp.0;
_13 = D.2853.__delta;
_14 = (sizetype) _13;
_15 = this + _14;
iftmp.1_12 (_15);
}
In my eyes this gimple looks much better, but there maybe valid reasons why the
SAVE_EXPRs were not added before.
But a lot of the code in get_member_function_from_ptrfunc() is decades old
("75th Cygnus merge" for example), so it's hard
to find anything related in the ChangeLogs.
The tentative patch maybe incomplete and/or too broad, but it nicely shows
what's going on.
So, what do you think? Should more SAVE_EXPR be added in
get_member_function_from_ptrfunc()?
[Bug testsuite/116522] [15 regression] gcc.dg/ipa/ipa-icf-38.c: error executing dg-final after r15-3254-g3f51f0dc88ec21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116522
--- Comment #6 from GCC Commits ---
The master branch has been updated by Alex Coplan :
https://gcc.gnu.org/g:4b729d2ff3259e5b1d40f93d4f9e7edf5f0064f4
commit r15-3283-g4b729d2ff3259e5b1d40f93d4f9e7edf5f0064f4
Author: Alex Coplan
Date: Thu Aug 29 11:31:40 2024 +0100
testsuite: Fix up refactored scanltranstree.exp functions [PR116522]
When adding RTL variants of the scan-ltrans-tree* functions in:
r15-3254-g3f51f0dc88ec21c1ec79df694200f10ef85915f4
I messed up the name of the underlying scan function to invoke. The
code currently attempts to invoke functions named
scan{,-not,-dem,-dem-not} but should instead be invoking
scan-dump{,-not,-dem,-dem-not}. This patch fixes that.
gcc/testsuite/ChangeLog:
PR testsuite/116522
* lib/scanltranstree.exp: Fix name of underlying scan function
used for scan-ltrans-{tree,rtl}-dump{,-not,-dem,-dem-not}.
[Bug testsuite/116522] [15 regression] gcc.dg/ipa/ipa-icf-38.c: error executing dg-final after r15-3254-g3f51f0dc88ec21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116522 Alex Coplan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Alex Coplan --- Should be fixed, sorry for the breakage.
[Bug libstdc++/116531] Forward declaration with std::vector does not compile with -O on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116531 --- Comment #3 from Andrew Pinski --- > only for arm (an EABI difference?) Constructors return "this" for arm eabi (note aarch64 follows the original ia64 c++ abi here).
[Bug libstdc++/116531] Forward declaration with std::vector does not compile with -O on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116531 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > > only for arm (an EABI difference?) > > Constructors return "this" for arm eabi (note aarch64 follows the original > ia64 c++ abi here). Deconstructors too.
[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104 --- Comment #7 from GCC Commits --- The trunk branch has been updated by Arsen Arsenovic : https://gcc.gnu.org/g:d9c54e9a036189e8961ec17e118fccf794d7bfab commit r15-3285-gd9c54e9a036189e8961ec17e118fccf794d7bfab Author: Arsen ArsenoviÄ Date: Fri Aug 16 19:07:01 2024 +0200 c++: don't remove labels during coro-early-expand-ifns [PR105104] In some scenarios, it is possible for the CFG cleanup to cause one of the labels mentioned in CO_YIELD, which coro-early-expand-ifns intends to remove, to become part of some statement. As a result, when that label is removed, the statement it became part of becomes invalid, crashing the compiler. There doesn't appear to be a reason to remove the labels (anymore, at least), so let's not do that. PR c++/105104 gcc/ChangeLog: * coroutine-passes.cc (execute_early_expand_coro_ifns): Don't remove any labels. gcc/testsuite/ChangeLog: * g++.dg/coroutines/torture/pr105104.C: New test.
[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104 Arsen Arsenović changed: What|Removed |Added CC||arsen at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |arsen at gcc dot gnu.org Status|NEW |WAITING --- Comment #8 from Arsen Arsenović --- okay, fixed for trunk, possibly a backport candidate
[Bug c++/109867] -Wswitch-default reports missing default in coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109867 Arsen Arsenović changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |arsen at gcc dot gnu.org Status|NEW |WAITING --- Comment #5 from Arsen Arsenović --- fixed on trunk, possible backport candidate
[Bug c++/108620] coroutines: ICE: in instantiate_type, at cp/class.cc:8742 when assign the return value of co_yield to a member of class/struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620 --- Comment #7 from Iain Sandoe --- (In reply to Arsen Arsenović from comment #6) > I think it'd be okay to just add the testcase as a regression test consider > this resolved. WDYT, Iain? yes - if it's no longer reproducible - then adding the test case would catch any reappearance (in case it became latent). Let's do that and move on.
[Bug c++/113457] Nesting coroutine definitions (e.g. via a lambda or a template expansion) can ICE the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113457 Arsen Arsenović changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #10 from Arsen Arsenović --- fixed on trunk, maybe a backport candidate
[Bug c++/105475] coroutines: ICE in coerce_template_parms, at cp/pt.cc:9183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105475 Arsen Arsenović changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #6 from Arsen Arsenović --- fixed on trunk, maybe a backport candidate
[Bug target/115830] [avr] Make better use of SREG in conditional jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115830 --- Comment #2 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:07e5e054a1c579dec3e1ed2192992b2fea14ad40 commit r15-3286-g07e5e054a1c579dec3e1ed2192992b2fea14ad40 Author: Georg-Johann Lay Date: Sun Aug 4 19:46:43 2024 +0200 AVR: target/115830 - Make better use of SREG.N and SREG.Z. This patch adds new CC modes CCN and CCZN for operations that set SREG.N, resp. SREG.Z and SREG.N. Add peephole2 patterns to generate new compute + branch insns that make use of the Z and N flags. Most of these patterns need their own asm output routines that don't do all the micro-optimizations that the ordinary outputs may perform, as the latter have no requirement to set CC in a usable way. We don't use cmpelim because it cannot provide scratch regs (which peephole2 can), and some of the patterns require a scratch reg, whereas the same operations that don't set REG_CC don't require a scratch. See the comments in avr.md for details. The existing add.for.cc* patterns are simplified as they no more cover QImode, which is handled in a separate QImode case. Apart from that, it adds 3 patterns for subtractions and one pattern for shift left, all for multi-byte cases (HI, PSI, SI). The add.for.cc* patterns now use CC[Z]Nmode, instead of the formerly abuse of CCmode. PR target/115830 gcc/ * config/avr/avr-modes.def (CCN, CCZN): New CC_MODEs. * config/avr/avr-protos.h (avr_cond_branch): New from ret_cond_branch. (avr_out_plus_set_N, avr_op8_ZN_operator, avr_cmp0_code) (avr_out_op8_set_ZN, avr_len_op8_set_ZN): New protos. (ccn_reg_rtx, cczn_reg_rtx): New declarations. * config/avr/avr.cc (avr_cond_branch): New from ret_cond_branch. (avr_cond_string): Add bool cc_overflow_unusable argument. (avr_print_operand) ['L']: Like 'j' but overflow unusable. ['K']: Like 'k' but overflow unusable. (avr_out_plus_set_ZN): Remove handling of QImode. (avr_out_plus_set_N, avr_op8_ZN_operator, avr_cmp0_code) (avr_out_op8_set_ZN, avr_len_op8_set_ZN): New functions. (avr_adjust_insn_length) [ADJUST_LEN_ADD_SET_N]: Hande case. (avr_class_max_nregs): All MODE_CCs occupy one hard reg. (avr_hard_regno_nregs): Same. (avr_hard_regno_mode_ok) [REG_CC]: Allow all MODE_CC. (pass_manager.h, context.h, tree-pass.h): Include them. (ccn_reg_rtx, cczn_reg_rtx): New GTY variables. (avr_init_expanders): Initialize them. (avr_option_override): Run peephole2 a second time. * config/avr/avr.md (adjust_len) [add_set_N]: New attr value. (ALLCC, HI_SI): New mode iterators. (CCname): New mode attribute. (eqnegtle, cmp_signed, op8_ZN): New code iterators. (swap, SWAP): New code attributes. (branch): Handle CCNmode and CCZNmode. Assimilate... (difficult_branch): ...this insn. (p1m1): Remove. (gen_add_for__): Adjust to CCNmode and CCZNmode. Use HISI as mode iterator. Extend peephole2s that produce them. (*add.for.eqne.): Extend to *add.for.cc[z]n.. (*ashift.for.ccn.): New insn and peephole2 to make them. (*sub.for.cczn., *sub-extend.for.cczn.): New insns and peephole2s to make them. (*op8.for.cczn.): New insn and peephole2 to make them. * config/avr/predicates.md (const_1_to_3_operand) (abs1_abs2_operand, signed_comparison_operator) (op8_ZN_operator): New predicates. gcc/testsuite/ * gcc.target/avr/pr115830-add.c: New test. * gcc.target/avr/pr115830-add-c.c: New test. * gcc.target/avr/pr115830-add-i.c: New test. * gcc.target/avr/pr115830-and.c: New test. * gcc.target/avr/pr115830-asl.c: New test. * gcc.target/avr/pr115830-asr.c: New test. * gcc.target/avr/pr115830-ior.c: New test. * gcc.target/avr/pr115830-lsr.c: New test. * gcc.target/avr/pr115830-asl32.c: New test. * gcc.target/avr/pr115830-sub.c: New test. * gcc.target/avr/pr115830-sub-ext.c: New test.
[Bug c++/115905] [coroutines] Wrong behavior of await_suspend()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-08-29 Status|UNCONFIRMED |NEW CC||iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- after discussion, we are all agreed that the current behaviour is not per standard (or any supposed intent thereof).
[Bug target/115830] [avr] Make better use of SREG in conditional jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115830 Georg-Johann Lay changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Georg-Johann Lay --- Added in v15. For now, most cases are handled, except: * Multi-byte bit operations that set SREG.N. * Unary operations like NEG and COM.
[Bug rtl-optimization/116516] [15 Regression] [lra] ICE in decompose_normal_address, at rtlanal.cc:6712 by r15-3213-g708ee71808ea61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116516 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:ac6d433b02ce26a646b2a7254b1d87fcc06b0beb commit r15-3288-gac6d433b02ce26a646b2a7254b1d87fcc06b0beb Author: Richard Sandiford Date: Thu Aug 29 14:00:23 2024 +0100 Allow subregs around constant displacements [PR116516] This patch fixes a regression introduced by g:708ee71808ea61758e73. x86_64 allows addresses of the form: (zero_extend:DI (subreg:SI (symbol_ref:DI "foo") 0)) Before the previous patch, a lax SUBREG check meant that we would treat the subreg as a base and reload it into a base register. But that wasn't what the target was expecting. Instead we should treat "foo" as a constant displacement, to match: leal foo, After the patch, we recognised that "foo" isn't a base register, but ICEd on it rather than handling it as a displacement. With or without the recent patches, if the address had instead been: (zero_extend:DI (subreg:SI (plus:DI (reg:DI R) (symbol_ref:DI "foo") 0))) then we would have treated "foo" as the displacement and R as the base or index, as expected. The problem was that the code that does this was rejecting all subregs of objects, rather than just subregs of variable objects. gcc/ PR middle-end/116516 * rtlanal.cc (strip_address_mutations): Allow subregs around constant displacements. gcc/testsuite/ PR middle-end/116516 * gcc.c-torture/compile/pr116516.c: New test.
[Bug rtl-optimization/116516] [15 Regression] [lra] ICE in decompose_normal_address, at rtlanal.cc:6712 by r15-3213-g708ee71808ea61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116516 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Sandiford --- Hopefully fixed. Thanks for the report.
[Bug c++/90847] misplaced alignment-specifier not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90847 Marek Polacek changed: What|Removed |Added CC||jlame646 at gmail dot com --- Comment #5 from Marek Polacek --- *** Bug 116532 has been marked as a duplicate of this bug. ***
[Bug c++/116532] GCC accepts invaild static int iarr2 alignas(16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116532 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Marek Polacek --- Dup. *** This bug has been marked as a duplicate of bug 90847 ***
[Bug c++/90847] misplaced alignment-specifier not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90847 --- Comment #6 from Marek Polacek --- More: static int iarr2 alignas(16); //accepted by all gcc,clang and msvc
[Bug c++/116534] New: [14 regression] internal compiler error with comparison of pointers calculated with array offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116534
Bug ID: 116534
Summary: [14 regression] internal compiler error with
comparison of pointers calculated with array offset
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: john at drouhard dot dev
Target Milestone: ---
The following produces an internal compiler when compiled with -Wall starting
with gcc 14:
$ cat test.cpp
template
class Test {
void foo(unsigned x, unsigned y) {
bool test = &a[x] == &b[y];
}
unsigned *a;
unsigned *b;
};
$ g++ -Wall ./test.cpp
./test.cpp: In member function 'void Test::foo(unsigned int, unsigned int)':
./test.cpp:4:34: internal compiler error: Segmentation fault
4 | bool test = &a[x] == &b[y];
| ^
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug lto/116535] New: LTO partitioning vs. offloading compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116535
Bug ID: 116535
Summary: LTO partitioning vs. offloading compilation
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: openacc, openmp, wrong-code
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, hubicka at gcc dot gnu.org,
jakub at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
I ran into a curious issue re LTO partitioning vs. offloading compilation. I
guess what happened was that, given sufficiently high 'make -j', and only
'check-target-libgomp' running (which limits itself to 19 parallel slots), for
the '-flto -flto-partition=max' test cases
'libgomp.oacc-c-c++-common/data-clauses-{kernels,parallel}-ipa-pta.c', there
was actual parallel LTO compilation/partitioning, and these test cases then
FAIL, for example:
libgomp: Cannot map target functions or variables (expected 180 + 0 + 1,
have 11)
Running the compilation outside of 'make -j check', we see:
lto-wrapper: warning: using serial compilation of 36 LTRANS jobs
lto-wrapper: note: see the ‘-flto’ option documentation for more
information
..., and they execute successfully. However, for example, with '-flto=3
-flto-partition=max':
libgomp: Cannot map target functions or variables (expected 30 + 0 + 1,
have 11)
... where here '30' is 'N * 10' for '-flto=N'. So the "expected" number is
wrong.
This reproduces down to GCC 10:
libgomp: Cannot map target functions or variables (expected 30, have 10)
(..., so isn't related to the PR116361 LTO plugin changes.)
[Bug c++/116534] [14 regression] internal compiler error with comparison of pointers calculated with array offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116534 Marek Polacek changed: What|Removed |Added Last reconfirmed||2024-08-29 Keywords||ice-on-valid-code Priority|P3 |P2 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Target Milestone|--- |14.3 --- Comment #1 from Marek Polacek --- Started with r14-4793: commit dad311874ac3b3cf4eca1c04f67cae80c953f7b8 Author: Patrick Palka Date: Fri Oct 20 10:45:00 2023 -0400 c++: remove NON_DEPENDENT_EXPR, part 1
[Bug c++/116534] [14/15 regression] internal compiler error with comparison of pointers calculated with array offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116534 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Summary|[14 regression] internal|[14/15 regression] internal |compiler error with |compiler error with |comparison of pointers |comparison of pointers |calculated with array |calculated with array |offset |offset Status|NEW |ASSIGNED
[Bug middle-end/116508] [15 Regression] `popcount(short) == 1` or char no longer expands to using `(arg ^ (arg - 1)) > arg - 1` trick after r15-2946-gfcc3af99498804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116508
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:215c7e3084ea9ec75dcc803f73c94b36e2751e54
commit r15-3306-g215c7e3084ea9ec75dcc803f73c94b36e2751e54
Author: Andrew Pinski
Date: Wed Aug 28 15:03:53 2024 -0700
expand: Allow widdening optab when expanding popcount==1 [PR116508]
After adding popcount{qi,hi}2 to the aarch64 backend, I noticed that
the expansion for popcount==1 was no longer trying to do the trick
of handling popcount==1 as `(arg ^ (arg - 1)) > arg - 1`. The problem
is the expansion was using OPTAB_DIRECT, when using OPTAB_WIDEN
will allow modes which are smaller than SImode (in the aarch64 case).
Note QImode's cost still needs some improvements so part of popcnt-eq-1.c
is xfailed. Though there is a check to make sure the costs are compared
now.
Built and tested on aarch64-linux-gnu.
PR middle-end/116508
gcc/ChangeLog:
* internal-fn.cc (expand_POPCOUNT): Use OPTAB_WIDEN for PLUS and
XOR/AND expansion.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/popcnt-eq-1.c: New test.
Signed-off-by: Andrew Pinski
[Bug middle-end/116508] [15 Regression] `popcount(char) == 1` or char no longer expands to using `(arg ^ (arg - 1)) > arg - 1` trick after r15-2946-gfcc3af99498804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116508 Andrew Pinski changed: What|Removed |Added Summary|[15 Regression] |[15 Regression] |`popcount(short) == 1` or |`popcount(char) == 1` or |char no longer expands to |char no longer expands to |using `(arg ^ (arg - 1)) > |using `(arg ^ (arg - 1)) > |arg - 1` trick after|arg - 1` trick after |r15-2946-gfcc3af99498804|r15-2946-gfcc3af99498804 --- Comment #7 from Andrew Pinski --- short is fixed. char depends on cost. Will work back on that today.
[Bug target/113816] Using SVE bit op reduction for SLP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113816 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-08-29 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- .
[Bug testsuite/116536] New: [15 Regression] gcc.dg/ipa/ipa-icf-38.c: error executing dg-final since r15-3254-g3f51f0dc88e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116536 Bug ID: 116536 Summary: [15 Regression] gcc.dg/ipa/ipa-icf-38.c: error executing dg-final since r15-3254-g3f51f0dc88e Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ewlu at rivosinc dot com Target Milestone: --- We're seeing the following testsuite error on our postcommit ci https://github.com/patrick-rivos/gcc-postcommit-ci/issues/1624. ERROR: gcc.dg/ipa/ipa-icf-38.c: error executing dg-final: variable is not assigned by any conversion specifiers Bisected down to r15-3254-g3f51f0dc88e Test log Executing on host: /scratch/ewlu/ci/triage/riscv-gnu-toolchain/hash-3f51f0dc88ec21c1ec79df694200f10ef85915f4/build-gcc-linux-stage2/gcc/xgcc -B/scratch/ewlu/ci/triage/riscv-gnu-toolchain/hash-3f51f0dc88ec21c1ec79df694200f10ef85915f4/build-gcc-linux-stage2/gcc/ /scratch/ewlu/ci/triage/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c -march=rv64gc -mabi=lp64d -mcmodel=medlow -fdiagnostics-plain-output -O2 -fdump-ipa-icf-optimized -flto -fdump-tree-optimized -fno-ipa-vrp -flto-partition=one /scratch/ewlu/ci/triage/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.dg/ipa/ipa-icf-38a.c -dumpbase "" -lm -o ipa-icf-38.exe(timeout = 600) spawn -ignore SIGHUP /scratch/ewlu/ci/triage/riscv-gnu-toolchain/hash-3f51f0dc88ec21c1ec79df694200f10ef85915f4/build-gcc-linux-stage2/gcc/xgcc -B/scratch/ewlu/ci/triage/riscv-gnu-toolchain/hash-3f51f0dc88ec21c1ec79df694200f10ef85915f4/build-gcc-linux-stage2/gcc/ /scratch/ewlu/ci/triage/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c -march=rv64gc -mabi=lp64d -mcmodel=medlow -fdiagnostics-plain-output -O2 -fdump-ipa-icf-optimized -flto -fdump-tree-optimized -fno-ipa-vrp -flto-partition=one /scratch/ewlu/ci/triage/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.dg/ipa/ipa-icf-38a.c -dumpbase -lm -o ipa-icf-38.exe PASS: gcc.dg/ipa/ipa-icf-38.c (test for excess errors) PASS: gcc.dg/ipa/ipa-icf-38.c scan-wpa-ipa-dump icf "Semantic equality hit:foo/[0-9+]+->bar/[0-9+]+" PASS: gcc.dg/ipa/ipa-icf-38.c scan-wpa-ipa-dump icf "Equal symbols: 1" ERROR: gcc.dg/ipa/ipa-icf-38.c: error executing dg-final: variable is not assigned by any conversion specifiers UNSUPPORTED: gcc.dg/ipa/ipa-icf-38a.c
[Bug testsuite/116536] [15 Regression] gcc.dg/ipa/ipa-icf-38.c: error executing dg-final since r15-3254-g3f51f0dc88e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116536 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- This was fixed just within the last 12 hours. Dup. *** This bug has been marked as a duplicate of bug 116522 ***
[Bug testsuite/116522] [15 regression] gcc.dg/ipa/ipa-icf-38.c: error executing dg-final after r15-3254-g3f51f0dc88ec21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116522 Andrew Pinski changed: What|Removed |Added CC||ewlu at rivosinc dot com --- Comment #8 from Andrew Pinski --- *** Bug 116536 has been marked as a duplicate of this bug. ***
[Bug fortran/116530] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 kargls at comcast dot net changed: What|Removed |Added CC||kargls at comcast dot net --- Comment #1 from kargls at comcast dot net --- (In reply to philippe.wautelet from comment #0) > > I'm not sure it is conforming to the Fortran standard but it shouldn't > trigger an ICE. > I agree with you about the ICE should not happen. Staring at F2023, I find the following constraint. C8107 (R871) The namelist-group-name shall not be a name accessed by use association. If I understand it, your code is nonstandard. But, I don't use namelist, so will need to read through the Fortran standard a bit more.
[Bug testsuite/116271] [15 regression] gcc.dg/vect/tsvc/vect-tsvc-s176.c fails after r15-2777-g8fac69a2dbff98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116271 Thomas Schwinge changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |amylaar at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Keywords||testsuite-fail CC||tschwinge at gcc dot gnu.org --- Comment #5 from Thomas Schwinge --- Confirming fixed, thanks!
[Bug target/115830] [avr] Make better use of SREG in conditional jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115830 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |15.0
[Bug rtl-optimization/116321] [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321 --- Comment #7 from Georg-Johann Lay --- (In reply to GCC Commits from comment #6) > The PR is about an existing testcase that fails with LRA on m86k. > > gcc/ > PR middle-end/116321 > * lra-constraints.cc (get_hard_regno): Only apply eliminations > to existing hard registers. > (get_reg_class): Likewise. Hi Richard, as far as I can tell the bug is still somewhere in LRA. With your patch and -Os like in the initial report, the test compiles fine. But with -O0, it still breaks: $ avr-gcc -S lra-bug.c -O0 -mlra lra-bug.c:6:1: internal compiler error: in get_reload_reg, at lra-constraints.cc:755 6 | } | ^ gcc version 15.0.0 20240829 (experimental) (GCC) ...ok, the ICE is actually from a different place now (LRA instead of backend), so the remaining ICE is PR116326 I guess?
[Bug middle-end/116537] New: integer_three_node looks like it can be removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116537 Bug ID: 116537 Summary: integer_three_node looks like it can be removed Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- ChangeLog-2010: (integer_three_node): Add. ChangeLog-2010: NULL_TREE in build_int_cst calls. Initialize the integer_three_node. builtins.cc:arg2 = integer_three_node; cp/ChangeLog-2010: * decl.c (integer_three_node): Remove. cp/ChangeLog-2010: (cxx_init_decl_processing): Do not initialize the integer_three_node. cp/ChangeLog-2010: * cp-tree.h (integer_three_node): Remove. tree-ssa-loop-prefetch.cc: local = nontemporal ? integer_zero_node : integer_three_node; tree.cc: integer_three_node = build_int_cst (integer_type_node, 3); tree.h:#define integer_three_node global_trees[TI_INTEGER_THREE] Those are the only references to integer_three_node in the whole GCC tree. The use in builtins.cc is definitely not needed as it just calls expand_normal right afterwards. The use in tree-ssa-loop-prefetch.cc can just be replaced with `build_int_cst (integer_type_node, 3);` as this is definitely not a hot loop and move over the pass is not enabled for most of the time anyways.
[Bug middle-end/116537] integer_three_node looks like it can be removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116537 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-08-29 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- .
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE with member of namelist |[14/15 Regression] ICE with |renamed by use module |member of namelist renamed ||by use module Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Priority|P3 |P4 Known to work||13.3.0 Target Milestone|--- |14.3 Known to fail||14.1.0, 14.2.0, 15.0 Last reconfirmed||2024-08-29 --- Comment #2 from anlauf at gcc dot gnu.org --- Reduced testcase: module mod_nml1 logical :: ldiag namelist /nam_nml1/ldiag end module mod_nml1 module mod_interm use mod_nml1 end module mod_interm program ice_nml ! Interchanging the following two lines fixes the ICE: use mod_nml1, ldiag_nml1 => ldiag use mod_interm integer :: ilu read(unit=ilu,nml=nam_nml1) end program ice_nml Works with Intel, NAG, Nvidia, flang. As written above, interchanging the use statements fixes the ICE.
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #3 from anlauf at gcc dot gnu.org --- Tentative obvious fix for NULL pointer dereference: diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc index 7ab82fa2f5b..de38f4a808f 100644 --- a/gcc/fortran/trans-io.cc +++ b/gcc/fortran/trans-io.cc @@ -1692,7 +1692,8 @@ transfer_namelist_element (stmtblock_t * block, const char * var_name, gcc_assert (sym || c); /* Build the namelist object name. */ - if (sym && !sym->attr.use_only && sym->attr.use_rename) + if (sym && !sym->attr.use_only && sym->attr.use_rename + && sym->ns->use_stmts->rename) string = gfc_build_cstring_const (sym->ns->use_stmts->rename->local_name); else string = gfc_build_cstring_const (var_name);
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #1) > (In reply to philippe.wautelet from comment #0) > > > > > I'm not sure it is conforming to the Fortran standard but it shouldn't > > trigger an ICE. > > > > I agree with you about the ICE should not happen. Staring at F2023, > I find the following constraint. > > C8107 (R871) The namelist-group-name shall not be a name accessed by use > association. > > If I understand it, your code is nonstandard. But, I don't use namelist, so > will need to read through the Fortran standard a bit more. This constraint applies to the namelist statement and does not apply to the issue here.
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #5 from kargls at comcast dot net --- (In reply to anlauf from comment #4) > (In reply to kargls from comment #1) > > (In reply to philippe.wautelet from comment #0) > > > > > > > > I'm not sure it is conforming to the Fortran standard but it shouldn't > > > trigger an ICE. > > > > > > > I agree with you about the ICE should not happen. Staring at F2023, > > I find the following constraint. > > > > C8107 (R871) The namelist-group-name shall not be a name accessed by use > > association. > > > > If I understand it, your code is nonstandard. But, I don't use namelist, so > > will need to read through the Fortran standard a bit more. > > This constraint applies to the namelist statement and does not apply to the > issue here. Yeah, I needed to review more the Fortran, and you beat me to working out a patch. The '(R871)' above restricts the constraint to namelist statement. However, this did lead to module mod_nml1 implicit none logical :: ldiag namelist /nam_nml1/ldiag end module mod_nml1 program ice_nml use mod_nml1 implicit none integer :: ilu, j namelist /nam_nml1/j !<-- Does this violates C8107? ldiag = .false. j = 42 write(*,nml=nam_nml1) end program ice_nml % gfcx -o z a.f90 && ./z &NAM_NML1 LDIAG=F, J=42 , /
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #5) > (In reply to anlauf from comment #4) > > (In reply to kargls from comment #1) > > > (In reply to philippe.wautelet from comment #0) > > > > > > > > > > > I'm not sure it is conforming to the Fortran standard but it shouldn't > > > > trigger an ICE. > > > > > > > > > > I agree with you about the ICE should not happen. Staring at F2023, > > > I find the following constraint. > > > > > > C8107 (R871) The namelist-group-name shall not be a name accessed by use > > > association. > > > > > > If I understand it, your code is nonstandard. But, I don't use namelist, > > > so > > > will need to read through the Fortran standard a bit more. > > > > This constraint applies to the namelist statement and does not apply to the > > issue here. > > Yeah, I needed to review more the Fortran, and you beat me > to working out a patch. The '(R871)' above restricts the > constraint to namelist statement. However, this did lead to > > module mod_nml1 >implicit none >logical :: ldiag >namelist /nam_nml1/ldiag > end module mod_nml1 > > program ice_nml >use mod_nml1 >implicit none >integer :: ilu, j >namelist /nam_nml1/j !<-- Does this violates C8107? Yes, that is illegal and rejected by Intel and NAG, e.g.: NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7200 Error: iii.f90, line 11: Redeclaration of symbol NAM_NML1 from USEd module MOD_NML1 detected at /@NAM_NML1 Warning: iii.f90, line 15: Unused local variable ILU [NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning] I think we should track that constraint violation separately (no regression) from the present PR (regression). >ldiag = .false. >j = 42 >write(*,nml=nam_nml1) > end program ice_nml > > % gfcx -o z a.f90 && ./z > &NAM_NML1 > LDIAG=F, > J=42 , > /
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #6 from kargls at comcast dot net --- (In reply to anlauf from comment #3) > Tentative obvious fix for NULL pointer dereference: > > diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc > index 7ab82fa2f5b..de38f4a808f 100644 > --- a/gcc/fortran/trans-io.cc > +++ b/gcc/fortran/trans-io.cc > @@ -1692,7 +1692,8 @@ transfer_namelist_element (stmtblock_t * block, const > char * var_name, >gcc_assert (sym || c); > >/* Build the namelist object name. */ > - if (sym && !sym->attr.use_only && sym->attr.use_rename) > + if (sym && !sym->attr.use_only && sym->attr.use_rename > + && sym->ns->use_stmts->rename) > string = gfc_build_cstring_const > (sym->ns->use_stmts->rename->local_name); >else > string = gfc_build_cstring_const (var_name); Patch looks good. If it passes regression testing, you can commit it you want.
[Bug c++/116369] [12/13/14/15 Regression] temporary variable bounded to const reference with mutable field incorrectly marked as rodata since r9-869-g5603790dbf233c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116369 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Priority|P3 |P2
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #6) > (In reply to anlauf from comment #3) > > Tentative obvious fix for NULL pointer dereference: > > > > diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc > > index 7ab82fa2f5b..de38f4a808f 100644 > > --- a/gcc/fortran/trans-io.cc > > +++ b/gcc/fortran/trans-io.cc > > @@ -1692,7 +1692,8 @@ transfer_namelist_element (stmtblock_t * block, const > > char * var_name, > >gcc_assert (sym || c); > > > >/* Build the namelist object name. */ > > - if (sym && !sym->attr.use_only && sym->attr.use_rename) > > + if (sym && !sym->attr.use_only && sym->attr.use_rename > > + && sym->ns->use_stmts->rename) > > string = gfc_build_cstring_const > > (sym->ns->use_stmts->rename->local_name); > >else > > string = gfc_build_cstring_const (var_name); > > Patch looks good. If it passes regression testing, you can commit it you > want. Yes, it passed. I was just packaging it for submission, but given your OK I will push to master and inform the list.
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #9 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6bfeba12c86b4d0dae27d99b484f64774dd49398 commit r15-3308-g6bfeba12c86b4d0dae27d99b484f64774dd49398 Author: Harald Anlauf Date: Thu Aug 29 21:21:39 2024 +0200 Fortran: fix ICE with use with rename of namelist member [PR116530] gcc/fortran/ChangeLog: PR fortran/116530 * trans-io.cc (transfer_namelist_element): Prevent NULL pointer dereference. gcc/testsuite/ChangeLog: PR fortran/116530 * gfortran.dg/use_rename_12.f90: New test.
[Bug rtl-optimization/116516] [15 Regression] [lra] ICE in decompose_normal_address, at rtlanal.cc:6712 by r15-3213-g708ee71808ea61
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116516
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment #8 from Sergei Trofimovich ---
The change fixed ICE on linux-6.10.6 for me.
Thank you!
In case it's useful `cvise` reduced kernel's arch/x86/kernel/cpu/common.c into
the following:
// $ cat common.c.c
void entry_SYSENTER_compat(void)
{
unsigned low = (long)entry_SYSENTER_compat;
asm (""::"S"((long)low));
}
Before the fix gcc crashed as:
$ gcc -O2 -c common.c.c -o bug.o
during RTL pass: reload
common.c.c: In function 'entry_SYSENTER_compat':
common.c.c:5:1: internal compiler error: in decompose_normal_address, at
rtlanal.cc:6712
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline so far.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #208 from John Paul Adrian Glaubitz ---
Building with Go enabled, fails with:
during RTL pass: subreg3
../../../libgo/go/unicode/utf16/utf16.go: In function 'unicode/utf16.Encode':
../../../libgo/go/unicode/utf16/utf16.go:56:1: internal compiler error: in
decompose_multiword_subregs, at lower-subreg.cc:1728
56 | func Encode(s []rune) []uint16 {
| ^
libtool: compile: /srv/glaubitz/gcc/build/./gcc/gccgo
-B/srv/glaubitz/gcc/build/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=internal/itoa ../../../libgo/go/internal/itoa/itoa.go -o
internal/itoa.o >/dev/null 2>&1
libtool: compile: /srv/glaubitz/gcc/build/./gcc/gccgo
-B/srv/glaubitz/gcc/build/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=sync/atomic ../../../libgo/go/sync/atomic/doc.go
../../../libgo/go/sync/atomic/unaligned.go
../../../libgo/go/sync/atomic/value.go -o sync/atomic.o >/dev/null 2>&1
libtool: compile: /srv/glaubitz/gcc/build/./gcc/gccgo
-B/srv/glaubitz/gcc/build/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=container/ring ../../../libgo/go/container/ring/ring.go -o
container/ring.o >/dev/null 2>&1
0x1872ddb internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:491
0x67aca7 fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1772
0x173af73 decompose_multiword_subregs
../../gcc/lower-subreg.cc:1728
0x173b8bf execute
../../gcc/lower-subreg.cc:1849
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #13 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-August/060931.html
[Bug testsuite/116143] [15 regression] gcc.dg/plugin/diagnostic-* test fails intermittently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116143 --- Comment #7 from seurer at gcc dot gnu.org --- I was wrong initially about this being intermittent. It always fails for a compiler built with --enable-checking=release and it started with r15-1410-gf89f9c7ae7190c
[Bug target/113939] Switch m68k to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939 --- Comment #4 from Jeffrey A. Law --- Spinning. Should have some results tomorrow.
[Bug other/116419] RFE: capture URLs in SARIF messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116419 --- Comment #5 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:aff7f677120ec394adcedd0dd5cc3afa3b5be102 commit r15-3312-gaff7f677120ec394adcedd0dd5cc3afa3b5be102 Author: David Malcolm Date: Thu Aug 29 18:48:32 2024 -0400 SARIF output: implement embedded URLs in messages (§3.11.6; PR other/116419) GCC diagnostic messages can contain URLs, such as to our documentation when we suggest an option name to correct a misspelling. SARIF message strings can contain embedded URLs in the plain text messages (see SARIF v2.1.0 §3.11.6), but previously we were simply dropping any URLs from the diagnostic messages. This patch adds support for encoding URLs into messages in our SARIF output, using the pp_token machinery added in the previous patch. As well as supporting URLs, the patch also adjusts how we report event IDs in SARIF message, so that rather than e.g. "text": "second 'free' here; first 'free' was at (1)" we now report: "text": "second 'free' here; first 'free' was at [(1)](sarif:/runs/0/results/0/codeFlows/0/threadFlows/0/locations/0)" i.e. the text "(1)" now has a embedded link referring within the sarif log to the threadFlowLocation object for the other event, via JSON pointer (see §3.10.3 "URIs that use the sarif scheme"). Doing so requires the arious objects to know their index within their containing array, requiring some reworking of how they are constructed. gcc/ChangeLog: PR other/116419 * diagnostic-event-id.h (diagnostic_event_id_t::zero_based): New. * diagnostic-format-sarif.cc: Include "pretty-print-format-impl.h" and "pretty-print-urlifier.h". (sarif_result::sarif_result): Add param "idx_within_parent". (sarif_result::get_index_within_parent): New accessor. (sarif_result::m_idx_within_parent): New field. (sarif_code_flow::sarif_code_flow): New ctor. (sarif_code_flow::get_parent): New accessor. (sarif_code_flow::get_index_within_parent): New accessor. (sarif_code_flow::m_parent): New field. (sarif_code_flow::m_thread_id_map): New field. (sarif_code_flow::m_thread_flows_arr): New field. (sarif_code_flow::m_all_tfl_objs): New field. (sarif_thread_flow::sarif_thread_flow): Add "parent" and "idx_within_parent" params. (sarif_thread_flow::get_parent): New accessor. (sarif_thread_flow::get_index_within_parent): New accessor. (sarif_thread_flow::m_parent): New field. (sarif_thread_flow::m_idx_within_parent): New field. (sarif_thread_flow_location::sarif_thread_flow_location): New ctor. (sarif_thread_flow_location::get_parent): New accessor. (sarif_thread_flow_location::get_index_within_parent): New accessor. (sarif_thread_flow_location::m_parent): New field. (sarif_thread_flow_location::m_idx_within_parent): New field. (sarif_builder::get_code_flow_for_event_ids): New accessor. (class sarif_builder::sarif_token_printer): New. (sarif_builder::m_token_printer): New member. (sarif_builder::m_next_result_idx): New field. (sarif_builder::m_current_code_flow): New field. (sarif_code_flow::get_or_append_thread_flow): New. (sarif_code_flow::get_thread_flow): New. (sarif_code_flow::add_location): New. (sarif_code_flow::get_thread_flow_loc_obj): New. (sarif_thread_flow::add_location): Create the new sarif_thread_flow_location internally, rather than passing it in as a parm so that we can keep track of its index in the array. Return a reference to it. (sarif_builder::sarif_builder): Initialize m_token_printer, m_next_result_idx, and m_current_code_flow. (sarif_builder::on_report_diagnostic): Pass index to make_result_object. (sarif_builder::make_result_object): Add "idx_within_parent" param and pass to sarif_result ctor. Pass code flow index to call to make_code_flow_object. (make_sarif_url_for_event): New. (sarif_builder::make_code_flow_object): Add "idx_within_parent" param and pass it to sarif_code_flow ctor. Reimplement walking of events so that we first create threadFlow objects for each thread, then populate them with threadFlowLocation objects, so that the IDs work. Set m_current_code_flow whilst creating the latter, so that we can create correct URIs for "%@". (sarif_builder::make_thread_flow_location_object): Replace with... (sarif_builder::populate_th
[Bug middle-end/116537] integer_three_node looks like it can be removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116537 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661831.html https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661832.html
[Bug other/116419] RFE: capture URLs in SARIF messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116419 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from David Malcolm --- Should be implemented by the above patch for GCC 15.
[Bug middle-end/94787] Failure to detect single bit popcount pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94787 --- Comment #8 from Andrew Pinski --- Created attachment 59026 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59026&action=edit The (pop cmp 1) |& (a cmp 0) testcase This is the full one. Note `a ? 1 : b` is also reduced down to `a | b` (etc.) So I am still deciding on how to handle this in a reasonable fashion.
[Bug other/116525] Commit hook allows empty ChangeLog entry description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116525 --- Comment #2 from Hans-Peter Nilsson --- (In reply to Andrew Pinski from comment #1) > I think it is more related the changelog for testsuite rather than anything > else. Can you please elaborate? There are scripts in contrib/gcc-changelog/ yes, common to ChangeLog generation and server-side pre-commit hook, but I can't see that this empty-entry wart is specific to entries for the testsuite. Perhaps the contrib/mklog.py script can be improved too, so it emits e.g. "PLACEHOLDER." instead of leaving the entry empty; more eye-catching. Did you use that script or did you write the entry in the example commit "manually"?
[Bug middle-end/116538] New: GET_MODE_BITSIZE() returns wrong value for PSImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116538
Bug ID: 116538
Summary: GET_MODE_BITSIZE() returns wrong value for PSImode
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: alancf0 at gmail dot com
Target Milestone: ---
Target: msp430-none-elf
Some targets (ie, msp430-none-elf with the -mlarge flag) have size_t and
pointer types with a size between HImode and SImode; the size of this type is
often not a multiple of 8 bits. In the case of msp430 with -mlarge, PSImode is
20 bits. The current implementation of GET_MODE_BITSIZE() is as follows:
/* Return the base GET_MODE_BITSIZE value for MODE. */
ALWAYS_INLINE poly_uint16
mode_to_bits (machine_mode mode)
{
return mode_to_bytes (mode) * BITS_PER_UNIT;
}
This obviously does not return the correct value for types whose size is not a
multiple of one byte. One possible patch, which mirrors the above
mode_to_bytes():
diff -ur gcc-12.2.0/gcc/machmode.h ../gcc-12.2.0/gcc/machmode.h
--- gcc-12.2.0/gcc/machmode.h 2022-08-19 01:09:52.940667079 -0700
+++ ../gcc-12.2.0/gcc/machmode.h2024-08-29 21:51:01.099313215 -0700
@@ -558,7 +558,12 @@
ALWAYS_INLINE poly_uint16
mode_to_bits (machine_mode mode)
{
- return mode_to_bytes (mode) * BITS_PER_UNIT;
+#if GCC_VERSION >= 4001
+ return (__builtin_constant_p (mode)
+ ? mode_unit_precision_inline (mode) : mode_unit_precision[mode]);
+#else
+ return mode_unit_precision[mode];
+#endif
}
/* Return the base GET_MODE_PRECISION value for MODE. */
Note: I have not tested this patch extensively; perhaps in context it is
necessary for mode_to_bits to return a value which is a multiple of 8.
[Bug middle-end/116538] GET_MODE_BITSIZE() returns wrong value for PSImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116538 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- GET_MODE_BITSIZE is supposed to be the size of gets loaded/stored to memory so it should be 24bits which should always be a mutiply of BITS_PER_UNIT. While GET_MODE_PRECISION tells how many bits are in the precision fo the mode. Now there could be places where GET_MODE_PRECISION should be used instead of GET_MODE_BITSIZE but you didn't mention that and all.
[Bug middle-end/116538] GET_MODE_BITSIZE() returns wrong value for PSImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116538 --- Comment #2 from Andrew Pinski --- Note on x86, XFmode has mode_to_bits which is 128 or 96 but precision is 80. So changing mode_to_bits to return precision is 100% the wrong thing. So the bug might be the case there is a place which is using GET_MODE_BITSIZE but should be using GET_MODE_PRECISION . But changing GET_MODE_BITSIZE to be the same GET_MODE_PRECISION is wrong.
[Bug target/116512] [12/13/14/15 Regression] vzeroupper emitted even though the upper half of the z registers are returned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116512 --- Comment #7 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:ab214ef734bfc3dcffcf79ff9e1dd651c2b40566 commit r15-3314-gab214ef734bfc3dcffcf79ff9e1dd651c2b40566 Author: liuhongt Date: Thu Aug 29 11:39:20 2024 +0800 Check avx upper register for parallel. For function arguments/return, when it's BLK mode, it's put in a parallel with an expr_list, and the expr_list contains the real mode and registers. Current ix86_check_avx_upper_register only checked for SSE_REG_P, and failed to handle that. The patch extend the handle to each subrtx. gcc/ChangeLog: PR target/116512 * config/i386/i386.cc (ix86_check_avx_upper_register): Iterate subrtx to scan for avx upper register. (ix86_check_avx_upper_stores): Inline old ix86_check_avx_upper_register. (ix86_avx_u128_mode_needed): Ditto, and replace FOR_EACH_SUBRTX with call to new ix86_check_avx_upper_register. gcc/testsuite/ChangeLog: * gcc.target/i386/pr116512.c: New test.
