[Bug bootstrap/103306] parallel build hangs since r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||xry111 at mengyan1223 dot wang

--- Comment #7 from Jakub Jelinek  ---
I guess that means the r12-5234 change is incorrect, we don't or shouldn't
require that a user has installed all the headers that have fixincl rules, the
traditional behavior has been that it fixes up those headers that user has
installed and skips the others.

[Bug middle-end/103309] [12 Regression] Random gcc/system.h:784:34: error: section type conflict

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug target/103307] Unused "%!" before return

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Fixed.

[Bug bootstrap/103306] parallel build hangs since r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

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

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||11.2.0, 8.2.0
Version|8.2.0   |11.2.0
 CC||jason at gcc dot gnu.org
   Keywords||ABI

--- Comment #2 from Richard Biener  ---
Maybe an issue in the C++ layout engine.

[Bug bootstrap/103306] parallel build hangs since r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #6 from Zdenek Sojka  ---
With 04c5a91d068c4ca2f09c2bc206fce00db9d1790b reverted, the output is:

$ grep -C5 'Cannot access ' gcccompile-REVERT.log 
Applying io_quotes_useto xorg/xorgVersion.h
Applying io_quotes_useto xorg/xf86Module.h
Applying strict_ansi_only to xorg/compiler.h
Fixed:  xorg/compiler.h
Quoted includes in xorg/compiler.h
Cannot access CL/cl_ext.h from /usr/include
error 2 (No such file or directory)
Cannot access CL/cl_gl_ext.h from /usr/include
error 2 (No such file or directory)
Cannot access CL/cl_gl.h from /usr/include
error 2 (No such file or directory)
Cannot access CL/cl.h from /usr/include
error 2 (No such file or directory)
Cannot access CL/cl_platform.h from /usr/include
error 2 (No such file or directory)
Cannot access CL/opencl.h from /usr/include
error 2 (No such file or directory)
Applying io_quotes_defto SDL2/SDL_version.h
Applying io_quotes_defto libssh/libssh_version.h
Applying io_quotes_useto libssh/libssh_version.h
Applying io_quotes_useto vulkan/vulkan_core.h
Applying io_quotes_defto
libsoup-2.4/libsoup/soup-websocket-connection.h
Cannot access cblas.h from /usr/include
error 2 (No such file or directory)
Applying io_quotes_useto fuse3/fuse_common.h
Applying io_quotes_defto mozjs-78/mozilla/HelperMacros.h
Applying io_quotes_useto brotli/port.h
Applying io_quotes_defto wx-3.0-gtk3/wx/variant.h

eg. we don't give up after the first failure

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

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |12.0
   Priority|P3  |P1
 CC||rguenth at gcc dot gnu.org

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I will have a look.

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.0|---

[Bug c++/103291] [11/12 Regression] #pragma gcc visibility is lost for external decls declared inside a function

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug fortran/103285] [DEC] ICE in output_constructor_regular_field, at varasm.c:5514

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
(gdb) p debug_generic_expr (exp)
{.c="abc ", .d={0B, 0B}, .e=3}

Confirmed.  The .d elements have the wrong type/size.

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
I will have a look

[Bug target/103252] questionable codegen with kmovd

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Hongtao.liu  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Jason A. Donenfeld from comment #2)
> > Here's a more minimal test case: https://gcc.godbolt.org/z/15hnsb6of
> 
> kmovd   k0, ecx
> mov ecx, DWORD PTR __libc_tsd_CTYPE_B@gotntpoff[ebx]
> kmovd   eax, k0
> mov ecx, DWORD PTR gs:[ecx]
> testBYTE PTR 1[ecx+eax*2], 32
> 
> vs:
> 
> mov ecx, DWORD PTR __libc_tsd_CTYPE_B@gotntpoff[ebx]
> mov ecx, DWORD PTR gs:[ecx]
> testBYTE PTR 1[ecx+edx*2], 32
> 

Why cprop_hardreg can't handle this?

[Bug bootstrap/103306] parallel build hangs since r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #5 from Zdenek Sojka  ---
$ make --version
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ grep -C5 'Cannot access ' gcccompile.log 
Applying io_quotes_useto xorg/xorgVersion.h
Applying io_quotes_useto xorg/xf86Module.h
Applying strict_ansi_only to xorg/compiler.h
Fixed:  xorg/compiler.h
Quoted includes in xorg/compiler.h
Cannot access CL/cl_ext.h: No such file or directory
Cleaning up unneeded directories:
fixincludes is done
echo timestamp > stmp-fixinc
if [ -d include ] ; then true; else mkdir include; chmod a+rx include; fi
if [ -d include-fixed ] ; then true; else mkdir include-fixed; chmod a+rx
include-fixed; fi

I might be hitting the "Some really strange error happened." situation

Disabling ccache does not help.

Reverting the fixincludes patch on current master (r12-5347) fixes the parallel
build for me.

[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 #14 from Hongtao.liu  ---
(In reply to H.J. Lu from comment #11)
> (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
It looks like gcc won't generate kmovq  foo@tlsld(%rip), %k0, but only leaq
 ("lea{q}\t{%&@tlsld(%%rip), %%rdi|rdi, %&@tlsld[rip]}", operands);

[Bug c++/55227] designated initializer for char array by string constant

[wjwray at gmail dot com via Gcc-bugs]

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

Will Wray  changed:

   What|Removed |Added

  Attachment #51828|0   |1
is obsolete||

--- Comment #14 from Will Wray  ---
Created attachment 51829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51829=edit
V2 Patch Nov 17

[Bug c++/55227] designated initializer for char array by string constant

[wjwray at gmail dot com via Gcc-bugs]

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

Will Wray  changed:

   What|Removed |Added

  Attachment #51737|0   |1
is obsolete||

--- Comment #13 from Will Wray  ---
Created attachment 51828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51828=edit
v2 patch Nov 17

Incorporates Marek's Nov 15 review comments.

[Bug libstdc++/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #8 from cqwrteur  ---
Created attachment 51827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51827=edit
Patch for fixing this issue

LOL. it bloats my mind. WHY WHY WHY are

 # DLL is installed to $(libdir)/../bin by postinstall_cmds

Twice in libstdc++'s configure?

We need a full-on cleanup on GCC source, please.

[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte

[amodra at gmail dot com via Gcc-bugs]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #7 from Alan Modra  ---
(In reply to acsawdey from comment #2)
> From the reload dump:
No, that's too late.  In the ira dump gcc has already chosen a vsx reg.  See
r120.

Disposition:
0:r117 l0 33:r118 l0 42:r119 l0 91:r120 l032
4:r121 l0 35:r122 l0 4

[Bug c/103310] null comparison with a weak symbol eliminated

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

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

Martin Sebor  changed:

   What|Removed |Added

  Component|middle-end  |c

--- Comment #1 from Martin Sebor  ---
The test case below shows that storing the address of the alias in a local
pointer avoids the problem.  The dumps show that the problem is in the front
end which folds the test of the address of the weak symbol to true.

$ cat pr103310.c && gcc -Wall -O2 -S -fdump-tree-original=/dev/stdout
-fdump-tree-optimized=/dev/stdout pr103310.c
extern void alias (void);

void call_alias (void)
{
  __builtin_printf ("in %s: alias = %p\n", __func__, alias);

  if (alias)
alias ();
}

void call_ptr_alias (void)
{
  void (*p)(void) = alias;

  __builtin_printf ("in %s: alias = %p\n", __func__, p);

  if (p)
p ();
}

extern void alias (void)  __attribute__((weak));
pr103310.c: In function ‘call_alias’:
pr103310.c:7:7: warning: the address of ‘alias’ will always evaluate as ‘true’
[-Waddress]
7 |   if (alias)
  |   ^

;; Function call_alias (null)
;; enabled by -tree-original


{
  static const char __func__[11] = "call_alias";

static const char __func__[11] = "call_alias";
  __builtin_printf ((const char *) "in %s: alias = %p\n", (const char *)
&__func__, alias);
  if (1)
{
  alias ();
}
}


;; Function call_ptr_alias (null)
;; enabled by -tree-original


{
  void (*) (void) p = alias;
  static const char __func__[15] = "call_ptr_alias";

static const char __func__[15] = "call_ptr_alias";
void (*) (void) p = alias;
  __builtin_printf ((const char *) "in %s: alias = %p\n", (const char *)
&__func__, p);
  if (p != 0B)
{
  p ();
}
}


;; Function call_alias (call_alias, funcdef_no=0, decl_uid=1945, cgraph_uid=1,
symbol_order=0)

void call_alias ()
{
  static const char __func__[11] = "call_alias";

   [local count: 1073741824]:
  __builtin_printf ("in %s: alias = %p\n", &__func__, alias);
  alias (); [tail call]
  return;

}



;; Function call_ptr_alias (call_ptr_alias, funcdef_no=1, decl_uid=1949,
cgraph_uid=2, symbol_order=1)

Removing basic block 5
void call_ptr_alias ()
{
  static const char __func__[15] = "call_ptr_alias";

   [local count: 1073741824]:
  __builtin_printf ("in %s: alias = %p\n", &__func__, alias);
  if (alias != 0B)
goto ; [53.47%]
  else
goto ; [46.53%]

   [local count: 574129753]:
  alias (); [tail call]

   [local count: 1073741824]:
  return;

}

[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 #16 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #15)
> Reopened :-(
> 
> I have a patch to make clang happy, but I think what we really want is a
> language change.

hi jwakely. i am trying to add a new patch to ignore copying DLLs to
../$(libdir)/bin if we are build gcc with multilibs (since 32 bits dlls
overrides 64 bits dlls). libgcc does not copy dlls either. do you think that is
appropriate?

[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

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

--- Comment #15 from Jonathan Wakely  ---
Reopened :-(

I have a patch to make clang happy, but I think what we really want is a
language change.

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

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

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

--- Comment #3 from Eric Gallager  ---
Along these lines, there's also some non-portable usage of `expr` in the file,
too (which I brought up on IRC), but I forget what exactly it was...

[Bug tree-optimization/55177] missed optimizations with __builtin_bswap

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #25 from Andrew Pinski  ---
Fixed fully in GCC 12.

[Bug tree-optimization/55177] missed optimizations with __builtin_bswap

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

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

Bug 103228 Summary: [9/10/11/12 Regression] missed optimization with |^ at the 
gimple level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103228

   What|Removed |Added

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

[Bug tree-optimization/103228] [9/10/11/12 Regression] missed optimization with |^ at the gimple level

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|9.5 |12.0

--- Comment #8 from Andrew Pinski  ---
Fixed in GCC 12, not worth the backport really.

[Bug tree-optimization/55177] missed optimizations with __builtin_bswap

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

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

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

https://gcc.gnu.org/g:32221357007666124409ec3ee0d3a1cf263ebc9e

commit r12-5358-g32221357007666124409ec3ee0d3a1cf263ebc9e
Author: Andrew Pinski 
Date:   Mon Nov 15 09:31:20 2021 +

Fix PR tree-optimization/103228 and 103228: folding of (type) X op CST
where type is a nop convert

Currently we fold (type) X op CST into (type) (X op ((type-x) CST)) when
the conversion widens
but not when the conversion is a nop. For the same reason why we move the
widening conversion
(the possibility of removing an extra conversion), we should do the same if
the conversion is a
nop.

Committed as approved with the comment change.

PR tree-optimization/103228
PR tree-optimization/55177

gcc/ChangeLog:

* match.pd ((type) X bitop CST): Also do this
transformation for nop conversions.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr103228-1.c: New test.
* gcc.dg/tree-ssa/pr55177-1.c: New test.

[Bug tree-optimization/103228] [9/10/11/12 Regression] missed optimization with |^ at the gimple level

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

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

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

https://gcc.gnu.org/g:32221357007666124409ec3ee0d3a1cf263ebc9e

commit r12-5358-g32221357007666124409ec3ee0d3a1cf263ebc9e
Author: Andrew Pinski 
Date:   Mon Nov 15 09:31:20 2021 +

Fix PR tree-optimization/103228 and 103228: folding of (type) X op CST
where type is a nop convert

Currently we fold (type) X op CST into (type) (X op ((type-x) CST)) when
the conversion widens
but not when the conversion is a nop. For the same reason why we move the
widening conversion
(the possibility of removing an extra conversion), we should do the same if
the conversion is a
nop.

Committed as approved with the comment change.

PR tree-optimization/103228
PR tree-optimization/55177

gcc/ChangeLog:

* match.pd ((type) X bitop CST): Also do this
transformation for nop conversions.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr103228-1.c: New test.
* gcc.dg/tree-ssa/pr55177-1.c: New test.

[Bug middle-end/103309] [12 Regression] Random gcc/system.h:784:34: error: section type conflict

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

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

--- Comment #5 from H.J. Lu  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to H.J. Lu from comment #3)
> > I first ran into it with r12-5074.  I am using GCC 11.2.1 from Fedora 35
> > and binutils master branch.   For r12-5074, the only change on the machine
> > is the GCC source.
> 
> r12-5074 does not even touch anything used for x86_64 builds either ...

My tester doesn't check every commit.  This failure comes and goes at
random.  I have no idea when it was introduced.

[Bug middle-end/103309] [12 Regression] Random gcc/system.h:784:34: error: section type conflict

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to H.J. Lu from comment #3)
> I first ran into it with r12-5074.  I am using GCC 11.2.1 from Fedora 35
> and binutils master branch.   For r12-5074, the only change on the machine
> is the GCC source.

r12-5074 does not even touch anything used for x86_64 builds either ...

[Bug middle-end/103309] [12 Regression] Random gcc/system.h:784:34: error: section type conflict

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

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

--- Comment #3 from H.J. Lu  ---
I first ran into it with r12-5074.  I am using GCC 11.2.1 from Fedora 35
and binutils master branch.   For r12-5074, the only change on the machine
is the GCC source.

[Bug bootstrap/103306] parallel build hangs since r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Also what version of make are you using?
Can you provide the full log of where it hangs?

[Bug middle-end/103309] [12 Regression] Random gcc/system.h:784:34: error: section type conflict

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |WAITING
  Component|bootstrap   |middle-end
 Target||x86_64-linux

--- Comment #2 from Andrew Pinski  ---
Hmm, since this is stage2, that might mean stage 1 is being miscompiled.

What GCC/binutils version are you starting with?
Do you know when it started to fail like this?

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #16 from Jeffrey A. Law  ---
Fixed years ago.

[Bug preprocessor/103026] Implement warning for Unicode bidi override characters [CVE-2021-42574]

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-5356-gbef32d4a28595e933f24fef378cf052a30b674a7
Author: David Malcolm 
Date:   Tue Nov 2 15:45:22 2021 -0400

libcpp: capture and underline ranges in -Wbidi-chars= [PR103026]

This patch converts the bidi::vec to use a struct so that we can
capture location_t values for the bidirectional control characters.

Before:

  Wbidi-chars-1.c: In function âmainâ:
  Wbidi-chars-1.c:6:43: warning: unpaired UTF-8 bidirectional control
character detected [-Wbidi-chars=]
  6 | /* } if (isAdmin)  begin
admins only */
|  
^
  Wbidi-chars-1.c:9:28: warning: unpaired UTF-8 bidirectional control
character detected [-Wbidi-chars=]
  9 | /* end admins only  { */
|^

After:

  Wbidi-chars-1.c: In function âmainâ:
  Wbidi-chars-1.c:6:43: warning: unpaired UTF-8 bidirectional control
characters detected [-Wbidi-chars=]
  6 | /* } if (isAdmin)  begin
admins only */
|      
^
|   |   |  
|
|   |   |  
end of bidirectional context
|   U+202E (RIGHT-TO-LEFT OVERRIDE) U+2066
(LEFT-TO-RIGHT ISOLATE)
  Wbidi-chars-1.c:9:28: warning: unpaired UTF-8 bidirectional control
characters detected [-Wbidi-chars=]
  9 | /* end admins only  { */
|    ^
||  ||
||  |end of bidirectional
context
||  U+2066 (LEFT-TO-RIGHT ISOLATE)
|U+202E (RIGHT-TO-LEFT OVERRIDE)

Signed-off-by: David Malcolm 

gcc/testsuite/ChangeLog:
PR preprocessor/103026
* c-c++-common/Wbidi-chars-ranges.c: New test.

libcpp/ChangeLog:
PR preprocessor/103026
* lex.c (struct bidi::context): New.
(bidi::vec): Convert to a vec of context rather than unsigned
char.
(bidi::ctx_at): Rename to...
(bidi::pop_kind_at): ...this and reimplement for above change.
(bidi::current_ctx): Update for change to vec.
(bidi::current_ctx_ucn_p): Likewise.
(bidi::current_ctx_loc): New.
(bidi::on_char): Update for usage of context struct.  Add "loc"
param and pass it when pushing contexts.
(get_location_for_byte_range_in_cur_line): New.
(get_bidi_utf8): Rename to...
(get_bidi_utf8_1): ...this, reintroducing...
(get_bidi_utf8): ...as a wrapper, setting *OUT when the result is
not NONE.
(get_bidi_ucn): Rename to...
(get_bidi_ucn_1): ...this, reintroducing...
(get_bidi_ucn): ...as a wrapper, setting *OUT when the result is
not NONE.
(class unpaired_bidi_rich_location): New.
(maybe_warn_bidi_on_close): Use unpaired_bidi_rich_location when
reporting on unpaired bidi chars.  Split into singular vs plural
spellings.
(maybe_warn_bidi_on_char): Pass in a location_t rather than a
const uchar * and use it when emitting warnings, and when calling
bidi::on_char.
(_cpp_skip_block_comment): Capture location when kind is not NONE
and pass it to maybe_warn_bidi_on_char.
(skip_line_comment): Likewise.
(forms_identifier_p): Likewise.
(lex_raw_string): Likewise.
(lex_string): Likewise.

Signed-off-by: David Malcolm 

[Bug middle-end/98503] [11/12 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #16 from Martin Sebor  ---
*** Bug 103292 has been marked as a duplicate of this bug. ***

[Bug middle-end/103292] [12 regression] xorg-server-1.20.13 -Werror=array-bounds false positive on unions

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE
  Component|c   |middle-end
 Blocks||56456
 CC||jeffreyalaw at gmail dot com

--- Comment #3 from Martin Sebor  ---
The originally intended purpose of this instance of -Warray-bounds was to warn
for accesses to smaller buffers by larger lvalues, like in this function:

struct A { int i; };
struct B { long j; };

struct B* make_B_from_A (const struct A *p)
{
  struct B *q = __builtin_malloc (sizeof *p);   // should be sizeof *q
  q->j = p->i;
  return q;
}

Here a warning should be issued regardless of whether -fstrict-aliasing is in
effect because the access is out of bounds.  That the warning also triggers in
instances when the problem isn't one of an out-of-bounds access but rather an
aliasing violation was incidental (i.e., I didn't set out with that as a goal),
but because -Wstrict-aliasing in GCC is very limited, seemed like a bonus.

So an argument could be (and in pr98503 in fact was) made that the instances of
-Warray-bounds where the ultimate access is strictly in bounds should be
replaced by one of -Wstrict-aliasing, which is enabled only when
-fstrict-aliasing is in effect.  I agreed and submitted a patch to do that:

  https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564483.html

Regrettably, the change was rejected.  I CC the reviewer for his comments.

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug preprocessor/103026] Implement warning for Unicode bidi override characters [CVE-2021-42574]

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-5355-g1a7f2c0774129750fdf73e9f1b78f0ce983c9ab3
Author: David Malcolm 
Date:   Tue Nov 2 09:54:32 2021 -0400

libcpp: escape non-ASCII source bytes in -Wbidi-chars= [PR103026]

This flags rich_locations associated with -Wbidi-chars= so that
non-ASCII bytes will be escaped when printing the source lines
(using the diagnostics support I added in
r12-4825-gbd5e882cf6e0def3dd1bc106075d59a303fe0d1e).

In particular, this ensures that the printed source lines will
be pure ASCII, and thus the visual ordering of the characters
will be the same as the logical ordering.

Before:

  Wbidi-chars-1.c: In function âmainâ:
  Wbidi-chars-1.c:6:43: warning: unpaired UTF-8 bidirectional control
character detected [-Wbidi-chars=]
  6 | /*â® } â¦if (isAdmin)⩠⦠begin admins only */
|   ^
  Wbidi-chars-1.c:9:28: warning: unpaired UTF-8 bidirectional control
character detected [-Wbidi-chars=]
  9 | /* end admins only â® { â¦*/
|^

  Wbidi-chars-11.c:6:15: warning: UTF-8 vs UCN mismatch when closing a
context by "U+202C (POP DIRECTIONAL FORMATTING)" [-Wbidi-chars=]
  6 | int LRE_âª_PDF_\u202c;
|   ^
  Wbidi-chars-11.c:8:19: warning: UTF-8 vs UCN mismatch when closing a
context by "U+202C (POP DIRECTIONAL FORMATTING)" [-Wbidi-chars=]
  8 | int LRE_\u202a_PDF_â¬_;
|   ^
  Wbidi-chars-11.c:10:28: warning: UTF-8 vs UCN mismatch when closing a
context by "U+202C (POP DIRECTIONAL FORMATTING)" [-Wbidi-chars=]
 10 | const char *s1 = "LRE_âª_PDF_\u202c";
|^
  Wbidi-chars-11.c:12:33: warning: UTF-8 vs UCN mismatch when closing a
context by "U+202C (POP DIRECTIONAL FORMATTING)" [-Wbidi-chars=]
 12 | const char *s2 = "LRE_\u202a_PDF_â¬";
| ^

After:

  Wbidi-chars-1.c: In function âmainâ:
  Wbidi-chars-1.c:6:43: warning: unpaired UTF-8 bidirectional control
character detected [-Wbidi-chars=]
  6 | /* } if (isAdmin)  begin
admins only */
|  
^
  Wbidi-chars-1.c:9:28: warning: unpaired UTF-8 bidirectional control
character detected [-Wbidi-chars=]
  9 | /* end admins only  { */
|^

  Wbidi-chars-11.c:6:15: warning: UTF-8 vs UCN mismatch when closing a
context by "U+202C (POP DIRECTIONAL FORMATTING)" [-Wbidi-chars=]
  6 | int LRE__PDF_\u202c;
|   ^
  Wbidi-chars-11.c:8:19: warning: UTF-8 vs UCN mismatch when closing a
context by "U+202C (POP DIRECTIONAL FORMATTING)" [-Wbidi-chars=]
  8 | int LRE_\u202a_PDF__;
|   ^
  Wbidi-chars-11.c:10:28: warning: UTF-8 vs UCN mismatch when closing a
context by "U+202C (POP DIRECTIONAL FORMATTING)" [-Wbidi-chars=]
 10 | const char *s1 = "LRE__PDF_\u202c";
|^
  Wbidi-chars-11.c:12:33: warning: UTF-8 vs UCN mismatch when closing a
context by "U+202C (POP DIRECTIONAL FORMATTING)" [-Wbidi-chars=]
 12 | const char *s2 = "LRE_\u202a_PDF_";
| ^

libcpp/ChangeLog:
PR preprocessor/103026
* lex.c (maybe_warn_bidi_on_close): Use a rich_location
and call set_escape_on_output (true) on it.
(maybe_warn_bidi_on_char): Likewise.

Signed-off-by: David Malcolm 

[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

--- Comment #3 from Andrew Pinski  ---
(In reply to hubicka from comment #2)
> Needs -O2  -floop-unroll-and-jam   --param early-inlining-insns=14
> to fail, so I guess it may be issue with unrol-and-jam.

The major difference I see between GCC 11 and GCC 12 is how tree-loop-im
handles the load/store of a and c. In GCC 11, it was an unconditional move of
the store of a and c while in GCC 12 we get some interesting branches:
   [local count: 35059055]:
  # a_lsm.21_25 = PHI <_20(D)(6), _15(8)>
  # a_lsm_flag.22_8 = PHI <0(6), 1(8)>
  # c_lsm.23_22 = PHI <0(6), _5(8)>
  if (c_lsm.23_22 <= 2)
goto ; [94.50%]
  else
goto ; [5.50%]

   [local count: 1928248]:
  # a_lsm_flag.22_14 = PHI 
  # a_lsm.21_28 = PHI 
  c_lsm.23_27 = 3;
  if (a_lsm_flag.22_14 != 0)
goto ; [66.67%]
  else
goto ; [33.33%]

   [local count: 1285499]:
  c = c_lsm.23_27;

   [local count: 1285499]:
  if (a_lsm_flag.22_14 != 0)
goto ; [66.67%]
  else
goto ; [33.33%]

   [local count: 856999]:
  a = a_lsm.21_28;

   [local count: 1928248]:

[Bug tree-optimization/102759] [12 Regression] ICE: Segmentation fault in maybe_check_access_sizes since r12-2976-gb48d4e6818674898

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed.

[Bug tree-optimization/102759] [12 Regression] ICE: Segmentation fault in maybe_check_access_sizes since r12-2976-gb48d4e6818674898

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r12-5354-gea9e0d6c27405d256b4888e9e860e469037c911d
Author: Martin Sebor 
Date:   Wed Nov 17 15:09:23 2021 -0700

Avoid pathological function redeclarations when checking access sizes
[PR102759].

Resolves:
PR tree-optimization/102759 - ICE: Segmentation fault in
maybe_check_access_sizes since r12-2976-gb48d4e6818674898

gcc/ChangeLog:

PR tree-optimization/102759
* gimple-array-bounds.cc (build_printable_array_type): Move...
* gimple-ssa-warn-access.cc (build_printable_array_type): Avoid
pathological function redeclarations that remove a previously
declared prototype.
Improve formatting of function arguments in informational notes.
* pointer-query.cc (build_printable_array_type): ...to here.
* pointer-query.h (build_printable_array_type): Declared.

gcc/testsuite/ChangeLog:

PR tree-optimization/102759
* gcc.dg/Warray-parameter-10.c: New test.
* gcc.dg/Wstringop-overflow-82.c: New test.

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #1 from Andrew Pinski  ---

#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::uintptr_t t = (std::uintptr_t)this;
printf("this:%lx\n", (long)(t&0xff));
printf("this->PureInterfaceHandler:%lx\n",
(long)((std::uintptr_t)(PureInterfaceHandler*)this&0xff));
(printf("this->%s:%lx\n", typeid
(MsgCategoryNotifierS).name(),(long)((std::uintptr_t)(MsgCategoryNotifierS*)this&0xff)),...);
std::cout << __PRETTY_FUNCTION__  << std::endl;
}
};


struct Base1{
Base1(){
std::cout << __PRETTY_FUNCTION__  << std::endl;
std::uintptr_t t = (std::uintptr_t)
printf("%lx\n", (long)(t&0xff));
}
virtual ~Base1(){
std::uintptr_t t = (std::uintptr_t)
printf("%lx\n", (long)(t&0xff));
std::cout << __PRETTY_FUNCTION__  << std::endl;
}
largeAligned aligned1;
};


struct Base2{
Base2(){
std::cout << __PRETTY_FUNCTION__  << std::endl;
std::uintptr_t t = (std::uintptr_t)
printf("%lx\n", (long)(t&0xff));
}
virtual ~Base2(){
std::uintptr_t t = (std::uintptr_t)
printf("%lx\n", (long)(t&0xff));
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;
}

Looks like there is some wrong alignment information feed to the rest of the
compiler.
this->9ICategoryI5Base2E:b8
this->9ICategoryI5Base1E:c0

[Bug middle-end/103310] New: null comparison with a weak symbol eliminated

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

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

Bug ID: 103310
   Summary: null comparison with a weak symbol eliminated
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following test case was prompted by the discussion in the review of a
-Waddress enhancement:
  https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584749.html

Before folding the test in call_alias() to true, GCC issues a -Waddress.  At
runtime the program then crashes.  In the review Jason suggests GCC should
reject the subsequent declaration of the alias with an error because it has
been used (and because the test for null may have been eliminated).

cat a.c && gcc -DUSE_ALIAS -O2 -Wall -c a.c && gcc -O2 -Wall a.c a.o && ./a.out
#if USE_ALIAS

extern void alias (void);

void call_alias (void)
{
  __builtin_printf ("in %s: alias = %p\n", __func__, alias);

  if (alias)
alias ();
}

extern void alias (void)  __attribute__((weak));

#else

extern void alias (void)  __attribute__((weak));   // not defined

extern void call_alias (void);

int main (void)
{
  __builtin_printf ("in %s: alias = %p\n", __func__, alias);

  call_alias ();
}

#endif
a.c: In function ‘call_alias’:
a.c:9:7: warning: the address of ‘alias’ will always evaluate as ‘true’
[-Waddress]
9 |   if (alias)
  |   ^
in main: alias = (nil)
in call_alias: alias = (nil)
Segmentation fault (core dumped)

[Bug c/103292] [12 regression] xorg-server-1.20.13 -Werror=array-bounds false positive on unions

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

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

--- Comment #2 from Sergei Trofimovich  ---
(In reply to Martin Sebor from comment #1)
> The warning is intended.  The program allocates an object of a size that's
> smaller than the size of the type used to access it:
> 
>pPicture->pSourcePict = (union _SourcePict*) malloc(sizeof(struct
> _PictSolidFill));
> pPicture->pSourcePict->type = 0;
> 
> It's not valid to access an object of one type using an lvalue of another. 
> In simple cases GCC diagnoses violations of this requirement by
> -Wstrict-aliasing.  -Warray-bounds doesn't detect aliasing violations but it
> does detect a subset of the problem that's apparent when the size of the
> lvalue's type is greater than the size of the object.  The object must be
> big enough for the whole lvalue, even if the accessed member is within the
> bounds of the smaller object.
> 
> The following is a smaller test case that should make the issue clearer. 
> See also pr102151 for a similar report.
> 
> $ cat a.c && gcc -O2 -S -Wall a.c
> struct A { char a[1]; };
> struct B { char a[2]; };
> union U { struct A a; struct B b; };
> 
> void* f (void)
> {
>   union U *p = __builtin_malloc (sizeof (struct A));
>   p->a.a[0] = 0;
>   return p;
> }
> a.c: In function ‘f’:
> a.c:8:4: warning: array subscript ‘union U[0]’ is partly outside array
> bounds of ‘unsigned char[1]’ [-Warray-bounds]
> 8 |   p->a.a[0] = 0;
>   |^~
> a.c:7:16: note: object of size 1 allocated by ‘__builtin_malloc’
> 7 |   union U *p = __builtin_malloc (sizeof (struct A));
>   |^~~~

Aha, that makes sense. Filed upstream report as
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1256

Related question:

It sounds like this diagnostic is somewhat related to -fstrict-aliasing. xorg
builds with -fno-strict-aliasing. Would it be fair to say the access in that
case is reasonable and -Warray-bounds is a false positive?

[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte

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

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

--- Comment #6 from Segher Boessenkool  ---
Not only is this a missed-optimization, it also is a regression (in GCC 10
already).  It seems like the root cause here may be the same as in PR102169.

[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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Keywords||missed-optimization

[Bug target/102952] New code-gen options for retpolines and straight line speculation

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

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

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

https://gcc.gnu.org/g:53a643f8568067d7700a9f2facc8ba39974973d3

commit r12-5353-g53a643f8568067d7700a9f2facc8ba39974973d3
Author: H.J. Lu 
Date:   Wed Oct 27 07:48:54 2021 -0700

x86: Add -mharden-sls=[none|all|return|indirect-branch]

Add -mharden-sls= to mitigate against straight line speculation (SLS)
for function return and indirect branch by adding an INT3 instruction
after function return and indirect branch.

gcc/

PR target/102952
* config/i386/i386-opts.h (harden_sls): New enum.
* config/i386/i386.c (output_indirect_thunk): Mitigate against
SLS for function return.
(ix86_output_function_return): Likewise.
(ix86_output_jmp_thunk_or_indirect): Mitigate against indirect
branch.
(ix86_output_indirect_jmp): Likewise.
(ix86_output_call_insn): Likewise.
* config/i386/i386.opt: Add -mharden-sls=.
* doc/invoke.texi: Document -mharden-sls=.

gcc/testsuite/

PR target/102952
* gcc.target/i386/harden-sls-1.c: New test.
* gcc.target/i386/harden-sls-2.c: Likewise.
* gcc.target/i386/harden-sls-3.c: Likewise.
* gcc.target/i386/harden-sls-4.c: Likewise.
* gcc.target/i386/harden-sls-5.c: Likewise.

[Bug fortran/101329] ICE: Invalid expression in gfc_element_size

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Packaged: https://gcc.gnu.org/pipermail/fortran/2021-November/057029.html

[Bug target/103307] Unused "%!" before return

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

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

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

https://gcc.gnu.org/g:8e410de43ce039bbe08f1e0195e3b6ec24f68cae

commit r12-5352-g8e410de43ce039bbe08f1e0195e3b6ec24f68cae
Author: H.J. Lu 
Date:   Wed Nov 17 11:41:12 2021 -0800

x86: Remove "%!" before ret

Before MPX was removed, "%!" was mapped to

case '!':
  if (ix86_bnd_prefixed_insn_p (current_output_insn))
fputs ("bnd ", file);
  return;

After CET was added and MPX was removed, "%!" was mapped to

   case '!':
  if (ix86_notrack_prefixed_insn_p (current_output_insn))
fputs ("notrack ", file);
  return;

ix86_notrack_prefixed_insn_p always returns false on ret since the
notrack prefix is only for indirect branches.  Remove the unused "%!"
before ret.

PR target/103307
* config/i386/i386.c (ix86_code_end): Remove "%!" before ret.
(ix86_output_function_return): Likewise.
* config/i386/i386.md (simple_return_pop_internal): Likewise.

[Bug tree-optimization/100740] [9/10/11/12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r9-4145-ga81e2c6240655f60

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pallansson at gmail dot com

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

[Bug tree-optimization/103308] gcc regression after version 8, simple double loop exiting early with optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 100740.

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

[Bug bootstrap/103309] [12 Regression] Random gcc/system.h:784:34: error: section type conflict

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
The build error can happen on different source files.  But it always points
to

https://gcc.gnu.org/pipermail/gcc-regression/2021-November/075734.html

In member function ‘hash_table::value_type*
hash_table::alloc_entries(size_t) const [with
Descriptor = hash_map >::hash_entry; bool Lazy =
false; Allocator = xcallocator]’,
inlined from ‘void hash_table::expand() [with
Descriptor = hash_map >::hash_entry; bool Lazy =
false; Allocator = xcallocator]’ at ../../src-master/gcc/hash-table.h:802:40:
../../src-master/gcc/system.h:784:34: error: section type conflict with ‘void
hash_table::expand() [with Descriptor =
hash_map >::hash_entry; bool Lazy = false;
Allocator = xcallocator]’
  784 |((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0
: 0))
  |  ^~
../../src-master/gcc/hash-table.h:715:3: note: in expansion of macro
‘gcc_assert’
  715 |   gcc_assert (nentries != NULL);
  |   ^~

[Bug bootstrap/103306] parallel build hangs since r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #3 from Zdenek Sojka  ---
Thank you for having a look at this. I am using btrfs.
I will re-check with ccache disabled if this commit is really the one causing
the issue for me.

[Bug analyzer/103032] false positive diagnostic from -fanalyzer about double-free

[rhialto at falu dot nl via Gcc-bugs]

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

--- Comment #2 from Olaf 'Rhialto' Seibert  ---
I tried my case on a different system with a later gcc version, and it didn't
show the problems I reported. It did however show the diagnostics you showed,
and I think it is correct. strdup() could indeed return NULL.

I don't know how the gcc policy about backporting fixes is. If you don't do it
(and this one isn't super important, just somewhat misleading), then this
report can be closed.

If you might consider a backport, then of course not :)

[Bug analyzer/102779] gcc.dg/analyzer/capacity-1.c etc.FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #4 from Rainer Orth  ---
It did indeed on both Solaris/SPARC and x86.  Thanks.

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

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

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

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

https://gcc.gnu.org/g:425369bf3068a9f840d1c2f04a4d4c38e924d4dc

commit r12-5351-g425369bf3068a9f840d1c2f04a4d4c38e924d4dc
Author: Jan Hubicka 
Date:   Wed Nov 17 22:04:26 2021 +0100

Fix modref summary streaming

Fixes bug in streaming in modref access tree that now cause a failure
of gamess benchmark.  The bug is quite old (present in GCC11 release) but
it
needs quite interesting series of events to manifest. In particular
 1) At lto time ISRA turns some parameters passed by reference to scalar
 2) At lto time modref computes summaries for old parameters and then
updates
them but does so quite stupidly believing that the load from parameters
are now unkonwn loads (rather than optimized out).
This renders summary not very useful since it thinks every memory
aliasing
int is now accssed (as opposed as parameter dereference)
 3) At stream in we notice too early that summary is useless, set
every_access
flag and drop the list.  However while reading rest of the summary we
overwrite the flag back to 0 which makes us to lose part of summary.
 4) right selection of partitions needs to be done to avoid late modref
from
recalculating and thus fixing the summary.

This patch fixes the stream in bug, however we also should fix updating of
summaries.

gcc/ChangeLog:

2021-11-17  Jan Hubicka  

PR ipa/103246
* ipa-modref.c (read_modref_records): Fix streaminig in of
every_access
flag.

[Bug bootstrap/103309] New: [12 Regression] Random gcc/system.h:784:34: error: section type conflict

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

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

Bug ID: 103309
   Summary: [12 Regression] Random gcc/system.h:784:34: error:
section type conflict
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Linux/x86-64, I started getting:

/export/build/gnu/tools-build/gcc-gitlab/build-x86_64-linux/./prev-gcc/xg++
-B/export/build/gnu/tools-build/gcc-gitlab/build-x86_64-linux/./prev-gcc/
-B/usr/gcc-12.0.0-x86-64/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/export/build/gnu/tools-build/gcc-gitlab/build-x86_64-linux/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/export/build/gnu/tools-build/gcc-gitlab/build-x86_64-linux/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/export/build/gnu/tools-build/gcc-gitlab/build-x86_64-linux/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/export/build/gnu/tools-build/gcc-gitlab/build-x86_64-linux/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/libsupc++
-L/export/build/gnu/tools-build/gcc-gitlab/build-x86_64-linux/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/export/build/gnu/tools-build/gcc-gitlab/build-x86_64-linux/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c   -g -O2 -fchecking=1 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/export/gnu/import/git/gitlab/x86-gcc/gcc
-I/export/gnu/import/git/gitlab/x86-gcc/gcc/.
-I/export/gnu/import/git/gitlab/x86-gcc/gcc/../include
-I/export/gnu/import/git/gitlab/x86-gcc/gcc/../libcpp/include
-I/export/gnu/import/git/gitlab/x86-gcc/gcc/../libcody 
-I/export/gnu/import/git/gitlab/x86-gcc/gcc/../libdecnumber
-I/export/gnu/import/git/gitlab/x86-gcc/gcc/../libdecnumber/bid
-I../libdecnumber -I/export/gnu/import/git/gitlab/x86-gcc/gcc/../libbacktrace  
-o passes.o -MT passes.o -MMD -MP -MF ./.deps/passes.TPo
/export/gnu/import/git/gitlab/x86-gcc/gcc/passes.c
In file included from /export/gnu/import/git/gitlab/x86-gcc/gcc/passes.c:26:
In member function ??hash_table::value_type*
hash_table::alloc_entries(size_t) const [with
Descriptor = hash_map::hash_entry; bool Lazy =
false; Allocator = xcallocator]??,
inlined from ??void hash_table::expand() [with
Descriptor = hash_map::hash_entry; bool Lazy =
false; Allocator = xcallocator]?? at
/export/gnu/import/git/gitlab/x86-gcc/gcc/hash-table.h:802:40:
/export/gnu/import/git/gitlab/x86-gcc/gcc/system.h:784:34: error: section type
conflict with ??void hash_table::expand() [with
Descriptor = hash_map::hash_entry; bool Lazy =
false; Allocator = xcallocator]??
  784 |((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0
: 0))
  |  ^~
/export/gnu/import/git/gitlab/x86-gcc/gcc/hash-table.h:715:3: note: in
expansion of macro ??gcc_assert??
  715 |   gcc_assert (nentries != NULL);
  |   ^~
In file included from
/export/gnu/import/git/gitlab/x86-gcc/gcc/coretypes.h:482,
 from /export/gnu/import/git/gitlab/x86-gcc/gcc/passes.c:27:
/export/gnu/import/git/gitlab/x86-gcc/gcc/hash-table.h: In member function
??void hash_table::expand() [with Descriptor =
hash_map::hash_entry; bool Lazy = false;
Allocator = xcallocator]??:
/export/gnu/import/git/gitlab/x86-gcc/gcc/hash-table.h:779:1: note: ??void
hash_table::expand() [with Descriptor =
hash_map::hash_entry; bool Lazy = false;
Allocator = xcallocator]?? was declared here
  779 | hash_table::expand ()
  | ^~~
In file included from
/export/gnu/import/git/gitlab/x86-gcc/gcc/coretypes.h:474,
 from /export/gnu/import/git/gitlab/x86-gcc/gcc/expmed.c:26:
In function ??poly_uint16 mode_to_bytes(machine_mode)??,
inlined from ??typename if_nonpoly::type
GET_MODE_SIZE(const T&) [with T = scalar_int_mode]?? at
/export/gnu/import/git/gitlab/x86-gcc/gcc/machmode.h:647:24,
inlined from ??rtx_def* emit_store_flag_1(rtx, rtx_code, rtx, rtx,
machine_mode, int, int, machine_mode)?? at
/export/gnu/import/git/gitlab/x86-gcc/gcc/expmed.c:5724:56:
/export/gnu/import/git/gitlab/x86-gcc/gcc/machmode.h:550:49: warning:
??*(unsigned int*)((char*)_mode + offsetof(scalar_int_mode,
scalar_int_mode::m_mode))?? may be used uninitialized in this function
[-Wmaybe-uninitialized]
  550 |   ? mode_size_inline (mode) : mode_size[mode]);
  | ^~~~
/export/gnu/import/git/gitlab/x86-gcc/gcc/expmed.c: In function ??rtx_def*

[Bug c/103308] gcc regression after version 8, simple double loop exiting early with optimizations

[pallansson at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Per Allansson  ---
Created attachment 51826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51826=edit
early loop exit example

[Bug c/103308] New: gcc regression after version 8, simple double loop exiting early with optimizations

[pallansson at gmail dot com via Gcc-bugs]

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

Bug ID: 103308
   Summary: gcc regression after version 8, simple double loop
exiting early with optimizations
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pallansson at gmail dot com
  Target Milestone: ---

Picked up from here:
https://cboard.cprogramming.com/c-programming/180520-interesting-bug-gcc-9-above.html


I have tested gcc-9/10/11 as included in Ubuntu and they all give the same
results, as well as builds from gcc.git of latest gcc-11 and gcc-12, specific
results from gcc 11.1.0 in Ubuntu 21.04 below:

$ gcc-11 -Og -o el earlyloop.c
$ ./el
a=0, c=1
a=0, c=2
a=1, c=3
a=1, c=4
a=2, c=5
a=2, c=6
a=3, c=7
a=3, c=8
a=4, c=9
a=4, c=10
a=5, c=11
a=5, c=12
a=6, c=13
a=6, c=14
a=7, c=15
a=7, c=16
a=8, c=17
a=8, c=18
a=9, c=19
a=9, c=20
$ gcc-11 -O3 -o el earlyloop.c
$ ./el
a=0, c=1
a=0, c=2
a=1, c=3
$ gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.1.0-1ubuntu1~21.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-RPS7jb/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-RPS7jb/gcc-11-11.1.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~21.04)

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

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #2 from eggert at cs dot ucla.edu ---
(In reply to David Malcolm from comment #1)

> 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?

Yes there's a cast to void *, but no it doesn't free the storage. Instead, the
caller later is supposed to take ownership of the storage if it removes the
item from the hashtable, e.g., the caller can later do this:

   void *entry = hash_remove (pattern);
   free (entry);

where ENTRY will be the same pointer as STR in the sample code I gave earlier.
This means there's no leak in addpat per se.

[Bug tree-optimization/103168] Value numbering for PRE of pure functions can be improved

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

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

--- Comment #3 from Jan Hubicka  ---
This is simple (and fairly common) case we don't optimize
struct a {
int a;
static __attribute__ ((noinline))
int ret (int v) {return v;}

__attribute__ ((noinline))
int inca () {return a++;}
};
int
test()
{
struct a av;
av.a=1;
int val = av.ret (0) + av.inca();
av.a=2;
return val + av.ret(0) + av.inca();
}

what ret is const however becaue it is in COMDAT group we only detect it as
pure which makes GVN to give up on proving that its value did not change over
av.a=2 store.  We could easily work this out from modref summary (which says
that function makes no memory load)

[Bug bootstrap/103306] parallel build hangs since r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b

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

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

--- Comment #2 from Andrew Pinski  ---
Plus this change removes code which was questionable 樂.  And replaces it with
an abort. If the access is failing, then something is really wrong.

[Bug bootstrap/103306] parallel build hangs since r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b

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

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

--- Comment #1 from Andrew Pinski  ---
I have done a -j16 and -j24 build after this change on x86_64-linux with the
build directory on nfs mounted filesystem and got no hang.

What file system are you using?

[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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #18 from Aldy Hernandez  ---
Got it!

Confirmed.  I had disabled the optimization while exploring Tamar's comment #7.
 Ugh..

[Bug target/103307] New: Unused "%!" before return

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

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

Bug ID: 103307
   Summary: Unused "%!" before return
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386, x86-64

x86 backend has

i386.c:  output_asm_insn ("%!ret", NULL);
i386.c:return "%!ret";
i386.md:  "%!ret\t%0"

Before MPX was removed, "%!" was mapped to

case '!':
  if (ix86_bnd_prefixed_insn_p (current_output_insn))
fputs ("bnd ", file);
  return;

After CET was added and MPX was removed, "%!" was mapped to

   case '!':
  if (ix86_notrack_prefixed_insn_p (current_output_insn))
fputs ("notrack ", file);
  return;

ix86_notrack_prefixed_insn_p always returns false on RET since the
notrack prefix is only for indirect branches.  Therefore, "%!" before
RET is unused.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12 Regression]  |[11 Regression]
   |optimization breaks address |optimization breaks address
   |of struct member since  |of struct member since
   |r11-4984-g47923622c663ffad  |r11-4984-g47923622c663ffad

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

[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 #20 from Jan Hubicka  ---
linking with --dbg-cnt=ipa_cp_values:10 -flto-partition=one
--disable-tree-modref2 --dbg-cnt=ipa_mod_ref:836 -fdump-tree-all-details
-fdump-ipa-all-details is first that produces different results. Diff to 835
is:

diff -u 835/gamess.ltrans0.ltrans.113t.dse2 836/gamess.ltrans0.ltrans.113t.dse2
--- 835/gamess.ltrans0.ltrans.113t.dse2 2021-11-17 20:11:34.894715053 +0100
+++ 836/gamess.ltrans0.ltrans.113t.dse2 2021-11-17 20:12:40.387968675 +0100
@@ -14780,7 +14780,6 @@
 ipa-modref: call to dco.isra/287 does not use ref: kz alias sets: 4->4
 ipa-modref: call stmt dc_1560 = dco.isra (l_1973, m_1975, , , ,
la_1974, mu_1976, _513, _510, _507, _504, _501, _498);
 ipa-modref: call to dco.isra/287 does not use ref: jndx alias sets: 4->4
-***dbgcnt: upper limit 835 reached for ipa_mod_ref.***
 ipa-modref: call stmt dc_1560 = dco.isra (l_1973, m_1975, , , ,
la_1974, mu_1976, _513, _510, _507, _504, _501, _498);
 ipa-modref: call to dco.isra/287 does not use ref: kz alias sets: 4->4
   Deleted trivially dead stmt: _1548 = (long int) _1547;
@@ -14799,6 +14798,13 @@

   Deleted trivially dead stmt: _1770 = indx_1668 + 1;

+***dbgcnt: upper limit 836 reached for ipa_mod_ref.***
+ipa-modref: call stmt dc_1710 = dco.isra (0, 0, , , ,
la_1977, mu_1978, _513, _510, _507, _504, _501, _498);
+ipa-modref: call to dco.isra/287 does not use ref: D.8522 alias sets: 4->4
+  Deleted dead store: D.8522 = _1709;
+
+  Deleted trivially dead stmt: _1709 = kz_1696 + kzp_1699;
+

At WPA time we first compute summary for original function and then update for
new signature:

Updating summary for dco.isra/287 from:
  loads:
Limits: 32 bases, 16 refs
  Base 0:int (alias set 4)
Ref 0:int (alias set 4)
  access: Parm 0 param offset:0 offset:0 size:32 max_size:32
  access: Parm 1 param offset:0 offset:0 size:32 max_size:32
  access: Parm 5 param offset:0 offset:0 size:32 max_size:32
  access: Parm 6 param offset:0 offset:0 size:32 max_size:32
  access: Parm 2 param offset:0 offset:0 size:32 max_size:32
  access: Parm 3 param offset:0 offset:0 size:32 max_size:32
  access: Parm 4 param offset:0 offset:0 size:32 max_size:32
  Base 1:int[0:] (alias set 4)
Ref 0:int (alias set 4)
  access: Parm 9 param offset:0 offset:0 size:32 max_size:-1
  access: Parm 10 param offset:0 offset:0 size:32 max_size:-1
  access: Parm 11 param offset:0 offset:0 size:32 max_size:-1
  access: Parm 12 param offset:0 offset:0 size:32 max_size:-1
  Base 2:double[0:] (alias set 5)
Ref 0:double (alias set 5)
  access: Parm 8 param offset:0 offset:0 size:64 max_size:-1
  Base 3:double[15625] (alias set 5)
Ref 0:double (alias set 5)
  access: Parm 7 param offset:0 offset:0 size:64 max_size:-1
  stores:
Limits: 32 bases, 16 refs
  parm 0 flags: not_returned_directly not_returned_indirectly no_indirect_read
  parm 1 flags: not_returned_directly not_returned_indirectly no_indirect_read
  parm 2 flags: not_returned_directly not_returned_indirectly no_indirect_read
  parm 3 flags: not_returned_directly not_returned_indirectly no_indirect_read
  parm 4 flags: not_returned_directly not_returned_indirectly no_indirect_read
  parm 5 flags: not_returned_directly not_returned_indirectly no_indirect_read
  parm 6 flags: not_returned_directly not_returned_indirectly no_indirect_read
  parm 7 flags: not_returned_directly no_indirect_read
  parm 8 flags: not_returned_directly no_indirect_read
  parm 9 flags: not_returned_directly not_returned_indirectly no_indirect_read
  parm 10 flags: not_returned_directly not_returned_indirectly no_indirect_read
  parm 11 flags: not_returned_directly not_returned_indirectly no_indirect_read
  parm 12 flags: not_returned_directly not_returned_indirectly no_indirect_read
to:
  loads:
Limits: 32 bases, 16 refs
  Base 0:int (alias set 4)
Ref 0:int (alias set 4)
  access:
  access:
  access:
  access:
  access: Parm 2 param offset:0 offset:0 size:32 max_size:32
  access: Parm 3 param offset:0 offset:0 size:32 max_size:32
  access: Parm 4 param offset:0 offset:0 size:32 max_size:32
  Base 1:int[0:] (alias set 4)
Ref 0:int (alias set 4)
  access: Parm 9 param offset:0 offset:0 size:32 max_size:-1
  access: Parm 10 param offset:0 offset:0 size:32 max_size:-1
  access: Parm 11 param offset:0 offset:0 size:32 max_size:-1
  access: Parm 12 param offset:0 offset:0 size:32 max_size:-1
  Base 2:double[0:] (alias set 5)
Ref 0:double (alias set 5)
  access: Parm 8 param offset:0 offset:0 size:64 max_size:-1
  Base 3:double[15625] (alias set 5)
Ref 0:double (alias set 5)
  access: Parm 7 param offset:0 offset:0 size:64 max_size:-1
  stores:
Limits: 32 bases, 16 refs
  

[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 #17 from Aldy Hernandez  ---
The .s files on my cross versus the AWS instance or not even remotely the same:

--- j.s 2021-11-17 14:13:19.979883609 -0500
+++ j.s.bad 2021-11-17 14:13:12.083828127 -0500
@@ -5,79 +5,78 @@
 .global _main;
 .type _main, STT_FUNC;
 _main:
-   P2.H = _b;
-   [--sp] = ( r7:7, p5:3 );
+   [--sp] = ( p5:3 );

+   P2.H = _b;
+   [--SP] = FP;
P2.L = _b;
-   R2 = [P2];
-   P1.H = _a;
-   cc =R2==0;
-   P1.L = _a;
+   R0 = [P2];
+   P0.H = _a;
+   cc =R0==0;
+   P0.L = _a;
if !cc jump .L2;
-   P4.H = _f;
-   P3.H = _e;
-   P5.H = _d;
-   P4.L = _f;

etc
etc.

Except for the --with-newlib, the GCC configure lines look similar:

Configured with: /home/aldyh/src/gcc/configure --target=bfin-elf
--enable-languages=c --with-newlib --prefix=/home/aldyh/bld/bfin/install/
Configured with: /home/jenkins/gcc/configure --prefix=/home/jenkins/installed
--target=bfin-elf

Is there some sort of default -mcpu flag that is different?

Anywhoo...I'll continue working on this tomorrow since copying the AWS .s file
and compiling it on my cross also exhibits the broken behavior... so there's
clearly something there.

[Bug bootstrap/103306] New: parallel build hangs since 04c5a91d068c4ca2f09c2bc206fce00db9d1790b

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 103306
   Summary: parallel build hangs since
04c5a91d068c4ca2f09c2bc206fce00db9d1790b
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

For a few days, I am failing to build a x86_64-pc-linux-gnu compiler on one of
my systems; both bootstrap and non-bootstrap builds behave the same.



libtool: link: x86_64-pc-linux-gnu-ranlib .libs/libubsan.a
libtool: link: rm -fr .libs/libubsan.lax
libtool: link: ( cd ".libs" && rm -f "libubsan.la" && ln -s "../libubsan.la"
"libubsan.la" )
make[8]: Leaving directory
'/repo/build-gcc-trunk-amd64/x86_64-pc-linux-gnu/32/libsanitizer/ubsan'
make[8]: Entering directory
'/repo/build-gcc-trunk-amd64/x86_64-pc-linux-gnu/32/libsanitizer'
true "AR_FLAGS=rc" "CC_FOR_BUILD=x86_64-pc-linux-gnu-gcc" "CFLAGS=-g -O2  -m32"
"CXXFLAGS=-g -O2 -D_GNU_SOURCE  -m32" "CFLAGS_FOR_BUILD=-g -O2"
"CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c"
"INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c"
"INSTALL_SCRIPT=/usr/bin/install -c" "JC1FLAGS=" "LDFLAGS=-m32" "LIBCFLAGS=-g
-O2  -m32" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo
--split-size=500   " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh"
"RUNTESTFLAGS="
"exec_prefix=/repo/gcc-trunk//binary-trunk-r12-5339-2024023225-g04c5a91d068-checking-yes-rtl-df-extra-nobootstrap-amd64"
"infodir=/repo/gcc-trunk//binary-trunk-r12-5339-2024023225-g04c5a91d068-checking-yes-rtl-df-extra-nobootstrap-amd64/share/info"
"libdir=/repo/gcc-trunk//binary-trunk-r12-5339-2024023225-g04c5a91d068-checking-yes-rtl-df-extra-nobootstrap-amd64/lib"
"prefix=/repo/gcc-trunk//binary-trunk-r12-5339-2024023225-g04c5a91d068-checking-yes-rtl-df-extra-nobootstrap-amd64"
"includedir=/repo/gcc-trunk//binary-trunk-r12-5339-2024023225-g04c5a91d068-checking-yes-rtl-df-extra-nobootstrap-amd64/include"
"AR=x86_64-pc-linux-gnu-ar" "AS=/repo/build-gcc-trunk-amd64/./gcc/as"
"LD=/repo/build-gcc-trunk-amd64/./gcc/collect-ld -m elf_x86_64 -m elf_i386"
"LIBCFLAGS=-g -O2  -m32" "NM=/repo/build-gcc-trunk-amd64/./gcc/nm" "PICFLAG="
"RANLIB=x86_64-pc-linux-gnu-ranlib" "DESTDIR=" DO=all multi-do # make
make[8]: Leaving directory
'/repo/build-gcc-trunk-amd64/x86_64-pc-linux-gnu/32/libsanitizer'
make[7]: Leaving directory
'/repo/build-gcc-trunk-amd64/x86_64-pc-linux-gnu/32/libsanitizer'
make[6]: Leaving directory
'/repo/build-gcc-trunk-amd64/x86_64-pc-linux-gnu/32/libsanitizer'
make[5]: Leaving directory
'/repo/build-gcc-trunk-amd64/x86_64-pc-linux-gnu/libsanitizer'
make[4]: Leaving directory
'/repo/build-gcc-trunk-amd64/x86_64-pc-linux-gnu/libsanitizer'
make[3]: Leaving directory
'/repo/build-gcc-trunk-amd64/x86_64-pc-linux-gnu/libsanitizer'
make[2]: Leaving directory
'/repo/build-gcc-trunk-amd64/x86_64-pc-linux-gnu/libsanitizer'
make[1]: Leaving directory '/repo/build-gcc-trunk-amd64'


The system is 100% idle afterwards, but I don't get my terminal / build script
doesn't continue with make install.

I've bisected this to have started with
04c5a91d068c4ca2f09c2bc206fce00db9d1790b

Configure:

/repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-5339-2024023225-g04c5a91d068-checking-yes-rtl-df-extra-nobootstrap-amd64

make:
make -j8

non-parallel build works fine:
make -j1

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

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

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

--- Comment #6 from seurer at gcc dot gnu.org ---
I am still seeing the failure on powerpc64 with current trunk (r12-5320), too.

[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 #19 from Jan Hubicka  ---
I was too optimistic - the patch does not help.

The problem is related to modref.  With lto-partition=max the problem triggers
while lto-partition=one hides it becuase late tree modref recomputes summaries
and after that things works as expected.  It may be wrong summary produced by
the ipa-modref and streamed to the ltrans or some TBAA related bug. Disabling
TBAA checks from the summary use makes the testcase to pass and there are some
TBAA violation warnings when linking. I am isolating the problematic
disambiguation.

[Bug c/101702] [12 Regression] ICE: in handle_argspec_attribute, at c-family/c-attribs.c:3623

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Fixed.

[Bug c/101702] [12 Regression] ICE: in handle_argspec_attribute, at c-family/c-attribs.c:3623

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r12-5347-g2c2148d8c144d7388abcb7c34b782be647fe81c9
Author: Martin Sebor 
Date:   Wed Nov 17 11:51:33 2021 -0700

Handle folded nonconstant array bounds [PR101702]

PR c/101702 - ICE: in handle_argspec_attribute, at
c-family/c-attribs.c:3623

gcc/c/ChangeLog:

PR c/101702
* c-decl.c (get_parm_array_spec): Strip casts earlier and fold
array
bounds before deciding if they're constant.

gcc/testsuite/ChangeLog:

PR c/101702
* gcc.dg/Warray-parameter-11.c: New test.

[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 #16 from Aldy Hernandez  ---
(In reply to Jeffrey A. Law from comment #15)
> 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.

Oh, that's funny.  I just logged into the AWS instance only to notice that your
instructions contained -msim.

I can now run a hello world on my cross build, but still cannot reproduce the
problem:

tor:~/bld/bfin/install/bin$ cat a.c
main(){printf("hello world\n"); }
tor:~/bld/bfin/install/bin$ ./bfin-elf-gcc a.c  -w -msim -O2
tor:~/bld/bfin/install/bin$ ./bfin-elf-run ./a.out
hello world
tor:~/bld/bfin/install/bin$ cat j.c
/* { dg-do run } */

int a, b, c, d, e, f, g[4];

static int fn1 ()
{
  int h, i;
  if (b)
goto L1;
L2:;
   int m = a;
   while (1)
 {
   int n = 2;
   e = !f && (n = 5);
   if (e)
 for (h = 0; h < 9; h++)
   for (i = 0; i < 6; i++)
 if (a)
   g[h] = 4;
   if (d)
 goto L2;
   a & n || b;
L1:
   if (a)
 L3:
 c = m;
   if (a)
 goto L3;
   if (b < 5)
 return 0;
 }
}

int main ()
{
  fn1 ();
  return 0; 
}
tor:~/bld/bfin/install/bin$ ./bfin-elf-gcc j.c  -w -msim -O2
tor:~/bld/bfin/install/bin$ ./bfin-elf-run ./a.out
tor:~/bld/bfin/install/bin$ 

However, I can reproduce on the AWS instance:

[root@ip-172 gcc]# bfin-elf-gcc -msim -O2 j.c
[root@ip-172 gcc]# bfin-elf-run a.out
[long wait]

Strange.

[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 #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
>  static const mask blank= space;

We might want to use blank = _ISspace | _ISblank for this last one, but I don't
really understand what newlib defines those categories as:


#define isblank(__c) \
  __extension__ ({ __typeof__ (__c) __x = (__c);\
(__ctype_lookup(__x)&_B) || (int) (__x) == '\t';})
(__ctype_lookup(__x)&_ISblank) || (int) (__x) == '\t';})

This definition is weird ... why is '\t' not already handled by _ISblank?

[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.

[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 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

[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 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 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/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 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 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++/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++/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 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 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

[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 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 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 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 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

[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 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/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/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/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