[Bug tree-optimization/98304] Failure to optimize bitwise arithmetic pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98304 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed
[Bug driver/86030] specs file processing does not create response files for input directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030 --- Comment #18 from John Soo --- And actually the proposed patch is not conservative enough, because the size of the strings in argv/env also matter.
[Bug tree-optimization/106379] DCE depends on order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106379 Andrew Pinski changed: What|Removed |Added Blocks||106380, 106505, 106381 Depends on|106380 | --- Comment #7 from Andrew Pinski --- bug 106380, bug 106381 and bug 106505 are all the basic issue now transforming `~a & b` and `~a | b` into `a < b` and `a <= b`. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380 [Bug 106380] DCE depends on datatype used (bool vs unsigned) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106381 [Bug 106381] DCE depends on used programming language (C vs C++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106505 [Bug 106505] DCE depends on whether if or else is used
[Bug tree-optimization/106505] DCE depends on whether if or else is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106505 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-09-17 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
[Bug tree-optimization/109546] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-3596-ge7310e24b1c0ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|13.3|14.0 Status|UNCONFIRMED |RESOLVED --- Comment #8 from Andrew Pinski --- Fixed.
[Bug analyzer/110529] Analyzer fails to handle computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110529 --- Comment #6 from mengli ming --- (In reply to David Malcolm from comment #5) > Should be fixed on trunk for gcc 14 by the above commit. Thanks a lot for your hard work!
[Bug target/111438] Missing libSystem.B.dylib during execution - Mac OS 13.5.2 (22G91), XCODE: Version 14.3.1 (14E300c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111438 --- Comment #4 from Andrew Pinski --- Also see https://github.com/containerd/containerd/discussions/5525#discussioncomment-2685649
[Bug target/111438] Missing libSystem.B.dylib during execution - Mac OS 13.5.2 (22G91), XCODE: Version 14.3.1 (14E300c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111438 --- Comment #3 from Andrew Pinski --- (In reply to Gamal Akabani from comment #2) > (In reply to Andrew Pinski from comment #1) > > >GCC: 13.2.0, GCC, gfortran was installed using homebrew > > > but the code sometimes crashes in my new Mac Studio M2 Pro. > > > > GCC upstream does not have support for aarch64-darwin yet. > > So you will need to report this first to homebrew. > > Dear Andrew, > > Thank you for your prompt response. I am a bit confused. > So the gfortran compiler offered for Apple Silicon machines using the link > below is incompatible? > Do I also need to report this bug to Git Hub, gfortran-for-macOS? > > https://github.com/fxcoudert/gfortran-for-macOS/releases > > If you could elaborate, I would be very appreciative. Yes you should report it to that github or to homebrew. The support for Mac OS ARM64 is not supported in the sources in gcc.gnu.org version.
[Bug target/111438] Missing libSystem.B.dylib during execution - Mac OS 13.5.2 (22G91), XCODE: Version 14.3.1 (14E300c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111438 --- Comment #2 from Gamal Akabani --- (In reply to Andrew Pinski from comment #1) > >GCC: 13.2.0, GCC, gfortran was installed using homebrew > > but the code sometimes crashes in my new Mac Studio M2 Pro. > > GCC upstream does not have support for aarch64-darwin yet. > So you will need to report this first to homebrew. Dear Andrew, Thank you for your prompt response. I am a bit confused. So the gfortran compiler offered for Apple Silicon machines using the link below is incompatible? Do I also need to report this bug to Git Hub, gfortran-for-macOS? https://github.com/fxcoudert/gfortran-for-macOS/releases If you could elaborate, I would be very appreciative. Thank you
[Bug target/111438] Missing libSystem.B.dylib during execution - Mac OS 13.5.2 (22G91), XCODE: Version 14.3.1 (14E300c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111438 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|fortran |target Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- >GCC: 13.2.0, GCC, gfortran was installed using homebrew > but the code sometimes crashes in my new Mac Studio M2 Pro. GCC upstream does not have support for aarch64-darwin yet. So you will need to report this first to homebrew.
[Bug fortran/111438] New: Missing libSystem.B.dylib during execution - Mac OS 13.5.2 (22G91), XCODE: Version 14.3.1 (14E300c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111438
Bug ID: 111438
Summary: Missing libSystem.B.dylib during execution - Mac OS
13.5.2 (22G91), XCODE: Version 14.3.1 (14E300c)
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gamal.akabani at gmail dot com
Target Milestone: ---
Hi,
First of all, I am no expert, and I am posting a bug for the first time. Please
bear with me if my narrative is incomplete. I am running the code "talys" for
nuclear reactions. The code runs fine on my old Mac Intel, but the code
sometimes crashes in my new Mac Studio M2 Pro.
I made contact with the Mac developer team, and I got nowhere, as they claim
that the dynamic libraries are now loaded differently.
Please see the following link and narrative
https://developer.apple.com/forums/thread/722360?login=true
___
GCC: 13.2.0, GCC, gfortran was installed using homebrew
___
System: Mac OS 13.5.2 VENTURA
XCODE: Version 14.3.1 (14E300c)
Command line tools were installed using: xcode-select --install
__
The options given when GCC was configured/built;
A script was used with the following commands
${compiler} -c *.f
${compiler} *.o -o talys
The executable "talys" was generated without any problems.
___
The complete command line that triggers the bug;
The code runs and executes normally in some cases, while in other cases, it
crashes with the following
___
the compiler output (error messages, warnings, etc.); and
the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below).
(base) gamalakabani@Gamals-Mac-Studio samples % ./verify
*** Running sample case ./a-Ho165-omp1/new
dyld[9171]: dyld cache '(null)' not loaded: syscall to map cache into shared
region failed
dyld[9171]: Library not loaded: /usr/lib/libSystem.B.dylib
Referenced from:
/Users/gamalakabani/Applications/TALYS_CODE/talys/bin/talys
Reason: tried: '/usr/lib/libSystem.B.dylib' (no such file),
'/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib' (no such
file), '/usr/lib/libSystem.B.dylib' (no such file, no dyld cache),
'/usr/local/lib/libSystem.B.dylib' (no such file)
./verify: line 12: 9171 Abort trap: 6 $talys < talys.inp > talys.out
___
The library libSystem.B.dylib is not loading in some instances.
___
I can further provide more information if you let me know what steps to take.
Thank you
GA
[Bug middle-end/108847] [11/12/13/14 Regression] unnecessary bitwise AND on boolean types and shifting of the "sign" bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52345 --- Comment #7 from Andrew Pinski --- Funny, the match pattern in comment #5 is similar to the one which I was working on for PR 52345 .
[Bug tree-optimization/111435] [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/630668.html --- Comment #8 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630668.html
[Bug tree-optimization/109960] [11/12/13/14 Regression] missing combining of `(a&1) != 0 || (a&2)!=0` into `(a&3)!=0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960 --- Comment #9 from Andrew Pinski --- Created attachment 55915 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55915=edit match pattern for the non-ifcombine case sometimes we need to handle this outside of ifcombine due to phiopt or other passes. So this adds that pattern.
[Bug middle-end/108370] gcc doesn't merge bitwise-AND if an explicit comparison against 0 is given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370 --- Comment #7 from Andrew Pinski --- Created attachment 55914 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55914=edit Patch Combined with the patch for PR 109960. We are able to optimize this correctly: _5 = bio_4(D)->bi_flags; _8 = _5 & 3; if (_8 != 0) goto ; [66.50%] else goto ; [33.50%] [local count: 714038312]: _1 = (int) mark_dirty_6(D); __bio_release_pages (bio_4(D), _1); [tail call]
[Bug middle-end/108370] gcc doesn't merge bitwise-AND if an explicit comparison against 0 is given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > _10 = _9 >> 1; > _11 = (bool) _10; > if (_11 != 0) > > > Should just be optimized to: > _t = _9 & 1 > if (_t != 0) > > Let me add that to match. We do handle: /* Fold ((X << C1) & C2) cmp C3 into (X & (C2 >> C1)) cmp (C3 >> C1) ((X >> C1) & C2) cmp C3 into (X & (C2 << C1)) cmp (C3 << C1). */
[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243 --- Comment #15 from Alex Mohr --- Thank you Richard B, Richard G, Xi, Jonathan, Jakub, and Eric for all the great info. Much appreciated. With more experience using '-Og -fno-inline' I've found that sometimes inspecting local variables doesn't work -- "". So I'll continue using -O0 for now. To offer my perspective as a user, I think the manual should step back a bit from recommending -Og as the default opt level for the edit/debug cycle, at least in its current state. Or at the very least, some mention of caveats would be valuable. That said I love that you're pursuing this direction and I'm eager to see how this develops going forward. Cheers!
[Bug middle-end/108370] gcc doesn't merge bitwise-AND if an explicit comparison against 0 is given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370 --- Comment #5 from Andrew Pinski --- _10 = _9 >> 1; _11 = (bool) _10; if (_11 != 0) Should just be optimized to: _t = _9 & 1 if (_t != 0) Let me add that to match.
[Bug tree-optimization/109960] [11/12/13/14 Regression] missing combining of `(a&1) != 0 || (a&2)!=0` into `(a&3)!=0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960 --- Comment #8 from Andrew Pinski --- Created attachment 55913 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55913=edit part of the ifcombine fixes It does not catch: _10 = _5 >> 1; _11 = (_Bool) _10; if (_11 != 0) Though. I will add that in a bit. That is used for PR 108370.
[Bug middle-end/108370] gcc doesn't merge bitwise-AND if an explicit comparison against 0 is given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Andrew Pinski --- Mine.
[Bug tree-optimization/109960] [11/12/13/14 Regression] missing combining of `(a&1) != 0 || (a&2)!=0` into `(a&3)!=0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- Mine.
[Bug tree-optimization/111435] [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435 --- Comment #7 from Andrew Pinski --- Created attachment 55912 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55912=edit Patch which I am testing
[Bug c++/111436] Wrong code when bit-casting struct through pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111436 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- You are type punning and that will almost definitely cause undefined code due to alias violations. You could use memcpy instead of the which will (almost; standard layout structures [or POD for pre C++11]) always work.
[Bug c/111437] Some always inline functions are incorrectly warn of as "might not be inlinable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111437 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-09-16 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source where the warning is and the exact command line you are using to invoke gcc? I suspect the issue is that the function can be overridden due to use of -fPIC or something smilar to that.
[Bug tree-optimization/111435] [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435 --- Comment #6 from Andrew Pinski --- Note my testcase needs exceptions turned on ...
[Bug c/111437] New: Some always inline functions are incorrectly warn of as "might not be inlinable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111437 Bug ID: 111437 Summary: Some always inline functions are incorrectly warn of as "might not be inlinable" Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gb2985 at gmail dot com Target Milestone: --- Couldn't find a similar thread so my apologies if there actually was. For starters a link to the code that made me cotton on to the issue: https://gitlab.com/awsdert/dragonbuilder/-/blob/419c686fd59c0a40145154ef3d43b8d8b75aa29d/include/paw/pawidb.h#L34 In short it amounts to a simple LOAD, DIV, STORE set of instructions once compiled which is undoubtedly inline-able in all situations. I had marked the function as always inline but when gcc got to it it decided that no, those measly few instructions are somehow not inlinable. The issue also occurs for wrapped calls such as pawcv_gettop() calling the template generated _pawcv_gettop(), the former existing for intellisense purposes while the latta being what does the actual work. I seriously doubt my system or any other details are relevant here but for what I need to provide I'll add below (only remember one at time of posting, will edit in rest if I can): OS: Manjaro x64 XFCE (4.18)
[Bug tree-optimization/111435] [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435
--- Comment #5 from Andrew Pinski ---
Here is a better testcase:
```
void find_slot_with_hash(const int &,int, int);
void put(const int , const int ) {
find_slot_with_hash(k, 0, 1);
__builtin_unreachable();
}
unsigned len();
int *address();
void h(int header, int **bounds) {
if (!*bounds)
return;
unsigned t = *bounds ? len() : 0;
int queue_index = t;
address()[(unsigned)queue_index] = 0;
put(header, queue_index);
}
```
[Bug tree-optimization/111435] [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435
--- Comment #4 from Sergei Trofimovich ---
Meanwhile cvise extracted this test:
// $ cat tree-ssa-loop-niter.cc.cc
int discover_iteration_bound_by_body_walk_queue_index, m_vec;
int *address();
unsigned length();
int deref(unsigned ix) {
int __trans_tmp_1 = address()[ix];
return __trans_tmp_1;
}
unsigned discover_iteration_bound_by_body_walk___trans_tmp_4;
void discover_iteration_bound_by_body_walk() {
bool __trans_tmp_3 = m_vec;
if (!__trans_tmp_3)
return;
discover_iteration_bound_by_body_walk___trans_tmp_4 = m_vec ? length() : 0;
discover_iteration_bound_by_body_walk_queue_index =
discover_iteration_bound_by_body_walk___trans_tmp_4;
for (;;)
deref(discover_iteration_bound_by_body_walk_queue_index);
}
[Bug c++/111436] New: Wrong code when bit-casting struct through pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111436
Bug ID: 111436
Summary: Wrong code when bit-casting struct through pointer
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: josopait at goopax dot com
Target Milestone: ---
Does gcc produce wrong code here? The program below is part of a bitwise
conversion mechanism, similar to std::bit_cast, but for more general types.
The output should be:
from=17,23
to=17,23
But with -O2 or higher the output is:
from=17,23
to=0,0
I tried with gcc 12, 13, and 14 on x86_64 linux.
#include
#include
#include
using namespace std;
template
inline void reinterpret_switch3(TO& to, const FROM& from)
{
to = *reinterpret_cast();
}
template
inline void reinterpret_switch2(TO& to, const FROM& from)
{
reinterpret_switch3(to, array({ { from } }));
}
template
inline void reinterpret_switch(TO& to, const FROM& from)
{
array tmp;
reinterpret_switch2(tmp, from);
to = tmp[0];
}
int main(int argc, char** argv)
{
pair from = {17, 23};
pair to;
reinterpret_switch(to, from);
cout << "from=" << from.first << "," << from.second << endl;
cout << "to=" << to.first << "," << to.second << endl;
}
[Bug tree-optimization/111435] [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435 --- Comment #3 from Andrew Pinski --- Changing the match pattern for conversions to non-recusive fixes the issue. That is: /* A conversion from an zero_one_valued_p is still a [0,1]. This is useful when the range of a variable is not known */ /* Note this matches can't be recusive because of the way VN handles nop conversions being equivalent and then recusive between them. */ (match zero_one_valued_p (convert@0 @1) (if (INTEGRAL_TYPE_P (TREE_TYPE (@1)) && (TYPE_UNSIGNED (TREE_TYPE (@1)) || TYPE_PRECISION (TREE_TYPE (@1)) > 1) && wi::leu_p (tree_nonzero_bits (@1), 1
[Bug tree-optimization/52345] Missed optimization dealing with bools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52345
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> // (a | zero_one) != 0 -> a!=0 | zero_one
>
> (simplify
> (ne (bit_ior:c @1 zero_one_value_p@2) integer_zerop@3)
> (bit_ior (convert @1) (ne @2 @3)))
>
>
> // (a & zero_one) != 0 -> a==0 & (zero_one^1)
Should have been:
// (a & zero_one) == 0 -> a==0 & (zero_one^1)
> (simplify
> (eq (bit_and:c @1 zero_one_value_p@2) integer_zerop@3)
> (bit_and
> (convert (bit_xor @1 { build_one_cst (TREE_TYPE (@1)); } ))
> (ne @2 @3)))
>
>
> Similar to:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630651.html
[Bug tree-optimization/111435] [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435 --- Comment #2 from Andrew Pinski --- So Basically you can't have a recusive match because of the way VN works ... I should have figured that out when I was adding bitwise_inverted_equal_p .
[Bug tree-optimization/111435] [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-09-16 Keywords||build, ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Target Milestone|--- |14.0 --- Comment #1 from Andrew Pinski --- Must be something 32bit related ...
[Bug tree-optimization/111435] New: [14 Regression] gimple_zero_one_valued_p() infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111435 Bug ID: 111435 Summary: [14 Regression] gimple_zero_one_valued_p() infinite recursion Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Created attachment 55911 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55911=edit tree-ssa-loop-niter.cc.cc.gz Noticed on i686-linux gcc bootstrap when building r14-4077-g86451305d8b2a2. Reproduced on x86_64-linux -m32 as well. r14-4038-gb975c0dc3be285 looks suspicious. The reduction is a bit slow. Attaching partially reduced. How to crash: $ gcc/xg++ -Bgcc ~/dev/bugs/gcc-14-i686-ICE/tree-ssa-loop-niter.cc.cc -O2 -m32 --verbose Or: $ gcc/cc1plus -quiet -imultilib . -iprefix /tmp/gb/gcc/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/ -isystem gcc/include -isystem gcc/include-fixed -D_GNU_SOURCE /home/slyfox/dev/bugs/gcc-14-i686-ICE/tree-ssa-loop-niter.cc.cc -quiet -dumpdir a- -dumpbase tree-ssa-loop-niter.cc.cc -dumpbase-ext .cc -m32 -mtune=generic -march=x86-64 -O2 -version -o /run/user/1000/ccgZ63HD.s GNU C++17 (GCC) version 14.0.0 20230916 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 14.0.0 20230916 (experimental), GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 7c2c55b6bcbe18476b6d2c66d34ac4cc Segmentation fault (core dumped) Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0150a239 in get_nonzero_bits (name=0x7fffe8c02240) at /home/slyfox/dev/git/gcc/gcc/tree-ssanames.cc:494 494 unsigned int precision = element_precision (TREE_TYPE (name)); (gdb) bt #0 0x0150a239 in get_nonzero_bits (name=0x7fffe8c02240) at /home/slyfox/dev/git/gcc/gcc/tree-ssanames.cc:494 #1 0x0150ad4c in get_nonzero_bits (name=) at /home/slyfox/dev/git/gcc/gcc/tree-ssanames.cc:489 #2 0x00f04105 in tree_nonzero_bits (t=t@entry=0x7fffe8c02240) at /home/slyfox/dev/git/gcc/gcc/fold-const.cc:16792 #3 0x021de3ce in gimple_zero_one_valued_p (t=0x7fffe8c02240, valueize=valueize@entry=0x14a18c0 ) at gimple-match-3.cc:19 #4 0x021de537 in gimple_zero_one_valued_p (t=0x7fffe8c02090, valueize=valueize@entry=0x14a18c0 ) at gimple-match-3.cc:70 #5 0x021de537 in gimple_zero_one_valued_p (t=0x7fffe8c02240, valueize=valueize@entry=0x14a18c0 ) at gimple-match-3.cc:70 #6 0x021de537 in gimple_zero_one_valued_p (t=0x7fffe8c02090, valueize=valueize@entry=0x14a18c0 ) at gimple-match-3.cc:70 ...
[Bug tree-optimization/52345] Missed optimization dealing with bools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52345
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #5 from Andrew Pinski ---
// (a | zero_one) != 0 -> a!=0 | zero_one
(simplify
(ne (bit_ior:c @1 zero_one_value_p@2) integer_zerop@3)
(bit_ior (convert @1) (ne @2 @3)))
// (a & zero_one) != 0 -> a==0 & (zero_one^1)
(simplify
(eq (bit_and:c @1 zero_one_value_p@2) integer_zerop@3)
(bit_and
(convert (bit_xor @1 { build_one_cst (TREE_TYPE (@1)); } ))
(ne @2 @3)))
Similar to:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630651.html
[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/630651.html --- Comment #11 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630651.html
[Bug tree-optimization/111431] a & (a == 0) is not optimized to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111431 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/630656.html Keywords||patch --- Comment #6 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630656.html
[Bug driver/86030] specs file processing does not create response files for input directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030 --- Comment #17 from John Soo --- Created attachment 55910 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55910=edit libiberty, Unix: pass argv over ARG_MAX through an @file This does not handle environ being too large, but it is an adaptation of the argv fix in pex-win32.c.
[Bug ada/111434] New: Infinite loop with limited withs?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111434 Bug ID: 111434 Summary: Infinite loop with limited withs? Product: gcc Version: 13.1.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 55909 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55909=edit Full source code reproducer. Compiling source codes with multiple limited withs probably leads to an infinite loop: % gcc -c -gnatv pyside6-qtcore.adb GNAT 13.1.0 Copyright 1992-2023, Free Software Foundation, Inc. ^C When commenting one or several withs the compiler finish. HTH, Pascal. Full source codes in attached archive file.
[Bug ada/111433] New: Erroneous message "error: null exclusion for "O" does not match"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111433 Bug ID: 111433 Summary: Erroneous message "error: null exclusion for "O" does not match" Product: gcc Version: 13.1.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 55908 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55908=edit Archive of reproducer and full error message. When compiling the procedure body, I got: 8.procedure Clear (O : access TJavaMeth) is | >>> error: not fully conformant with declaration at objsrc.ads:25 >>> error: null exclusion for "O" does not match whereas procedure spec is: 25.procedure Clear (O : access TJavaMeth); However, the declarations spec and body are identical. What could be wrong? I got this error when I add: 20.procedure Append (O : access TJavaClass; M : PJavaMeth); and the incomplete type: 14.type TJavaMeth; 15.type PJavaMeth is access TJavaMeth; HTH, Pascal. See full source and full error message in attached zip.
[Bug middle-end/111391] RISC-V Vector: ICE in lra_split_hard_reg_for during reload pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111391 --- Comment #1 from CVS Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:86451305d8b2a25e7c6ea6c2f1ee69c419cba3ef commit r14-4077-g86451305d8b2a25e7c6ea6c2f1ee69c419cba3ef Author: Juzhe-Zhong Date: Thu Sep 14 18:49:52 2023 +0800 RISC-V: Expand VLS mode to scalar mode move[PR111391] This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111391 PR target/111391 gcc/ChangeLog: * config/riscv/autovec.md (@vec_extract): Remove @. (vec_extract): Ditto. * config/riscv/riscv-vsetvl.cc (emit_vsetvl_insn): Fix bug. (pass_vsetvl::local_eliminate_vsetvl_insn): Fix bug. * config/riscv/riscv.cc (riscv_legitimize_move): Expand VLS mode to scalar mode move. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/partial/slp-9.c: Adapt test. * gcc.target/riscv/rvv/autovec/pr111391-1.c: New test. * gcc.target/riscv/rvv/autovec/pr111391-2.c: New test.
[Bug target/111425] ia64: ICE in net/ipv4/fib_semantics.c:1621:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425 --- Comment #4 from Frank Scheiner --- (In reply to Richard Biener from comment #3) Hi Richard, in case you wanted me to test this reduced test case, I ran it through as if it was the file in question. I needed to remove `-Werror=strict-prototypes` and `-Werror=return-type` from the command line. It does not reproduce the problem, though: ``` # ia64-linux-gcc -v -Wp,-MMD,net/ipv4/.fib_semantics.o.d -nostdinc -I./arch/ia64/include -I./arch/ia64/include/generated -I./include -I./arch/ia64/include/uapi -I./arch/ia64/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -DHAVE_WORKING_TEXT_ALIGN -DHAVE_MODEL_SMALL_ATTRIBUTE -DHAVE_SERIALIZE_DIRECTIVE -fmacro-prefix-map=./= -std=gnu11 -fshort-wchar -funsigned-char -fno-common -fno-PIE -fno-strict-aliasing -pipe -ffixed-r13 -mfixed-range=f12-f15,f32-f127 -frename-registers -fno-optimize-sibling-calls -fno-delete-null-pointer-checks -O2 -fno-allow-store-data-races -fno-stack-protector -fomit-frame-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection -falign-functions=32 -fstrict-flex-arrays=3 -fno-strict-overflow -fno-stack-check -fconserve-stack -Wall -Wundef -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -Wno-trigraphs -Wno-frame-address -Wno-address-of-packed-member -Wframe-larger-than=2048 -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-dangling-pointer -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-array-bounds -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wenum-conversion -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-restrict -Wno-packed-not-aligned -Wno-format-overflow -Wno-format-truncation -Wno-stringop-overflow -Wno-stringop-truncation -Wno-missing-field-initializers -Wno-type-limits -Wno-shift-negative-value -Wno-maybe-uninitialized -Wno-sign-compare -g -mconstant-gp -DKBUILD_MODFILE='"net/ipv4/fib_semantics"' -DKBUILD_BASENAME='"fib_semantics"' -DKBUILD_MODNAME='"fib_semantics"' -D__KBUILD_MODNAME=kmod_fib_semantics -c -o net/ipv4/fib_semantics.o net/ipv4/fib_semantics.c Using built-in specs. COLLECT_GCC=ia64-linux-gcc Target: ia64-linux Configured with: /home/arnd/git/gcc/configure --host=x86_64-linux-gnu --build=aarch64-linux --target=ia64-linux --enable-targets=all --prefix=/home/arnd/cross/x86_64/gcc-13.2.0-nolibc/ia64-linux --enable-languages=c --without-headers --disable-bootstrap --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --disable-libquadmath --disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release --with-static-standard-libraries --with-system-libunwind Thread model: single Supported LTO compression algorithms: zlib zstd gcc version 13.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-nostdinc' '-I' './arch/ia64/include' '-I' './arch/ia64/include/generated' '-I' './include' '-I' './arch/ia64/include/uapi' '-I' './arch/ia64/include/generated/uapi' '-I' './include/uapi' '-I' './include/generated/uapi' '-include' './include/linux/compiler-version.h' '-include' './include/linux/kconfig.h' '-include' './include/linux/compiler_types.h' '-D' '__KERNEL__' '-D' 'HAVE_WORKING_TEXT_ALIGN' '-D' 'HAVE_MODEL_SMALL_ATTRIBUTE' '-D' 'HAVE_SERIALIZE_DIRECTIVE' '-fmacro-prefix-map=./=' '-std=gnu11' '-fshort-wchar' '-funsigned-char' '-fno-common' '-fno-PIE' '-fno-strict-aliasing' '-pipe' '-ffixed-r13' '-mfixed-range=f12-f15,f32-f127' '-frename-registers' '-fno-optimize-sibling-calls' '-fno-delete-null-pointer-checks' '-O2' '-fno-allow-store-data-races' '-fno-stack-protector' '-fomit-frame-pointer' '-ftrivial-auto-var-init=zero' '-fno-stack-clash-protection' '-falign-functions=32' '-fstrict-flex-arrays=3' '-fno-strict-overflow' '-fstack-check=no' '-fconserve-stack' '-Wall' '-Wundef' '-Werror=implicit-function-declaration' '-Werror=implicit-int' '-Wno-format-security' '-Wno-trigraphs' '-Wno-frame-address' '-Wno-address-of-packed-member' '-Wframe-larger-than=2048' '-Wno-main' '-Wunused-const-variable=0' '-Wdangling-pointer=0' '-Wvla' '-Wno-pointer-sign' '-Wcast-function-type' '-Warray-bounds=0' '-Walloc-size-larger-than=18446744073709551615EiB' '-Wimplicit-fallthrough=5' '-Werror=date-time' '-Werror=incompatible-pointer-types' '-Werror=designated-init' '-Wenum-conversion' '-Wno-unused-but-set-variable' '-Wunused-const-variable=0' '-Wno-restrict' '-Wno-packed-not-aligned' '-Wformat-overflow=0' '-Wformat-truncation=0' '-Wstringop-overflow=0' '-Wno-stringop-truncation' '-Wno-missing-field-initializers' '-Wno-type-limits' '-Wno-shift-negative-value' '-Wno-maybe-uninitialized' '-Wno-sign-compare' '-g' '-mconstant-gp' '-D' 'KBUILD_MODFILE="net/ipv4/fib_semantics"' '-D' 'KBUILD_BASENAME="fib_semantics"'
[Bug tree-optimization/110941] [14 Regression] Dead Code Elimination Regression at -O3 since r14-2379-gc496d15954c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110941 --- Comment #2 from Andrew Pinski --- GCC 13: Global Exported: _6 = [irange] unsigned int [0, 24] NONZERO 0x1e trunk: Global Exported: _6 = [irange] unsigned int [0, 24][+INF, +INF] MASK 0x1c VALUE 0x0 And then: Folding predicate _6 > 24 to 0 does not happen. But what is interesting is with https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629128.html , We get: ``` Simplified relational if (_6 > 24) into if (_6 == 4294967295) Folded into: if (_6 == 4294967295) ``` And then during cfgcleanup the match pattern: /* X == C (or X & Z == Y | C) is impossible if ~nonzero(X) & C != 0. */ Hits which is totally funny because that means the range and nonzero information are out of sync ...
[Bug tree-optimization/95408] Failure to optimize bitwise and with negated conditional using the same operand to conditional with decremented operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95408 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/630651.html Keywords||patch --- Comment #3 from Andrew Pinski --- I was looking for this one when I wrote https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630651.html .
[Bug tree-optimization/110502] [14 Regression] Dead Code Elimination Regression at -Os since r14-1656-g55fcaa9a8bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110502 --- Comment #3 from Andrew Pinski --- Note LIM2 has way different IR selection which is kinda interesting since there are no stores that happened in the bbs that were removed: if (_2 != 0) goto ; [75.00%] else goto ; [25.00%] [local count: 6515660663]: iftmp.8_23 = s.5_14 + -3; [local count: 8687547565]: # iftmp.8_24 = PHI
