[Bug tree-optimization/103257] [9/10/11/12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/584677.html

--- Comment #8 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584677.html

[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt

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

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

--- Comment #12 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r12-5333-g1a15a91a0015208eafb797e4de1348c9877fd6d0
Author: Andrew Pinski 
Date:   Tue Nov 16 23:37:08 2021 +

Fix PR 103288, ICE after PHI-OPT, move an assigment when still in use for
another bb

The problem is r12-5300-gf98f373dd822b35c allows phiopt to recognize more
basic blocks
but missed one location where phiopt could move an assignment from the
middle block
to the non-middle one.  This patch fixes that.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/103288

gcc/ChangeLog:

* tree-ssa-phiopt.c (value_replacement): Return early if middle
block has more than one pred.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/pr103288-1.c: New test.

[Bug tree-optimization/103288] [12 Regression] ice during GIMPLE pass: phiopt

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Fixed.

[Bug ipa/103243] [12 regression] pr98499.C fails after r12-5203

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

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

Jan Hubicka  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-17
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #2 from Jan Hubicka  ---
will have a look

[Bug lto/102426] [12 regression] Fix for PR 49664 breaks Solaris bootstrap with gld

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

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Jan Hubicka  ---
note that same error happens on older x86_64-linux debian boxes.

[Bug tree-optimization/102880] [12 Regression] Dead Code Elimination Regression at -O3

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #10 from Christophe Lyon  ---
After r12-5301, on aarch64 I can see:
FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread2 "Jumps
threaded: 18"

[Bug lto/102426] [12 regression] Fix for PR 49664 breaks Solaris bootstrap with gld

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jan Hubicka from comment #5)
> note that same error happens on older x86_64-linux debian boxes.

That has to be a totally different issue from here. This is specificially about
solaris specific code in libtool.

[Bug tree-optimization/103298] New: [12 regressions] regressions on arm after r12-5301

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

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

Bug ID: 103298
   Summary: [12 regressions] regressions on arm after r12-5301
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

r12-5301 is causing regressions on some arm targets:

arm-none-linux-gnueabi -march=armv7-a -mthumb:
FAIL: gcc.target/arm/pr42093.c scan-assembler-not tbb
FAIL: gcc.target/arm/pr43920-2.c object-size text <= 54

arm-none-linux-gnueabi -march=armv5t -mthumb:
FAIL: gcc.dg/tree-ssa/if-to-switch-3.c scan-tree-dump iftoswitch "Condition
chain with [^\n\r]* BBs transformed into a switch statement."

[Bug tree-optimization/102880] [12 Regression] Dead Code Elimination Regression at -O3

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Christophe Lyon from comment #10)
> After r12-5301, on aarch64 I can see:
> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread2 "Jumps
> threaded: 18"

Yes it looks like Richard forgot to adjust the testcase for aarch64

[Bug tree-optimization/103298] [12 regressions] regressions on arm after r12-5301

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

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

--- Comment #1 from Andrew Pinski  ---
(In reply to Christophe Lyon from comment #0) 
> arm-none-linux-gnueabi -march=armv5t -mthumb:
> FAIL: gcc.dg/tree-ssa/if-to-switch-3.c scan-tree-dump iftoswitch "Condition
> chain with [^\n\r]* BBs transformed into a switch statement."

PR 103278.

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

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #6 from Jürgen Reuter  ---
(In reply to Thomas Koenig from comment #5)
> I can confirm the ICE with current trunk both on x86_64 and
> on POWER.
> 
> x86_64:
> 
> $ gfortran -v
> Es werden eingebaute Spezifikationen verwendet.
> COLLECT_GCC=gfortran
> COLLECT_LTO_WRAPPER=/home/ig25/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-
> wrapper
> Ziel: x86_64-pc-linux-gnu
> Konfiguriert mit: ../trunk/configure --prefix=/home/ig25
> --enable-languages=c,c++,fortran --enable-maintainer-mode
> Thread-Modell: posix
> Unterstützte LTO-Kompressionsalgorithmen: zlib
> gcc-Version 12.0.0 2026 (experimental) [master revision
> e87559d202d:f4e6da6e8ac:36ec54aac7da134441c83248e14825381b8d6f17] (GCC) 
> $ gfortran a.f90 
> a.f90:10:13:
> 
>10 | ]
>   | 1
> interner Compiler-Fehler: tree check: expected integer_cst, have save_expr
> in gfc_trans_array_constructor_value, at fortran/trans-array.c:2187
> 0x808a8a tree_check_failed(tree_node const*, char const*, int, char const*,
> ...)
> ../../trunk/gcc/tree.c:8701
> 
> POWER:
> 


Really interesting, I don't get an ICE with the following setup:
../configure --prefix=/usr/local/ --with-gmp=/usr/local/
--with-mpfr=/usr/local/ --with-mp=/usr/local/
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/
--enable-checking=release --enable-languages=c,c++,fortran,lto,objc,obj-c++
$ gfortran --version
GNU Fortran (GCC) 12.0.0 2025 (experimental)
Maybe the enable-checking setup!?

I am compiling without any flags the code snippet in the very first post in
this PR.

[Bug c++/103299] New: accessing incorrect storage for union at constexpr context

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 103299
   Summary: accessing incorrect storage for union at constexpr
context
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

struct compile_time_fp
{
void* ct_fp{};
};

struct foo
{
union
{
void* fp{};
compile_time_fp ct_fp;
};
};

inline constexpr foo foo_factory()
{
if (__builtin_is_constant_evaluated())
{
return {.ct_fp={}};
}
else
{
return {};
}
}

constexpr bool test_direct_construction()
{
foo f{.ct_fp={}};
f.ct_fp;
return true;
}


constexpr bool test_factory_construction()
{
foo_factory().ct_fp;
return true;
}
static_assert(test_direct_construction());
static_assert(test_factory_construction());//should not fail


GCC fails for the 2nd one while msvc and clang all accept the code here.

[Bug ipa/103246] [12 Regression] 416.gamess miscompare with -O2 -g -flto=auto since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e

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

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

--- Comment #13 from Martin Liška  ---
(In reply to Jan Hubicka from comment #11)
> Thanks for reducing the testcase.
> I found the reason for build difference.  There is misplaced code clearing
> to_info_lto. 

Thanks! Great you found it so quickly.

[Bug tree-optimization/88542] Optimize symmetric range check

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Richard Biener from comment #3)
> not sure why that only happens in the last phiopt pass.  Ah, because
> the main phiopt pass sees the following:
> 
>[local count: 1073741825]:
>   if (d_3(D) < max_4(D))
> goto ; [50.00%]
>   else
> goto ; [50.00%]
> 
>[local count: 536870912]:
>   _1 = -max_4(D);
>   if (_1 < d_3(D))
> goto ; [50.00%]
>   else
> goto ; [50.00%]
> 
>[local count: 805306368]:
> 
>[local count: 1073741825]:
>   # iftmp.0_2 = PHI <1(3), 0(4)>

The above issue of not doing the phiopt early was solved finally by
r12-5300-gf98f373dd822b35c.

[Bug tree-optimization/89018] common subexpression present in both branches of condition is not factored out

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Andrew Pinski  ---
Mine, I think there are a few other bugs for the same thing.

[Bug ipa/103246] [12 Regression] 416.gamess miscompare with -O2 -g -flto=auto since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e

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

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

--- Comment #14 from hubicka at kam dot mff.cuni.cz ---
> Thanks! Great you found it so quickly.
It is bit stupid code since everything is duplicated twice (for LTO and
non-LTO). I have to refactor it: we could have common base of the two
summaries and handle most of things in unified way. The problem is that
gengtype does not like it, so it will probably need manual GGC
annotations.

It stil leaves us with a wrong code, right?

[Bug tree-optimization/95729] Failure to optimize away certain returns when the condition to reach them is a calculation that already results in that value

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Andrew Pinski  ---
;; a != b ? a - b : 0
Something like:
(simplify
 (cond (ne:c @0 @1) (minus@2 @0 @1) zero_p)
 (if (!HONOR_NANS (type) && !HONOR_SIGNED_ZEROS (type))
 @2)
(simplify
 (cond (eq:c @0 @1) zero_p (minus@2 @0 @1))
 (if (!HONOR_NANS (type) && !HONOR_SIGNED_ZEROS (type))
 @2)

Note I noticed LLVM 13 no longer does this optimization (I wonder if they have
a testsuite).

[Bug tree-optimization/102981] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

--- Comment #6 from Aldy Hernandez  ---
This looks like a class of problems we could easily get if we wanted.  The
pattern is:

PREHEADER
|
|
V
  HEADER --> LOOPEXIT
|
|
V
   SUCC
|  \
|   \
   DEAD  \
 |   /
 |  /
 | v
   XX

On the PREHEADER->HEADER->SUCC path we want to know if the edge out of SUCC can
be statically determined.  The threader can't do this for a number of reasons. 
First, we'd be essentially peeling an iteration.  Second, IIUC, we'd be
rotating the loop.

However, there's no reason we can't catch this in a loop optimizer like we did
with the loopch pass.  This is the exact type of problem that is trivially
handled by the path solver, which is quite cheap when you don't have to do full
path discovery like the threader has to do.

Something like:

gimple *control = gimple_outgoing_range_stmt_p (succ);
if (control) {
  auto_vec bbs (3);
  bbs.quick_push (preheader);
  bbs.quick_push (header);
  bbs.quick_push (succ);

  int_range<2> r;
  path_range_query query;
  query.compute_ranges (bbs);
  query.range_of_stmt (r, control);
  if (r == desired_static_value...)
peel();
...
}

If "dead code on the first iteration" is something we want to handle, I could
help with the ranger bits if someone gives me a hand with the loop bits.

[Bug libstdc++/103295] constexpr std::string does not work for clang

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

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

--- Comment #7 from Jonathan Wakely  ---
The code can be reduced to this, which GCC, EDG and MSVC all accept, but Clang
doesn't:

struct S
{
  union {
char buf[8];
char* ptr;
  };
  unsigned len;

  constexpr S(const char* s, unsigned n)
  {
char* p;
if (n > 7)
  p = ptr = new char[n];
else
  p = buf;
for (len = 0; len < n; ++len)
  p[len] = s[len];
p[len] = '\0';
  }

  constexpr ~S()
  {
if (len > 7)
  delete[] ptr;
  }
};

constexpr bool test()
{
  S s("test", 4);
  return true;
}

static_assert( test() );


Clang accepts it if written like this:

  constexpr S(const char* s, unsigned n)
  {
if (n > max_size())
{
  ptr = new char[n];
  for (len = 0; len < n; ++len)
ptr[len] = s[len];
  ptr[len] = '\0';
}
else
{
  for (len = 0; len < n; ++len)
buf[len] = s[len];
  buf[len] = '\0';
}
  }

It just doesn't allow assignment through the pointer.

[Bug tree-optimization/58195] Missed optimization opportunity when returning a conditional

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Mine,  After PR 25290, the below match.pd pattern will just work :).
> 
> (In reply to Marc Glisse from comment #3) 
> > and something that could be auto-generated from a pattern like:
> > (cond (ne @0 0) (negate @0) 0) -> (negate @0)

Actually that was implemented with r12-2041.

It is just the loop that is left.  We do get the optimization if we use -fwrapv
:).

I will handle the loop one for GCC 13.

[Bug libstdc++/103295] constexpr std::string does not work for clang

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

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

--- Comment #8 from Jonathan Wakely  ---
Which means this is enough to make Clang happy for the comment 0 example:

--- a/libstdc++-v3/include/bits/basic_string.tcc
+++ b/libstdc++-v3/include/bits/basic_string.tcc
@@ -167,6 +167,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _M_construct(_InIterator __beg, _InIterator __end,
   std::input_iterator_tag)
   {
+#if __cpp_lib_is_constant_evaluated
+   if (__builtin_is_constant_evaluated())
+ _M_local_buf[0] = _CharT();
+#endif
+
size_type __len = 0;
size_type __capacity = size_type(_S_local_capacity);

@@ -223,6 +228,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_data(_M_create(__dnew, size_type(0)));
_M_capacity(__dnew);
  }
+#if __cpp_lib_is_constant_evaluated
+   else if (__builtin_is_constant_evaluated())
+ _M_local_buf[0] = _CharT();
+#endif

// Check for out_of_range and length_error exceptions.
__try
@@ -247,6 +256,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _M_data(_M_create(__n, size_type(0)));
  _M_capacity(__n);
}
+#if __cpp_lib_is_constant_evaluated
+   else if (__builtin_is_constant_evaluated())
+ _M_local_buf[0] = _CharT();
+#endif

   if (__n)
this->_S_assign(_M_data(), __n, __c);

[Bug libstdc++/103295] constexpr std::string does not work for clang

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #9 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #8)
> Which means this is enough to make Clang happy for the comment 0 example:
> 
> --- a/libstdc++-v3/include/bits/basic_string.tcc
> +++ b/libstdc++-v3/include/bits/basic_string.tcc
> @@ -167,6 +167,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>_M_construct(_InIterator __beg, _InIterator __end,
>std::input_iterator_tag)
>{
> +#if __cpp_lib_is_constant_evaluated
> +   if (__builtin_is_constant_evaluated())
> + _M_local_buf[0] = _CharT();
> +#endif
> +
> size_type __len = 0;
> size_type __capacity = size_type(_S_local_capacity);
>  
> @@ -223,6 +228,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> _M_data(_M_create(__dnew, size_type(0)));
> _M_capacity(__dnew);
>   }
> +#if __cpp_lib_is_constant_evaluated
> +   else if (__builtin_is_constant_evaluated())
> + _M_local_buf[0] = _CharT();
> +#endif
>  
> // Check for out_of_range and length_error exceptions.
> __try
> @@ -247,6 +256,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   _M_data(_M_create(__n, size_type(0)));
>   _M_capacity(__n);
> }
> +#if __cpp_lib_is_constant_evaluated
> +   else if (__builtin_is_constant_evaluated())
> + _M_local_buf[0] = _CharT();
> +#endif
>  
>if (__n)
> this->_S_assign(_M_data(), __n, __c);

where can i download EDG??

[Bug libstdc++/103295] constexpr std::string does not work for clang

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

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

--- Comment #10 from Jonathan Wakely  ---
(Do you really need to quote the whole of comment 9 to reply to comment 8?)

You can't, it's not freely available.

[Bug tree-optimization/49959] ABS pattern is not recognized

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

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

--- Comment #4 from Andrew Pinski  ---
Note Pre is able to remove the casts since GCC 8.
So the original testcase is fixed but if you change it to:
#define ABS(X)(((X)>0)?(X):-(X))
unsigned long
test_abs(int *cur)
{
  unsigned long sad = 0;
  sad += ABS(cur[0]);
  return sad;
}

We still have the same issue as before.

[Bug libgomp/103276] [openacc] Trying to map already mapped data

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

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

--- Comment #4 from Yury Gribov  ---
(In reply to Andrew Pinski from comment #3)
> No the gimple is wrong.  &var is taking the address of the argument. It
> should just be var here if you what the reference points to rather than the
> address of the decl holding the pointer.

Thank you, makes sense. In that case the problem occurs at OMP lowering:
  voidD.27 copyin_simple (struct simple & restrict varD.3961)
  {
var.0_1 = varD.3961;
{
  D.3965.D.3963 = var.0_1;
  D.3965.varD.3964 = &varD.3961;
  #pragma omp target oacc_enter_exit_data map(to:*var.0_1 [len: 8])
map(alloc:varD.3961 [pointer assign, bias: 0])

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

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 103300
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression.

[596] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 2027 (experimental) [master r12-5333-g1a15a91a001] (GCC) 
[597] % 
[597] % gcctk -O2 small.c; ./a.out
[598] % 
[598] % gcc110 -O3 small.c; ./a.out
[599] % 
[599] % gcctk -O3 small.c
[600] % ./a.out
Aborted
[601] % 
[601] % cat small.c
int a, b[2], c, d, e, f;
int g(int h, int i) { return !i || h && i == 1 ? 0 : h % i; }
void j() {
  while (1)
while (1) {
  if (d)
  L:
if (f)
  break;
  if (e)
goto L;
  return;
}
}
int main() {
  j();
  for (c = 0; c < 3; c++)
for (a = 0; a < 2; a++)
  if (g(0, b[a]++))
while (1)
  ;
  if (b[1] != 3)
__builtin_abort();
  return 0;
}

[Bug libgomp/103276] [openacc] Trying to map already mapped data

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

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

--- Comment #5 from Yury Gribov  ---
Created attachment 51823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51823&action=edit
Runnable reprocase

I've attached another reprocase which reproduces the error at runtime (but let
me reiterate that the original minirepro is easier to analyze). It can be
compiled with
  /home/y.gribov/install/gcc-master/usr/local/bin/gfortran repro.f90 -O2
-ffree-form -fopenacc -foffload-options=-march=gfx908
It crashes at runtime with
  libgomp: Trying to map into device [0x7fffd8d0..0x7fffd928) object
when [0x7fffd918..0x7fffd920) is already mapped

Problem reproduces both on devel/omp/gcc-11 (commit f85ed229, Nov 10) and
master (commit 0136f25a, Nov 10).

[Bug tree-optimization/103300] [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=103300

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection, wrong-code
   Last reconfirmed||2021-11-17
 Ever confirmed|0   |1
   Target Milestone|--- |12.0
Summary|wrong code at -O3 on|[12 Regression] wrong code
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu

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

[Bug fortran/97896] [11/12 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #14 from Mikael Morin  ---
Fixed for 11.3 and 12.1.
Closing.

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

[Jan Hubicka via Gcc-bugs]

Needs -O2  -floop-unroll-and-jam   --param early-inlining-insns=14
to fail, so I guess it may be issue with unrol-and-jam.

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

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

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

--- Comment #2 from hubicka at kam dot mff.cuni.cz ---
Needs -O2  -floop-unroll-and-jam   --param early-inlining-insns=14
to fail, so I guess it may be issue with unrol-and-jam.

[Bug fortran/103301] New: co_broadcast: broadcast of an object of a derived type with custom assignment operator defined

[xavier.daura at uab dot cat via Gcc-bugs]

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

Bug ID: 103301
   Summary: co_broadcast: broadcast of an object of a derived type
with custom assignment operator defined
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xavier.daura at uab dot cat
  Target Milestone: ---

Before making a full report, I'd like to specify first the case, since I am not
sure whether gfortran should be able to handle this.

According to the Fortran 2018 ISO, the first argument to co_broadcast "shall
have the same shape, dynamic type, and type parameter values, in corresponding
references. It shall not be a coindexed object. [...]  If no error condition
occurs, A becomes defined, as if by intrinsic assignment, on all images [...]"

Similarly, according to the gfortran 11.2.0 manual it "shall have the same dy-
namic type and type parameters on all images of the current team. If it is an
array, it shall have the same shape on all images."

My understanding (but I may well be wrong) is that neither description excludes
objects of a derived type with non-coarray components. I also understand that
for this to work on an object, the corresponding derived type needs to have a
custom assignment operator defined.

The program in question fails to compile producing an internal compiler error
at: call co_broadcast(sys_cnf, 1), where sys_cnf is such an object.

If this is not supposed to work, there is nothing else to say, but I guess the
compiler should say so instead of giving an internal compiler error and asking
to submit a bug report. Otherwise, if it is supposed to work, I'll be happy to
complement the information given here with the preprocessed code so that the
problem can be sorted out.

System:
CentOS 8, kernel 5.15.2-1.el8.elrepo.x86_64

Compiler details:
caf : opencoarrays 2.9.2
gfortran : gcc 11.2.0

Configuration at installation:
gcc : path_to_gcc-11.2.0/configure --enable-languages=fortran
--disable-multilib
opencoarrays : FC=path_to_gfortran-11.2.0 cmake path_to_OpenCoarrays-2.9.2

Compilation instruction and error:
caf -c  -std=f2018 -g -O0 -fcheck=all -fbacktrace -Jmod src/prg_nrgmin.f90 -o
obj/prg_nrgmin.o   
src/prg_nrgmin.f90:78:32:   

   78 |call co_broadcast(sys_cnf, 1)
  |1
internal compiler error: in gfc_get_descriptor_field, at
fortran/trans-array.c:140   
0x618734 gfc_get_descriptor_field
../../gcc-11.2.0/gcc/fortran/trans-array.c:140
0x760585 gfc_get_descriptor_dimension(tree_node*)
../../gcc-11.2.0/gcc/fortran/trans-array.c:294
0x760585 gfc_conv_descriptor_dimension
../../gcc-11.2.0/gcc/fortran/trans-array.c:306
0x760585 gfc_conv_descriptor_subfield
../../gcc-11.2.0/gcc/fortran/trans-array.c:326
0x76a60e gfc_conv_descriptor_ubound
../../gcc-11.2.0/gcc/fortran/trans-array.c:390
0x76a60e gfc_conv_descriptor_ubound_get(tree_node*, tree_node*)
../../gcc-11.2.0/gcc/fortran/trans-array.c:398
0x76a60e gfc_full_array_size(stmtblock_t*, tree_node*, int)
../../gcc-11.2.0/gcc/fortran/trans-array.c:8345
0x7708c2 structure_alloc_comps
../../gcc-11.2.0/gcc/fortran/trans-array.c:8853
0x775947 gfc_bcast_alloc_comp(gfc_symbol*, gfc_expr*, int, tree_node*,
tree_node*, tree_node*, tree_node*)  
../../gcc-11.2.0/gcc/fortran/trans-array.c:9836
0x7b3a11 conv_co_collective
../../gcc-11.2.0/gcc/fortran/trans-intrinsic.c:11344
0x7b3a11 gfc_conv_intrinsic_subroutine(gfc_code*)
../../gcc-11.2.0/gcc/fortran/trans-intrinsic.c:12471
0x75bef2 trans_code
../../gcc-11.2.0/gcc/fortran/trans.c:1991
0x785b69 gfc_generate_function_code(gfc_namespace*)
../../gcc-11.2.0/gcc/fortran/trans-decl.c:6893
0x7015ae translate_all_program_units
../../gcc-11.2.0/gcc/fortran/parse.c:6354
0x7015ae gfc_parse_file()
../../gcc-11.2.0/gcc/fortran/parse.c:6623
0x7590ef gfc_be_parse_file
../../gcc-11.2.0/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Error: comand:
   `/usr/local/bin/gfortran -I/usr/local/include/OpenCoarrays-2.9.2_GNU-11.2.0
-fcoarray=lib -pthread -c -std=f2018 -g -O0 -fcheck=all -fbacktrace -Jmod
src/prg_nrgmin.f90 -o obj/prg_nrgmin.o`
failed to compile.
make: *** [Makefile:85: obj/prg_nrgmin.o] Error 1

[Bug ipa/103243] [12 regression] pr98499.C fails after r12-5203

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

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

--- Comment #3 from Jan Hubicka  ---
Does not reproduce for me on aarch64 (gcc114 from the compile farm)
jh@gcc114:~/trunk/build2/gcc$ ./xgcc -B ./ --version
xgcc (GCC) 12.0.0 2027 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
jh@gcc114:~/trunk/build2/gcc$ make  -k check-gcc
RUNTESTFLAGS="dg.exp=g++.dg/pr98499.C"
Making a new config file...
echo "set tmpdir /home/jh/trunk/build2/gcc/testsuite" >> ./site.tmp
rm -rf testsuite/gcc-parallel
make[1]: Entering directory `/home/jh/trunk/build2/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc; ${PWDCMD-pwd}` ; export srcdir ; \
if [ -n "" ] \
   && [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
   && [ -f testsuite/gcc-parallel/finished ]; then \
  rm -rf testsuite/gcc; \
else \
  cd testsuite/gcc; \
  rm -f tmp-site.exp; \
  sed '/set tmpdir/ s|testsuite$|testsuite/gcc|' \
< ../../site.exp > tmp-site.exp; \
  /bin/bash ${srcdir}/../move-if-change tmp-site.exp site.exp; \
  EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
  if [ -f ${rootme}/../expect/expect ] ; then  \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ;
\
export TCL_LIBRARY ; \
  fi ; \
  `if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc
dg.exp=g++.dg/pr98499.C; \
  if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch ${rootme}/testsuite/gcc-parallel/finished; \
  fi ; \
fi )
Test Run By jh on Wed Nov 17 03:10:42 2021
Native configuration is aarch64-unknown-linux-gnu

=== gcc tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/jh/trunk/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /home/jh/trunk/gcc/testsuite/gcc.dg/dg.exp ...

=== gcc Summary ===

/home/jh/trunk/build2/gcc/xgcc  version 12.0.0 2027 (experimental) (GCC) 

make[1]: Leaving directory `/home/jh/trunk/build2/gcc'


Can you, please, post -fdump-tree-all-details -fdump-ipa-all-details files?

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

--- Comment #4 from Aldy Hernandez  ---
It's been a LONG time since I had to do a sim build, so please bear with me.

I have combined tree with  gcc, binutils-gdb, dejagnu, newlib-cygwin:

~/src/combined/configure --target=bfin-elf --enable-languages=c,c++
--with-newlib --prefix=`pwd`/install

C++ won't build:
In file included from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bits/locale_facets.h:41,
 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bits/basic_ios.h:37,
 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/ios:44,
 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/istream:38,
 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/sstream:38,
 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/complex:45,
 from
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/ccomplex:39,
 from
/home/aldyh/src/combined/libstdc++-v3/include/precompiled/stdc++.h:54:
/home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bfin-elf/bits/ctype_base.h:44:35:
error: ‘_U’ was not declared in this scope
   44 | static const mask upper = _U;
  |   ^~
...
...

So I tried --enable-languages=c which builds, but in-tree testing doesn't work:

(DEJAGNU is set to the provided baseboard file.)

make check-gcc RUNTESTFLAGS="--target_board=basic-sim dg.exp=pr80974.c"

bf532-none/mid-shared-library/mleaf-id-shared-library;@mcpu=bf532-none@mid-shared-library@mleaf-id-shared-library
Executing on host: /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/  -fdiagnostics-plain-output  -flto -c -o
lto3625067.o lto3625067.c(timeout = 300)
spawn -ignore SIGHUP /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/ -fdiagnostics-plain-output -flto -c -o
lto3625067.o lto3625067.c
Executing on host: /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/ linker_plugin3625067.c 
-fdiagnostics-plain-output  -flto -fuse-linker-plugin  -lm  -o
linker_plugin3625067.exe(timeout = 300)
spawn -ignore SIGHUP /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/ linker_plugin3625067.c
-fdiagnostics-plain-output -flto -fuse-linker-plugin -lm -o
linker_plugin3625067.exe
xgcc: error: no processor type specified for linking
xgcc: fatal error: error in arguments to spec function 'pass-through-libs'
compilation terminated.
compiler exited with status 1
Executing on host: /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/ offload_gcn3625067.c 
-fdiagnostics-plain-output  -foffload=amdgcn-amdhsa -S -o offload_gcn3625067.s 
  (timeout = 300)
spawn -ignore SIGHUP /opt/notnfs/aldyh/bld/bfin-elf/gcc/xgcc
-B/opt/notnfs/aldyh/bld/bfin-elf/gcc/ offload_gcn3625067.c
-fdiagnostics-plain-output -foffload=amdgcn-amdhsa -S -o offload_gcn3625067.s
xgcc: error: GCC is not configured to support 'amdgcn-amdhsa' as offload target
xgcc: note: no offloading targets configured
compiler exited with status 1

I also tried --target_board=[bfin,bfin-elf,sim,bfin-sim], but those give:

ERROR: couldn't load description file for bfin-sim

With an installed toolchain, I get a similar linking problem:

$ ./bfin-elf-gcc hello.c -w
bfin-elf-gcc: error: no processor type specified for linking
bfin-elf-gcc: fatal error: error in arguments to spec function
‘pass-through-libs’
compilation terminated.

I tried a few random cpu's from config/bfin/elf.h:

 ./bfin-elf-gcc -mcpu=bf549 hello.c -w
/opt/notnfs/aldyh/bld/bfin-elf/install/bin/../lib/gcc/bfin-elf/12.0.0/../../../../bfin-elf/bin/ld:
/opt/notnfs/aldyh/bld/bfin-elf/install/bin/../lib/gcc/bfin-elf/12.0.0/../../../../bfin-elf/
lib/libc.a(lib_a-closer.o): in function `close_r':
/home/aldyh/src/combined/newlib/libc/reent/closer.c:47: warning: _close is not
implemented and will always fail
/opt/notnfs/aldyh/bld/bfin-elf/install/bin/../lib/gcc/bfin-elf/12.0.0/../../../../bfin-elf/bin/ld:
/opt/notnfs/aldyh/bld/bfin-elf/install/bin/../lib/gcc/bfin-elf/12.0.0/../../../../bfin-elf/
lib/libc.a(lib_a-fstatr.o): in function `fstat_r':
etc
etc.

Hmmm, maybe I should just look at the *.optimized dump and see what's up ;-).

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

--- Comment #5 from Aldy Hernandez  ---
FWIW, the *.ch2 dump on both x86-64 and bfin-elf are identical.

This is unlikely to help, but...

In *.ivopts we start seeing differences in the IL:

[local count: 60236916]:
   e = 1;
+  ivtmp.29_7 = (unsigned int) &g;
   goto ; [100.00%]

[local count: 60236916]:
@@ -593,7 +590,8 @@
 goto ; [50.00%]

[local count: 1625827684]:
-  MEM[(int *)&g + ivtmp.26_25 * 4] = 4;
+  _8 = (void *) ivtmp.29_25;
+  MEM[(int *)_8] = 4;

[local count: 3251655368]:
   ivtmp_15 = ivtmp_14 - 1;
@@ -603,8 +601,9 @@
 goto ; [14.29%]

[local count: 542132239]:
-  ivtmp.26_10 = ivtmp.26_25 + 1;
-  if (ivtmp.26_10 != 9)
+  h_11 = h_6 + 1;
+  ivtmp.29_10 = ivtmp.29_25 + 4;
+  if (h_11 != 9)
 goto ; [90.00%]
   else
 goto ; [10.00%]
@@ -612,7 +611,8 @@
[local count: 487919014]:

[local count: 542132239]:
-  # ivtmp.26_25 = PHI 
+  # h_6 = PHI 
+  # ivtmp.29_25 = PHI 
   goto ; [100.00%]

[Bug c++/103297] GCC cannot detect out of bounds in constexpr context.

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
Another issue

#include
#include
#include

inline constexpr std::string_view lifetime_detector(std::string const& str)
noexcept
{
return str;
}

inline constexpr bool test2(std::string_view vw2) noexcept
{
bool res{true};
for(auto e : vw2)
res|=e;
return true;
}

inline constexpr bool test() noexcept
{
std::string_view vw{lifetime_detector("abcde12124")};
return test2(vw);
}
static_assert(test());

int main()
{
assert(test());
}

This does not get detected at neither compile nor runtime???

[Bug c++/103297] GCC cannot detect out of bounds in constexpr context.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #2 from Jonathan Wakely  ---
These are two different bugs, and I think there are existing PRs about both of
them.

[Bug c++/103297] GCC cannot detect out of bounds in constexpr context.

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to cqwrteur from comment #0)
>   out_of_bounds_detector(buffer,buffer+7);//should give a hard error

This looks like PR 70151

(In reply to cqwrteur from comment #1)
>   std::string_view vw{lifetime_detector("abcde12124")};
>   return test2(vw);

This might be PR 70331

[Bug c++/82876] out-of-bounds pointer offset silently accepted in constexpr context

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/103297] GCC cannot detect out of bounds in constexpr context.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to cqwrteur from comment #0)
> > out_of_bounds_detector(buffer,buffer+7);//should give a hard error
> 
> This looks like PR 70151

Or its dependent, PR 82876



> (In reply to cqwrteur from comment #1)
> > std::string_view vw{lifetime_detector("abcde12124")};
> > return test2(vw);
> 
> This might be PR 70331

Or PR 89757 or PR 98675 or PR 96630

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

[Bug c++/70151] forming out of bounds constexpr pointer accepted

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #2 from Jonathan Wakely  ---
*** Bug 103297 has been marked as a duplicate of this bug. ***

[Bug libstdc++/103295] constexpr std::string does not work for clang

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

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #7)
> It just doesn't allow assignment through the pointer.

I think that's correct according to [class.union.general] p6:

"When the left operand of an assignment operator involves a member access
expression ([expr.ref]) that nominates a union member, it may begin the
lifetime of that union member, as described below."

`_M_local_buf[0] = 0;` is OK, but `auto p = _M_local_buf; p[0] = 0;` is not.

[Bug c++/102286] [constexpr] construct_at incorrectly starts union array lifetime in some cases

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98637
 Blocks||55004
   Last reconfirmed||2021-11-17
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #13 from Jakub Jelinek  ---
> Created attachment 51807
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51807&action=edit
> gcc12-pr102838-2.patch
>
> Does this patch fix it?

While the patch fixes all 32-bit x86 failures, it introduces ca. 230
execution failures for 64-bit (both x86 and sparc), all like

libgomp: Out of memory allocating 2656 bytes

e.g. for libgomp.c/single-1.c with this stack trace:

Thread 2 hit Breakpoint 1, gomp_fatal (fmt=fmt@entry=0x7fff57b183d8 "Out of
memory allocating %lu bytes") at
/vol/gcc/src/hg/master/local/libgomp/error.c:85
85  {
(gdb) where
#0  gomp_fatal (fmt=fmt@entry=0x7fff57b183d8 "Out of memory allocating %lu
bytes") at /vol/gcc/src/hg/master/local/libgomp/error.c:85
#1  0x7fff57b1b278 in gomp_aligned_alloc (al=al@entry=64,
size=size@entry=2656) at /vol/gcc/src/hg/master/local/libgomp/alloc.c:94
#2  0x7fff57b2e1eb in gomp_new_team (nthreads=nthreads@entry=3) at
/vol/gcc/src/hg/master/local/libgomp/team.c:181
#3  0x7fff57b25627 in GOMP_parallel_start (fn=0x401410 ,
data=0x0, num_threads=3) at /vol/gcc/src/hg/master/local/libgomp/parallel.c:133
#4  0x004014e6 in main ()

Running the test under truss shows this immediately before the error
message:

brk(0x) = 0x00501980
brk(0x00501980) = 0x
brk(0x00505980) = 0x

[Bug c++/102286] [constexpr] construct_at incorrectly starts union array lifetime in some cases

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

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

--- Comment #3 from Jonathan Wakely  ---
This code from PR 103295 is kinda related, which GCC, EDG and MSVC all accept,
but Clang doesn't:

struct S
{
  union {
char buf[8];
char* ptr;
  };
  unsigned len;

  constexpr S(const char* s, unsigned n)
  {
char* p;
if (n > 7)
  p = ptr = new char[n];
else
  p = buf;
for (len = 0; len < n; ++len)
  p[len] = s[len];
p[len] = '\0';
  }

  constexpr ~S()
  {
if (len > 7)
  delete[] ptr;
  }
};

constexpr bool test()
{
  S s("test", 4);
  return true;
}

static_assert( test() );



In the constructor, buf[len] starts the lifetime of the union member, but
p[len] does not.

[Bug ipa/103246] [12 Regression] 416.gamess miscompare with -O2 -g -flto=auto since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e

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

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

--- Comment #15 from Jan Hubicka  ---
Yep, I still see difference in the output with and without SRA

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

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

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

--- Comment #15 from Jakub Jelinek  ---
Ah, bet Solaris aligned_alloc relies on:
"the value of size shall be an integral multiple of alignment"
(glibc aligned_alloc doesn't).
Does memalign or posix_memalign rely on that too, or just aligned_alloc?
If just aligned_alloc, we could do incrementally:
2021-11-17  Jakub Jelinek  

PR libgomp/102838
* alloc.c (gomp_aligned_alloc): Prefer _aligned_alloc over
memalign over posix_memalign over aligned_alloc over fallback
with malloc instead of aligned_alloc over _aligned_alloc over
posix_memalign over memalign over fallback with malloc.  For
aligned_alloc, round up size up to multiple of al.

--- libgomp/alloc.c.jj  2021-01-04 10:25:56.157037659 +0100
+++ libgomp/alloc.c 2021-11-17 13:32:25.246271672 +0100
@@ -65,18 +65,24 @@ gomp_aligned_alloc (size_t al, size_t si
   void *ret;
   if (al < sizeof (void *))
 al = sizeof (void *);
-#ifdef HAVE_ALIGNED_ALLOC
-  ret = aligned_alloc (al, size);
-#elif defined(HAVE__ALIGNED_MALLOC)
+#ifdef HAVE__ALIGNED_MALLOC
   ret = _aligned_malloc (size, al);
-#elif defined(HAVE_POSIX_MEMALIGN)
-  if (posix_memalign (&ret, al, size) != 0)
-ret = NULL;
 #elif defined(HAVE_MEMALIGN)
   {
 extern void *memalign (size_t, size_t);
 ret = memalign (al, size);
   }
+#elif defined(HAVE_POSIX_MEMALIGN)
+  if (posix_memalign (&ret, al, size) != 0)
+ret = NULL;
+#lif defined(HAVE_ALIGNED_ALLOC)
+  {
+size_t sz = (size + al - 1) & ~(al - 1);
+if (__builtin_expect (sz >= size, 1))
+  ret = aligned_alloc (al, sz);
+else
+  ret = NULL;
+  }
 #else
   ret = NULL;
   if ((al & (al - 1)) == 0 && size)

[Bug tree-optimization/103255] [11/12 Regression] optimization breaks address of struct member since r11-4984-g47923622c663ffad

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-5336-gc39cb6bf835ca12e590eaa6f90222e51be207c50
Author: Jakub Jelinek 
Date:   Wed Nov 17 13:45:53 2021 +0100

ranger: Fix up fold_using_range::range_of_address [PR103255]

If on &base->member the offset isn't constant or isn't zero and
-fdelete-null-pointer-checks and not -fwrapv-pointer and base has a range
that doesn't include NULL, we return the range of the base.
Usually it isn't a big deal, because for most pointers we just use
varying, range_zero and range_nonzero ranges and nothing beyond that,
but if a pointer is initialized from a constant, we actually track the
exact range and in that case this causes miscompilation.
As discussed on IRC, I think doing something like:
  offset_int off2;
  if (off_cst && off.is_constant (&off2))
{
  tree cst = wide_int_to_tree (sizetype, off2 /
BITS_PER_UNIT);
  // adjust range r with POINTER_PLUS_EXPR cst
  if (!range_includes_zero_p (&r))
return true;
}
  // Fallback
  r = range_nonzero (TREE_TYPE (gimple_assign_rhs1 (stmt)));
  return true;
could work, given that most of the pointer ranges are just the simple ones
perhaps it is too much for little benefit.

2021-11-17  Jakub Jelinek  

PR tree-optimization/103255
* gimple-range-fold.cc (fold_using_range::range_of_address): Return
range_nonzero rather than unadjusted base's range.  Formatting
fixes.

* gcc.c-torture/execute/pr103255.c: New test.

[Bug ipa/103246] [12 Regression] 416.gamess miscompare with -O2 -g -flto=auto since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e

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

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

--- Comment #16 from Jan Hubicka  ---
Building with LTO only ecpder.fppized.o and ecplib.fppized.o I get the failure
going away with --dbg-cnt=ipa_cp_values:10 and :9 works.

Different ipa-cp decision is
+***dbgcnt: upper limit 10 reached for ipa_cp_values.***
+ - Creating a specialized node of formdr/4 for all known contexts.
+replacing param #5 int & restrict with const &ecpidx.iamin
+replacing param #6 int & restrict with const &ecpidx.iamax
+Removed a reference from formii.constprop/284 to ecpidx/11.
+  ...and replaced it with LOAD one.
+Removed a reference from ecp2d/1 to ecpidx/11.
+Removed a reference from ecp1d/0 to ecpidx/11.
+replacing param #9 logical(kind=4) & restrict with const &ecpidx.norm -
forcing load reference

In modref the propagation goes same way and we update signature as follows:
+Updating summary for formdr.constprop/285 from:
+  loads:
+Limits: 32 bases, 16 refs
+Every base
+  stores:
+Limits: 32 bases, 16 refs
+Every base
+  Side effects
+  Nondeterministic
+  parm 0 flags: no_direct_clobber no_direct_escape no_indirect_escape
+  parm 1 flags: no_direct_clobber no_direct_escape no_indirect_escape
+  parm 2 flags: no_direct_escape no_indirect_escape
+  parm 3 flags: no_direct_escape no_indirect_escape
+  parm 4 flags: no_direct_escape no_indirect_escape
+  parm 5 flags: no_direct_clobber no_indirect_clobber no_direct_escape
no_indirect_escape no_indirect_read
+  parm 6 flags: no_direct_clobber no_indirect_clobber no_direct_escape
no_indirect_escape no_indirect_read
+  parm 7 flags: no_direct_clobber no_indirect_clobber no_direct_escape
no_indirect_escape no_indirect_read
+  parm 8 flags: no_direct_clobber no_indirect_clobber no_direct_escape
no_indirect_escape no_indirect_read
+  parm 9 flags: no_direct_clobber no_indirect_clobber no_direct_escape
no_indirect_escape no_indirect_read
+to:
+  loads:
+Limits: 32 bases, 16 refs
+Every base
+  stores:
+Limits: 32 bases, 16 refs
+Every base
+  Side effects
+  Nondeterministic
+  parm 0 flags: no_direct_clobber no_direct_escape no_indirect_escape
+  parm 1 flags: no_direct_clobber no_direct_escape no_indirect_escape
+  parm 2 flags: no_direct_escape no_indirect_escape
+  parm 3 flags: no_direct_escape no_indirect_escape
+  parm 4 flags: no_direct_escape no_indirect_escape
+  parm 5 flags: no_direct_clobber no_indirect_clobber no_direct_escape
no_indirect_escape no_indirect_read
+  parm 6 flags: no_direct_clobber no_indirect_clobber no_direct_escape
no_indirect_escape no_indirect_read

this changes partitioning decisions which makes quite a lot of fuzz in latr
dump files.

[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope

[gerald at pfeifer dot com via Gcc-bugs]

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

--- Comment #20 from Gerald Pfeifer  ---
Thank you, Jakub!

I finished testing/preparing the second part of the patch, just did not get
to push.

So I went ahead and gave your suggested patch a try - and it passes bootstrap,
so good to go I'd say! Thanks.

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #15 from Jakub Jelinek  ---
> Ah, bet Solaris aligned_alloc relies on:
> "the value of size shall be an integral multiple of alignment"
> (glibc aligned_alloc doesn't).

Indeed, cf. aligned_alloc(3C):

   The alignment argument must be a valid alignment, that is, any power of
   two  (1, 2, 4, 8, ...) and the size argument must be an integral multi-
   ple of alignment.

> Does memalign or posix_memalign rely on that too, or just aligned_alloc?

memalign(3C) has:

   The  memalign()  function allocates size bytes on a specified alignment
   boundary and returns a pointer to the allocated block. The value of the
   returned address is guaranteed to be an even multiple of alignment. The
   value of alignment must be a power of two and must be greater  than  or
   equal to the size of a word.

and posix_memalign(3C):

   The  posix_memalign() function allocates size bytes aligned on a bound-
   ary specified by alignment, and returns a pointer to the allocated mem-
   ory  in  memptr. The value of alignment must be a power of two multiple
   of sizeof(void *).

> If just aligned_alloc, we could do incrementally:
> 2021-11-17  Jakub Jelinek  
>
> PR libgomp/102838
> * alloc.c (gomp_aligned_alloc): Prefer _aligned_alloc over
> memalign over posix_memalign over aligned_alloc over fallback
> with malloc instead of aligned_alloc over _aligned_alloc over
> posix_memalign over memalign over fallback with malloc.  For
> aligned_alloc, round up size up to multiple of al.

That patch worked just fine (only tried on i386-pc-solaris2.11, 32 and
64-bit): all 64-bit failures are gone again.  Thanks.

[Bug ipa/103246] [12 Regression] 416.gamess miscompare with -O2 -g -flto=auto since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e

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

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

--- Comment #17 from Jan Hubicka  ---
and fun fact is that it really depends how program is paritioned. 
-flto-partition=max keeps problem reproducing while -flto-partition=one makes
it go away and -flto-partition=one --disable-tree-modref2 brings it back.

[Bug target/103275] [11/12 Regression] don't generate kmov with IE model relocations

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Hongtao.liu  ---
I'm working on a patch which adds a new memory constraint "Bk" which will
exclude TLS UNSPECs for mask register alternative.

The UNSPEC i'm excluding is like below, any other UNSPEC needs to be added?

bool
ix86_notls_memory (rtx mem)
{
  gcc_assert (MEM_P (mem));

  rtx addr = XEXP (mem, 0);
  subrtx_var_iterator::array_type array;
  FOR_EACH_SUBRTX_VAR (iter, array, addr, ALL)
{
  rtx op = *iter;
  if (GET_CODE (op) == UNSPEC)
switch (XINT (op, 1))
  {
  case UNSPEC_GOTTPOFF:
  case UNSPEC_GOTNTPOFF:
  case UNSPEC_TP:
  case UNSPEC_TLS_GD:
  case UNSPEC_TLS_LD_BASE:
  case UNSPEC_TLSDESC:
  case UNSPEC_TLS_IE_SUN:
return false;
  default:
break;
  }
  /* Should iter.skip_subrtxes ();
 if there's no inner UNSPEC in addr???.  */
}

  return true;
}

[Bug tree-optimization/103192] [12 Regression] ICE on libgomp target-in-reduction-2.{C,c}

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

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

--- Comment #21 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:077425c890927eefacb765ab5236060de9859e82

commit r12-5337-g077425c890927eefacb765ab5236060de9859e82
Author: Jakub Jelinek 
Date:   Wed Nov 17 14:18:42 2021 +0100

lim: Reset flow sensitive info even for pointers [PR103192]

Since 2014 is lim clearing SSA_NAME_RANGE_INFO for integral SSA_NAMEs
if moving them from conditional contexts inside of a loop into
unconditional
before the loop, but as the miscompilation of gimplify.c shows, we need to
treat pointers the same, even for them we need to reset whether the pointer
can/can't be null or the recorded pointer alignment.

This fixes
-FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (internal
compiler error)
-FAIL: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c (test for
excess errors)
-UNRESOLVED: libgomp.c/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
-FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
(internal compiler error)
-FAIL: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c (test
for excess errors)
-UNRESOLVED: libgomp.c++/../libgomp.c-c++-common/target-in-reduction-2.c
compilation failed to produce executable
-FAIL: libgomp.c++/target-in-reduction-2.C (internal compiler error)
-FAIL: libgomp.c++/target-in-reduction-2.C (test for excess errors)
-UNRESOLVED: libgomp.c++/target-in-reduction-2.C compilation failed to
produce executable
on both x86_64 and i686.

2021-11-17  Jakub Jelinek  

PR tree-optimization/103192
* tree-ssa-loop-im.c (move_computations_worker): Use
reset_flow_sensitive_info instead of manually clearing
SSA_NAME_RANGE_INFO and do it for all SSA_NAMEs, not just ones
with integral types.

[Bug target/103275] [11/12 Regression] don't generate kmov with IE model relocations

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

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

--- Comment #11 from H.J. Lu  ---
(In reply to Hongtao.liu from comment #10)
> I'm working on a patch which adds a new memory constraint "Bk" which will
> exclude TLS UNSPECs for mask register alternative.
> 
> The UNSPEC i'm excluding is like below, any other UNSPEC needs to be added?
> 
> bool
> ix86_notls_memory (rtx mem)
> {
>   gcc_assert (MEM_P (mem));
> 
>   rtx addr = XEXP (mem, 0);
>   subrtx_var_iterator::array_type array;
>   FOR_EACH_SUBRTX_VAR (iter, array, addr, ALL)
> {
>   rtx op = *iter;
>   if (GET_CODE (op) == UNSPEC)
>   switch (XINT (op, 1))
> {
> case UNSPEC_GOTTPOFF:
> case UNSPEC_GOTNTPOFF:
> case UNSPEC_TP:
> case UNSPEC_TLS_GD:
> case UNSPEC_TLS_LD_BASE:
> case UNSPEC_TLSDESC:
> case UNSPEC_TLS_IE_SUN:

This doesn't look right.  For TARGET_64BIT, only

kmovq   foo@gottpoff(%rip), %k0
kmovq   foo@tlsld(%rip), %k0

should be disallowed.  For !TARGET_64BIT, only

kmovd   foo@gotntpoff(%eax), %k0
kmovd   foo@tpoff(%eax), %k0

should be disallowed.

>   return false;
> default:
>   break;
> }
>   /* Should iter.skip_subrtxes ();
>if there's no inner UNSPEC in addr???.  */
> }
> 
>   return true;
> }

[Bug c/91038] ICE with VLA type and statement expression (gimplify_var_or_parm_decl)

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

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

commit r12-5338-g4e6bf0b9dd5585df1a1472d6a93b9fff72fe2524
Author: Martin Uecker 
Date:   Wed Nov 17 14:20:59 2021 +0100

Fix ICE when mixing VLAs and statement expressions [PR91038]

When returning VM-types from statement expressions, this can
lead to an ICE when declarations from the statement expression
are referred to later. Most of these issues can be addressed by
gimplifying the base expression earlier in gimplify_compound_lval.
Another issue is fixed by wrapping the pointer expression in
pointer_int_sum. This fixes PR91038 and some of the test cases
from PR29970 (structs with VLA members need further work).

gcc/
PR c/91038
PR c/29970
* gimplify.c (gimplify_var_or_parm_decl): Update comment.
(gimplify_compound_lval): Gimplify base expression first.
(gimplify_target_expr): Add comment.

gcc/c-family/
PR c/91038
PR c/29970
* c-common.c (pointer_int_sum): Make sure pointer expressions
are evaluated first when the size expression depends on for
variably-modified types.

gcc/testsuite/
PR c/91038
PR c/29970
* gcc.dg/vla-stexp-3.c: New test.
* gcc.dg/vla-stexp-4.c: New test.
* gcc.dg/vla-stexp-5.c: New test.
* gcc.dg/vla-stexp-6.c: New test.
* gcc.dg/vla-stexp-7.c: New test.
* gcc.dg/vla-stexp-8.c: New test.
* gcc.dg/vla-stexp-9.c: New test.

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

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

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

commit r12-5338-g4e6bf0b9dd5585df1a1472d6a93b9fff72fe2524
Author: Martin Uecker 
Date:   Wed Nov 17 14:20:59 2021 +0100

Fix ICE when mixing VLAs and statement expressions [PR91038]

When returning VM-types from statement expressions, this can
lead to an ICE when declarations from the statement expression
are referred to later. Most of these issues can be addressed by
gimplifying the base expression earlier in gimplify_compound_lval.
Another issue is fixed by wrapping the pointer expression in
pointer_int_sum. This fixes PR91038 and some of the test cases
from PR29970 (structs with VLA members need further work).

gcc/
PR c/91038
PR c/29970
* gimplify.c (gimplify_var_or_parm_decl): Update comment.
(gimplify_compound_lval): Gimplify base expression first.
(gimplify_target_expr): Add comment.

gcc/c-family/
PR c/91038
PR c/29970
* c-common.c (pointer_int_sum): Make sure pointer expressions
are evaluated first when the size expression depends on for
variably-modified types.

gcc/testsuite/
PR c/91038
PR c/29970
* gcc.dg/vla-stexp-3.c: New test.
* gcc.dg/vla-stexp-4.c: New test.
* gcc.dg/vla-stexp-5.c: New test.
* gcc.dg/vla-stexp-6.c: New test.
* gcc.dg/vla-stexp-7.c: New test.
* gcc.dg/vla-stexp-8.c: New test.
* gcc.dg/vla-stexp-9.c: New test.

[Bug ipa/103246] [12 Regression] 416.gamess miscompare with -O2 -g -flto=auto since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e

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

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

--- Comment #18 from Jan Hubicka  ---
This seems to fix it for this particular partitioning at least ;)
The problem was in summary update producing ill formed access range (which
doesn't know base but knows offset from it) and that confused streamer.

I will test it with additional sanity check that accesses are sane.

diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h
index 1bf2aa8460e..c29dda56fc1 100644
--- a/gcc/ipa-modref-tree.h
+++ b/gcc/ipa-modref-tree.h
@@ -677,6 +677,8 @@ struct GTY((user)) modref_tree
access_node->parm_index = (*map)[access_node->parm_index];
  else
access_node->parm_index = MODREF_UNKNOWN_PARM;
+ if (access_node->parm_index == MODREF_UNKNOWN_PARM)
+   access_node->parm_offset_known = false;
}
  }
   }

[Bug target/103275] [11/12 Regression] don't generate kmov with IE model relocations

[jason at zx2c4 dot com via Gcc-bugs]

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

--- Comment #12 from Jason A. Donenfeld  ---
(It might be too late at this point to say it, but I thought it's worth
mentioning that another approach might be convincing the binutils people to
accept kmov/vmov/vex relocations.)

[Bug target/103302] New: wrong code with -fharden-compares

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 103302
   Summary: wrong code with -fharden-compares
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

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

Output:
$ riscv64-unknown-linux-gnu-gcc -Og -fharden-compares -fno-tree-dce
-fno-tree-fre testcase.c -static
$ qemu-riscv64 -- ./a.out 
Trace/breakpoint trap

Debugging shows one of the compares on the first statement probably goes wrong:

(gdb) 
0x000106ea  19u32_0 <= (v512u128) (v512u128_0 != u8_0);
(gdb) 
0x00010a48  24  }

I could find any other target where this testcase is failing.

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-5221-2023015125-g2f3d43a3515-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/12.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-5221-2023015125-g2f3d43a3515-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 2023 (experimental) (GCC)

[Bug target/103275] [11/12 Regression] don't generate kmov with IE model relocations

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

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

--- Comment #13 from Jakub Jelinek  ---
If you read the tls.pdf, you'll see that it is not really possible, the IE ->
LE transition needs to change the instructions that read from the .got memory
to instructions that set the destination to an immediate.  I think it can deal
currently with:
subl foo@{tpoff,gotntpoff}(%reg1), %reg2
movl foo@{tpoff,gotntpoff}(%reg1), %reg2
addl foo@{tpoff,gotntpoff}(%reg1), %reg2
and is tranformed into movl immediate, %reg2.  There is no instruction that
would set a mask register to an immediate (except for some special cases like
0).

[Bug c++/103299] [10/11/12 Regression] accessing incorrect storage for designated init of anonymous union at constexpr context

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to fail||11.2.0, 12.0
   Keywords||rejects-valid
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102538
 Status|UNCONFIRMED |NEW
  Known to work||10.1.0, 10.2.0, 10.3.0
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
Summary|accessing incorrect storage |[10/11/12 Regression]
   |for union at constexpr  |accessing incorrect storage
   |context |for designated init of
   ||anonymous union at
   ||constexpr context
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-17
   Target Milestone|--- |10.4

--- Comment #1 from Patrick Palka  ---
Started with r12-954, which has also been backported to the 11/10 branches.

Reduced rejects-valid testcase:

struct foo {
  union {
int fp1{};
char fp2;
  };
};

static_assert(foo{.fp2={}}.fp2 == 0);

[Bug c++/103299] [11/12 Regression] accessing incorrect storage for designated init of anonymous union at constexpr context

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[11/12 Regression]
   |accessing incorrect storage |accessing incorrect storage
   |for designated init of  |for designated init of
   |anonymous union at  |anonymous union at
   |constexpr context   |constexpr context
   Target Milestone|10.4|11.3

--- Comment #2 from Patrick Palka  ---
Actually I don't think the bug is present on the 10 branch since the full
r12-954 fix hasn't been backported there according to PR100489#c4.

[Bug libstdc++/103295] constexpr std::string does not work for clang

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

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

--- Comment #12 from Jonathan Wakely  ---
But even with those problems fixed, Clang fails for anything that doesn't fit
in the SSO buffer, as shown by this:

#include 

constexpr char test()
{
  char* p = std::allocator().allocate(2);

  p[0] = 'a';
  char c = *p;
  std::allocator().deallocate(p, 2);
  return c;
}

static_assert( test() == 'a' );

[Bug tree-optimization/103278] [12 Regression] Recent change to cddce inhibits switch optimization

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

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

--- Comment #3 from Jeffrey A. Law  ---
Note we also see these regressions:

rl78-elf
  if-to-switch-5
  if-to-switch-9

xstormy16-elf
  if-to-switch-9

sh3-linux-gnu
sh3eb-linux-gnu
  gcc.target/sh/pr51244-19.c, but I think this is fixable with a trivial sh.md
change

[Bug analyzer/101713] -Wanalyzer-malloc-leak false positive with GNU coreutils hash table code

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

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

--- Comment #1 from David Malcolm  ---
Thanks for reporting this issue.

The analyzer sees that "str" is passed to hash_insert as a const pointer, and
therefore assumes that hash_insert cannot free it, that hash_insert is merely
borrowing a pointer to str, rather than taking ownership.

Am I right in thinking that there's a cast somewhere inside the hash table code
that at some point casts away the const from the pointer and frees it?

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #6 from Tamar Christina  ---
(In reply to Aldy Hernandez from comment #4)
> It's been a LONG time since I had to do a sim build, so please bear with me.
> 
> I have combined tree with  gcc, binutils-gdb, dejagnu, newlib-cygwin:
> 
> ~/src/combined/configure --target=bfin-elf --enable-languages=c,c++
> --with-newlib --prefix=`pwd`/install
> 
> C++ won't build:
> In file included from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bits/locale_facets.h:
> 41,
>  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bits/basic_ios.h:37,
>  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/ios:44,
>  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/istream:38,
>  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/sstream:38,
>  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/complex:45,
>  from
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/ccomplex:39,
>  from
> /home/aldyh/src/combined/libstdc++-v3/include/precompiled/stdc++.h:54:
> /home/aldyh/bld/bfin-elf/bfin-elf/libstdc++-v3/include/bfin-elf/bits/
> ctype_base.h:44:35: error: ‘_U’ was not declared in this scope
>44 | static const mask upper = _U;
>   |   ^~
> ...
> ...

I see the same failures on aarch64-none-elf cross builds which use newlib:

/build-agent/temp/buildTmp/gcc-2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf/bits/ctype_base.h:44:35:
error: '_U' was not declared in this scope
   44 | static const mask upper = _U;
  |   ^~
/build-agent/temp/buildTmp/gcc-2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf/bits/ctype_base.h:45:35:
error: '_L' was not declared in this scope
   45 | static const mask lower = _L;
  |   ^~
/build-agent/temp/buildTmp/gcc-2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf/bits/ctype_base.h:46:35:
error: '_U' was not declared in this scope
   46 | static const mask alpha = _U | _L;

and so on.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

--- Comment #7 from Tamar Christina  ---
Just a note, in our case the error seems to cause stage2 build to fail.

[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698

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

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

Tamar Christina  changed:

   What|Removed |Added

   Host|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||aarch64-none-linux-gnu
 CC||tnfchris at gcc dot gnu.org
  Build|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||aarch64-none-linux-gnu
 Target|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||aarch64-none-linux-gnu

--- Comment #3 from Tamar Christina  ---
I'm seeing the same failure on aarch64-none-linux-gnu

[Bug c++/103303] New: compiler have trouble to point to the correct destructor address while for large align objects with complex inheritance while destruct object

[wqpfelix at gmail dot com via Gcc-bugs]

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

Bug ID: 103303
   Summary: compiler have trouble to point to the correct
destructor address while for large align objects with
complex inheritance while destruct object
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wqpfelix at gmail dot com
  Target Milestone: ---

Created attachment 51825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51825&action=edit
c++ code trigger the 0x8 offset for movaps

the error is reproduced on compiler explorer:
https://godbolt.org/z/v8roq3641
where I can trigger this problem while gcc after 8.1

more details: 
while running with the following compiler
```sh
$Compiler/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/net/binlib/build-kits/build-kit-20191029-x86_64-pc-linux-gnu-gcc-8.2.0-gcc82_u18_v3/bin/g++
COLLECT_LTO_WRAPPER=/net/binlib/build-kits/build-kit-20191029-x86_64-pc-linux-gnu-gcc-8.2.0-gcc82_u18_v3/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: .../gcc/configure --with-gmp={PathTo_gcc82_u18_v3}
--with-mpfr={PathTo_gcc82_u18_v3} --with-mpc={PathTo_gcc82_u18_v3}
--with-isl={PathTo_gcc82_u18_v3} --prefix={PathTo_gcc82_u18_v3}
--exec-prefix={PathTo_gcc82_u18_v3} --enable-languages=c,c++ --enable-shared
--enable-static --enable-threads=posix --disable-host-shared --enable-lto
--with-ld={PathTo_gcc82_u18_v3}/bin/ld --target=x86_64-pc-linux-gnu
--with-sysroot=/.
--with-gxx-include-dir={PathTo_gcc82_u18_v3}/include/libstdc++
--disable-multilib --verbose
Thread model: posix
gcc version 8.2.0 (GCC)
```

on C++ program with
```C++
#include 
#include 

struct alignas(16) largeAligned{ // change to 8, no crash
uint32_t u_arr[128];
};

template
struct ICategory: public virtual Base{
ICategory(){
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
};

struct PureInterfaceHandler{
virtual ~PureInterfaceHandler() = default;
};

template
class TemplateNotifier
  : public PureInterfaceHandler,
 public MsgCategoryNotifierS...{
public:
TemplateNotifier() {
std::cout << __PRETTY_FUNCTION__  << std::endl;
}

virtual ~TemplateNotifier() {
std::cout << __PRETTY_FUNCTION__  << std::endl;
}
};


struct Base1{
Base1(){
std::cout << __PRETTY_FUNCTION__  << std::endl;
}
virtual ~Base1(){
std::cout << __PRETTY_FUNCTION__  << std::endl;
}
largeAligned aligned1;
};


struct Base2{
Base2(){
std::cout << __PRETTY_FUNCTION__  << std::endl;
}
virtual ~Base2(){
std::cout << __PRETTY_FUNCTION__  << std::endl;
}
largeAligned aligned2;
};

using Category2 = ICategory;
using Category1 = ICategory;
struct ProblematicNotifier: TemplateNotifier{};

int main(){
static_assert(alignof(ProblematicNotifier) == 16, "128 is great" );
static_assert( alignof(std::max_align_t) == 16, "16? is great" );
ProblematicNotifier* objPtr = new ProblematicNotifier();
delete objPtr;
std::cout << "Done" << std::endl;
}
```


with: 
$Compiler/bin/g++ -I $Compiler/include -I $Compiler/include/libstdc++
crash.cpp -O3
I found: 
Program received signal SIGSEGV, Segmentation fault.
0x0040228a in ProblematicNotifier::~ProblematicNotifier() ()
on instruction: 
0x40228a <_ZN19ProblematicNotifierD0Ev+202> movaps %xmm0,0x8(%rbx)
where (gdb) x/i $rbx
  0x417e70:mov$0x34,%al

it looks like compiler generates 
movaps with offset 0x8 while handling aligned object, while is not expected for
movaps

[Bug c++/103304] New: tgmath returns incorrect results for float fma (fmaf)

[oscar.smith at juliacomputing dot com via Gcc-bugs]

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

Bug ID: 103304
   Summary: tgmath returns incorrect results for float fma (fmaf)
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oscar.smith at juliacomputing dot com
  Target Milestone: ---

In the following program, g++ incorrectly believes that the fma call is a
double precision fma rather than a templated single precision fma, leading to
an incorrect answer due to double rounding. This program produces
-4167095.50
-4167095.75
instead of the correct result which would be
-4167095.75
-4167095.75

#include 
#include 
int main() {
float a = -1.9369631e13f, b = 2.1513551e-7f, c = -1.7354427e-24f;
float f1 = fma(a, b, c);
float f2 = fmaf(a, b, c);
printf("%f\n", f1);
printf("%f\n", f2);
return 0;
}

For comparison, the identical C program

#include 
#include 
int main() {
float a = -1.9369631e13f, b = 2.1513551e-7f, c = -1.7354427e-24f;
float f1 = fma(a, b, c);
float f2 = fmaf(a, b, c);
printf("%f\n", f1);
printf("%f\n", f2);
return 0;
}

produces
-4167095.75
-4167095.75

as expected.

These were compiled with g++ -o testoutcpp test.cpp -march=haswell -Wall
-Wextra -std=c++11
and gcc -o testoutc test.c -march=haswell -Wall -Wextra -lm -std=c11
respectively (although I get the same results for all combinations of flags
that I've tried.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

--- Comment #8 from Aldy Hernandez  ---
(In reply to Tamar Christina from comment #7)
> Just a note, in our case the error seems to cause stage2 build to fail.

Please file a PR for it and indicate the architecture.  This PR is for a
pr80974.c regression on bfin-elf.

[Bug ipa/103243] [12 regression] pr98499.C fails after r12-5203

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

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

--- Comment #4 from seurer at gcc dot gnu.org ---
At or somewhere just before r12-5221 it now succeeds, at least on powerpc64

g:2f3d43a35155685b1795b4392e20e1c14a33c38f, r12-5221
New passes (these tests previously failed but now do not):
FAIL: g++.dg/pr98499.C  -std=gnu++14 execution test
FAIL: g++.dg/pr98499.C  -std=gnu++14 execution test
FAIL: g++.dg/pr98499.C  -std=gnu++17 execution test
FAIL: g++.dg/pr98499.C  -std=gnu++17 execution test
FAIL: g++.dg/pr98499.C  -std=gnu++2a execution test
FAIL: g++.dg/pr98499.C  -std=gnu++2a execution test
FAIL: g++.dg/pr98499.C  -std=gnu++98 execution test
FAIL: g++.dg/pr98499.C  -std=gnu++98 execution test

[Bug c++/103304] tgmath returns incorrect results for float fma (fmaf)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is a bug in your program, combined with a bug in libstdc++ that allows
your invalid code to compile.

You have included  but then called fma and fmaf unqualified, which is
invalid. If you include  then they are only guaranteed to be defined
in namespace std. What happens is that you call ::fma which is the libc version
that takes double arguments. To get the overload for float arguments you need
to call std::fma (either using a qualified name, or following using std::fma or
using namespace std).

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

[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||oscar.smith@juliacomputing.
   ||com

--- Comment #9 from Jonathan Wakely  ---
*** Bug 103304 has been marked as a duplicate of this bug. ***

[Bug c++/103304] tgmath returns incorrect results for float fma (fmaf)

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

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

--- Comment #2 from Jonathan Wakely  ---
N.B. the same applies to printf: you included  so you should be using
std::printf. Or you should include 

Stop including C++ headers that put names in namespace std and then using them
as though they are not in namespace std. That is not guaranteed to work.

[Bug bootstrap/103305] New: [12 Regression] Cannot build aarch64-none-elf

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

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

Bug ID: 103305
   Summary: [12 Regression] Cannot build aarch64-none-elf
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: build, wrong-code
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
  Host: aarch64-none-linux-gnu
Target: aarch64-none-elf
 Build: aarch64-none-elf

aarch64-none-elf stage2 cross builds which use newlib fail with:

/build-agent/temp/buildTmp/gcc-2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf/bits/ctype_base.h:44:35:
error: '_U' was not declared in this scope
   44 | static const mask upper = _U;
  |   ^~
/build-agent/temp/buildTmp/gcc-2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf/bits/ctype_base.h:45:35:
error: '_L' was not declared in this scope
   45 | static const mask lower = _L;
  |   ^~
/build-agent/temp/buildTmp/gcc-2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf/bits/ctype_base.h:46:35:
error: '_U' was not declared in this scope
   46 | static const mask alpha = _U | _L;

and so on.

This looks like the exact same bug as PR103226 but have been asked to make a
new ticket.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

--- Comment #9 from Tamar Christina  ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Tamar Christina from comment #7)
> > Just a note, in our case the error seems to cause stage2 build to fail.
> 
> Please file a PR for it and indicate the architecture.  This PR is for a
> pr80974.c regression on bfin-elf.

Sure, I commented here because the error is the same and on the same file on
the same conditions, so it's likely the same bug. But here it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

--- Comment #10 from Jeffrey A. Law  ---
Aldy, the trick is to not build the C++ runtime ;-)

So instead of "make" use "make all-gcc && make all-target-libgcc" to build the
compiler and libgcc runtime.  Then use "make install-gcc install-target-libgcc"
to install the compiler and libgcc runtime.

Once that completes you can proceed to build & install newlib.

Make sure to use the same --prefix for each component (binutils-gdb, gcc,
newlib) and they should.

[Bug tree-optimization/102756] [12 Regression] Complete unrolling is too senative to PRE; c-c++-common/torture/vector-compare-2.c

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

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

--- Comment #4 from Jeffrey A. Law  ---
I could also set up a toolchain ready-to-debug in an AWS instance that you
could use if that would be helpful.

[Bug tree-optimization/102756] [12 Regression] Complete unrolling is too senative to PRE; c-c++-common/torture/vector-compare-2.c

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

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

--- Comment #5 from Jeffrey A. Law  ---
Ignore last comment.  Meant for a different BZ.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

--- Comment #11 from Jeffrey A. Law  ---
Aldy, I could also set up a cross toolchain, ready for debugging in an AWS
instance if that would be helpful.

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

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

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

--- Comment #7 from Thomas Koenig  ---
(In reply to Jürgen Reuter from comment #6)

> Really interesting, I don't get an ICE with the following setup:
> ../configure --prefix=/usr/local/ --with-gmp=/usr/local/
> --with-mpfr=/usr/local/ --with-mp=/usr/local/
> --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
> platform/Developer/SDKs/MacOSX.sdk/ --enable-checking=release
> --enable-languages=c,c++,fortran,lto,objc,obj-c++
> $ gfortran --version
> GNU Fortran (GCC) 12.0.0 2025 (experimental)
> Maybe the enable-checking setup!?

Extremely likely.

--enable-checking=release turns off a very large number of checks
which are really only interesting for developers to find bugs,
and which make the compiler run rather slowly.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

--- Comment #12 from Aldy Hernandez  ---
(In reply to Tamar Christina from comment #9)
> (In reply to Aldy Hernandez from comment #8)
> > (In reply to Tamar Christina from comment #7)
> > > Just a note, in our case the error seems to cause stage2 build to fail.
> > 
> > Please file a PR for it and indicate the architecture.  This PR is for a
> > pr80974.c regression on bfin-elf.
> 
> Sure, I commented here because the error is the same and on the same file on
> the same conditions, so it's likely the same bug. But here it is
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305

I mentioned the failure in comment #4 to indicate that I can't a build bfin-elf
cross with c++ enabled, but I wasn't implying it was due to the same commit
which is referenced in this PR (r12-5138).

For that matter, if I disable the code introduced by the above commit, C++
still fails to build, so it's not related to this bug at all.  This is why I
asked you to file another PR :).

[Bug preprocessor/103130] [11/12 Regression] \*/ is not detected as the end of a comment with -fdirectives-only since r11-206-gb224c3763e018e8b

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:049f0efeaa77b43a508172161ca040feb6bb5622

commit r12-5340-g049f0efeaa77b43a508172161ca040feb6bb5622
Author: Jakub Jelinek 
Date:   Wed Nov 17 17:31:40 2021 +0100

libcpp: Fix up handling of block comments in -fdirectives-only mode
[PR103130]

Normal preprocessing, -fdirectives-only preprocessing before the Nathan's
rewrite, and all other compilers I've tried on godbolt treat even \*/
as end of a block comment, but the new -fdirectives-only handling doesn't.

2021-11-17  Jakub Jelinek  

PR preprocessor/103130
* lex.c (cpp_directive_only_process): Treat even \*/ as end of
block
comment.

* c-c++-common/cpp/dir-only-9.c: New test.

[Bug preprocessor/103130] [11 Regression] \*/ is not detected as the end of a comment with -fdirectives-only since r11-206-gb224c3763e018e8b

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12 Regression] \*/ is   |[11 Regression] \*/ is not
   |not detected as the end of  |detected as the end of a
   |a comment with  |comment with
   |-fdirectives-only since |-fdirectives-only since
   |r11-206-gb224c3763e018e8b   |r11-206-gb224c3763e018e8b

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug bootstrap/103305] [12 Regression] Cannot build C++ with newlib on aarch64-none-elf or bfin-elf

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Target|aarch64-none-elf|aarch64-none-elf, bfin-elf
 CC||aldyh at gcc dot gnu.org
   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=103226|
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-17
 Status|UNCONFIRMED |NEW
Summary|[12 Regression] Cannot  |[12 Regression] Cannot
   |build aarch64-none-elf  |build C++ with newlib on
   ||aarch64-none-elf or
   ||bfin-elf

--- Comment #1 from Aldy Hernandez  ---
Confirmed on a bfin-elf cross.  C++ does not build on a cross --with-newlib.

However, this is not the same problem in PR103226.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

--- Comment #13 from Aldy Hernandez  ---
(In reply to Jeffrey A. Law from comment #11)
> Aldy, I could also set up a cross toolchain, ready for debugging in an AWS
> instance if that would be helpful.

Ok, I give up.

I configured and installed the following in order:

binutils
gcc (all-gcc, all-target-libgcc)
newlib

everything's living in install/ and yet I get:

tor:~/bld/bfin/install/bin$ ./bfin-elf-gcc a.c  -w
bfin-elf-gcc: error: no processor type specified for linking
bfin-elf-gcc: fatal error: error in arguments to spec function
‘pass-through-libs’
compilation terminated.

so yeah...set me up with an environment to connect to.  I'm a wuss :-).

[Bug bootstrap/103305] [12 Regression] Cannot build C++ with newlib on aarch64-none-elf or bfin-elf

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
config/os/newlib/ctype_base.h hasn't changed in years, what changed?

[Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:054bf99841aad3869c70643b2ba2d9f85770c980

commit r12-5342-g054bf99841aad3869c70643b2ba2d9f85770c980
Author: Jonathan Wakely 
Date:   Tue Nov 16 21:03:21 2021 +

libstdc++: Fix std::type_info::before for ARM [PR103240]

The r179236 fix for std::type_info::operator== should also have been
applied to std::type_info::before. Otherwise two distinct types can
compare equivalent due to using a string comparison, when they should do
a pointer comparison.

libstdc++-v3/ChangeLog:

PR libstdc++/103240
* libsupc++/tinfo2.cc (type_info::before): Use unadjusted name
to check for the '*' prefix.
* testsuite/util/testsuite_shared.cc: Add type_info object for
use in new test.
* testsuite/18_support/type_info/103240.cc: New test.

[Bug libstdc++/103295] constexpr std::string does not work for clang

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r12-5343-g6afa1083c6ee7b31629fb0c16299b952cb17868c
Author: Jonathan Wakely 
Date:   Wed Nov 17 10:23:14 2021 +

libstdc++: Set active member of union in std::string [PR103295]

Clang diagnoses that the new constexpr std::string constructors are not
usable in constant expressions, because they start to write to members
of the union without setting an active member.

This adds a new helper function which returns the address of the local
buffer after making it the active member.

This doesn't fix all problems with Clang, because it still refuses to
write to memory returned by the allocator.

libstdc++-v3/ChangeLog:

PR libstdc++/103295
* include/bits/basic_string.h (_M_use_local_data()): New
member function to make local buffer the active member.
(assign(const basic_string&)): Use it.
* include/bits/basic_string.tcc (_M_construct, reserve()):
Likewise.

[Bug libstdc++/103295] constexpr std::string does not work for clang

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
I'm going to mark this as fixed, I think the remaining problem is a clang bug.
I'll reopen if Richard Smith convinces me otherwise.

[Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI

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

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

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk, backports to follow.

[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698

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

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

--- Comment #4 from Aldy Hernandez  ---
Is this still an issue with the latest trunk? There have been a few changes in
this space (phi ordering, loop header copying, etc).

[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698

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

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

--- Comment #5 from Tamar Christina  ---
(In reply to Aldy Hernandez from comment #4)
> Is this still an issue with the latest trunk? There have been a few changes
> in this space (phi ordering, loop header copying, etc).

At least on aarch64 our nightlies are still miscompiling perlbench, and the new
lines are still there, but I can't rule out of something else didn't cause the
issue again.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

--- Comment #14 from Tamar Christina  ---
(In reply to Aldy Hernandez from comment #12)
> (In reply to Tamar Christina from comment #9)
> > (In reply to Aldy Hernandez from comment #8)
> > > (In reply to Tamar Christina from comment #7)
> > > > Just a note, in our case the error seems to cause stage2 build to fail.
> > > 
> > > Please file a PR for it and indicate the architecture.  This PR is for a
> > > pr80974.c regression on bfin-elf.
> > 
> > Sure, I commented here because the error is the same and on the same file on
> > the same conditions, so it's likely the same bug. But here it is
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
> 
> I mentioned the failure in comment #4 to indicate that I can't a build
> bfin-elf cross with c++ enabled, but I wasn't implying it was due to the
> same commit which is referenced in this PR (r12-5138).
> 
> For that matter, if I disable the code introduced by the above commit, C++
> still fails to build, so it's not related to this bug at all.  This is why I
> asked you to file another PR :).

I see, sincere apologies, I misunderstood your comment!

[Bug bootstrap/103305] [12 Regression] Cannot build C++ with newlib on aarch64-none-elf or bfin-elf

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

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

--- Comment #3 from Tamar Christina  ---
logs indicate that this started happening between 
3ba1bd0d9dbc..2ec453b566ac on Nov 12. However that range contains a suspicious
newlib commit
https://github.com/bminor/newlib/commit/3ba1bd0d9dbc015c14a0aaafcef042f706d1249a
which changed ctype_.h.  So that is likely the culprid.

[Bug bootstrap/103305] [12 Regression] Cannot build C++ with newlib on aarch64-none-elf or bfin-elf

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

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

--- Comment #4 from Tamar Christina  ---
Looks like that commit moved the short named to ctype_.h instead of ctype.h.

I'm however unsure if this is something GCC needs to adapt to or if newlib
needs to fix this.  They claim it now matches glibc.

[Bug bootstrap/103305] [12 Regression] Cannot build C++ with newlib on aarch64-none-elf or bfin-elf

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

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

--- Comment #5 from Jonathan Wakely  ---
This should work:

--- a/libstdc++-v3/config/os/newlib/ctype_base.h
+++ b/libstdc++-v3/config/os/newlib/ctype_base.h
@@ -41,6 +41,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 // NB: Offsets into ctype::_M_table force a particular size
 // on the mask type. Because of this, we don't use an enum.
 typedef char   mask;
+#if defined _U && defined _L && defined _N && defined _S
 static const mask upper= _U;
 static const mask lower= _L;
 static const mask alpha= _U | _L;
@@ -52,6 +53,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 static const mask cntrl= _C;
 static const mask punct= _P;
 static const mask alnum= _U | _L | _N;
+#else
+static const mask upper= _ISupper;
+static const mask lower= _ISlower;
+static const mask alpha= _ISupper | _ISlower;
+static const mask digit= _ISdigit;
+static const mask xdigit   = _ISxdigit | _ISdigit;
+static const mask space= _ISspace;
+static const mask print= _ISpunct | _ISupper | _ISlower | _ISdigit |
_ISblank;
+static const mask graph= _ISpunct | _ISupper | _ISlower | _ISdigit;
+static const mask cntrl= _IScntrl;
+static const mask punct= _ISpunct;
+static const mask alnum= _ISupper | _ISlower | _ISdigit;
+#endif
 #if __cplusplus >= 201103L
 static const mask blank= space;
 #endif


But of course we can't fix already-released versions.

[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974

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

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

--- Comment #15 from Jeffrey A. Law  ---
Re: c#13.  You were so close :-)  Add "-msim" to your command line.  THat's one
of the things the baseboards file does for you when you run things under
dejagnu on bfin-elf... 

I've sent Aldy instructions to access an AWS instance I've set up for
debugging.