[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||pascal_cuoq at hotmail dot com

--- Comment #13 from Richard Biener  ---
*** Bug 86026 has been marked as a duplicate of this bug. ***

[Bug c/86026] Document and/or change allowed operations on integer representation of pointers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
We have a (very old) duplicate bug for the RTL issue.

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

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2016-10-19 00:00:00 |2018-6-4
  Known to fail||8.1.0

--- Comment #14 from Richard Biener  ---
Reconfirmed.

[Bug tree-optimization/86038] [9 Regression] ICE in to_reg_br_prob_base, at profile-count.h:242

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-04
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I'll take a look.

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
IMHO as RTL drops the difference between pointers and integers (of the same
mode)
it has to drop the assumption that pointer arithmetic has to stay inside a
pointed-to object similar to how it has to drop reliance on undefined overflow
for optimization since it drops the notion of signedness.

The other choice may seem to take REG_POINTER setting conservative and only
have the assumption on REG_POINTER regs.  (and thus make sure to set
REG_POINTER and MEM_POINTER conservatively, which may be a difficult task on
its own)

[Bug tree-optimization/86038] [9 Regression] ICE in to_reg_br_prob_base, at profile-count.h:242

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
So instead of dropping the initialized_p () check in the original below we
should probably return NULL as well if !initialized_p ().

if (best->probability.initialized_p ()
&& best->probability.to_reg_br_prob_base () <= probability_cutoff)   
  return NULL;

Testing

Index: gcc/tracer.c
===
--- gcc/tracer.c(revision 261136)
+++ gcc/tracer.c(working copy)
@@ -159,7 +159,8 @@ find_best_successor (basic_block bb)
 }
   if (!best || ignore_bb_p (best->dest))
 return NULL;
-  if (best->probability.to_reg_br_prob_base () <= probability_cutoff)
+  if (!best->probability.initialized_p ()
+  || best->probability.to_reg_br_prob_base () <= probability_cutoff)
 return NULL;
   return best;
 }

[Bug tree-optimization/86038] [9 Regression] ICE in to_reg_br_prob_base, at profile-count.h:242

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug target/86036] [9 Regression] wrong code with -mavx512bw

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/85765] [8/9 Regression] Missing SFINAE in default template argument

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-04
 CC||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Thomas Schwinge  ---
For the record, I'm also seeing that ("[...]/ld: /tmp/cc[...].lto.o: plugin
needed to handle lto object") on x86_64-pc-linux-gnu, with binutils/ld version
2.25.51.

[Bug c++/85958] Make const qualifier error clear

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to W E Brown from comment #8)
> (2) For the same reason, the note accompanying the diagnostic might at the
> same time be more accurately rephrased as "initializing parameter 1 of ..."
> instead of the current "initializing argument 1 of ...".

Agreed.

> (3) Finally, there seems to be a fair amount of redundancy in the note,
> mentioning the called function both with and without its parameter's name. 
> Perhaps just one of these might suffice?

The first occurrence is the function type (including any template arguments),
and is always shown. The second is the verbatim line from the source code
highlighted with carets, but is only shown conditionally (caret diagnostics can
be disabled with -fno-diagnostics-show-caret) and might not show the entire
function declaration. For example:

template
void f(int, 
   T&)  
{ } 

int main()  
{   
  f(1, 1);
}


f.cc: In function ‘int main()’:
f.cc:8:9: error: cannot bind non-const lvalue reference of type ‘int&’ to an
rvalue of type ‘int’
   f(1, 1);
 ^
f.cc:2:6: note:   initializing argument 2 of ‘void f(int, T&) [with T = int]’
 void f(int,
  ^

Removing the note here would mean losing valuable information (the caret
diagnostic doesn't show the right line, which is a separate bug, but even with
that fixed would only show one line not the whole function declaration).

[Bug c++/86025] ICE with -Wduplicated-branches and OpenMP critical

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun  4 07:27:52 2018
New Revision: 261137

URL: https://gcc.gnu.org/viewcvs?rev=261137&root=gcc&view=rev
Log:
PR c++/86025
* tree.c (inchash::add_expr): Handle IDENTIFIER_NODE.

* c-c++-common/gomp/pr86025.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/pr86025.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c++/86025] ICE with -Wduplicated-branches and OpenMP critical

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun  4 07:34:06 2018
New Revision: 261138

URL: https://gcc.gnu.org/viewcvs?rev=261138&root=gcc&view=rev
Log:
PR c++/86025
* tree.c (inchash::add_expr): Handle IDENTIFIER_NODE.

* c-c++-common/gomp/pr86025.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/c-c++-common/gomp/pr86025.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree.c

[Bug tree-optimization/69615] 0 to limit signed range checks don't always use unsigned compare

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun  4 07:37:56 2018
New Revision: 261139

URL: https://gcc.gnu.org/viewcvs?rev=261139&root=gcc&view=rev
Log:
PR tree-optimization/69615
* fold-const.c (merge_ranges): If range1 is - [x, x] and x is the
maximum or minimum of the type, try to merge it also as if
range1 is + [-, x - 1] or + [x + 1, -].

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

Added:
trunk/gcc/testsuite/gcc.dg/pr69615.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/86008] std::quoted(std::basic_string_view) is missing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-31
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Matt Whitlock from comment #0)
> The following shim allows the code above to compile, although it is
> sub-optimal because it captures a std::basic_string_view by reference.

Have you profiled to see if that matters? A basic_string_view is twice the size
of a reference, which makes the returned _Quoted_string object larger (but then
since the iostream inserter takes it by reference, avoiding the
double-dereference might help).

[Bug target/86036] [9 Regression] wrong code with -mavx512bw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-04
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Broken with the PR85832 change.

[Bug target/86027] string literals get corrupted with -O3 and gas on solaris i386

[subscribe at teskor dot de]

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

--- Comment #2 from Michael Teske  ---
Comparing the assembler output got my guess confirmed.

The generated code on 7.3.0 starts with:
.file   "comperr.cpp"
.text
.section   
.gnu.linkonce.r._ZN19SystemCallExceptionC1EPKcl.str1.1,"aMS",@progbits,1
.LC0:
.string "Exception: "
.LC1:
.string "\n"
.LC2:
.string "12"


If I change the attributes of the first section in line 3 from .gnu.linkonce...
to
   .section.rodata

like it is on 8.1, the problem is gone.

[Bug target/85832] [AVX512] possible shorter code when comparing with vector of zeros

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Actually, vpcmpeq zmmX, zero and vptestm zmmX, zmmX perform exactly the
opposite, not the same thing, as vpcmpeq sets bits in the %kY register if zmmX
element is equal to 0, while vptestm if it is not equal to 0.
So we want to use vptestnm instead.

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #16 from Alexander Monakov  ---
What do you think about the suggestion made in the most recent duplicate,
namely expanding GIMPLE pointer-to-integer casts to non-transparent RTL
assignments, i.e. going from

  val = (intptr_t) ptr;

to

  asm ("" : "=g" (rval) : "0" (rptr));

Wouldn't this plug the hole in one shot instead of chasing down missing
REG_POINTERs in multiple RTL passes?

[Bug target/86003] [8/9 Regression] GCC fails to build when configured --with-cpu=xscale

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
Author: rearnsha
Date: Mon Jun  4 08:41:45 2018
New Revision: 261140

URL: https://gcc.gnu.org/viewcvs?rev=261140&root=gcc&view=rev
Log:
[arm] PR target/86003 build failures with --with-cpu=xscale

The XScale cpu configuration in GCC has always been somewhat
non-conforming.  Although XScale isn't an architecture (it's simply an
implementation of ARMv5te), we do by tradition emit a specific
pre-define for it.  We achieve this effect by adding an additional
feature bit to the xscale CPU definition that isn't part of the base
architecture.

When I restructured the options last year I overlooked this oddity and
the result, of course, is that this configuration now fails to build
as intended.

What happens is that the driver (correctly) constructs an architecture
for the xscale cpu name (as armv5te) and passes it in addition to the
CPU name.  The backend code, on finding both a cpu and an architecture
specifies attempts to correlate the two and finds a difference due to
the additional feature bit and reports an inconsistency (fatally if
-werror is specified).

I think the best fix to this is to treat the xscale feature bit using
the same mechanism that we use for other 'quirks' in CPU
implementations and simply filter it out before comparing the
capabilities.  It has the additional benefit that it's also the
simplest fix.

PR target/86003
* config/arm/arm-cpus.in (ALL_QUIRKS): Add xscale feature to the list
of bits to ignore when comparing architectures.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-cpus.in

[Bug target/86003] [8/9 Regression] GCC fails to build when configured --with-cpu=xscale

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  ---
Author: rearnsha
Date: Mon Jun  4 08:46:04 2018
New Revision: 261141

URL: https://gcc.gnu.org/viewcvs?rev=261141&root=gcc&view=rev
Log:
[arm] PR target/86003 build failures with --with-cpu=xscale

The XScale cpu configuration in GCC has always been somewhat
non-conforming.  Although XScale isn't an architecture (it's simply an
implementation of ARMv5te), we do by tradition emit a specific
pre-define for it.  We achieve this effect by adding an additional
feature bit to the xscale CPU definition that isn't part of the base
architecture.

When I restructured the options last year I overlooked this oddity and
the result, of course, is that this configuration now fails to build
as intended.

What happens is that the driver (correctly) constructs an architecture
for the xscale cpu name (as armv5te) and passes it in addition to the
CPU name.  The backend code, on finding both a cpu and an architecture
specifies attempts to correlate the two and finds a difference due to
the additional feature bit and reports an inconsistency (fatally if
-werror is specified).

I think the best fix to this is to treat the xscale feature bit using
the same mechanism that we use for other 'quirks' in CPU
implementations and simply filter it out before comparing the
capabilities.  It has the additional benefit that it's also the
simplest fix.

PR target/86003
* config/arm/arm-cpus.in (ALL_QUIRKS): Add xscale feature to the list
of bits to ignore when comparing architectures.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/arm/arm-cpus.in

[Bug target/86003] [8/9 Regression] GCC fails to build when configured --with-cpu=xscale

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Earnshaw  ---
Fixed on trunk and gcc-8 branch.

[Bug regression/81497] [7/8/9/ Regression] error compiling arm_acle.h

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
Summary|error compiling arm_acle.h  |[7/8/9/ Regression] error
   ||compiling arm_acle.h

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Testing a patch.

[Bug sanitizer/86022] TCB size calculated in ThreadDescriptorSize() is wrong for glibc-2.14

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||https://github.com/google/s
   ||anitizers/issues/966
   Last reconfirmed||2018-06-04
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I created upstream bug. I'm not familiar with glibc API, so let's wait for
confirmation of someone.

[Bug tree-optimization/85964] [8/9 Regression] compile time hog w/ -O3 -ftracer -fno-guess-branch-probability

[rguenth at gcc dot gnu.org]

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

Bug 86038 Summary: [9 Regression] ICE in to_reg_br_prob_base, at 
profile-count.h:242
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86038

   What|Removed |Added

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

[Bug tree-optimization/86038] [9 Regression] ICE in to_reg_br_prob_base, at profile-count.h:242

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Jun  4 09:28:22 2018
New Revision: 261142

URL: https://gcc.gnu.org/viewcvs?rev=261142&root=gcc&view=rev
Log:
2018-06-04  Richard Biener  

PR tree-optimization/86038
* tracer.c (find_best_successor): Check probability for
being initialized, bail out if not.

* gcc.dg/pr86038.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr86038.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tracer.c

[Bug tree-optimization/86038] [9 Regression] ICE in to_reg_br_prob_base, at profile-count.h:242

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Blocks||85964
 Resolution|--- |FIXED

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85964
[Bug 85964] [8/9 Regression] compile time hog w/ -O3 -ftracer
-fno-guess-branch-probability

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Ok and can you please analyze why this return true:

  1139/* Creating a symtab alias is the optimal way to merge.
  1140   It however can not be used in the following cases:
  1141  
  1142   1) if ORIGINAL and ALIAS may be possibly compared for address
equality.
  1143   2) if ORIGINAL is in a section that may be discarded by linker or
if
  1144  it is an external functions where we can not create an alias
  1145  (ORIGINAL_DISCARDABLE)
  1146   3) if target do not support symbol aliases.
  1147   4) original and alias lie in different comdat groups.
  1148  
  1149   If we can not produce alias, we will turn ALIAS into WRAPPER of
ORIGINAL
  1150   and/or redirect all callers from ALIAS to ORIGINAL.  */
  1151if ((original_address_matters && alias_address_matters)
  1152|| (original_discardable
  1153&& (!DECL_COMDAT_GROUP (alias->decl)
  1154|| (DECL_COMDAT_GROUP (alias->decl)
  1155!= DECL_COMDAT_GROUP (original->decl
  1156|| original_discarded
  1157|| !sem_item::target_supports_symbol_aliases_p ()
  1158|| DECL_COMDAT_GROUP (alias->decl) != DECL_COMDAT_GROUP
(original->decl))
  1159  {

Thanks.

[Bug target/85832] [AVX512] possible shorter code when comparing with vector of zeros

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 44227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44227&action=edit
gcc9-pr85832.patch

Untested fix.

[Bug target/86036] [9 Regression] wrong code with -mavx512bw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 44228
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44228&action=edit
gcc9-pr85832.patch

Untested fix.

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

[rguenther at suse dot de]

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

--- Comment #17 from rguenther at suse dot de  ---
On Mon, 4 Jun 2018, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
> 
> Alexander Monakov  changed:
> 
>What|Removed |Added
> 
>  CC||amonakov at gcc dot gnu.org
> 
> --- Comment #16 from Alexander Monakov  ---
> What do you think about the suggestion made in the most recent duplicate,
> namely expanding GIMPLE pointer-to-integer casts to non-transparent RTL
> assignments, i.e. going from
> 
>   val = (intptr_t) ptr;
> 
> to
> 
>   asm ("" : "=g" (rval) : "0" (rptr));
> 
> Wouldn't this plug the hole in one shot instead of chasing down missing
> REG_POINTERs in multiple RTL passes?

I suspect such assignments are simply too common and doing this would
be worse than not assuming pointer arithmetic cannot cross different
objects at the RTL level.  How do you for example treat an aggregate
memcpy of a structure containing pointers RTL expanded to say
word-wise (integer-mode!) copies and then RTL afterwards figuring
out reg-reg dependence chains from that.  You have to realize that
you'd have to introduce those "barriers" during RTL optimization
itself...  in which case you're back at sth like REG_POINTER.

I think it would be nice to isolate this assumption on RTL and
put it behind a user-crontrollable flag.  That would allow
benchmarking this.

[Bug tree-optimization/85478] ICE with single element vector

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #13 from Andreas Krebbel  ---
Fixed.

[Bug libstdc++/78870] Support std::filesystem on Windows

[development at jordi dot vilar.cat]

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

Jordi Vilar  changed:

   What|Removed |Added

 CC||development at jordi dot 
vilar.cat

--- Comment #17 from Jordi Vilar  ---
I think the patch is not including the required changes in  in order
to properly handle path arguments. Specifically, both constructors and methods
open() need an additional overload taking const wchar_t*, as required per
specs:

30.9.1 Header  synopsis
[...]
3 In this subclause, member functions taking arguments of const
filesystem::path::value_type* are only be provided on systems where
filesystem::path::value_type (30.10.7) is not char. [ Note: These
functions enable class path support for systems with a wide native path
character type, such as wchar_t.
—end note ]

This involves methods:
basic_filebuf::open(const filesystem::path::value_type* s, ios_base::openmode
mode);
explicit basic_ifstream::basic_ifstream(const filesystem::path::value_type* s,
ios_base::openmode mode = ios_base::in);
void basic_ifstream::open(const filesystem::path::value_type* s,
ios_base::openmode mode = ios_base::in);
explicit basic_ofstream::basic_ofstream(const filesystem::path::value_type* s,
ios_base::openmode mode = ios_base::out);
void basic_ofstream::open(const filesystem::path::value_type* s,
ios_base::openmode mode = ios_base::out);
explicit basic_fstream::basic_fstream(const std::filesystem::path::value_type*
s, ios_base::openmode mode = ios_base::in|ios_base::out);
void basic_fstream::open(const std::filesystem::path::value_type* s,
ios_base::openmode mode = ios_base::in|ios_base::out);

I hope this helps

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
That was already done two weeks ago by r260479

[Bug target/86027] string literals get corrupted with -O3 and gas on solaris i386

[subscribe at teskor dot de]

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

--- Comment #3 from Michael Teske  ---
Another addition, I now tried the gcc-7 snapshot 20180531 and it is fixed here
as well. I guess I'll used this one or wait for 7.3.1.

[Bug libstdc++/78870] Support std::filesystem on Windows

[development at jordi dot vilar.cat]

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

--- Comment #19 from Jordi Vilar  ---
(In reply to Jonathan Wakely from comment #18)
> That was already done two weeks ago by r260479

Thank you! And a last question: Do you plan to merge both patches into the gcc
8 branch?

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
Probably not.

[Bug other/86039] New: Compiler placed in deep/long folder cannot open/run needed files on Windows

[samuel.hultgren at st dot com]

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

Bug ID: 86039
   Summary: Compiler placed in deep/long folder cannot open/run
needed files on Windows
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: samuel.hultgren at st dot com
  Target Milestone: ---

Created attachment 44229
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44229&action=edit
output of compilation with compiler in directories with different length

If the compiler file structure is placed in a folder with a name that is 163
characters or longer, the GCC will fail to include certain files and/or run
sub-programs (cc1.exe etc).

Tested on Windows 7, and Windows 10, with GCC based on 6.3.1.

How to reproduce:
Create a simple file c:\test.c:
#include 
int main()
{
  return 0;
}

Place a Windows native GCC toolchain in a folder called c:\1 which includes the
bin, lib, share and target folders directly in it.

Use cygwin or other environment to run help script to try with different folder
name lengths:
cd /cygdrive/c
str=""
for i in `seq 1 256`; 
do 
echo "Testing length $i";
str="1$str"; 
mv 1* $str; 
1*/bin/arm-none-eabi-gcc test.c -o test.o --specs=nano.specs
-specs=nosys.specs;
done

Adjust above script as necessary for your environment, but you should get
similar results to the attached output.

In the attached output we can see that when the folder name is 163 characters
or longer, we see the first type of error, GCC can no longer find all the
header files in the compiler structure.
At folder length 180, GCC can no longer find stdio.h.
At folder length 214, GCC no longer can CreateProcess cc1.exe.

After that length specs files can not be found.

[Bug c++/85765] [8/9 Regression] Missing SFINAE in default template argument

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Mon Jun  4 13:22:52 2018
New Revision: 261146

URL: https://gcc.gnu.org/viewcvs?rev=261146&root=gcc&view=rev
Log:
PR c++/85765 - SFINAE and non-type default template arg.

* pt.c (type_unification_real): Do full semantic processing if
substituting a partial args list replaces all template parms.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug target/85832] [AVX512] possible shorter code when comparing with vector of zeros

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun  4 13:49:55 2018
New Revision: 261148

URL: https://gcc.gnu.org/viewcvs?rev=261148&root=gcc&view=rev
Log:
PR target/85832
PR target/86036
* config/i386/sse.md (_eq3_1):
Use vptestnm rather than vptestm in (=Yc,v,C) variant.

* gcc.target/i386/avx512f-pr85832.c: Expect vptestnm rather than
vptestm.
* gcc.target/i386/avx512vl-pr85832.c: Likewise.
* gcc.target/i386/avx512vlbw-pr85832.c: Likewise.
* gcc.target/i386/avx512bw-pr85832.c: Likewise.
* gcc.target/i386/avx512bw-pr86036.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr86036.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr85832.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85832.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr85832.c
trunk/gcc/testsuite/gcc.target/i386/avx512vlbw-pr85832.c

[Bug target/86036] [9 Regression] wrong code with -mavx512bw

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun  4 13:49:55 2018
New Revision: 261148

URL: https://gcc.gnu.org/viewcvs?rev=261148&root=gcc&view=rev
Log:
PR target/85832
PR target/86036
* config/i386/sse.md (_eq3_1):
Use vptestnm rather than vptestm in (=Yc,v,C) variant.

* gcc.target/i386/avx512f-pr85832.c: Expect vptestnm rather than
vptestm.
* gcc.target/i386/avx512vl-pr85832.c: Likewise.
* gcc.target/i386/avx512vlbw-pr85832.c: Likewise.
* gcc.target/i386/avx512bw-pr85832.c: Likewise.
* gcc.target/i386/avx512bw-pr86036.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr86036.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr85832.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr85832.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr85832.c
trunk/gcc/testsuite/gcc.target/i386/avx512vlbw-pr85832.c

[Bug target/86036] [9 Regression] wrong code with -mavx512bw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/85832] [AVX512] possible shorter code when comparing with vector of zeros

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/85994] Comparison failure in 64-bit libgcc *_{sav,res}ms64*.o on Solaris/x86

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> --- Comment #1 from Richard Biener  ---
>> (In reply to Rainer Orth from comment #0)
>>> I see several possible fixes:
>>> 
>>> * Just compile those files with -g0: there's probably no point in gas adding
>>>   debug info anyway.
>>> 
>>> * Restrict the cpp -P workaround to non-gas.
>>> 
>>> * Autoconf assembler #  support and only pass -P to cpp if really
>>> needed.
>>> 
>>> Suggestions?
>>
>> The last two work for me.
>
> Unless there are other comments, I'll go for the third option.

I tried that, to no avail:

* The original Solaris 10/x86 as (version s10_73) cannot even assemble

  mov %r15,-0x70(%rax)

  It seems it doesn't recognize any amd64 register names.

* The first as to support line markers (from patch 119961-03) breaks in
  the 64-bit libgcc:

Assembler: unwind-c.c
"/var/tmp//ccFLB9of.s", line 127 : Illegal subtraction - symbols from
different sections: ".L23", ".L25"
make[5]: *** [/vol/gcc/src/hg/trunk/local/libgcc/shared-object.mk:14:
unwind-c.o] Error 1

  Unlike the current Solaris 10/x86 as, HAVE_AS_IX86_DIFF_SECT_DELTA
  isn't defined in gcc/auto-host.h.

Given that neither assembler is usable to bootstrap current gcc, with or
without passing -P to cpp and nobody cared, I've chosen just to always
omit -P to fix the comparison failure.

Will install patch shortly.

[Bug libstdc++/85116] std::min_element does not optimize well with inlined predicate

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So what is missing is for us to see that for the following __first_21 is
__first_20 + 8B and so we can replace either with the other.  IVOPTs figures
this out but nothing before.


# __first_20 = PHI <&testArray._M_elems(2), __first_21(7)>
# __first_21 = PHI <&MEM[(void *)&testArray + 8B](2), __first_7(7)>
...
_8 = MEM[(const double *)__first_20 + 8B];

 [local count: 955630224]:
# __result_15 = PHI <__first_21(5), __result_22(8)>
__first_7 = __first_21 + 8;
if (__first_7 != &MEM[(void *)&testArray + 8000B])
  goto ; [89.00%]
else
  goto ; [11.00%]

 [local count: 850510900]:

[Bug c++/61806] [C++11] Expression sfinae w/o access gives hard error in partial template specializations

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/86015] Better handling of iterator distances

[joshua.r.marshall.1991 at gmail dot com]

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

--- Comment #7 from Josh Marshall  ---
I got the licensing cleared up over the weekend, and so I can actually
reference the code in question for this.

https://github.com/anadon/Sort-Comparisons-and-Performance-metrics

The only way to track use of operations on iterator distances effectively would
be for a change like this to go through.  If deemed appropriate, I might ask
about this change to the C++ standard since it won't break any existing code
and adds flexibility.

[Bug c++/61806] [C++11] Expression sfinae w/o access gives hard error in partial template specializations

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Mon Jun  4 15:16:00 2018
New Revision: 261151

URL: https://gcc.gnu.org/viewcvs?rev=261151&root=gcc&view=rev
Log:
PR c++/61806 - missed SFINAE with partial specialization.

* cp-tree.h (deferring_access_check_sentinel): Add deferring_kind
parameter to constructor.
* pt.c (instantiate_class_template_1): Enable access checking
before call to most_specialized_partial_spec.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae63.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug c/85623] strncmp() warns about attribute 'nonstring' incorrectly in -Wstringop-overflow

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Mon Jun  4 15:35:49 2018
New Revision: 261152

URL: https://gcc.gnu.org/viewcvs?rev=261152&root=gcc&view=rev
Log:
PR c/85623 - strncmp() warns about attribute 'nonstring' incorrectly
in -Wstringop-overflow

gcc/ChangeLog:

PR c/85623
* calls.c (maybe_warn_nonstring_arg): Use string length to set
or ajust the presumed bound on an operation to avoid unnecessary
warnings.

gcc/testsuite/ChangeLog:

PR c/85623
* c-c++-common/attr-nonstring-3.c: Adjust.
* c-c++-common/attr-nonstring-4.c: Adjust.
* c-c++-common/attr-nonstring-6.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/c-c++-common/attr-nonstring-6.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/calls.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/c-c++-common/attr-nonstring-3.c
branches/gcc-8-branch/gcc/testsuite/c-c++-common/attr-nonstring-4.c

[Bug c/85623] strncmp() warns about attribute 'nonstring' incorrectly in -Wstringop-overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Patch backported into 8-branch in r261152.

[Bug target/86040] New: [avr]: RAMPZ is not always cleared after loading __flashN data

[lmorrison at nautel dot com]

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

Bug ID: 86040
   Summary: [avr]: RAMPZ is not always cleared after loading
__flashN data
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lmorrison at nautel dot com
  Target Milestone: ---

Created attachment 44230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44230&action=edit
Test case demonstrating the failure to restore/clear RAMPZ

This is possibly related to bug 52461, but it appears that either not all cases
were caught, or else a regression might have re-introduced the problem.

When data is fetched from program memory through the use of the __flashN named
address spaces, the RAMPZ register is set-up with the correct high-order
address byte prior to the data fetch. Most of the time, after the fetch is
complete, RAMPZ is cleared back to zero. However, it appears that at least some
of the time, RAMPZ is not cleared after use.

It's important that RAMPZ must be cleared after use, because some supported AVR
processors (ie. XMEGA with EBI) also implicitly make use of the RAMPZ register
whenever data-space memory is accessed through the Z pointer.

I am attaching a minimal example, targeting the ATxmega128A1U, which
demonstrates both one case in which the correct behavior occurs, and another in
which the wrong behavior occurs.

Specifically, when a single-byte value is fetched (myArray[x][y].value1) RAMPZ
is not cleared. When a multi-byte value is fetched (myArray[x][y].value2) RAMPZ
is correctly cleared.

This test case has been compiled against avr-gcc 5.4.0, 8.0.1, and 8.1.0, with
optimization set to O0, O1, and Os. All cases exhibit the problem.

[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data

[lmorrison at nautel dot com]

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

--- Comment #1 from Luke Morrison  ---
Created attachment 44231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44231&action=edit
Compiled output from avr-gcc 8.1.0 of the test case.

[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Jun  4 15:54:48 2018
New Revision: 261154

URL: https://gcc.gnu.org/viewcvs?rev=261154&root=gcc&view=rev
Log:
2018-06-04  Steven G. Kargl  

PR fortran/85981
* resolve.c (resolve_allocate_deallocate): Check errmsg is default
character kind.

2018-06-04  Steven G. Kargl  

PR fortran/85981
* gfortran.dg/allocate_alloc_opt_14.f90: New test.
* gfortran.dg/allocate_alloc_opt_1.f90: Update error string.
* gfortran.dg/allocate_stat_2.f90: Ditto.
* gfortran.dg/deallocate_alloc_opt_1.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_14.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_1.f90
trunk/gcc/testsuite/gfortran.dg/allocate_stat_2.f90
trunk/gcc/testsuite/gfortran.dg/deallocate_alloc_opt_1.f90

[Bug libstdc++/85930] [8/9 Regression] Misaligned reference created in shared_ptr_base.h with -fno-rtti

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon Jun  4 16:07:35 2018
New Revision: 261155

URL: https://gcc.gnu.org/viewcvs?rev=261155&root=gcc&view=rev
Log:
PR libstdc++/85930 fix misaligned reference

PR libstdc++/85930
* include/bits/shared_ptr_base.h (_Sp_make_shared_tag::_S_ti): Align
the static variable correctly.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr_base.h

[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Jun  4 16:41:31 2018
New Revision: 261160

URL: https://gcc.gnu.org/viewcvs?rev=261160&root=gcc&view=rev
Log:
2018-06-04  Steven G. Kargl  

PR fortran/85981
* resolve.c (resolve_allocate_deallocate): Check errmsg is default
character kind.

2018-06-04  Steven G. Kargl  

PR fortran/85981
* gfortran.dg/allocate_alloc_opt_14.f90: New test.
* gfortran.dg/allocate_alloc_opt_1.f90: Update error string.
* gfortran.dg/allocate_stat_2.f90: Ditto.
* gfortran.dg/deallocate_alloc_opt_1.f90: Ditto.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/allocate_alloc_opt_14.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/allocate_alloc_opt_1.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/allocate_stat_2.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/deallocate_alloc_opt_1.f90

[Bug libstdc++/78870] Support std::filesystem on Windows

[lh_mouse at 126 dot com]

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

--- Comment #21 from Liu Hao  ---
On current branch master [1] and gcc-8-branch the libstdc++fs DLL is not
created for x86_64-w64-mingw32.

Please re-open.

[1]  remotes/origin/master 84b3cf31c30  PR
target/85832 PR target/86036 * config/i386/sse.md
(_eq3

[Bug libstdc++/78870] Support std::filesystem on Windows

[lh_mouse at 126 dot com]

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

--- Comment #22 from Liu Hao  ---
```
lh_mouse@lhmouse-pc /e/GitHub/MINGW-packages/mingw-w64-gcc-git $ gcc --version
gcc.exe (master HEAD with MCF thread model, built by LH_Mouse.) 9.0.0 20180604
(experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



This is the list of DLLs installed with `make install`:

```
libatomic-1.dll
libgcc_s_seh-1.dll
libgomp-1.dll
libquadmath-0.dll
libssp-0.dll
libstdc++-6.dll
```

[Bug c++/86041] New: g++.dg/cpp1z/feat-cxx1z.C fails since 261090

[clyon at gcc dot gnu.org]

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

Bug ID: 86041
   Summary: g++.dg/cpp1z/feat-cxx1z.C fails since 261090
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi Jason,

Since your commit r261090 (Bump __cpp_deduction_guides to 201703), I've noticed
that:
FAIL: g++.dg/cpp1z/feat-cxx1z.C
at least on arm
/gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C:362:4: error: #error
"__cpp_deduction_guides != 201611"
compiler exited with status 1

Is it just a matter of updating the testcase?

[Bug tree-optimization/86042] New: [8 Regression] missing strlen optimization after second strcpy

[msebor at gcc dot gnu.org]

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

Bug ID: 86042
   Summary: [8 Regression] missing strlen optimization after
second strcpy
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC 7 and prior eliminate both strlen() calls in the program below.  GCC 8 only
eliminates the first call, emitting worse code than prior versions.

$ cat c.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout c.c
char a[3];

int main ()
{
  int n[2];

  __builtin_strcpy (a, "12");
  n[0] = __builtin_strlen (a);

  __builtin_strcpy (a, "12");
  n[1] = __builtin_strlen (a);

  __builtin_printf ("%i %i\n", n[0], n[1]);
}

;; Function main (main, funcdef_no=0, decl_uid=1956, cgraph_uid=0,
symbol_order=1) (executed once)

main ()
{
  long unsigned int _3;
  int _4;

   [local count: 1073741825]:
  MEM[(char * {ref-all})&a] = MEM[(char * {ref-all})"12"];
  _3 = __builtin_strlen (&a);
  _4 = (int) _3;
  __builtin_printf ("%i %i\n", 2, _4);
  return 0;
}

[Bug tree-optimization/86042] [8 Regression] missing strlen optimization after second strcpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83501
 Blocks||83819

--- Comment #1 from Martin Sebor  ---
Bisection points to r255197 (see also bug 83501 for another regression related
to this change):

2017-11-28  Richard Biener  

PR middle-end/83141
* gimple-fold.c (gimple_fold_builtin_memory_op): For aggregate
copies generated from memcpy use a character array as reference
type.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug c++/86041] g++.dg/cpp1z/feat-cxx1z.C fails since 261090

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #1 from Jason Merrill  ---
I updated the testcase in r261100.

[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Jun  4 17:09:01 2018
New Revision: 261162

URL: https://gcc.gnu.org/viewcvs?rev=261162&root=gcc&view=rev
Log:
2018-06-04  Steven G. Kargl  

PR fortran/85981
* resolve.c (resolve_allocate_deallocate): Check errmsg is default
character kind.

2018-06-04  Steven G. Kargl  

PR fortran/85981
* gfortran.dg/allocate_alloc_opt_14.f90: New test.
* gfortran.dg/allocate_alloc_opt_1.f90: Update error string.
* gfortran.dg/allocate_stat_2.f90: Ditto.
* gfortran.dg/deallocate_alloc_opt_1.f90: Ditto.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/allocate_alloc_opt_14.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/allocate_alloc_opt_1.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/allocate_stat_2.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/deallocate_alloc_opt_1.f90

[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Fixed on 7-branch, 8-branch, and trunk.  Closing.
Thanks for bug report.

[Bug tree-optimization/86029] gcc -O3 make very slow product

[tavianator at gmail dot com]

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

--- Comment #5 from Tavian Barnes  ---
(In reply to Zsolt from comment #3)
> What is the difference between gcc's and clang's __mulsc3?

The important difference is that Clang (and GCC trunk) expand the fastpath
inline, and fall back on __mulsc3 for the more complicated cases.  So instead
of

complex float a = b * c;

expanding to

complex float a = __mulsc3(crealf(b), cimagf(b), crealf(c), cimagf(c));

it's more like

complex float a = (crealf(b)*crealf(c) - cimagf(b)*cimagf(c) +
I*(crealf(b)*cimagf(c) + cimagf(b)*crealf(c));
if (isunordered(crealf(a), cimagf(a))) {
a = __mulsc3(crealf(b), cimagf(b), crealf(c), cimagf(c));
}

The fastpath and unlikely branch tends to be faster than the function call.

[Bug rtl-optimization/80481] Unoptimal additional copy instructions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2018-06-04
 CC||jason at gcc dot gnu.org
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #9 from Jason Merrill  ---
The testcase has been failing for a while on x86_64 linux as well:

https://gcc.gnu.org/ml/gcc-testresults/2018-06/msg00431.html

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

--- Comment #23 from Jonathan Wakely  ---
Nothing has been committed for gcc-8-branch so of course it isn't created.

For trunk, did you read comment 14?

[Bug tree-optimization/86043] New: strlen after memcpy partially overwriting a string not optimized

[msebor at gcc dot gnu.org]

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

Bug ID: 86043
   Summary: strlen after memcpy partially overwriting a string not
optimized
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The tree-ssa-strlen optimization has code to detect non-nul character stores
into the initial elements of a string of a known length and avoid invalidating
its length information, but it's missing the same optimization for
corresponding stores by memcpy (or similarly, strcpy).

$ cat d.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout d.c
char a[5];

int f (void)
{
  __builtin_strcpy (a, "123");

  a[0] = '1';
  return __builtin_strlen (a);   // folded, good
}

int g (void)
{
  __builtin_strcpy (a, "123");

  __builtin_memcpy (a + 1, "2", 1);
  return __builtin_strlen (a);   // not folded
}

;; Function f (f, funcdef_no=0, decl_uid=1957, cgraph_uid=0, symbol_order=1)

f ()
{
   [local count: 1073741825]:
  __builtin_memcpy (&a, "123", 4);
  return 3;

}



;; Function g (g, funcdef_no=1, decl_uid=1960, cgraph_uid=1, symbol_order=2)

g ()
{
  long unsigned int _1;
  int _5;

   [local count: 1073741825]:
  __builtin_memcpy (&a, "123", 4);
  __builtin_memcpy (&MEM[(void *)&a + 1B], "2", 1);
  _1 = __builtin_strlen (&a);
  _5 = (int) _1;
  return _5;

}

[Bug tree-optimization/86043] strlen after memcpy partially overwriting a string not optimized

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86042
 Blocks||83819

--- Comment #1 from Martin Sebor  ---
See also bug 86042.  It's possible to handle this enhancement by fixing that
bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug c++/86044] New: noexcept(false) of constexpr member function ignored

[johelegp at gmail dot com]

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

Bug ID: 86044
   Summary: noexcept(false) of constexpr member function ignored
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
  Target Milestone: ---

In the following snippet, the assertion fails if `constexpr` isn't commented
out. See https://godbolt.org/g/FCEHCb.

```C++
struct A {
};

template 
struct H {
constexpr
int operator()(const K&) const noexcept(false)
{
return 0;
}
};

static_assert(!noexcept(H()(A())), "");
```

[Bug other/86039] Compiler placed in deep/long folder cannot open/run needed files on Windows

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #1 from Jim Wilson  ---
Windows has a 260 character default maximum path length.  See for instance
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath

This looks like an OS problem not a gcc problem.

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #17 from G. Steinmetz  ---
(In reply to kargl from comment 16)
> I propose that first 2 testcases be committed to the testsuite ...
Good, sounds reasonable.


I did a new search for test cases without nested array constructors 
and found a few other valid examples :

$ cat za3.f90
program p
   real, parameter :: z(3) = 2.0 * [real :: 1, (2), 3]
   print *, z
end

$ cat za4.f90
program p
   integer, parameter :: z(3) = 2 * [integer :: 1, (2), 3]
   print *, z
end

$ cat za5.f90
program p
   real, parameter :: z(2) = [real :: 1, (2)] + 10.0
   print *, z
end


$ gfortran-9-20180603 -c za3.f90
f951: internal compiler error: Segmentation fault
0xba15af crash_signal
../../gcc/toplev.c:325
0x675028 reduce_binary_ca
../../gcc/fortran/arith.c:1348
0x674fc2 reduce_binary_ca
../../gcc/fortran/arith.c:1335
0x675204 reduce_binary
../../gcc/fortran/arith.c:1418
0x675b3b eval_intrinsic
../../gcc/fortran/arith.c:1596
0x675d9e eval_intrinsic_f3
../../gcc/fortran/arith.c:1733
0x6dd7b4 match_add_operand
../../gcc/fortran/matchexp.c:392
0x6dd99c match_level_2
../../gcc/fortran/matchexp.c:480
0x6ddaf2 match_level_3
../../gcc/fortran/matchexp.c:551
0x6ddc04 match_level_4
../../gcc/fortran/matchexp.c:599
0x6ddc04 match_and_operand
../../gcc/fortran/matchexp.c:693
0x6dddc2 match_or_operand
../../gcc/fortran/matchexp.c:722
0x6ddeb2 match_equiv_operand
../../gcc/fortran/matchexp.c:765
0x6ddfa2 match_level_5
../../gcc/fortran/matchexp.c:811
0x6dd311 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.c:870
0x6ae3e2 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:2807
0x69bfb9 variable_decl
../../gcc/fortran/decl.c:2681
0x69bfb9 gfc_match_data_decl()
../../gcc/fortran/decl.c:5880
0x6f6fb9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6fa6ae match_word
../../gcc/fortran/parse.c:376

[Bug fortran/86045] New: ICE in reduce_binary_ac, at fortran/arith.c:1308 (and others)

[gs...@t-online.de]

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

Bug ID: 86045
   Summary: ICE in reduce_binary_ac, at fortran/arith.c:1308 (and
others)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This invalid code affects versions down to at least 4.8 :


$ cat z1.f90
program p
   logical :: a(2) = (mod([2,3],0) == 0)
   integer :: b = count(mod([2,3],0) == 0)
   integer :: c = all(mod([2,3],0) == 0)
   integer :: d = any(mod([2,3],0) == 0)
end


$ gfortran-9-20180603 -c z1.f90
f951: internal compiler error: Segmentation fault
0xba15af crash_signal
../../gcc/toplev.c:325
0x675138 reduce_binary_ac
../../gcc/fortran/arith.c:1308
0x6750d2 reduce_binary_ac
../../gcc/fortran/arith.c:1295
0x67531c reduce_binary
../../gcc/fortran/arith.c:1421
0x675b3b eval_intrinsic
../../gcc/fortran/arith.c:1596
0x675d9e eval_intrinsic_f3
../../gcc/fortran/arith.c:1733
0x6ac5a5 simplify_intrinsic_op
../../gcc/fortran/expr.c:1158
0x6ac5a5 gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:1984
0x6ab947 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2775
0x6ae431 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:2821
0x69bfb9 variable_decl
../../gcc/fortran/decl.c:2681
0x69bfb9 gfc_match_data_decl()
../../gcc/fortran/decl.c:5880
0x6f6fb9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6fa6ae match_word
../../gcc/fortran/parse.c:376
0x6fa6ae decode_statement
../../gcc/fortran/parse.c:376
0x6fc5d4 next_free
../../gcc/fortran/parse.c:1230
0x6fc5d4 next_statement
../../gcc/fortran/parse.c:1462
0x6fe3ec parse_spec
../../gcc/fortran/parse.c:3670
0x7003b3 parse_progunit
../../gcc/fortran/parse.c:5667
0x701994 gfc_parse_file()
../../gcc/fortran/parse.c:6207

[Bug fortran/86045] ICE in reduce_binary_ac, at fortran/arith.c:1308 (and others)

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

In addition some ugly cases with null(), losely related to pr66193.


$ cat zn1.f90
program p
   real :: z(1) = [real :: null()] + 2.0
end

$ cat zn2.f90
program p
   real :: z(1) = [real :: null()] + [real :: 2]
end

$ cat zn3.f90
program p
   real :: z(1) = 1.0 + [real :: null()]
end

$ cat zn4.f90
program p
   real :: z(1) = [real :: 1] + [real :: null()]
end

$ cat zn5.f90
program p
   real :: z(2) = [real :: null()] + [real :: null()]
end


$ gfortran-9-20180603 -c zn1.f90
f951: internal compiler error: Segmentation fault
0xba15af crash_signal
../../gcc/toplev.c:325
0x675138 reduce_binary_ac
../../gcc/fortran/arith.c:1308
0x6750d2 reduce_binary_ac
../../gcc/fortran/arith.c:1295
0x67531c reduce_binary
../../gcc/fortran/arith.c:1421
0x675b3b eval_intrinsic
../../gcc/fortran/arith.c:1596
0x675d9e eval_intrinsic_f3
../../gcc/fortran/arith.c:1733
0x6ac645 simplify_intrinsic_op
../../gcc/fortran/expr.c:1133
0x6ac645 gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:1984
0x70f44f resolve_operator
../../gcc/fortran/resolve.c:4162
0x70f44f gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6716
0x6ab92f gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2773
0x6ae431 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:2821
0x69bfb9 variable_decl
../../gcc/fortran/decl.c:2681
0x69bfb9 gfc_match_data_decl()
../../gcc/fortran/decl.c:5880
0x6f6fb9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6fa6ae match_word
../../gcc/fortran/parse.c:376
0x6fa6ae decode_statement
../../gcc/fortran/parse.c:376
0x6fc5d4 next_free
../../gcc/fortran/parse.c:1230
0x6fc5d4 next_statement
../../gcc/fortran/parse.c:1462
0x6fe3ec parse_spec
../../gcc/fortran/parse.c:3670

[Bug c/86046] New: [9 Regression] ICE in execute_todo, at passes.c:2043

[gs...@t-online.de]

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

Bug ID: 86046
   Summary: [9 Regression] ICE in execute_todo, at passes.c:2043
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Since end of april, gcc configured with --enable-checking=release
and test case compiled with option -fchecking :


$ cat z1.c
typedef int V __attribute__ ((vector_size(4)));
void fn1 ()
{
  (V){(1,0)}[1] = 0;
}


$ gcc-8 -c z1.c -fchecking -O2
$
$ gcc-9-20180603 -c z1.c -fchecking -O0
$ gcc-9-20180603 -c z1.c -fchecking -O2
during GIMPLE pass: forwprop
z1.c: In function 'fn1':
z1.c:5:1: internal compiler error: in execute_todo, at passes.c:2043
 }
 ^
0xa2a4da execute_todo
../../gcc/passes.c:2043

[Bug fortran/86045] ICE in reduce_binary_ac, at fortran/arith.c:1308 (and others)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-04
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug middle-end/85955] ICE in fold_convert_loc, at fold-const.c:2408

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Jun  4 18:03:24 2018
New Revision: 261165

URL: https://gcc.gnu.org/viewcvs?rev=261165&root=gcc&view=rev
Log:
2018-06-04  Richard Biener  

PR tree-optimization/85955
* builtins.c (fold_builtin_sincos): Convert pointers to
destination to appropriate type before dereferencing.

* gcc.dg/pr85955.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr85955.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug c/86047] New: [9 Regression] ICE in for_each_index, at tree-ssa-loop.c:647

[gs...@t-online.de]

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

Bug ID: 86047
   Summary: [9 Regression] ICE in for_each_index, at
tree-ssa-loop.c:647
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Introduced between 20180513 and 20180520 :


$ cat z1.c
extern void f (int, int);
void g (int a, int b)
{
  int i, j;
  for (i = a; i <= b; ++i)
__builtin_memcpy (g, f, 6);
  for (j = a; j <= b; ++j)
f(j, i);
}


$ gcc-9-20180513 -c z1.c -O2
$
$ gcc-9-20180603 -c z1.c -O2
during GIMPLE pass: dse
z1.c: In function 'g':
z1.c:9:1: internal compiler error: in for_each_index, at tree-ssa-loop.c:647
 }
 ^
0xc28623 for_each_index(tree_node**, bool (*)(tree_node*, tree_node**, void*),
void*)
../../gcc/tree-ssa-loop.c:647
0xbe63f1 dse_classify_store
../../gcc/tree-ssa-dse.c:571
0xbe6bf4 dse_dom_walker::dse_optimize_stmt(gimple_stmt_iterator*)
../../gcc/tree-ssa-dse.c:859
0xbe6e9e dse_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-dse.c:924
0x1148e1f dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0xbe52a4 execute
../../gcc/tree-ssa-dse.c:978

[Bug middle-end/85955] ICE in fold_convert_loc, at fold-const.c:2408

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
  Known to fail|9.0 |

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

[Bug libstdc++/86008] std::quoted(std::basic_string_view) is missing

[gcc at mattwhitlock dot name]

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

--- Comment #2 from Matt Whitlock  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Matt Whitlock from comment #0)
> > The following shim allows the code above to compile, although it is
> > sub-optimal because it captures a std::basic_string_view by reference.
> 
> Have you profiled to see if that matters?

No, mostly because I find micro-benchmarks to be unreliable indicators of
real-world performance. Instead, I prefer to compare the generated code.

I've made a simplified comparison that boils down the essence of what's going
on in the two cases.

/* BEGIN CODE */

#include 

struct sv_ref {
const std::string_view &sv;
};

struct sv_val {
std::string_view sv;
};

std::ostream & operator << (std::ostream &os, const sv_ref &svr) {
// os.put('"');
for (auto c : svr.sv) {
if (c == '"' || c == '\\') {
os.put('\\');
}
os.put(c);
}
// os.put('"');
return os;
}

std::ostream & operator << (std::ostream &os, const sv_val &svv) {
// os.put('"');
for (auto c : svv.sv) {
if (c == '"' || c == '\\') {
os.put('\\');
}
os.put(c);
}
// os.put('"');
return os;
}

/* END CODE */

Plugging this code into Compiler Explorer (godbolt.org) reveals the following
relevant difference:

-operator<<(std::basic_ostream >&, sv_ref const&):
+operator<<(std::basic_ostream >&, sv_val const&):
   push r13
   push r12
   mov r12, rdi
   push rbp
   push rbx
   sub rsp, 8
-  mov rax, QWORD PTR [rsi] ; rax := &svr.sv
-  mov rbp, QWORD PTR [rax+8]   ; rbp := (&svr.sv)->begin()
-  mov r13, QWORD PTR [rax] ; r13 := (&svr.sv)->size()
+  mov rbp, QWORD PTR [rsi+8]   ; rbp := svv.sv.begin()
+  mov r13, QWORD PTR [rsi] ; r13 := svv.sv.size()
   add r13, rbp
   cmp rbp, r13

As expected, the pass-by-reference case requires one additional indirect load
from memory versus the pass-by-value case.

However, this is offset by what happens on the calling side.

/* BEGIN CODE */

#include 
#include 

struct sv_ref {
const std::string_view &sv;
};

struct sv_val {
std::string_view sv;
};

std::ostream & operator << (std::ostream &os, const sv_ref &svr);
std::ostream & operator << (std::ostream &os, const sv_val &svv);

const std::string_view sv;

void pass_by_ref() {
std::cout << sv_ref{ sv };
}

void pass_by_val() {
std::cout << sv_val{ sv };
}

/* END CODE */

Here we see tho following relevant difference:

-pass_by_ref():
+pass_by_val():
   sub rsp, 24
   mov edi, OFFSET FLAT:std::cout
-  mov QWORD PTR [rsp+8], OFFSET FLAT:sv
-  lea rsi, [rsp+8]
-  call operator<<(std::basic_ostream >&, sv_ref
const&)
+  mov rsi, rsp
+  mov QWORD PTR [rsp], 0
+  mov QWORD PTR [rsp+8], 0
+  call operator<<(std::basic_ostream >&, sv_val
const&)
   add rsp, 24
   ret

The pass-by-value case requires one additional indirect store to memory versus
the pass-by-reference case.

So it's a wash. And, in fact, when I combine the two above snippets of source
code into one compilation unit so that the optimizer can work its magic, the
only differences in the generated code between the two cases are the labels.
That's what I would expect too.

So you're right: although the pass-by-reference case is conceptually
sub-optimal, given the typical advice that std::string_view objects should be
passed by value, in practice it is identical.

[Bug libstdc++/85951] make_signed and make_unsigned are incorrect for wchar_t, char16_t, and char32_t

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 8.2

[Bug c++/85731] [8/9 Regression] Inner class method declaration changes meaning of outer template class template method

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85976] [8/9 Regression] ICE in cp_tree_equal when building Blitz. May be nested templates.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #7 from Marek Polacek  ---
Got it:

template  class A;
template  class B;
template  struct C;
template  class D {
  using B::rank_;
  void operator()(typename C>::i);
};

template  class F {
  using B::rank_;
  void operator()(typename C>::i);
};

[Bug target/86048] New: [8/9 Regression] .seh_savexmm offset is negative error when compiling libpng

[daniel.f.starke at freenet dot de]

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

Bug ID: 86048
   Summary: [8/9 Regression] .seh_savexmm offset is negative error
when compiling libpng
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Created attachment 44232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44232&action=edit
pre-processed source file

Using GCC 8.1.0 configured as following:
  Configured with: ../../src/gcc-8.1.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix
--disable-nls --disable-shared --enable-static --enable-fully-dynamic-string
--enable-lto --enable-plugins --enable-libgomp --with-dwarf2
--enable-mingw-wildcard=platform --disable-win32-registry
--enable-version-specific-runtime-libs --prefix=/mingw64-64
--with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32 --enable-targets=all
--enable-checking=release --with-gmp=/usr/new-gcc/lib/gmp-5.0.5
--with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2 --with-mpc=/usr/new-gcc/lib/mpc-0.9
--with-isl=/usr/new-gcc/lib/isl-0.18 --with-cloog=/usr/new-gcc/lib/cloog-0.18.4
--with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check
--enable-cloog-backend=isl

The pre-build compiler binaries for x64 Windows can be downloaded from:
 
https://sourceforge.net/projects/gcc-win64/files/8.1.0/gcc-8.1.0-no-debug.7z/download

When I try to compile libpng 1.6.34 with -O2 I get the following error from the
assembler:
  Error: .seh_savexmm offset is negative

The error does not occur when compiling the same pre-processed file with GCC
7.3.0 using the same command-line options.

Attached you can find the pre-processed file in question as well as an
automatically reduced version of it.
The file was compiled with:
  gcc -save-temps -O2 -fno-ident -fno-strict-aliasing -fomit-frame-pointer -s
-static -c -o pngvalid.o pngvalid.i

The error was also posted to the libpng library by someone else:
  https://sourceforge.net/p/libpng/bugs/280/
And to the libpng library as part of the MinGW packages:
  https://github.com/Alexpux/MINGW-packages/issues/3893

I believe the error resists in GCC. I only changed the GCC compiler itself and
the MinGW runtime libraries (this was needed to compile GCC 8.1.0 on Windows).

[Bug testsuite/85888] [9 Regression] New test case c-c++-common/attr-nonstring-6.c from r260541 fails with excess errors

[seurer at gcc dot gnu.org]

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

--- Comment #7 from seurer at gcc dot gnu.org ---
This same error just popped up on gcc 8 (r261152 for gcc 8 backported r260541
for trunk) so don't forget about this fix as well.

[Bug c++/86049] New: Array bindings are not const when initializer is

[blitzrakete at gmail dot com]

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

Bug ID: 86049
   Summary: Array bindings are not const when initializer is
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blitzrakete at gmail dot com
  Target Milestone: ---

Compiles with clang, doesn't under gcc 8.1.0:

template  struct is_same {
  static constexpr bool value = false;
};
template  struct is_same {
  static constexpr bool value = true;
};

int main() {
  const int Array[] = {1};
  auto[One] = Array;
  static_assert(is_same::value); // fail
}

[dcl.struct.bind]p1 is pretty clear here that the type of the underlying
structured binding element is const int[1], and so per [dcl.struct.bind]p2 the
element type is const int and thus so is also One's type.

[Bug fortran/70244] [OOP] ICE in spec_dimen_size(): Bad dimension

[simon at whiteowl dot co.uk]

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

simon at whiteowl dot co.uk changed:

   What|Removed |Added

 CC||simon at whiteowl dot co.uk

--- Comment #3 from simon at whiteowl dot co.uk ---
Created attachment 44233
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44233&action=edit
Small testcase that triggers this bug

[Bug fortran/70244] [OOP] ICE in spec_dimen_size(): Bad dimension

[simon at whiteowl dot co.uk]

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

--- Comment #4 from simon at whiteowl dot co.uk ---
I have the same problem but with a much smaller test case (attached above):

/usr/local/bin/gfortran -c planets.f90 -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gfortran
Target: x86_64-pc-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 8.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/f951 planets.f90 -quiet
-dumpbase planets.f90 -mtune=generic -march=x86-64 -auxbase planets -version
-fintrinsic-modules-path /usr/local/lib/gcc/x86_64-pc-linux-gnu/8.1.0/finclude
-o /tmp/ccy3mnd3.s
GNU Fortran (GCC) version 8.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 8.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 3.1.5,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: spec_dimen_size(): Bad dimension
0x5f22af gfc_internal_error(char const*, ...)
../.././gcc/fortran/error.c:1358
0x5c583b spec_dimen_size(gfc_array_spec*, int, __mpz_struct (*) [1])
../.././gcc/fortran/array.c:2174
0x656736 expression_shape
../.././gcc/fortran/resolve.c:5088
0x656736 expression_rank(gfc_expr*)
../.././gcc/fortran/resolve.c:5168
0x66323c resolve_variable
../.././gcc/fortran/resolve.c:5575
0x66323c gfc_resolve_expr(gfc_expr*)
../.././gcc/fortran/resolve.c:6721
0x659da2 gfc_resolve_code(gfc_code*, gfc_namespace*)
../.././gcc/fortran/resolve.c:11094
0x65cedf resolve_codes
../.././gcc/fortran/resolve.c:16535
0x65cfae gfc_resolve(gfc_namespace*)
../.././gcc/fortran/resolve.c:16570
0x64ae00 resolve_all_program_units
../.././gcc/fortran/parse.c:6060
0x64ae00 gfc_parse_file()
../.././gcc/fortran/parse.c:6310
0x69130f gfc_be_parse_file
../.././gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/86050] New: Inline break tail-call optimization

[asorenji at gmail dot com]

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

Bug ID: 86050
   Summary: Inline break tail-call optimization
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asorenji at gmail dot com
  Target Milestone: ---

I have deep tail-recursion and try check how many bytes it consumed. Algorithm
for this very simple - pointer to variable in main function minus pointer to
variable in current recursive call. If function for this check have noinline
attribute, tail-call optimization doing well and my recursion consume very
little amount of memory. But if I remove noinline attribute, optimization don't
work and I get stack overflow.

OS - Debian Stretch.
g++ --version - g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Command line - g++ -O2 main.cpp -o main
Code:

#include 

using namespace std;

struct Parent
{
virtual void tailCall(const char*,long )const{}
};

struct Child:Parent
{
//remove noinline and you get stack overflow
static __attribute__((noinline)) void stackConsume(const char*stack){
char value;
std::cout<<"Consumed "tailCall(&stack,0);
return 0;
}

[Bug testsuite/63177] Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|carll at gcc dot gnu.org   |bergner at gcc dot 
gnu.org

--- Comment #8 from Peter Bergner  ---
I'm testing a patch that fixes the issue Carl mentions in Comment 6 and Comment
7.

[Bug target/86005] [RISCV] Invalid intermixing of __atomic_* libcalls and inline atomic instruction sequences

[wilson at gcc dot gnu.org]

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

--- Comment #8 from Jim Wilson  ---
This looks like a generic GCC problem, not a RISC-V specific problem.

For instance, if I build an armv6t2 compiler I get
bl  __atomic_fetch_add_4

[Bug fortran/86045] ICE in reduce_binary_ac, at fortran/arith.c:1308 (and others)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #1)
> In addition some ugly cases with null(), losely related to pr66193.
> 
> 
> $ cat zn1.f90
> program p
>real :: z(1) = [real :: null()] + 2.0
> end
> 
> $ cat zn2.f90
> program p
>real :: z(1) = [real :: null()] + [real :: 2]
> end
> 
> $ cat zn3.f90
> program p
>real :: z(1) = 1.0 + [real :: null()]
> end
> 
> $ cat zn4.f90
> program p
>real :: z(1) = [real :: 1] + [real :: null()]
> end
> 
> $ cat zn5.f90
> program p
>real :: z(2) = [real :: null()] + [real :: null()]
> end
>

There's a are different issue than the one involving MOD().

[Bug libstdc++/85930] [8/9 Regression] Misaligned reference created in shared_ptr_base.h with -fno-rtti

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon Jun  4 21:38:42 2018
New Revision: 261172

URL: https://gcc.gnu.org/viewcvs?rev=261172&root=gcc&view=rev
Log:
PR libstdc++/85930 fix misplaced alignment-specifier

PR libstdc++/85930
* include/bits/shared_ptr_base.h [!__cpp_rtti]: Include 
unconditionally. Remove redundant declaration.
[!__cpp_rtti] (_Sp_make_shared_tag::_S_ti): Fix location of
alignment-specifier.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr_base.h

[Bug target/86005] [RISCV] Invalid intermixing of __atomic_* libcalls and inline atomic instruction sequences

[wilson at gcc dot gnu.org]

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

--- Comment #9 from Jim Wilson  ---
Oops, hitting tab doesn't work as expected.  Trying again...

This looks like a generic GCC problem, not a RISC-V specific problem.  Or
perhaps, not a gcc bug at all.

For instance, if I build an armv6t2 compiler I get
bl  __atomic_fetch_add_4
...
mcr p15, 0, r0, c7, c10, 5
ldr r3, [r3]
mcr p15, 0, r0, c7, c10, 5
where the mcr is equivalent to the RISC-V fence.  It looks like MIPS16 and a
number of other targets have the same problem.

GCC has no support for calling __atomic_load_4 for this testcase.  GCC assumes
that loads smaller or equal to the word size are always atomic, and will not
call a library routine for them.  It will emit memory barriers.

If what gcc is doing is wrong, then it is broken for all targets that don't
inline expand every atomic function call, and/or don't have atomic
instructions.

I can fix the rv32ia support by inlining expanding every atomic function call. 
I can't fix the rv32i support without target independent optimizer changes.

[Bug tree-optimization/86050] Inline break tail-call optimization

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|middle-end  |tree-optimization

--- Comment #1 from Marc Glisse  ---
Indeed. The testcase is easier to analyze if you replace iostreams with a plain
printf. The key element seems to be taking the address of a local variable.

[Bug middle-end/54770] sibling call optimization is not applied where it ought to be

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c++ |middle-end
   Severity|normal  |enhancement

[Bug tree-optimization/86050] Inline break tail-call optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Related to PR 54770.

[Bug fortran/86051] New: internal compiler error: in conv_function_val, at fortran/trans-expr.c:3717

[daniel.bershatsky at skolkovotech dot ru]

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

Bug ID: 86051
   Summary: internal compiler error: in conv_function_val, at
fortran/trans-expr.c:3717
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.bershatsky at skolkovotech dot ru
  Target Milestone: ---

Unfortunately, I have not succeeded in building short example that brokes
compiler. So, in order to reproduce the issue one should get file located in
GitHub.
https://github.com/oseledets/tt-fort/blob/658ae2d9148148fb4933de2dda2434aee0b94c39/dispmodule.f90

- GNU Fortran (GCC) 7.3.1 20180406

- x86_64 GNU/Linux

- GNU Fortran distributed with ArchLinux or Ubuntu 18.04 LTS
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.3.1 20180406 (GCC)

- With fortran source located at
https://github.com/oseledets/tt-fort/blob/658ae2d9148148fb4933de2dda2434aee0b94c39/dispmodule.f90
$ gfortran -fdefault-integer-8 -ffree-line-length-none -O3 -fPIC -c
dispmodule.f90
dispmodule.f90:1248:0:

 character(widthmax_dint(x, fmt)) :: sa(size(x))

internal compiler error: in conv_function_val, at fortran/trans-expr.c:3717

- Files generated by adding -save-temps
$ cat dispmodule.s 
.file   "dispmodule.f90"

[Bug libstdc++/85930] [8/9 Regression] Misaligned reference created in shared_ptr_base.h with -fno-rtti

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Jun  4 22:34:39 2018
New Revision: 261174

URL: https://gcc.gnu.org/viewcvs?rev=261174&root=gcc&view=rev
Log:
PR libstdc++/85930 fix misaligned reference

PR libstdc++/85930
* include/bits/shared_ptr_base.h [!__cpp_rtti]: Include 
unconditionally. Remove redundant declaration.
[!__cpp_rtti] (_Sp_make_shared_tag::_S_ti): Align the static variable
correctly.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/shared_ptr_base.h

[Bug libstdc++/85930] [8/9 Regression] Misaligned reference created in shared_ptr_base.h with -fno-rtti

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 8.2

[Bug tree-optimization/81384] built-in form of strnlen missing

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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