[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #10 from Richard Biener --- (In reply to Roger Sayle from comment #7) > Created attachment 54843 [details] > proposed patch > > Proposed patch. Does this look reasonable? Yes, but doesn't this work for all GET_CODE (op) != ASHIFTRT?
[Bug lto/109369] LTO drops explicitly referenced symbol _pei386_runtime_relocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109369 --- Comment #10 from Pali Rohár --- > I would suggest to move the bug to the Binutils Bugzilla. Done: https://sourceware.org/bugzilla/show_bug.cgi?id=30343
[Bug middle-end/109449] [11/12/13 Regression] false positive stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109449 --- Comment #5 from Richard Biener --- As expected that causes FAIL: c-c++-common/Wstringop-truncation.c -std=gnu++98 bug 77293 (test for warn ings, line 271) FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings, lin e 49) FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings, lin e 50) FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings, lin e 51) FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings, lin e 55) FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings, line 56) FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings, line 57) FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings, line 61) FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings, line 62) FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings, line 63) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 28) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 29) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 30) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 50) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 51) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 52) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 53) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 127) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 128) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 129) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 131) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 132) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 135) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 136) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 137) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 139) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 140) FAIL: gcc.dg/Wstringop-overflow-37.c note (test for warnings, line 194) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 195) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 213) FAIL: gcc.dg/Wstringop-overflow-37.c note (test for warnings, line 230) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 231) FAIL: gcc.dg/Wstringop-overflow-37.c note (test for warnings, line 236) FAIL: gcc.dg/Wstringop-overflow-37.c (test for warnings, line 237) FAIL: gcc.dg/Wstringop-overflow-37.c (test for excess errors) FAIL: gcc.dg/Wstringop-overflow-40.c (test for warnings, line 103) FAIL: gcc.dg/Wstringop-overflow-40.c (test for excess errors) FAIL: gcc.dg/pr56837.c scan-tree-dump-times optimized "memset ..c, 68, 16384.;" 1 FAIL: gcc.dg/warn-strnlen-no-nul.c (test for warnings, line 150) FAIL: gcc.dg/warn-strnlen-no-nul.c (test for warnings, line 154) FAIL: c-c++-common/Wstringop-truncation.c -Wc++-compat bug 77293 (test for warnings, line 271) as those all explicitely test for this "misbehavior" (aka _FORTIFY_SOURCE=2). Note -Wstringop-overflow=1 diagnoses this the same. The workaround in the source would be to use for example uint8_t *tdp = (uint8_t *)drlg.transDirMap; or simply use two-dimensional array accesses directly to transDirMap. So as a summary, the diagnostic works this way by design (a design not everyone agrees to, me included, esp. for the case of multidimensional arrays).
[Bug middle-end/109493] Broken O2 optimization on s390x in GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109493 --- Comment #6 from Mikhail Mitskevich --- (In reply to Sam James from comment #3) > It's unclear to me from the reports if this started with GCC 13 or if it > always failed on s390x. Could you clarify? Thanks. I have run this test on GCC 12 on s390x and it fails (gcc version 12.2.1 20221121 (Red Hat 12.2.1-4) (GCC) ).
[Bug c++/109494] New: inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
Bug ID: 109494
Summary: inline const variables interfere with source_location
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oliver.rosten at googlemail dot com
Target Milestone: ---
The bug, (for which I'm not sure if it is a front end problem or a library
problem), is reproduced here: https://github.com/ojrosten/SourceLoc
The project comprises three files in the Test directory:
Main.cpp
Test.cpp
Test.hpp
Both the cpps depend on the hpp. The latter contains an unused variable
inline const std::string foo{};
The presence of this seems to cause:
1. The appearance of a warning: "ld: warning: direct access in function ...
from file ... to global weak symbol ... from file ... means the weak symbol
cannot be overridden at runtime..."
2. std::source_location::current() to misbehave: building and running causes
the path to Main.cpp to be output twice, whereas it should just be printed
once, with the path to Test.cpp appearing second.
Any of the following cures both of the problems:
1. Removing foo;
2. Removing inline;
3. Replacing const with constexpr
In the much more complex project where I first encountered this, I reliably got
a segmentation fault. I was able to cure this by removing inline in a handful
of places.
[Bug tree-optimization/109048] [13 regression] redundant mask compare generated by vectorizer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109048 --- Comment #11 from Richard Biener --- The recent patch improved this to avoid some of the compares. We still have the three-argument PHI and thus three VEC_CONDs. .L10: vmovups (%rdi,%rdx), %ymm0 vcmpltps%ymm6, %ymm0, %ymm3 vcmpltps%ymm2, %ymm0, %ymm1 vpandn %ymm1, %ymm3, %ymm1 vblendvps %ymm1, %ymm5, %ymm4, %ymm1 vblendvps %ymm3, %ymm7, %ymm1, %ymm1 vaddps %ymm1, %ymm0, %ymm0 vaddps (%rax,%rdx), %ymm0, %ymm0 vmovups %ymm0, (%rax,%rdx) addq$32, %rdx cmpq$1024, %rdx jne .L10 vs. GCC 12 .L6: vmovups (%rdi,%rdx), %ymm1 vcmpltps%ymm5, %ymm1, %ymm0 vcmpltps%ymm6, %ymm1, %ymm4 vblendvps %ymm0, %ymm3, %ymm2, %ymm0 vandps %ymm3, %ymm4, %ymm4 vaddps %ymm4, %ymm0, %ymm0 vaddps %ymm1, %ymm0, %ymm0 vaddps (%rax,%rdx), %ymm0, %ymm0 vmovups %ymm0, (%rax,%rdx) addq$32, %rdx cmpq$1024, %rdx jne .L6 which at least overall looks comparable.
[Bug analyzer/108722] gcc.dg/analyzer/file-CWE-1341-example.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108722 Richard Biener changed: What|Removed |Added Keywords||testsuite-fail Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Target|powerpc64-linux-gnu |powerpc64-linux-gnu |hppa-linux-gnu |hppa-linux-gnu ||x86_64-unknown-linux-gnu CC||dmalcolm at gcc dot gnu.org Component|target |analyzer --- Comment #2 from Richard Biener --- also seeing this on x86_64, it's dependent on the glibc version (I have 2.37). The bug is in the analyzer I think, it implements FILE open/close tracking so it should suppress itself from diagnosing malloc/free diagnostic on FILEs.
[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 --- Comment #9 from Jonathan Wakely --- No: This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies): — in a return statement in a function with a class return type, when the expression is the name of a non-volatile object with automatic storage duration (other than a function parameter or a variable introduced by the exception-declaration of a handler (14.4)) with the same type (ignoring cv-qualification) as the function return type, the copy/move operation can be omitted by constructing the object directly into the function call’s return object "Other than a function parameter" means the return object must be at a distinct address.
[Bug tree-optimization/109434] [12 Regression] std::optional weird -Wmaybe-uninitialized and behaviour with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434 --- Comment #6 from Tomáš Pecka --- I can confirm that the bug now does not appear in our application code that I simplified into attached code. Tested on commit df7f55cb2ae. Thank you!
[Bug lto/109369] LTO drops explicitly referenced symbol _pei386_runtime_relocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109369 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Resolution|--- |MOVED URL||https://sourceware.org/bugz ||illa/show_bug.cgi?id=30343 Status|UNCONFIRMED |RESOLVED --- Comment #11 from Xi Ruoyao --- Moved.
[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #10 from Jakub Jelinek ---
Making the reference types to return or parameter non-POD types passed by value
restrict could be
--- gcc/cp/call.cc.jj 2023-03-30 09:34:05.609725768 +0200
+++ gcc/cp/call.cc 2023-04-13 09:56:53.226908996 +0200
@@ -9223,7 +9223,11 @@ type_passed_as (tree type)
{
/* Pass classes with copy ctors by invisible reference. */
if (TREE_ADDRESSABLE (type))
-type = build_reference_type (type);
+{
+ type = build_reference_type (type);
+ type = build_qualified_type (type,
+ TYPE_QUALS (type) | TYPE_QUAL_RESTRICT);
+}
else if (targetm.calls.promote_prototypes (NULL_TREE)
&& INTEGRAL_TYPE_P (type)
&& COMPLETE_TYPE_P (type)
--- gcc/cp/cp-gimplify.cc.jj2023-03-15 15:36:02.500430556 +0100
+++ gcc/cp/cp-gimplify.cc 2023-04-13 09:57:51.989059798 +0200
@@ -2000,6 +2000,9 @@ cp_genericize (tree fndecl)
{
t = DECL_RESULT (fndecl);
TREE_TYPE (t) = build_reference_type (TREE_TYPE (t));
+ TREE_TYPE (t)
+ = build_qualified_type (TREE_TYPE (t), TYPE_QUALS (TREE_TYPE (t))
+ | TYPE_QUAL_RESTRICT);
DECL_BY_REFERENCE (t) = 1;
TREE_ADDRESSABLE (t) = 0;
relayout_decl (t);
Completely untested. Does this what we want? Stage1 material anyway...
[Bug preprocessor/109485] improve include path handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485 --- Comment #6 from Dani Borg --- (In reply to Andrew Pinski from comment #1) > Is this even valid with NFS? My knowledge of different file systems is limited, but I think checking the presence of a directory should be as valid on NFS as most other file systems?
[Bug tree-optimization/109048] [13 regression] redundant mask compare generated by vectorizer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109048 Hongtao.liu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Hongtao.liu --- So marked as fixed.
[Bug c++/109490] [11/12/13 Regression] ICE when declaring custom OpenMP reduction in generic Lambda in Template Function since r11-3236-g8155316c6fc230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109490 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|ICE when declaring custom |[11/12/13 Regression] ICE |OpenMP reduction in generic |when declaring custom |Lambda in Template Function |OpenMP reduction in generic ||Lambda in Template Function ||since ||r11-3236-g8155316c6fc230 --- Comment #2 from Martin Liška --- Started with r11-3236-g8155316c6fc230.
[Bug preprocessor/109485] improve include path handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485 --- Comment #7 from Dani Borg --- (In reply to Andrew Pinski from comment #2) > Also does it work with Windows style pathes? > I am suspecting clang does not do the right thing there ... I don't know much about Windows path handling, so I can't say. It's possible some adaptations are needed depending on the OS. I think the main principles/strategy should work for any file system that has a directory structure though.
[Bug middle-end/109493] Broken O2 optimization on s390x in GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109493 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #7 from Xi Ruoyao --- (In reply to Mikhail Mitskevich from comment #4) > (In reply to Andrew Pinski from comment #1) > > belt_mac_st* st = &state; > > belt_mac_st* st2 = &state2; > > ((word*)(st->s))[0] = 0, ((word*)(st->s))[1] = 0; > > ((word*)(st->r))[0] = 0, ((word*)(st->r))[1] = 0; > > st->filled = 0; > > > > I am 99% sure those are aliasing rule violations. > > > > Does -fno-strict-aliasing help? > > With -fno-strict-aliasing option code works as well as with -O1 option. Then it's likely the code is buggy, not GCC is buggy (unless you have some fancy type attributes on "word" or "belt_mac_st").
[Bug preprocessor/109485] improve include path handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485 --- Comment #8 from Dani Borg --- (In reply to Andrew Pinski from comment #3) > Also I really doubt the improvement here is less than 1% improvement really > for the common case where people don't put pathes in the include line. Yes, it really depends on the project. It mainly becomes an issue for larger projects that may have a lot of libraries with their own include paths. But the file system is a big factor as well. I imagine the performance cost of open() calls can be quite expensive for some file systems. The project I have focused on had system load peaks reaching over 70% when using gcc, while with clang the peaks reached only around 8%. This extreme difference is what got me started looking into this to begin with. Actually, I did an experiment to wrap the open() call where I implemented my own caching (I wrapped gcc's call by creating a shared library and using LD_PRELOAD). With my quick and dirty hack the system load peaks were reduced to 11% and the overall build time was reduced by 12%. It's quite possible this is an extreme case, but I'm sure there are other large projects out there that would see noticeable improvements as well.
[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 --- Comment #11 from Jakub Jelinek --- And I don't see any code generation changes on the #c0 testcase with added #include with the patch.
[Bug preprocessor/109485] improve include path handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485 --- Comment #9 from Dani Borg --- (In reply to Andrew Pinski from comment #5) > Note I think clang's "optimization" might get the case where a subdirectory > is not "executable" but is readable wrong. > > So this is definitely something which would need testing too. The idea is just to check for the presence of directories and not to try to list the contents in them. I think various permissions can be handled just fine, but this is one of probably many corner cases that needs to be considered and handled correctly.
[Bug bootstrap/109460] Build gcc for win32 failed in gcc13 master branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460 --- Comment #36 from Costas Argyris --- Regarding usage of the -r flag: Building windows(mingw)-hosted gcc with clang at this point seems highly experimental at best, and impossible with msvc. With clang (lld linker), -r is supported with ELF, but not with COFF (windows). This sounds like incomplete support on the lld side though, and therefore not something that should prevent us from using -r (I think lld should support it for COFF as it does for ELF, because it is meant to be a drop-in replacement after all).
[Bug target/108809] gcc.target/powerpc/builtins-5-p9-runnable.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108809
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #2 from Jiu Fu Guo ---
(In reply to Kewen Lin from comment #1)
> It's very likely a test issue, may need to adjust some built-in function for
> endianness issue (as they have different element ordering on BE and LE).
Yeap it should be the test case issue on the difference between BE and LE:
For a buff `\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022`,
after loading to a vector right justified, the result is different between BE
and LE.
e.g. for a vector (from 128bit view: 0x102030405060708),
from v16_int8 view on BE, it is v16_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8}; but from the v16_int8 view on LE,
it is v16_int8 = {0x8, 0x7, 0x6, 0x5, 0x4, 0x3, 0x2, 0x1, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0}.
So, we would just need to update the expected result for BE for this test case.
[Bug c/109412] [13 Regression] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109412 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 54848 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54848&action=edit gcc13-pr109412.patch Untested fix.
[Bug c/107682] [13 Regression] ICE in c_parser_braced_init, at c/c-parser.cc:5619
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107682 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109412#c3 should fix this too.
[Bug tree-optimization/91355] [10/11/12/13 Regression] optimized code does not call destructor while unwinding after exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91355
Richard Biener changed:
What|Removed |Added
CC||matz at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Last reconfirmed|2019-08-05 00:00:00 |2023-4-13
--- Comment #17 from Richard Biener ---
Re-confirmed.
The implicit IL contract with the following is incredibly fragile:
[count: 0]:
:
d.1_16 = d;
_17 = d.1_16 + 4294967295;
d = _17;
resx 4 // EDGE_EH fallthru
[count: 0]:
:
_20 = __builtin_eh_filter (1);
if we don't support any stmts inbetween the RESX and the landing pad then
we should prohibit splitting the edge.
I think the issue is that splitting the EH edge creates a new landing pad
(OK), but when we sink stmts into that empty block there's a fallthru
from that landing pad to another landing pad. When ehcleanup then
elides the just RESX 4 containing forwarder via cleanup_empty_eh_merge_phis
that confuses it and the EH tree gets corrupt.
Into GIMPLE sink we get
Eh tree:
1 allowed_exceptions land:{1,},{3,} filter :-1 types:int
4 cleanup land:{2,}
which splitting two EH edges via split_edges_for_insertion turns into
Eh tree:
1 allowed_exceptions land:{4,},{1,},{3,} filter :-1 types:int
4 cleanup land:{2,}
remove_unreachable_handlers does
Eh tree:
1 allowed_exceptions land:{4,},{1,} filter :-1 types:int
4 cleanup land:{2,}
and cleanup_empty_eh
Eh tree:
1 allowed_exceptions land:{4,},{1,} filter :-1 types:int
4 cleanup
[Bug c++/109495] New: Stack is used (unexpectedly) for copying on-heap objects (while clang doesn't)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495
Bug ID: 109495
Summary: Stack is used (unexpectedly) for copying on-heap
objects (while clang doesn't)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bug-reports at xhtml dot guru
Target Milestone: ---
Could be a bug or could be a feature -- can't tell. Please help understand why
GCC involves stack in certain conditions when copying on-heap objects (no
problem in clang).
Problem:
In actual live project I have a large struct/class with a lot of data in it ("a
lot" is defined as larger than Wframe-larger-than), I've also got many
locations where that struct is copied (directly or indirectly), and got
Wframe-larger-than enabled. In some cases I'm hitting the error on lines that
_indirectly_ copy-construct the object from an object that's stored on heap
into an object that is also stored on heap (i.e. heap-to-heap operation, if you
will).
After finding minimal case that reproduces the issue
(https://godbolt.org/z/xcnP9E39a), disassembling the code and looking into
potential reasons why GCC might want to use the stack (and thus trigger
Wframe-larger-than), I see that (subjectively for no apparent reason) GCC
involves stack as an intermediate buffer, which I am looking to avoid. clang
doesn't use intermediate buffer in this same scenario. Some surprising
observations (which make the problem go away) might be indicative of a bug in
GCC:
1) If private member "y" of class Parent is made public, Wframe-larger-than
goes away (https://godbolt.org/z/G7x5EWKEf);
2) If type of member "s" of struct Child is changed from std::string to int,
the problem goes away (https://godbolt.org/z/zK6Wjj8nK);
3) If class Parent is adjusted so that there is no padding at the end, for
example by changing type of "z" member of class Parent to short
(https://godbolt.org/z/jsbsc6jcb) or by deleting member "z" altogether
(https://godbolt.org/z/3jqaoKse9), the problem goes away;
4) If inheritance is taken out of the equation, for example by aggregating
class Parent below class Child (instead of inheriting;
https://godbolt.org/z/451K1s7bc), the problem goes away.
Expected behavior: GCC not reporting Wframe-larger-than.
Actual behavior: GCC reports Wframe-larger-than.
// Code (attached as test.cpp):
#include
class Parent
{
private:
unsigned char y[ 1024 * 64 ]; // Beef up class' size past
Wframe-larger-than
public:
short x;// sizeof == 2 -> increases
alignment requirement to 2
char z; // sizeof == 1 -> triggers padding
(1) at the end of struct
};
struct Child : public Parent
{
std::string s;
};
int main( int, char** )
{
auto* ptr = new Child();
auto* ptr2 = new Child( *ptr ); // g++ reports frame-larger-than
violation; clang doesn't.
delete ptr2;
delete ptr;
return 0;
}
// Environment (gcc version):
$ g++ --version
g++ (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
// but it could be any GCC version.
// Command line (gcc; https://godbolt.org/z/xcnP9E39a):
$ g++ -Werror -Wframe-larger-than=4096 -o test test.cpp
/code/Src/E2EE/dstepanovs.cpp: In copy constructor ‘Child::Child(const
Child&)’:
/code/Src/E2EE/dstepanovs.cpp:14:8: error: the frame size of 65568 bytes is
larger than 4096 bytes [-Werror=frame-larger-than=]
14 | struct Child : public Parent
|^
cc1plus: all warnings being treated as errors
// Compiling same code with same flags with clang yields no error (clang
command line; https://godbolt.org/z/PMq5Yr3Tn):
$ clang++ -Werror -Wframe-larger-than=4096 -o test test.cpp
[Bug c++/109495] Stack is used (unexpectedly) for copying on-heap objects (no problem in clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495 --- Comment #1 from gcc-bug-reports at xhtml dot guru --- Created attachment 54849 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54849&action=edit test.cpp: test code that triggers Wframe-larger-than in GCC
[Bug tree-optimization/93271] [10/11/12/13 regression] SRA producing wrong code on denormals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
Last reconfirmed|2022-01-29 00:00:00 |2023-4-13
--- Comment #13 from Richard Biener ---
The issue is that on some targets (like i386) a FP load/store isn't a noop
but alters the bit representation. SRA in this case sees aggregate
store/load and scalar float store/load (but this one conditional).
In case there's a non-FP load or store of the part of the aggregate that's
also accessed as float there's no way to correctly perform the scalar
ops _but at the very point they are done originally_.
So the issue is we're doing the replacement in a non-flow-sensitive manner.
Of course when done flow-sentitive then the replacement will be pointless.
For long/double it's the same. There is currently no predicate that will
tell whether a target implements no-op reg = FP-mem; FP-mem = reg; so the
only "safe" fix would be to avoid scalarization of FP parts when the
initialization isn't provably done with FP stores.
int main ()
{
+ float a$b;
union test a;
float _1;
float _2;
@@ -82,14 +70,16 @@
:
a = set (); [return slot optimization]
+ a$b_7 = a.b;
goto ; [INV]
:
- _1 = a.b;
+ _1 = a$b_8;
_2 = _1 + 1.0e+0;
- a.b = _2;
+ a$b_11 = _2;
:
+ # a$b_8 = PHI
val.0_3 ={v} val;
if (val.0_3 != 0)
goto ; [INV]
@@ -97,8 +87,8 @@
goto ; [INV]
:
+ a.b = a$b_8;
get (a);
- a ={v} {CLOBBER(eol)};
return 0;
[Bug c++/109490] [11/12/13 Regression] ICE when declaring custom OpenMP reduction in generic Lambda in Template Function since r11-3236-g8155316c6fc230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109490 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.4 Priority|P3 |P2
[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491 --- Comment #6 from Richard Biener --- Doesn't happen with a cross from x86_64 to powerpc64-suse-linux. I've just used ./configure --target=powerpc64-suse-linux --enable-languages=c,c++,lto and ./cc1plus -quiet -I include t.ii -mcpu=power8 -std=c++14 -O2 and yes, it's very slow. I wonder if at the point of the crash e1 or e2 are NULL or whether we have garbage and what the actual hashtable entry / lookup val are. How did you configure?
[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-04-13 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Richard Biener --- Ah, the original reduced testcase reproduces the issue with a cross. Let me have a look.
[Bug fortran/109492] gcc/fortran/trans-expr.cc:3407:17: error: call of overloaded ‘abs(long long int&)’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109492 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-04-13 --- Comment #2 from Richard Biener --- It should use abs_hwi () instead (or maybe absu_hwi for safety).
[Bug c/109409] [13 Regression] ICE in check_format_arg, at c-family/c-format.cc:1777 since r13-2205-g14cfa01755a66a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109409 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 54850 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54850&action=edit gcc13-pr109409.patch Untested fix.
[Bug middle-end/109493] Broken O2 optimization on s390x in GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109493 Richard Biener changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED Target||s390x --- Comment #8 from Richard Biener --- just use memset(...) here
[Bug modula2/109488] typo in lang.opt: libraries maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109488 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-04-13
[Bug middle-end/109495] Stack is used (unexpectedly) for copying on-heap objects (no problem in clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Known to fail||13.0, 7.5.0 Version|unknown |13.0 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target||x86_64-*-* Last reconfirmed||2023-04-13 Status|UNCONFIRMED |NEW Component|c++ |middle-end Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Selected stringop expansion strategy: libcall Selected stringop expansion strategy: libcall Selected stringop expansion strategy: libcall Selected stringop expansion strategy: libcall ;; MEM[(struct Child *)_6].D.35468 = MEM[(const struct Child &)_3].D.35468; and for some reason we expand this to a memcpy to a stack temporary and then a memcpy from that stack temporary!?
[Bug modula2/109496] New: Cannot pass a constant char to an array of char formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109496
Bug ID: 109496
Summary: Cannot pass a constant char to an array of char formal
parameter
Product: gcc
Version: 13.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: ---
If a constant char is passed to an ARRAY OF CHAR formal parameter then the
parameter contains the address of the value of the char. It should promote a
char to a string.
MODULE singlechar ;
FROM libc IMPORT printf, exit ;
FROM StrLib IMPORT StrLen ;
PROCEDURE input (a: ARRAY OF CHAR) ;
BEGIN
IF StrLen (a) # 1
THEN
printf ("string length is not 1, but %d\n", StrLen (a)) ;
exit (1)
END
END input ;
BEGIN
input (015C) ;
printf ("successful test, finishing\n")
END singlechar.
[Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #8 from Xi Ruoyao --- (In reply to Jakub Jelinek from comment #7) > Similar bug. The basic GCC expectations for inline-asm is that the whole > assembly template after substitutions (which is for GCC mostly intentionally > a black box) works as a single instruction which reads all its inputs (and > that obviously doesn't mean just the input themselves, but also any other > register/memory used in the input) and then stores all its outputs. > Early clobbers are the way to tell the compiler that it is not the case and > some output is written before all the inputs are used. Should we add this info into the doc?
[Bug modula2/109496] Cannot pass a constant char to an array of char formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109496 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-04-13
[Bug modula2/109497] New: Adding two constant chars should result in a string of two chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109497
Bug ID: 109497
Summary: Adding two constant chars should result in a string of
two chars
Product: gcc
Version: 13.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: ---
Adding two constant chars should result in a string of two chars and not a
single char of the sum of the two constants.
MODULE addcharconst ;
FROM libc IMPORT printf, exit ;
FROM StrLib IMPORT StrLen ;
PROCEDURE input (a: ARRAY OF CHAR) ;
BEGIN
IF StrLen (a) # 2
THEN
printf ("string length is not 2, but %d\n", StrLen (a)) ;
exit (1)
END
END input ;
BEGIN
input (015C + 012C) ;
printf ("successful test, finishing\n")
END addcharconst.
[Bug modula2/109497] Adding two constant chars should result in a string of two chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109497 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-04-13
[Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484 --- Comment #9 from Jakub Jelinek --- The documentation already says that.
[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357 --- Comment #10 from chenglulu --- (In reply to Xi Ruoyao from comment #5) > The test fails on loongarch64-linux-gnu. foo is kept in 114t.threadfull1, > but removed in 135t.forwprop3. > > Does this mean something is wrong for LoongArch, or we should simply check > the tree dump in a later pass (for e.g. 254t.optimized)? If the definition of the macro DEFAULT_SIGNED_CHAR is changed to 0, the test case can pass the test. I guess it is because the definition of DEFAULT_SIGNED_CHAR affects the optimization of the ccp pass, resulting in some blocks that cannot be removed, resulting in the failure of this test case.
[Bug testsuite/109466] [13 regression] gfortran.dg/gomp/affinity-clause-1.f90 fails after r13-7120-g46fe32cb4d887d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109466 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jakub Jelinek --- I think this was fixed with r13-7137.
[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357 --- Comment #11 from Xi Ruoyao --- (In reply to chenglulu from comment #10) > (In reply to Xi Ruoyao from comment #5) > > The test fails on loongarch64-linux-gnu. foo is kept in 114t.threadfull1, > > but removed in 135t.forwprop3. > > > > Does this mean something is wrong for LoongArch, or we should simply check > > the tree dump in a later pass (for e.g. 254t.optimized)? > > If the definition of the macro DEFAULT_SIGNED_CHAR is changed to 0, the test > case can pass the test. I guess it is because the definition of > DEFAULT_SIGNED_CHAR affects the optimization of the ccp pass, resulting in > some blocks that cannot be removed, resulting in the failure of this test > case. Hmm, but we cannot change DEFAULT_SIGNED_CHAR or we'll break ABI and API everywhere. And x86_64-linux-gnu also uses DEFAULT_SIGNED_CHAR=1.
[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #8 from Richard Biener ---
So we have a NULL op, in this case
(gdb) p *vro1
$4 = {opcode = TARGET_MEM_REF, clique = 0, base = 0, reverse = 0, align = 0,
off = {coeffs = {-1}}, type = ,
op0 = , op1 = , op2 = }
(gdb) p *vro2
$5 = {opcode = TARGET_MEM_REF, clique = 0, base = 0, reverse = 0, align = 0,
off = {coeffs = {-1}}, type = ,
op0 = , op1 = ,
op2 = }
I think we're lucky to not hit this more often (good hash!) and unlucky
here (bad hash!). We used to have
/* If only one of them is null, they cannot be equal. */
if (!e1 || !e2)
return false;
but r11-4982-g4d6b8d4213376e removed that. r11-5047-gaaccdb9cec423e fixed
one case where that was previously needed.
Now, for TARGET_MEM_REF a NULL operand is different from an operand
with no effect (a zero) since the addressing mode is different. So
canonicalization in copy_reference_ops_from_ref is unwanted (we'd use
that representation for PRE insertion for example).
The safest option is to restore the above check.
[Bug tree-optimization/109269] [sve] should check the upper bound for predicate sve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109269 rsandifo at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING CC||rsandifo at gcc dot gnu.org Last reconfirmed||2023-04-13 --- Comment #5 from rsandifo at gcc dot gnu.org --- I don't think there's a problem with the example in comment 3. The loop is (deliberately) using 64-bit arithmetic, so no overflow will occur even for num==INT_MAX.
[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357 --- Comment #12 from chenglulu --- (In reply to Xi Ruoyao from comment #11) > (In reply to chenglulu from comment #10) > > (In reply to Xi Ruoyao from comment #5) > > > The test fails on loongarch64-linux-gnu. foo is kept in 114t.threadfull1, > > > but removed in 135t.forwprop3. > > > > > > Does this mean something is wrong for LoongArch, or we should simply check > > > the tree dump in a later pass (for e.g. 254t.optimized)? > > > > If the definition of the macro DEFAULT_SIGNED_CHAR is changed to 0, the test > > case can pass the test. I guess it is because the definition of > > DEFAULT_SIGNED_CHAR affects the optimization of the ccp pass, resulting in > > some blocks that cannot be removed, resulting in the failure of this test > > case. > > Hmm, but we cannot change DEFAULT_SIGNED_CHAR or we'll break ABI and API > everywhere. And x86_64-linux-gnu also uses DEFAULT_SIGNED_CHAR=1. Uh, I didn't notice this, I'll keep looking.
[Bug middle-end/109495] Stack is used (unexpectedly) for copying on-heap objects (no problem in clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Adjusted testcase so that it doesn't need headers:
struct A
{
A ();
~A ();
A (const A &);
};
struct B
{
private:
unsigned char y[1024 * 64];
public:
short x;
char z;
};
struct C : public B
{
A s;
};
int
main ()
{
C *ptr = new C ();
C *ptr2 = new C (*ptr);
delete ptr2;
delete ptr;
}
Commenting out the private: line makes it go away. Happens already in r105000
when I look at the frame sizes in the assembly (-Wframe-larger-than= wasn't
supported back then).
[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491 --- Comment #9 from Richard Biener --- Note it's IPA consuming the most time for me, but it might be just another case of always_inline abuse (having always_inline across a deep call stack can exponentially increase compile-time)
[Bug target/109498] New: SVE support for ctz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109498
Bug ID: 109498
Summary: SVE support for ctz
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
We fail to vectorise the following function with SVE:
// -march=armv8.2-a+sve -O2
void
ctz (int *__restrict x, int *__restrict y, int n)
{
for (int i = 0; i < n; i++)
x[i] = __builtin_ctz (y[i]);
}
It should use a combination of RBIT + CLZ.
[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 --- Comment #12 from Richard Biener --- (In reply to Jakub Jelinek from comment #11) > And I don't see any code generation changes on the #c0 testcase with added > #include with the patch. Yes, that's because we cannot disambiguate the call against a restrict qualified memory access. But otherwise it "works". Note maybe the restrict qualification isn't the best representation since it doesn't capture the value will die upon function return (does it? I gues the DTOR if any will run in caller context and thus stores to it are not necessarily "dead"). It's on my list of things to do to investigate adding "'restrict' support" to calls for GCC14.
[Bug target/109499] New: Unnecessary zeroing in SVE loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499
Bug ID: 109499
Summary: Unnecessary zeroing in SVE loops
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
The following two loops contain unnecessary zeroing operations:
// -march=armv8.2-a+sve -O2
void
f (int *__restrict x, int *__restrict y, int n)
{
for (int i = 0; i < n; i++)
x[i] = x[i] ? y[i] : 0;
}
void
g (int *__restrict x, int *__restrict y, int n)
{
for (int i = 0; i < n; i++)
x[i] = x[i] ? y[i] & 15 : 0;
}
Output:
f(int*, int*, int):
cmp w2, 0
ble .L1
mov x3, 0
cntwx4
whilelo p0.s, wzr, w2
mov z1.b, #0
.L3:
ld1wz0.s, p0/z, [x0, x3, lsl 2]
cmpne p1.s, p0/z, z0.s, #0
ld1wz0.s, p1/z, [x1, x3, lsl 2] // Sets inactive lanes to zero
sel z0.s, p1, z0.s, z1.s // Not needed
st1wz0.s, p0, [x0, x3, lsl 2]
add x3, x3, x4
whilelo p0.s, w3, w2
b.any .L3
.L1:
ret
g(int*, int*, int):
cmp w2, 0
ble .L6
mov x3, 0
cntwx4
whilelo p0.s, wzr, w2
mov z1.s, #15
.L8:
ld1wz0.s, p0/z, [x0, x3, lsl 2]
cmpne p1.s, p0/z, z0.s, #0
ld1wz0.s, p1/z, [x1, x3, lsl 2] // Sets inactive lanes to zero
movprfx z0.s, p1/z, z0.s // Not needed
and z0.s, p1/m, z0.s, z1.s// Could be AND (immediate)
st1wz0.s, p0, [x0, x3, lsl 2]
add x3, x3, x4
whilelo p0.s, w3, w2
b.any .L8
.L6:
ret
It would be good to model somehow that IFN_MASK_LOAD has a zeroing effect on
AArch64, so that this is exposed at the gimple level. At the same time, we
probably don't want the behaviour of the ifn to depend on target hooks. Not
sure what the best design is here.
[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #13 from Jakub Jelinek ---
(In reply to Richard Biener from comment #12)
> Note maybe the restrict qualification isn't the best representation since
> it doesn't capture the value will die upon function return (does it? I
> gues the DTOR if any will run in caller context and thus stores to it
> are not necessarily "dead").
Yes, the dtors will be invoked by the caller and those can inspect the values
and do all kinds of things with them.
In fact, the restrict isn't probably right either, the constructor of the
object in the caller could legally save the address of the object somewhere
else (say global pointer,
or inside of the object, or wherever else) and as long as say the destructor
undoes that, it could be valid.
Something like:
struct S {
static bool enabled;
static S *p;
S () : s (0) {}
~S () { if (enabled) p = nullptr; }
S (const S &x) : s (x.s) { if (enabled) p = this; }
int s;
};
[[gnu::noipa]] void
bar (S s)
{
s.s++;
S::p->s = 0;
s.s++;
}
void
foo ()
{
S s;
S::enabled = true;
bar (s);
}
[Bug target/108809] gcc.target/powerpc/builtins-5-p9-runnable.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108809
--- Comment #3 from Jiu Fu Guo ---
A similar different view between BE and LE on the vector for vec_xst_len_r.
For:
store_data_uc = (vector unsigned char){ 1, 2, 3, 4, 5, 6, 7, 8,
9, 10, 11, 12, 13, 14, 15, 16 };
vec_xst_len_r(store_data_uc, address, size);
On BE, from 128bit view (corresponding to store_data_uc) is
`0x102030405060708090a0b0c0d0e0f10`.
But on LE, from 128bit view, it is `0x100f0e0d0c0b0a090807060504030201`.
After right justified (left clean to 0s), the effective bytes to be stored to
buff on LE are those with smaller values (1,2,...);
On BE, the bytes to be stored are those with bigger values (16,15,...)
BTW: the generated insn sequence aligns with the example implementation in
PVIPR.
[Bug middle-end/109495] Stack is used (unexpectedly) for copying on-heap objects (no problem in clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495 --- Comment #4 from Richard Biener --- In store_field we run into /* If the structure is in a register or if the component is a bit field, we cannot use addressing to access it. Use bit-field techniques or SUBREG to store in it. */ because /* If the RHS and field are a constant size and the size of the RHS isn't the same size as the bitfield, we must use bitfield operations. */ || (known_size_p (bitsize) && poly_int_tree_p (TYPE_SIZE (TREE_TYPE (exp))) && maybe_ne (wi::to_poly_offset (TYPE_SIZE (TREE_TYPE (exp))), bitsize) as bitsize == 524312 and TYPE_SIZE == 524320 (we have a COMPONENT_REF here and the size of the FIELD_DECL is 524312!) and since !TREE_ADDRESSABLE we're happily oblieging here. And then we proceed with temp = expand_normal (exp); which results in a copy on the stack. I wonder why we should ever, for smaller bitsize, use a copy here, when bitsize/bitpos is a multiple of BITS_PER_UNIT? In particular I don't understand why we need TREE_ADDRESSABLE to let a proper COMPONENT_REF through? /* And except for bitwise copying of TREE_ADDRESSABLE types, where the FIELD_DECL has the right bitsize, but TREE_TYPE (exp) includes some extra padding. store_expr / expand_expr will in that case call get_inner_reference that will have the bitsize we check here and thus the block move will not clobber the padding that shouldn't be clobbered. In the future we could replace the TREE_ADDRESSABLE check with a check that get_base_address needs to live in memory. */ && (!TREE_ADDRESSABLE (TREE_TYPE (exp)) || TREE_CODE (exp) != COMPONENT_REF || !multiple_p (bitsize, BITS_PER_UNIT) || !multiple_p (bitpos, BITS_PER_UNIT) || !poly_int_tree_p (DECL_SIZE (TREE_OPERAND (exp, 1)), &decl_bitsize) || maybe_ne (decl_bitsize, bitsize)) removing the !TREE_ADDRESSABLE check fixes the testcase.
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #11 from Wilhelm M --- After testing some more code, I got this ICE: /home/lmeier/Projekte/wmucpp/boards/rcfoc/gimbal_sbus_01.cc: In static member function 'static void GlobalFsm::ratePeriodic() [with BusDevs =BusDevs > >]': /home/lmeier/Projekte/wmucpp/boards/rcfoc/gimbal_sbus_01.cc:426:5: error: unrecognizable insn: 426 | } | ^ (insn 1584 1583 25 3 (set (concatn:HI [ (reg:QI 800) (reg:QI 801 [+1 ]) ]) (reg:HI 826)) "../../include0/external/sbus/sbus.h":226:69 -1 (nil)) during RTL pass: subreg1 /home/lmeier/Projekte/wmucpp/boards/rcfoc/gimbal_sbus_01.cc:426:5: internal compiler error: in extract_insn, at recog.cc:2791 0x79f2cb _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.cc:108 0x79f2e7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/rtl-error.cc:116 0x79dc77 extract_insn(rtx_insn*) ../../gcc/recog.cc:2791 0x1a43d91 decompose_multiword_subregs ../../gcc/lower-subreg.cc:1651 0x1a447ca execute ../../gcc/lower-subreg.cc:1790 Please submit a full bug report, with preprocessed source (by using -freport-bug).
[Bug middle-end/109495] Stack is used (unexpectedly) for copying on-heap objects (no problem in clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495 --- Comment #5 from Richard Biener --- That said, the comment says padding that shouldn't be clobbered. In the future we could replace the TREE_ADDRESSABLE check with a check that get_base_address needs to live in memory. */ but maybe testing for BLKmode is enough here. So && ((mode != BLKmode && !TREE_ADDRESSABLE (TREE_TYPE (exp)))
[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491 --- Comment #10 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a37783de23c067d6a26374ff29c014e49604035c commit r13-7166-ga37783de23c067d6a26374ff29c014e49604035c Author: Richard Biener Date: Thu Apr 13 14:09:30 2023 +0200 tree-optimization/109491 - ICE in expressions_equal_p At some point I elided the NULL pointer check in expressions_equal_p because it shouldn't be necessary not realizing that for example TARGET_MEM_REF has optional operands we cannot substitute with something non-NULL with the same semantics. The following does the simple thing and restore the check removed in r11-4982. PR tree-optimization/109491 * tree-ssa-sccvn.cc (expressions_equal_p): Restore the NULL operands test.
[Bug middle-end/109495] Stack is used (unexpectedly) for copying on-heap objects (no problem in clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- The private keyword makes it non-POD and so the tail padding can be reused and we need to make sure we copy only the bits except for type padding. I guess we need some archeology why the exact conditions are in there.
[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|13.0|11.4 Summary|[13 Regression] Segfault in |[11/12 Regression] Segfault |tree-ssa-sccvn.cc:expressio |in |ns_equal_p()|tree-ssa-sccvn.cc:expressio ||ns_equal_p() --- Comment #11 from Richard Biener --- Fixed on trunk, the issue is latent though.
[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357 --- Comment #13 from rguenther at suse dot de --- On Thu, 13 Apr 2023, chenglulu at loongson dot cn wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357 > > --- Comment #10 from chenglulu --- > (In reply to Xi Ruoyao from comment #5) > > The test fails on loongarch64-linux-gnu. foo is kept in 114t.threadfull1, > > but removed in 135t.forwprop3. > > > > Does this mean something is wrong for LoongArch, or we should simply check > > the tree dump in a later pass (for e.g. 254t.optimized)? > > If the definition of the macro DEFAULT_SIGNED_CHAR is changed to 0, the test > case can pass the test. I guess it is because the definition of > DEFAULT_SIGNED_CHAR affects the optimization of the ccp pass, resulting in > some > blocks that cannot be removed, resulting in the failure of this test case. Can you check if making b unsigned fixes the test for you? If so that's what we should do.
[Bug target/109499] Unnecessary zeroing in SVE loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499 --- Comment #1 from Richard Biener --- Is there not enough info to catch this on the RTL level with a peephole?
[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #14 from Xi Ruoyao ---
(In reply to rguent...@suse.de from comment #13)
> On Thu, 13 Apr 2023, chenglulu at loongson dot cn wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
> >
> > --- Comment #10 from chenglulu ---
> > (In reply to Xi Ruoyao from comment #5)
> > > The test fails on loongarch64-linux-gnu. foo is kept in 114t.threadfull1,
> > > but removed in 135t.forwprop3.
> > >
> > > Does this mean something is wrong for LoongArch, or we should simply check
> > > the tree dump in a later pass (for e.g. 254t.optimized)?
> >
> > If the definition of the macro DEFAULT_SIGNED_CHAR is changed to 0, the test
> > case can pass the test. I guess it is because the definition of
> > DEFAULT_SIGNED_CHAR affects the optimization of the ccp pass, resulting in
> > some
> > blocks that cannot be removed, resulting in the failure of this test case.
>
> Can you check if making b unsigned fixes the test for you? If so
> that's what we should do.
It works：
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
index 44c457b7a97..79cf371ef28 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
@@ -1,7 +1,7 @@
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-threadfull1" } */
-static char b;
+static unsigned char b;
static unsigned c;
void foo();
short(a)(short d, short e) { return d * e; }
But I'm still wondering why this is not an issue for x86_64.
[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #14 from rguenther at suse dot de ---
On Thu, 13 Apr 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
>
> --- Comment #13 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #12)
> > Note maybe the restrict qualification isn't the best representation since
> > it doesn't capture the value will die upon function return (does it? I
> > gues the DTOR if any will run in caller context and thus stores to it
> > are not necessarily "dead").
>
> Yes, the dtors will be invoked by the caller and those can inspect the values
> and do all kinds of things with them.
> In fact, the restrict isn't probably right either, the constructor of the
> object in the caller could legally save the address of the object somewhere
> else (say global pointer,
> or inside of the object, or wherever else) and as long as say the destructor
> undoes that, it could be valid.
>
> Something like:
>
> struct S {
> static bool enabled;
> static S *p;
> S () : s (0) {}
> ~S () { if (enabled) p = nullptr; }
> S (const S &x) : s (x.s) { if (enabled) p = this; }
> int s;
> };
>
> [[gnu::noipa]] void
> bar (S s)
> {
> s.s++;
> S::p->s = 0;
> s.s++;
> }
>
> void
> foo ()
> {
> S s;
> S::enabled = true;
> bar (s);
> }
If that's valid then all bets for this PR are off since f() then
_can_ change v.size ().
[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #15 from rguenther at suse dot de ---
On Thu, 13 Apr 2023, xry111 at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
>
> --- Comment #14 from Xi Ruoyao ---
> (In reply to rguent...@suse.de from comment #13)
> > On Thu, 13 Apr 2023, chenglulu at loongson dot cn wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
> > >
> > > --- Comment #10 from chenglulu ---
> > > (In reply to Xi Ruoyao from comment #5)
> > > > The test fails on loongarch64-linux-gnu. foo is kept in
> > > > 114t.threadfull1,
> > > > but removed in 135t.forwprop3.
> > > >
> > > > Does this mean something is wrong for LoongArch, or we should simply
> > > > check
> > > > the tree dump in a later pass (for e.g. 254t.optimized)?
> > >
> > > If the definition of the macro DEFAULT_SIGNED_CHAR is changed to 0, the
> > > test
> > > case can pass the test. I guess it is because the definition of
> > > DEFAULT_SIGNED_CHAR affects the optimization of the ccp pass, resulting
> > > in some
> > > blocks that cannot be removed, resulting in the failure of this test case.
> >
> > Can you check if making b unsigned fixes the test for you? If so
> > that's what we should do.
>
> It works?
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
> b/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
> index 44c457b7a97..79cf371ef28 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c
> @@ -1,7 +1,7 @@
> /* { dg-do compile } */
> /* { dg-options "-O2 -fdump-tree-threadfull1" } */
>
> -static char b;
> +static unsigned char b;
> static unsigned c;
> void foo();
> short(a)(short d, short e) { return d * e; }
>
> But I'm still wondering why this is not an issue for x86_64.
Yes, that's interesting to see. It does change how b is extended
in b ^ 9854 (but for the value zero it doesn't matter).
[Bug target/109499] Unnecessary zeroing in SVE loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499 --- Comment #2 from rsandifo at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > Is there not enough info to catch this on the RTL level with a peephole? That works for simple cases like the first loop. But in general, I think we want the full power of gimple to push the information down. The second loop is one example of that, but in general, there could be a chain of operations that naturally do the right thing for inactive lanes.
[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 Jakub Jelinek changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #14) > If that's valid then all bets for this PR are off since f() then > _can_ change v.size (). Well, in C++ the ctors are typically defined inline, so if we wanted and they would be inline the FE could do some quick check whether the ctor could leak the this address or some address derived from it and we could do the optimization only if we prove that the copy constructor (and default constructor?) doesn't do this. CCing Jonathan on whether it is valid.
[Bug target/109499] Unnecessary zeroing in SVE loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499 --- Comment #3 from rguenther at suse dot de --- On Thu, 13 Apr 2023, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499 > > --- Comment #2 from rsandifo at gcc dot gnu.org > --- > (In reply to Richard Biener from comment #1) > > Is there not enough info to catch this on the RTL level with a peephole? > That works for simple cases like the first loop. But in general, I think we > want the full power of gimple to push the information down. The second loop > is > one example of that, but in general, there could be a chain of operations that > naturally do the right thing for inactive lanes. AVX512 masking allows merge and zero modes, zero being cheaper (obviously). I think "zero" is what all targets support so we could define GIMPLE to be that way - inactive lanes become zero. That's then also less of a "partial definition" and "undefined" should be avoided at best?
[Bug fortran/109500] New: SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 Bug ID: 109500 Summary: SIGABRT when calling a function that returns an unallocated value Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: leandro.lupori at linaro dot org Target Milestone: --- While doing some tests with functions that return an allocatable result, I found out that the following program receives a SIGABRT: program main print *, is_allocated(f()) contains function f() integer, allocatable :: f end function logical function is_allocated(p) integer, allocatable :: p is_allocated = allocated(p) end function end program This is the output (without the backtrace): free(): invalid pointer Program received signal SIGABRT: Process abort signal. I tested it with gfortran 11.3.0 and 12.0.0 20220117 (experimental) [master r12-6624-gb75aab194e3] (from gcc-snapshot). The program above is a reduced version. I was actually trying to use a function that could return either an allocated result or an unallocated one, depending on the argument, such as: function f(p) integer, allocatable :: f, p if (allocated(p)) then f = p endif end function
[Bug c++/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 --- Comment #16 from rguenther at suse dot de --- On Thu, 13 Apr 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||redi at gcc dot gnu.org > > --- Comment #15 from Jakub Jelinek --- > (In reply to rguent...@suse.de from comment #14) > > If that's valid then all bets for this PR are off since f() then > > _can_ change v.size (). > > Well, in C++ the ctors are typically defined inline, so if we wanted and they > would be inline the FE could do some quick check whether the ctor could leak > the this address or some address derived from it and we could do the > optimization only if we prove that the copy constructor (and default > constructor?) doesn't do this. Yes, with IPA we could also figure out cases where arguments / return by reference could be effectively restrict.
[Bug c++/109501] New: vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 Bug ID: 109501 Summary: vec_test_data_class defines missing Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: chip.kerchner at ibm dot com Target Milestone: --- These defines seems to be missing #define __VEC_CLASS_FP_NAN (1<<6) #define __VEC_CLASS_FP_INFINITY_P (1<<5) #define __VEC_CLASS_FP_INFINITY_N (1<<4) #define __VEC_CLASS_FP_ZERO_P (1<<3) #define __VEC_CLASS_FP_ZERO_N (1<<2) #define __VEC_CLASS_FP_SUBNORMAL_P (1<<1) #define __VEC_CLASS_FP_SUBNORMAL_N (1<<0) #define __VEC_CLASS_FP_INFINITY (__VEC_CLASS_FP_INFINITY_P | __VEC_CLASS_FP_INFINITY_N) #define __VEC_CLASS_FP_ZERO (__VEC_CLASS_FP_ZERO_P | __VEC_CLASS_FP_ZERO_N) #define __VEC_CLASS_FP_SUBNORMAL (__VEC_CLASS_FP_SUBNORMAL_P | __VEC_CLASS_FP_SUBNORMAL_N) #define __VEC_CLASS_FP_NOT_NORMAL (__VEC_CLASS_FP_NAN | __VEC_CLASS_FP_SUBNORMAL | __VEC_CLASS_FP_ZERO | __VEC_CLASS_FP_INFINITY)
[Bug c++/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 Chip Kerchner changed: What|Removed |Added CC||chip.kerchner at ibm dot com --- Comment #1 from Chip Kerchner --- ``` __vector float p4f = some data; 1645 | __vector __bool int nan_selector = vec_test_data_class(p4f, __VEC_CLASS_FP_NAN); ```
[Bug c++/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 --- Comment #2 from Chip Kerchner --- '__VEC_CLASS_FP_NAN' was not declared in this scope
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 Andrew Pinski changed: What|Removed |Added Component|c++ |target --- Comment #3 from Andrew Pinski --- Which target is this for? If s390 did you include vecintrin.h?
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 --- Comment #4 from Chip Kerchner --- PowerPC LE - P9. Yes, other PVIPR APIs are available and compile in more source code.
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #5 from Chip Kerchner ---
Here's a testcase
```
#include
#include
int main()
{
__vector float p4f = { float(0), float(1), float(2), float(3) };
__vector __bool int nan_selector = vec_test_data_class(p4f,
__VEC_CLASS_FP_NAN);
return 0;
}
```
```
NAN_defines.cpp: In function ‘int main()’:
NAN_defines.cpp:7:63: error: ‘__VEC_CLASS_FP_NAN’ was not declared in this
scope
7 | __vector __bool int nan_selector = vec_test_data_class(p4f,
__VEC_CLASS_FP_NAN);
|
^~
```
```
/opt/gcc-nightly/trunk/bin/g++ -O3 -mcpu=power9 NAN_defines.cpp
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #6 from Segher Boessenkool --- None of those are required. All are optional. No portable code should use them.
[Bug target/109499] Unnecessary zeroing in SVE loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499 --- Comment #4 from rsandifo at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #3) > AVX512 masking allows merge and zero modes, zero being cheaper > (obviously). I think "zero" is what all targets support so we could > define GIMPLE to be that way - inactive lanes become zero. That's > then also less of a "partial definition" and "undefined" should be > avoided at best? Thanks, sounds good to me. If direct support for merging turns out to be useful in future, maybe we could add the value of inactive lanes as an extra parameter at that point. Would be quite an invasive change, but it would just be work.
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 --- Comment #7 from Segher Boessenkool --- "For clarity of code, the following named constants are suggested. Preferably, compilers will provide these constants in a header file, but this is not required for compliance."
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-04-13 Ever confirmed|0 |1 Component|c++ |target Keywords|diagnostic |wrong-code Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- Can you provide the information as requested on https://gcc.gnu.org/bugs/ ? At least the output of "gcc -v". Also can you attach the testcase and not use cmake as cmake makes it hard to figure out the exact command line which is being invoked, a shell script or a simple make file should be enough?
[Bug target/109501] vec_test_data_class defines missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 --- Comment #8 from Chip Kerchner --- Well, then I'm asking GCC to add these to make it easier to use `vec_test_data_class`
[Bug c/56528] __attribute__((visibility)) ignored for a function declaration with an asm label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56528 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2023-04-13 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Fortunately, this is not a bug in gfortran. Unfortunately, this is a bug in your program. A function is required by the Fortran standard to have its result variable assigned when it returns. If you compile your code with the -Wall option, you'll see gfortran -o z -Wall a.f90 a.f90:5:2: 5 | function f() | 1 Warning: Return value of function 'f' at (1) not set [-Wreturn-type] On my system, 'z' either segfaults or prints 'T'. For 'T' the function f() is pointing to whatever is left on the stack.
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 --- Comment #12 from Segher Boessenkool --- With the modified compiler? Does it ICE with an unmodified compiler as well?
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #2 from Oliver Rosten --- Created attachment 54851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54851&action=edit Preprocessed file
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #3 from Oliver Rosten --- Created attachment 54852 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54852&action=edit Preprocessed file for Test.cpp
[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109277 Jason Merrill changed: What|Removed |Added Last reconfirmed|2023-03-24 00:00:00 |2023-04-13 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug target/100836] microblaze-linux: RTX may be used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100836 Jan-Benedict Glaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Jan-Benedict Glaw --- This is fixed in recent builds, so I'm closing this ticket.
[Bug target/100268] lm32-uclinux: ../.././gcc/config/lm32/uclinux-elf.h:70: error: "LINK_GCC_C_SEQUENCE_SPEC" redefined [-Werror]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100268 Jan-Benedict Glaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Jan-Benedict Glaw --- This seems to be fixed, so I'm closing this ticket.
[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910 --- Comment #14 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:66946624b96b762985de56444d726a0ebd4e0df5 commit r13-7167-g66946624b96b762985de56444d726a0ebd4e0df5 Author: Richard Sandiford Date: Thu Apr 13 16:57:57 2023 +0100 aarch64: Don't trust TYPE_ALIGN for pointers [PR108910] The aarch64 PCS rules ignore user alignment for scalars and vectors and use the "natural" alignment of the type. GCC tried to calculate that natural alignment using: TYPE_ALIGN (TYPE_MAIN_VARIANT (type)) But as discussed in the PR, it's possible that the main variant of a pointer type is an overaligned type (although that's usually accidental). This isn't known to be a problem for other types, so this patch changes the bare minimum. It might be that we need to ignore TYPE_ALIGN in other cases too. gcc/ PR target/108910 * config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Do not trust TYPE_ALIGN for pointer types; use POINTER_SIZE instead. gcc/testsuite/ PR target/108910 * gcc.dg/torture/pr108910.c: New test.
[Bug target/108910] [12 Regression] Further ICE in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910 rsandifo at gcc dot gnu.org changed: What|Removed |Added Summary|[12/13 Regression] Further |[12 Regression] Further ICE |ICE in aarch64_layout_arg |in aarch64_layout_arg Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #15 from rsandifo at gcc dot gnu.org --- Fixed on trunk so far.
[Bug modula2/109496] Cannot pass a constant char to an array of char formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109496 --- Comment #1 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:a1afdc6e2aa77d0a990e1a82aceeffc837b7e50c commit r13-7168-ga1afdc6e2aa77d0a990e1a82aceeffc837b7e50c Author: Gaius Mulley Date: Thu Apr 13 17:02:48 2023 +0100 PR modula2/109496 Fix constant char parameter passing to an array of char This patch fixes PR modula2/109496 and PR modula2/109497. The fix for PR modula2/109496 promotes a char constant to a string. The PR modula2/109497 allows for constant chars to be added to form a string. The fixes for both PR's occur in M2GenGCC.mod and M2GCCDeclare.mod after the resolving of constant declarations. gcc/m2/ChangeLog: * gm2-compiler/M2ALU.def (PopChar): New procedure function. * gm2-compiler/M2ALU.mod (PopChar): New procedure function. * gm2-compiler/M2GCCDeclare.mod (PromoteToString): Detect a single constant char and build a C string. * gm2-compiler/M2GenGCC.mod (IsConstStr): New procedure function. (GetStr): New procedure function. (FoldAdd): Use IsConstStr. * gm2-compiler/M2Quads.mod: Formatting changes. * gm2-gcc/m2expr.cc (m2expr_GetCstInteger): New function. * gm2-gcc/m2expr.def (GetCstInteger): New procedure function. * gm2-gcc/m2expr.h (m2expr_GetCstInteger): New prototype. gcc/testsuite/ChangeLog: PR modula2/109497 * gm2/pim/run/pass/addcharconst.mod: New test. PR modula2/109496 * gm2/pim/run/pass/singlechar.mod: New test. Signed-off-by: Gaius Mulley
[Bug modula2/109497] Adding two constant chars should result in a string of two chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109497 --- Comment #1 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:a1afdc6e2aa77d0a990e1a82aceeffc837b7e50c commit r13-7168-ga1afdc6e2aa77d0a990e1a82aceeffc837b7e50c Author: Gaius Mulley Date: Thu Apr 13 17:02:48 2023 +0100 PR modula2/109496 Fix constant char parameter passing to an array of char This patch fixes PR modula2/109496 and PR modula2/109497. The fix for PR modula2/109496 promotes a char constant to a string. The PR modula2/109497 allows for constant chars to be added to form a string. The fixes for both PR's occur in M2GenGCC.mod and M2GCCDeclare.mod after the resolving of constant declarations. gcc/m2/ChangeLog: * gm2-compiler/M2ALU.def (PopChar): New procedure function. * gm2-compiler/M2ALU.mod (PopChar): New procedure function. * gm2-compiler/M2GCCDeclare.mod (PromoteToString): Detect a single constant char and build a C string. * gm2-compiler/M2GenGCC.mod (IsConstStr): New procedure function. (GetStr): New procedure function. (FoldAdd): Use IsConstStr. * gm2-compiler/M2Quads.mod: Formatting changes. * gm2-gcc/m2expr.cc (m2expr_GetCstInteger): New function. * gm2-gcc/m2expr.def (GetCstInteger): New procedure function. * gm2-gcc/m2expr.h (m2expr_GetCstInteger): New prototype. gcc/testsuite/ChangeLog: PR modula2/109497 * gm2/pim/run/pass/addcharconst.mod: New test. PR modula2/109496 * gm2/pim/run/pass/singlechar.mod: New test. Signed-off-by: Gaius Mulley
[Bug modula2/109496] Cannot pass a constant char to an array of char formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109496 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Gaius Mulley --- Closed as patch (and test code) has been applied.
[Bug modula2/109497] Adding two constant chars should result in a string of two chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109497 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Gaius Mulley --- Closing as patch has been applied and regression test code added.
[Bug target/109502] New: [12/13 Regression] wrong code with -O -ftree-vectorize -fvect-cost-model=unlimited on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109502 Bug ID: 109502 Summary: [12/13 Regression] wrong code with -O -ftree-vectorize -fvect-cost-model=unlimited on aarch64 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 54853 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54853&action=edit reduced testcase Output: $ aarch64-unknown-linux-gnu-gcc -O -ftree-vectorize -fvect-cost-model=unlimited testcase.c -static $ qemu-aarch64 -- ./a.out qemu: uncaught target signal 6 (Aborted) - core dumped Aborted The value is 0x instead of 1. $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-7165-20230413001648-g66c7257b675-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-7165-20230413001648-g66c7257b675-checking-yes-rtl-df-extra-aarch64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.1 20230413 (experimental) (GCC)
[Bug target/109501] rs6000: Add suggested defines for vec_test_data_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2023-04-13 Ever confirmed|0 |1 Summary|vec_test_data_class defines |rs6000: Add suggested |missing |defines for ||vec_test_data_class Priority|P3 |P4 Status|UNCONFIRMED |NEW Severity|normal |enhancement --- Comment #9 from Segher Boessenkool --- I marked this as enhancement, and changed the summary. Thanks!
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 Allan W. Macdonald changed: What|Removed |Added CC||allan.w.macdonald at gmail dot com --- Comment #5 from Allan W. Macdonald --- This is annoying as it breaks all my existing makefiles. Here is a workaround: $ gcc-11 -E -MMD test.c > /dev/null
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 --- Comment #6 from Allan W. Macdonald --- (In reply to Allan W. Macdonald from comment #5) > Here is a workaround: or just gcc -E -MMD test.c > /dev/null if gcc-11 is default gcc.
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 --- Comment #7 from Andrew Pinski --- Does using -c instead help?
