[Bug c/43798] [8/9/10 Regression] attribute((aligned(x))) not honored for array element types?

[zsojka at seznam dot cz]

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

--- Comment #18 from Zdenek Sojka  ---
>From my (of course limited) experience, such behavior is unexpected by the
user. The user really wants:

typedef
struct  __attribute__((aligned(16))) {
unsigned long long w[3];
} UINT192;

OR

typedef
struct {
unsigned long long w[3];
} __attribute__((aligned(16))) UINT192;

BUT if he writes

typedef __attribute__((aligned(16)))
struct {
unsigned long long w[3];
} UINT192;

OR

typedef
struct {
unsigned long long w[3];
} UINT192 __attribute__((aligned(16)));

he then gets this broken code (array elements not aligned to 16).



Currently, you get an error for:

typedef __attribute__((__aligned__(64)))
struct {
int a;
} SMALL ;

SMALL s[2];

$ gcc tst.c
tst.c:64:1: error: alignment of array elements is greater than element size
 SMALL s[2];
 ^

BUT not for:

typedef __attribute__((__aligned__(64)))
struct {
int a[100];
} BIG;

BIG b[2];

even though this is leads to the same kind bugs as using SMALL.
(b[1] is not aligned to 64)
_Alignof(BIG)=64, sizeof(BIG)=400
_Alignof(b)=64, sizeof(b)=832 (why?)

I think a warning for declaration of both SMALL and BIG, or at least when
declaring "BIG b[2]", would be reasonable.

[Bug other/90286] failure in arduino

[tada at specyal dot com]

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

--- Comment #2 from tada at specyal dot com ---
There is no other compiler for Arduino.

On 4/29/2019 4:31 PM, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90286
>
> Andrew Pinski  changed:
>
> What|Removed |Added
> 
>   Status|UNCONFIRMED |RESOLVED
>   Resolution|--- |DUPLICATE
>
> --- Comment #1 from Andrew Pinski  ---
> Dup of bug 87695.  There is still missing a testcase there ...
> Also GCC 5.x is no longer maintained, please try a newer compiler.
>
> *** This bug has been marked as a duplicate of bug 87695 ***
>

[Bug tree-optimization/90078] [7/8 Regression] ICE with deep templates caused by overflow

[amker at gcc dot gnu.org]

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

--- Comment #12 from bin cheng  ---
Author: amker
Date: Tue Apr 30 03:00:59 2019
New Revision: 270673

URL: https://gcc.gnu.org/viewcvs?rev=270673=gcc=rev
Log:
PR tree-optimization/90240
Revert:
2019-04-23  Bin Cheng  

PR tree-optimization/90078
* tree-ssa-loop-ivopts.c (comp_cost::operator +,-,+=,-+,/=,*=): Add
checks for infinite_cost overflow.

* gcc/testsuite/g++.dg/tree-ssa/pr90078.C: New test.

Removed:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr90078.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug tree-optimization/90240] [10 Regression] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:6694

[amker at gcc dot gnu.org]

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

--- Comment #9 from bin cheng  ---
Author: amker
Date: Tue Apr 30 03:00:59 2019
New Revision: 270673

URL: https://gcc.gnu.org/viewcvs?rev=270673=gcc=rev
Log:
PR tree-optimization/90240
Revert:
2019-04-23  Bin Cheng  

PR tree-optimization/90078
* tree-ssa-loop-ivopts.c (comp_cost::operator +,-,+=,-+,/=,*=): Add
checks for infinite_cost overflow.

* gcc/testsuite/g++.dg/tree-ssa/pr90078.C: New test.

Removed:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr90078.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug rtl-optimization/89721] __builtin_mffs sometimes optimized away

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
Segher, can we move this to Fixed now?

[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox

[aoliva at gcc dot gnu.org]

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

--- Comment #23 from Alexandre Oliva  ---
> what are the rules of which ones we can remove?  Can we always just keep the
last?  What about location differences?  What about possibly interleaving
DEBUG_BEGIN stmts?

code insns and markers are potential inspection points, so binds reaching them
should ideally not be messed with.  this means one can safely remove binds that
are overridden before the next inspection point, so yes, keeping only the last
one that provides a binding for any given variable before each inspection point
should be safe.

this should (in theory) be reasonably rare, though, because there should be
sequence points between assignments to the same variable.  this doesn't imply
inspection points, e.g., we don't insert markers at comma operators.  I suppose
these arise from binds inserted by CFG rearrangements rather than when entering
SSA.  I don't have much of a sense of these yet, but it's clear their meaning
is looser, in a way.  They don't refer to a specific code location or bind
present in sources, but rather they indicate our inability to keep track of
bindings after certain transformations.  My intuition is that, as things are,
we could drop them in the same circumstances we'd drop overriding binds, but
maybe we could go looser about them, especially when they're resets.

When you ask about location differences, it's not clear whether you're asking
about binding values (used in location lists) or source line locations.  It's
not always viable to tell whether binding expressions are equivalent, but the
last one prevails except at control flow confluences, and var-tracking deals
with that much later.  As for source line locations, I don't think they're
relevant in debug bind statements.


> # DEBUG INLINE_ENTRY NULL

That is a marker, but without naming the inlined function, it would appear to
be useless indeed.  I wonder, however, if the logical block that named the
inlined function was really lost, or if it just references some anonymous
function.  This would guide the decision on whether the marker became useless
for losing track of the function named by it (which might require an
investigation of how this came about, instead of silently dropping further
debug info), or whether we just don't have a name for the function any more
(but we might still have debug info generated for it)

> my guess that debug temps are always in the same BB as uses is wrong.

they can be bound in one BB and used in another, indeed.  they may even be
bound in multiple BBs and used in multiple other BBs, and then var-tracking
will attempt to identify shared values in incoming exprs at confluence points. 
we don't do that very much, but we could.  even without that, there are cases
in which we issue temp binds in one block and reference them in another, even
when we're not sure one reaches the other: var-tracking sorts that out
eventually.

[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox

[hubicka at gcc dot gnu.org]

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

--- Comment #22 from Jan Hubicka  ---
gcc 8 with debug info

real45m49.664s
user500m1.776s
sys 22m39.816s

llvm 7 with debug info

real43m43.798s
user447m36.028s
sys 10m13.512s

[Bug c++/90287] New: [concepts] bogus error on overload failure inside requires-expression

[redbeard0531 at gmail dot com]

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

Bug ID: 90287
   Summary: [concepts] bogus error on overload failure inside
requires-expression
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/30Cf6s

#include 

template 
constexpr inline bool isAddable = requires(const T& lhs, const U& rhs) {
 lhs + rhs;
};

auto x = isAddable;

: In instantiation of 'constexpr const bool isAddable >':
:13:10:   required from here
:10:10: error: no match for 'operator+' (operand types are 'const int'
and 'const std::__cxx11::basic_string')
   10 |  lhs + rhs ;
  |  ^

[snip rest of wall-o-errors]

If I make isAddable a concept, it correctly evaluates to false, but I would
expect requires-expressions to also work when assigned to a constexpr bool.

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #33 from Eric Gallager  ---
This came up on the mailing lists again here:
https://gcc.gnu.org/ml/gcc/2019-04/msg00276.html

[Bug other/90286] failure in arduino

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 87695.  There is still missing a testcase there ...
Also GCC 5.x is no longer maintained, please try a newer compiler.

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

[Bug other/87695] Arduino: ICE with avr and LTO

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||tada at specyal dot com

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

[Bug other/90286] New: failure in arduino

[tada at specyal dot com]

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

Bug ID: 90286
   Summary: failure in arduino
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tada at specyal dot com
  Target Milestone: ---

C:\a\arduinoinstallation\hardware\arduino\avr\cores\arduino\Print.cpp: In
function 'println.constprop':

C:\a\arduinoinstallation\hardware\arduino\avr\cores\arduino\Print.cpp:164:1:
internal compiler error: Segmentation fault

 }

 ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

lto-wrapper.exe: fatal error:
C:\a\arduinoinstallation\hardware\tools\avr/bin/avr-gcc returned 1 exit status

compilation terminated.

c:/a/arduinoinstallation/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe:
error: lto-wrapper failed

collect2.exe: error: ld returned 1 exit status

exit status 1
Error compiling for board Arduino Nano.

[Bug c++/90285] New: Poor optimised codegen for memmove() back on top of oneself

[s_gccbugzilla at nedprod dot com]

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

Bug ID: 90285
   Summary: Poor optimised codegen for memmove() back on top of
oneself
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s_gccbugzilla at nedprod dot com
  Target Milestone: ---

The following code produces poor optimised codegen on trunk GCC at the time of
writing (2019-04-29):

// Reinterprets a T into its array of bytes
// Currently defined behaviour in C++ 20 for
// trivially copyable types only. The proposal
// would be that this would become defined 
// behaviour for most possible C++ types.
template
constexpr inline byte_array_ref detach_cast(T ) noexcept
{
byte_array_ref ret = reinterpret_cast>(v);
byte temp[sizeof(T)];

// Reinterpret bytes by copying (not UB for TC types)
memmove(temp, , sizeof(T));

// Put reinterpreted bytes back. This avoids the UB
// of reinterpret casting without creating new objects.
memmove(ret, temp, sizeof(T));
return ret;
}

You can see GCC's codegen here (it does two copies of 40Kb):
https://godbolt.org/z/sJWSc1

You can see clang's codegen here (which is optimal, nothing is copied):
https://godbolt.org/z/ou8VFT

I think GCC ought to not perform memory copies for the above code sequence.

Niall

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e, jrtc27 at jrtc27 dot com
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=87338

--- Comment #16 from Eric Gallager  ---
(In reply to Jim Wilson from comment #14)
> https://wiki.debian.org/Ports/ia64
> 
> James Clarke has been active recently on the binutils and/or gcc mailing
> lists.  My IA-64 work has dwindled down to nothing, as RISC-V work has kept
> me too busy to do anything else.  With the architecture already set to
> end-of-life next year, I'm not planning to do anymore IA-64 work.

(In reply to Jim Wilson from comment #15)
> See also PR 87338 which has a response earlier today from John Paul Adrian
> Glaubitz.

ok, thanks

[Bug target/88696] Power VSX builtins missing vmuluwm / vector int vec_mul (vector int, vector int);

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-29
 Ever confirmed|0   |1

--- Comment #3 from Bill Schmidt  ---
Confirmed, FWIW.

[Bug target/88696] Power VSX builtins missing vmuluwm / vector int vec_mul (vector int, vector int);

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Yes, we need a big clean-up on the documentation here.  Presently working on a
better documentation vehicle for vector built-ins.  Once that's done, we'll
have the GCC manual point to that instead.

[Bug c++/89949] Internal compiler error with lambda as template argument

[john.boyer at tutanota dot com]

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

John Boyer  changed:

   What|Removed |Added

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

--- Comment #2 from John Boyer  ---
Fixed in a more recent version of GCC trunk (not sure which version exactly,
godbolt doesn't specify).

[Bug target/69868] vec_perm built-in is not handled by swap optimization on powerpc64le

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #7 from Bill Schmidt  ---
I missed closing this a long time ago, apologies.

[Bug c++/90284] New: -Wunused-value points to the wrong expression

[john.boyer at tutanota dot com]

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

Bug ID: 90284
   Summary: -Wunused-value points to the wrong expression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.boyer at tutanota dot com
  Target Milestone: ---

In the following code https://godbolt.org/z/0jTk3e, GCC warns about the second
operand of a conditional expression having no effect, even though the second
operand is returned.

In reality, the first operand is the one that has no effect, not the second.

This only happens when a ternary is involved. If there is no ternary, the
proper warning is printed.

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

[eyalroz at technion dot ac.il]

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

--- Comment #8 from Eyal Rozenberg  ---
(In reply to rguent...@suse.de from comment #5)
> int foo3()
> {
>   struct { int x; int y; } s;
>   s.x = 3;
>   char c = 1;
>   return replace_bytes_3(,c);
> }
> 
> Coalescing successful!
> Merged into 1 stores

This is very interesting! Do you think I could somehow adapt this example into
a workaround, for existing GCC versions, rather than wait for the bug fix?

[Bug go/90272] internal compile error with full backtrace

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed on trunk by revision 270658.

[Bug target/90096] Misleading option hint for AVX intrinsics

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|10.0|9.0

--- Comment #3 from Jakub Jelinek  ---
Fixed for 9.1+.

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
Probably dup of bug 87281.

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

[wilson at gcc dot gnu.org]

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

--- Comment #15 from Jim Wilson  ---
See also PR 87338 which has a response earlier today from John Paul Adrian
Glaubitz.

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

[wilson at gcc dot gnu.org]

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

--- Comment #14 from Jim Wilson  ---
https://wiki.debian.org/Ports/ia64

James Clarke has been active recently on the binutils and/or gcc mailing lists.
 My IA-64 work has dwindled down to nothing, as RISC-V work has kept me too
busy to do anything else.  With the architecture already set to end-of-life
next year, I'm not planning to do anymore IA-64 work.

[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #8)
> Well, for the decode_field_reference, I think it is essential not to change
> *exp_ if returning NULL, because the caller uses lr_arg/rr_arg without
> checking whether it returned NULL or not.  The c_common_type_for_size change
> is independent of the rest, I'd find it too risky for GCC9, but could be
> posted for GCC10.

David, are you going to submit this c_common_type_for_size change for GCC 10?

[Bug tree-optimization/90278] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
  Known to fail|10.0|

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/90278] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 29 17:53:36 2019
New Revision: 270657

URL: https://gcc.gnu.org/viewcvs?rev=270657=gcc=rev
Log:
2019-04-29  Richard Biener  

PR tree-optimization/90278
* tree-ssa-forwprop.c (pass_forwprop::execute): Transfer/clean
EH on comparison simplification.

* gcc.dg/torture/pr90278.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr90278.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug go/90272] internal compile error with full backtrace

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
Thanks.  To be clear, while of course the compiler should not crash, this is
not a valid Go program.

[Bug middle-end/90283] New: 519.lbm_r is 7%-10% slower with -Ofast -march=native and both LTO and PGO than with GCC 8

[jamborm at gcc dot gnu.org]

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

Bug ID: 90283
   Summary: 519.lbm_r is 7%-10% slower with -Ofast -march=native
and both LTO and PGO  than with GCC 8
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

When I build 519.lbm_r with GCC 9 (specifically, r270364) using -Ofast
-march=native -mtune=native and both LTO and PGO, the binary is then
about 7%-10% slower than when built with GCC 8 and the same options.

I can see this on both and AMD Zen machine (10%) and an Intel Skylake
server (7%).

I have bisected the regression on the Zen machine where it regressed
in two steps.  The first one is r260348, which causes a 7% regression
on both the Zen and Intel server CPUs.  Because it affects both in a
similar way, I hope it is not another manifestation of PR 84200.

As far as profile data are concerned, in all cases 99% of run-time is
spent in function main.  Perf stat output is the following:

Fast (r260347) on Zen:

 Performance counter stats for 'numactl -C 0 -l specinvoke':

 157862.072201  task-clock:u (msec)   #0.999 CPUs utilized  
 0  context-switches:u#0.000 K/sec  
 0  cpu-migrations:u  #0.000 K/sec  
  4354  page-faults:u #0.028 K/sec  
  490921430199  cycles:u  #
5942617830  stalled-cycles-frontend:u #1.21% frontend cycles
idle (83.36%)
   11565687163  stalled-cycles-backend:u  #2.36% backend cycles
idle  (83.32%)
 1121945505076  instructions:u#2.29  insn per cycle 
  #0.01  stalled cycles per
insn  (83.32%)
   11591019938  branches:u#   73.425 M/sec 
  (83.36%)
  50878910  branch-misses:u   #0.44% of all branches   
  (83.33%)

 158.013578100 seconds time elapsed

Slower (r260348) on Zen:

 Performance counter stats for 'numactl -C 0 -l specinvoke':

 166747.570030  task-clock:u (msec)   #0.999 CPUs utilized
 0  context-switches:u#0.000 K/sec
 0  cpu-migrations:u  #0.000 K/sec
  4354  page-faults:u #0.026 K/sec
  520147919104  cycles:u  #
4619521659  stalled-cycles-frontend:u #0.89% frontend cycles
idle (83.32%)
   11565577319  stalled-cycles-backend:u  #2.22% backend cycles
idle  (83.32%)
 1133497632829  instructions:u#2.18  insn per cycle
  #0.01  stalled cycles per
insn  (83.36%)
   11583199072  branches:u#   69.465 M/sec 
  (83.33%)
  50821264  branch-misses:u   #0.44% of all branches   
  (83.32%)

 166.898923990 seconds time elapsed


The second performance drop on Zen happened at r265795, albeit only by
3% and the revision does not seem to have any effect on the Intel CPU
(and thus given how weirdly the benchmark can sometimes behave, may
not be that interesting).

Just before the second drop (r265794):

 Performance counter stats for 'numactl -C 0 -l specinvoke':

 165315.997872  task-clock:u (msec)   #0.999 CPUs utilized  
 0  context-switches:u#0.000 K/sec  
 0  cpu-migrations:u  #0.000 K/sec  
  4354  page-faults:u #0.026 K/sec  
  520201473687  cycles:u  #
4890796962  stalled-cycles-frontend:u #0.94% frontend cycles
idle (83.37%)
   11565134531  stalled-cycles-backend:u  #2.22% backend cycles
idle  (83.32%)
 1132849187518  instructions:u#2.18  insn per cycle 
  #0.01  stalled cycles per
insn  (83.31%)
   11591493304  branches:u#   70.117 M/sec 
  (83.37%)
  50879513  branch-misses:u   #0.44% of all branches   
  (83.32%)

 165.498590592 seconds time elapsed


Second drop (r265795):

 Performance counter stats for 'numactl -C 0 -l specinvoke':

 170908.963939  task-clock:u (msec)   #0.999 CPUs utilized  
 0  context-switches:u#0.000 K/sec  
 0  

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[jason.duerstock at gmail dot com]

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

--- Comment #1 from Jason Duerstock  ---
Created attachment 46264
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46264=edit
gcc dump

[Bug tree-optimization/88709] Improve store-merging

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
WIP:
--- gcc/gimple-ssa-store-merging.c.jj   2019-01-01 12:37:19.063943678 +0100
+++ gcc/gimple-ssa-store-merging.c  2019-04-29 19:02:55.992151104 +0200
@@ -1615,13 +1615,31 @@ encode_tree_to_bitpos (tree expr, unsign
   unsigned int total_bytes)
 {
   unsigned int first_byte = bitpos / BITS_PER_UNIT;
-  tree tmp_int = expr;
   bool sub_byte_op_p = ((bitlen % BITS_PER_UNIT)
|| (bitpos % BITS_PER_UNIT)
|| !int_mode_for_size (bitlen, 0).exists ());
+  bool empty_ctor_p
+= (TREE_CODE (expr) == CONSTRUCTOR
+   && CONSTRUCTOR_NELTS (expr) == 0
+   && TYPE_SIZE_UNIT (TREE_TYPE (expr))
+  && tree_fits_uhwi_p (TYPE_SIZE_UNIT (TREE_TYPE
(expr;

   if (!sub_byte_op_p)
-return native_encode_expr (tmp_int, ptr + first_byte, total_bytes) != 0;
+{
+  if (first_byte >= total_bytes)
+   return false;
+  total_bytes -= first_byte;
+  if (empty_ctor_p)
+   {
+ unsigned HOST_WIDE_INT rhs_bytes
+   = tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (expr)));
+ if (rhs_bytes > total_bytes)
+   return false;
+ memset (ptr + first_byte, '\0', rhs_bytes);
+ return true;
+   }
+  return native_encode_expr (expr, ptr + first_byte, total_bytes) != 0;
+}

   /* LITTLE-ENDIAN
  We are writing a non byte-sized quantity or at a position that is not
@@ -1667,14 +1685,29 @@ encode_tree_to_bitpos (tree expr, unsign

   /* We must be dealing with fixed-size data at this point, since the
  total size is also fixed.  */
-  fixed_size_mode mode = as_a  (TYPE_MODE (TREE_TYPE
(expr)));
+  unsigned int byte_size;
+  if (empty_ctor_p)
+{
+  unsigned HOST_WIDE_INT rhs_bytes
+   = tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (expr)));
+  if (rhs_bytes > total_bytes)
+   return false;
+  byte_size = rhs_bytes;
+}
+  else
+{
+  fixed_size_mode mode
+   = as_a  (TYPE_MODE (TREE_TYPE (expr)));
+  byte_size = GET_MODE_SIZE (mode);
+}
   /* Allocate an extra byte so that we have space to shift into.  */
-  unsigned int byte_size = GET_MODE_SIZE (mode) + 1;
+  byte_size++;
   unsigned char *tmpbuf = XALLOCAVEC (unsigned char, byte_size);
   memset (tmpbuf, '\0', byte_size);
   /* The store detection code should only have allowed constants that are
- accepted by native_encode_expr.  */
-  if (native_encode_expr (expr, tmpbuf, byte_size - 1) == 0)
+ accepted by native_encode_expr or empty ctors.  */
+  if (!empty_ctor_p
+  && native_encode_expr (expr, tmpbuf, byte_size - 1) == 0)
 gcc_unreachable ();

   /* The native_encode_expr machinery uses TYPE_MODE to determine how many
@@ -4164,7 +4197,8 @@ lhs_valid_for_store_merging_p (tree lhs)
   tree_code code = TREE_CODE (lhs);

   if (code == ARRAY_REF || code == ARRAY_RANGE_REF || code == MEM_REF
-  || code == COMPONENT_REF || code == BIT_FIELD_REF)
+  || code == COMPONENT_REF || code == BIT_FIELD_REF
+  || DECL_P (lhs))
 return true;

   return false;
@@ -4178,6 +4212,11 @@ static bool
 rhs_valid_for_store_merging_p (tree rhs)
 {
   unsigned HOST_WIDE_INT size;
+  if (TREE_CODE (rhs) == CONSTRUCTOR
+  && CONSTRUCTOR_NELTS (rhs) == 0
+  && TYPE_SIZE_UNIT (TREE_TYPE (rhs))
+  && tree_fits_uhwi_p (TYPE_SIZE_UNIT (TREE_TYPE (rhs
+return true;
   return (GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (rhs))).is_constant ()
  && native_encode_expr (rhs, NULL, size) != 0);
 }

[Bug c++/82081] Tail call optimisation of noexcept function leads to exception allowed through

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Mon Apr 29 17:27:13 2019
New Revision: 270656

URL: https://gcc.gnu.org/viewcvs?rev=270656=gcc=rev
Log:
PR c++/82081 - tail call optimization breaks noexcept

If a noexcept function calls a function that might throw, doing the tail
call optimization means that an exception thrown in the called function
will propagate out, breaking the noexcept specification.  So we need to
prevent the optimization in that case.

* tree-tailcall.c (find_tail_calls): Don't turn a call from a
nothrow function to a might-throw function into a tail call.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/tail-call-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-tailcall.c

[Bug c/90036] [8/9/10 Regression] false positive: directive argument is null [-Werror=format-overflow=]

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
extern int sprintf (char *__restrict __s,
const char *__restrict __format, ...)
  __attribute__ ((__nothrow__));

typedef int bfd_boolean;



struct stab_type_stack
{
  long index;
  bfd_boolean definition;
};



struct stab_write_handle
{
  struct stab_type_stack *type_stack;
};
extern char *stab_pop_type (struct stab_write_handle *);
bfd_boolean stab_start_struct_type (void *, const char *, unsigned int,
bfd_boolean, unsigned int);


bfd_boolean
stab_start_class_type (void *p, const char *tag, unsigned int id,
   bfd_boolean structp, unsigned int size,
   bfd_boolean vptr, bfd_boolean ownvptr)
{
  struct stab_write_handle *info = (struct stab_write_handle *) p;
  bfd_boolean definition;
  char *vstring;

  if (!vptr || ownvptr)
{
  definition = 0;
  vstring = ((void *) 0);
}
  else
{
  definition = info->type_stack->definition;
  vstring = stab_pop_type (info);
}



  if (vptr)
{
  if (ownvptr)
{

  sprintf (p, "~%%%ld", info->type_stack->index);
}
  else
{
  sprintf (p, "~%%%s", vstring);
}

}

  if (definition)
info->type_stack->definition = 1;

  return 1;
}

[Bug rtl-optimization/90282] New: internal compiler error: qsort checking failed in snapshot-20190429

[jason.duerstock at gmail dot com]

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

Bug ID: 90282
   Summary: internal compiler error: qsort checking failed in
snapshot-20190429
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.duerstock at gmail dot com
  Target Milestone: ---

/home/jason/gcc-snapshot-20190429/build/./prev-gcc/xg++
-B/home/jason/gcc-snapshot-20190429/build/./prev-gcc/
-B/usr/lib/gcc-snapshot/ia64-linux-gnu/bin/ -nostdinc++
-B/home/jason/gcc-snapshot-20190429/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs
-B/home/jason/gcc-snapshot-20190429/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/jason/gcc-snapshot-20190429/build/prev-ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu

-I/home/jason/gcc-snapshot-20190429/build/prev-ia64-linux-gnu/libstdc++-v3/include
 -I/home/jason/gcc-snapshot-20190429/src/libstdc++-v3/libsupc++
-L/home/jason/gcc-snapshot-20190429/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs
-L/home/jason/gcc-snapshot-20190429/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DUSE_LIBUNWIND_EXCEPTIONS  -g -O2 -fno-checking -gtoggle -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc
-I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include 
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o cselib.o -MT cselib.o
-MMD -MP -MF ./.deps/cselib.TPo ../../src/gcc/cselib.c
../../src/gcc/cselib.c: In function 'int rtx_equal_for_cselib_1(rtx, rtx,
machine_mode, int)':
../../src/gcc/cselib.c:1044:1: error: qsort comparator non-negative on sorted
output: 1
 1044 | }
  | ^
during RTL pass: mach
../../src/gcc/cselib.c:1044:1: internal compiler error: qsort checking failed
cc1plus(9051): unaligned access to 0x22b302d4, ip=0x44240841
cc1plus(9051): unaligned access to 0x22b302d4, ip=0x44240910
cc1plus(9051): unaligned access to 0x22b302d4, ip=0x442409b0
cc1plus(9051): unaligned access to 0x22b3e6be, ip=0x44240751
cc1plus(9051): unaligned access to 0x22b3e6c6, ip=0x44240841
0x4409cc2f qsort_chk_error
../../src/gcc/vec.c:211
0x4409db2f qsort_chk(void*, unsigned long, unsigned long, int (*)(void
const*, void const*))
../../src/gcc/vec.c:254
0x4415b3ef gcc_qsort(void*, unsigned long, unsigned long, int (*)(void
const*, void const*))
../../src/gcc/sort.cc:238
0x43cc658f ready_sort_real
../../src/gcc/haifa-sched.c:3097
0x43cc66df ready_sort
../../src/gcc/haifa-sched.c:3113
0x43ce2ecf schedule_block(basic_block_def**, void*)
../../src/gcc/haifa-sched.c:6700
0x43efcfaf schedule_ebb(rtx_insn*, rtx_insn*, bool)
../../src/gcc/sched-ebb.c:537
0x43efdd1f schedule_ebbs()
../../src/gcc/sched-ebb.c:656
0x4317624f ia64_reorg
../../src/gcc/config/ia64/ia64.c:9852
0x42201f5f execute
../../src/gcc/reorg.c:3992
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug other/44435] gengtype: don't test undefined value after vasprintf failure

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
I have not been tracking the state of review or lack thereof for these 
patches.

[Bug c/90036] [8/9/10 Regression] false positive: directive argument is null [-Werror=format-overflow=]

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
Bah!  Lost my reduced testcase...

[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

[roland.illig at gmx dot de]

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

--- Comment #10 from Roland Illig  ---
(In reply to Richard Biener from comment #9)
> IMHO the error calls in our IL checkers are abusive, they could have been
> simple dumps to stderr for example.  It was just "convenient" to use
> a disagnostic reporting routine here (largely historically convenient).

I can totally understand that since I was in the same situation some days ago.
In a linter I maintain I was so used to issuing diagnostics that I didn't
notice that I/O errors are something different and that there need to be
separate functions for reporting these.

[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue

[zhroma at gcc dot gnu.org]

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

Roman Zhuykov  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2019-04-29
 Resolution|INVALID |---
Summary|[9/10 Regression]   |[9/10 Regression]
   |-Wnull-dereference false|-Wnull-dereference QoI
   |positive after r270574  |issue
 Ever confirmed|0   |1

--- Comment #4 from Roman Zhuykov  ---
Let me perhaps explain better.  Function asprintf should set *s to point
allocated memory and return non-negative amount of printed chars.  When
allocation fails it will return -1.  So, there are really no issue in the
original code, but compiler isn’t clever enough to know how asprintf works.

Gcc 8 doesn’t warn, thats why I’ve created this bugreport as false-positive. 
So, here trunk gives a warning: https://godbolt.org/z/-o6UMv

If we decide that warning is correct, we must also warn same code, when -1
bailout removed: https://godbolt.org/z/ayb9pS

Than we have a false negative and it is *not* a “9 Regression”, but we have to
fix it.

I also want to note, that when -2 bail out is removed from both examples, 8.3
and trunk give a warning.  There is a separate issue with gcc 8.3 here, it
warns two times.

: In function 'cn_sequence':
:11:8: warning: potential null pointer dereference [-Wnull-dereference]
   *out = '\0';
   ~^~
:11:8: warning: potential null pointer dereference [-Wnull-dereference]
Compiler returned: 0

But I haven’t checked recent 8-branch, maybe that was fixed and backported
after  8.3.

[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference

[zhroma at gcc dot gnu.org]

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

Bug 90264 Summary: [9/10 Regression] -Wnull-dereference QoI issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox

[hubicka at gcc dot gnu.org]

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

--- Comment #21 from Jan Hubicka  ---
I just built Firefox with GCC 9 branch and the updated patch. Debug enabled
build is:
real45m56.187s
user493m8.688s
sys 22m4.512s

compared to debug disabled build with GCC 9:
real35m5.141s
user386m2.364s
sys 17m21.892s

GCC 8 debug disabled build is:
real36m55.979s
user389m54.256s
sys 17m51.964s

and llvm7 debug disabled is:
real36m28.096s
user384m24.056s
sys 8m53.768s

All with LTO. I will build gcc8 and llvm7 with debug info enabled.

[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Another report: https://gcc.gnu.org/ml/gcc/2019-04/msg00270.html

[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64

[agner at agner dot org]

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

Agner Fog  changed:

   What|Removed |Added

 CC||agner at agner dot org

--- Comment #6 from Agner Fog  ---
I get the same error with G++ 7.4.0 Cygwin when compiling with option
-mavx512vl -m64. 

A workaround is to use -fno-asynchronous-unwind-tables

Register xmm16-31 should be considered clobbered in Win64. See
https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin

[Bug rtl-optimization/90280] [9/10 Regression] ICE: in lra_assign, at lra-assigns.c:1650 with -O -fno-dce -fno-forward-propagate -fno-omit-frame-pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #9 from Richard Biener  ---
(In reply to Martin Sebor from comment #8)
> (In reply to Richard Biener from comment #6)
> 
> The trouble is that there is no way to tell whether
> 
>   error ("BIT_FIELD_REF of non-mode-precision operand");
> 
> is a user-facing error or an internal error not meant to be translated.  The
> #pragma GCC diagnostic ignored "-Wformat-diag" solution suppresses the
> warning but won't help translators.  The only ways to deal with that that
> comes to mind are either a new  inernal_error_and_continue() function or
> some special annotation in the format string to make it clear both to
> -Wformat-diag and to translators that the string isn't meant to be
> translated (or checked for translation problems).  Is there a preference for
> one or other approach?  Or some other solution I'm not thinking of?

Ah, so Roland pointed out the bug this was discussed.  I think his approach
is reasonable (keep the original message but prefix it with a localized
prefix).  I think it would be useful for translators to know whether
they are dealing with "internal" errors or regular errors.

IMHO the error calls in our IL checkers are abusive, they could have been
simple dumps to stderr for example.  It was just "convenient" to use
a disagnostic reporting routine here (largely historically convenient).

[Bug libstdc++/90281] utf-8 encoded std::filesystem::path can not be converted to utf-16.

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The problem is that I'm using codecvt_utf8, which converts between
UTF-8 and UCS-2 (not UTF-16). The U+1D11E is outside the basic multilingual
plane, so is not valid UCS-2.

I need to use a different codecvt facet for UTF-16.

[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
On the store-merging side
--- gimple-ssa-store-merging.c.jj   2019-01-01 12:37:19.063943678 +0100
+++ gimple-ssa-store-merging.c  2019-04-29 16:45:38.333266338 +0200
@@ -4164,7 +4164,8 @@ lhs_valid_for_store_merging_p (tree lhs)
   tree_code code = TREE_CODE (lhs);

   if (code == ARRAY_REF || code == ARRAY_RANGE_REF || code == MEM_REF
-  || code == COMPONENT_REF || code == BIT_FIELD_REF)
+  || code == COMPONENT_REF || code == BIT_FIELD_REF
+  || DECL_P (lhs))
 return true;

   return false;
alone fixes that.  But the whole PR88709 needs to be fixed of course.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[jakub at gcc dot gnu.org]

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

Bug 90257 Summary: [10 Regression] 8% degradation on cpu2006 403.gcc starting 
with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257

   What|Removed |Added

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

[Bug target/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx

[jakub at gcc dot gnu.org]

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

Bug 90257 Summary: [10 Regression] 8% degradation on cpu2006 403.gcc starting 
with r270484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90257

   What|Removed |Added

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

[Bug rtl-optimization/90257] [10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #17 from Jakub Jelinek  ---
Should be fixed now.

[Bug libstdc++/90281] utf-8 encoded std::filesystem::path can not be converted to utf-16.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-29
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/90050] std::filesystem::path segfault in destructor

[doko at debian dot org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #8 from Matthias Klose  ---
that's now mitigated by a local patch, always linking with -lstdc++fs.

https://salsa.debian.org/toolchain-team/gcc/blob/gcc-8-debian/debian/patches/pr90050.diff

[Bug target/90260] function multiversioning: template functions not supported

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
> Also somewhat irrelevant, GCC supports function multiversioning in class
> constructors, whereas clang doesn't:
> https://bugs.llvm.org/show_bug.cgi?id=41614
> 

Ah, ok, so then a C++ maintainer should help us here.

[Bug target/90260] function multiversioning: template functions not supported

[nheart at gmail dot com]

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

--- Comment #2 from Nikolay Bogoychev  ---
Hey Martin,

I know clang doesn't support that. I have opened a separate bug report there
https://bugs.llvm.org/show_bug.cgi?id=41613

Based on some discussions on their mailing lists, it seems like this is a
planned feature.

Also somewhat irrelevant, GCC supports function multiversioning in class
constructors, whereas clang doesn't:
https://bugs.llvm.org/show_bug.cgi?id=41614

Cheers,

Nick

[Bug libstdc++/90281] New: utf-8 encoded std::filesystem::path can not be converted to utf-16.

[ssh at pobox dot com]

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

Bug ID: 90281
   Summary: utf-8 encoded std::filesystem::path can not be
converted to utf-16.
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ssh at pobox dot com
  Target Milestone: ---

During tests on an implementation of a std::fs compatible backport for
C++11/C++14 I found the following issue when running my checks against GCCs
C++17 std::fs code. The following example

#include 

int main()
{
auto p = std::filesystem::u8path("\xf0\x9d\x84\x9e").u16string();
return 0;
}

fails with:

terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: Cannot convert character sequence: Invalid or
incomplete multibyte or wide character

Tested with GCC 8.1.0 and 8.2.0 on Ubuntu 18.04 and macOS, and GCC 8.3.0 on
Wandbox.

The UTF-8 sequence is the musical symbol "clef" (U+1D11E) and on both systems I
can create a file with that name, e.g. from the shell. Even when then iterating
over the directory and calling u16string() on the filename of the
directory_entry, this exception will be thrown, but the example code is
simpler.

(Just as additional info: \xf0\x9d\x84\x9e is the correct UTF8 encoding for
U+1D11E and this works with clang and its libc++/libc++fs.)

[Bug rtl-optimization/90280] New: [9/10 Regression] ICE: in lra_assign, at lra-assigns.c:1650 with -O -fno-dce -fno-forward-propagate -fno-omit-frame-pointer

[zsojka at seznam dot cz]

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

Bug ID: 90280
   Summary: [9/10 Regression] ICE: in lra_assign, at
lra-assigns.c:1650 with -O -fno-dce
-fno-forward-propagate -fno-omit-frame-pointer
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi

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

Compiler output:
$ armv7a-hardfloat-linux-gnueabi-gcc -O -fno-dce -fno-forward-propagate
-fno-omit-frame-pointer testcase.c 
during RTL pass: reload
testcase.c: In function 'foo':
testcase.c:13:1: internal compiler error: in lra_assign, at lra-assigns.c:1650
   13 | }
  | ^
0xc3093a lra_assign(bool&)
/repo/gcc-trunk/gcc/lra-assigns.c:1650
0xc2a5ca lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.c:2534
0xbd5369 do_reload
/repo/gcc-trunk/gcc/ira.c:5516
0xbd5369 execute
/repo/gcc-trunk/gcc/ira.c:5700
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-270639-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/10.0.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
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-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-270639-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 10.0.0 20190429 (experimental) (GCC)

[Bug c/90036] [8/9/10 Regression] false positive: directive argument is null [-Werror=format-overflow=]

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
(In reply to Martin Sebor from comment #5)
> A conversion specification is what follows the % character (i.e., just the
> 's' in in something like "%3s", with the 's' being called a conversion
> specifier).

7.21.6.1/4.  's' is the "conversion specifier character", but the whole
thing is the "conversion specification", including the percent sign.

/3 says a directive is a conversion specification or an ordinary character,
so imho it isn't great to refer to directives in the warning (also it's the
first time I heard it called that; I hazard I'm not the only one.

> The use of plain here null comes -Wnonnull: null argument where non-null
> required.  I don't see that as a problem but I also wouldn't have an issue
> with changing both to "null pointer" (like -Wformat prints) just as long as
> it's done consistently.

Right.  There are two goals to warnings:

1) They should be *correct*;
2) they should be helpful.

Sometimes these two bite each other.  Rephrasing can help sometimes.

[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
(In reply to Richard Biener from comment #6)

The trouble is that there is no way to tell whether

  error ("BIT_FIELD_REF of non-mode-precision operand");

is a user-facing error or an internal error not meant to be translated.  The
#pragma GCC diagnostic ignored "-Wformat-diag" solution suppresses the warning
but won't help translators.  The only ways to deal with that that comes to mind
are either a new  inernal_error_and_continue() function or some special
annotation in the format string to make it clear both to -Wformat-diag and to
translators that the string isn't meant to be translated (or checked for
translation problems).  Is there a preference for one or other approach?  Or
some other solution I'm not thinking of?

[Bug target/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Mon Apr 29 14:18:55 2019
New Revision: 270653

URL: https://gcc.gnu.org/viewcvs?rev=270653=gcc=rev
Log:
PR rtl-optimization/90257
* cfgrtl.c (flow_active_insn_p): Return true for USE of a function
return value.

Revert the revert:
2019-04-21  H.J. Lu  

PR target/90178
Revert:
2018-11-21  Uros Bizjak  

Revert the revert:
2013-10-26  Vladimir Makarov  

Revert:
2013-10-25  Vladimir Makarov  

* lra-spills.c (lra_final_code_change): Remove useless move insns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgrtl.c
trunk/gcc/lra-spills.c

[Bug rtl-optimization/90257] [10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Mon Apr 29 14:18:55 2019
New Revision: 270653

URL: https://gcc.gnu.org/viewcvs?rev=270653=gcc=rev
Log:
PR rtl-optimization/90257
* cfgrtl.c (flow_active_insn_p): Return true for USE of a function
return value.

Revert the revert:
2019-04-21  H.J. Lu  

PR target/90178
Revert:
2018-11-21  Uros Bizjak  

Revert the revert:
2013-10-26  Vladimir Makarov  

Revert:
2013-10-25  Vladimir Makarov  

* lra-spills.c (lra_final_code_change): Remove useless move insns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgrtl.c
trunk/gcc/lra-spills.c

[Bug c/90036] [8/9/10 Regression] false positive: directive argument is null [-Werror=format-overflow=]

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
(In reply to Dmitry G. Dyachenko from comment #3)

The null pointer detection was added in r265648 so that would be the change
responsible for the warning.  As Jeff noted, the root cause of false positives
here isn't the warning itself but a missing optimization.  We will be making
some design changes to the printf warning pass in GCC 10 that could affect the
false positive rate so they might also give us an opportunity to look into the
missed dom optimization. 

(In reply to Segher Boessenkool from comment #4)

I agree the underlining could stand to be improved here (tracking is separately
would increase the odds of it getting fixed).

A conversion specification is what follows the % character (i.e., just the 's'
in in something like "%3s", with the 's' being called a conversion specifier). 
A directive either includes the % character and whatever follows up to the end
of the conversion specification, or is a plain character.  For simplicity,
-Wformat-overflow refers to whole strings of one or more ordinary characters
that don't form a conversion specification as directives.

The use of plain here null comes -Wnonnull: null argument where non-null
required.  I don't see that as a problem but I also wouldn't have an issue with
changing both to "null pointer" (like -Wformat prints) just as long as it's
done consistently.

[Bug middle-end/90263] Calls to mempcpy should use memcpy

[wilco at gcc dot gnu.org]

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

--- Comment #18 from Wilco  ---
(In reply to Martin Liška from comment #14)
> Created attachment 46262 [details]
> Patch candidate
> 
> Patch candidate that handles:
> 
> $ cat ~/Programming/testcases/mempcpy.c
> int *mempcopy2 (int *p, int *q, long n)
> {
>   return __builtin_mempcpy (p, q, n);
> }
> 
> $ ./xgcc -B. -O2 -S ~/Programming/testcases/mempcpy.c -o/dev/stdout
> ...
> mempcopy2:
> .LFB0:
>   .cfi_startproc
>   pushq   %rbx
>   .cfi_def_cfa_offset 16
>   .cfi_offset 3, -16
>   movq%rdx, %rbx
>   callmemcpy
>   addq%rbx, %rax
>   popq%rbx
>   .cfi_def_cfa_offset 8
>   ret
> ...
> 
> There's a single failing test: gcc.dg/20050503-1.c

On AArch64 it calls mempcpy but memcpy on x86, which is the wrong way around...

-  if (retmode == RETURN_END && target != const0_rtx)
+  if (!TARGET_HAS_FAST_MEMPCPY_ROUTINE && retmode == RETURN_END && target !=
const0_rtx)

When I uncomment this, it uses memcpy. Also:

+TARGET_HAS_FAST_MEMPCPY_ROUTINE
+&& retmode == RETURN_END_MINUS_ONE,
+_move_done);

Should that be RETURN_END? And is_move_done isn't used, is that right?

[Bug other/90257] [10 Regression] 8% degradation on cpu2006 403.gcc starting with r270484

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
I have tried:
--- gcc/cfgrtl.c(revision 270605)
+++ gcc/cfgrtl.c(working copy)
@@ -557,7 +557,8 @@ flow_active_insn_p (const rtx_insn *insn
  keep the return value from being live across the entire
  function.  If we allow it to be skipped, we introduce the
  possibility for register lifetime confusion.  */
-  if (GET_CODE (PATTERN (insn)) == CLOBBER
+  if ((GET_CODE (PATTERN (insn)) == CLOBBER
+   || GET_CODE (PATTERN (insn)) == USE)
   && REG_P (XEXP (PATTERN (insn), 0))
   && REG_FUNCTION_VALUE_P (XEXP (PATTERN (insn), 0)))
 return true;
--- gcc/lra-spills.c(revision 270605)
+++ gcc/lra-spills.c(working copy)
@@ -740,6 +740,7 @@ lra_final_code_change (void)
   int i, hard_regno;
   basic_block bb;
   rtx_insn *insn, *curr;
+  rtx set;
   int max_regno = max_reg_num ();

   for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
@@ -818,5 +819,19 @@ lra_final_code_change (void)
  }
  if (insn_change_p)
lra_update_operator_dups (id);
+
+ if ((set = single_set (insn)) != NULL
+ && REG_P (SET_SRC (set)) && REG_P (SET_DEST (set))
+ && REGNO (SET_SRC (set)) == REGNO (SET_DEST (set)))
+   {
+ /* Remove an useless move insn.  IRA can generate move
+insns involving pseudos.  It is better remove them
+earlier to speed up compiler a bit.  It is also
+better to do it here as they might not pass final RTL
+check in LRA, (e.g. insn moving a control register
+into itself).  */
+ lra_invalidate_insn_data (insn);
+ delete_insn (insn);
+   }
}
 }

on trunk, passed bootstrap/regtest and compared bootstrap with just the
lra-spills.c change.
Besides cfgrtl.o (expected) there were changes in
dwarf2asm.o
gimple-ssa-evrp.o
ipa-utils.o
reload1.o
reload.o
tree-data-ref.o
tree.o
tree-scalar-evolution.o
between the 2 stage3 gcc/ directories, but in some cases changes in debug info
only, in other cases mostly changes like:
--- tree-scalar-evolution.s_2019-04-29 15:24:02.029836995 +0200
+++ tree-scalar-evolution.s 2019-04-29 15:26:22.216589907 +0200
@@ -6537,7 +6537,30 @@ _ZL18find_var_scev_infoP15basic_block_de
jmp .L1172
.p2align 4,,10
.p2align 3
+.L1187:
+   movl%r9d, 36(%rbp)
+.L1176:
+   addq$24, %rsp
+   .cfi_remember_state
+   .cfi_def_cfa_offset 56
+   addq$8, %rax
+   popq%rbx
+   .cfi_def_cfa_offset 48
+   popq%rbp
+   .cfi_def_cfa_offset 40
+   popq%r12
+   .cfi_def_cfa_offset 32
+   popq%r13
+   .cfi_def_cfa_offset 24
+   popq%r14
+   .cfi_def_cfa_offset 16
+   popq%r15
+   .cfi_def_cfa_offset 8
+   ret
+   .p2align 4,,10
+   .p2align 3
 .L1177:
+   .cfi_restore_state
movq%rcx, %r12
.p2align 4,,10
.p2align 3
@@ -6560,28 +6583,10 @@ _ZL18find_var_scev_infoP15basic_block_de
movl84(%r8), %edx
movl%edx, 4(%rax)
movq%rax, (%r12)
-.L1176:
-   addq$24, %rsp
-   .cfi_remember_state
-   .cfi_def_cfa_offset 56
-   addq$8, %rax
-   popq%rbx
-   .cfi_def_cfa_offset 48
-   popq%rbp
-   .cfi_def_cfa_offset 40
-   popq%r12
-   .cfi_def_cfa_offset 32
-   popq%r13
-   .cfi_def_cfa_offset 24
-   popq%r14
-   .cfi_def_cfa_offset 16
-   popq%r15
-   .cfi_def_cfa_offset 8
-   ret
+   jmp .L1176
.p2align 4,,10
.p2align 3
 .L1170:
-   .cfi_restore_state
movl%r9d, 36(%rbp)
testq   %r12, %r12
je  .L1177
@@ -6597,11 +6602,6 @@ _ZL18find_var_scev_infoP15basic_block_de
movq8(%rbp), %rsi
movq8(%rsp), %r8
jmp .L1163
-   .p2align 4,,10
-   .p2align 3
-.L1187:
-   movl%r9d, 36(%rbp)
-   jmp .L1176
.cfi_endproc
.section.text.unlikely
.cfi_startproc
wgere just some bbs are moved around, but the *.s length is the same.  In
gimple-ssa-evrp.s there is a one byte difference in *.s size, guess just
different label numbers plus reordering.
The only larger change is ipa-utils.s, without the cfgrtl.c hunk 96603 bytes,
with that change 96479 bytes of assembly, but just 18038 vs. 18022 bytes of
.text.

[Bug libstdc++/87982] No error for std::generate_n(ptr, ptr, f)

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Addressed in r270651

[Bug tree-optimization/90270] [8/9/10 Regression] Do not select best induction variable optimization

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Mon, 29 Apr 2019, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90270
> 
> --- Comment #10 from bin cheng  ---
> (In reply to Richard Biener from comment #9)
> > (In reply to bin cheng from comment #7)
> > > Also, when calling move_fixed_address_to_symbol, fixed_address_object_p
> > > looks too restricted, it only considers link time constant address.  In 
> > > this
> > > case, it's an array object in stack.
> > 
> > But this is because a stack access isn't $reloc but $sp + offset and thus
> > _not_ a symbol.
> From ivopts/loop's point of view, the address ($sp + offset) is loaded into
> register, then the register is used to address elements in array.  In other
> words, it doesn't really matter if the address is global and determined by
> linker or local and determined by stack frame.

I thought 'symbol' in move_fixed_address_to_symbol was really meant to
be a [relocatable] absolute address.  A stack var can be still moved
to 'base' (and we do not account for the stack offset in IVOs
compute - that will either be forwarded to 'offset' during RTL or
as you said stay as separate stmt)

> > 
> > But as you noticed IVOPTs computing TARGET_MEM_REF so "early" is a bit
> > brittle due to later eventual forwardings.  And those forwardings are
> > hard to avoid because they affect fundamental predicates like
> > may_propagate_copy where we decide early whether we can propagte into
> > all uses before actually visiting them.
> Can we avoid propagating into TARGET_MEM_REF if it creates invalid addressing
> mode?  IIUC, passes (like ivopts, slsr) creating TARGET_MEM_REF do generate
> "correct" addressing mode, it doesn't make much sense to create invalid ones
> afterwards.

I think the only way to avoid propagating into it is to re-materialize
the propagated value right before the TARGET_MEM_REF.  There's no
good way to forbid propagating on the base of destination stmt
properties.

But I wonder if RTL expansion, based on this, cannot easily undo
such propagation?

[Bug libstdc++/71312] mutexes for shared_ptr atomics should be padded to cacheline size

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk.

[Bug middle-end/90263] Calls to mempcpy should use memcpy

[wilco at gcc dot gnu.org]

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

--- Comment #17 from Wilco  ---
(In reply to Wilco from comment #16)
> (In reply to Martin Sebor from comment #15)
> > I just noticed I have been misreading mempcpy as memccpy and so making no
> > sense.  Sorry about that!  Please ignore my comments.
> 
> I see, yes we have too many and the names are too similar. Now all we need
> is someone to propose strlpcpy or stplcpy...

https://github.com/fishilico/shared/blob/master/linux/nolibc/uname.c

Aargh...

[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox

[rsandifo at gcc dot gnu.org]

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

--- Comment #19 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #18)
> (In reply to rsand...@gcc.gnu.org from comment #17)
> > Created attachment 46261 [details]
> > Doing the removal in find_obviously_necessary_stmts
> > 
> > Just for the record: I'd written this over the weekend for completely
> > unrelated reasons (was looking at debug info, and wanted to replicate the
> > DCE that is already done in RTL).  It doesn't include the DEBUG_EXPR_DECL
> > stuff, so obviously can't go in as-is, but it means that we never even add
> > the redundant instructions to the worklist.
> 
> Yeah, that looks nearly equivalent (same issue with DEBUG_EXPR_DECLs though).
> 
> I think doing it in eliminate_unnecessary_stmts is slightly better for the
> case where we come from 
> 
>   # DEBUG i => NULL;
>   i_3 = 1;
>   # DEBUG i => i_3;
> 
> and are about to DCE i_3

Ah, yeah.

[Bug middle-end/90263] Calls to mempcpy should use memcpy

[wilco at gcc dot gnu.org]

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

--- Comment #16 from Wilco  ---
(In reply to Martin Sebor from comment #15)
> I just noticed I have been misreading mempcpy as memccpy and so making no
> sense.  Sorry about that!  Please ignore my comments.

I see, yes we have too many and the names are too similar. Now all we need is
someone to propose strlpcpy or stplcpy...

[Bug libstdc++/87982] No error for std::generate_n(ptr, ptr, f)

[j.v.dijk at tue dot nl]

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

--- Comment #10 from Jan van Dijk  ---
Thanks a lot. And sorry for being pedantic, but I believe that the
documentation of the return value of generate_n is still wrong for negative __n
(see the first part of comment #5).

[Bug middle-end/90263] Calls to mempcpy should use memcpy

[msebor at gcc dot gnu.org]

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

--- Comment #15 from Martin Sebor  ---
I just noticed I have been misreading mempcpy as memccpy and so making no
sense.  Sorry about that!  Please ignore my comments.

[Bug debug/90279] New: DW_AT_location missing for struct-based Variable

[daniel.penning at embeff dot com]

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

Bug ID: 90279
   Summary: DW_AT_location missing for struct-based Variable
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.penning at embeff dot com
  Target Milestone: ---


struct StrongType {
explicit StrongType(int val) : m_value(val) { }
int m_value;
};

StrongType Square(StrongType val) {
return StrongType{val.m_value * val.m_value};
}

int EvalDwarfStrong(int var) {
StrongType strongArg{var};
StrongType strongRes = Square(strongArg);
return strongRes.m_value;
}


gcc -Og -g
dwarfdump outputs the following information for the strongArg variable:

< 2><0x00a6>  DW_TAG_variable
DW_AT_name  strongArg
DW_AT_decl_file 0x0001
/DwarfStrong.cpp
DW_AT_decl_line 0x000b
DW_AT_type  <0x002d>



There is no DW_AT_location specified, so a debugger will not be able to display
its value.
This is not a problem-per-se with the struct since the DWARF output for the
Square() function argument is using a correct DW_AT_location.
The compiler is not inlining the function call with -Og so the variable will be
available right before the function call to Square().
Using the same code, but with a plain int instead of the struct-wrapper yields
the desired output:

-
int Square(int val) {
return val*val;
}

int EvalDwarfUnsafe(int var) {
int unsafeArg{var};
int unsafeRes = Square(unsafeArg);
return unsafeRes;
}


< 2><0x0061>  DW_TAG_variable
DW_AT_name  unsafeArg
DW_AT_decl_file
0x0001/DwarfUnsafe.cpp
DW_AT_decl_line 0x0006
DW_AT_type  <0x0093>
DW_AT_location  
[ 0]< offset pair low-off : 0x0006 addr  0x0006
high-off  0x000a addr 0x000a>DW_OP_reg5
[ 1]< offset pair low-off : 0x000a addr  0x000a
high-off  0x000d addr 0x000d>DW_OP_GNU_entry_value 0x0001 contents
0x55 DW_OP_stack_value

[Bug middle-end/90263] Calls to mempcpy should use memcpy

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
Created attachment 46262
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46262=edit
Patch candidate

Patch candidate that handles:

$ cat ~/Programming/testcases/mempcpy.c
int *mempcopy2 (int *p, int *q, long n)
{
  return __builtin_mempcpy (p, q, n);
}

$ ./xgcc -B. -O2 -S ~/Programming/testcases/mempcpy.c -o/dev/stdout
...
mempcopy2:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdx, %rbx
callmemcpy
addq%rbx, %rax
popq%rbx
.cfi_def_cfa_offset 8
ret
...

There's a single failing test: gcc.dg/20050503-1.c

[Bug target/90260] function multiversioning: template functions not supported

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-29
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
It's unsupported feature, we should provide a reasonable error message.
Note that clang++ also rejects that:

$ clang++ pr90260.cc
pr90260.cc:7:39: error: attribute 'target' multiversioned functions do not yet
support function templates
__attribute__ ((target("default"))) T foo(T num) {
  ^
1 error generated.

[Bug tree-optimization/90278] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-29
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  forward_propagate_into_comparison changes

_5 = 1.0/0.0;
_6 = _5 < 0.0;

into

_6 = false;

but fails to clear EH info.

[Bug libstdc++/71312] mutexes for shared_ptr atomics should be padded to cacheline size

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon Apr 29 12:55:29 2019
New Revision: 270649

URL: https://gcc.gnu.org/viewcvs?rev=270649=gcc=rev
Log:
PR libstdc++/71312 Increase alignment of pooled mutexes

PR libstdc++/71312
* src/c++11/shared_ptr.cc (get_mutex): Align pool mutexes to 64 bytes.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/shared_ptr.cc

[Bug middle-end/90263] Calls to mempcpy should use memcpy

[msebor at gcc dot gnu.org]

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

--- Comment #13 from Martin Sebor  ---
I mean an equivalent of the following (with suitable symbol linkage):

  void* memccpy (void *d, const void *s, int c, size_t n)
  {
// efficient memccpy, perhaps in assembly
  }

  void* memcpy (void *d, const void *s, size_t n)
  {
memccpy (d, s, 0, n);
return d;
  }

[Bug tree-optimization/90278] New: ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[asolokha at gmx dot com]

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

Bug ID: 90278
   Summary: ICE: verify_gimple failed (error: statement marked for
throw, but doesn't)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha20190428 snapshot (r270633), 8.3, 7.3, 6.3 all ICE when
compiling the following testcase at any optimization level (except -Ofast) and
w/ -fexceptions -fnon-call-exceptions:

double
hc (void)
{
  double dp = 0.0;
  double ek[1];

  ek[0] = 1.0 / dp < 0.0;

  return ek[0];
}

% gcc-9.0.0-alpha20190428 -O1 -fexceptions -fnon-call-exceptions -c dhh1zxr0.c
dhh1zxr0.c: In function 'hc':
dhh1zxr0.c:10:1: error: statement marked for throw, but doesn't
   10 | }
  | ^
_6 = 0;
during GIMPLE pass: forwprop
dhh1zxr0.c:10:1: internal compiler error: verify_gimple failed
0xd992ed verify_gimple_in_cfg(function*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190428/work/gcc-9-20190428/gcc/tree-cfg.c:5386
0xc6c24f execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190428/work/gcc-9-20190428/gcc/passes.c:1977
0xc6d16e execute_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190428/work/gcc-9-20190428/gcc/passes.c:2031

[Bug rtl-optimization/90249] [9/10 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398

[rearnsha at gcc dot gnu.org]

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

--- Comment #8 from Richard Earnshaw  ---
(In reply to Richard Earnshaw from comment #7)
> (In reply to Segher Boessenkool from comment #4)
> > That is code *size*.  Code size is expected to grow a tiny bit, because of
> > *better* register allocation.
> > 
> > But we could not do make_more_copies at -Os, if that helps?  (The hard
> > register
> > changes themselves are required for correctness).
> 
> In this case, however, we get *worse* register allocation, since it is using
> the the expensive register more frequently than a cheaper register which is
> hardly used at all.
> 
> In this particular case, all the uses of the "cheap" register (r7) could use
> the 'expensive' register at no additional cost, since the cheap register is
> being used only to hold a value that will be moved to another register (a
> cheap operation regardless of the register used).

FTR, I don't think the combine changes are directly implicated in this
regression.  They just expose a latent issue with register allocation and its
costing.

[Bug rtl-optimization/90249] [9/10 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398

[rearnsha at gcc dot gnu.org]

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

--- Comment #7 from Richard Earnshaw  ---
(In reply to Segher Boessenkool from comment #4)
> That is code *size*.  Code size is expected to grow a tiny bit, because of
> *better* register allocation.
> 
> But we could not do make_more_copies at -Os, if that helps?  (The hard
> register
> changes themselves are required for correctness).

In this case, however, we get *worse* register allocation, since it is using
the the expensive register more frequently than a cheaper register which is
hardly used at all.

In this particular case, all the uses of the "cheap" register (r7) could use
the 'expensive' register at no additional cost, since the cheap register is
being used only to hold a value that will be moved to another register (a cheap
operation regardless of the register used).

[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
(In reply to rsand...@gcc.gnu.org from comment #17)
> Created attachment 46261 [details]
> Doing the removal in find_obviously_necessary_stmts
> 
> Just for the record: I'd written this over the weekend for completely
> unrelated reasons (was looking at debug info, and wanted to replicate the
> DCE that is already done in RTL).  It doesn't include the DEBUG_EXPR_DECL
> stuff, so obviously can't go in as-is, but it means that we never even add
> the redundant instructions to the worklist.

Yeah, that looks nearly equivalent (same issue with DEBUG_EXPR_DECLs though).

I think doing it in eliminate_unnecessary_stmts is slightly better for the
case where we come from 

  # DEBUG i => NULL;
  i_3 = 1;
  # DEBUG i => i_3;

and are about to DCE i_3 (I think that's not handled by my patch either
without further tweaks).  No debug-stmt support in the GIMPLE FE right now
so not so easy to test atm.  For 

int main()
{
  int i;
  i = 1, i = 2;
  return i+1;
}

with -O -g -fdisable-tree-ccp1 -fdisable-tree-fre1 -fdisable-tree-evrp we
go from

   :
  # DEBUG BEGIN_STMT
  # DEBUG BEGIN_STMT
  i_1 = 1;
  # DEBUG i => i_1
  i_2 = 2;
  # DEBUG i => i_2
  # DEBUG BEGIN_STMT
  _3 = 3;
  return 3;

after DSE1 to

   :
  # DEBUG BEGIN_STMT
  # DEBUG BEGIN_STMT
  # DEBUG i => 1
  # DEBUG i => 2
  # DEBUG BEGIN_STMT
  return 3;

after CDDCE1 which could be improved to just # DEBUG i => 2 (note the
missing DEBUG BEGIN_STMT for compound stmts).  The following would do
that trick (doing a bit more debug DCE on the testcase in this PR)

Index: gcc/tree-ssa-dce.c
===
--- gcc/tree-ssa-dce.c  (revision 270645)
+++ gcc/tree-ssa-dce.c  (working copy)
@@ -1282,11 +1283,15 @@ eliminate_unnecessary_stmts (void)
  if (!is_gimple_debug (stmt))
something_changed = true;
  remove_dead_stmt (, bb, to_remove_edges);
+ continue;
}
  else if (is_gimple_call (stmt))
{

[Bug rtl-optimization/90249] [9/10 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
(In reply to Wilco from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > That is code *size*.  Code size is expected to grow a tiny bit, because of
> > *better* register allocation.
> > 
> > But we could not do make_more_copies at -Os, if that helps?  (The hard
> > register
> > changes themselves are required for correctness).
> 
> Better register allocation implies lower average codesize due to fewer
> spills, fewer callee-saves, fewer moves etc.

That depends on the case.  And we are dealing with a quite specialised case
here.

> I still don't understand what specific problem make_more_copies is trying to
> solve. Is it trying to do life-range splitting of argument registers?

Nope.  It is simply that before the hard-reg change we very often combined the
argument register moves with other insns to something a different form than
those other insns, importantly when we can do this because we know how those
values are extended, etc.  make_more_copies simply inserts another reg-reg move
so that that new move can do this instead, since we no longer combine the hard
register move.  Without this we get a lot of actual code quality regressions.

[Bug rtl-optimization/90249] [9/10 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #5 from Wilco  ---
(In reply to Segher Boessenkool from comment #4)
> That is code *size*.  Code size is expected to grow a tiny bit, because of
> *better* register allocation.
> 
> But we could not do make_more_copies at -Os, if that helps?  (The hard
> register
> changes themselves are required for correctness).

Better register allocation implies lower average codesize due to fewer spills,
fewer callee-saves, fewer moves etc.

I still don't understand what specific problem make_more_copies is trying to
solve. Is it trying to do life-range splitting of argument registers?

[Bug middle-end/90263] Calls to mempcpy should use memcpy

[wilco at gcc dot gnu.org]

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

--- Comment #12 from Wilco  ---
(In reply to Martin Sebor from comment #11)
> My concern is that transforming memccpy to memcpy would leave little
> incentive for libraries like glibc to provide a more optimal implementation.
> Would implementing the function simply as memcpy and having the latter
> return the result of the former be a viable option?  Basically, rename
> memcpy to meccpy, parameterizing it on the termination character in the
> process, and change memcpy to call memccpy and return the first pointer.

I have no idea what you mean - there is no way you can implement memcpy using
memccpy. It never makes sense to slow down a performance critical function in
order to speed up an infrequently used one.

[Bug rtl-optimization/90275] [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.4

[Bug rtl-optimization/90249] [9/10 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
That is code *size*.  Code size is expected to grow a tiny bit, because of
*better* register allocation.

But we could not do make_more_copies at -Os, if that helps?  (The hard register
changes themselves are required for correctness).

[Bug libstdc++/90276] FAIL: 20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Lots of others fail too:

make check RUNTESTFLAGS=conformance.exp="*/pstl/* \
  --target_board=unix/-D_GLIBCXX_DEBUG"
...

FAIL: 20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc execution
test
FAIL: 25_algorithms/pstl/alg_merge/inplace_merge.cc execution test
FAIL: 25_algorithms/pstl/alg_merge/merge.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/copy_if.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/copy_move.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/fill.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/generate.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/is_partitioned.cc execution
test
FAIL: 25_algorithms/pstl/alg_modifying_operations/partition.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/partition_copy.cc execution
test
FAIL: 25_algorithms/pstl/alg_modifying_operations/remove.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/remove_copy.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/replace.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/replace_copy.cc execution
test
FAIL: 25_algorithms/pstl/alg_modifying_operations/rotate.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/rotate_copy.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/swap_ranges.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/transform_binary.cc execution
test
FAIL: 25_algorithms/pstl/alg_modifying_operations/transform_unary.cc execution
test
FAIL: 25_algorithms/pstl/alg_modifying_operations/unique.cc execution test
FAIL: 25_algorithms/pstl/alg_modifying_operations/unique_copy_equal.cc
execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/adjacent_find.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/all_of.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/any_of.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/count.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/equal.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/find.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/find_end.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/find_first_of.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/find_if.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/for_each.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/mismatch.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/none_of.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/nth_element.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/reverse.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/reverse_copy.cc execution test
FAIL: 25_algorithms/pstl/alg_nonmodifying/search_n.cc execution test
FAIL: 25_algorithms/pstl/alg_sorting/includes.cc execution test
FAIL: 25_algorithms/pstl/alg_sorting/is_heap.cc execution test
FAIL: 25_algorithms/pstl/alg_sorting/is_sorted.cc execution test
FAIL: 25_algorithms/pstl/alg_sorting/lexicographical_compare.cc execution test
FAIL: 25_algorithms/pstl/alg_sorting/minmax_element.cc execution test
FAIL: 25_algorithms/pstl/alg_sorting/partial_sort.cc execution test
FAIL: 25_algorithms/pstl/alg_sorting/partial_sort_copy.cc execution test
FAIL: 25_algorithms/pstl/alg_sorting/set.cc execution test
FAIL: 25_algorithms/pstl/alg_sorting/sort.cc execution test
FAIL: 26_numerics/pstl/numeric_ops/adjacent_difference.cc execution test
FAIL: 26_numerics/pstl/numeric_ops/reduce.cc execution test
FAIL: 26_numerics/pstl/numeric_ops/scan.cc execution test
FAIL: 26_numerics/pstl/numeric_ops/transform_reduce.cc execution test
FAIL: 26_numerics/pstl/numeric_ops/transform_scan.cc execution test

[Bug libstdc++/87982] No error for std::generate_n(ptr, ptr, f)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed on trunk.

[Bug libstdc++/87982] No error for std::generate_n(ptr, ptr, f)

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Mon Apr 29 12:12:43 2019
New Revision: 270646

URL: https://gcc.gnu.org/viewcvs?rev=270646=gcc=rev
Log:
PR libstdc++/87982 Fix generate_n and fill_n use of _Size parameter

The standard only requires that _Size can be converted to an integral
type, not that it can be used for arithmetic. Add a new set of
__size_to_integer helper functions to do the conversion (which will be
ambiguous if there is no one conversion that is better than any others).

Also add tests for DR 426 which requires these algorithms and search_n
to handle negative values of n.

PR libstdc++/87982
* include/bits/stl_algo.h (generate_n): Convert _Size parameter to
an integral type.
* include/bits/stl_algobase.h (__size_to_integer): New overloaded
functions to convert a value to an integral type.
(__fill_n_a, __fill_n_a): Assert that __n is already an integral type.
(fill_n): Convert _Size parameter to an integral type.
* testsuite/25_algorithms/fill_n/dr426.cc: New test.
* testsuite/25_algorithms/generate_n/87982.cc: New test.
* testsuite/25_algorithms/generate_n/dr426.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/fill_n/87982.cc
trunk/libstdc++-v3/testsuite/25_algorithms/fill_n/87982_neg.cc
trunk/libstdc++-v3/testsuite/25_algorithms/fill_n/dr426.cc
trunk/libstdc++-v3/testsuite/25_algorithms/generate_n/87982.cc
trunk/libstdc++-v3/testsuite/25_algorithms/generate_n/87982_neg.cc
trunk/libstdc++-v3/testsuite/25_algorithms/generate_n/dr426.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h
trunk/libstdc++-v3/include/bits/stl_algobase.h

[Bug libstdc++/90277] New: Debug Mode test failures

[redi at gcc dot gnu.org]

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

Bug ID: 90277
   Summary: Debug Mode test failures
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: fdumont at gcc dot gnu.org
  Target Milestone: ---

I think these tests started to fail because of the PR 89608 changes:

FAIL: 23_containers/unordered_multimap/insert/24061-multimap.cc execution test
FAIL: 23_containers/unordered_multimap/insert/hint.cc execution test
FAIL: 23_containers/unordered_multiset/insert/24061-multiset.cc execution test

Presumably they're relying on properties of our unordered containers which are
not guaranteed by the standard (and so fail in debug mode, which is stricter).

[Bug middle-end/90263] Calls to mempcpy should use memcpy

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
My concern is that transforming memccpy to memcpy would leave little incentive
for libraries like glibc to provide a more optimal implementation.  Would
implementing the function simply as memcpy and having the latter return the
result of the former be a viable option?  Basically, rename memcpy to meccpy,
parameterizing it on the termination character in the process, and change
memcpy to call memccpy and return the first pointer.

[Bug middle-end/90263] Calls to mempcpy should use memcpy

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to Wilco from comment #6)
> (In reply to Martin Liška from comment #5)
> > The discussion looks familiar to me. Isn't that PR70140, where I was
> > suggesting something like:
> > 
> > https://marc.info/?l=gcc-patches=150166433909242=2
> > 
> > with a new target macro: TARGET_HAS_FAST_MEMPCPY_ROUTINE ?
> 
> Yes something like that should be fine. Unfortunately that patch doesn't
> apply anymore, and when I got it to compile it didn't do anything.

I'm testing an updated version of the patch right now..

[Bug libstdc++/90276] FAIL: 20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc execution test

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-29
 Ever confirmed|0   |1

[Bug libstdc++/90276] New: FAIL: 20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc execution test

[redi at gcc dot gnu.org]

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

Bug ID: 90276
   Summary: FAIL:
20_util/specialized_algorithms/pstl/uninitialized_copy
_move.cc execution test
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: rodgertq at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This test fails in Debug Mode i.e.

make check $RTF="20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc
--target_board=unix/-D_GLIBCXX_DEBUG"

The error is:

/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:874:
In function:
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >,
std::__debug::vector >,
std::random_access_iterator_tag>::difference_type
__gnu_debug::operator-(const _Self&, const _Self&)

Error: attempt to compute the difference between a singular iterator to a
singular iterator.

Objects involved in the operation:
iterator "__lhs" @ 0x0x7ffd09bd9760 {
  type = __gnu_cxx::__normal_iterator > > (mutable iterator);
  state = singular;
}
iterator "__rhs" @ 0x0x7ffd09bd9730 {
  type = __gnu_cxx::__normal_iterator > > (mutable iterator);
  state = singular;
}
FAIL: 20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc execution
test

[Bug libstdc++/90252] PSTL test failures

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #17 from rsandifo at gcc dot gnu.org  
---
Created attachment 46261
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46261=edit
Doing the removal in find_obviously_necessary_stmts

Just for the record: I'd written this over the weekend for completely unrelated
reasons (was looking at debug info, and wanted to replicate the DCE that is
already done in RTL).  It doesn't include the DEBUG_EXPR_DECL stuff, so
obviously can't go in as-is, but it means that we never even add the redundant
instructions to the worklist.

[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Created attachment 46260
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46260=edit
removed-unused-local patch

There do appear to be variables that are just appearing in # DEBUG var => NULL
stmts, not in debug binds and not referenced elsewhere.  But not many.
Mostly unused this variables it seems.  362 debug binds are dead this way
for the testcase (after the DCE patch).

[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
And it's indeed "caused" by the CFG-cleanup fixes.  The DCE patch gets us back
to (nearly) the same number of debug stmts as before.

[Bug rtl-optimization/90275] New: [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce

[zsojka at seznam dot cz]

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

Bug ID: 90275
   Summary: [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128
with -O2 -fno-dce -fno-tree-dce
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi

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

Compiler output:
$ armv7a-hardfloat-linux-gnueabi-gcc -O2 -fno-dce -fno-tree-dce testcase.c 
during RTL pass: cse_local
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: in insert_regs, at cse.c:1129
   11 | }
  | ^
0x7d954d insert_regs
/repo/gcc-trunk/gcc/cse.c:1129
0x16445a8 cse_insn
/repo/gcc-trunk/gcc/cse.c:5980
0x164783b cse_extended_basic_block
/repo/gcc-trunk/gcc/cse.c:6662
0x164783b cse_main
/repo/gcc-trunk/gcc/cse.c:6841
0x164874d rest_of_handle_cse_after_global_opts
/repo/gcc-trunk/gcc/cse.c:7820
0x164874d execute
/repo/gcc-trunk/gcc/cse.c:7871
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-270639-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/10.0.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
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-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-270639-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 10.0.0 20190429 (experimental) (GCC)

[Bug target/86984] invalid relocation accessing a const char array

[glaubitz at physik dot fu-berlin.de]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #6 from John Paul Adrian Glaubitz  ---
Is there a chance this can get backported to the gcc-8 branch?