[Bug c/81854] weak alias of an incompatible symbol accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-18
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01103.html

[Bug target/77579] Missed multiple add (int) for CSEd case

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-18
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
With that patch there are a few regressions:
+FAIL: gcc.dg/tree-ssa/pr40921.c scan-tree-dump-times optimized "_* = -y_" 0
+FAIL: gcc.dg/tree-ssa/slsr-10.c scan-tree-dump-times optimized " * " 1
+FAIL: gcc.dg/tree-ssa/slsr-14.c scan-tree-dump-times optimized " * " 1
+FAIL: gcc.dg/tree-ssa/slsr-15.c scan-tree-dump-times optimized " * " 1
+FAIL: gcc.dg/tree-ssa/slsr-19.c scan-tree-dump-times optimized " * " 2
+FAIL: gcc.dg/tree-ssa/slsr-20.c scan-tree-dump-times optimized " * s" 1
+FAIL: gcc.dg/tree-ssa/slsr-21.c scan-tree-dump-times optimized " * stride"
1
+FAIL: gcc.dg/tree-ssa/slsr-22.c scan-tree-dump-times optimized " * 3" 1
+FAIL: gcc.dg/tree-ssa/slsr-23.c scan-tree-dump-times optimized " * stride"
1
+FAIL: gcc.dg/tree-ssa/slsr-24.c scan-tree-dump-times optimized " * " 1
+FAIL: gcc.dg/tree-ssa/slsr-25.c scan-tree-dump-times optimized " * " 1
+FAIL: gcc.dg/tree-ssa/slsr-26.c scan-tree-dump-times optimized " * stride"
1
+FAIL: gcc.dg/tree-ssa/slsr-31.c scan-tree-dump-times optimized " * 2" 1
+FAIL: gcc.dg/tree-ssa/slsr-32.c scan-tree-dump-times optimized " * s" 1
+FAIL: gcc.dg/tree-ssa/slsr-37.c scan-tree-dump-times optimized " * s" 1
+FAIL: gcc.dg/tree-ssa/slsr-5.c scan-tree-dump-times optimized " * " 1
+FAIL: gcc.dg/tree-ssa/slsr-7.c scan-tree-dump-times optimized " * " 1
+FAIL: gcc.dg/tree-ssa/slsr-9.c scan-tree-dump-times optimized " * " 1

Though most are not really worse code.
slsr-21.c, slsr-22.c, slsr-23.c, slsr-24.c, slsr-25.c, slsr-26.c, slsr-31.c,
slsr-32.c, slsr-37.c.

Basically if the one of the operand is a constant, we want to optimize this to:
add DST, SRC, SRC1 lsl #N .  But if it is not constant we don't want to do
madd.  Let me see if I can do that.

[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jason Merrill  ---
(In reply to Jan Hubicka from comment #4)
> The ICE is about vtable:
> which is constructed without any DECL_INITIAL. Is this intended? If so, we
> could just remove the assert and silently ignore it, but I see no point in
> having vtable attached without actually knowning the contents.

Hmm, I'm not sure either why we need to have a VAR_DECL before we get to
initialize_vtable.  Nathan, I think this was your code?

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #6 from Peter Bergner  ---
I have a patch I'm testing.  The problem is that rs6000_set_current_function()
is not clearing the rs6000_previous_fndecl cache correctly when it needs to. 
With the test case, we notice that rs6000_previous_fndecl is set (when it
shouldn't be) and we end up restoring options from it which incorrectly disable
HW sqrt leading to the ICE.

The current code is also a rats nest and hard to read/understand, so the patch
I'm testing is modeled on s390's version of the same function which is much
cleaner and correctly clears out the rs6000_previous_fndecl when it needs to.

[Bug target/81268] [avr] Support __gcc_isr pseudo-instruction for more efficient ISR prologues

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01469.html

--- Comment #3 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Aug 14 09:14:16 2017
New Revision: 251085

URL: https://gcc.gnu.org/viewcvs?rev=251085=gcc=rev
Log:
gcc/
PR target/81754
PR target/81268
* config/avr/avr.opt (mgas-isr-prologues): New Var
avr_gasisr_prologues.
* config/avr/avr.md (gasisr, *gasisr): Use it instead of
TARGET_GASISR_PROLOGUES.
* config/avr/avr.c (avr_option_override): Same.
(avr_pass_pre_proep::execute): Same.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.md
trunk/gcc/config/avr/avr.opt

[Bug c/81117] Improve buffer overflow checking in strncpy

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01672.html

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Mon Aug 14 20:21:44 2017
New Revision: 251100

URL: https://gcc.gnu.org/viewcvs?rev=251100=gcc=rev
Log:
PR c/81117 - Improve buffer overflow checking in strncpy - part 2

gcc/ChangeLog:

PR c/81117
* doc/extend.texi (attribute nonstring): Document new attribute.

gcc/c-family/ChangeLog:

PR c/81117
* c-attribs.c (c_common_attribute_table): Add nonstring entry.
(handle_nonstring_attribute): New function.

gcc/testsuite/ChangeLog:

PR c/81117
* c-c++-common/attr-nonstring-1.c: New test.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/45113] absent or confusing diagnostics of invalid template argument list in implicit template class instantiation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01665.html

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Roman Kononov from comment #0)
> $cat test1.cpp
> template struct is_same { static bool const
> value=false; };
> template struct is_same { static bool const value=true; };
> template struct U {};
> struct Q { typedef U C; };
> typedef char check[is_same::value ? 1 : -1];
> 
> $g++ -std=gnu++0x -c test1.cpp && echo $?
> 0
> 
> In 14.3.1, the Standard says: "A template-argument for a template-parameter
> which is a type shall be a type-id." The test must fail compilation, and
> Q::C can not be int.

This now fails with:
$ /usr/local/bin/g++ -c -std=gnu++0x 45113.cc
45113.cc:4:33: error: template argument 1 is invalid
 struct Q { typedef U C; };
 ^
$

> 
> $cat test2.cpp
> template struct U {};
> typedef U B;
> 
> $g++ -std=gnu++0x -c test2.cpp 
> test2.cpp:2:25: error: invalid type in declaration before ';' token
> 
> This message is confusing.

This message is now:
$ /usr/local/bin/g++ -c -std=gnu++0x 45113_2.cc
45113_2.cc:2:22: error: template argument 1 is invalid
 typedef U B;
  ^
$

> 
> $cat test3.cpp 
> template struct U {};
> typedef U A;
> 
> $g++ -c test3.cpp 
> test3.cpp:2:22: error: wrong number of template arguments (1, should be 2)
> test3.cpp:1:40: error: provided for 'template struct U'
> test3.cpp:2:25: error: invalid type in declaration before ';' token
> 
> These messages are confusing.

This message is now:
$ /usr/local/bin/g++ -c -std=gnu++0x 45113_3.cc
45113_3.cc:2:22: error: wrong number of template arguments (1, should be 2)
 typedef U A;
  ^
45113_3.cc:1:40: note: provided for ‘template struct U’
 template struct U {};
^
$

Which I guess is still kinda confusing. So test1.cpp and test2.cpp are fixed,
but confirming for test3.cpp.

[Bug preprocessor/77810] provide format_inform_at_substring to go with format_warning_at_substring

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01655.html

--- Comment #4 from David Malcolm  ---
Patch looks reasonable, and I can approve it.

CC me on it when you post it to gcc-patches.

[Bug translation/79998] typo in diagnostic "specified bound %wu"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Component|tree-optimization   |translation
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Severity|normal  |trivial

--- Comment #1 from Eric Gallager  ---
Redoing lost comments, which seem to be in reverse order:

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01640.html

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|ASSIGNED|RESOLVED
  Component|tree-optimization   |translation
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
Fixed in r251096.

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01641.html

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Mon Aug 14 16:47:40 2017
New Revision: 251096

URL: https://gcc.gnu.org/viewcvs?rev=251096=gcc=rev
Log:
PR translation/79998 - typo in diagnostic "specified bound %wu"

gcc/ChangeLog:
* gimple-ssa-sprintf.c (pass_sprintf_length::handle_gimple_call):
Remove a stray space.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01635.html

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-14
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot
gnu.org
 Ever confirmed|0   |1
   Severity|normal  |trivial

--- Comment #1 from Martin Sebor  ---
Confirmed.  Let me fix it.

[Bug translation/79997] simple-ssa-sprintf i18n: wrong plural form in maybe_warn

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Component|tree-optimization   |translation
 Depends on||77810
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01634.html

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||msebor at gcc dot gnu.org
  Component|tree-optimization   |translation
 Depends on||77810
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  There are a few instances of this idiom in the file and elsewhere
in GCC.  The pass makes use of the format_warning_at_substring() function to do
the formatting and that function only comes in one form, and doesn't provide an
"overload" similar to warning_n or warning_at_rich_loc_n to format plural forms
of diagnostics (this enhancement request is being tracked in pr77810).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77810
[Bug 77810] provide format_inform_at_substring to go with
format_warning_at_substring


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77810
[Bug 77810] provide format_inform_at_substring to go with
format_warning_at_substring

[Bug c++/44580] inconsistent "right-hand operand of comma has no effect"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01632.html

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed.

[Bug c++/44520] improve diagnostic for ambiguous lookup

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01630.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, the g++ diagnostic is now:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 44520.cc
44520.cc: In member function ‘void D::g()’:
44520.cc:10:5: error: ‘B1’ is an ambiguous base of ‘D’
   f();
 ^
$

[Bug c++/44400] GCC allows declaring a function having the name of the class using a typedef

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01629.html

Eric Gallager  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, g++ accepts it with neither warning nor error, while clang++ rejects
it like this:

$ /usr/local/bin/g++ -Wall -Wextra -pedantic -c 44400.cc
$ /sw/opt/llvm-3.1/bin/clang++ -Wall -Wextra -pedantic -c 44400.cc
44400.cc:2:14: error: member 'X' has the same name as its class
struct X { F X; };
 ^
44400.cc:2:14: error: constructor cannot have a return type
struct X { F X; };
   ~ ^
2 errors generated.
$

[Bug c++/43105] Document restrictions on mixing -fno-rtti and -frtti

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01628.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, text in the current docs is still pretty much the same as it was in
4.4.3.

[Bug c++/43454] warning with -Wall despite __attribute__ ((__unused__))

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
  Known to work||4.0.2
 Ever confirmed|0   |1
  Known to fail||4.0.4, 4.1.2, 4.2.4, 4.3.4,
   ||4.4.3, 8.0

--- Comment #2 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01627.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
  Known to work||4.0.2
 Ever confirmed|0   |1
  Known to fail||4.0.4, 4.1.2, 4.2.4, 4.3.4,
   ||4.4.3, 8.0

--- Comment #2 from Eric Gallager  ---
Confirmed, output now looks like this now that there's underlining and stuff:

$ /usr/local/bin/g++ -c -Wall -S 43454.cc
43454.cc:7:44: warning: ‘check_moo’ defined but not used [-Wunused-variable]
 static int (* __attribute__ ((__unused__)) check_moo) (void) = gnulib::moo;
^
$

[Bug c++/38087] Pseudo destructor call

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
Redoing lost comments:

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01624.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> I still think this is valid code ...  There are defect reports against this
> area too.

Which ones do you mean?

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01637.html

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|WAITING |NEW

--- Comment #5 from Jonathan Wakely  ---
There's https://wg21.link/cwg555 but I don't think it changes anything here.

[expr.pseudo] definitely doesn't apply, as that only applies to non-class
types. (The bug title is wrong for the same reason, this is a destructor call,
not a pseudo destructor call.)

The current wording in [basic.lookup.classref] says "At least one of the
lookups shall find a name that refers to cv T." The object expression has type
C, but the lookup result for B does not find that type, so the code is invalid.

[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #8 from Eric Gallager  ---
Redoing lost comments:

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01623.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #8 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #5)
> If it is getting you an internal error, then it is usually it is because the
> attachments are too big.
> 
> As for the other issue, there is a C++ defect report about this case, which
> consider this as dependent but a member as non dependent and all confusing
> happens with namelookup and such.

Link to the C++ DR? Is it still open?

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01625.html

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #9 from Eric Gallager  ---
(In reply to Roger Leigh from comment #6)
> Created attachment 18264 [details]
> Preprocessed source for g++-4.5.0 (svn 149777)

This compiles successfully without error for me with g++-8 (svn 250985), so I
guess I can close it.

[Bug c++/36685] clarify/diagnose use of weak constant

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01622.html

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
Confirmed.

[Bug c++/30812] enhancement: exception specification in __PRETTY_FUNCTION__

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01620.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Eric Gallager  ---
Confirming as an enhancement, although maybe a new identifier so as not to
break existing code? __PRETTIER_FUNCTION__?

[Bug c++/51277] Feature request: C++ diagnostic for ambiguous overloads

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01619.html except actually
confirming it this time:

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #3 from Eric Gallager  ---
Confirming as an enhancement.

[Bug c++/15369] "Wrong" line number for static constructor function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||seongbae.park at gmail dot com

--- Comment #10 from Eric Gallager  ---
*** Bug 30257 has been marked as a duplicate of this bug. ***

[Bug c++/30257] static initializers are attributed to bogus line number in coverage.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01613.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Eric Gallager  ---
(In reply to Seongbae Park from comment #2)
> Yes, it looks like duplicate, although PR 15369 is against 3.4.

Still duplicate-ish enough. Closing.

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

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

[Bug bootstrap/81881] [8 Regression] bootstrap failed on x86

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from H.J. Lu  ---
False alarm.

[Bug bootstrap/81883] bootstrap-lto build fails with undefined reference to `_Unwind_Resume'

[t at sharklasers dot com]

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

JD  changed:

   What|Removed |Added

 Target||x86_64
   Host||x86_64

--- Comment #1 from JD  ---
This part of the output may be relevant:
The build was configured with --disable-multilib

Checking multilib configuration for libgcc...
make[3]: Entering directory 'gccbuild/x86_64-pc-linux-gnu/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
# Early copyback; see "all" above for the rationale.  The
# early copy is necessary so that the gcc -B options find
# the right startup files when linking shared libgcc.
/bin/bash gcc-7.2.0/libgcc/../mkinstalldirs ../.././gcc
parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o crtprec32.o
crtprec64.o crtprec80.o crtfastmath.o";   
\
for file in $parts; do  \
  rm -f ../.././gcc/$file;  \
  /usr/bin/install -c -m 644 $file ../.././gcc/;\
  case $file in \
*.a)\
  gcc-ranlib ../.././gcc/$file ;;   \
  esac; \
done
# @multilib_flags@ is still needed because this may use
# gccbuild/./gcc/xgcc -Bgccbuild/./gcc/ -Bgcc-7.2.0/x86_64-pc-linux-gnu/bin/
-Bgcc-7.2.0/x86_64-pc-linux-gnu/lib/ -isystem
gcc-7.2.0/x86_64-pc-linux-gnu/include -isystem
gcc-7.2.0/x86_64-pc-linux-gnu/sys-includeand -O2  -g -O2 -march=native -O3
-flto -fno-fat-lto-objects -fuse-linker-plugin -DIN_GCC-W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector  directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/bash gcc-7.2.0/libgcc/../mkinstalldirs .
gccbuild/./gcc/xgcc -Bgccbuild/./gcc/ -Bgcc-7.2.0/x86_64-pc-linux-gnu/bin/
-Bgcc-7.2.0/x86_64-pc-linux-gnu/lib/ -isystem
gcc-7.2.0/x86_64-pc-linux-gnu/include -isystem
gcc-7.2.0/x86_64-pc-linux-gnu/sys-include-O2  -g -O2 -march=native -O3
-flto -fno-fat-lto-objects -fuse-linker-plugin -DIN_GCC-W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1
-Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -march=native -O3
-flto -fno-fat-lto-objects -fuse-linker-plugin -B./ _muldi3_s.o _negdi2_s.o
_lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o
_clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o
_addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o
_negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o
_clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o
_powidf2_s.o _powixf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o
_divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o
_clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o
_fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o
_fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o
_floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o
_udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o cpuinfo_s.o
sfp-exceptions_s.o addtf3_s.o divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o
unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o
fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o
fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o
extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o getf2_s.o
letf2_s.o eqtf2_s.o _divtc3_s.o _multc3_s.o _powitf2_s.o
enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o
unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f ./libgcc_s.so && if [ -f
./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else
true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && (echo "/* GNU ld script";
echo "   Use the shared library, but some functions are only in"; echo "   the
static library.  */"; echo "GROUP ( libgcc_s.so.1 -lgcc )" ) > ./libgcc_s.so
binutils-2.29/x86_64-pc-linux-gnu/bin/ld: error in
/tmp/ccYY0W1A.ltrans0.ltrans.o(.eh_frame); no .eh_frame_hdr table will be
created.

I don't know what's happening there but it seems to have failed and the build
continued.

[Bug bootstrap/81883] New: bootstrap-lto build fails with undefined reference to `_Unwind_Resume'

[t at sharklasers dot com]

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

Bug ID: 81883
   Summary: bootstrap-lto build fails with undefined reference to
`_Unwind_Resume'
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t at sharklasers dot com
  Target Milestone: ---

Created attachment 41999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41999=edit
Output of a sequential make run for context

I compiled gcc-7.2 without LTO optimizations and tried to compile it again with
bootstrap-lto using the new gcc-7.2 compiler.

System:
Linux 4.4.0-91-generic #114-Ubuntu SMP x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=gcc-7.2.0/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: gcc-7.2.0/configure --prefix=gcc-7.2.0
--enable-languages=c,c++,fortran --enable-gold=yes --enable-ld=yes
--enable-bootstrap --disable-multilib
Thread model: posix
gcc version 7.2.0 (GCC) 

$ env | grep -i flags
LDFLAGS=-O3 -flto=4 -fuse-linker-plugin
CXXFLAGS=-march=native -O3 -flto -fno-fat-lto-objects -fuse-linker-plugin
CFLAGS=-march=native -O3 -flto -fno-fat-lto-objects -fuse-linker-plugin

$ ld -v
GNU ld (GNU Binutils) 2.29

GCC tools were used
export AR=gcc-ar
export NM=gcc-nm
export RANLIB=gcc-ranlib

The bootstrap-lto build was configured with:
gcc-7.2.0/configure --prefix=gcc-7.2.0 --enable-languages=c,c++,fortran
--enable-gold=yes --enable-ld=yes --enable-bootstrap
--with-build-config=bootstrap-lto --disable-multilib


make[3]: Entering directory 'gccbuild/gcc'
gccbuild/./prev-gcc/xg++ -Bgccbuild/./prev-gcc/
-Bgcc-7.2.0/x86_64-pc-linux-gnu/bin/ -nostdinc++
-Bgccbuild/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-Bgccbuild/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-Igccbuild/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu 
-Igccbuild/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-Igcc-7.2.0/libstdc++-v3/libsupc++
-Lgccbuild/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-Lgccbuild/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs   -g -O2
-flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc  -no-pie -o
build/genmddeps \
build/genmddeps.o build/read-md.o build/errors.o .././libiberty/libiberty.a
binutils-2.29/x86_64-pc-linux-gnu/bin/ld: error in
/tmp/ccK67upk.ltrans0.ltrans.o(.eh_frame); no .eh_frame_hdr table will be
created.
/tmp/ccK67upk.ltrans0.ltrans.o: In function `__verbose_terminate_handler':
gcc-7.2.0/libstdc++-v3/libsupc++/vterminate.cc:82: undefined reference to
`_Unwind_Resume'
collect2: error: ld returned 1 exit status
Makefile:2791: recipe for target 'build/genmddeps' failed
make[3]: *** [build/genmddeps] Error 1
make[3]: Leaving directory 'gccbuild/gcc'
Makefile:4596: recipe for target 'all-stage2-gcc' failed
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory 'gccbuild'
Makefile:26888: recipe for target 'stage2-bubble' failed
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory 'gccbuild'
Makefile:941: recipe for target 'all' failed
make: *** [all] Error 2

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
Fixed.

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Thu Aug 17 19:56:46 2017
New Revision: 251165

URL: https://gcc.gnu.org/viewcvs?rev=251165=gcc=rev
Log:
Fix build of --enable-gather-detailed-mem-stats (PR bootstrap/81864).

2017-08-17  Martin Liska  

PR bootstrap/81864
* tree-loop-distribution.c (ddrs_table): Change type to pointer
type.
(get_data_dependence): Use it as pointer type.
(distribute_loop): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-loop-distribution.c

[Bug target/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[uros at gcc dot gnu.org]

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

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Aug 17 19:39:20 2017
New Revision: 251164

URL: https://gcc.gnu.org/viewcvs?rev=251164=gcc=rev
Log:
Backport from mainline
2017-08-17  Maxim Ostapenko  

PR target/81861
* config/i386/i386.c (ix86_option_override_internal): Save target
specific options after ix86_stack_protector_guard_reg was changed.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c

[Bug target/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[uros at gcc dot gnu.org]

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

--- Comment #11 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Aug 17 19:38:20 2017
New Revision: 251163

URL: https://gcc.gnu.org/viewcvs?rev=251163=gcc=rev
Log:
2017-08-17  Uros Bizjak  

Backport from mainline
2017-08-17  Maxim Ostapenko  

PR target/81861
* config/i386/i386.c (ix86_option_override_internal): Save target
specific options after ix86_stack_protector_guard_reg was changed.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c

[Bug fortran/80467] Function Without Arguments Fails to Generate Error When Declared Later

[jeffrey.armstrong at approximatrix dot com]

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

--- Comment #7 from Jeffrey Armstrong  ---
Any update on this Internal Compiler Error?  Has anyone looked into it further?

[Bug target/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[uros at gcc dot gnu.org]

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

--- Comment #10 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Aug 17 19:37:06 2017
New Revision: 251162

URL: https://gcc.gnu.org/viewcvs?rev=251162=gcc=rev
Log:
Backport from mainline
2017-08-17  Maxim Ostapenko  

PR target/81861
* config/i386/i386.c (ix86_option_override_internal): Save target
specific options after ix86_stack_protector_guard_reg was changed.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/i386.c

[Bug target/81863] [7 regression] -mword-relocations is unreliable

[ard.biesheuvel at linaro dot org]

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

--- Comment #6 from ard.biesheuvel at linaro dot org ---
FWIW, the following makes the issue go away (tested on 4.9.4)

@@ -6196,7 +6210,9 @@
   [(set (match_operand:SI 0 "nonimmediate_operand" "=r")
(lo_sum:SI (match_operand:SI 1 "nonimmediate_operand" "0")
   (match_operand:SI 2 "general_operand"  "i")))]
-  "arm_arch_thumb2 && arm_valid_symbolic_address_p (operands[2])"
+  "arm_arch_thumb2 && arm_valid_symbolic_address_p (operands[2])
+   && (   GET_CODE (operands[2]) != SYMBOL_REF
+   || !target_word_relocations)"
   "movt%?\t%0, #:upper16:%c2"
   [(set_attr "predicable" "yes")
(set_attr "predicable_short_it" "no")

I have no idea whether this is a suitable fix: I will leave that to the
experts. Just providing this as a data point.

[Bug target/79242] ICE in simplify_subreg, at simplify-rtx.c:6029

[apushkin at gmail dot com]

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

Andrei Pushkin  changed:

   What|Removed |Added

 CC||apushkin at gmail dot com

--- Comment #6 from Andrei Pushkin  ---
Still broken in 7.2

What are the chances of this bug getting some love?

[Bug libstdc++/81835] cxxabi.h has invalid link in comment.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-17
  Component|demangler   |libstdc++
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
(In reply to Chris Johns from comment #0)
> Tiny issue.
> 
> Looking over cxxabi.h I noticed a link in a comment about __cxa_demangle is
> not valid anymore:
> 
>*  See http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch39.html
>*  for other examples of use.

I'll fix the link.

> I am looking for the implementation of the demangler code we have on our
> mebedded targets in RTEMS. A pointer to that location would be most welcomed.

https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_demangling.html is the new
location.

[Bug c++/26426] Type layout bug

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
See https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01667.html where I said:

I don't think this is a bug. B is the primary base class for Z so has already
been allocated (as part of the Y subobject, in I-2b), and so the B base class
of the X subobject is not allocated as part of the X (in III).

https://itanium-cxx-abi.github.io/cxx-abi/abi.html#a17

[Bug target/72804] Poor code gen with -mvsx-timode

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2017-08/msg00910.ht
   ||ml
 Resolution|--- |FIXED

--- Comment #7 from Peter Bergner  ---
Fixed on trunk.  The issue still exists in GCC 7.  I will let it sit on trunk a
week or two and then will see how the back port looks.

[Bug fortran/81827] Large compile time with derived-type rrays

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||pault at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #7 from Paul Thomas  ---
Hi Richi,

This is not right - only the first level should be nullified. Oddly, GNU
Fortran (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4) did the right thing. It seems to
have been fixed and the unfixed!

I have reopened it.

Paul

[Bug c++/26426] Type layout bug

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Redoing lost https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01612.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
How are you getting the byte values? I compiled the testcase but I don't know
what I'm supposed to be looking for in the output...

$ /usr/local/bin/g++ -Wall -Wextra -Wreorder -Wpacked -Wpadded -c 26426.cc
$ size 26426.o
__TEXT  __DATA  __OBJC  others  dec hex
1237232 0   16  14855cd
$ nm 26426.o
041c s EH_frame1
012c S __ZN1AC2Ev
 U __ZN1AD2Ev
0148 S __ZN1BC2Ev
 U __ZN1BD2Ev
0164 S __ZN1XC2Ev
01ac S __ZN1XD2Ev
01f4 S __ZN1YC2Ev
 U __ZN1YD2Ev
007a T __ZN1ZC1Ev
 T __ZN1ZC2Ev
02e6 S __ZN1ZD0Ev
0222 S __ZN1ZD1Ev
038c S __ZTC1Z0_1Y
03a4 S __ZTC1Z4_1X
 U __ZTI1A
 U __ZTI1B
03f4 S __ZTI1X
 U __ZTI1Y
03d4 S __ZTI1Z
0417 S __ZTS1X
0414 S __ZTS1Z
0368 S __ZTT1Z
 U __ZTV1A
 U __ZTV1B
032c S __ZTV1Z
 U __ZTVN10__cxxabiv121__vmi_class_type_infoE
0311 S __ZTv0_n12_N1ZD0Ev
02d4 S __ZTv0_n12_N1ZD1Ev
 U __ZdlPvm
0323 S ___x86.get_pc_thunk.ax
0327 S ___x86.get_pc_thunk.bx
05c4 s l__ZTT1Z$non_lazy_ptr
05c8 s l__ZTV1A$non_lazy_ptr
05cc s l__ZTV1B$non_lazy_ptr
05c0 s l__ZTV1Z$non_lazy_ptr
$

--- New Comment ---

Jonathan Wakely also had a comment that got lost in the Bugzilla outage, but my
browser doesn't seem to want to load my email or the archived copy, so he'll
have to re-add it himself... (I think he said something like this wasn't
actually a bug...)

[Bug target/81874] internal compiler error: in do_SUBST, at combine.c:725

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Reduced test-case:

int a, c;
int
d (int f, int g)
{
  return g ?: f;
}
void
h ()
{
  int b = a > 0 && 1 > 2147483647 - a, e = b;
  c = d (++a, e);
}

[Bug target/81874] internal compiler error: in do_SUBST, at combine.c:725

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||clm at codesourcery dot com,
   ||marxin at gcc dot gnu.org,
   ||mfortune at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, on trunk it hides with r239421 (and -fcode-hoisting).

The problematic do_SUBST is:

(gdb) p debug_rtx(*into)
(reg:SI 202)
$1 = void
(gdb) p debug_rtx(newval)
(const_int 2147418112 [0x7fff])

Adding port maintainers to CC.

[Bug target/81803] [7/8 regression] miscompilation at -O1 on mips64el

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> I have just noticed this which seems curious. Is the 39 -> 40 combine really
> a valid transformation? It seems we've lost the sign extension and we're
> just putting a 32-bit value into a 64-bit register without trying to clear
> the upper bits anymore?

Yes, for WORD_REGISTER_OPERATIONS architectures the combiner can do things like
that, although there might be bugs lurking of course.

[Bug c/81882] attribute ifunc documentation uses invalid code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01090.html

[Bug c/81882] attribute ifunc documentation uses invalid code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-17
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I believe the documentation should be changed like so:

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 251156)
+++ gcc/doc/extend.texi (working copy)
@@ -2783,21 +2783,24 @@ The @code{ifunc} attribute is used to mark a funct
 function using the STT_GNU_IFUNC symbol type extension to the ELF
 standard.  This allows the resolution of the symbol value to be
 determined dynamically at load time, and an optimized version of the
-routine can be selected for the particular processor or other system
+routine to be selected for the particular processor or other system
 characteristics determined then.  To use this attribute, first define
 the implementation functions available, and a resolver function that
 returns a pointer to the selected implementation function.  The
 implementation functions' declarations must match the API of the
-function being implemented, the resolver's declaration is be a
-function returning pointer to void function returning void:
+function being implemented.  The resolver should be declared to
+be a function returning a pointer to a function taking no arguments
+and returning a pointer to a function of the same type as the
+implementation.  For example:

 @smallexample
 void *my_memcpy (void *dst, const void *src, size_t len)
 @{
   @dots{}
+  return dst;
 @}

-static void (*resolve_memcpy (void)) (void)
+static void* (*resolve_memcpy (void))(void *, const void *, size_t)
 @{
   return my_memcpy; // we'll just always select this routine
 @}

[Bug c/81882] New: attribute ifunc documentation uses invalid code

[msebor at gcc dot gnu.org]

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

Bug ID: 81882
   Summary: attribute ifunc documentation uses invalid code
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The documentation of the ifunc ("resolver") attribute in the GCC manual isn't
quite correct.  It advises users to declare the resolver to return a pointer to
a void function returning void, and shows an example of how to do that, like
so:

typedef __SIZE_TYPE__  size_t;

void* my_memcpy (void *dst, const void *src, size_t len)
{
  // ...
  return dst;
}

static void (*resolve_memcpy (void)) (void)
{
  return my_memcpy; // we'll just always select this routine
}

But the example returns the address of a function of incompatible type, which
then causes compilation warnings in C and errors in C++ (see below).

Instead, the resolver should be declared to return a pointer to the a function
of the same type as whose address it returns.

x.c: In function ‘resolve_memcpy’:
x.c:10:10: warning: returning ‘void * (*)(void *, const void *, size_t) {aka
void * (*)(void *, const void *, long unsigned int)}’ from a function with
incompatible return type ‘void (*)(void)’ [-Wincompatible-pointer-types]
   return my_memcpy; // we'll just always select this routine
  ^
At top level:
x.c:8:15: warning: ‘resolve_memcpy’ defined but not used [-Wunused-function]
 static void (*resolve_memcpy (void)) (void)
   ^~

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[amonakov at gcc dot gnu.org]

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

--- Comment #9 from Alexander Monakov  ---
I don't understand how LIM may deduce that store sinking is safe without
considering may-alias relations. If it is UB to write the same object from
different declared-independent iterations, then I think the correct deduction
would be "iteration count is at most 1", not "store sinking is safe"?


A C++ variation of the test, doesn't need -fno-tree-sra or asm() shenanigans:

void g(int p, int *out)
{
  int x = 0, y;
#pragma GCC ivdep
  for (int i = 0; i < 100; i++)
{
  int  = p ? x : y;
  r = 42;
  out[i] = x;
}
}

[Bug target/78804] [RX] -m64bit-doubles does not work

[ian at airs dot com]

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

--- Comment #15 from Ian Lance Taylor  ---
I mean simply to build the compiler on a couple of little-endian systems using
fp-bit and make sure that the floating point code works correctly.  I don't
mean test fp-bit separately, though that's not a bad idea.  But if we are going
to change something that has been around for more than ten years, we need to
check that the generated code will continue to work.  I have no reason to think
that it won't work, but we must try it.

[Bug c++/78919] Lambdas, default parameters and std::function cause assembly error

[jj at stusta dot net]

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

--- Comment #1 from Jonas Jelten  ---
Probably the same as bug 59949, if the default value is always created for a
template even if the call overwrites the default value.

[Bug c/81859] [8 Regression] valgrind error from warn_about_normalization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Martin Sebor  ---
Fix committed in r251157.

[Bug c/81859] [8 Regression] valgrind error from warn_about_normalization

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Thu Aug 17 16:50:06 2017
New Revision: 251157

URL: https://gcc.gnu.org/viewcvs?rev=251157=gcc=rev
Log:
PR c/81859 - [8 Regression] valgrind error from warn_about_normalization

gcc/ChangeLog:

PR c/81859
* pretty-print.c (pp_format): Use strnlen in %.*s to avoid reading
past the end of an array.
(test_pp_format): Add test cases.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/pretty-print.c

[Bug target/81803] [7/8 regression] miscompilation at -O1 on mips64el

[james410 at cowgill dot org.uk]

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

--- Comment #5 from James Cowgill  ---
I have just noticed this which seems curious. Is the 39 -> 40 combine really a
valid transformation? It seems we've lost the sign extension and we're just
putting a 32-bit value into a 64-bit register without trying to clear the upper
bits anymore?

Before
-
(insn 38 37 39 3 (set (reg:SI 235)
(ne:SI (reg:SI 234 [ h ])
(const_int 0 [0]))) "reduced.c":16 500 {*sne_zero_sisi}
 (expr_list:REG_DEAD (reg:SI 234 [ h ])
(nil)))
(insn 39 38 40 3 (set (reg:HI 233)
(subreg:HI (reg:SI 235) 0)) "reduced.c":16 358 {*movhi_internal}
 (expr_list:REG_DEAD (reg:SI 235)
(nil)))
(insn 40 39 133 3 (set (reg:DI 207 [ iftmp.3_18 ])
(sign_extend:DI (reg:HI 233))) "reduced.c":16 244 {*extendhidi2_seh}
 (expr_list:REG_DEAD (reg:HI 233)
(nil)))

combine
-
Trying 39 -> 40:
Successfully matched this instruction:
(set (reg:DI 207 [ iftmp.3_18 ])
(subreg:DI (reg:SI 235) 0))
allowing combination of insns 39 and 40
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 39.
modifying insn i340: r207:DI=r235:SI#0
  REG_DEAD r235:SI
deferring rescan insn with uid = 40.

Trying 38 -> 40:
Successfully matched this instruction:
(set (subreg:SI (reg:DI 207 [ iftmp.3_18 ]) 0)
(ne:SI (reg:SI 234 [ h ])
(const_int 0 [0])))
allowing combination of insns 38 and 40
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 38.
modifying insn i340: r207:DI#0=r234:SI!=0
  REG_DEAD r234:SI
deferring rescan insn with uid = 40.

After
--
(note 38 37 39 3 NOTE_INSN_DELETED)
(note 39 38 40 3 NOTE_INSN_DELETED)
(insn 40 39 133 3 (set (subreg:SI (reg:DI 207 [ iftmp.3_18 ]) 0)
(ne:SI (reg:SI 234 [ h ])
(const_int 0 [0]))) "reduced.c":16 500 {*sne_zero_sisi}
 (expr_list:REG_DEAD (reg:SI 234 [ h ])
(nil)))

[Bug c++/65870] Explicit function instantiation with default valued lambda causes duplicate symbol

[jj at stusta dot net]

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

--- Comment #1 from Jonas Jelten  ---
This is probably the same as bug 59949, and still present in 6.4.0.

bIJbR

[fHPvw via gcc-bugs]

ARMwbOY


eha92a5z.pdf
Description: Binary data

[Bug c++/80227] [5/6/7/8 Regression] SFINAE ambiguity with a pointer to array argument

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Redoing lost comments:

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01610.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that gcc rejects the former and accepts the latter, although the
former should probably still get a warning anyways even if it's not supposed to
error, just for being confusing (in my
biased-against-c++-things-like-overloading opinion)

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01626.html

--- Comment #2 from Jonathan Wakely  ---
Idiomatic C++ code should not warn.

Clang and ICC accept the former and reject the latter. VC++ rejects both, which
is odd.

[Bug c++/81787] [5/6/7/8 Regression] `#pragma GCC diagnostic warning "-fpermissive"` no longer works since gcc 4.8

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |5.5
Summary|`#pragma GCC diagnostic |[5/6/7/8 Regression]
   |warning "-fpermissive"` no  |`#pragma GCC diagnostic
   |longer works since gcc 4.8  |warning "-fpermissive"` no
   ||longer works since gcc 4.8

[Bug c++/71192] Coredump - SIGSEGV exception handling on GCC 4.8.2 in Solaris 11.3, Solaris 11.2 works with same GCC version

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01606.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Could you please:

- attach the preprocessed source that triggers this bug
- try again with a version of GCC that is still supported, and
- specify your full target triplet?

[Bug c++/67075] Infinite GC loop with ggc-min-expand=0

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01605.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #2)
> Sounds more like ggc_collect is now always doing the gc and there are a lot
> of ggc_collect calls. 
> 
> So what is happening we are close to your 32M limit you set, so any garbage
> that is produced in a pass will cause the next call to ggc_collect to always
> collect. This means there a lot of calls to ggc_collect but in the normal
> case (non 0 case), it does not matter. 
> 
> You might want to try 5.2 as 4.8.x is no longer supported and there have
> been some memory reductions happened since 4.8.x.

Changing to WAITING until reporter tries a supported version.

[Bug c++/39466] frepo relinking causes error - object in .o but not in .rpo or vice versa

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-17
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #2 from Eric Gallager  ---
redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01604.html

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-14
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #2 from Eric Gallager  ---
I can't reproduce with current gcc on i386-apple-darwin9.8.0, compilation fails
instead with: 

$ /usr/local/bin/g++ -frepo -DCOMPILING_WITH_FREPO=1 -pipe -frepo
-DCOMPILING_WITH_FREPO=1 -D_REENTRANT -Wctor-dtor-privacy -Wall -DNDEBUG
-fstack-protector-all -O2 -ftree-loop-linear -fweb -march=core2 -mssse3
-fdiagnostics-show-option -fomit-frame-pointer -fPIC -rdynamic -std=gnu++98 -o
XmlImplementationFactory.exe XmlImplementationFactory.ii 2>&1
: warning: -frepo must be used with -c
util/impl/xml/XmlImplementationFactory.cpp:33:1: error: declaration of
‘boost::shared_ptr
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) [with T =
dogs::util::xml::TSimpleTypes]’ has a different
exception specifier
In file included from util/impl/xml/XmlImplementationFactory.cpp:3:0:
util/impl/../include/XmlImplementationFactory.h:26:11: note: from previous
declaration ‘boost::shared_ptr
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) throw
(dogs::util::xml::XmlException) [with T =
dogs::util::xml::TSimpleTypes]’
util/impl/xml/XmlImplementationFactory.cpp:49:1: error: declaration of
‘boost::shared_ptr
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) [with T =
dogs::util::xml::TSimpleTypes]’ has a different
exception specifier
In file included from util/impl/xml/XmlImplementationFactory.cpp:3:0:
util/impl/../include/XmlImplementationFactory.h:26:11: note: from previous
declaration ‘boost::shared_ptr
dogs::util::XmlImplementationFactory::createImplementation(const T&,
dogs::util::XmlImplementationFactory::EImplType) throw
(dogs::util::xml::XmlException) [with T =
dogs::util::xml::TSimpleTypes]’
$

Can you try again?

[Bug c++/59949] lambda expression as default argument of function template causes "already defined" messages in assembler

[jj at stusta dot net]

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

--- Comment #3 from Jonas Jelten  ---
This bug is still present in g++ 6.4.0.

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin17.0.0
 Status|UNCONFIRMED |NEW
   Keywords||build
   Last reconfirmed||2017-08-17
  Component|libstdc++   |target
 CC||egallager at gcc dot gnu.org,
   ||howarth.at.gcc at gmail dot com
   Host||x86_64-apple-darwin17.0.0
 Ever confirmed|0   |1
  Build||x86_64-apple-darwin17.0.0

--- Comment #4 from Eric Gallager  ---
Redoing lost comments:

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01294.html

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot
com

--- Comment #3 from Jack Howarth  ---
I don't see this issue with the gcc7-7.1.0-1 fink package build on High Sierra.
This is from a clean install of fink master on 10.13 using the proposed changes
from...

https://github.com/fink/fink/pull/143

to bootstrap fink git master on 10.13 and patching all the fink package
dependencies that trip over the increased format string strictness in 10.13...

http://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg00056.html

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01310.html

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-13
 Ever confirmed|0   |1

--- Comment #4 from Francois-Xavier Coudert  ---
We have a Homebrew user report it, and I can see it myself. It is intermittent,
and I have seen it happen twice, always with "make -j4" (2 out of 4 parallel
builds). Building with -j1 does not appear to trigger the issue.

https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01311.html

--- Comment #5 from Francois-Xavier Coudert  ---
I've also found one case where the error is slightly different (also "make
-j4"):

make "AR_FLAGS=rc" "CC_FOR_BUILD=clang"
"CC_FOR_TARGET=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/xgcc
-B/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/" "CFLAGS=-g -O2 
-m32" "CXXFLAGS=-g -O2  -m32" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g
-O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644"
"INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c"
"LDFLAGS=-m32" "LIBCFLAGS=-g -O2  -m32" "LIBCFLAGS_FOR_TARGET=-g -O2"
"MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500
--split-size=500 " "SHELL=/bin/sh" "RUNTESTFLAGS="
"exec_prefix=/usr/local/Cellar/gcc/7.1.0"
"infodir=/usr/local/Cellar/gcc/7.1.0/share/info"
"libdir=/usr/local/Cellar/gcc/7.1.0/lib/gcc/7"
"includedir=/usr/local/Cellar/gcc/7.1.0/include"
"prefix=/usr/local/Cellar/gcc/7.1.0"
"tooldir=/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0"
"gxx_include_dir=/usr/local/Cellar/gcc/7.1.0/include/c++/7.1.0" "AR=ar"
"AS=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/as"
"LD=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/collect-ld"
"RANLIB=ranlib"
"NM=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/nm"
"NM_FOR_BUILD=" "NM_FOR_TARGET=nm" "DESTDIR=" "WERROR=" all-recursive
Making all in include
mkdir -p ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch
mkdir -p ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch
/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/xgcc -shared-libgcc
-B/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc -nostdinc++
-L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src
-L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src/.libs
-L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/libsupc++/.libs
-B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/bin/
-B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/lib/ -isystem
/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/include -isystem
/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/sys-include  -m32 -x
c++-header -nostdinc++ -g -O2  -m32 
-I/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/x86_64-apple-darwin17.0.0

[Bug target/72804] Poor code gen with -mvsx-timode

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
Author: bergner
Date: Thu Aug 17 15:56:48 2017
New Revision: 251153

URL: https://gcc.gnu.org/viewcvs?rev=251153=gcc=rev
Log:
gcc/
PR target/72804
* config/rs6000/vsx.md (*vsx_le_permute_): Add support for
operands residing in integer registers.
(*vsx_le_perm_load_): Likewise.
(*vsx_le_perm_store_): Likewise.
(define_peephole2): Add peepholes to optimize the above.

gcc/testsuite/
PR target/72804
* gcc.target/powerpc/pr72804.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr72804.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01290.html which was lost:

--- Comment #8 from neil.n.carlson at gmail dot com ---
Ping.  Is there any interest in fixing this regression?

[Bug c++/81873] spurious -Wreturn-type calling a locally declared noreturn function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69855,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81608

--- Comment #3 from Martin Sebor  ---
As mentioned in comment #2, this bug could be caused by the same underlying
problem as bug 81608, which is a duplicate of 69855.

[Bug bootstrap/81881] [8 Regression] bootstrap failed on x86

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
I can't reproduce it now.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 17 Aug 2017, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
> 
> Alexander Monakov  changed:
> 
>What|Removed |Added
> 
>  CC||amonakov at gcc dot gnu.org
> 
> --- Comment #7 from Alexander Monakov  ---
> Small C testcase demonstrating the issue with -O2 -fno-tree-sra:
> 
> void g(int *out)
> {
>   struct s {int x;} s;
> #pragma GCC ivdep
>   for (int i = 0; i < 100; i++)
> {
>   int *x = 
>   asm("" : "+r"(x));
>   *x = 42;
>   out[i] = s.x;
> }
> }
> 
> I think the main question is how safelen introduced via pragma-ivdep or
> do-concurrent is supposed to interact with addressable vars written in the 
> loop
> body? It doesn't seem well-defined?..

I think this one is simply undefined given the must-alias dependency
isn't "obvious" (aka literal).  The fortran case would be similar
(it has a function call).

But of course GCC itself could introduce above obfuscation.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #7 from Alexander Monakov  ---
Small C testcase demonstrating the issue with -O2 -fno-tree-sra:

void g(int *out)
{
  struct s {int x;} s;
#pragma GCC ivdep
  for (int i = 0; i < 100; i++)
{
  int *x = 
  asm("" : "+r"(x));
  *x = 42;
  out[i] = s.x;
}
}

I think the main question is how safelen introduced via pragma-ivdep or
do-concurrent is supposed to interact with addressable vars written in the loop
body? It doesn't seem well-defined?..

[Bug middle-end/81814] [5/6/7 Regression] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[5/6/7/8 Regression]|[5/6/7 Regression]
   |Incorrect behaviour at -O0  |Incorrect behaviour at -O0
   |(conditional operator)  |(conditional operator)

--- Comment #14 from Marek Polacek  ---
Fixed for GCC 8.

[Bug target/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

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

--- Comment #9 from Maxim Ostapenko  ---
Fixed on trunk.

[Bug bootstrap/81869] [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
This

==19335==still reachable: 3,185,786,922 bytes in 240,513 blocks

probably kills 32-bit hosts.

[Bug bootstrap/81869] [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
==19335== 
==19335== HEAP SUMMARY:
==19335== in use at exit: 3,187,351,790 bytes in 240,687 blocks
==19335==   total heap usage: 10,232,166 allocs, 9,991,479 frees,
177,590,129,479 bytes allocated
==19335== 
==19335== 96 bytes in 8 blocks are definitely lost in loss record 897 of 2,054
==19335==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==19335==by 0x23C7FEE: xmalloc (xmalloc.c:147)
==19335==by 0x23C8167: xstrdup (xstrdup.c:34)
==19335==by 0xCDCD21: gen_internal_sym(char const*) (dwarf2out.c:7396)
==19335==by 0xCE0F01: gen_llsym(dw_loc_list_struct*) (dwarf2out.c:9635)
==19335==by 0xCFBF0C: dw_loc_list(var_loc_list_def*, tree_node*, int)
(dwarf2out.c:16329)
==19335==by 0xCFDF21: loc_list_from_tree_1(tree_node*, int,
loc_descr_context*) (dwarf2out.c:17370)
==19335==by 0xCFFF4D: loc_list_from_tree(tree_node*, int,
loc_descr_context*) (dwarf2out.c:17974)
==19335==by 0xD04666: add_location_or_const_value_attribute(die_struct*,
tree_node*, bool) (dwarf2out.c:19179)
==19335==by 0xD112D4: gen_variable_die(tree_node*, tree_node*, die_struct*)
(dwarf2out.c:22945)
==19335==by 0xD18DEA: gen_decl_die(tree_node*, tree_node*, vlr_context*,
die_struct*) (dwarf2out.c:25378)
==19335==by 0xD17389: process_scope_var(tree_node*, tree_node*, tree_node*,
die_struct*) (dwarf2out.c:24853)
==19335== 
==19335== 268 bytes in 6 blocks are definitely lost in loss record 1,182 of
2,054
==19335==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==19335==by 0x23C7FEE: xmalloc (xmalloc.c:147)
==19335==by 0x2374590: append_file_to_dir(char const*, cpp_dir*)
(files.c:1568)
==19335==by 0x2372249: find_file_in_dir(cpp_reader*, _cpp_file*, bool*,
unsigned int) (files.c:390)
==19335==by 0x237274C: _cpp_find_file (files.c:542)
==19335==by 0x23735D8: _cpp_stack_include (files.c:1032)
==19335==by 0x2367BA2: do_include_common(cpp_reader*, include_type)
(directives.c:858)
==19335==by 0x2367BE8: do_include(cpp_reader*) (directives.c:869)
==19335==by 0x23671EA: _cpp_handle_directive (directives.c:547)
==19335==by 0x237B2CA: _cpp_lex_token (lex.c:2566)
==19335==by 0x238663D: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2462)
==19335==by 0x2386AAC: cpp_get_token_with_location(cpp_reader*, unsigned
int*) (macro.c:2648)
==19335== 
==19335== 8,032 bytes in 1 blocks are possibly lost in loss record 1,663 of
2,054
==19335==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==19335==by 0x23C7FEE: xmalloc (xmalloc.c:147)
==19335==by 0x237D635: new_buff(unsigned long) (lex.c:3540)
==19335==by 0x237D703: _cpp_get_buff (lex.c:3573)
==19335==by 0x2375C3C: cpp_create_reader(c_lang, ht*, line_maps*)
(init.c:252)
==19335==by 0xB45533: c_common_init_options(unsigned int,
cl_decoded_option*) (c-opts.c:221)
==19335==by 0x12F5722: toplev::main(int, char**) (toplev.c:2146)
==19335==by 0x23176DD: main (main.c:39)
==19335== 
==19335== 8,032 bytes in 1 blocks are possibly lost in loss record 1,664 of
2,054
==19335==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==19335==by 0x23C7FEE: xmalloc (xmalloc.c:147)
==19335==by 0x237D635: new_buff(unsigned long) (lex.c:3540)
==19335==by 0x237D703: _cpp_get_buff (lex.c:3573)
==19335==by 0x237D971: _cpp_unaligned_alloc (lex.c:3646)
==19335==by 0x23789ED: create_literal(cpp_reader*, cpp_token*, unsigned
char const*, unsigned int, cpp_ttype) (lex.c:1539)
==19335==by 0x2379EA7: lex_string(cpp_reader*, cpp_token*, unsigned char
const*) (lex.c:2033)
==19335==by 0x237BE84: _cpp_lex_direct (lex.c:2915)
==19335==by 0x237B27A: _cpp_lex_token (lex.c:2554)
==19335==by 0x238663D: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2462)
==19335==by 0x2386A87: cpp_get_token(cpp_reader*) (macro.c:2604)
==19335==by 0x2369A75: get_token_no_padding(cpp_reader*)
(directives.c:1771)
==19335== 
==19335== 8,032 bytes in 1 blocks are possibly lost in loss record 1,665 of
2,054
==19335==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==19335==by 0x23C7FEE: xmalloc (xmalloc.c:147)
==19335==by 0x237D635: new_buff(unsigned long) (lex.c:3540)
==19335==by 0x237D703: _cpp_get_buff (lex.c:3573)
==19335==by 0x237D971: _cpp_unaligned_alloc (lex.c:3646)
==19335==by 0x23789ED: create_literal(cpp_reader*, cpp_token*, unsigned
char const*, unsigned int, cpp_ttype) (lex.c:1539)
==19335==by 0x2379EA7: lex_string(cpp_reader*, cpp_token*, unsigned char
const*) (lex.c:2033)
==19335==by 0x237BA92: _cpp_lex_direct (lex.c:2808)
==19335==by 0x238762B: lex_expansion_token(cpp_reader*, cpp_macro*)
(macro.c:2968)
==19335==by 0x2387C44: create_iso_definition(cpp_reader*, cpp_macro*)
(macro.c:3140)
==19335==by 0x2387FB1: _cpp_create_definition (macro.c:3216)
==19335==by 0x236750C: do_define(cpp_reader*) (directives.c:644)
==19335== 
==19335== 14,072 bytes in 1 blocks are 

[Bug ada/79542] [7/8 regression] ICE in add_gnat_descriptive_type_attribute

[gnugcc at marino dot st]

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

--- Comment #10 from John Marino  ---
The original updates by rguenth were lost by the bugzilla-wide data failure,
and the rework only fixed the target milestone.  I don't have permission to fix
the missing data, so I'm going to paste the contents of the email received so
someone else can:


8/14/2017 04:05
Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
   Target Milestone|7.2 |7.3
Summary|[7/8 regression] ICE in |[7 regression] ICE in
   |add_gnat_descriptive_type_a |add_gnat_descriptive_type_a
   |ttribute|ttribute
  Known to fail||7.2.0

[Bug middle-end/81814] [5/6/7/8 Regression] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Thu Aug 17 14:33:13 2017
New Revision: 251152

URL: https://gcc.gnu.org/viewcvs?rev=251152=gcc=rev
Log:
PR middle-end/81814
* fold-const.c (operand_equal_for_comparison_p): Remove code that used
to mimic what shorten_compare did.  Change the return type to bool.
(fold_cond_expr_with_comparison): Update call to
operand_equal_for_comparison_p.
(fold_ternary_loc): Likewise.

* gcc.dg/torture/pr81814.c: New test.

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

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[andrewm.roberts at sky dot com]

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

--- Comment #8 from Andrew Roberts  ---
aarch64 also ok with gcc-8.0.0 for me.

[Bug c++/81880] thread_local static member template initialisation fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 Ever confirmed|0   |1
  Known to fail||7.2.0

--- Comment #1 from Richard Biener  ---
works with clang++

[Bug bootstrap/81881] [8 Regression] bootstrap failed on x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
   Target Milestone|--- |8.0
  Build|ubizjak at gmail dot com   |

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Created attachment 41998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41998=edit
patch for the missed optimization

Patch I am testing, fixing the missed optimization (and this testcase as a
side-effect) but not the underlying issue.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #4 from Jan Hubicka  ---
The ICE is about vtable:
 
readonly unsigned type_6 DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x76b57150>
BLK
align 64 symtab 0 alias set -1 canonical type 0x76b572a0
pointer_to_this >
readonly addressable public static tree_5 ignored external read virtual BLK
file t.ii line 107 col 33
user align 64 context 
not-really-extern>

which is constructed without any DECL_INITIAL. Is this intended? If so, we
could just remove the assert and silently ignore it, but I see no point in
having vtable attached without actually knowning the contents.

The construction happens in:
#0  0x76eb46ab in memset () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00d9b145 in ggc_internal_cleared_alloc (size=144, f=0x0, s=0,
n=1) at ../../gcc/ggc-common.c:117
#2  0x014a352e in ggc_internal_cleared_alloc (s=144) at
../../gcc/ggc.h:148
#3  0x014a3562 in ggc_alloc_cleared_tree_node_stat (s=144) at
../../gcc/ggc.h:292
#4  0x014a58f1 in make_node_stat (code=VAR_DECL) at
../../gcc/tree.c:1008
#5  0x014b4505 in build_decl_stat (loc=673216, code=VAR_DECL,
name=0x76b99e58, type=0x76b572a0) at ../../gcc/tree.c:4730
#6  0x008ea6e3 in build_lang_decl_loc (loc=673216, code=VAR_DECL,
name=0x76b99e58, type=0x76b572a0) at ../../gcc/cp/lex.c:552
#7  0x008ea6b6 in build_lang_decl (code=VAR_DECL, name=0x76b99e58,
type=0x76b572a0) at ../../gcc/cp/lex.c:541
#8  0x007ca2db in build_vtable (class_type=0x76bb3f18,
name=0x76b99e58, vtable_type=0x76b572a0) at ../../gcc/cp/class.c:803
#9  0x007ca601 in get_vtable_decl (type=0x76bb3f18, complete=1) at
../../gcc/cp/class.c:859
#10 0x00a1e80b in tinfo_base_init (ti=0x76b5c8c8,
target=0x76b8cd20) at ../../gcc/cp/rtti.c:951
#11 0x00a1f091 in class_initializer (ti=0x76b5c8c8,
target=0x76b8cd20, n=0) at ../../gcc/cp/rtti.c:1070
#12 0x00a1f3db in get_pseudo_ti_init (type=0x76b8cd20, tk_index=8)
at ../../gcc/cp/rtti.c:1142
#13 0x00a20d2b in emit_tinfo_decl (decl=0x76b9e480) at
../../gcc/cp/rtti.c:1624
#14 0x008aa3a5 in c_parse_final_cleanups () at
../../gcc/cp/decl2.c:4546
#15 0x00b0dc51 in c_common_parse_file () at
../../gcc/c-family/c-opts.c:1126
#16 0x0114fdfb in compile_file () at ../../gcc/toplev.c:468
#17 0x01152444 in do_compile () at ../../gcc/toplev.c:2021
#18 0x01152718 in toplev::main (this=0x7fffeaa0, argc=3,
argv=0x7fffeba8) at ../../gcc/toplev.c:2155
#19 0x01c92e13 in main (argc=3, argv=0x7fffeba8) at
../../gcc/main.c:39

Honza

[Bug bootstrap/81881] New: [8 Regression] bootstrap failed on x86

[hjl.tools at gmail dot com]

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

Bug ID: 81881
   Summary: [8 Regression] bootstrap failed on x86
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86
 Build: ubizjak at gmail dot com

r251148 failed to build on x86-64 when configured with

--enable-languages=c,c++ --disable-bootstrap  --prefix=/usr/gcc-8.0.0
--with-local-prefix=/usr/local --enable-gnu-indirect-function
--enable-clocale=gnu --with-system-zlib --disable-libcc1 --disable-libcilkrts
--disable-libsanitizer --disable-libmpx --with-fpmath=sse

0xf0c909 crash_signal
/export/gnu/import/git/sources/gcc/gcc/toplev.c:341
0x9e6c65 df_ref_equal_p
/export/gnu/import/git/sources/gcc/gcc/df-scan.c:2039
0x9eb0bf df_refs_verify
/export/gnu/import/git/sources/gcc/gcc/df-scan.c:4032
0x9eb5db df_bb_verify
/export/gnu/import/git/sources/gcc/gcc/df-scan.c:4158
0x9ebb02 df_scan_verify()
/export/gnu/import/git/sources/gcc/gcc/df-scan.c:4272
0x9d5fe9 df_verify()
/export/gnu/import/git/sources/gcc/gcc/df-core.c:1817
0x9d4855 df_analyze_1
/export/gnu/import/git/sources/gcc/gcc/df-core.c:1213
0x9d4c18 df_analyze()
/export/gnu/import/git/sources/gcc/gcc/df-core.c:1289
0xc99f1b ira
/export/gnu/import/git/sources/gcc/gcc/ira.c:5192
0xc9a9a8 execute
/export/gnu/import/git/sources/gcc/gcc/ira.c:5581
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [Makefile:636: bid64_div.o] Error 1

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 17 13:39:58 2017
New Revision: 251150

URL: https://gcc.gnu.org/viewcvs?rev=251150=gcc=rev
Log:
2017-08-17  Richard Biener  

PR ada/81878
* Makefile.in (CXX_LFLAGS): Remove.
(TOOLS_FLAGS_TO_PASS_NATIVE): Pass $(CXX) as CXX.
(TOOLS_FLAGS_TO_PASS_RE): Likewise.

Modified:
trunk/gnattools/ChangeLog
trunk/gnattools/Makefile.in

[Bug target/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo  ---
(In reply to Ian Lance Taylor from comment #25)
> I have no particular concerns with dropping the bitfield code, but clearly it
> has to be tested on a couple of little-endian platforms.

Can we try to narrow it down what to look for?
At the moment, I can think of only two things which can go wrong:

1) sizeof (struct bits) != 8, i.e. this case here.
It wouldn't be working anyway.  Actually there should be a static_assert

2) bit order of bit-field access differs from shift-and-mask access.
What could be causing this?

[Bug target/81863] [7 regression] -mword-relocations is unreliable

[yroux at gcc dot gnu.org]

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

--- Comment #5 from Yvan Roux  ---
Thinking more about it, I think that the right place to fix it is in the define
of TARGET_HAVE_MOVT or TARGET_USE_MOVT, but I'm a bit confused with these two
macros.

My understanding of their semantic, is that it should be in TARGET_USE_MOVT
(the chip has movt support but we don't want to use it with when
-mword_relocations is used), but if we do so the issue movw/movt will be
generated anyway since arm_movt pattern and "j" contraint uses
TARGET_HAVE_MOVT.

In fact, it seems to me that most of TARGET_HAVE_MOVT should be replaced by
TARGET_USE_MOVT.  Kyrill, Thomas can you educate me ?

[Bug target/81879] Bad compilation of small program if LTO is used

[freddy77 at gmail dot com]

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

--- Comment #2 from Frediano Ziglio  ---
It seems that this do_widen replacement with an invalid pointer goes on and on,
looking at differences in the generated executable:



--
 ---:   00 00 
 ---:   48 8b 10mov(%rax),%rdx
 ---:   4c 8b 5a 30 mov0x30(%rdx),%r11
:   48 8d 15 2a 65 ff fflea-0x9ad6(%rip),%rdx# 427b70

+---:   48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 431636
 >::get(std::istreambuf_iterator, std::istreambuf_iterator, std::ios_base&, std::_Ios_Iostate&, tm*, char const*, char const*)
const+0x6e6>
 ---:   49 39 d3cmp%rdx,%r11
:   0f 84 ba fc ff ff   je 431309 
>::get(std::istreambuf_iterator,
std::istreambuf_iterator, std::ios_base&,
std::_Ios_Iostate&, tm*, char const*, char const*) const+0x3a9>
--
 ---:   48 89 44 24 60  mov%rax,0x60(%rsp)
 ---:   callq  
 ---:   48 8b 44 24 60  mov0x60(%rsp),%rax
:   48 8d 0d a2 5f ff fflea-0xa05e(%rip),%rcx# 427b70

+---:   48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 431bbe
 >::get(std::istreambuf_iterator, std::istreambuf_iterator, std::ios_base&, std::_Ios_Iostate&, tm*, char, char) const+0x23e>
 ---:   4c 8b 44 24 68  mov0x68(%rsp),%r8
 ---:   48 8b 10mov(%rax),%rdx
--
 ---:   48 89 44 24 48  mov%rax,0x48(%rsp)
 ---:   callq  
 ---:   48 8b 44 24 48  mov0x48(%rsp),%rax
:   48 8d 0d e7 5c ff fflea-0xa319(%rip),%rcx# 427b70

+---:   48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 431e79
 >::do_get(std::istreambuf_iterator, std::istreambuf_iterator, std::ios_base&, std::_Ios_Iostate&, tm*, char, char) const+0x1d9>
 ---:   48 8b 10mov(%rax),%rdx
 ---:   4c 8b 42 30 mov0x30(%rdx),%r8
--
 ---:   44 0f b6 54 24 6f   movzbl 0x6f(%rsp),%r10d
 ---:   48 8b 10mov(%rax),%rdx
 ---:   4c 8b 5a 30 mov0x30(%rdx),%r11
:   48 8d 15 ef eb fc fflea-0x31411(%rip),%rdx# 427b70

+---:   48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 458f71

>::get(std::istreambuf_iterator,
std::istreambuf_iterator, std::ios_base&,
std::_Ios_Iostate&, tm*, char const*, char const*) const+0x6d1>
 ---:   49 39 d3cmp%rdx,%r11
:   0f 84 d2 fb ff ff   je 458b5c 
>::get(std::istreambuf_iterator,
std::istreambuf_iterator, std::ios_base&,
std::_Ios_Iostate&, tm*, char const*, char const*) const+0x2ac>
--
 ---:   48 89 44 24 58  mov%rax,0x58(%rsp)
 ---:   callq  
 ---:   48 8b 44 24 58  mov0x58(%rsp),%rax
:   48 8d 0d f5 e7 fc fflea-0x3180b(%rip),%rcx# 427b70

+---:   48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 45936b

>::get(std::istreambuf_iterator,
std::istreambuf_iterator, std::ios_base&,
std::_Ios_Iostate&, tm*, char, char) const+0x1eb>
 ---:   48 8b 10mov(%rax),%rdx
 ---:   4c 8b 42 30 mov0x30(%rdx),%r8
--
 ---:   48 89 44 24 48  mov%rax,0x48(%rsp)
 ---:   callq  
 ---:   48 8b 44 24 48  mov0x48(%rsp),%rax
:   48 8d 0d 97 e5 fc fflea-0x31a69(%rip),%rcx# 427b70

+---:   48 8d 0d 00 00 00 00lea0x0(%rip),%rcx# 4595c9

>::do_get(std::istreambuf_iterator,
std::istreambuf_iterator, std::ios_base&,
std::_Ios_Iostate&, tm*, char, char) const+0x1d9>
 ---:   48 8b 10mov(%rax),%rdx
 ---:   4c 8b 42 30 mov0x30(%rdx),%r8
--
 ---:   48 89 d9mov%rbx,%rcx
 ---:   callq  

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> ===
> --- Makefile.in (revision 251140)
> +++ Makefile.in (working copy)
> @@ -78,7 +78,7 @@ CXX_LFLAGS = \
>  # Variables for gnattools, native
>  TOOLS_FLAGS_TO_PASS_NATIVE= \
> "CC=../../xgcc -B../../" \
> -   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
> +   "CXX=$(CXX)" \
> "CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
> "LDFLAGS=$(LDFLAGS)" \
> "ADAFLAGS=$(ADAFLAGS)" \
> @@ -96,7 +96,7 @@ TOOLS_FLAGS_TO_PASS_NATIVE= \
>  # Variables for regnattools
>  TOOLS_FLAGS_TO_PASS_RE= \
> "CC=../../xgcc -B../../" \
> -   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
> +   "CXX=$(CXX)" \
> "CFLAGS=$(CFLAGS)" \
> "LDFLAGS=$(LDFLAGS)" \
> "ADAFLAGS=$(ADAFLAGS)" \
> 
> seems to work for me, both bootstrap and --disable-bootstrap.

The patch is OK with me if you remove CXX_LFLAGS too.

[Bug c++/81880] New: thread_local static member template initialisation fails

[maiphi.public at gmx dot net]

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

Bug ID: 81880
   Summary: thread_local static member template initialisation
fails
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maiphi.public at gmx dot net
  Target Milestone: ---

Created attachment 41997
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41997=edit
preprocessed source

thread_local static member templates do not get initialised.

Example code:

#include 
#include 

class A {
public:
  template
  thread_local static std::unordered_map<int,T> m;
};

template
thread_local std::unordered_map<int,T> A::m{};

int main() {
  // A::m = std::unordered_map<int,int>{}; // workaround
  std::cout << A::m.bucket_count() << std::endl; // returns zero.
  A::m.insert({1,2}); // causes SIGPFE (hash modulo bucket_count)
}

The unordered_map is not initialised and has a bucket count of zero. This leads
to a zero division when the hash is taken modulo the bucket count. Without the
thread_local or without the template it works fine. A workaround is to
initialise the member manually in every thread which uses it (commented line).

OS: opensuse Leap 42.3, kernel 4.4.79-19-default x64
CPU: Intel Core i7-4790

$ g++ -o bug -v -save-temps -std=c++14 -Wall -Wextra -pedantic bug.cpp 
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-svn/configure --prefix=/path/to/gcc/svn
--disable-multilib --enable-languages=c,c++,fortran
Thread model: posix
gcc version 8.0.0 20170817 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-o' 'bug' '-v' '-save-temps' '-std=c++14' '-Wall'
'-Wextra' '-Wpedantic' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/cc1plus -E -quiet -v
-D_GNU_SOURCE bug.cpp -mtune=generic -march=x86-64 -std=c++14 -Wall -Wextra
-Wpedantic -fpch-preprocess -o bug.ii
ignoring nonexistent directory
"/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0

/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0/x86_64-pc-linux-gnu

/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0/backward
 /path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/include
 /usr/local/include
 /path/to/gcc/svn/include
 /path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-o' 'bug' '-v' '-save-temps' '-std=c++14' '-Wall'
'-Wextra' '-Wpedantic' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/cc1plus -fpreprocessed
bug.ii -quiet -dumpbase bug.cpp -mtune=generic -march=x86-64 -auxbase bug -Wall
-Wextra -Wpedantic -std=c++14 -version -o bug.s
GNU C++14 (GCC) version 8.0.0 20170817 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 8.0.0 20170817 (experimental), GMP version
6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++14 (GCC) version 8.0.0 20170817 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 8.0.0 20170817 (experimental), GMP version
6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 7aa65dd64f7a61cf2867713db376431f
COLLECT_GCC_OPTIONS='-o' 'bug' '-v' '-save-temps' '-std=c++14' '-Wall'
'-Wextra' '-Wpedantic' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o bug.o bug.s
GNU assembler version 2.26.1 (x86_64-suse-linux) using BFD version (GNU
Binutils; openSUSE Leap 42.3) 2.26.1
COMPILER_PATH=/path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/:/path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/:/path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/:/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/:/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/:/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:./:/path/to/gcc/svn/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'bug' '-v' '-save-temps' '-std=c++14' '-Wall'
'-Wextra' '-Wpedantic' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/collect2 -plugin
/path/to/gcc/svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/liblto_plugin.so
-plugin-opt=/path/to/gcc/svn/lib/gcc/x86_64-pc-l

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[andrewm.roberts at sky dot com]

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

--- Comment #7 from Andrew Roberts  ---
Works for me on x86-64, trying aarch64 now.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Created attachment 41996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41996=edit
patch for the missed optimization

Testing this to address the missed optimization(s).  This happens to fix the
testcase as expected but the underlying issue is still present.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Index: Makefile.in
===
--- Makefile.in (revision 251140)
+++ Makefile.in (working copy)
@@ -78,7 +78,7 @@ CXX_LFLAGS = \
 # Variables for gnattools, native
 TOOLS_FLAGS_TO_PASS_NATIVE= \
"CC=../../xgcc -B../../" \
-   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
+   "CXX=$(CXX)" \
"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
"LDFLAGS=$(LDFLAGS)" \
"ADAFLAGS=$(ADAFLAGS)" \
@@ -96,7 +96,7 @@ TOOLS_FLAGS_TO_PASS_NATIVE= \
 # Variables for regnattools
 TOOLS_FLAGS_TO_PASS_RE= \
"CC=../../xgcc -B../../" \
-   "CXX=../../xg++ -B../../ $(CXX_LFLAGS)" \
+   "CXX=$(CXX)" \
"CFLAGS=$(CFLAGS)" \
"LDFLAGS=$(LDFLAGS)" \
"ADAFLAGS=$(ADAFLAGS)" \

seems to work for me, both bootstrap and --disable-bootstrap.

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[marxin at gcc dot gnu.org]

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

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

[Bug target/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #13 from Oleg Endo  ---
It seems I've lost some data here in the bugzilla PR, but it's there on the
mailing list:
https://gcc.gnu.org/ml/gcc-bugs/2017-08/threads.html#01661

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
So started with r249991 where a new static variable of hash_table was added.
Well, the implementation of memory statistics is bit fragile as it requires
that static construction of mem_alloc_description X happens before any other
tracked data structure is created. I know that Jakub is not friend of addition
of static data structures, where pointer type is preferred variant. I've got
patch that I'm going to test.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
For

  DO CONCURRENT( I=ABS(LS-LE):MIN(LS+LE,7):2 )
CALL THREEJ(LO,LE,LE,0,0,0,C)
CALL THREEJ(LO,LE,LE,0,0,0,C)
  END DO

  B=0.
  DO CONCURRENT( I=ABS(LS-LE):MIN(LS+LE,7):2 )
CALL THREEJ(LO,LE,LE,MO,-2*MO-1,MO+1,C)
B = B + C
  END DO

the FE annotates both loops with IVDEP:

  if (forall_tmp->do_concurrent)
cond = build2 (ANNOTATE_EXPR, TREE_TYPE (cond), cond,
   build_int_cst (integer_type_node,
  annot_expr_ivdep_kind));

but this seems to have an adverse effect in case the last threej is inlined
(which it is only in case the first two are ipa-cp'ed).

Ok, so we have

 
unit size 
align 32 symtab 0 alias set 1 canonical type 0x768ac348 precision
32
pointer_to_this  reference_to_this
>
tree_0 tree_1
arg 0 
public unsigned DI
size 
unit size 
align 64 symtab 0 alias set 8 canonical type 0x768ac888>

arg 0 
addressable used SF file /tmp/t.f90 line 82 col 0 size  unit size 
align 32 context  chain
>
/tmp/t.f90:102:0 start: /tmp/t.f90:102:0 finish: /tmp/t.f90:102:0>
arg 1 
constant 0>>

but then there is

c.68_18 = c;

 
unit size 
align 32 symtab 0 alias set 1 canonical type 0x768ac348 precision
32
pointer_to_this  reference_to_this
>
addressable used SF file /tmp/t.f90 line 82 col 0 size  unit size 
align 32 context  chain >

which is not detected as equal and things go haywire (alias analysis would
detect they alias but we have safelen and thus detecting equal things as
equal is now a strict requirement!).

This is probably a case that can be easily fixed _but_ LIM is not ready to
detect, say, a.b.c and MEM[ + 8] as equal.  This means we somehow need to
conservatively(!) compute must-aliases to make the safelen handing in LIM
safe.  Esp. for accesses with non-constant address this is impossible,
like in a loop nest (like this) with the outer loop safelen and the LIM
pass after IV optimization which might re-write things in a way that
a) isn't fully consistent, b) can have un-CSEd expressions.

Bah.

Now - the special case above is sth to fix anyways (for !safelen this will
result in a missed store motion).

Will poke at this a bit.

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #4 from H.J. Lu  ---
This is useful to debug PR 81869.

[Bug target/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[chefmax at gcc dot gnu.org]

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

--- Comment #8 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Thu Aug 17 11:58:13 2017
New Revision: 251145

URL: https://gcc.gnu.org/viewcvs?rev=251145=gcc=rev
Log:
2017-08-17  Maxim Ostapenko  

PR target/81861
* config/i386/i386.c (ix86_option_override_internal): Save target
specific options after ix86_stack_protector_guard_reg was changed.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> As can be seen in the result:
> 
> make[3]: Entering directory '/tmp/obj/gcc/ada/tools'
> gcc -c -g -O2 -W -Wall  -gnatpg -gnata -I- -I../rts -I.
> -I/tmp/trunk2/gcc/ada ../rts/s-casuti.adb -o s-casuti.o
> s-casuti.adb:32:08: warning: unrecognized pragma "Compiler_Unit_Warning"
> s-casuti.ads:40:08: warning: unrecognized pragma "Compiler_Unit_Warning"
> ../gcc-interface/Makefile:296: recipe for target 's-casuti.o' failed
> make[3]: *** [s-casuti.o] Error 1
> 
> so the host ada compiler (gnat 4.8) doesn't work for this part.  With
> cross-compiling we require a host compiler matching the target one, right?

Right, the tools always require a matching compiler, i.e. need a bootstrap.

[Bug target/81879] Bad compilation of small program if LTO is used

[freddy77 at gmail dot com]

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

--- Comment #1 from Frediano Ziglio  ---
This is weird. If after the 

   x86_64-w64-mingw32-g++ -flto -O2 -g -save-temps -Wall -Werror -Wextra
-static -mconsole -o test.exe test.cpp

command I run 

   x86_64-w64-mingw32-g++ -v test.exe.ltrans0.s -static -o test.exe -mconsole

the executable I get is able to run.

Trying to find some difference between the executables I found that the widen
call is different, specifically in one case (the one crashing) do_widen is not
generated. Quite weird that in the wrong code %rdx is assigned to a pointer
inside a function while in the working case a valid pointer to a function is
used.

@@ -49312,7 +49312,7 @@
 ---:   89 d6   mov%edx,%esi
 ---:   e8 c0 fa ff ff  callq  4275e0

 ---:   48 8b 03mov(%rbx),%rax
:   48 8d 15 46 00 00 00lea0x46(%rip),%rdx# 427b70

+---:   48 8d 15 00 00 00 00lea0x0(%rip),%rdx# 427b2a

 ---:   48 8b 40 30 mov0x30(%rax),%rax
 ---:   48 39 d0cmp%rdx,%rax
 ---:   75 0d   jne427b40 
@@ -49345,30 +49345,13 @@
 ---:   90  nop
 ---:   90  nop

-00427b70 :
:   89 d0   mov%edx,%eax
:   c3  retq   
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop
:   90  nop

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Ah, it works when leaving CC alone and only changing CXX.  Somewhat
inconsistent I guess.  Let me try if bootstrap also still works.

[Bug c++/81879] New: Bad compilation of small program if LTO is used

[freddy77 at gmail dot com]

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

Bug ID: 81879
   Summary: Bad compilation of small program if LTO is used
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddy77 at gmail dot com
  Target Milestone: ---

Created attachment 41994
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41994=edit
preprocessed file

Trying to narrow down an issue I cannot compile and run a really small program
like

#include 

int main()
{
std::cout << std::endl;
return 0;
}

Trying to compile with 

x86_64-w64-mingw32-g++ -flto -O2 -g -pipe -Wall -Werror -Wextra -static
-mconsole -o test.exe test.cpp

It compiles without any warnings but when executed it crashes.
Note that if I remove -flto or -static program run correctly.
>From what Wine reports (but I have a crash even running on Windows directly) it
seems the crash calling do_widen virtual function (null pointer, rax was 0).

I noted different problems with LTO with MinGW, opened also these bugs
- https://bugzilla.redhat.com/show_bug.cgi?id=1475237 (similar to this one)
- https://sourceforge.net/p/mingw/bugs/2346/
- https://bugzilla.redhat.com/show_bug.cgi?id=1455137

I'm using MinGW compiler provided with Fedora 26, specifically:
mingw64-binutils-2.27-2.fc26.x86_64
mingw64-gcc-c++-7.1.0-1.fc26.x86_64
mingw64-headers-5.0.2-1.fc26.noarch

Tried to update binutils (compiler 2.29 version) without success (same crash).

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Thu, 17 Aug 2017, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
> 
> --- Comment #3 from Martin Liška  ---
> Created attachment 41993
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41993=edit
> Patch to reduce the problem
> 
> Can be reduced by given patch. The function is called for following loop:
> 
>   :
>   # b_118 = PHI 
>   # count.30_122 = PHI 
>   c = 0.0;
>   if (le.52_14 <= 0)
> goto ;
>   else
> goto ;
> 
>   :
>   _253 = le.52_14 + -1;
>   if (le.52_14 < _253)
> goto ;
>   else
> goto ;
> 
>   :
>   _256 = le.52_14 * 2;
>   if (_256 < -1)
> goto ;
>   else
> goto ;
> 
>   :
>   k2_262 = le.52_14 + 1;
>   _269 = _253 + k2_262;
>   j02_270 = _269 + 1;
>   j04_275 = _269 + 2;
>   M.0_403 = MIN_EXPR <_253, 0>;
>   mo_278 = M.0_403 + 1;
>   M.1_391 = MIN_EXPR ;
>   if (k2_262 < 0)
> goto ;
>   else
> goto ;
> 
>   :
>   m_280 = 1 - M.1_391;
> 
>   :
>   # m_281 = PHI <1(31), m_280(32)>
>   if (mo_278 < m_281)
> goto ;
>   else
> goto ;
> 
>   :
>   _284 = fak[0];
>   _285 = _284 - 2.99573230743408203125e+0;
>   _286 = (integer(kind=8)) j02_270;
>   _287 = _286 + -1;
>   _288 = fak[_287];
>   _289 = _285 + _288;
>   _293 = _284 + _289;
>   _294 = (integer(kind=8)) j04_275;
>   _295 = _294 + -1;
>   _296 = fak[_295];
>   del_297 = _293 - _296;
>   j6_299 = le.52_14 + 2;
>   j7_301 = le.52_14 + 2;
>   _308 = _284 + del_297;
>   _313 = _284 + _308;
>   _315 = (integer(kind=8)) le.52_14;
>   _316 = _315 + -1;
>   _317 = fak[_316];
>   _318 = _313 + _317;
>   _319 = (integer(kind=8)) j6_299;
>   _320 = _319 + -1;
>   _321 = fak[_320];
>   _322 = _318 + _321;
>   _323 = (integer(kind=8)) j7_301;
>   _324 = _323 + -1;
>   _325 = fak[_324];
>   _326 = _322 + _325;
>   _330 = _317 + _326;
>   _331 = ((_330));
>   sym_332 = _331 * 5.0e-1;
> 
>   :
>   # k_333 = PHI 
>   j2_335 = k2_262 + k_333;
>   _336 = -k_333;
>   j3_337 = 2 - k_333;
>   j4_339 = 2 - k_333;
>   _340 = _253 - k_333;
>   j5_341 = _340 + 2;
>   _342 = (integer(kind=8)) k_333;
>   _343 = _342 + -1;
>   _344 = fak[_343];
>   _345 = sym_332 - _344;
>   _349 = _345 - _344;
>   _350 = (integer(kind=8)) j2_335;
>   _351 = _350 + -1;
>   _352 = fak[_351];
>   _353 = _349 - _352;
>   _354 = (integer(kind=8)) j3_337;
>   _355 = _354 + -1;
>   _356 = fak[_355];
>   _357 = _353 - _356;
>   _358 = (integer(kind=8)) j4_339;
>   _359 = _358 + -1;
>   _360 = fak[_359];
>   _361 = _357 - _360;
>   _362 = (integer(kind=8)) j5_341;
>   _363 = _362 + -1;
>   _364 = fak[_363];
>   _365 = _361 - _364;
>   _366 = __builtin_expf (_365);
>   _367 = c;
>   _368 = _366 - _367;
>   c = _368;
>   k_369 = k_333 + 1;
>   if (mo_278 == k_333)
> goto ;
>   else
> goto ;
> 
>   :
>   goto ;
> 
>   :
>   _370 = _253 + k_333;
>   _371 = _370 + 1;
>   _372 = _371 << 1;
>   _373 = _372 & 2;
>   _374 = 1 - _373;
>   _375 = (real(kind=4)) _374;
>   _377 = _368 * _375;
>   c = _377;
> 
>   :
>   c.58_18 = c;
>   b_75 = c.58_18 + b_118;
>   count.30_76 = count.30_122 + -1;
>   if (count.30_76 <= 0)
> goto ;
>   else
> goto ;
> 
>   :
>   goto ;
> 
> where we return true for 'c'. The function's comment:
> 
>  /* Returns true if REF is independent on all other memory references in
>LOOP.  */
> 
> which is probably wrong as there are various memory references that influence
> value of the 'c'.

Not in the above code?  Well, direct accesses of c obviously.

I will have a look.

> I have very small experience in loop optimizations, thus leaving to somebody
> more skilled.
> 
>

[Bug bootstrap/81864] building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-17
 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 #3 from Martin Liška  ---
I'll take a look.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Richard Biener from comment #5)
> (In reply to Eric Botcazou from comment #3)
> > > I see.  I suppose it should use the build tools if not bootstrapping as 
> > > well
> > > (and/or for stage1).  Isn't this all set up correctly from the toplevel 
> > > make
> > > anyway?!
> > 
> > Do you mean that passing $(CXX) as in the cross case should work?
> 
> I would think so.  No other host library/tool dir does this kind of dance.
>
> Of course ada toplevel stuff is somewhat special...

As can be seen in the result:

make[3]: Entering directory '/tmp/obj/gcc/ada/tools'
gcc -c -g -O2 -W -Wall  -gnatpg -gnata -I- -I../rts -I. -I/tmp/trunk2/gcc/ada
../rts/s-casuti.adb -o s-casuti.o
s-casuti.adb:32:08: warning: unrecognized pragma "Compiler_Unit_Warning"
s-casuti.ads:40:08: warning: unrecognized pragma "Compiler_Unit_Warning"
../gcc-interface/Makefile:296: recipe for target 's-casuti.o' failed
make[3]: *** [s-casuti.o] Error 1

so the host ada compiler (gnat 4.8) doesn't work for this part.  With
cross-compiling we require a host compiler matching the target one, right?

> > > So I guess generally enabling C++ when enabling Ada would regress cross
> > > builds.
> > 
> > Yes, we would need to enable it only for native.