[Bug target/101469] wrong code with "-O2 -fPIE" for SH

[olegendo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469

--- Comment #4 from Oleg Endo  ---
(In reply to Rin Okuyama from comment #3)
> Thank you very much for your analysis!
> 
> If that peephole is removed, GCC 10.3 generates working codes.
> 
> NetBSD/shle built by this compiler works fine as far as I can see.
> I'm carrying out full regression tests of NetBSD on this system.
> (It takes about a day to finish.)
> 
> Is there a better fix than mechanically removing that peephole?

Thanks for reporting and analyzing this issue.

I was suspecting that to be a broken peephole pattern.  Of course it's better
to fix the broken pattern instead of deleting it completely.

I'll try to come up with a patch during this week.

[Bug target/101469] wrong code with "-O2 -fPIE" for SH

[rin at NetBSD dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469

--- Comment #3 from Rin Okuyama  ---
Thank you very much for your analysis!

If that peephole is removed, GCC 10.3 generates working codes.

NetBSD/shle built by this compiler works fine as far as I can see.
I'm carrying out full regression tests of NetBSD on this system.
(It takes about a day to finish.)

Is there a better fix than mechanically removing that peephole?

Thanks,
rin

[Bug bootstrap/45372] warning coverage.c assigns -1 to unsigned, suggest -1u

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45372

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |4.7.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Pinski  ---
Warnings during the first stage will not always be correct.


Anyways this has been fixed since r0-108388 which changes the code a lot and
removed the assignment.
So all fixed for GCC 4.7.0.

[Bug tree-optimization/33027] missed optimisation could pull branch out of loop

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33027

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-19
   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
Confirmed.

-O2 produces much better code than -O3 or -O3 -fno-tree-vectorize.
And we even optimize a slightly different case at -O2 where 1 is replaced with
any other value:
unsigned int fn(unsigned int n, unsigned int dmax) throw()
{
  for (unsigned int d = 0; d < dmax; ++d) {
n += d?d:55;
  }
  return n;
}

Note GCC seems to produce better code than LLVM for both cases even. 
Especially the -O3 with constant of 1, on aarch64, GCC produces an umax
instruction while LLVM produces a cmeq/bsl pair :).

[Bug tree-optimization/32553] missed optimization to eliminate duplicate expressions

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32553

--- Comment #2 from Andrew Pinski  ---
Reassociation is not done:
  _3 = p_14(D) + _2;
  _17 = g ();
  *_3 = _17;
  _5 = _2 + 8;
  _6 = p_14(D) + _5;
  _20 = g ();
  *_6 = _20;
  _8 = _2 + 40;
  _9 = p_14(D) + _8;
  _23 = g ();
  *_9 = _23;
  _11 = _2 + 400;
  _12 = p_14(D) + _11;
  _26 = g ();
  *_12 = _26;

[Bug tree-optimization/90460] Inefficient vector construction from pieces

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90460

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-19
   Keywords||missed-optimization
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/89491] Inline jump tables

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89491

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-19
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Keywords||missed-optimization

--- Comment #6 from Andrew Pinski  ---
The big question is how useful is this in real code?
ICC does it, then there must have been a benchmark where this improves but I
don't know which one.

Also it looks like ICC does:
int f(int x)
{
  const p *t = arr[x];
  if (t == square)
return square(1);
  else
return add(1);
}

[Bug tree-optimization/100457] [meta bug] Enabling O2 vectorization in GCC 12

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100457

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||meta-bug,
   ||missed-optimization
   Last reconfirmed||2021-07-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement

[Bug tree-optimization/98026] optimization dependant on condition order

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98026

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Ever confirmed|0   |1
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-19

--- Comment #2 from Andrew Pinski  ---
Confirmed. I Noticed that LLVM does not even optimize f3.

[Bug tree-optimization/83073] Range for VR_VARYING | [1, 1]

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug tree-optimization/83073] Range for VR_VARYING | [1, 1]

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073

--- Comment #5 from Andrew Pinski  ---
Take -O2 -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop:
int f(int x)
{
x = x|1;
return x & 1;
}

We should be able to figure this out in evrp but don't currently.

VRP can figure it out as it does a match and simplify for the statement.

[Bug tree-optimization/96195] aarch64: ICE during GIMPLE pass:vect

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96195

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED
   Keywords||ice-on-valid-code

--- Comment #3 from Andrew Pinski  ---
This was fixed in GCC 11, I can reproduce the ICE in GCC 10.2 though.

[Bug target/94617] Simple if condition not optimized

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94617

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |target
 Target||x86_64-linux-gnu

--- Comment #8 from Andrew Pinski  ---
Note only vanilla_bandpass produces the best code on aarch64:
cmp w0, w2
ccmpw2, w1, 0, le
cselx0, x3, x4, ge

[Bug tree-optimization/101501] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

[glisse at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101501

--- Comment #2 from Marc Glisse  ---
unsigned char a = 55;
int main() {
  unsigned char c;
d:
  c = a-- * 52;
  if (c)
goto d;
  __builtin_printf("%d\n", a);
}


outputs 40 at -O3 instead of 255, and already fails with gcc-8. Cunroll seems
confused about the number of iterations of this loop.

[Bug tree-optimization/32825] Reduction with nonzero start (arbitrary also) causes an extra add to happen

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32825

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2012-01-28 00:00:00 |2021-7-18

--- Comment #5 from Andrew Pinski  ---
Clang actually does one extra thing of having 2 variables to carry the add
through the loop, one is {e, 0, 0, 0}.

Also Power has been enhanced such that creating {e, 0, 0, 0} is not as
expensive any more either.

[Bug ipa/51506] Function cloning misses constant struct at -Os vs -O2

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51506

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |ipa
Summary|Function cloning misses |Function cloning misses
   |constant struct |constant struct at -Os vs
   ||-O2
 CC||marxin at gcc dot gnu.org
 Target||avr

--- Comment #3 from Andrew Pinski  ---
So this is done at -O2 already but not -Os.  I have not looked into why though.
Someone will need to look at the heurstics to figure out why.

Also it just does not happen on avr even.  There must be some heurstic changes
between most other targets and avr that causes this not to happen.

[Bug tree-optimization/89184] GCC does not simplify expressions involving shifts, bitwise operators and comparisons.

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89184

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

--- Comment #4 from Andrew Pinski  ---
Note clang does this optimization.

[Bug target/80874] gcc does not emit cmov for minmax

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80874

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
  Component|tree-optimization   |target
   Keywords||missed-optimization

--- Comment #3 from Andrew Pinski  ---
aarch64 produces the cmov:
minmax1(int, int):
cmp w0, w1
cselw2, w0, w1, gt
cselw0, w1, w0, gt
orr x0, x0, x2, lsl 32
ret
minmax2(int, int):
cmp w0, w1
cselw2, w1, w0, le
cselw0, w0, w1, le
orr x0, x0, x2, lsl 32
ret

Note minmax3 code is not correct itself returns a std::pair

[Bug other/33702] [meta-bug] GCC 4.4 pending patches

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33702
Bug 33702 depends on bug 34943, which changed state.

Bug 34943 Summary: -fno-strict-overflow fails to prevent use of signed overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34943

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/34943] -fno-strict-overflow fails to prevent use of signed overflow

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34943

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.7
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
The original testcase is wrong, it should have been:
v > 0x7fffu

With that fixed, it has been fixed since at least GCC 4.4.7, the earliest
version I can test.

[Bug tree-optimization/29710] gnat ICEs on -fprefetch-loop-arrays -O1.

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29710

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #8 from Andrew Pinski  ---
The original Ada issue was fixed with r0-101637 .
The java issue was fixed with r0-105374 but java support was removed anyways.

[Bug c++/67491] [meta-bug] concepts issues

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 90033, which changed state.

Bug 90033 Summary: [concepts] ICE segfault evaluating a requires clause that 
transitively depends on itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90033

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c++/90033] [concepts] ICE segfault evaluating a requires clause that transitively depends on itself

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90033

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |10.0
 Resolution|--- |FIXED

--- Comment #2 from Andrew Pinski  ---
I am going to close this as fixed for GCC 10. GCC 9.5 I think is the last GCC
9.x compiler and I really doubt it will be fixed for that.

[Bug c++/81971] [concepts] internal compiler error: in check_noexcept_r, at cp/except.c:1028

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81971

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92746

--- Comment #2 from Andrew Pinski  ---
Fixed for GCC 10.1.

I suspect it was fixed by the patch which fixed PR 92746.

[Bug c++/89080] ICE with immediately invoked constexpr lambda

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89080

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0
URL|https://godbolt.org/z/1IOgp |
   |U   |

--- Comment #6 from Andrew Pinski  ---
It looks like it is working in GCC 9.1 even.

Note to build on the trunk I had to add:
#include 

Otherwise some types are undefined.

[Bug c++/84162] Internal compiler error: in tsubst, at cp/pt.c:13617 / SEGFAULT

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84162

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79549
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Andrew Pinski  ---
GCC 7 is no longer supported and it was fixed in GCC 8 so closing as fixed.

[Bug c++/83040] __attribute__((always_inline)) causes internal_compiler_error (segmentation fault) (with recursive meta-template programming function)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83040

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #2 from Andrew Pinski  ---
The limits on -ftemplate-depth= is designed explicitly do you don't run into
these issues.  I am just going to mark this as won't fix.

Most likely it is a stack overflow even.

[Bug c++/67491] [meta-bug] concepts issues

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 82833, which changed state.

Bug 82833 Summary: [concepts] Out-of-line definition of nested class template 
errors with constraint (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82833

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c++/82833] [concepts] Out-of-line definition of nested class template errors with constraint (ICE)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82833

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |10.3
 Status|NEW |RESOLVED

--- Comment #1 from Andrew Pinski  ---
This was fixed in GCC 10.3 (note 10.2 also rejects it).

I suspect it was fixed with r11-3296 (10 version: r10-9634 )

[Bug c++/79711] [concepts] ICE in instantiate_decl, at cp/pt.c:22474

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79711

--- Comment #1 from Andrew Pinski  ---
On the trunk we get:
t65.cc:4:17: error: lvalue required as unary ‘&’ operand
4 | static_assert(()());
  | ^~

[Bug c++/95822] [coroutines] compiler internal error with local object with noexcept false destructor

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95822

Andrew Pinski  changed:

   What|Removed |Added

 CC||familiebaumanns at gmail dot 
com

--- Comment #7 from Andrew Pinski  ---
*** Bug 96141 has been marked as a duplicate of this bug. ***

[Bug c++/96141] ICE in gimplify: Coroutine and noexcept(false) destructor cause: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2817

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96141

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Pinski  ---
This was fixed on the trunk and for GCC 10.3 with PR 95822. So marking this as
a dup.

Note I had to change one thing slightly:
constexpr COROUTINE_IMPL_NS::suspend_always
final_suspend() const noexcept(true) { return {}; }


Notice the noexcept(true) there.

*** This bug has been marked as a duplicate of bug 95822 ***

[Bug c++/85885] internal compiler error, gimplify.c related

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85885

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #3 from Andrew Pinski  ---
No preprocessed source in over 2 years so closing as invalid.

Note if you can still reproduce this, the internal compiler error even had this
line:
Preprocessed source stored into /tmp/ccHdef5s.out file, please attach this to
your bugreport.


Which you should have attached here.

[Bug testsuite/100422] [12 regression] g++.dg/gomp/clause-3.C fails after r12-438

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100422

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:de8945a3665ab8ec0ad62afd39193772201fc2d4

commit r11-8775-gde8945a3665ab8ec0ad62afd39193772201fc2d4
Author: Tobias Burnus 
Date:   Wed May 5 08:50:15 2021 +0200

g++.dg/gomp/clause-3.C: Fix - missing in r12-438-g1580fc7 [PR100422]

gcc/testsuite/
PR testsuite/100422
* g++.dg/gomp/clause-3.C: Use 'reduction(&:..)' instead of
'...(&&:..)'.

(cherry picked from commit af4e4d35f0b84d7c2f57a7b682a09116e9911142)

[Bug middle-end/94366] OpenMP Parallel Reduction with "&&" operator does not compute correct result

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94366

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:9119f51f40226526bfbb79dec07ef39ec8d87466

commit r11-8774-g9119f51f40226526bfbb79dec07ef39ec8d87466
Author: Jakub Jelinek 
Date:   Thu Jul 1 08:55:49 2021 +0200

openmp - Fix up && and || reductions [PR94366]

As the testcase shows, the special treatment of && and || reduction
combiners
where we expand them as omp_out = (omp_out != 0) && (omp_in != 0) (or with
||)
is not needed just for &&/|| on floating point or complex types, but for
all
&&/|| reductions - when expanded as omp_out = omp_out && omp_in (not in C
but
GENERIC) it is actually gimplified into NOP_EXPRs to bool from both
operands,
which turns non-zero values multiple of 2 into 0 rather than 1.

This patch just treats all &&/|| the same and furthermore uses bool type
instead of int for the comparisons.

2021-07-01  Jakub Jelinek  

PR middle-end/94366
gcc/
* omp-low.c (lower_rec_input_clauses): Rename is_fp_and_or to
is_truth_op, set it for TRUTH_*IF_EXPR regardless of new_var's
type,
use boolean_type_node instead of integer_type_node as NE_EXPR type.
(lower_reduction_clauses): Likewise.
libgomp/
* testsuite/libgomp.c-c++-common/pr94366.c: New test.

(cherry picked from commit 91c771ec8a3b649765de3e0a7b04cf946c6649ef)

[Bug c++/101443] [9/10/11 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1519

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443

--- Comment #9 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:2f49122aec76fdd40a7157f66df9c058d635efe6

commit r11-8772-g2f49122aec76fdd40a7157f66df9c058d635efe6
Author: Jakub Jelinek 
Date:   Thu Jul 15 18:53:20 2021 +0200

c++: Optimize away NULLPTR_TYPE comparisons [PR101443]

Comparisons of NULLPTR_TYPE operands cause all kinds of problems in the
middle-end and in fold-const.c, various optimizations assume that if they
see e.g. a non-equality comparison with one of the operands being
INTEGER_CST and it is not INTEGRAL_TYPE_P (which has TYPE_{MIN,MAX}_VALUE),
they can build_int_cst (type, 1) to find a successor.

The following patch fixes it by making sure they don't appear in the IL,
optimize them away at cp_fold time as all can be folded.

Though, I've just noticed that clang++ rejects the non-equality comparisons
instead, foo () > 0 with
invalid operands to binary expression ('decltype(nullptr)' (aka
'nullptr_t') and 'int')
and foo () > nullptr with
invalid operands to binary expression ('decltype(nullptr)' (aka
'nullptr_t') and 'nullptr_t')

Shall we reject those too, in addition or instead of parts of this patch?
If so, wouldn't this patch be still useful for backports, I bet we don't
want to start reject it on the release branches when we used to accept it.

2021-07-15  Jakub Jelinek  

PR c++/101443
* cp-gimplify.c (cp_fold): For comparisons with NULLPTR_TYPE
operands, fold them right away to true or false.

* g++.dg/cpp0x/nullptr46.C: New test.

(cherry picked from commit 7094a69bd62a14dfa311eaa2fea468f221c7c9f3)

[Bug go/101407] non-determinism in -fdump-go-spec

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101407

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:31b76a815fc177dd579adc03b671ba9a8846ae6c

commit r11-8771-g31b76a815fc177dd579adc03b671ba9a8846ae6c
Author: Jakub Jelinek 
Date:   Wed Jul 14 10:22:50 2021 +0200

godump: Fix -fdump-go-spec= reproduceability issue [PR101407]

pot_dummy_types is a hash_set from whose traversal the code prints some
type
lines.  hash_set normally uses default_hash_traits which for pointer types
(the hash set hashes const char *) uses pointer_hash which hashes the
addresses of the pointers except of the least significant 3 bits.
With address space randomization, that results in non-determinism in the
-fdump-go-specs= generated file, each invocation can have different order
of
the lines emitted from pot_dummy_types traversal.

This patch fixes it by hashing the string contents instead to make the
hashes reproduceable.

2021-07-14  Jakub Jelinek  

PR go/101407
* godump.c (godump_str_hash): New type.
(godump_container::pot_dummy_types): Use string_hash instead of
ptr_hash in the hash_set.

(cherry picked from commit 3be762c2ed79e36b9c8faaea2be04725c967a34e)

[Bug target/80377] gcc: error: unrecognized command line option ‘-mavx512’; did you mean ‘-mavx512 ’?

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #8 from Andrew Pinski  ---
Works for me also so closing as works for me since nobody seems to be able to
reproduce the failure.

I don't see how it would be "-mavx512 " either.  Notice the space.  I wonder if
the console is doing something wrong due to the UTF8 quotes.

[Bug debug/101266] ICE with -g: in loc_list_from_tree_1, at dwarf2out.c:19421

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101266

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:135680bdce4577208daf0507089ac932abdbf5f9

commit r11-8769-g135680bdce4577208daf0507089ac932abdbf5f9
Author: Jakub Jelinek 
Date:   Thu Jul 1 09:45:02 2021 +0200

dwarf2out: Handle COMPOUND_LITERAL_EXPR in loc_list_from_tree_1 [PR101266]

In this case dwarf2out_decl is called from the FEs with GENERIC but not
yet gimplified expressions in it.

As loc_list_from_tree_1 has an exhaustive list of tree codes it wants to
handle and for checking asserts no other codes makes it in, we should
handle even GENERIC trees that shouldn't be valid in GIMPLE.

The following patch handles COMPOUND_LITERAL_EXPR by hnadling it like the
underlying VAR_DECL temporary.

Verified the emitted DWARF is correct (but unoptimized, we emit
DW_OP_lit1 DW_OP_lit1 DW_OP_minus for the upper bound).

2021-07-01  Jakub Jelinek  

PR debug/101266
* dwarf2out.c (loc_list_from_tree_1): Handle COMPOUND_LITERAL_EXPR.

* gcc.dg/pr101266.c: New test.

(cherry picked from commit b0ab968999c9af88d45acf552ca673ef3960306a)

[Bug c++/101210] [9/10/11 regression] spurious "reference binding to misaligned address" ubsan error for integer comparison

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101210

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:86a9718e162b08cd4263402bcbf0d17a557bfcf1

commit r11-8768-g86a9718e162b08cd4263402bcbf0d17a557bfcf1
Author: Jakub Jelinek 
Date:   Tue Jun 29 11:24:38 2021 +0200

match.pd: Avoid (intptr_t)x eq/ne CST to x eq/ne (typeof x) CST opt in
GENERIC when sanitizing [PR101210]

When we have (intptr_t) x == cst where x has REFERENCE_TYPE, this
optimization creates x == cst out of it where cst has REFERENCE_TYPE.
If it is done in GENERIC folding, it can results in ubsan failures
where the INTEGER_CST with REFERENCE_TYPE is instrumented.

Fixed by deferring it to GIMPLE folding in this case.

2021-06-29  Jakub Jelinek  

PR c++/101210
* match.pd ((intptr_t)x eq/ne CST to x eq/ne (typeof x) CST): Don't
perform the optimization in GENERIC when sanitizing and x has a
reference type.

* g++.dg/ubsan/pr101210.C: New test.

(cherry picked from commit 53fd7544aff6d0a18869017cb9bb921a7f5dcd04)

[Bug c/101176] valgrind error for c-c++-common/builtin-has-attribute.c

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101176

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:72ff4a04bb33795fe5b6d5863a66cac5293559b6

commit r11-8767-g72ff4a04bb33795fe5b6d5863a66cac5293559b6
Author: Jakub Jelinek 
Date:   Thu Jun 24 15:58:02 2021 +0200

c: Fix up c_parser_has_attribute_expression [PR101176]

This function keeps src_range member of the result uninitialized, which at
least under valgrind can show up later when those uninitialized
location_t's
can make it into the IL or location_t hash tables.

2021-06-24  Jakub Jelinek  

PR c/101176
* c-parser.c (c_parser_has_attribute_expression): Set source range
for
the result.

(cherry picked from commit 178fb8df9315f2f8f45b7fe5faf11a9c2912cc28)

[Bug c/101171] [10/11 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:3006

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101171

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:6c9eaa1de2c4d600c236bc2d95be66dbc3a27b2e

commit r11-8766-g6c9eaa1de2c4d600c236bc2d95be66dbc3a27b2e
Author: Jakub Jelinek 
Date:   Thu Jun 24 15:55:28 2021 +0200

c: Fix C cast error-recovery [PR101171]

The following testcase ICEs during error-recovery, as build_c_cast calls
note_integer_operands on error_mark_node and that wraps it into
C_MAYBE_CONST_EXPR which is unexpected and causes ICE later on.
Seems most other callers of note_integer_operands check early if something
is error_mark_node and return before calling note_integer_operands on it.

The following patch fixes it by not calling on error_mark_node, another
possibility would be to handle error_mark_node in note_integer_operands and
just return it.

2021-06-24  Jakub Jelinek  

PR c/101171
* c-typeck.c (build_c_cast): Don't call note_integer_operands on
error_mark_node.

* gcc.dg/pr101171.c: New test.

(cherry picked from commit fdc5522fb04b4a820b28c4d1f16f54897f5978de)

[Bug middle-end/101172] [11 Regression] ICE Segmentation fault

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101172

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:2b99794806d83e47249fd7c05bf521caee1fdcd4

commit r11-8765-g2b99794806d83e47249fd7c05bf521caee1fdcd4
Author: Jakub Jelinek 
Date:   Thu Jun 24 12:22:14 2021 +0200

stor-layout: Avoid DECL_BIT_FIELD_REPRESENTATIVE with NULL TREE_TYPE
[PR101172]

finish_bitfield_representative has an early out if the field after a
bitfield has error_mark_node type, but that early out leads to TREE_TYPE
of the DECL_BIT_FIELD_REPRESENTATIVE being NULL, which breaks assumptions
on code that uses the DECL_BIT_FIELD_REPRESENTATIVE during error-recovery.

The following patch instead sets TREE_TYPE of the representative to
error_mark_node, something the users can deal with better.  At this point
the representative can be set as DECL_BIT_FIELD_REPRESENTATIVE for multiple
bitfields, so making sure that we clear the DECL_BIT_FIELD_REPRESENTATIVE
instead would be harder (but doable, e.g. with the error_mark_node
TREE_TYPE
set by this patch set some flag in the caller and if the flag is there,
walk
all the fields once again and clear all DECL_BIT_FIELD_REPRESENTATIVE that
have error_mark_node TREE_TYPE).

2021-06-24  Jakub Jelinek  

PR middle-end/101172
* stor-layout.c (finish_bitfield_representative): If nextf has
error_mark_node type, set repr type to error_mark_node too.

* gcc.dg/pr101172.c: New test.

(cherry picked from commit 65371066d8967560e3508af4a804e0ddb90acee7)

[Bug c++/79746] [7 Regression] Confusing -Wunused-but-set-parameter warning with virtual inheritance

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79746

Andrew Pinski  changed:

   What|Removed |Added

 CC||petschy at gmail dot com

--- Comment #7 from Andrew Pinski  ---
*** Bug 79172 has been marked as a duplicate of this bug. ***

[Bug c++/79172] -Wunused-but-set-parameter gone nuts

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79172

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Andrew Pinski  ---
This is a dup of bug 79746 which was fixed in the end.

*** This bug has been marked as a duplicate of bug 79746 ***

[Bug preprocessor/66932] Preprocessor includes wrong header file

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66932

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Andrew Pinski  ---
The problem is you have -I. and C_INCLUDE_PATH including the cwd ".".


from the documentation:
https://gcc.gnu.org/onlinedocs/cpp/Invocation.html#Invocation:
If a standard system include directory, or a directory specified with -isystem,
is also specified with -I, the -I option is ignored. 

 CUT -

C_INCLUDE_PATH is considered similar to -isystem but after processing the
commandline options.

So this is not a bug really except just a minor wording there might improve
dealing with the envs.

[Bug tree-optimization/101501] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101501

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.2
Summary|wrong code at -O3 on|[11/12 Regression] wrong
   |x86_64-linux-gnu|code at -O3 on
   ||x86_64-linux-gnu
   Keywords||wrong-code

[Bug tree-optimization/101501] wrong code at -O3 on x86_64-linux-gnu

[qrzhang at gatech dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101501

--- Comment #1 from Qirun Zhang  ---
My bisection points to g:287522613d661b4c5ba8403b051eb470c1674cba

[Bug tree-optimization/101501] New: wrong code at -O3 on x86_64-linux-gnu

[qrzhang at gatech dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101501

Bug ID: 101501
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

It appears to be a recent regression. Gcc-10 works fine.

$ gcc-trunk -v
gcc version 12.0.0 20210718 (experimental) [master revision
0103d18dfc9:a1cef02c5e3:853921378bfa149353b4e1c7dde5c02f80072ad7] (GCC)


$ gcc-trunk abc.c ; ./a.out
-1

$ gcc-trunk -O3 abc.c ; ./a.out
40


$ cat abc.c
char a = 55;
int main() {
  int b;
  char c;
d:
  c = a-- * 52;
  b = 3L * c;
  if (b)
goto d;
  printf("%d\n", a);
}

[Bug c++/94939] [9.2.1] invalid code generation in ternary op with static class member (undefined behaviour nearby?)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94939

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Andrew Pinski  ---
Invalid as this is aliasing violation.

[Bug c++/94939] [9.2.1] invalid code generation in ternary op with static class member (undefined behaviour nearby?)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94939

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Andrew Pinski  ---
t567.cc: In function ‘OldDerived callee(bool)’:
t567.cc:187:14: warning:
‘a.NewDerived::.type_safe::strong_typedef::value_.New::.Old::storage’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 return b ? a.toOld() : OldDerived::magic;
~~^~~~
t567.cc: In function ‘void caller_magic(bool)’:
t567.cc:187:14: warning: ‘a’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
 return b ? a.toOld() : OldDerived::magic;
~~^~~~


  MEM[(struct  &)] ={v} {CLOBBER};
  MEM[(struct strong_typedef *)] = 11;
  if (b_5(D) != 0)
goto ; [0.00%]
  else
goto ; [0.00%]

   [100.00%]:
  _7 = [(const struct New *)].D.43195;
  _13 = _7;
  iftmp.0_8 = _13;
  goto ; [0.00%]

   [0.00%]:
  iftmp.0_6 = 

   [0.00%]:
  # iftmp.0_1 = PHI 
  D.48802 = *iftmp.0_1;
  a ={v} {CLOBBER};


Yes I think there is some aliasing issues in fact using -fno-strict-aliasing
"fixes" the warning and even gives what you expect.


And yes the code is undefined and violates aliasing.

NewDerived has no field or inheritance from OldDerived so mixing those together
like you with the casts is what causes the aliasing violations.

[Bug debug/95360] inconsistent behaviors at -O0

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |MOVED

--- Comment #8 from Andrew Pinski  ---
This is a gdb issue so closing as moved.

[Bug c++/95948] memmove error

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95948

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
No feedback in over one year and most likely you need
-fno-tree-loop-distribution if you are hand coding memmove yourself.

[Bug middle-end/77682] GCC crashes while compiling OpenAL-Soft 1.17.2

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77682

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Andrew Pinski  ---
compiler error: Segmentation fault
 int m = 2 * (int)floor(a);
 ^
gcc: internal compiler error: Segmentation fault (program cc1)


I am 99% sure this is actually MPFR/GMP being miscompiled or configured
incorrectly.  So this is not a GCC bug directly.

[Bug libstdc++/78409] Segfault in classify_object_over_fdes when throwing an exception

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78409

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |libstdc++
 Status|WAITING |NEW
   See Also||https://github.com/void-lin
   ||ux/void-packages/issues/255
   ||35
   Keywords||wrong-code

--- Comment #3 from Andrew Pinski  ---
My bet is the same problem as what is reported here:

https://github.com/void-linux/void-packages/issues/25535

And is fixed with:
https://github.com/void-linux/void-packages/pull/25605/commits/22e78dc1b001bf26908e1d91ab81d706fe035b60

It looks like the order is still broken too.

[Bug target/78784] CRITIC BUG: Create a trash code using trash values of registers.

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78784

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Andrew Pinski  ---
No test that fails provided in over 4.5 years so closing as invalid.

[Bug sanitizer/62088] [GCC-5] Compilation failed to produce executable: torture with -fsanitize=address

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62088

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |WONTFIX

--- Comment #4 from Andrew Pinski  ---
Won't fix is more correct here rather than invalid.

[Bug sanitizer/62088] [GCC-5] Compilation failed to produce executable: torture with -fsanitize=address

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62088

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Yes without doing an install, only the asan/ubsan/tsan/hwasn testsuites are
setup to handle non-installed support of running with -fsanitize= .

I really doubt we want to move that logic to the normal part of the gcc
testsuite either.

[Bug c++/101500] New: gcc accepts the code with extra curly braces

[fchelnokov at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101500

Bug ID: 101500
   Summary: gcc accepts the code with extra curly braces
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The following ill-formed code is the illustration
```
struct A
{
A() {}
A( A&& ) = delete;
~A() {}
};

int main() {
const A a = {{A{}}}; //error line
}
```
https://gcc.godbolt.org/z/eq5WhTfz3

[Bug target/63435] Bad code with weak vs localalias on AIX

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435

Andrew Pinski  changed:

   What|Removed |Added

 CC||streibel.2003 at gmx dot net

--- Comment #7 from Andrew Pinski  ---
*** Bug 67950 has been marked as a duplicate of this bug. ***

[Bug c++/67950] AIX: Illegal instruction in accept()

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67950

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Andrew Pinski  ---
Just marked as a dup of bug 63435 as mentioned and it looks like it is only an
issue in GCC 4.9 and before.

*** This bug has been marked as a duplicate of bug 63435 ***

[Bug middle-end/62080] Suboptimal code generation with eigen library

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #9 from Andrew Pinski  ---
No feedback in over a year and no self-contained preprocessed source so there
is no way to reproduce this any more so closing as invalid.

[Bug libstdc++/101485] Calling std::equal with std::byte* does not use memcmp

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93059
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-18

[Bug tree-optimization/61051] Duplicated instructions in both conditional branches

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61051

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|10.0|7.0

--- Comment #4 from Andrew Pinski  ---
Rather since GCC 7.

[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-18
 Ever confirmed|0   |1

[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||10.3.0
   Keywords||wrong-code
  Known to fail||11.1.0, 12.0
Summary|Miscompiled code involving  |[11/12 Regression]
   |operator new|Miscompiled code involving
   ||operator new
   Target Milestone|--- |11.2
 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Started with r11-4745

Add fnspecs for C++ new and delete operators

gcc/ChangeLog:

* gimple.c (gimple_call_fnspec): Handle C++ new and delete.
* gimple.h (gimple_call_from_new_or_delete): Constify parameter.

gcc/testsuite/ChangeLog:

* g++.dg/ipa/devirt-24.C: Update template.

[Bug tree-optimization/61051] Duplicated instructions in both conditional branches

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61051

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |tree-optimization
 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0
   Keywords||missed-optimization

--- Comment #3 from Andrew Pinski  ---
Fixed on the trunk:
  x.0_4 = x;
  if (_3 != x.0_4)
goto ; [66.00%]
  else
goto ; [34.00%]

   [local count: 195204118]:

   [local count: 574129753]:
  # prephitmp_24 = PHI <1(3), 2(4)>
  r.1_5 = r;
  pretmp_26 = d;
  if (r.1_5 > 0)
goto ; [59.00%]
  else
goto ; [41.00%]

   [local count: 338736556]:
  f_18 = pretmp_26 + 1;

   [local count: 574129754]:
  # f_9 = PHI 

I think it has been fixed in since at least GCC 10 even.

[Bug ipa/59479] Inlining of static function bloats code size when Os

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59479

Andrew Pinski  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Component|tree-optimization   |ipa

--- Comment #3 from Andrew Pinski  ---
Is there a misunderstanding of what called once means?  Does it mean only
called from one other function rather than one time?

I see std is called three times from __sinit rather than once in that function.

[Bug libfortran/101255] FLUSH statement - error should be negative

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Component|fortran |libfortran
   Last reconfirmed||2021-07-18
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.  Changing component to libfortran.

In F2018 the IOSTAT= specifier is described in 12.11.5.

[Bug fortran/101348] [Coarray] ICE in gfc_get_nodesc_array_type, at fortran/trans-types.c:1697

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101348

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|ICE in  |[Coarray] ICE in
   |gfc_get_nodesc_array_type,  |gfc_get_nodesc_array_type,
   |at  |at
   |fortran/trans-types.c:1697  |fortran/trans-types.c:1697
   Last reconfirmed||2021-07-18
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Priority|P3  |P4

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

[Bug target/101492] -msse4 -mgeneral-regs-only doesn't work

[hjl.tools at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101492

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 12.

[Bug target/101495] Unnecessary vzeroupper

[hjl.tools at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101495

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 12.

[Bug tree-optimization/59377] VRP produces bogus warning with -Warray-bounds

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59377

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #4 from Andrew Pinski  ---
The testcase provided in comment #0 is correctly warning about array bounds as
I had explained.  The testcase is reduced way too much from the original code
and there is no feedback in getting the original testcase in over 7 years so
just closing as invalid.

[Bug jit/101491] [11 regression] /usr/local/include/libgccjit++.h conflicts between different GCC installations

[dimitry at andric dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491

--- Comment #4 from Dimitry Andric  ---
(In reply to Gerald Pfeifer from comment #3)
> (In reply to David Malcolm from comment #2)
> > I wonder why this changed recently; as Dimitry notes, this has been 
> > done the same since the initial merger of libgccjit into trunk.
> 
> I believe we are not looking at a regression in one of the FreeBSD ports
> nor on the gccjit side, just an issue that's been there "from day 1".
> 
> Dimitry, is this consistent with your experience?

Yes, it's only the FreeBSD gcc 11 and 12 ports that have these headers. But
indeed they have been provided by gcc's Makefiles since 2014.

[Bug bootstrap/58427] xgcc target compilation depends on installed libgcc_s.so

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58427

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|WAITING |RESOLVED

--- Comment #4 from Andrew Pinski  ---
No feedback in over 6 months assuming the binutils bug was the cause so closing
as moved.

[Bug target/101492] -msse4 -mgeneral-regs-only doesn't work

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101492

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:6ae8aac19cdbdbd96d90f86e4d8505fe121bdf06

commit r12-2387-g6ae8aac19cdbdbd96d90f86e4d8505fe121bdf06
Author: H.J. Lu 
Date:   Sat Jul 17 14:38:39 2021 -0700

x86: Enable the GPR only instructions for -mgeneral-regs-only

For -mgeneral-regs-only, enable the GPR only instructions which are
enabled implicitly by SSE ISAs unless they have been disabled explicitly.

gcc/

PR target/101492
* common/config/i386/i386-common.c (ix86_handle_option): For
-mgeneral-regs-only, enable the GPR only instructions which are
enabled implicitly by SSE ISAs unless they have been disabled
explicitly.

gcc/testsuite/

PR target/101492
* gcc.target/i386/pr101492-1.c: New test.
* gcc.target/i386/pr101492-2.c: Likewise.
* gcc.target/i386/pr101492-3.c: Likewise.
* gcc.target/i386/pr101492-4.c: Likewise.

[Bug fortran/101084] [10/11/12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1124

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101084

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:f527b8233498b40c8a2c616b82265f2e58aba42a

commit r12-2386-gf527b8233498b40c8a2c616b82265f2e58aba42a
Author: Harald Anlauf 
Date:   Sun Jul 18 21:35:53 2021 +0200

Fortran: reject FORMAT tag of unknown type.

gcc/fortran/ChangeLog:

PR fortran/101084
* io.c (resolve_tag_format): Extend FORMAT check to unknown type.

gcc/testsuite/ChangeLog:

PR fortran/101084
* gfortran.dg/fmt_nonchar_3.f90: New test.

[Bug target/101495] Unnecessary vzeroupper

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101495

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:5586e7e85de381f3df843091494889f8ad8e3e1f

commit r12-2385-g5586e7e85de381f3df843091494889f8ad8e3e1f
Author: H.J. Lu 
Date:   Sun Jul 18 06:12:29 2021 -0700

x86: Don't issue vzeroupper if callee returns AVX register

Don't issue vzeroupper before function call if callee returns AVX
register since callee must be compiled with AVX.

gcc/

PR target/101495
* config/i386/i386.c (ix86_check_avx_upper_stores): Moved before
ix86_avx_u128_mode_needed.
(ix86_avx_u128_mode_needed): Return AVX_U128_DIRTY if callee
returns AVX register.

gcc/testsuite/

PR target/101495
* gcc.target/i386/avx-vzeroupper-28.c: New test.

[Bug libstdc++/51785] gets not anymore declared

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #31 from Andrew Pinski  ---
I don't think there is any thing more to fix here.  gets works correctly as far
as I Know.

[Bug sanitizer/94076] libsanitizer fails with 64-bit time_t

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94076

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED
   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=45138

--- Comment #4 from Andrew Pinski  ---
Suspended is better here than waiting.

[Bug bootstrap/94761] host != target

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94761

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Andrew Pinski  ---
No feedback and not even what is going wrong.  So closing as works for me.

[Bug tree-optimization/101497] [12 Regression] ice in type, at value-range.h:221

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101497

David Binderman  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #4 from David Binderman  ---
Range seems to be [33255ad3ac14e395, c031ea2782a1873e],
so this looks like another one for Andrew Macleod.

[Bug target/101469] wrong code with "-O2 -fPIE" for SH

[uwe at netbsd dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469

--- Comment #2 from Valeriy E. Ushakov  ---
I don't have the latest gcc handy, but I see this bug already in an old netbsd
tree from about an year ago with gcc 8.4.0

As hgutch@n.o pointed out, this seems to be a problem with this peephole2:

;;  mov r12,r0
;;  add #-48,r0 ->  add #-48,r12
;;  mov.l   r0,@(4,r10) mov.l   r12,@(4,r10)
;;  (r12 dead)
(define_peephole2
  [(set (match_operand:SI 0 "arith_reg_dest")
(match_operand:SI 1 "arith_reg_dest"))
   (set (match_dup 0) (plus:SI (match_dup 0)
   (match_operand:SI 2 "const_int_operand")))
   (set (match_operand:SI 3 "general_movdst_operand") (match_dup 0))]


as far as I can tell, it optimizes

  r0 = r2
  r0 += 64
  *(r0+4) = r0

to

  r2 += 64
  *(r0+4) = r2

failing to notice that the the destination uses r0 too.

Then in the cprop-registers step that r0 is replaced with r12 b/c of r0 = r12
done a bit earlier.

[Bug tree-optimization/101497] [12 Regression] ice in type, at value-range.h:221

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101497

--- Comment #3 from David Binderman  ---
(In reply to David Binderman from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > (In reply to David Binderman from comment #0)
> > > Bug first seems to occur sometime between git hash 7466a0a5d8d536ab
> > > and 94ba897be8b59ef5
> > 
> > So between r12-2235 and r12-2372.
> 
> About 68 revisions, so trying revision 269ca408e2839d7f.

Seems good, so trying 33255ad3ac14e395.

[Bug tree-optimization/101497] [12 Regression] ice in type, at value-range.h:221

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101497

--- Comment #2 from David Binderman  ---
(In reply to Andrew Pinski from comment #1)
> (In reply to David Binderman from comment #0)
> > Bug first seems to occur sometime between git hash 7466a0a5d8d536ab
> > and 94ba897be8b59ef5
> 
> So between r12-2235 and r12-2372.

About 68 revisions, so trying revision 269ca408e2839d7f.

[Bug target/80786] m68k: internal compiler error: in change_address_1

[mikpelinux at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80786

--- Comment #2 from Mikael Pettersson  ---
Still ICEs gcc-12. m68k_legitimate_address_p () returns false for

(const:SI (plus:SI (symbol_ref:SI ("G") [flags 0x40] )
(const_int 6 [0x6])))
mode 4 (QI is 4)

which triggers the assert failure in change_address_1 ().

[Bug target/82420] ICE with -malign-int and -m68000

[mikpelinux at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420

--- Comment #3 from Mikael Pettersson  ---
Still ICEs in gcc-12:

> gcc/xgcc -Bgcc -march=68000 -malign-int -S /tmp/pr82420.c
during RTL pass: expand
/tmp/pr82420.c: In function 'f':
/tmp/pr82420.c:3:4: internal compiler error: Segmentation fault
3 |  a /= 3;
  |^~
0x95fe3f crash_signal
/tmp/gcc-12-20210711/gcc/toplev.c:328
0x6c30a2 assign_temp(tree_node*, int, int)
/tmp/gcc-12-20210711/gcc/function.c:976
0x67e321 emit_push_insn(rtx_def*, machine_mode, tree_node*, rtx_def*, unsigned
int, int, rtx_def*, poly_int<1u, long>, rtx_def*, rtx_def*, int, rtx_def*,
bool)
/tmp/gcc-12-20210711/gcc/expr.c:4621
0x559c98 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
/tmp/gcc-12-20210711/gcc/calls.c:5595
0x86de22 emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, rtx_def*, machine_mode, rtx_def*, machine_mode)
/tmp/gcc-12-20210711/gcc/rtl.h:4390
0x86de22 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
/tmp/gcc-12-20210711/gcc/optabs.c:2172
0x86f9e6 sign_expand_binop(machine_mode, optab_tag, optab_tag, rtx_def*,
rtx_def*, rtx_def*, int, optab_methods)
/tmp/gcc-12-20210711/gcc/optabs.c:2304
0x665e44 expand_divmod(int, tree_code, machine_mode, rtx_def*, rtx_def*,
rtx_def*, int, optab_methods)
/tmp/gcc-12-20210711/gcc/expmed.c:5271
0x66fdad expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/tmp/gcc-12-20210711/gcc/expr.c:9473
0x57296a expand_gimple_stmt_1
/tmp/gcc-12-20210711/gcc/cfgexpand.c:3980
0x57296a expand_gimple_stmt
/tmp/gcc-12-20210711/gcc/cfgexpand.c:4041
0x577392 expand_gimple_basic_block
/tmp/gcc-12-20210711/gcc/cfgexpand.c:6083
0x579196 execute
/tmp/gcc-12-20210711/gcc/cfgexpand.c:6809
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The SEGV occurs because emit_library_call_value_1 () [calls.c line 5595] calls
emit_push_insn () with NULL_TREE for TYPE, emit_push_insn () in this test case
needs to call assign_temp () [expr.c line 4621] with the given TYPE, but
assign_temp () fundamentally requires a non-NULL_TREE TYPE.

[Bug jit/101491] [11 regression] /usr/local/include/libgccjit++.h conflicts between different GCC installations

[gerald at pfeifer dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491

Gerald Pfeifer  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-18
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Gerald Pfeifer  ---
As one data point, gccjit is a "relatively newer" thing for the FreeBSD
ports of GCC, e.g. in case of lang/gcc11-devel:

  commit bb995aaf6e25e33b028fa4b32321864b48f49055
  Author: Ashish SHUKLA 
  Date:   Tue Feb 23 09:07:37 2021 +

- Enable gccjit support

Approved by:gerald (maintainer)

Looking at the diff it appears the issue was there back then already:

  --- a/lang/gcc11-devel/pkg-plist
  +++ b/lang/gcc11-devel/pkg-plist
  @@ -18,6 +18,8 @@ bin/gcov-dump%%SUFFIX%%
   bin/gcov-tool%%SUFFIX%%
   bin/gfortran%%SUFFIX%%
   bin/lto-dump%%SUFFIX%%
  +include/libgccjit++.h
  +include/libgccjit.h

Alas it only materialized when lang/gcc12-devel was added:

  commit 982ce2ea27d8d41ed4f69c6c8f1eb56f04280531
  Author: Gerald Pfeifer 
  Date:   Mon May 3 10:45:02 2021 +

lang/gcc12-devel: New port based on the 20210426 snapshot of GCC 12.0.0

This is the first snapshot from trunk with the GCC 12 designation. It
largely is a copy of lang/gcc11-devel.


(In reply to David Malcolm from comment #2)
> I wonder why this changed recently; as Dimitry notes, this has been 
> done the same since the initial merger of libgccjit into trunk.

I believe we are not looking at a regression in one of the FreeBSD ports
nor on the gccjit side, just an issue that's been there "from day 1".

Dimitry, is this consistent with your experience?


> I'm using $(includedir).  What should I be using?  Thanks

I'm not an expert, yet dug a bit and most include files appear to be 
installed in lib/gcc11/gcc/i386-portbld-freebsd11.4/11.1.1/include
which libgomp/Makefile, libquadmath/Makefile, libssp/Makefile and
others have as

   libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include

Would something like this work for libgccjit as well, David?

[Bug jit/95498] unhandled conversion

[bouanto at zoho dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498

Antoni  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #8 from Antoni  ---
Fixed in master.

[Bug jit/95498] unhandled conversion

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Antoni Boucher :

https://gcc.gnu.org/g:5cca4131e4aabf70a18e362620ad65a3cebf227a

commit r12-2384-g5cca4131e4aabf70a18e362620ad65a3cebf227a
Author: Antoni Boucher 
Date:   Sun Jul 5 19:07:30 2020 -0400

libgccjit: Handle truncation and extension for casts [PR95498]

2021-07-18  Antoni Boucher  

gcc/jit/
PR target/95498
* jit-playback.c (convert): Add support to handle truncation and
extension in the convert function.

gcc/testsuite/
PR target/95498
* jit.dg/all-non-failing-tests.h: New test.
* jit.dg/test-cast.c: New test.

Signed-off-by: Antoni Boucher 

[Bug c++/101499] New: ICE: in dependent_type_p, at cp/pt.c:26765

[hewillk at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101499

Bug ID: 101499
   Summary: ICE: in dependent_type_p, at cp/pt.c:26765
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

template 
template 
concept C = T::value;

static_assert(C);

https://godbolt.org/z/WfEYEvb8n

[Bug bootstrap/93758] Building x86_64-w64-mingw32-gcc (mingw-w64) on macOS Catalina results in "internal compiler error: Segmentation fault"

[iains at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93758

--- Comment #5 from Iain Sandoe  ---
(In reply to Mojca Miklavec from comment #4)
> I'm sorry, I forgot about this ticket. I can confirm that building (version
> 11.1) in fact works on all macOS versions at the moment
> 
> https://ports.macports.org/port/x86_64-w64-mingw32-gcc/details/
> 
> It's only broken for i686 on 10.6, but that's a completely different issue
> that we need to investigate separately at some point.
> 
> (ld: illegal text-relocation to ___stdoutp in /usr/lib/libSystem.dylib from
> _main in build/gengenrtl.o for architecture i386)

Is that using clang as the bootstrap compiler?

I have a patch that works around the issue with -m32 -fno-PIE producing broken
relocations with clang - but I thought Ken had already applied it?

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #253 from The Written Word  
---
(In reply to The Written Word from comment #245)
> (In reply to John Buddery from comment #238)
> > Was your 11.1 build successful ?
> 
> Our rebuild of 11.1.0 completed successfully. I haven't tested it though. I
> am going to try earlier GCC releases and build on 11.23/IA as well.

A build on 11.23/IA worked using similar patches to 11.31/IA.

[Bug bootstrap/93758] Building x86_64-w64-mingw32-gcc (mingw-w64) on macOS Catalina results in "internal compiler error: Segmentation fault"

[mojca at macports dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93758

--- Comment #4 from Mojca Miklavec  ---
I'm sorry, I forgot about this ticket. I can confirm that building (version
11.1) in fact works on all macOS versions at the moment

https://ports.macports.org/port/x86_64-w64-mingw32-gcc/details/

It's only broken for i686 on 10.6, but that's a completely different issue that
we need to investigate separately at some point.

(ld: illegal text-relocation to ___stdoutp in /usr/lib/libSystem.dylib from
_main in build/gengenrtl.o for architecture i386)

[Bug c++/101498] New: gcc accepts template code with 'auto' as subtype

[fchelnokov at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101498

Bug ID: 101498
   Summary: gcc accepts template code with 'auto' as subtype
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The code as follows:
```
template  struct S;
void foo(S);

```
is ill-formed and must be rejected, but gcc accepts it:
https://gcc.godbolt.org/z/bMof1xsEa

[Bug target/101286] [12 Regression] ICE: in ix86_expand_vector_move, at config/i386/i386-expand.c:574 with -mavx2 and __int128 vector

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101286

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/101160] [12 Regression] ICE in df_word_lr_local_compute, at df-problems.c:2962 since r12-1702-g7232f7c4c2d72743

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101160

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/101162] [12 Regression] ICE (verify_gimple failed) for switch returning pointer-to-members since r12-1608

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101162

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/101496] [12 Regression] ice during GIMPLE pass: evrp

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101496

David Binderman  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #5 from David Binderman  ---
(In reply to David Binderman from comment #4)
> (In reply to David Binderman from comment #3)
> > (In reply to David Binderman from comment #2)
> > > (In reply to Andrew Pinski from comment #1)
> > > > (In reply to David Binderman from comment #0)
> > > > > Bug first seems to occur sometime after git hash 42ff474e28fa3c85
> > > > > but before cca7eb8f7cc157ed.
> > > > 
> > > > So between r12-1856 and r12-1917.
> > > 
> > > There are about 61 revisions, so git bisect offers 32638d4975f2768b
> > > for testing.
> > 
> > Seems good, so trying ba4b83c3e3bd8a85e3771b91ae39421d9dd7
> 
> Seems good, so trying 0c06e46a81d86d70

Bug seems to be between a7e655ae4016eaf04e261ff32fc67a14ebb0e329
and cca7eb8f7cc157ed1b351cbaa10a4066f8065c3a. Andrew Macleod is
the author of three of those four revisions, so adding this person
for additional comment.

[Bug tree-optimization/101496] [12 Regression] ice during GIMPLE pass: evrp

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101496

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> (In reply to David Binderman from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > (In reply to David Binderman from comment #0)
> > > > Bug first seems to occur sometime after git hash 42ff474e28fa3c85
> > > > but before cca7eb8f7cc157ed.
> > > 
> > > So between r12-1856 and r12-1917.
> > 
> > There are about 61 revisions, so git bisect offers 32638d4975f2768b
> > for testing.
> 
> Seems good, so trying ba4b83c3e3bd8a85e3771b91ae39421d9dd7

Seems good, so trying 0c06e46a81d86d70