[Bug c++/77477] error recovery for explicit qualification

[jmichae3 at yahoo dot com]

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

--- Comment #3 from Jim Michaels  ---
oh, and the error messages do not fit the problem.

[Bug c++/77477] error recovery for explicit qualification

[jmichae3 at yahoo dot com]

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

--- Comment #2 from Jim Michaels  ---
I don't believe this answer.
to my knowledge the syntax is OK for c++11.
I was even told once that  is not needed, which was wrong.
you did not state exactly what was wrong, only that "your code is wrong."
please be explicit like you require your bug reporters to be. thank you.

[Bug c++/77477] error recovery for explicit qualification

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||error-recovery
   Last reconfirmed||2016-09-04
  Component|libstdc++   |c++
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|template functions don't|error recovery for explicit
   |seem to work|qualification
   Severity|normal  |enhancement

--- Comment #1 from Manuel López-Ibáñez  ---
The error is in your code, but g++ could be clearer:

namespace str {
template< class S >
int find1(S searchIn, S searchFor, bool iCase=false, int pos=0);
template< class S >
int find2(S searchIn, S searchFor, bool iCase=false, int pos=0);
template< class S >
int str::find3(S searchIn, S searchFor, bool iCase=false, int pos=0);
template< class S >
int str::find4(S searchIn, S searchFor, bool iCase=false, int pos=0);
}

prog.cc:5:10: error: expected initializer before '<' token
 int find2(S searchIn, S searchFor, bool iCase=false, int pos=0);
  ^
prog.cc:7:68: error: explicit qualification in declaration of 'int
str::find3(S, S, bool, int)'
 int str::find3(S searchIn, S searchFor, bool iCase=false, int pos=0);
^
prog.cc:9:15: error: expected initializer before '<' token
 int str::find4(S searchIn, S searchFor, bool iCase=false, int pos=0);
   ^

[Bug c/77478] New: Incorrect code generated with -O3, m32, -msse2 and -ffast-math

[gcc_bugzilla at appletonaudio dot com]

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

Bug ID: 77478
   Summary: Incorrect code generated with -O3, m32, -msse2 and
-ffast-math
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc_bugzilla at appletonaudio dot com
  Target Milestone: ---

Created attachment 39555
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39555=edit
The output of -save-temps

Apologies if I've selected the wrong component - I suspect this issue is
something wrong in one of the optimization phases, but was not sure what
"component" to select.

The attached program will crash with a segmentation fault when compiled with
the specified arguments. The generated code appears to be generating aligned
vector load instructions on a not properly aligned address. I've tried to
reduce the program and compiler arguments as much as I can into something which
still triggers the behavior.

* the exact version of GCC;
* the system type;
* the options given when GCC was configured/built;

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) 

(This GCC was obtained using apt)

* the complete command line that triggers the bug;

gcc -msse2 -O3 -ffast-math -m32 test.c

* the compiler output (error messages, warnings, etc.); and

The compiler produces no warnings with -Wextra. When I tried to use the
undefined behavior sanitizer (-fsanitize=undefined), the crash vanishes.

* the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below).

This file is attached and is identical to the .c file which generated it (minus
the hash-prefixed lines at the top).

[Bug libstdc++/77477] New: template functions don't seem to work

[jmichae3 at yahoo dot com]

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

Bug ID: 77477
   Summary: template functions don't seem to work
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmichae3 at yahoo dot com
  Target Milestone: ---

#include 
#include 
namespace str {
template< class S >
size_t str::find(S searchIn, S searchFor, bool iCase=false, size_t pos=0);
template< class S >
int str::compare(S first, S second, bool iCase=false, size_t firstPos=0);
template< class S >
S str::ltrim(S s, S whitespaceCharSet);
}
/*
h.cpp:5:17: error: expected initializer before '<' token
 size_t str::find(S searchIn, S searchFor, bool iCase=false, size_t pos=0);
 ^
h.cpp:7:17: error: expected initializer before '<' token
 int str::compare(S first, S second, bool iCase=false, size_t firstPos=0);
 ^
h.cpp:9:13: error: expected initializer before '<' token
 S str::ltrim(S s, S whitespaceCharSet);
 ^
*/

[Bug driver/77475] unnecessary or misleading context in reporting command line problems

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack
 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
This happens when diagnostics use the implicit input_location and that is not
set correctly:

./config/i386/i386.c:4540:  error ("wrong arg %s to option %s",
curr_ran

This should use "error_at (UNKNOWN_LOCATION," or if this option can be set from
an attribute or pragma, it should pass down the correct location from the
caller.

Also, values should be quoted (and 'arg' is not English):

 error_at (loc, "wrong argument %qs to option %s", curr_range_str,

And:

Index: i386.c
===
--- i386.c  (revision 239969)
+++ i386.c  (working copy)
@@ -5480,7 +5480,7 @@
 error ("intel CPU can be used only for %stune=%s %s",
   prefix, suffix, sw);
   else if (i == pta_size)
-error ("bad value (%s) for %sarch=%s %s",
+error_at (loc, "bad value %qs for %sarch=%s %s",
   opts->x_ix86_arch_string, prefix, suffix, sw);

Ideally, it should also use find_closest_string, so we can say:

gcc: error: unrecognized argument 'i685' in option '-march='; did you mean
'i686' ?

See opts-common.c:cmdline_handle_error

Unfortunately, targets tend to play fast and loose with diagnostics...

[Bug target/77476] New: [Regression 7] [AVX-512] illegal kmovb instruction on KNL

[babokin at gmail dot com]

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

Bug ID: 77476
   Summary: [Regression 7] [AVX-512] illegal kmovb instruction on
KNL
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 39554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39554=edit
reproducer

> g++ -std=c++11 -O3 -march=knl -o out init.cpp driver.cpp func.cpp check.cpp 
> hash.cpp -w
> sde -knl -- ./out
TID 0 SDE-ERROR: Executed instruction not valid for specified chip (KNL):
0x4022c6: kmovb ecx, k0
Image: ./out+0x22c6 (in multi-region image, region# 0)
Function: _Z3foov
Instruction bytes are: c5 f9 93 c8

> g++ --version
g++ (Revision=239971/svn-rev:239971/) 7.0.0 20160903 (experimental)
Copyright (C) 2016 Free Software Foundation, Inc.

This is a regression, which appeared between August 22 (rev 239643) and August
23 (rev 239673).

[Bug web/50642] onlinedocs formated text too small to read

[gerald at pfeifer dot com]

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

--- Comment #20 from Gerald Pfeifer  ---
Created attachment 39553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39553=edit
Firefox font configuratoin

(In reply to Jon Grant from comment #18)
> Just looking at this page:
> 
> https://gcc.gnu.org/onlinedocs/gcc/Enumerator-Attributes.html#Enumerator-
> Attributes
> 
> The "deprecated" word appears to be smaller (like 9pt, compared to 11pt
> regular I estimate). I', using a default Firefox install and profile. Latest
> version of Ubuntu. I'll attach a screenshot

Thanks for sharing that.  I confirm the same with Firefox on openSUSE
Tumbleweed, and bet your font config dialog looks similar to mine.

At this point this is not a GCC issue any longer, if Firefox deliberately
uses a smaller font size for fixed width text, I guess.

[Bug target/70341] [5/6/7 Regression] cost model for addresses is incorrect, slsr is using reg + reg + CST for arm

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #8 from Fredrik Hederstierna 
 ---
Could it be something in tree-ssa-forwprop pass?

This pass is executed 4 times in -Os, and starting with GCC-4.9 it seems like
statements that seems to generate instructions that are hard to eliminate later
in compilation could be propagated?


Checking 4.8.5 (good result)

;; Function test (test, funcdef_no=0, decl_uid=4075, cgraph_uid=0)

test (struct table_s * table, int xi)
{
  struct item_s * item;
  int _6;
  int _7;
  int _9;
  int _11;
  int _13;

  :
  item_4 = _2(D)->items[xi_3(D)];
  _6 = item_4->type;
  switch (_6) , case 1: , case 2: , case 3: , case 4:
>

:
  _7 = item_4->name;
  handle_case_1 (_7);
  goto  ();

:
  _9 = item_4->name;
  handle_case_2 (_9);
  goto  ();

:
  _11 = item_4->name;
  handle_case_3 (_11);
  goto  ();

:
  _13 = item_4->name;
  handle_case_4 (_13);

:
  return;

}

---

Same code GCC 4.9.3 (bad result)

;; Function test (test, funcdef_no=0, decl_uid=4090, symbol_order=0)

test (struct table_s * table, int xi)
{
  struct item_s * item;
  int _6;
  int _7;
  int _9;
  int _11;
  int _13;

  :
  _6 = MEM[(struct item_s *)table_2(D)].items[xi_3(D)].type;
  switch (_6) , case 1: , case 2: , case 3: , case 4:
>

:
  _7 = MEM[(struct item_s *)table_2(D)].items[xi_3(D)].name;
  handle_case_1 (_7);
  goto  ();

:
  _9 = MEM[(struct item_s *)table_2(D)].items[xi_3(D)].name;
  handle_case_2 (_9);
  goto  ();

:
  _11 = MEM[(struct item_s *)table_2(D)].items[xi_3(D)].name;
  handle_case_3 (_11);
  goto  ();

:
  _13 = MEM[(struct item_s *)table_2(D)].items[xi_3(D)].name;
  handle_case_4 (_13);

:
  return;

}


When comparing the two versions of "tree-ssa-forwprop.c" it seems like
sometimes there are removed checks for invariant code, eg. in
forward_propagate_addr_expr_1() there are no checks for
is_gimple_min_invariant(), but I'm not familiar with this code is it might just
fine, it was just an observation, since it seems like invariant code are
propagated here, but maybe I'm wrong.

When compiling for speed there is less downside in copying statements, its like
loop unrolling or peeling, but when optimizing for size its always bad if later
passes cannot eliminate these extra copied instructions again I think. Maybe
propagation should be more restrictive when optimizing for size?
I did not see any checks for optimization type in forwardpropagation, but maybe
its intended to only do zero-cost propagations?

Thank & BR/Fredrik

[Bug web/50642] onlinedocs formated text too small to read

[jg at jguk dot org]

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

--- Comment #19 from Jon Grant  ---
Created attachment 39552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39552=edit
Firefox screenshot 4 September 2016

Shows the small text visible still.

[Bug web/50642] onlinedocs formated text too small to read

[jg at jguk dot org]

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

--- Comment #18 from Jon Grant  ---
Just looking at this page:

https://gcc.gnu.org/onlinedocs/gcc/Enumerator-Attributes.html#Enumerator-Attributes

The "deprecated" word appears to be smaller (like 9pt, compared to 11pt regular
I estimate). I', using a default Firefox install and profile. Latest version of
Ubuntu.
I'll attach a screenshot

[Bug c++/77474] sizeof and function template don't work properly together

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||29143

--- Comment #2 from Andrew Pinski  ---
Related to 29143 but not fixed by that.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29143
[Bug 29143] address-of overloaded function does not work in function call

[Bug fortran/77391] gfortran allows CHARACTER(LEN=:),PARAMETER:: STRING='constant' buts does not report it as an extension

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug web/56736] Broken link in http://gcc.gnu.org/gcc-4.8/changes.html

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||gerald at pfeifer dot com
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |gerald at pfeifer dot 
com

--- Comment #3 from Gerald Pfeifer  ---
Apologies, I fixed this a while ago but missed updating this report
(and close it).

Thanks for letting us know!

[Bug libstdc++/77469] std::regex x("[b\\-a]") throws with message "Invalid range in bracket expression."

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||timshen at gcc dot gnu.org
 Resolution|INVALID |DUPLICATE

--- Comment #5 from Tim Shen  ---


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

[Bug libstdc++/77356] regex error for a ECMAScript syntax string

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||alban...@baker-research.com

--- Comment #4 from Tim Shen  ---
*** Bug 77469 has been marked as a duplicate of this bug. ***

[Bug web/50642] onlinedocs formated text too small to read

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

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

--- Comment #17 from Gerald Pfeifer  ---
I believe this should be fixed now, cf.
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00171.html
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00172.html
for the two patches to a script and our stylesheet, respectively.

If anything requires (or desires) further tweaking, we can now
easily do so.

[Bug tree-optimization/61139] missed fma/reassoc optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Andrew Pinski  ---
From the trunk I get (on aarch64):
_Z6mirrorRff:
.LFB0:
.cfi_startproc
ldr s2, [x0]
fmovs1, 2.0e+0
fnmsub  s0, s0, s1, s2
str s0, [x0]
ret

_Z7mirror2Rff:
.LFB1:
.cfi_startproc
ldr s2, [x0]
fmovs1, 2.0e+0
fnmsub  s0, s0, s1, s2
str s0, [x0]
ret

I am not seeing any difference after the patch that fixed bug 63586 so closing
as a dup again.

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

[Bug tree-optimization/63586] x+x+x+x -> 4*x in gimple

[pinskia at gcc dot gnu.org]

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

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

[Bug fortran/77391] gfortran allows CHARACTER(LEN=:),PARAMETER:: STRING='constant' buts does not report it as an extension

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Sep  4 20:00:48 2016
New Revision: 239982

URL: https://gcc.gnu.org/viewcvs?rev=239982=gcc=rev
Log:
2016-09-04  Steven G. Kargl  

PR fortran/77391
* resolve.c (deferred_requirements): New function to check F2008:C402.
(resolve_fl_variable,resolve_fl_parameter): Use it.

2016-09-04  Steven G. Kargl  

PR fortran/77391
* gfortran.dg/pr77391.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77391.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug web/50642] onlinedocs formated text too small to read

[gerald at gcc dot gnu.org]

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

--- Comment #16 from gerald at gcc dot gnu.org  ---
Author: gerald
Date: Sun Sep  4 19:38:05 2016
New Revision: 239981

URL: https://gcc.gnu.org/viewcvs?rev=239981=gcc=rev
Log:
PR documentation/50642 
* update_web_docs_svn (CSS): Introduce.
Have generated files refer to it.

Modified:
trunk/maintainer-scripts/ChangeLog

[Bug driver/77475] unnecessary or misleading context in reporting command line problems

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-04
 Ever confirmed|0   |1

[Bug driver/77475] New: unnecessary or misleading context in reporting command line problems

[drepper.fsp+rhbz at gmail dot com]

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

Bug ID: 77475
   Summary: unnecessary or misleading context in reporting command
line problems
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drepper.fsp+rhbz at gmail dot com
  Target Milestone: ---

When specifying a wrong command line option gcc reports the error as being on
the first line of the file and also prints that line.  This can be confusing.

$ cat u.c
this is garbage
$ local-gcc -c -mmemset-strategy=wrong u.c
u.c:1:0: error: wrong arg wrong to option -mmemset_strategy=
 this is garbage

$ local-gcc -c -march=wrong u.c
u.c:1:0: error: bad value (wrong) for -march= switch
 this is garbage


The message should ideally not include any file information and especially not
line from the input file should be printed, it has nothing to do with the
error.

[Bug fortran/77460] ICE when summing an overflowing array

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug c++/77474] sizeof and function template don't work properly together

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The same problem occurs for the current gcc HEAD 7.0.0 20160901 (experimental).

[Bug fortran/77460] ICE when summing an overflowing array

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Sep  4 18:43:40 2016
New Revision: 239979

URL: https://gcc.gnu.org/viewcvs?rev=239979=gcc=rev
Log:
2016-09-04  Steven G. Kargl  

PR fortran/77460
* simplify.c (simplify_transformation_to_scalar):  On error, result
may be NULL, simply return.

2016-09-04  Steven G. Kargl  

PR fortran/77460
* gfortran.dg/pr77460.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77460.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug web/50642] onlinedocs formated text too small to read

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||gerald at pfeifer dot com
   Assignee|unassigned at gcc dot gnu.org  |gerald at pfeifer dot 
com

--- Comment #15 from Gerald Pfeifer  ---
I'm working on this.  First I will have the online documentation reference
our global CSS style ( https://gcc.gnu.org/gcc.css ), then we can easily
tweak that.

[Bug c++/77474] New: sizeof and function template don't work properly together

[michele.caini at gmail dot com]

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

Bug ID: 77474
   Summary: sizeof and function template don't work properly
together
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michele.caini at gmail dot com
  Target Milestone: ---

The following code compiles:

void f() { }

int main() {
sizeof();
}

The following does not instead:

template
void f() { }

int main() {
sizeof();
}

The error returned is:

error: address of overloaded function with no contextual type information

According to expr.sizeof, both of them should compile.

[Bug preprocessor/71681] header.gcc file lookup is broken for -remap

[andris.pavenis at iki dot fi]

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

--- Comment #2 from Andris Pavenis  ---
Created attachment 39551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39551=edit
Test script to reproduce problem

[Bug fortran/71902] [5/6/7 Regression] Unneeded temporary on reallocatable character assignment

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Sep  4 16:17:55 2016
New Revision: 239977

URL: https://gcc.gnu.org/viewcvs?rev=239977=gcc=rev
Log:
2016-09-04  Thomas Koenig  

PR fortran/71902
* frontend-passes.c (realloc_string_callback): Also check for the
lhs being deferred.  Name temporary variable "realloc_string".

2016-09-04  Thomas Koenig  

PR fortran/71902
* gfortran.dg/dependency_47.f90:  New test.
* gfortran.dg/dependency_49.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/dependency_47.f90
trunk/gcc/testsuite/gfortran.dg/dependency_49.f90
Modified:
trunk/gcc/fortran/frontend-passes.c

[Bug lto/77472] __attribute__((flatten)) when used with -flto can lead to extreme number of inlined functions

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka  ---
> I'm not sure what is the best way forward.
> Maybe gcc should ignore __attribute__((flatten)) when using LTO
> unconditionally?

Well, I am not sure - flatten can make compiler explode without LTO, too,
and I can imagine that in future one may want to do cross-module flattening.
Of course we can document flatten as being applied at compile time only and
eventually intorduce lto_flatten if need for link time flattening arrises,
so existing codebases does not explode.

Honza

[Bug ipa/77472] build of intel_drv.so (xf86-video-intel) takes over 13GB+ memory during lto1

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
I'm not sure what is the best way forward.
Maybe gcc should ignore __attribute__((flatten)) when using LTO
unconditionally?

[Bug ipa/77472] build of intel_drv.so (xf86-video-intel) takes over 13GB+ memory during lto1

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
Ah this is an old issue. Martin reported it a while ago:
https://bugs.freedesktop.org/show_bug.cgi?id=77580

[Bug ipa/77472] build of intel_drv.so (xf86-video-intel) takes over 13GB+ memory during lto1

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Jan Hubicka from comment #3)
> Looks like GCC is trying to satisfy the flatten attribute at link time which
> is ignored by clang?

Yes, you're right:

% grep -D skip -R -i "flatten"
sna_glyphs.i:__attribute__((flatten)) static 
sna_glyphs.i:__attribute__((flatten)) static 
sna_glyphs.i:__attribute__((flatten)) static 

Deleting these three attributes "fixes" the issue.
Even a single flatten attribute is enough to cause problems.

[Bug ipa/77472] build of intel_drv.so (xf86-video-intel) takes over 13GB+ memory during lto1

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Jan Hubicka  ---
Looks like GCC is trying to satisfy the flatten attribute at link time which is
ignored by clang?

[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark

[tulipawn at gmail dot com]

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

--- Comment #3 from PeteVine  ---
Curiously, up to gcc 6, targeting Cortex-A5 made virtually no difference, but
in gcc 7, generic codegen takes an 8% hit while -mcpu=cortex-a5 produces
roughly the same performance as before. (but that's a different issue so FWIW)

[Bug c/77464] gcc -no-pie breaks -shared

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Manuel López-Ibáñez from comment #3)
> > Or at least give a clearer error that mentions -fPIC ...
> 
> Actually this is not a driver issue just a binutils issue if that. Why add
> no-pie anyways to the ldflags.

GCC controls the driver and decides what to pass to the linker.

(In reply to Andrew Pinski from comment #8)
> Basically -no-pie says you are now doing an executable overriding the
> previous -shared.  This is not a bug, you want -no-pie -shared.

This seems counter-intuitive to how other options work. The documentation says
nothing about it. Then we wonder why people complain that GCC is harder to
use/learn.

[Bug libfortran/77473] New: New PRNG causes regressions on DragonFly BSD

[rimvydas.jas at gmail dot com]

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

Bug ID: 77473
   Summary: New PRNG causes regressions on DragonFly BSD
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

Created attachment 39550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39550=edit
changes to tests

Native configuration is x86_64-unknown-dragonfly4.7

r239356 Replace KISS PRNG with xorshift1024* using per-thread state
caused all execution failures for:
FAIL: gfortran.dg/random_7.f90   -O0  execution test
FAIL: gfortran.fortran-torture/execute/random_1.f90 execution,  -O0

r239611 Always initialize PRNG using random data from the OS
added:
FAIL: gfortran.dg/random_4.f90   -O0  execution test

Adding prints for seed and check arrays before comparison shows that they
differ:
./random_4.x
 seed   42  42  42  42  42  42 
42  42  42  42  42  42 
42  42  42  42  42  42  42 
42  42  42  42  42  42  42 
42  42  42  42  42  42 
 0
 check -2110421118 -1194805269  141524222154534463  1225148040   821055102
-1530405947 -1820502322  2146652427  -147906310 -1761641582 -1622508139 
2006260459   151764285 -1191598697  -239551325 -1064082961  2093503284 
1165045647 -1200385605  -867398903  -830236747   846618033   706688103 
1954790377   859476278 -1696051309 -1413451556 -1779817981  1071423788 
1556108935  1966576166   0

If -pthread is explicitly used for those tests (attachment) only failure left
is gfortran.dg/graphite/pr68279.f90 pr71348
(execute/random_1.f90 still fails in testsuite - doesn't take -pthread flag)

Should libgfortran.so always bring in libpthread.so or new PRNG could be
changed to have deterministic behavior with or without -pthread on DragonFly?

[Bug middle-end/77468] C-ray regression on Aarch64

[tulipawn at gmail dot com]

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

--- Comment #2 from PeteVine  ---
Created attachment 39549
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39549=edit
Annotated assembly files

[Bug middle-end/77468] C-ray regression on Aarch64

[tulipawn at gmail dot com]

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

--- Comment #1 from PeteVine  ---
GCC 5.3's profile (./c-ray-mt -t 64 -s 1600x1200 -r 8 -i sphfract -o
output.ppm):

CPU: ARM Cortex-A53, speed 1536 MHz (estimated)
Counted CPU_CYCLES events (Cycle) with a unit mask of 0x00 (No unit mask) count
10

samples  %linenr info image name   symbol
name  
4247694  63.5062  c-ray-mt.c:372  c-ray-mt shade
1281882  19.1651  c-ray-mt.c:336  c-ray-mt trace
1022514  15.2874  c-ray-mt.c:310  c-ray-mt
render_scanline
49166 0.7351  e_pow.c:65  libm-2.23.so
__pow_finite 
17372 0.2597  c-ray-mt.c:454  c-ray-mt
get_primary_ray
17013 0.2544  e_exp.c:248 libm-2.23.so __exp1
14750 0.2205  c-ray-mt.c:501  c-ray-mt
get_sample_pos
13948 0.2085  (no location information)   no-vmlinux  
/no-vmlinux  
13325 0.1992  w_pow.c:26  libm-2.23.so pow
4844  0.0724  e_pow.c:455 libm-2.23.so checkint
4426  0.0662  fputc.c:32  libc-2.23.so fputc
932   0.0139  mpa.c:768   libm-2.23.so __sqr
393   0.0059  c-ray-mt.c:170  c-ray-mt main
214   0.0032  mpa.c:615   libm-2.23.so __mul
27   4.0e-04  mpa.c:443   libm-2.23.so
sub_magnitudes
19   2.8e-04  mpa.c:375   libm-2.23.so
add_magnitudes
11   1.6e-04  mpa.c:333   libm-2.23.so __dbl_mp
81.2e-04  mpa.c:114   libm-2.23.so __cpy
71.0e-04  mpexp.c:44  libm-2.23.so __mpexp
57.5e-05  c-ray-mt.c:656  c-ray-mt
thread_func
57.5e-05  strtod_l.c:481  libc-2.23.so
strtod_l_internal
57.5e-05  strpbrk.c:30libc-2.23.so strpbrk
57.5e-05  syscall-template.S:86   libc-2.23.so write
57.5e-05  mpa.c:310   libm-2.23.so __mp_dbl
57.5e-05  mpa.c:563   libm-2.23.so __sub
34.5e-05  fileops.c:808   libc-2.23.so
_IO_file_overflow@@GLIBC_2.17
34.5e-05  cancellation.c:69   libc-2.23.so
__libc_disable_asynccancel
34.5e-05  fileops.c:501   libc-2.23.so
new_do_write
34.5e-05  strtod_l.c:338  libc-2.23.so
str_to_mpn.isra.0
34.5e-05  mpa.c:899   libm-2.23.so __dvd
34.5e-05  halfulp.c:64libm-2.23.so
__halfulp
23.0e-05  malloc.c:2940   libc-2.23.so free
23.0e-05  getpagesize.c:28libc-2.23.so
getpagesize
23.0e-05  random.c:288libc-2.23.so random
23.0e-05  random_r.c:357  libc-2.23.so random_r
23.0e-05  mpa.c:516   libm-2.23.so __add
23.0e-05  mplog.c:41  libm-2.23.so __mplog
11.5e-05  dl-runtime.c:66 ld-2.23.so  
_dl_fixup
11.5e-05  rtld.c:647  ld-2.23.so  
_dl_initial_error_catch_tsd
11.5e-05  dl-lookup.c:806 ld-2.23.so  
_dl_lookup_symbol_x
11.5e-05  dl-load.c:871   ld-2.23.so  
_dl_map_object_from_fd
11.5e-05  dl-reloc.c:149  ld-2.23.so  
_dl_relocate_object
11.5e-05  dl-tls.c:321ld-2.23.so  
allocate_dtv
11.5e-05  dl-lookup.c:92  ld-2.23.so  
check_match
11.5e-05  strcmp.S:52 ld-2.23.so   strcmp
11.5e-05  fileops.c:494   libc-2.23.so
_IO_do_write@@GLIBC_2.17
11.5e-05  filedoalloc.c:95libc-2.23.so
_IO_file_doallocate
11.5e-05  fileops.c:200   libc-2.23.so
_IO_file_finish@@GLIBC_2.17
11.5e-05  dl-addr.c:126   libc-2.23.so _dl_addr
11.5e-05  malloc.c:3842   libc-2.23.so
_int_free
11.5e-05  syscall-template.S:84   libc-2.23.so mprotect
11.5e-05  strtod_l.c:197  libc-2.23.so
round_and_return
11.5e-05  strtod.c:64 libc-2.23.so strtod
11.5e-05  strtok.c:40 libc-2.23.so strtok
11.5e-05  mpa.c:83libm-2.23.so __acr
11.5e-05  k_standard.c:99   

[Bug ipa/77472] build of intel_drv.so (xf86-video-intel) takes over 13GB+ memory during lto1

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Created attachment 39548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39548=edit
unreduced testcase

 % gcc -flto -fvisibility=hidden -O2 -shared -fPIC intel_module.i gen7_render.i
gen8_eu.i gen8_render.i gen9_render.i kgem.i sna_accel.i sna_display.i
sna_dri2.i sna_driver.i sna_glyphs.i

[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build, wrong-code
  Component|bootstrap   |target
  Known to work||4.9.3
   Target Milestone|--- |5.5
Summary|GCC 5.3.0 bootstrap |[5/6/7 Regression] 5.3.0
   |comparison failure on   |bootstrap comparison
   |arm-linux-gnueabihf |failure on
   ||arm-linux-gnueabihf
  Known to fail||4.9.3, 5.3.0

[Bug ipa/77472] build of intel_drv.so (xf86-video-intel) takes over 13GB+ memory during lto1

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||compile-time-hog, lto,
   ||memory-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-04
 CC||trippels at gcc dot gnu.org
  Component|lto |ipa
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed.

gcc spends ages in ipa inline analysis at WPA time (~4GB used):

Overhead  Shared Object  Symbol
  41.71%  lto1   [.] estimate_calls_size_and_time
  22.29%  lto1   [.] update_callee_keys

then at LTRANS time:

Overhead  Shared Object  Symbol 
  72.35%  lto1   [.] get_abnormal_succ_dispatcher   
   2.11%  lto1   [.] htab_find_slot_with_hash  

more and more memory gets used.

(Clang -flto manages with under 400KB)

Will try to come up with a testcase tomorrow.

[Bug other/68610] configure failure in libssp

[gccbugzilla at limegreensocks dot com]

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

--- Comment #2 from David  ---
Yes, this still occurs with trunk Revision 239974.  I'm using MSYS2 under
Windows and my current configure line is:

../gcctrunk/configure --enable-languages=c,c++ --target=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --disable-multilib
--disable-nls --disable-win32-registry --enable-checking=release
--disable-bootstrap --enable-version-specific-runtime-libs
--disable-fixed-point --prefix=/home/david/gccb --enable-twoprocess
--with-native-system-header-dir=/mingw64/include

None of which turns out to be important.

Looking at libssp/configure.ac, we see this code for testing to see if
fstack-protector works:

AC_MSG_CHECKING([whether -fstack-protector works])
save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -fstack-protector -Werror"
AC_TRY_COMPILE([
void __attribute__((noinline)) bar (char *x)
{
  __builtin_memset (x, 0, 64);
}],[char buf[64]; bar (buf);],
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)])
CFLAGS="$save_CFLAGS"

Note how it saves the CFLAGS, explicitly sets Werror, then does the
AC_TRY_COMPILE.  Contrast this with the code that immediately follows which
attempts to do the same thing for visibility:

AC_MSG_CHECKING([whether hidden visibility is supported])
AC_TRY_COMPILE([
void __attribute__((visibility ("hidden"))) bar (void) {}],,
[ssp_hidden=yes],[ssp_hidden=no])
AC_MSG_RESULT($ssp_hidden)
if test x$ssp_hidden = xyes; then
  AC_DEFINE([HAVE_HIDDEN_VISIBILITY],[1],[__attribute__((visibility
("hidden"))) supported])
fi

If visibility is NOT supported, the compiler will produce a warning.  However,
since in this case Werror is NOT being specified, the compile 'succeeds,' and
visibility is assumed to be supported, even though the compiler explicitly said
it wasn't.

I've learned a lot about how configure scripts work since I originally posted
this bug.  Hopefully this helps makes the problem clearer.

[Bug lto/77472] New: build of intel_drv.so (xf86-video-intel) takes over 13GB+ memory during lto1

[sverd.johnsen at googlemail dot com]

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

Bug ID: 77472
   Summary: build of intel_drv.so (xf86-video-intel) takes over
13GB+ memory during lto1
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sverd.johnsen at googlemail dot com
  Target Milestone: ---

gcc version 6.2.1 20160830 (GCC)

stumbled upon this by accident. should be buildable with no hassle on a
recent-ish distro

git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-intel --depth 1
./autogen.sh
make CC="gcc -flto"

[...]

/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/lto1 -quiet -dumpdir .libs/ -dumpbase
intel_drv.so.ltrans0 -mtune=generic -march=x86-64 -mtune=generic -march=x86-64
-auxbase-strip /tmp/ccc0HKj0.ltrans0.ltrans.o -g -O2 -O2 -fmath-errno
-fsigned-zeros -ftrapping-math -fno-trapv -fno-openmp -fno-openacc
-fno-fat-lto-objects -fPIC -fltrans @/tmp/ccXeZeQR -o /tmp/cchNXbJ0.s

lto1 stays stable at 4GB for a long time then slowly moves towards towards 13GB
or so at which point i stopped it manually since I didnt want to force the OOM
kill

in case you dont get to the point you might need to remove the always_inline
attr from the force_inline in src/sna/compiler.h

[Bug target/77452] [7 Regression] ICE: in plus_constant, at explow.c:87 with -fno-split-wide-types -mavx512f --param=max-combine-insns=2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-04
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #2 from Uroš Bizjak  ---
Combine is able to combine the whole sequence of:

(insn 24 12 25 2 (set (reg:V2SI 110)
(vec_concat:V2SI (subreg:SI (reg/v:V4TI 100 [ v ]) 0)
(const_int 0 [0]))) pr77452.c:7 3640 {*vec_concatv2si_sse4_1}
 (nil))
(insn 25 24 26 2 (set (reg:V2SI 112)
(mem/u/c:V2SI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [2  S8 A64]))
pr77452.c:7 1115 {*movv2si_internal}
 (expr_list:REG_EQUAL (const_vector:V2SI [
(const_int 1 [0x1])
(const_int 1 [0x1])
])
(nil)))
(insn 26 25 30 2 (set (reg:V4SI 113)
(vec_concat:V4SI (reg:V2SI 112)
(reg:V2SI 110))) pr77452.c:7 3642 {*vec_concatv4si}
 (expr_list:REG_DEAD (reg:V2SI 112)
(expr_list:REG_DEAD (reg:V2SI 110)
(nil
(insn 30 26 32 2 (set (reg:V8SI 117)
(vec_concat:V8SI (reg:V4SI 113)
(const_vector:V4SI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
]))) pr77452.c:7 4493 {avx_vec_concatv8si}
 (expr_list:REG_DEAD (reg:V4SI 113)
(nil)))
(insn 32 30 34 2 (set (reg:V16SI 101 [ D.2653 ])
(vec_concat:V16SI (reg:V8SI 117)
(const_vector:V8SI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
]))) pr77452.c:7 4499 {avx_vec_concatv16si}
 (expr_list:REG_DEAD (reg:V8SI 117)
(nil)))
(insn 34 32 35 2 (set (reg:SI 90 [ _4 ])
(subreg:SI (reg:V16SI 101 [ D.2653 ]) 0)) pr77452.c:7 82
{*movsi_internal}
 (expr_list:REG_DEAD (reg:V16SI 101 [ D.2653 ])
(nil)))

to a simple:

(insn 34 32 35 2 (set (reg:SI 90 [ _4 ])
(mem/u/c:SI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [2  S4 A64]))
pr77452.c:7 82 {*movsi_internal}
 (nil))


However, plus_constant is not able to handle lowpart SImode access to:

(const_vector:V2SI [
(const_int 1 [0x1])
(const_int 1 [0x1])
])

Following patch allows this.

--cut here--
Index: explow.c
===
--- explow.c(revision 239975)
+++ explow.c(working copy)
@@ -106,7 +106,15 @@ plus_constant (machine_mode mode, rtx x, HOST_WIDE
   if (GET_CODE (XEXP (x, 0)) == SYMBOL_REF
  && CONSTANT_POOL_ADDRESS_P (XEXP (x, 0)))
{
- tem = plus_constant (mode, get_pool_constant (XEXP (x, 0)), c);
+ rtx cst = get_pool_constant (XEXP (x, 0));
+
+ if (GET_CODE (cst) == CONST_VECTOR
+ && GET_MODE_INNER (GET_MODE (cst)) == mode)
+   {
+ cst = gen_lowpart (mode, cst);
+ gcc_assert (cst);
+   }
+ tem = plus_constant (mode, cst, c);
  tem = force_const_mem (GET_MODE (x), tem);
  /* Targets may disallow some constants in the constant pool, thus
 force_const_mem may return NULL_RTX.  */
--cut here--

[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

[ludo at gnu dot org]

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

--- Comment #9 from Ludovic Courtès  ---
GCC 4.9.4 exhibits the same bootstrapping failure (again on
arm-linux-gnueabihf).

I reverted the ARM-specific changes made between 4.9.3 and 4.9.4 by applying
the result of "diff -ur gcc-4.9.{4,3}/gcc/config/arm" to 4.9.4 (patch
attached); the resulting compiler bootstraps fine.

[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

[ludo at gnu dot org]

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

--- Comment #8 from Ludovic Courtès  ---
Created attachment 39547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39547=edit
Revert ARM-specific 4.9.3-to-4.9.4 changes

[Bug tree-optimization/41244] "[i] - data" isn't converted to "i"

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #3)
> On the trunk (on aarch64) we get:

Yes, on I32P64 platforms we still have a chance to prove that the
multiplication doesn't overflow.

>   long int _4;
>   long int _5;
>   int _7;
>   sizetype _10;
> 
>   :
>   _10 = i_6(D) w* 4;

Ah, you actually get WIDEN_MULT_EXPR on aarch64? I essentially never saw it on
other platforms... x86_64 has

  _9 = (sizetype) i_6(D);
  _10 = _9 * 4;

instead.

>   _4 = (long int) _10;

Hmm, why doesn't that get combined with the WIDEN_MULT_EXPR? I would expect

  _4 = i_6(D) w* 4;

to be valid.

>   _5 = _4 /[ex] 4;
>   _7 = (int) _5;

[Bug debug/77471] -O3 -g compile time hog on ppc64le

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Overhead  Command  Shared Object  Symbol
  34.45%  cc1  cc1[.] canonicalize_values_star  
  20.56%  cc1  cc1[.] set_slot_part 
  12.52%  cc1  cc1[.] dataflow_set_merge
  10.73%  cc1  cc1[.] loc_cmp   
   3.03%  cc1  cc1[.] hash_table::find_slot_with_hash   
   1.47%  cc1  libc-2.20.so   [.] free 
...

[Bug debug/77471] New: -O3 -g comile time hog on ppc64le

[trippels at gcc dot gnu.org]

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

Bug ID: 77471
   Summary: -O3 -g comile time hog on ppc64le
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

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

On ppc64le I see:

trippels@gcc2-power8 linux-4.7.2 % time gcc -O2 -g -c qla_dbg.i
gcc -O2 -g -c qla_dbg.i  1.81s user 0.02s system 99% cpu 1.827 total

trippels@gcc2-power8 linux-4.7.2 % time gcc -O3 -c qla_dbg.i
gcc -O3 -c qla_dbg.i  5.65s user 0.04s system 99% cpu 5.686 total

trippels@gcc2-power8 linux-4.7.2 % time gcc -O3 -g -c qla_dbg.i
gcc -O3 -g -c qla_dbg.i  86.01s user 0.15s system 99% cpu 1:26.16 total

Happens with all supported gcc versions and also for gcc-4.9.

[Bug libgcc/77470] New: libssp may have bad includes

[coypu at sdf dot org]

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

Bug ID: 77470
   Summary: libssp may have bad includes
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

apologies if this is invalid for vanilla GCC, I am very skeptical I will be
able to build it without the help of a package, which includes small changes.

configuring with --enable-libssp, I got a header file:

$ grep ssp /usr/pkg/gcc5/lib/gcc/x86_64--netbsd/5.4.0/include/ssp/stdio.h 
#include 

there is no /usr/pkg/gcc5/lib/gcc/x86_64--netbsd/5.4.0/include/ssp.h,
only /usr/pkg/gcc5/lib/gcc/x86_64--netbsd/5.4.0/include/ssp/ssp.h.

and if I try to build hello world (i.e. include stdio.h) with -D_FORTIFY_SOURCE
I get:

$ /usr/pkg/gcc5/bin/gcc -D_FORTIFY_SOURCE test.c
In file included from /usr/include/stdio.h:597:0,
 from test.c:1:
/usr/pkg/gcc5/lib/gcc/x86_64--netbsd/5.4.0/include/ssp/stdio.h:38:17: fatal
error: ssp.h: No such file or directory
compilation terminated.

[Bug libstdc++/77469] std::regex x("[b\\-a]") throws with message "Invalid range in bracket expression."

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andreas Schwab  ---
\ is not special inside bracket expressions, [b\-a] means b and the range
between \ and a.  If you want to include a - in a bracket expression, put it
first or last.