[Bug c++/103057] [11/12 Regression] Internal compiler error: Error reporting routines re-entered

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
Summary|Internal compiler error:|[11/12 Regression] Internal
   |Error reporting routines|compiler error: Error
   |re-entered  |reporting routines
   ||re-entered

--- Comment #4 from Andrew Pinski  ---
(In reply to Dennis Lubert from comment #3)
> Yes, the original testcase is valid code that compiles fine with -w

There might be two different bugs here I think, can you redo your reduction but
this test also testing if -w still compiles the source?

[Bug fortran/103054] [f18] Gfortran accepts invalid and rejects valid co_reduce argument keyword name

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/103076] slp vectorizer failed to try smaller size for generic vectors with word_mode

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526

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

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

--- Comment #4 from Christophe Lyon  ---
If I'm not mistaken, if you click on "REGRESSED" for that specific line, you'll
see that only ssa-dom-thread-7.c actually regressed with the corresponding
flags.

For ivopts-4.c, if seems you need -mthumb and one of these values for -march:
armv7-a+mp+sec+neon-fp16
armv7ve+simd
armv7-a+mp+sec+vfpv3-d16-fp16
armv8-a+crc+simd+crypto
(possibly with -mfpu=auto)
or -march=armv8-a -mfpu=crypto-neon-fp-armv8

[Bug middle-end/96159] atomic creates incorrect code for possible isaligned struct

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #3 from Martin Uecker  ---

The documentation:

https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins

"The four non-arithmetic functions (load, store, exchange, and
compare_exchange) all have a generic version as well. This generic version
works on any data type.
It uses the lock-free built-in function if the specific data type size makes
that possible; otherwise, an external call is left to be resolved at run time."

[Bug fortran/103115] New: reallocation of character array fails when appending a constant size 4 array

[ygalklein at gmail dot com via Gcc-bugs]

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

Bug ID: 103115
   Summary: reallocation of character array fails when appending a
constant size 4 array
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ygalklein at gmail dot com
  Target Milestone: ---

The following example program:
```fortran
program reallocationCharacterArray
implicit none
character(:), dimension(:), allocatable :: titles
titles = ["1"]
titles = [titles,&
"2",&
"3",&
"4",&
"5"&
]
block
integer :: iTitle
do iTitle = 1, size(titles)
write(*, "('titles(',i2,') = ',a)") iTitle, trim(titles(iTitle))
end do
end block
end program reallocationCharacterArray
```

when compiled using gfortran 11.1 or 10.3 results with the following output:
`
size(titles) = 5
titles( 1) = 1
titles( 2) = 
titles( 3) = 
titles( 4) = 
titles( 5) = 
`

which is clearly wrong.
One can see that the reallocation succeded in increasing the size of titles
from 1 to 5 - but the assignment to all the places from 2 to 5 are erronous.

one should note that using intel compiler 2021.4 - results with the following
output:
`
size(titles) = 5
titles( 1) = 1
titles( 2) = 2
titles( 3) = 3
titles( 4) = 4
titles( 5) = 5
`

which is the right output.

One should also note that commenting one line from the constant array being
appended - i.e appending an array of size 3 (instead of size 4) results with
the right output when using gfortran, i.e

the following program (note the ! sign commenting one line):
```fortran
program reallocationCharacterArray
implicit none
character(:), dimension(:), allocatable :: titles
titles = ["1"]
titles = [titles,&
! "2",&
"3",&
"4",&
"5"&
]
write(*, "('size(titles) = ',i1)") size(titles)
block
integer :: iTitle
do iTitle = 1, size(titles)
write(*, "('titles(',i2,') = ',a)") iTitle, trim(titles(iTitle))
end do
end block
end program reallocationCharacterArray
```

results with the following right output:
`
size(titles) = 4
titles( 1) = 1
titles( 2) = 3
titles( 3) = 4
titles( 4) = 5
`

both in gfortran and ifort.

[Bug target/103095] Option to force no overalignment

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

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

Tom de Vries  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|RESOLVED|REOPENED
 Resolution|INVALID |---
   Last reconfirmed||2021-11-07
 Target|x86_64  |

--- Comment #3 from Tom de Vries  ---
This is not an x86_64-specific feature request, so removing the x86_64 from the
target field.

Thanks for pointing out -malign-data=abi, that's interesting.

I think though that it doesn't entirely match the feature request I've
described here.

Let's call the new one -fprecise-align for the moment.  It may be that
-fprecise-align should imply -malign-data=abi, I'm not sure, but for the
purposes of this discussion, I'll assume not.

AFAIU, the -malign-data=abi option has the effect that the compiler doesn't
require more alignment than required by the abi (which is one interpretation of
no overalignment).

The additional idea of this feature request is that the toolchain guarantees
that if some alignment is required, the actual address fits that alignment, but
not a greater alignment (which is another interpretation of no overalignment. 
Perhaps there's a better term for what I'm describing here?).

To be more concrete, take a float var, according to abi: size 4, alignment 4.

If we use -malign-data=abi and the variable at runtime is found at address 0x8,
we consider that the option is obeyed.

In contrast, if we use -malign=abi and -fprecise-align, and the variable at
runtime is found at address 0x8, we consider that the latter option is not
obeyed.

[Bug fortran/103115] reallocation of character array fails when appending a constant size 4 array

[ygalklein at gmail dot com via Gcc-bugs]

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

--- Comment #1 from ygal klein  ---
I see that in the first program I gave as an example I forgot to insert the
line

write(*, "('size(titles) = ',i1)") size(titles)

bf the block

anyway - it is there (one can see the output).

[Bug tree-optimization/103116] New: SLP vectoriser fails to peel for gaps

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

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

Bug ID: 103116
   Summary: SLP vectoriser fails to peel for gaps
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51744&action=edit
testcase

Compiling the attached testcase on x86_64-linux-gnu with -O2
-fno-vect-cost-model triggers a segfault.  We implement the y[] reads in:

  for (int i = 0; i < COUNT; ++i)
{
  x[i * 4] = y[i * 2] + 1;
  x[i * 4 + 1] = y[i * 2] + 2;
  x[i * 4 + 2] = y[i * 2 + 1] + 3;
  x[i * 4 + 3] = y[i * 2 + 1] + 4;
}

using a load and permute in which only the low half of the loaded data is used.
 The high half of the final iteration overruns the array.

I guess the usual approach of peeling one iteration for gaps will be enough,
but haven't thought about it much.  Are there corner cases where we might need
to peel more?

(We get away with this on AArch64 because we fall back to load/store lanes
instead.)

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #15 from Martin Uecker  ---
Another version of the patch:

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583593.html

[Bug c++/21678] Using inline disables warnings about missing return statements

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #8 from Marek Polacek  ---
This came up again in
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583592.html

[Bug fortran/103054] [f18] Gfortran accepts invalid and rejects valid co_reduce argument keyword name

[jvdelisle2 at gmail dot com via Gcc-bugs]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle2 at gmail dot com

--- Comment #3 from Jerry DeLisle  ---
I will commit as obvious.

[Bug tree-optimization/103117] New: uncprop produces harder to analyze but not better code

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

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

Bug ID: 103117
   Summary: uncprop produces harder to analyze but not better code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

For the following
struct a {int v; struct a *next;};

struct a*
next(struct a *a)
{
  if (!a || a->v)
return 0;
  return a->next;
}

(we have quite few functions like this in gcc sources)

We produce

struct a * next (struct a * a)
{
  int _1;
  struct a * _2;
  struct a * _5;

   [local count: 1073741824]:
  if (a_3(D) == 0B)
goto ; [8.27%]
  else
goto ; [91.73%]

   [local count: 88798448]:
  goto ; [100.00%]

   [local count: 984943377]:
  _1 = a_3(D)->v;
  if (_1 != 0)
goto ; [17.38%]
  else
goto ; [82.62%]

   [local count: 171183158]:
  goto ; [100.00%]

   [local count: 813760219]:
  _5 = a_3(D)->next;

   [local count: 1073741824]:
  # _2 = PHI <0B(7), _5(4), 0B(6)>
  return _2;

}

while uncprop concludes it is a good idea to turn 0 in the last PHI to a:

  # _2 = PHI <0B(7), _5(4), a_3(D)(6)>

this confuses e.g. modref that thinks that a may be returned directly because
it does not understand that the a_3 argument of PHI is funny way to express
constant 0.

I do not think the uncprop change helps anything - the PHI still has 0 argument
in the other arm.

The modref confussion can be solved by moving it before uncprop, but I wonder
if we want to do the transform after all.

[Bug fortran/103054] [f18] Gfortran accepts invalid and rejects valid co_reduce argument keyword name

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

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Created attachment 51745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51745&action=edit
documentation update

Forgot the documentation part of the patch.

[Bug target/103095] Option to force no overalignment

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #4 from Andrew Pinski  ---
(In reply to Tom de Vries from comment #3)
> In contrast, if we use -malign=abi and -fprecise-align, and the variable at
> runtime is found at address 0x8, we consider that the latter option is not
> obeyed.


The original issue referenced in this bug was really fixed with
-malign-data=abi.


The more complex issue here is that "over alignment" is something which might
be the just does not make sense as an option to be provided.

Stack will need be reunaligned at runtime, I have to wonder if this is even a
good thing to do and can be represented in dwarf2 ...

[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

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

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

--- Comment #25 from Jan Hubicka  ---
LNT sees new regresion on WRF build times (around 6%) at Nov 3

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=287.548.8
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.270.8

The revision range is 
g:2d01bef2f214bb80dca0e91c14e95cf4d76b0afb..cd389e5f9447d21084abff5d4b7db6cf1da74e57
which contains switch of vrp2 to ranger, so I guess it is the likely reason.

[Bug fortran/89078] [meta-bug] Improve the gfortran manual

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

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

--- Comment #2 from sandra at gcc dot gnu.org ---
I did look over the entire list of still-open issues and did not see any
further low-hanging fruit.  It also seemed to me that some of the issues on the
list are cases where it appears the implementation is broken or not useful, not
just the documentation.

[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Sandra Loosemore :

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

commit r12-4979-gee11be7f2d788e6055ebed9746a8d8ac3cb04b8e
Author: Sandra Loosemore 
Date:   Thu Nov 4 15:43:29 2021 -0700

Fortran: Diagnose all operands/arguments with constraint violations

04-Nov-2021  Sandra Loosemore 
 Bernhard Reutner-Fischer 

 PR fortran/101337

gcc/fortran/ChangeLog:
* interface.c (gfc_compare_actual_formal): Continue checking
all arguments after encountering an error.
* intrinsic.c (do_ts29113_check): Likewise.
* resolve.c (resolve_operator): Continue resolving on op2 error.

gcc/testsuite/ChangeLog:
* gfortran.dg/bessel_3.f90: Expect additional diagnostics from
multiple bad arguments in the call.
* gfortran.dg/pr24823.f: Likewise.
* gfortran.dg/pr39937.f: Likewise.
* gfortran.dg/pr41011.f: Likewise.
* gfortran.dg/pr61318.f90: Likewise.
* gfortran.dg/c-interop/c407b-2.f90: Remove xfails.
* gfortran.dg/c-interop/c535b-2.f90: Likewise.

[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from sandra at gcc dot gnu.org ---
Fixed, at least the cases I wrote testcases for relating to TS29113 constraint
violations.

[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

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

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

--- Comment #26 from Aldy Hernandez  ---
(In reply to Jan Hubicka from comment #25)
> LNT sees new regresion on WRF build times (around 6%) at Nov 3
> 
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=287.548.8
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.270.8
> 
> The revision range is 
> g:2d01bef2f214bb80dca0e91c14e95cf4d76b0afb..
> cd389e5f9447d21084abff5d4b7db6cf1da74e57 which contains switch of vrp2 to
> ranger, so I guess it is the likely reason.

This PR is still open, at least for slowdown in the threader with LTO.  The
issue is ranger wide, so it may also cause slowdowns  on non-LTO builds for
WRF, though I haven't checked.

[Bug c++/103118] New: [modules] ICE tree check in get_merge_kind at cp/module.cc

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 103118
   Summary: [modules] ICE tree check in get_merge_kind at
cp/module.cc
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

Including `` in the following source results in an ICE.

std.hpp:
```C++
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
```

Command:
```
g++ -std=c++23 -fmodules-ts -x c++-header -c std.hpp
```

Output:
```
std.hpp: internal compiler error: tree check: expected var_decl or
function_decl or field_decl or type_decl or concept_decl or template_decl, have
namespace_decl in get_merge_kind, at cp/module.cc:10072
0x208bafd internal_error(char const*, ...)
???:0
0x8b1d90 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0xabf5dd trees_out::decl_value(tree_node*, depset*)
???:0
0xac077b trees_out::decl_node(tree_node*, walk_kind)
???:0
0xac17aa trees_out::tree_node(tree_node*)
???:0
0xac1b02 trees_out::chained_decls(tree_node*)
???:0
0xac2ab1 trees_out::core_vals(tree_node*)
???:0
0xac5748 trees_out::tree_value(tree_node*)
???:0
0xac1608 trees_out::tree_node(tree_node*)
???:0
0xac5870 trees_out::write_function_def(tree_node*)
???:0
0xac7b6c depset::hash::find_dependencies(module_state*)
???:0
0xac7fba module_state::write(elf_out*, cpp_reader*)
???:0
0xac968e finish_module_processing(cpp_reader*)
???:0
0xa5739c c_parse_final_cleanups()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[aladjev.andrew at gmail dot com via Gcc-bugs]

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

--- Comment #30 from Andrew Aladjev  ---
Created attachment 51746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51746&action=edit
Include fenv dirty patch for gcc 11.2.0

Please apply carefully, it is not safe.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #31 from cqwrteur  ---
(In reply to Andrew Aladjev from comment #30)
> Created attachment 51746 [details]
> Include fenv dirty patch for gcc 11.2.0
> 
> Please apply carefully, it is not safe.

no. adding -nostdinc++ is the right solution. yours are wrong.

Re: [Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

[Jan Hubicka via Gcc-bugs]

> 
> This PR is still open, at least for slowdown in the threader with LTO.  The
> issue is ranger wide, so it may also cause slowdowns  on non-LTO builds for
> WRF, though I haven't checked.
I just wanted to record the fact somewhere since I was looking up the
revision range mostly to figure out if there was modref change that may
cause this.

Non-lto builds seems fine.  I suppose LTo is needed ot make bug enough
CFGs.  Thanks for looking into it.

Honza

[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #27 from hubicka at kam dot mff.cuni.cz ---
> 
> This PR is still open, at least for slowdown in the threader with LTO.  The
> issue is ranger wide, so it may also cause slowdowns  on non-LTO builds for
> WRF, though I haven't checked.
I just wanted to record the fact somewhere since I was looking up the
revision range mostly to figure out if there was modref change that may
cause this.

Non-lto builds seems fine.  I suppose LTo is needed ot make bug enough
CFGs.  Thanks for looking into it.

Honza

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[aladjev.andrew at gmail dot com via Gcc-bugs]

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

--- Comment #32 from Andrew Aladjev  ---
I've added include_next_fenv dirty patch. I want just to quickly explain how to
use it.

First of all I've noticed (many years ago) that gcc developers are making
releases based on limited set of basic tests. These tests include one self
compilation using same version of gcc: gcc 11.2.0 amd64 -> gcc 11.2.0 amd64.
But in reality you have the following case:

gcc #{prev_version} #{platform1} #{env1} -> gcc #{next_version} #{platform2}
#{env2}

This movement is very hard task in practice, so I've added an additional step:

gcc #{prev_version} #{platform1} #{env1} -> dirty gcc #{next_version}
#{platform2} #{dirty_env2} -> gcc #{next_version} #{platform2} #{env2}

"dirty gcc" and "dirty env" step is very usefull when nobody have a solution.
You can invent your own dirty bicycle, apply it and you will receive clean gcc
on target platform in the last step anyway.

You may also review the following repo
https://github.com/andrew-aladev/test-images with my some test images.

Thank you.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #33 from cqwrteur  ---
(In reply to Andrew Aladjev from comment #32)
> I've added include_next_fenv dirty patch. I want just to quickly explain how
> to use it.
> 
> First of all I've noticed (many years ago) that gcc developers are making
> releases based on limited set of basic tests. These tests include one self
> compilation using same version of gcc: gcc 11.2.0 amd64 -> gcc 11.2.0 amd64.
> But in reality you have the following case:
> 
> gcc #{prev_version} #{platform1} #{env1} -> gcc #{next_version} #{platform2}
> #{env2}
> 
> This movement is very hard task in practice, so I've added an additional
> step:
> 
> gcc #{prev_version} #{platform1} #{env1} -> dirty gcc #{next_version}
> #{platform2} #{dirty_env2} -> gcc #{next_version} #{platform2} #{env2}
> 
> "dirty gcc" and "dirty env" step is very usefull when nobody have a
> solution. You can invent your own dirty bicycle, apply it and you will
> receive clean gcc on target platform in the last step anyway.
> 
> You may also review the following repo
> https://github.com/andrew-aladev/test-images with my some test images.
> 
> Thank you.

I can ensure your patch is not correct

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #34 from cqwrteur  ---
Created attachment 51747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51747&action=edit
Correct Patch by just fixing configure and configure.ac with -nostdinc++

Tested with over 20 canadian cross builds without any issues.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[aladjev.andrew at gmail dot com via Gcc-bugs]

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

--- Comment #35 from Andrew Aladjev  ---
Hello cqwrteur, do you have an influence on core gcc developers? Please provide
an idea to add at least one "canadian" test before release. x86_64-pc-linux-gnu
-> x86_64-unknown-linux-gnu will be enough. We should not definitely meet here
trying to treat "childhood" issues.

Thank you.

[Bug tree-optimization/103119] New: ICE in get_imports, at gimple-range-gori.cc:230

[vsevolod.livinskij at frtk dot ru via Gcc-bugs]

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

Bug ID: 103119
   Summary: ICE in get_imports, at gimple-range-gori.cc:230
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

The bug is not reproducible on the trunk anymore (the reduction process took
forever).
I don't know if it was fixed or became latent. Feel free to close it if it is
not relevant anymore.

Reproducer:
unsigned short a;
bool b;
int h, f;
extern bool d[][1];
char g;
void i() {
  for (short c = 0; c < 10; c += 3)
for (unsigned e = 0; e < a; e = (d[c][0] ? true : 5) * (6021496ULL * b) ?:
f)
  h = g;
}

Error:
>$ g++ -O2 -c func.cpp
during GIMPLE pass: vrp
func.cpp: In function 'void i()':
func.cpp:6:6: internal compiler error: in get_imports, at
gimple-range-gori.cc:230
6 | void i() {
  |  ^
0x9e98e5 range_def_chain::get_imports(tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:230
0x1edc480 range_def_chain::register_dependency(tree_node*, tree_node*,
basic_block_def*)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:288
0x1edb976 range_def_chain::get_def_chain(tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:383
0x1edbf98 range_def_chain::in_chain_p(tree_node*, tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:198
0x1ede29b gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*, fur_source&)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:725
0x1edef21 gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*, fur_source&)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:1078
0x1ede699 gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*, fur_source&)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:761
0x1edf989 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*,
range_query&)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:1259
0x1ed28c5 ranger_cache::range_on_edge(irange&, edge_def*, tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range-cache.cc:983
0x1ed2b69 ranger_cache::propagate_cache(tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range-cache.cc:1082
0x1ecdd9d gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range.cc:280
0x15d1934 simplify_using_ranges::fold_cond(gcond*)
/testing/gcc/gcc_src_master/gcc/vr-values.c:3492
0x15d1ea8 simplify_using_ranges::simplify_cond_using_ranges_1(gcond*)
/testing/gcc/gcc_src_master/gcc/vr-values.c:3568
0x15d6f87 simplify_using_ranges::simplify(gimple_stmt_iterator*)
/testing/gcc/gcc_src_master/gcc/vr-values.c:4386
0x154e3c8 rvrp_folder::fold_stmt(gimple_stmt_iterator*)
/testing/gcc/gcc_src_master/gcc/tree-vrp.c:4324
0x14434d6 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-propagate.c:870
0x1e9c847 dom_walker::walk(basic_block_def*)
/testing/gcc/gcc_src_master/gcc/domwalk.c:309
0x1442689 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-propagate.c:987
0x15442c1 execute_ranger_vrp(function*, bool)
/testing/gcc/gcc_src_master/gcc/tree-vrp.c:4349
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

GCC version:
gcc version 12.0.0 20211105 (614b39757b8b61f70ac1c666edb7a01a5fc19cd4) (GCC)

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #36 from cqwrteur  ---
(In reply to Andrew Aladjev from comment #35)
> Hello cqwrteur, do you have an influence on core gcc developers? Please
> provide an idea to add at least one "canadian" test before release.
> x86_64-pc-linux-gnu -> x86_64-unknown-linux-gnu will be enough. We should
> not definitely meet here trying to treat "childhood" issues.
> 
> Thank you.

I built that before. x86_64-pc-linux-gnu -> x86_64-ubuntu-linux-gnu Canadian
native.

x86_64-pc-linux-gnu build x86_64-w64-mingw32 cross x86_64-ubuntu-linux-gnu
Canadian cross build.


That patch works of course.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #37 from cqwrteur  ---
(In reply to cqwrteur from comment #36)
> (In reply to Andrew Aladjev from comment #35)
> > Hello cqwrteur, do you have an influence on core gcc developers? Please
> > provide an idea to add at least one "canadian" test before release.
> > x86_64-pc-linux-gnu -> x86_64-unknown-linux-gnu will be enough. We should
> > not definitely meet here trying to treat "childhood" issues.
> > 
> > Thank you.
> 
> I built that before. x86_64-pc-linux-gnu -> x86_64-ubuntu-linux-gnu Canadian
> native.
> 
> x86_64-pc-linux-gnu build x86_64-w64-mingw32 cross x86_64-ubuntu-linux-gnu
> Canadian cross build.
> 
> 
> That patch works of course.

cqwrteur@localhost:~$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/cqwrteur/x86_64-ubuntu-linux-gnu/bin/../libexec/gcc/x86_64-ubuntu-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-ubuntu-linux-gnu
Configured with: ../../../gcc/configure --disable-werror --disable-nls
--enable-languages=c,c++ --enable-multilib --disable-bootstrap
--disable-libstdcxx-verbose
--with-gxx-libcxx-include-dir=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu_canadian/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/c++/v1
--prefix=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu_canadian/x86_64-ubuntu-linux-gnu
--with-pkgversion=cqwrteur --with-multilib-list=m64,m32,mx32
--target=x86_64-ubuntu-linux-gnu --host=x86_64-ubuntu-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210910 (experimental) (cqwrteur)


D:\hg>x86_64-ubuntu-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-ubuntu-linux-gnu-g++
COLLECT_LTO_WRAPPER=d:/x86_64-windows-gnu/x86_64-ubuntu-linux-gnu/bin/../libexec/gcc/x86_64-ubuntu-linux-gnu/12.0.0/lto-wrapper.exe
Target: x86_64-ubuntu-linux-gnu
Configured with: ../../../gcc/configure --disable-nls --disable-werror
--prefix=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu
--target=x86_64-ubuntu-linux-gnu --host=x86_64-w64-mingw32
--with-gxx-libcxx-include-dir=/home/cqwrteur/canadian/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/include/c++/v1
--enable-multilib --with-multilib-list=m64,mx32,m32 --disable-libstdcxx-verbose
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211005 (experimental) (GCC)

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[aladjev.andrew at gmail dot com via Gcc-bugs]

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

--- Comment #38 from Andrew Aladjev  ---
Sure, patches works perfect. But we need somehow decrease the chance of similar
regressions in future. It is possible by adding any basic "canadian" build into
the list of tests to be done before release. We should not try to add such test
into codebase itself, we need just to intrigue any of core gcc developers to
add this test into the virtual checklist.

Thank you.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #39 from cqwrteur  ---
(In reply to Andrew Aladjev from comment #38)
> Sure, patches works perfect. But we need somehow decrease the chance of
> similar regressions in future. It is possible by adding any basic "canadian"
> build into the list of tests to be done before release. We should not try to
> add such test into codebase itself, we need just to intrigue any of core gcc
> developers to add this test into the virtual checklist.
> 
> Thank you.

You do not need to worry tbh, people like me would test before you.

They have much more issues than just a Canadian build tbh. Like copying wrong
DLLs for multilibs. Nobody ever built that before probably.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #40 from cqwrteur  ---
(In reply to Andrew Aladjev from comment #38)
> Sure, patches works perfect. But we need somehow decrease the chance of
> similar regressions in future. It is possible by adding any basic "canadian"
> build into the list of tests to be done before release. We should not try to
> add such test into codebase itself, we need just to intrigue any of core gcc
> developers to add this test into the virtual checklist.
> 
> Thank you.

Issues like this are exactly why i would never use a script (including things
like cross-ng) to build anything. I would build everything manually since it is
very likely to fail for all sorts of different reasons, neither their testing
would fix it since they have to include different libcs (we have hundreds of
different libcs) to test each of them, which is not possible.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #41 from cqwrteur  ---
(In reply to Andrew Aladjev from comment #38)
> Sure, patches works perfect. But we need somehow decrease the chance of
> similar regressions in future. It is possible by adding any basic "canadian"
> build into the list of tests to be done before release. We should not try to
> add such test into codebase itself, we need just to intrigue any of core gcc
> developers to add this test into the virtual checklist.
> 
> Thank you.

The only thing you can do is that if you find a build bug, report to bugzilla

[Bug tree-optimization/103111] bogus stringop overflow warning

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
The warning corresponds to the call below where the RANGE shows what it's based
on:

;;   basic block 10, loop depth 1, count 237404316 (estimated locally), maybe
hot
;;prev block 9, next block 11, flags: (NEW, REACHABLE, VISITED)
;;pred:   9 [80.5% (guessed)]  count:237404316 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
  # RANGE [18446744071562067968, 18446744073709551615]
  _12 = (long unsigned intD.10) _5;
  # .MEM_39 = VDEF <.MEM_38>
  memcpyD.925 (_11, pretmp_90, _12);

Mixing signed and unsigned ints in computations involving sizes, especially in
LP64 where size_t is larger than int, tends to lead to excessive results that
might then end up either triggering warnings or lead to suboptimal code.  Using
unsigned integers (e.g., making sbuf's s_n and s_sz members unsigned) avoids
the warning and looks like also lets GCC emit better object code.

[Bug middle-end/96159] atomic creates incorrect code for possible isaligned struct

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

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

--- Comment #4 from Andrew Pinski  ---
So it looks like __atomic_load assumes the type is _Atomic which has the right
alignment to it.

[Bug fortran/103054] [f18] Gfortran accepts invalid and rejects valid co_reduce argument keyword name

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Please have a look at the testsuite, too.

[Bug fortran/102521] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6240

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

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

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

https://gcc.gnu.org/g:1b740d8000cac8048c728fb0bd75c7146429

commit r11-9213-g1b740d8000cac8048c728fb0bd75c7146429
Author: Harald Anlauf 
Date:   Sun Oct 10 20:11:43 2021 +0200

Fortran: handle initialization of derived type parameter arrays from scalar

gcc/fortran/ChangeLog:

PR fortran/99348
PR fortran/102521
* decl.c (add_init_expr_to_sym): Extend initialization of
parameter arrays from scalars to handle derived types.

gcc/testsuite/ChangeLog:

PR fortran/99348
PR fortran/102521
* gfortran.dg/parameter_array_init_8.f90: New test.

(cherry picked from commit 74ccca380cde5e79e082d39214b306a90ded0344)

[Bug fortran/99348] ICE in resolve_structure_cons, at fortran/resolve.c:1286

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

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

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

https://gcc.gnu.org/g:1b740d8000cac8048c728fb0bd75c7146429

commit r11-9213-g1b740d8000cac8048c728fb0bd75c7146429
Author: Harald Anlauf 
Date:   Sun Oct 10 20:11:43 2021 +0200

Fortran: handle initialization of derived type parameter arrays from scalar

gcc/fortran/ChangeLog:

PR fortran/99348
PR fortran/102521
* decl.c (add_init_expr_to_sym): Extend initialization of
parameter arrays from scalars to handle derived types.

gcc/testsuite/ChangeLog:

PR fortran/99348
PR fortran/102521
* gfortran.dg/parameter_array_init_8.f90: New test.

(cherry picked from commit 74ccca380cde5e79e082d39214b306a90ded0344)

[Bug fortran/102817] [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422 since r12-4278-g74ccca380cde5e79

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

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

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

https://gcc.gnu.org/g:907fd5049735ed1bd17e221db5a812dedee5dfc8

commit r11-9214-g907fd5049735ed1bd17e221db5a812dedee5dfc8
Author: Harald Anlauf 
Date:   Fri Nov 5 23:48:20 2021 +0100

Fortran: fix simplification of array-valued parameter expressions

gcc/fortran/ChangeLog:

PR fortran/102817
* expr.c (simplify_parameter_variable): Copy shape of referenced
subobject when simplifying.

gcc/testsuite/ChangeLog:

PR fortran/102817
* gfortran.dg/pr102817.f90: New test.

(cherry picked from commit bcf3728abe842922005166d3065fc5fdfea1)

[Bug fortran/102715] [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8184 since r12-4278-g74ccca380cde5e79

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

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

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

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

commit r11-9215-gdb1da3d37e33b0adcd7fed68cfdb96e8ee265ccf
Author: Harald Anlauf 
Date:   Sat Nov 6 19:42:01 2021 +0100

Fortran: error recovery on rank mismatch of array and its initializer

gcc/fortran/ChangeLog:

PR fortran/102715
* decl.c (add_init_expr_to_sym): Reject rank mismatch between
array and its initializer.

gcc/testsuite/ChangeLog:

PR fortran/102715
* gfortran.dg/pr68019.f90: Adjust error message.
* gfortran.dg/pr102715.f90: New test.

(cherry picked from commit df2135e88a8f78c853b35246ad426b01b6d08378)

[Bug fortran/102685] [12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514 since r12-4278-g74ccca380cde5e79

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

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

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

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

commit r11-9216-gb1cab51131ad4d5501bf3f01e694704142a10c1a
Author: Harald Anlauf 
Date:   Fri Oct 15 21:23:17 2021 +0200

Fortran: validate shape of arrays in constructors against declarations

gcc/fortran/ChangeLog:

PR fortran/102685
* decl.c (match_clist_expr): Set rank/shape of clist initializer
to match LHS.
* resolve.c (resolve_structure_cons): In a structure constructor,
compare shapes of array components against declared shape.

gcc/testsuite/ChangeLog:

PR fortran/102685
* gfortran.dg/derived_constructor_char_1.f90: Fix invalid code.
* gfortran.dg/pr70931.f90: Likewise.
* gfortran.dg/transfer_simplify_2.f90: Likewise.
* gfortran.dg/pr102685.f90: New test.

Co-authored-by: Tobias Burnus 
(cherry picked from commit 1e819bd95ebeefc1dc469daa1855ce005cb77822)

[Bug fortran/102816] [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467 since r12-4452-g1e819bd95ebeefc1

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

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

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

https://gcc.gnu.org/g:3371e7f18df52867b0b88966bd98d3f1eff6f815

commit r11-9217-g3371e7f18df52867b0b88966bd98d3f1eff6f815
Author: Harald Anlauf 
Date:   Tue Oct 26 20:51:46 2021 +0200

Fortran: error recovery on initializing invalid derived type array
component

gcc/fortran/ChangeLog:

PR fortran/102816
* resolve.c (resolve_structure_cons): Reject invalid array spec of
a DT component referenced in a structure constructor.

gcc/testsuite/ChangeLog:

PR fortran/102816
* gfortran.dg/pr102816.f90: New test.

(cherry picked from commit 99af0b2f0fe1c0dc8c6d558157e700326d52816a)

[Bug ipa/103055] [12 Regression] ICE: in get_ssa_name_flags, at ipa-modref.c:1660 with --param=modref-max-depth=0 since r12-4852-g18f0873d1e595dc2

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:87e57378ba554212a32a0743fee03481d1289318

commit r12-4981-g87e57378ba554212a32a0743fee03481d1289318
Author: Jan Hubicka 
Date:   Sun Nov 7 22:58:19 2021 +0100

Limit range of modref-max-depth

gcc/ChangeLog:

PR ipa/103055
* params.opt (modref-max-depth): Add range.
(modref-max-adjustments): Fix range.

[Bug middle-end/103120] New: [12 Regression] test miscompiled with -O2 on darwin since r12-4790

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 103120
   Summary: [12 Regression] test miscompiled with -O2 on darwin
since r12-4790
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Starting from r12-4790, one of the D library tests started failing on darwin.

Distilled it down to following C code.  Passes when compiled with -O1 and -O3,
but fails with -O2.
---
#define radix 10
__INT32_TYPE__ numDigits(__UINT64_TYPE__ value)
{
 __INT32_TYPE__ n = 1;
 while (value > __UINT32_MAX__)
 {
n += 4;
value /= radix * radix * radix * radix;
 }
 __UINT32_TYPE__ v = (__UINT32_TYPE__)value;
 while (1)
 {
 if (v < radix)
 return n;
 if (v < radix * radix)
 return n + 1;
 if (v < radix * radix * radix)
 return n + 2;
 if (v < radix * radix * radix * radix)
 return n + 3;
 n += 4;
 v /= radix * radix * radix * radix;
 }
}

int main()
{
if (numDigits(__UINT64_MAX__) != 20)
__builtin_abort();
}

[Bug tree-optimization/103120] [12 Regression] test miscompiled with -O2 on darwin since r12-4790

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
  Component|middle-end  |tree-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-07
 Ever confirmed|0   |1
 Target||x86_64-lin ux-gnu

--- Comment #1 from Andrew Pinski  ---
Confirmed, even on x86_64-linux-gnu.

[Bug ipa/103055] [12 Regression] ICE: in get_ssa_name_flags, at ipa-modref.c:1660 with --param=modref-max-depth=0 since r12-4852-g18f0873d1e595dc2

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
fixed.

[Bug tree-optimization/103120] [12 Regression] test miscompiled with -O2 on darwin since r12-4790

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 Target|x86_64-lin ux-gnu   |x86_64-linux-gnu,
   ||x86_64-apple-darwin20

--- Comment #2 from Iain Buclaw  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, even on x86_64-linux-gnu.
Thanks, I didn't see a failure for D on linux, so assumed that was fine.

[Bug tree-optimization/98925] Extend ipa-prop to handle return functions for slot optimization

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

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|Extend modref to handle |Extend ipa-prop to handle
   |return slot optimization|return functions for slot
   ||optimization
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mjambor at suse dot cz
   Severity|normal  |enhancement
   Last reconfirmed||2021-11-07

--- Comment #2 from Jan Hubicka  ---
Modref now handles return slots.
However as discussed in earlier comment we also need return function in
ipa-prop to propagate constant from callee to caller. So I am keeping the PR to
track this (I think it would be useful especially for offlined ctors)

[Bug tree-optimization/103120] [12 Regression] test miscompiled with -O2 since r12-4790

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|x86_64-linux-gnu,   |
   |x86_64-apple-darwin20   |

--- Comment #3 from Andrew Pinski  ---
(In reply to Iain Buclaw from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Confirmed, even on x86_64-linux-gnu.
> Thanks, I didn't see a failure for D on linux, so assumed that was fine.

It fails even on aarch64-linux-gnu.  Let me double check if it passes after
r12-4971

[Bug tree-optimization/103120] [12 Regression] test miscompiled with -O2 since r12-4790

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |blocker

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> It fails even on aarch64-linux-gnu.  Let me double check if it passes after
> r12-4971

Yes it still fails as of r12-4973 on x86_64-linux-gnu.

[Bug other/103121] New: Warnings

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

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

Bug ID: 103121
   Summary: Warnings
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

/home/dave/gnu/gcc/objdir/./prev-gcc/xg++
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-12/hppa-linux-gnu/bin/ -nostdinc++
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
 -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -fno-checking -DIN_GCC 
   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -I. -Icp
-I../../gcc/gcc -I../../gcc/gcc/cp -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o cp/optimize.o -MT
cp/optimize.o -MMD -MP -MF cp/.deps/optimize.TPo ../../gcc/gcc/cp/optimize.c
/home/dave/gnu/gcc/objdir/./prev-gcc/xg++
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-12/hppa-linux-gnu/bin/ -nostdinc++
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
 -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -fno-checking -DIN_GCC 
   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -I. -Icp
-I../../gcc/gcc -I../../gcc/gcc/cp -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o cp/parser.o -MT
cp/parser.o -MMD -MP -MF cp/.deps/parser.TPo ../../gcc/gcc/cp/parser.c
../../gcc/gcc/cp/optimize.c: In function 'tree_node* cdtor_comdat_group(tree,
tree)':
../../gcc/gcc/cp/optimize.c:208:17: error: writing 1 byte into a region of size
0 [-Werror=stringop-overflow=]
  208 |   grp_name[idx] = '\0';
  |   ~~^~
In file included from ../../gcc/gcc/system.h:706,
 from ../../gcc/gcc/cp/optimize.c:22:
../../gcc/gcc/../include/libiberty.h:733:36: note: at offset 1 into destination
object of size 1 allocated by '__builtin_alloca'
  733 | # define alloca(x) __builtin_alloca(x)
  |^~~
../../gcc/gcc/../include/libiberty.h:365:40: note: in expansion of macro
'alloca'
  365 | #define XALLOCAVEC(T, N)((T *) alloca (sizeof (T) * (N)))
  |^~
../../gcc/gcc/cp/optimize.c:191:14: note: in expansion of macro 'XALLOCAVEC'
  191 |   grp_name = XALLOCAVEC (char, IDENTIFIER_LENGTH (complete_name) + 1);
  |  ^~
../../gcc/gcc/cp/parser.c: In function 'void
cp_parser_decl_specifier_seq(cp_parser*, cp_parser_flags,
cp_decl_specifier_seq*, int*)':
../../gcc/gcc/cp/parser.c:15847:55: warning: misspelled term 'decl' in format;
use 'declaration' instead [-Wformat-diag]
15847 | "standard attributes in middle of
decl-specifiers");
  |   ^~~~
../../gcc/gcc/cp/parser.c:15849:57: warning: misspelled term 'decl' in format;
use 'declaration' instead [-Wformat-diag]
15849 |   "standard attributes must precede the decl-specifiers
to "
  | ^~~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1138: cp/optimize.o] Error 1

[Bug fortran/103054] [f18] Gfortran accepts invalid and rejects valid co_reduce argument keyword name

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

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

Thomas Koenig  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||tkoenig at gcc dot gnu.org

--- Comment #6 from Thomas Koenig  ---
Fixed by https://gcc.gnu.org/g:962ff7d2849e1fa6a1fe0535aa2dec5c2b9a32a6

Thanks for the bug report!

[Bug tree-optimization/103122] New: [12 Regression] ICE in fill_block_cache, at gimple-range-cache.cc:1277 with -O2

[vsevolod.livinskij at frtk dot ru via Gcc-bugs]

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

Bug ID: 103122
   Summary: [12 Regression] ICE in fill_block_cache, at
gimple-range-cache.cc:1277 with -O2
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Link to the Compiler Explorer: https://godbolt.org/z/GWbbq3sKK
Reproducer:
unsigned a;
int b;
short c;
void d(long) {
  for (bool e = (bool)c - 1; e < (bool)b - 1; e += 0)
;
  if (a) {
for (char f = 0; f < 7; f = 7)
  for (int g = 0; g < c; g += 10)
;
d(-!c);
  }
}

Error:
>$ g++ -O2 -c func.cpp
during GIMPLE pass: evrp
func.cpp: In function 'void d(long int)':
func.cpp:13:1: internal compiler error: in fill_block_cache, at
gimple-range-cache.cc:1277
   13 | }
  | ^
0x9e79d7 ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
/testing/gcc/gcc_src_master/gcc/gimple-range-cache.cc:1277
0x1ed1ecd ranger_cache::block_range(irange&, basic_block_def*, tree_node*,
bool)
/testing/gcc/gcc_src_master/gcc/gimple-range-cache.cc:1107
0x1ecc4f8 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
/testing/gcc/gcc_src_master/gcc/gimple-range.cc:92
0xee7dff expr_not_equal_to(tree_node*, generic_wide_int
const&)
/testing/gcc/gcc_src_master/gcc/fold-const.c:10733
0xeec8e3 tree_single_nonzero_warnv_p(tree_node*, bool*)
/testing/gcc/gcc_src_master/gcc/fold-const.c:15244
0xeed076 tree_expr_nonzero_p(tree_node*)
/testing/gcc/gcc_src_master/gcc/fold-const.c:10706
0xefe7a8 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/testing/gcc/gcc_src_master/gcc/fold-const.c:12284
0xf0254d fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/testing/gcc/gcc_src_master/gcc/fold-const.c:13774
0x13fe25c simplify_using_initial_conditions(loop*, tree_node*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-loop-niter.c:2353
0x1404cd7 simplify_using_initial_conditions(loop*, tree_node*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-loop-niter.c:2333
0x1404cd7 number_of_iterations_exit_assumptions(loop*, edge_def*,
tree_niter_desc*, gcond**, bool, basic_block_def**)
/testing/gcc/gcc_src_master/gcc/tree-ssa-loop-niter.c:2590
0x1405be2 number_of_iterations_exit_assumptions(loop*, edge_def*,
tree_niter_desc*, gcond**, bool, basic_block_def**)
/testing/gcc/gcc_src_master/gcc/tree-ssa-loop-niter.c:2825
0x1405be2 number_of_iterations_exit(loop*, edge_def*, tree_niter_desc*, bool,
bool, basic_block_def**)
/testing/gcc/gcc_src_master/gcc/tree-ssa-loop-niter.c:2812
0x135f6f0 number_of_latch_executions(loop*)
/testing/gcc/gcc_src_master/gcc/tree-scalar-evolution.c:2813
0x1405ef5 estimate_numbers_of_iterations(loop*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-loop-niter.c:4356
0x1408c87 max_loop_iterations(loop*,
generic_wide_int >*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-loop-niter.c:4462
0x15d2f6f bounds_of_var_in_loop(tree_node**, tree_node**, range_query*, loop*,
gimple*, tree_node*)
/testing/gcc/gcc_src_master/gcc/vr-values.c:1708
0x1ed6641 fold_using_range::range_of_ssa_name_with_loop_info(irange&,
tree_node*, loop*, gphi*, fur_source&)
/testing/gcc/gcc_src_master/gcc/gimple-range-fold.cc:1282
0x1ed6e1e fold_using_range::range_of_phi(irange&, gphi*, fur_source&)
/testing/gcc/gcc_src_master/gcc/gimple-range-fold.cc:837
0x1ed8e50 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range-fold.cc:554
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

GCC version:
gcc version 12.0.0 20211107 (9defce622893f87d954e0089e0ea79e1e388a480) (GCC)

[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r12-4984-g2ad1e8081f4797a99a96b513ffe14c7305e9b3d8
Author: liuhongt 
Date:   Mon Nov 8 09:19:29 2021 +0800

[Gimple] Simplify (trunc)fma ((extend)a, (extend)b, (extend)c) to IFN_FMA
(a,b, c).

a, b, c are same type as truncation type and has less precision than
extend type, the optimization is guarded under
flag_unsafe_math_optimizations.

gcc/ChangeLog:
PR target/102464
* match.pd: Simplify
(trunc)fma ((extend)a, (extend)b, (extend)c) to IFN_FMA (a, b,
c) under flag_unsafe_math_optimizations.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr102464-fma.c: New test.

[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r12-4985-ga1f7ead09cd41d32e2fe902eb32e587c36e7
Author: liuhongt 
Date:   Mon Nov 8 09:32:17 2021 +0800

Add !HONOR_SNANS to simplifcation: (trunc)copysign((extend)a, (extend)b) to
copysign (a, b).

> Note that this is not safe with -fsignaling-nans, so needs to be disabled
> for that option (if there isn't already logic somewhere with that
effect),
> because the extend will convert a signaling NaN to quiet (raising
> "invalid"), but copysign won't, so this transformation could result in a
> signaling NaN being wrongly returned when the original code would never
> have returned a signaling NaN.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

gcc/ChangeLog

PR target/102464
* match.pd (Simplifcation (trunc)copysign((extend)a, (extend)b)
to .COPYSIGN (a, b)): Add !HONOR_SNANS.

[Bug tree-optimization/103077] [12 Regression] -ftree-loop-vectorize and -ftree-slp-vectorize are enabled at -O2 but their documentation says they are only enabled at -O3 and above

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r12-4986-gae1de0bf72fca92f94a7e29f51ce4448b877db4a
Author: liuhongt 
Date:   Fri Nov 5 10:41:22 2021 +0800

Update documentation for -ftree-loop-vectorize and -ftree-slp-vectorize
which are enabled by default at -02.

gcc/ChangeLog:

PR tree-optimization/103077
* doc/invoke.texi (Options That Control Optimization):
Update documentation for -ftree-loop-vectorize and
-ftree-slp-vectorize which are enabled by default at -02.

[Bug tree-optimization/103077] [12 Regression] -ftree-loop-vectorize and -ftree-slp-vectorize are enabled at -O2 but their documentation says they are only enabled at -O3 and above

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #3 from Hongtao.liu  ---
Fixed in GCC12.

[Bug target/103090] [i386] GCC should use the SF and ZF flags in some atomic_fetch_op sequences

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
Similar like Jakub did in r7-532, We need another IFN & optab to do the
optimization. The IFN and optab is like atomic_logic_test_and_set_sf which used
to perform logic operation and set SF.

[Bug tree-optimization/103122] [12 Regression] ICE in fill_block_cache, at gimple-range-cache.cc:1277 with -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c/103123] New: incorrect or misleading warning "floating constant exceeds range of ..." in ISO C11 and C17

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Bug ID: 103123
   Summary: incorrect or misleading warning "floating constant
exceeds range of ..." in ISO C11 and C17
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

On the C code

#if __STDC__ == 1 && __STDC_VERSION__ >= 201710 && defined(__STDC_IEC_559__)
double foo (void)
{
  return 1.0e999;
}
#endif

I get the following warning:

tst.c: In function 'foo':
tst.c:4:3: warning: floating constant exceeds range of 'double' [-Woverflow]
4 |   return 1.0e999;
  |   ^~

Tested version:
gcc (Debian 20210918-1) 12.0.0 20210918 (experimental) [master
r12-3644-g7afcb534239]

However, the C11 committee draft N1570 and C17 ballot N2176 say in 5.2.4.2.2p5:
"The minimum range of representable values for a floating type is the most
negative finite floating-point number representable in that type through the
most positive finite floating-point number representable in that type. In
addition, if negative infinity is representable in a type, the range of that
type is extended to all negative real numbers; likewise, if positive infinity
is representable in a type, the range of that type is extended to all positive
real numbers."

Note: The C2x draft N2731 says the same thing.

So, since __STDC_IEC_559__ is defined, there is a negative and a positive
infinity for the double type, and 5.2.4.2.2p5 implies that the range is the
whole set of real numbers. In particular, it includes the constant 1.0e999
above, so that the warning is incorrect, or at least misleading.

[Bug c/103123] incorrect or misleading warning "floating constant exceeds range of ..." in ISO C11 and C17

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

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

--- Comment #1 from Andrew Pinski  ---
The code in GCC:
  /* Both C and C++ require a diagnostic for a floating constant
 outside the range of representable values of its type.  Since we
 have __builtin_inf* to produce an infinity, this is now a
 mandatory pedwarn if the target does not support infinities.  */
  if (REAL_VALUE_ISINF (real)
  || (const_type != type && REAL_VALUE_ISINF (real_trunc)))
{
  *overflow = OT_OVERFLOW;
  if (!(flags & CPP_N_USERDEF))
{
  if (!MODE_HAS_INFINITIES (TYPE_MODE (type)))
pedwarn (input_location, 0,
 "floating constant exceeds range of %qT", type);
  else
warning (OPT_Woverflow,
 "floating constant exceeds range of %qT", type);
}
}


This is warning and can be turned off, -Woverflow is on by default.

[Bug c/103123] incorrect or misleading warning "floating constant exceeds range of ..." in ISO C11 and C17

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=23572

--- Comment #2 from Andrew Pinski  ---
Also an user requested this warning too, See PR 23572.

[Bug c/103123] incorrect or misleading warning "floating constant exceeds range of ..." in ISO C11 and C17

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

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

--- Comment #3 from Andrew Pinski  ---
Clang produces:
:4:10: warning: magnitude of floating-point constant too large for type
'double'; maximum is 1.7976931348623157E+308 [-Wliteral-range]
  return 1.0e999;
 ^

[Bug target/103124] New: PPC: "mr" instruction is unnecessary when extending DI to V1TI

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

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

Bug ID: 103124
   Summary: PPC: "mr" instruction is unnecessary when extending DI
to V1TI
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guihaoc at gcc dot gnu.org
  Target Milestone: ---

//test.c
vector __int128 init (long long a)
{
  vector __int128 b;
  b = (vector __int128) {a};
  return b;
}

gcc -O2 -s test.c -mcpu=power9

//p9 assembly
mr 10,3
sradi 11,3,63
mtvsrdd 34,11,10

The first mr is unnecessary if the last one is changed to "mtvsrdd 34,11,3".

[Bug target/103124] PPC: "mr" instruction is unnecessary when extending DI to V1TI

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/103124] PPC: "mr" instruction is unnecessary when extending DI to V1TI

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

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

--- Comment #1 from HaoChen Gui  ---
Build command gcc -O2 -S test.c -mcpu=power9

[Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Kewen Lin :

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

commit r9-9815-g6cce26752d8431a1ef6d3f9a97fa0ee2e9f96816
Author: Kewen Lin 
Date:   Mon Oct 25 21:05:02 2021 -0500

vect: Don't update inits for simd_lane_access DRs [PR102789]

As PR102789 shows, when vectorizer does some peelings for alignment
in prologues, function vect_update_inits_of_drs would update the
inits of some drs.  But as the failed case, we shouldn't update the
dr for simd_lane_access, it has the fixed-length storage mainly for
the main loop, the update can make the access out of bound and access
the unexpected element.

gcc/ChangeLog:

PR tree-optimization/102789
* tree-vect-loop-manip.c (vect_update_inits_of_drs): Do not
update inits of simd_lane_access.

(cherry picked from commit f3dbd3f36d55178d0a9e4431043cbc950524969a)

[Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:4f024c99a05f1c6852d1e5daad4a172f4cdd24a1

commit r10-10257-g4f024c99a05f1c6852d1e5daad4a172f4cdd24a1
Author: Kewen Lin 
Date:   Mon Oct 25 21:05:02 2021 -0500

vect: Don't update inits for simd_lane_access DRs [PR102789]

As PR102789 shows, when vectorizer does some peelings for alignment
in prologues, function vect_update_inits_of_drs would update the
inits of some drs.  But as the failed case, we shouldn't update the
dr for simd_lane_access, it has the fixed-length storage mainly for
the main loop, the update can make the access out of bound and access
the unexpected element.

gcc/ChangeLog:

PR tree-optimization/102789
* tree-vect-loop-manip.c (vect_update_inits_of_drs): Do not
update inits of simd_lane_access.

(cherry picked from commit f3dbd3f36d55178d0a9e4431043cbc950524969a)

[Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:7cb3b868f702e63e53ee1880c6b8a61676144395

commit r11-9219-g7cb3b868f702e63e53ee1880c6b8a61676144395
Author: Kewen Lin 
Date:   Mon Oct 25 21:05:02 2021 -0500

vect: Don't update inits for simd_lane_access DRs [PR102789]

As PR102789 shows, when vectorizer does some peelings for alignment
in prologues, function vect_update_inits_of_drs would update the
inits of some drs.  But as the failed case, we shouldn't update the
dr for simd_lane_access, it has the fixed-length storage mainly for
the main loop, the update can make the access out of bound and access
the unexpected element.

gcc/ChangeLog:

PR tree-optimization/102789
* tree-vect-loop-manip.c (vect_update_inits_of_drs): Do not
update inits of simd_lane_access.

(cherry picked from commit f3dbd3f36d55178d0a9e4431043cbc950524969a)

[Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

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

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

Kewen Lin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #15 from Kewen Lin  ---
Thanks for both replies!  Backported and bootstrapped on active branches
9/10/11.

[Bug rtl-optimization/103125] New: [ARM]Useless stack initialization on aarch64 big-endian

[dongjianqiang2 at huawei dot com via Gcc-bugs]

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

Bug ID: 103125
   Summary: [ARM]Useless stack initialization on aarch64
big-endian
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dongjianqiang2 at huawei dot com
  Target Milestone: ---

demo:

typedef struct {
int a;
} S;

void foo(S s)
{
return;
}

compile with gcc demo.c -mbig-endian -O2 -S

output:

foo:
sub sp, sp, #16
add sp, sp, 16
ret

I think the function must not use the stack, just like compiling with LLVM. is
this gcc bug? 
https://gcc.godbolt.org/z/r35a3PbxE

[Bug rtl-optimization/103125] stack adjustment with struct with int element on aarch64be-*-*

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-08
Summary|Useless stack   |stack adjustment with
   |initialization on aarch64   |struct with int element on
   |big-endian  |aarch64be-*-*
   Severity|normal  |enhancement
 Blocks||101926
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed, There are other bugs related to this too.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
[Bug 101926] [meta-bug] struct/complex argument passing and return should be
improved

[Bug middle-end/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526

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

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

--- Comment #5 from Aldy Hernandez  ---
(In reply to Christophe Lyon from comment #4)
> If I'm not mistaken, if you click on "REGRESSED" for that specific line,
> you'll see that only ssa-dom-thread-7.c actually regressed with the
> corresponding flags.
> 
> For ivopts-4.c, if seems you need -mthumb and one of these values for -march:
> armv7-a+mp+sec+neon-fp16
> armv7ve+simd
> armv7-a+mp+sec+vfpv3-d16-fp16
> armv8-a+crc+simd+crypto
> (possibly with -mfpu=auto)
> or -march=armv8-a -mfpu=crypto-neon-fp-armv8

Works for:
-Os -fdump-tree-ivopts -save-temps -S  -march=armv8-a
-mfpu=crypto-neon-fp-armv8
-Os -fdump-tree-ivopts -save-temps -S -mthumb -march=armv8-a
-mfpu=crypto-neon-fp-armv8
-Os -fdump-tree-ivopts -save-temps -S -mthumb -march=armv7ve+simd -mfpu=auto

Similarly for ssa-dom-thread-7.c.

Perhaps someone else can reproduce.

And just to be clear, it would be easier if someone could reproduce with a cc1
/ gcc command line, and not by pointing us to some table in a web page.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

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

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

--- Comment #11 from Aldy Hernandez  ---
>From what I gather, this is only reproducible with PGO.  If so, it may be worth
nothing that Jeff has mentioned that the backward threader probably does not do
a very good job with keeping profile counts up to date:

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576437.html

The compute_path_counts function he mentions above is not even used by the
generic copier used by the backward threader, and currently all the threaders
with the exception of DOM are using the backward threader.

That being said, the commit this PR bisects to is not adding more threads, but
invalidating some.  Note the invalidation code works for all threaders, not
just the back threader.

This may have nothing to do with the issue at hand, but I thought it worth
mentioning.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

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

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

--- Comment #12 from Aldy Hernandez  ---
It's been mentioned that this SPEC test has irreconcilable differences between
the train and peak runs, and cannot be reasonably compared.  Is the slowdown
reported between two runs of compatible runs (two of the train data or two of
the peak data)?

[Bug middle-end/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526

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

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

--- Comment #6 from Christophe Lyon  ---
(In reply to Aldy Hernandez from comment #5)
> (In reply to Christophe Lyon from comment #4)
> > If I'm not mistaken, if you click on "REGRESSED" for that specific line,
> > you'll see that only ssa-dom-thread-7.c actually regressed with the
> > corresponding flags.
> > 
> > For ivopts-4.c, if seems you need -mthumb and one of these values for 
> > -march:
> > armv7-a+mp+sec+neon-fp16
> > armv7ve+simd
> > armv7-a+mp+sec+vfpv3-d16-fp16
> > armv8-a+crc+simd+crypto
> > (possibly with -mfpu=auto)
> > or -march=armv8-a -mfpu=crypto-neon-fp-armv8
> 
> Works for:
> -Os -fdump-tree-ivopts -save-temps -S  -march=armv8-a
> -mfpu=crypto-neon-fp-armv8
> -Os -fdump-tree-ivopts -save-temps -S -mthumb -march=armv8-a
> -mfpu=crypto-neon-fp-armv8
> -Os -fdump-tree-ivopts -save-temps -S -mthumb -march=armv7ve+simd -mfpu=auto
> 
> Similarly for ssa-dom-thread-7.c.
> 
> Perhaps someone else can reproduce.

It fails for me with:
cc1 -fpreprocessed ivopts-4.i -quiet -dumpbase ivopts-4.c -dumpbase-ext .c
-mthumb -mfloat-abi=hard -mfpu=neon -mtls-dialect=gnu
-mlibarch=armv7-a+mp+sec+neon-fp16 -march=armv7-a+mp+sec+neon-fp16 -Os -version
-fdiagnostics-color=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-urls=never
-fdiagnostics-path-format=separate-events -fdump-tree-ivopts -o ivopts-4.s


the main compilation line is:
arm-none-linux-gnueabihf-gcc -mthumb -march=armv7-a+mp+sec+neon-fp16
-fdiagnostics-plain-output -Os -fdump-tree-ivopts -save-temps -c -o ivopts-4.o
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/fixes/gcc/testsuite/gcc.target/arm/ivopts-4.c
then size ivopts-4.o:
   textdata bss dec hex filename
 38   0   0  38  26 ivopts-4.o
where the testcase expects text <= 36

My GCC is configured with --with-float=hard --with-cpu=cortex-a9
--with-fpu=neon --with-mode=arm

>
> And just to be clear, it would be easier if someone could reproduce with a
> cc1 / gcc command line, and not by pointing us to some table in a web page.

Sorry, these automated validations builds are deleted after the reports are
generated,
so it's not really easier for me to manually reproduce than for anyone else.