[Bug middle-end/85000] OpenMP and nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85000 --- Comment #3 from Andrew Pinski --- *** Bug 100661 has been marked as a duplicate of this bug. ***
[Bug c/100661] ICE in omp-low.c / refs_may_alias_p_2, at tree-ssa-alias.c:2460 with nested function in OMP region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100661 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 85000 ***
[Bug libstdc++/114553] Undefined symbol in directory_iterator move assignment operator with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114553
--- Comment #1 from Andrew Pinski ---
Just FYI. this is the uninclude example:
```
#include "filesystem"
namespace fs = std::filesystem;
int main() {
auto iter = fs::directory_iterator();
iter = fs::directory_iterator();
}
```
Because this is a libstdc++ issue with the shared library and not exporting the
"right thing" as -static-libstdc++ works.
[Bug c++/114553] New: Undefined symbol in directory_iterator move assignment operator with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114553 Bug ID: 114553 Summary: Undefined symbol in directory_iterator move assignment operator with -Os Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: toni.lammi at kone dot com Target Milestone: --- Created attachment 57842 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57842=edit save-temps Compiling code containing std::directory_iterator move assignment fails when -Os option is passed. The build was performed in Manjaro Linux. This happens with both GNU ld and mold linkers: $ g++ -save-temps -std=c++20 -Os -o gcc_err ./gcc_err.cpp /usr/bin/ld: gcc_err.o: in function `main': gcc_err.cpp:(.text.startup+0x3f): undefined reference to `std::__shared_ptr::swap(std::__shared_ptr&)' collect2: error: ld returned 1 exit status $ g++ -std=c++20 -Os -o gcc_err -fuse-ld=mold ./gcc_err.cpp mold: error: undefined symbol: std::__shared_ptr::swap(std::__shared_ptr&) >>> referenced by gcc_err.cpp >>> gcc_err.o:(main) collect2: error: ld returned 1 exit status When not optimizing for size everything works fine: $ g++ -std=c++20 -O3 -o gcc_err ./gcc_err.cpp In compiler explorer (https://godbolt.org/) I can replicate this with g++ versions 13.2, 12.3 and 11.4. The issue does not seem to be present in trunk.
[Bug analyzer/101713] -Wanalyzer-malloc-leak false positive with GNU coreutils hash table code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101713 Eric Gallager changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-02 --- Comment #3 from Eric Gallager --- Confirming due to the link to it from gnulib's manywarnings.m4
[Bug rtl-optimization/79688] ICE with a RTL test-case and -O1 provided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79688 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking --- Comment #4 from Andrew Pinski --- gcc_assert (bitmap_equal_p (regular_block_artificial_uses, >regular_block_artificial_uses)); The assert which is failing.
[Bug libgomp/83046] ICE in nvptx offloading, C++ compilation of libgomp.oacc-c-c++-common/gang-static-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83046 --- Comment #21 from Andrew Pinski --- *** Bug 80411 has been marked as a duplicate of this bug. ***
[Bug middle-end/80411] DCE vs. offloading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80411 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 83046 ***
[Bug target/63902] ix86_valid_target_attribute_tree frees memory still being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63902 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup and fixed alread. *** This bug has been marked as a duplicate of bug 71652 ***
[Bug target/71652] [5/6/7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71652 Andrew Pinski changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 63902 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/43809] ICE on unconditional divide trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43809 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- So all fixed in GCC 7. The combine issue that was mentioned in the mailing list was fixed in r7-4961-ga001d4f9b91236 .
[Bug rtl-optimization/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188 --- Comment #15 from Andrew Pinski --- (In reply to Andrew Pinski from comment #14) > (In reply to Joseph S. Myers from comment #13) > > ARC support has been removed for GCC 4.7, but it looks like there's an issue > > here potentially relevant to other targets. > > Actually it was fixed in r0-99280-g43ba743ca91e5d. > See https://gcc.gnu.org/pipermail/gcc-patches/2010-April/280623.html > > > (In reply to Steven Bosscher from comment #12) > > Someone should dust off the patch and submit it for trunk. Joern? > > Funny the issue was fixed 3 months before this comment was added but I don't > think Steven realized it though. Just a quick note the patch which was committed is almost exactly what was submitted even except it uses a common function now. Even the comments are almost the same; note I doubt the author of the committed patch even knew about the old patch but they look very similar to each other.
[Bug rtl-optimization/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |4.6.0 Resolution|--- |FIXED --- Comment #14 from Andrew Pinski --- (In reply to Joseph S. Myers from comment #13) > ARC support has been removed for GCC 4.7, but it looks like there's an issue > here potentially relevant to other targets. Actually it was fixed in r0-99280-g43ba743ca91e5d. See https://gcc.gnu.org/pipermail/gcc-patches/2010-April/280623.html (In reply to Steven Bosscher from comment #12) > Someone should dust off the patch and submit it for trunk. Joern? Funny the issue was fixed 3 months before this comment was added but I don't think Steven realized it though.
[Bug target/35294] iwmmxt intrinsics, internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294 Andrew Pinski changed: What|Removed |Added Known to work||5.1.0 Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #21 from Andrew Pinski --- Fixed.
[Bug c++/111132] [11/12/13/14 Regression] Function redeclaration in local scope breaks constant expression evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Marek Polacek --- I think I have a patch.
[Bug tree-optimization/114545] [11/12/13/14 Regression] Missed optimization for CSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114545 --- Comment #1 from Andrew Pinski --- I am not sure this is worse. In the GCC 7 case we have: ``` sub eax, DWORD PTR a[rip] mov edx, eax ... neg edx ``` While in GCC 8+ we get: ``` movl%edx, %ecx subl%eax, %ecx subl%edx, %eax ``` In the case of GCC 8, we have 2 independent sub and still a move. In GCC 7 we get one sub followed by a move an dependent neg. The latency for the GCC 8+ will be less than what was done for GCC 7 because both sub can happen at the same time and the mov (which only happens on x86_64) is removed during rename. aarch64 produces for GCC 8+: ``` adrpx1, a adrpx2, c adrpx3, b ldr w0, [x1, #:lo12:a] ldr w2, [x2, #:lo12:c] sub w4, w2, w0 sub w0, w0, w2 str w4, [x1, #:lo12:a] str w0, [x3, #:lo12:b] ret ``` While before: ``` adrpx1, a adrpx0, c adrpx2, b ldr w3, [x1, #:lo12:a] ldr w0, [x0, #:lo12:c] sub w0, w0, w3 str w0, [x1, #:lo12:a] neg w0, w0 str w0, [x2, #:lo12:b] ret ``` So the neg will issue with the first str but if you have 2 store units and 2 ALUs, the GCC 8+ is better. So for superscalars, what GCC 8+ is doing is better and even in order cores, GCC 8+ will still be better due to the 2 independent instructions I think only at -Os/-Oz it might make a difference for x86_64 really.
[Bug tree-optimization/114545] [11/12/13/14 Regression] Missed optimization for CSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114545 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5 Keywords||missed-optimization
[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Target||x86_64-linux-gnu Summary|wrong code at -O3 on|[14 Regression] wrong code |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu Ever confirmed|0 |1 Keywords||needs-bisection, wrong-code Last reconfirmed||2024-04-01 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #5) > Hi Harald, > > I am pinning this one on you since it needs backporting to 13-branch, at > least. It also keeps the audit trail clean. Hi Paul, this one is at the top of my backport list. It depends on backporting r14-8902 (mine), and has weak conflict if r14-1629 (yours) is not backported, as testcase gfortran.dg/pr99350.f90 was introduced in that commit. I could amend backporting the fix for the current PR as well as r14-8902 to 13-branch by removing the changes to pr99350.f90 from the backport. That is likely the most simple solution, as backporting r14-1629 might introduce regressions. Nevertheless, the current fixes can only be backported to 13-branch, as some of the infrastructure changes for better error recovery after arithmetic errors and when array ctors are involved are to risky to backport to 12-branch. What do you think?
[Bug middle-end/114552] [13/14 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.3
Last reconfirmed||2024-04-01
Summary|wrong code at -O1 and above |[13/14 Regression] wrong
|on x86_64-linux-gnu |code at -O1 and above on
||x86_64-linux-gnu
Component|tree-optimization |middle-end
Status|UNCONFIRMED |NEW
Target||x86_64-linux-gnu
Keywords||needs-bisection, wrong-code
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Better reduced testcase, removing the pragma and putting the packed on the
struct that is causing the issue:
```
struct a {
short b;
int c;
}__attribute__((packed));
struct d {
struct a b;
int e;
};
static const struct d k = {{1,0},0};
[[gnu::noinline]]
void p() { asm("":::"memory"); }
[[gnu::noinline]]
void q(struct a n) {
p();
}
int main() {
q(k.b);
return 0;
}
```
The bug is in the middle-end expanding the call `q(k.b);` such that k.b is on
the stack but it messes up and uses the wrong size or something.
[Bug tree-optimization/114552] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552 --- Comment #1 from Andrew Pinski --- Not this might not be a bug as pragma pack(1) changes the alignment of the fields.
[Bug tree-optimization/114552] New: wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
Bug ID: 114552
Summary: wrong code at -O1 and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It is a regression from 12.3, and affects 13.* and the trunk.
Compiler Explorer: https://godbolt.org/z/bznEs9bao
[656] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240401 (experimental) (GCC)
[657] %
[657] % gcctk -O0 small.c; ./a.out
[658] %
[658] % gcctk -O1 small.c
[659] % ./a.out
Segmentation fault
[660] %
[660] % cat small.c
#pragma pack(1)
struct a {
short b;
int c;
};
struct d {
struct a b;
int e;
};
short f, g, h;
int i, j, o;
const struct d k = {{1,0},0};
short *l = , *m = , *n =
void p() { *n = (o > 0) > o; }
void q(struct a n) {
j = 0;
for (; j < 5; j++)
i = *m = *l != 0;
p();
}
int main() {
q(k.b);
return 0;
}
[Bug tree-optimization/114551] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551
Bug ID: 114551
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it does not reproduce for 13.2 and
earlier.
Compiler Explorer: https://godbolt.org/z/q3hrz8MW1
[587] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240401 (experimental) (GCC)
[588] %
[588] % gcctk -O2 small.c; ./a.out
[589] %
[589] % gcctk -O3 small.c
[590] % ./a.out
Segmentation fault
[591] %
[591] % cat small.c
int a, b[4], c, d, e, f;
int main() {
a--;
for (f = 3; f >= 0; f--) {
for (e = 0; e < 4; e++)
c = 0;
for (; c < 4; c++) {
d = f && a > 0 && f > (2147483647 - a) ? 0 : b[f];
continue;
}
}
return 0;
}
[Bug ada/114550] New: Weird error when iterating over a character container.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114550 Bug ID: 114550 Summary: Weird error when iterating over a character container. Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: p.p11 at orange dot fr CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 57841 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57841=edit Reproducer. When iterating over a character container, Integer is found: % gcc -c -gnatl -gnat2022 test_20240331_char_iter.adb GNAT 13.2.0 Copyright 1992-2023, Free Software Foundation, Inc. Compiling: test_20240331_char_iter.adb Source file time stamp: 2024-03-31 16:32:13 Compiled at: 2024-03-31 18:59:54 1. with Ada.Containers.Vectors; 2. 3. procedure test_20240331_char_iter is 4. 5.package UCP is new Ada.Containers.Vectors (Positive, Wide_Wide_Character); 6. 7.UA : Wide_Wide_String := "blah blah"; 8.US : UCP.Vector; 9. 10. begin 11. US := [for E of UA => E]; | >>> error: expected type "Standard.Wide_Wide_Character" >>> error: found type "Standard.Integer" 12. end;
[Bug modula2/114548] gm2 fails to identify variable in a const expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114548 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Gaius Mulley --- Closing now the patch has been applied.
[Bug modula2/114548] gm2 fails to identify variable in a const expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114548 --- Comment #4 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:4bd2f59af4a78cdc80039cffa51c1d9ad91081a3 commit r14-9739-g4bd2f59af4a78cdc80039cffa51c1d9ad91081a3 Author: Gaius Mulley Date: Mon Apr 1 19:18:36 2024 +0100 PR modula2/114548 gm2 fails to identify variable in a const expression This patch introduces stricter checking within standard procedure functions which detect whether paramaters are variable when used in a const expression. gcc/m2/ChangeLog: PR modula2/114548 * gm2-compiler/M2Quads.mod (ConvertToAddress): Pass procedure, false parameters to BuildConvertFunction. (PushOne): Pass procedure, true parameters to BuildConvertFunction. Remove usused parameter internal. (BuildPseudoBy): Remove parameter to PushOne. (BuildIncProcedure): Ditto. (BuildDecProcedure): Ditto. (BuildFunctionCall): Add ConstExpr parameter to BuildPseudoFunctionCall. (BuildConstFunctionCall): Add procedure and true to BuildConvertFunction. (BuildPseudoFunctionCall): Add ConstExpr parameter. Pass ProcSym and ConstExpr to BuildLengthFunction, BuildConvertFunction, BuildOddFunction, BuildAbsFunction, BuildCapFunction, BuildValFunction, BuildChrFunction, BuildOrdFunction, BuildIntFunction, BuildTruncFunction, BuildFloatFunction, BuildAddAdrFunction, BuildSubAdrFunction, BuildDifAdrFunction, BuildCastFunction, BuildReFunction, BuildImFunction and BuildCmplxFunction. (BuildAddAdrFunction): Add ProcSym, ConstExpr parameters and check for constant parameters. (BuildSubAdrFunction): Ditto. (BuildDifAdrFunction): Ditto. (ConstExprError): Ditto. (BuildLengthFunction): Ditto. (BuildOddFunction): Ditto. (BuildAbsFunction): Ditto. (BuildCapFunction): Ditto. (BuildChrFunction): Ditto. (BuildOrdFunction): Ditto. (BuildIntFunction): Ditto. (BuildValFunction): Ditto. (BuildCastFunction): Ditto. (BuildConvertFunction): Ditto. (BuildTruncFunction): Ditto. (BuildFloatFunction): Ditto. (BuildReFunction): Ditto. (BuildImFunction): Ditto. (BuildCmplxFunction): Ditto. gcc/testsuite/ChangeLog: PR modula2/114548 * gm2/iso/const/fail/expression.mod: New test. * gm2/iso/const/fail/iso-const-fail.exp: New test. * gm2/iso/const/fail/testabs.mod: New test. * gm2/iso/const/fail/testaddadr.mod: New test. * gm2/iso/const/fail/testcap.mod: New test. * gm2/iso/const/fail/testcap2.mod: New test. * gm2/iso/const/fail/testchr.mod: New test. * gm2/iso/const/fail/testchr2.mod: New test. * gm2/iso/const/fail/testcmplx.mod: New test. * gm2/iso/const/fail/testfloat.mod: New test. * gm2/iso/const/fail/testim.mod: New test. * gm2/iso/const/fail/testint.mod: New test. * gm2/iso/const/fail/testlength.mod: New test. * gm2/iso/const/fail/testodd.mod: New test. * gm2/iso/const/fail/testord.mod: New test. * gm2/iso/const/fail/testre.mod: New test. * gm2/iso/const/fail/testtrunc.mod: New test. * gm2/iso/const/fail/testval.mod: New test. * gm2/iso/const/pass/constbool.mod: New test. * gm2/iso/const/pass/constbool2.mod: New test. * gm2/iso/const/pass/constbool3.mod: New test. Signed-off-by: Gaius Mulley
[Bug sanitizer/114494] false-positive with -O2 -Wstringop-overflow=2 -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114494
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #5 from Hans-Peter Nilsson ---
(In reply to Akihiko Odaki from comment #0)
> if (hlen < sizeof(struct ip_header)) {
Is this a typo for "if (hlen > sizeof(struct ip_header)) {" which makes a bot
more sense to me?
(I can't find it in Linux/drivers, so can't check "upstream" status.)
[Bug c++/114549] [11/12/13 Regression] GCC >= 10.1 selects the wrong overload of C++20 reversed operator== function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114549 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Keywords|needs-bisection | --- Comment #4 from Marek Polacek --- Looks like it's changed in r14-6221. Doesn't look backportable.
[Bug c++/114549] [11/12/13 Regression] GCC >= 10.1 selects the wrong overload of C++20 reversed operator== function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114549 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-04-01 Resolution|FIXED |--- Status|RESOLVED|NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- (In reply to Chris Peterson from comment #2) > > Looks to be fixed on the trunk though. > > Thanks for verifying! I see now on godbolt.org that this bug is fixed in GCC > trunk (though GCC 13.2.0 still has the bug). In that case, I will resolve > this bug as fixed. It was a regression on the other releases so let's leave it open until it is fixed on the release branches or decided it is too hard to do as such.
[Bug c++/114549] [11/12/13 Regression] GCC >= 10.1 selects the wrong overload of C++20 reversed operator== function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114549 Chris Peterson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Chris Peterson --- > Looks to be fixed on the trunk though. Thanks for verifying! I see now on godbolt.org that this bug is fixed in GCC trunk (though GCC 13.2.0 still has the bug). In that case, I will resolve this bug as fixed.
[Bug c++/114549] [11/12/13 Regression] GCC >= 10.1 selects the wrong overload of C++20 reversed operator== function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114549 Andrew Pinski changed: What|Removed |Added Known to fail||10.1.0, 13.1.0, 13.2.0 Summary|GCC >= 10.1 selects the |[11/12/13 Regression] GCC |wrong overload of C++20 |>= 10.1 selects the wrong |reversed operator== |overload of C++20 reversed |function|operator== function Target Milestone|--- |11.5 Keywords||needs-bisection Known to work||14.0 --- Comment #1 from Andrew Pinski --- Looks to be fixed on the trunk though.
[Bug c++/114549] New: GCC >= 10.1 selects the wrong overload of C++20 reversed operator== function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114549
Bug ID: 114549
Summary: GCC >= 10.1 selects the wrong overload of C++20
reversed operator== function
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cpeterson at mozilla dot com
Target Milestone: ---
While updating Firefox from -std=c++17 to -std=c++20, I found a case where
GCC's resolution of C++20 reversed operator== functions behaves differently
from the Clang, MSVC, and ICX compilers. This is Firefox bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1880776
I believe this difference was a regression in GCC 10.1.
Here's a Godbolt test case comparing those compilers' output:
https://godbolt.org/z/qneax5oaW
```
#include
struct Thing {
template
bool operator==(const T& rhs) const {
/* This operator== is selected by:
* GCC versions >= 10.1 -std=c++17
* GCC version 9.5 -std=c++2a
* Clang 18.1 -std=c++2a
* MSVC 19.38 -std=c++20
* Intel's ICX 2024.0.0 -std=c++20
*/
return false;
}
};
template
bool operator==(T const& lhs, Thing const& rhs) {
/* This operator== is selected by:
* GCC versions >= 10.1 -std=c++2a
*/
return true;
}
bool test() {
Thing const v{};
return v == 3;
}
```
[Bug tree-optimization/114546] Missed optimization: ~m || n || m+2 ==> 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114546
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-01
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
clang/LLVM (and GCC) does not handle this either:
```
int a, b, c;
void test(int m, int n) {
int t = m ^ 100;
n = n / t;
a = m + 2;
b = ~m;
c = (b | n | a)!=0;
}
```
Which GCC optimizes (maybe too early to) the original code to.
[Bug tree-optimization/114546] Missed optimization: ~m || n || m+2 ==> 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114546 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug modula2/114548] gm2 fails to identify variable in a const expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114548 --- Comment #3 from Gaius Mulley --- Created attachment 57840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57840=edit Proposed fix Here is a proposed patch (which fixes all the standard procedure function const/var parameter checking): $ gm2 -fiso testcmplx.mod testcmplx.mod:4:17: error: In program module ‘testcmplx’: the procedure function ‘CMPLX’ is being called from within a constant expression and therefore the parameter ‘r’ must be a constant, seen a variable 4 |foo = CMPLX (r, i) ; | ^ testcmplx.mod:4:20: error: the procedure function ‘CMPLX’ is being called from within a constant expression and therefore the parameter ‘i’ must be a constant, seen a variable 4 |foo = CMPLX (r, i) ; |^ testcmplx.mod:4:8: error: in assignment, cannot assign a variable to a constant ‘foo’ 4 |foo = CMPLX (r, i) ; |^ testcmplx.mod:4:4: error: designator ‘foo’ is declared as a CONST 4 |foo = CMPLX (r, i) ; |^~~
[Bug middle-end/114547] comparison than less than 0 (or greater or equal to than 0) after a subtraction does not use the flags regster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114547 --- Comment #2 from gooncreeper --- (In reply to Andrew Pinski from comment #1) > I am not sure this is always better ... sets and setns are 1 uop, just like any other setcc why wouldn't it be better?
[Bug c++/110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338 Bug 110338 depends on bug 114455, which changed state. Bug 114455 Summary: [C++26] P2748R5 - Disallow binding a returned reference to a temporary https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114455 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/114455] [C++26] P2748R5 - Disallow binding a returned reference to a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114455 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Implemented in r14-9738-gbba118db3f63cb for GCC 14.0. commit bba118db3f63cb1e3953a014aa3ac2ad89908950 Author: Jason Merrill Date: Thu Mar 28 21:33:57 2024 -0400 c++: C++26 returning reference to temporary
[Bug middle-end/114547] comparison than less than 0 (or greater or equal to than 0) after a subtraction does not use the flags regster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114547 Andrew Pinski changed: What|Removed |Added Summary|missed-optimization: use|comparison than less than 0 |sign flag |(or greater or equal to ||than 0) after a subtraction ||does not use the flags ||regster --- Comment #1 from Andrew Pinski --- I am not sure this is always better ...
[Bug modula2/114548] gm2 fails to identify variable in a const expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114548 --- Comment #2 from Gaius Mulley --- This is true for many of the standard procedure functions.
[Bug modula2/114548] gm2 fails to identify variable in a const expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114548 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-04-01 --- Comment #1 from Gaius Mulley --- Confirmed.
[Bug modula2/114548] New: gm2 fails to identify variable in a const expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114548 Bug ID: 114548 Summary: gm2 fails to identify variable in a const expression Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- As reported on the gm2 mailing list. gm2 fails to identify the specific variable within a const expression. It gives an error for the whole expression rather than the sub expression in error. For example: $ cat testcmplx.mod MODULE testcmplx ; CONST foo = CMPLX (r, i) ; VAR r, i: REAL ; BEGIN END testcmplx. $ gm2 -fiso testcmplx.mod testcmplx.mod:4:8: error: In program module ‘testcmplx’: in assignment, cannot assign a variable to a constant ‘foo’ 4 |foo = CMPLX (r, i) ; |^ testcmplx.mod:4:4: error: designator ‘foo’ is declared as a CONST 4 |foo = CMPLX (r, i) ; |^~~ it could identify r and i as variables.
[Bug middle-end/114547] missed-optimization: use sign flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114547 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Severity|normal |enhancement
[Bug middle-end/114547] New: missed-optimization: use sign flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114547
Bug ID: 114547
Summary: missed-optimization: use sign flag
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: goon.pri.low at gmail dot com
Target Milestone: ---
Example functions
int s(int *v, int n) {
*v -= n;
return *v < 0;
}
int ns(int *v, int n) {
*v -= n;
return *v >= 0;
}
Generated assembly
s:
mov eax, DWORD PTR [rdi]
sub eax, esi
mov DWORD PTR [rdi], eax
shr eax, 31
ret
ns:
mov eax, DWORD PTR [rdi]
sub eax, esi
mov DWORD PTR [rdi], eax
not eax
shr eax, 31
ret
Optimal assembly
s:
xor eax, eax
sub DWORD PTR [rdi], esi
setsal
ret
ns:
xor eax, eax
sub DWORD PTR [rdi], esi
setns al
ret
[Bug bootstrap/105474] GCC fails to bootstrap with --disable-libstdcxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105474
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=102665
CC||egallager at gcc dot gnu.org
--- Comment #5 from Eric Gallager ---
(In reply to Andrew Pinski from comment #4)
> Something like should provided an error while configuring so much earlier:
> ```
> case "$enable_bootstrap:${noconfigdirs}" in
> yes:*target-libstdc++-v3*)
> AC_MSG_ERROR([cannot also disable libstdcxx if bootstrapping]) ;;
> ;;
> esac
>
> ```
>
> Let me test that out and submit it for GCC 15.
Related: bug 102665
[Bug c++/114479] [14 Regression] std::is_array_v changed from false to true in GCC 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- Comment #5 from Arthur O'Dwyer ---
IIUC, the logic here goes as follows:
(1) Everyone's compiler extension currently makes this assertion fail, not
succeed:
#include
template struct is_array : std::false_type {};
template struct is_array : std::true_type {};
template struct is_array : std::true_type {};
static_assert(is_array::value, "this assert fails");
(2) Everyone's library is expected to implement `std::is_array` as the moral
equivalent of the partial specializations in (1). No reasonable library would
ever do anything else.
(3) Therefore, everyone's library will claim that int[0] is not an array type:
static_assert(std::is_array::value, "this assert fails");
(4) The __is_array builtin is provided specifically to speed up std::is_array
(and for no other reason). Therefore, it should give the same answer as (3).
Therefore, __is_array(int[0]) should also report false:
static_assert(__is_array(int[0]), "this assert fails");
This logic doesn't depend on any abstract reasoning about whether int[0] is
really "an array type" (I think it certainly *is* an array type, FWIW); it
simply depends on observing the extension's behavior in (1) -- and then *not*
claiming that that's a bug we need to fix. If the extension's behavior is
"correct" (i.e. we're not going to change it), then the behavior of
__is_array(T[0]) falls naturally out of that.
Personally, if I were designing the extension today, I would certainly make
T[0] match the partial specialization for T[N] (with N=0). This seems like it
would match users' expectations, and it doesn't seem to break any code that
wasn't already trying to use the extension, except for pathological party
tricks like being able to obfuscate the condition (N >= 1) as
(std::is_array_v). However, *if* the extension's behavior (1) is set in
stone, *then* conclusion (4) follows inexorably.
And since both (1) and (4) are core-language compiler issues, libstdc++ isn't
involved here: it's simply a bug for GCC to provide
partial-specialization-matching behavior as in (1) without also providing
__is_array behavior as in (4).
HOWEVER, here's a big question which I believe Aaron Ballman also raised on
llvm-project#54705: If it's not an array type, then where do we get off calling
it a compound type ( https://eel.is/c++draft/basic#compound-1 ), a literal type
( https://eel.is/c++draft/basic#types.general-10 ), an aggregate (
https://eel.is/c++draft/dcl.init.aggr#1 ), etc?
It certainly would be *simpler* -- if a big upheaval -- for GCC to provide
neither (1) nor (4), i.e. change the specialization-matching behavior to match
__is_array rather than the other way around. Then all the traits would give
consistent answers: int[0] would be a compound type, a literal type, and an
aggregate *because* it was an array type.
[Bug c++/114479] [14 Regression] std::is_array_v changed from false to true in GCC 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Marek Polacek --- Thanks. I'll go ahead and submit my patch.
[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980 --- Comment #9 from Giuliano Belinassi --- Hello, Kewen. (In reply to Kewen Lin from comment #8) > Hi @Michael, @Martin, could you help to confirm/clarify what triggers you to > be interested in this feature, is it for some user space usage or not? Yes, this is for userspace livepatching. Assume the following example: https://godbolt.org/z/b9M8nMbo1 As one can see, the sequence of 14 nops are generated after the global function entry point. In such way we can't use the this space to place a trampoline to the new function. We need this sequence of nops to be placed *before* the global function entry point. Thanks, Giuliano.
[Bug c++/114537] bit_cast does not work NSDMI of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114537
--- Comment #2 from Andrew Pinski ---
(In reply to Fedor Chelnokov from comment #1)
> Probably related:
> ```
> #include
>
> struct A { int a: 7; };
>
> static_assert( 1 == std::bit_cast(std::bit_cast(A{1})).a );
> ```
> It looks valid and accepted by MSVC, but GCC prints:
> error: '__builtin_bit_cast' accessing uninitialized byte at offset 0
>
> Online demo: https://gcc.godbolt.org/z/3W5onY955
That is unrelated and gcc is actually correct there see pr 99637.
[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 --- Comment #21 from chenglulu --- (In reply to Xi Ruoyao from comment #20) > (In reply to chenglulu from comment #19) > > (In reply to Xi Ruoyao from comment #18) > > > (In reply to chenglulu from comment #17) > > > > > > > The results of spec2006 on LA464 are: > > > > -falign-labels=4 -falign-functions=32 -falign-loops=16 -falign-jumps=16 > > > > > > Would you send a patch for them or prefer I to do it? > > > > I'll send a patch tomorrow. > > Ping. > > I'd like to do another system rebuild after this patch lands for verifying > GCC 14. Oh sorry, I'm waiting for yujie's patch, just merged today. I'll send this align patch tomorrow.
[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:a5bc8abef90874e81783e0fa34db133da71d1133 commit r13-8548-ga5bc8abef90874e81783e0fa34db133da71d1133 Author: Francois-Xavier Coudert Date: Sat Aug 19 23:22:06 2023 +0200 Testsuite: fix analyzer tests on Darwin On macOS, system headers redefine by default some macros (memcpy, memmove, etc) to checked versions, which defeats the analyzer. We want to turn this off. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 gcc/testsuite/ChangeLog: PR analyzer/104042 * gcc.dg/analyzer/analyzer.exp: Pass -D_FORTIFY_SOURCE=0 on Darwin. * gcc.dg/analyzer/fd-bind.c: Add missing header. * gcc.dg/analyzer/fd-datagram-socket.c: Likewise. * gcc.dg/analyzer/fd-listen.c: Likewise. * gcc.dg/analyzer/fd-socket-misuse.c: Likewise. * gcc.dg/analyzer/fd-stream-socket-active-open.c: Likewise. * gcc.dg/analyzer/fd-stream-socket-passive-open.c: Likewise. * gcc.dg/analyzer/fd-stream-socket.c: Likewise. * gcc.dg/analyzer/fd-symbolic-socket.c: Likewise. (cherry picked from commit ce33bbfcbc7dd3afc6c96fb48a19ed00f0c598ce)
[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 --- Comment #20 from Xi Ruoyao --- (In reply to chenglulu from comment #19) > (In reply to Xi Ruoyao from comment #18) > > (In reply to chenglulu from comment #17) > > > > > The results of spec2006 on LA464 are: > > > -falign-labels=4 -falign-functions=32 -falign-loops=16 -falign-jumps=16 > > > > Would you send a patch for them or prefer I to do it? > > I'll send a patch tomorrow. Ping. I'd like to do another system rebuild after this patch lands for verifying GCC 14.
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #7 from Rama Malladi --- (In reply to Rama Malladi from comment #5) > (In reply to Andrew Pinski from comment #3) > > Also do you have numbers with lto enabled? Or is these without lto? > > > > Does LTO improve the situation for Envoy too? > > These numbers are without lto. I haven't tried it but I can try and post an > update. I checked and found the Envoy run was w/o LTO but SPEC cpu2017 intrate was w LTO. I tried a build of Envoy w LTO and it failed. I need to debug that issue further. Below are perf results w/o LTO. gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04). copies=8-O2 -Ofast Gain w -O2 + inlining Gain w noLTO noLTO Ofast noLTO inlining 500.perlbench_r 33.733.398.8% 33.298.5% 502.gcc_r 45.246.9103.8% 46.3102.4% 505.mcf_r 44.744.399.1% 44.699.8% 520.omnetpp_r 21.424.4114.0% 21.399.5% 523.xalancbmk_r 41.645.5109.4% 44 105.8% 525.x264_r 44.289 201.4% 43.999.3% 531.deepsjeng_r 32.832.8100.0% 33.1100.9% 541.leela_r 28.630.5106.6% 30.3105.9% 548.exchange2_r 64.164.6100.8% 64.1100.0% 557.xz_r20.320.4100.5% 20.3100.0% SPECrate..base 35.639.4110.7% 36 101.1%
[Bug fortran/114535] [13/14 regression] ICE with elemental finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114535 --- Comment #4 from Paul Thomas --- Created attachment 57839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57839=edit "Fix" for this PR Even though no entities of type 'vs' are being referenced in subroutine iss, gfortran currently feels the need to generate a final wrapper for it. The comment in the patch explains what is happening but not why. I suspect that the evil is being done somewhere in resolve.cc and will investigate in another session. Note the comments in the testcase below: module d implicit none contains function en() result(dd) use :: iv implicit none type(vs) :: dd dd%i = 1 end function en end module d ! Comment out line 1 and all brands complain that 'vs' is an undefined type ! Comment out line 1 and line 2 allows compilation to proceed (with fix for gfortran) module ni implicit none contains subroutine iss() use :: iv! line 1 use :: d implicit none type(vs) :: ans; ans = en(); print *, ctr, ans%i ! line 2 end subroutine iss end module ni use ni call iss() call iss() ! print *, ctr end
[Bug tree-optimization/114546] New: Missed optimization: ~m || n || m+2 ==> 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114546
Bug ID: 114546
Summary: Missed optimization: ~m || n || m+2 ==> 1
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: 652023330028 at smail dot nju.edu.cn
Target Milestone: ---
Hello, we noticed that the code below can be optimized as stated in the title
(c = b || n || a ==> 1), but gcc -O3 (-fwrapv) missed it.
https://godbolt.org/z/6Kss3shKc
int a, b, c;
void test(int m, int n) {
int t = m ^ 100;
n = n / t;
a = m + 2;
b = ~m;
c = b || n || a;
}
GCC -O3 -fwrapv:
test(int, int):
mov eax, esi
lea ecx, [rdi+2]
mov r8d, edi
xor edi, 100
cdq
not r8d
mov DWORD PTR a[rip], ecx
idivedi
mov DWORD PTR b[rip], r8d
or ecx, r8d
mov esi, eax
xor eax, eax
or esi, ecx
setne al
mov DWORD PTR c[rip], eax
ret
Expected code (Clang):
test(int, int): # @test(int, int)
lea eax, [rdi + 2]
mov dword ptr [rip + a], eax
not edi
mov dword ptr [rip + b], edi
mov dword ptr [rip + c], 1
ret
Thank you very much for your time and effort! We look forward to hearing from
you.
[Bug c++/114537] bit_cast does not work NSDMI of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114537
--- Comment #1 from Fedor Chelnokov ---
Probably related:
```
#include
struct A { int a: 7; };
static_assert( 1 == std::bit_cast(std::bit_cast(A{1})).a );
```
It looks valid and accepted by MSVC, but GCC prints:
error: '__builtin_bit_cast' accessing uninitialized byte at offset 0
Online demo: https://gcc.godbolt.org/z/3W5onY955
[Bug tree-optimization/114545] New: [11/12/13/14 Regression] Missed optimization for CSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114545
Bug ID: 114545
Summary: [11/12/13/14 Regression] Missed optimization for CSE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: 652023330028 at smail dot nju.edu.cn
Target Milestone: ---
Hello, we noticed that there may be a missed CSE (t+c). Here is the reduced
code:
https://godbolt.org/z/f68qWa89s
int a, b, c;
void func() {
int t=0;
t = -a;
b = -(t + c);
a = t + c;
}
GCC -O3 -fwrapv:
func():
mov edx, DWORD PTR a[rip]
mov eax, DWORD PTR c[rip]
mov ecx, edx
sub ecx, eax
sub eax, edx
mov DWORD PTR b[rip], ecx
mov DWORD PTR a[rip], eax
ret
Expected code:
GCC-7.5:
func():
mov eax, DWORD PTR c[rip]
sub eax, DWORD PTR a[rip]
mov edx, eax
mov DWORD PTR a[rip], eax
neg edx
mov DWORD PTR b[rip], edx
ret
Thank you very much for your time and effort! We look forward to hearing from
you.
[Bug target/114544] [x86] stv should transform (subreg DI (V1TI) 8) as (vec_select:DI (V2DI) (const_int 1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114544
--- Comment #2 from Hongtao Liu ---
Also for
void
foo2 (v128_t* a, v128_t* b)
{
c = (*a & *b)+ *b;
}
(insn 9 8 10 2 (set (reg:V1TI 108 [ _3 ])
(and:V1TI (reg:V1TI 99 [ _2 ])
(mem:V1TI (reg:DI 113) [1 *a_6(D)+0 S16 A128])))
"/app/example.c":49:12 7100 {andv1ti3}
(expr_list:REG_DEAD (reg:DI 113)
(nil)))
(insn 10 9 13 2 (parallel [
(set (reg:TI 109 [ _11 ])
(plus:TI (subreg:TI (reg:V1TI 108 [ _3 ]) 0)
(subreg:TI (reg:V1TI 99 [ _2 ]) 0)))
(clobber (reg:CC 17 flags))
]) "/app/example.c":49:17 256 {*addti3_doubleword}
(expr_list:REG_DEAD (reg:V1TI 108 [ _3 ])
(expr_list:REG_DEAD (reg:V1TI 99 [ _2 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
Since V1TImode can only be accocated as SSE_REGS, reload use stack for
(subreg:TI (reg:V1TI 108 [ _3 ]) 0) since the latter only support GENERAL_REGS.
[Bug target/114544] [x86] stv should transform (subreg DI (V1TI) 8) as (vec_select:DI (V2DI) (const_int 1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114544
--- Comment #1 from Hongtao Liu ---
20590;; Turn SImode or DImode extraction from arbitrary SSE/AVX/AVX512F
20591;; vector modes into vec_extract*.
20592(define_split
20593 [(set (match_operand:SWI48x 0 "nonimmediate_operand")
20594(subreg:SWI48x (match_operand 1 "register_operand") 0))]
20595 "can_create_pseudo_p ()
20596 && REG_P (operands[1])
20597 && VECTOR_MODE_P (GET_MODE (operands[1]))
20598 && ((TARGET_SSE && GET_MODE_SIZE (GET_MODE (operands[1])) == 16)
20599 || (TARGET_AVX && GET_MODE_SIZE (GET_MODE (operands[1])) == 32)
20600 || (TARGET_AVX512F && TARGET_EVEX512
20601 && GET_MODE_SIZE (GET_MODE (operands[1])) == 64))
20602 && (mode == SImode || TARGET_64BIT || MEM_P (operands[0]))"
20603 [(set (match_dup 0) (vec_select:SWI48x (match_dup 1)
20604 (parallel [(const_int 0)])))]
20605{
20606 rtx tmp;
We need to do something similar.
[Bug target/114544] New: [x86] stv should transform (subreg DI (V1TI) 8) as (vec_select:DI (V2DI) (const_int 1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114544
Bug ID: 114544
Summary: [x86] stv should transform (subreg DI (V1TI) 8) as
(vec_select:DI (V2DI) (const_int 1))
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Target Milestone: ---
typedef __uint128_t v128_t __attribute__((vector_size(16)));
v128_t c;
v128_t
foo1 (v128_t *a, v128_t *b)
{
c = (*a >> 1 & *b) / (__extension__(v128_t){(__int128_t)0x3 << 120
| (__int128_t)0x3 << 112
| (__int128_t)0x3 << 104
| (__int128_t)0x3 << 96
| (__int128_t)0x3 << 88
| (__int128_t)0x3 << 80
| (__int128_t)0x3 << 72
| (__int128_t)0x3 << 64
| (__int128_t)0x3 << 56
| (__int128_t)0x3 << 48
| (__int128_t)0x3 << 40
| (__int128_t)0x3 << 32
| (__int128_t)0x3 << 24
| (__int128_t)0x3 << 16
| (__int128_t)0x3 << 8
| (__int128_t)0x3 << 0});
}
stv generates
(insn 32 11 35 2 (set (reg:DI 124 [ _4 ])
(subreg:DI (reg:V1TI 111 [ _4 ]) 0)) "/app/example.c":28:25 84
{*movdi_internal}
(nil))
(insn 35 32 12 2 (set (reg:DI 127 [+8 ])
(subreg:DI (reg:V1TI 111 [ _4 ]) 8)) "/app/example.c":28:25 84
{*movdi_internal}
(expr_list:REG_DEAD (reg:V1TI 111 [ _4 ])
(subreg:DI (reg:V1TI 111 [ _4 ]) 8) makes reload spills.
foo1:
movabsq $217020518514230019, %rdx # 57 [c=1 l=10]
*movdi_internal/4
subq$24, %rsp # 59 [c=4 l=4]
pro_epilogue_adjust_stack_add_di/0
vmovdqa (%rdi), %xmm0 # 8 [c=9 l=4] movv1ti_internal/3
movq%rdx, %rcx # 58[c=4 l=3] *movdi_internal/3
vpsrldq $8, %xmm0, %xmm1 # 42[c=4 l=5] sse2_lshrv1ti3/1
vpsrlq $1, %xmm0, %xmm0# 45[c=4 l=5] lshrv2di3/1
vpsllq $63, %xmm1, %xmm1 # 46 [c=4 l=5] ashlv2di3/1
vpor%xmm1, %xmm0, %xmm0 # 47 [c=4 l=4] *iorv2di3/1
vpand (%rsi), %xmm0, %xmm2 # 10[c=13 l=4] andv1ti3/1
vmovdqa %xmm2, (%rsp) # 52 [c=4 l=5] movv1ti_internal/4
movq(%rsp), %rdi# 56[c=5 l=4] *movdi_internal/3
movq8(%rsp), %rsi # 35 [c=9 l=5] *movdi_internal/3
call__udivti3 # 19 [c=13 l=5] *call_value
vmovq %rax, %xmm3 # 53 [c=4 l=5] *movdi_internal/20
vpinsrq $1, %rdx, %xmm3, %xmm0# 23[c=4 l=6] vec_concatv2di/2
vmovdqa %xmm0, c(%rip)# 25[c=4 l=8] movv1ti_internal/4
addq$24, %rsp # 62 [c=4 l=4]
pro_epilogue_adjust_stack_add_di/0
ret # 63[c=0 l=1] simple_return_internal
[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980 --- Comment #8 from Kewen Lin --- Hi @Michael, @Martin, could you help to confirm/clarify what triggers you to be interested in this feature, is it for some user space usage or not?
[Bug ipa/101362] can_change_signature does not consider 'used' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101362 --- Comment #3 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > In particular can_change_signature is one of the keys for > ix86_function_regparm to use local calling conventions on i?86 So looking through the code on i386 side we check ->local and ->can_change_signature. But ->local is set to false for node->externally_visible which gets set via cgraph_externally_visible_p for DECL_PRESERVE_P which gets set via handle_used_attribute (in c-family/c-attribs.cc). So can_change_signature might not be worried about here. Basically as far as I understand is that can_change_signature says if we can change the signature; though if it is not local, we can't change that version of it because it might called else where outside of the TU.
[Bug libcc1/114389] internal compiler error when compiling structure field with name-conflict in gdb `command`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114389
--- Comment #1 from Tan Senqi ---
reconfirmed at 2024-4-1
GCC: gcc (GCC) 14.0.1 20240401 (experimental)
GDB: GNU gdb (GDB) 14.2
Platform: AMD64, ubuntu 20.04
Testcase is following; Note that the position where segmentation fault happens
is different in this version().
struct A { int a;} a;
int main ()
{
struct A r;
r.a = 0;
return 0;
}
(gdb) b 6
Breakpoint 1 at 0x40110a: file a.c, line 6.
(gdb) run
Starting program: /home/asahi/emd/build/a.out
Breakpoint 1, main () at a.c:6
6 r.a = 0;
(gdb) expr r.a = 0
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_PRE_GENERICIZE| libcc1plugin
PLUGIN_GGC_MARKING | libcc1plugin
PLUGIN_PRAGMAS | libcc1plugin
gdb command line:1:2: internal compiler error: Segmentation fault
0xc402bf crash_signal
../.././gcc/toplev.cc:314
0x7f71bf63708f ???
/build/glibc-wuryBv/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xebedc2 component_ref_field_offset(tree_node*)
../.././gcc/tree.cc:12990
0x9afd62 gimplify_compound_lval
../.././gcc/gimplify.cc:3250
0x9aa537 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../.././gcc/gimplify.cc:16335
0x9b660a gimplify_modify_expr
../.././gcc/gimplify.cc:6169
0x9aab9d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../.././gcc/gimplify.cc:16383
0x9ac415 gimplify_stmt(tree_node**, gimple**)
../.././gcc/gimplify.cc:7226
0x9ac415 gimplify_statement_list
../.././gcc/gimplify.cc:2019
0x9ac415 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../.././gcc/gimplify.cc:16828
0x9b22fd gimplify_stmt(tree_node**, gimple**)
../.././gcc/gimplify.cc:7226
0x9b22fd gimplify_bind_expr
../.././gcc/gimplify.cc:1430
0x9ab52a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../.././gcc/gimplify.cc:16584
0x9aef13 gimplify_stmt(tree_node**, gimple**)
../.././gcc/gimplify.cc:7226
0x9aef13 gimplify_body(tree_node*, bool)
../.././gcc/gimplify.cc:17645
0x9af2d2 gimplify_function_tree(tree_node*)
../.././gcc/gimplify.cc:17844
0x83bf57 cgraph_node::analyze()
../.././gcc/cgraphunit.cc:684
0x83e567 analyze_functions
../.././gcc/cgraphunit.cc:1247
0x83f18d symbol_table::finalize_compilation_unit()
../.././gcc/cgraphunit.cc:2554
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compilation failed.
[Bug target/91420] relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 with "-O2" on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91420 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > That is definitely a bug in mcmodel=kernel in the x86backenbd which is > different from the problem here even though both have same testcase. Filed the x86_64 issue as PR 114543 .
[Bug target/114543] New: mcmodel=kernel generates relocation that definitely can't be handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114543
Bug ID: 114543
Summary: mcmodel=kernel generates relocation that definitely
can't be handled
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: link-failure
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-linux-gnu
Take:
```
const char *f()
{
return "1" + 2147483647;
}
int main() {}
```
Compile/link with `-O2 mcmodel=kernel` and you get:
```
ASM generation compiler returned: 0
/tmp/cc57BgGX.o: in function `f()':
example.cpp:(.text+0x3): relocation truncated to fit: R_X86_64_32S against
`.LC0'
collect2: error: ld returned 1 exit status
Execution build compiler returned: 1
```
That is because GCC Produces:
```
movq$.LC0+2147483647, %rax
```
But it should have split up the addon from the LC0 here.
Note that was reported in PR 91420 originally but that is a riscv64 backend
issue rather than one in the x86_64 backend.
