[Bug tree-optimization/85582] New: wrong code at -O1 and above on x86_64-linux-gnu in 32-bit mode

[su at cs dot ucdavis.edu]

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

Bug ID: 85582
   Summary: wrong code at -O1 and above on x86_64-linux-gnu in
32-bit mode
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20180501 (experimental) [trunk revision 259787] (GCC) 
$ 
$ gcctk -m32 -O0 small.c; ./a.out
$ 
$ gcctk -m32 -O1 small.c
$ ./a.out
Floating point exception (core dumped)
$ 

-

int a, b, d = 2, e; 
long long c = 1;

int main ()
{
  int g = 6;
 L1:
  e = d;
  if (a)
goto L1;
  g--;
  int i = c >> ~(~e | ~g);
 L2:
  c = (b % c) * i;
  if (!e)
goto L2;
  return 0;
}

[Bug target/81274] x86 optimizer emits unnecessary LEA instruction when using AVX intrinsics

[peter at cordes dot ca]

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

--- Comment #2 from Peter Cordes  ---
The stray LEA bug seems to be fixed in current trunk (9.0.0 20180429), at least
for this testcase.  Gcc's stack-alignment strategy seems to be improved overall
(not copying the return address when not needed), so probably it's really
fixed.

It's still present in 7.3.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[jameskuyper at alumni dot caltech.edu]

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

--- Comment #55 from James Kuyper Jr.  
---
> ou need, at a minimum, to modify "accesses via" to
> "accesses directly via", in order to convey your intended meaning.
(In reply to Davin McCall from comment #54)
> (In reply to James Kuyper Jr. from comment #53)
> > [...] However, because those
> > pointers are passed to f(), which does dereference them, f() does accesses
> > those members, and it does so via the use of the '.' operator in the calling
> > routine. Therefore, you need, at a minimum, to modify "accesses via" to
> > "accesses directly via", in order to convey your intended meaning.
> 
> I thought it was clear that I was referring to access via the union. That is
> certainly what I did mean.

The problem is, you're using a statement that the access must occur via a
union, with the implication that the code in question does not access the
member through the union. The code in the original bug report does in fact
access the members through the union - indirectly, but through the union. It's
not possible to bypass the u.s1 step; the fact that u.s1 is the operand of an &
operator and the resulting pointer value is an argument to a function call, and
that the called function is the one that actually accesses the member through
that pointer, does not change the fact that the access came about as the result
of the use of the '.' operator on a union object. Therefore, if you want your
wording to convey your belief that such indirect use of the member selection
operator is excluded, your wording needs modification to make that clear. Of
course, if so modified, it would be saying something with no actual support in
the C standard.

> > I don't see anything in the standard's wording of 6.5.2.3p6 to justify
> > restricting what it says to direct accesses - it says "it is permitted to
> > inspect", without specifying restrictions on how the inspection may be
> > performed.
> 
> As I have said, it is in a section regarding access and in a paragraph
> discussing "use of unions". While I understand what you are saying, I don't
> feel my own interpretation is really that difficult to fathom, and I'm not
> the only one to take it. See http://archive.is/PnW28 (DR 257).

True, but keep in mind that the committee did not agree with his objections.
The example he was complaining about is still present in the current version of
the standard, without any changes that address the issues he raised (I happen
to agree with him that it would have been better to use a common initial
sequence with a length greater than one member, and to use a member other than
the first one for the example).

> > The words "anywhere that a declaration of the completed type of the union
> > is visible." would become pointless with your interpretation.
> 
> Yes, as I already said.

The standard explicitly says, referring to the same example mentioned in DR
257, that the second code fragment is not valid, but only "because the union
type is not visible within function f", implying that it would be valid if the
declaration of the union type were moved so that it would be visible inside
f(). If it were so moved, it would be essentially equivalent to the code which
was the original defect report. While examples are non-normative, that example
implies that the visibility clause was intended to actually serve a purpose
(and it seems obvious to me that it actually does so).

[Bug fortran/85547] Run-time error: character array constructor

[w6ws at earthlink dot net]

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

--- Comment #5 from Walter Spector  ---
Turns out my third case, in comment #2, is incorrect.  To correct it, line 5
should read:

  path = (/ 'xyz/' /)

With this correction, my current trunk snapshot works ok.  (Doesn't apply to
the first two examples though.)

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[davmac at davmac dot org]

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

--- Comment #54 from Davin McCall  ---
(In reply to James Kuyper Jr. from comment #53)
> [...] However, because those
> pointers are passed to f(), which does dereference them, f() does accesses
> those members, and it does so via the use of the '.' operator in the calling
> routine. Therefore, you need, at a minimum, to modify "accesses via" to
> "accesses directly via", in order to convey your intended meaning.

I thought it was clear that I was referring to access via the union. That is
certainly what I did mean.

> 
> I don't see anything in the standard's wording of 6.5.2.3p6 to justify
> restricting what it says to direct accesses - it says "it is permitted to
> inspect", without specifying restrictions on how the inspection may be
> performed.

As I have said, it is in a section regarding access and in a paragraph
discussing "use of unions". While I understand what you are saying, I don't
feel my own interpretation is really that difficult to fathom, and I'm not the
only one to take it. See http://archive.is/PnW28 (DR 257).

> The words "anywhere that a declaration of the completed type of the union
> is visible." would become pointless with your interpretation.

Yes, as I already said.

[Bug other/69968] RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #4 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523

[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-05/msg1.html

[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Tue May  1 00:10:10 2018
New Revision: 259783

URL: https://gcc.gnu.org/viewcvs?rev=259783=gcc=rev
Log:
Add gcc_rich_location::add_fixit_insert_formatted

This patch adds a support function to class gcc_rich_location
to make it easier for fix-it hints to use idiomatic C/C++
indentation, for use by the patch for PR c++/85523.

gcc/ChangeLog:
PR c++/85523
* gcc-rich-location.c (blank_line_before_p): New function.
(use_new_line): New function.
(gcc_rich_location::add_fixit_insert_formatted): New function.
* gcc-rich-location.h
(gcc_rich_location::add_fixit_insert_formatted): New function.

gcc/testsuite/ChangeLog:
PR c++/85523
* gcc.dg/plugin/diagnostic-test-show-locus-generate-patch.c
(test_add_fixit_insert_formatted_single_line): New function.
(test_add_fixit_insert_formatted_multiline): New function.
Extend expected output of generated patch to include fix-it hints
for these.
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.c: Include
"gcc-rich-location.h".  Add test coverage for
gcc_rich_location::add_fixit_insert_formatted.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcc-rich-location.c
trunk/gcc/gcc-rich-location.h
trunk/gcc/testsuite/ChangeLog
   
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-show-locus-generate-patch.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c

[Bug fortran/85581] New: implied DO not initializing array as expected

[urbanjost at comcast dot net]

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

Bug ID: 85581
   Summary: implied DO not initializing array as expected
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

I expect the two functions to be equivalent, but returnarrB acts like
(char(64+isize),I=1,isize) instead of (char(64+i),I=1,isize) was specified???

program uuidgen
implicit none
character(len=:),allocatable :: methods(:)
   methods=[returnarrA(26),returnarrA(5)]
   write(*,'(*("[",a,"]":,","))')methods
   methods=[returnarrB(26),returnarrB(5)]
   write(*,'(*("[",a,"]":,","))')methods
contains

function returnarrA(isize) result(arr)
integer,intent(in)   :: isize
character(len=1),allocatable :: arr(:)   !<== len=1
   integer   :: i
   arr=[character(len=1) ::(char(64+i),i=1,isize)]
end function returnarrA

function returnarrB(isize) result(arr)
integer,intent(in)   :: isize
character(len=:),allocatable :: arr(:)   !<== len=:
   integer   :: i
   arr=[character(len=1) ::(char(64+i),i=1,isize)]
end function returnarrB

end program uuidgen

Output

  
[A],[B],[C],[D],[E],[F],[G],[H],[I],[J],[K],[L],[M],[N],[O],[P],[Q],[R],[S],[T],[U],[V],[W],[X],[Y],[Z],[A],[B],[C],[D],[E]
  
[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[E],[E],[E],[E],[E]

Expecting returnarrA() and returnarrB() functions to return the same results.
That is, I expect

  
[A],[B],[C],[D],[E],[F],[G],[H],[I],[J],[K],[L],[M],[N],[O],[P],[Q],[R],[S],[T],[U],[V],[W],[X],[Y],[Z],[A],[B],[C],[D],[E]
  
[A],[B],[C],[D],[E],[F],[G],[H],[I],[J],[K],[L],[M],[N],[O],[P],[Q],[R],[S],[T],[U],[V],[W],[X],[Y],[Z],[A],[B],[C],[D],[E]
~

[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores

[law at redhat dot com]

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

Bug 33562 Summary: [6 Regression] aggregate DSE disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33562

   What|Removed |Added

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

[Bug tree-optimization/33562] [6 Regression] aggregate DSE disabled

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #35 from Jeffrey A. Law  ---
We're not going to backport this any of the release branches.

[Bug c++/85580] [8/9 Regression] "conflicting C language linkage declaration" warning for variables with identical names in `extern "C"` functions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85305] Parameter pack expression in lambda capture list fails as part of a fold expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/84701] casting to ( unsigned typeof(variable) ) gives wrong results

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for GCC 9.

[Bug c++/85305] Parameter pack expression in lambda capture list fails as part of a fold expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||9.0

--- Comment #2 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/85305] Parameter pack expression in lambda capture list fails as part of a fold expression

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Mon Apr 30 21:21:25 2018
New Revision: 259779

URL: https://gcc.gnu.org/viewcvs?rev=259779=gcc=rev
Log:
PR c++/85305 - pack in lambda init-capture.

* parser.c (cp_parser_initializer): Add subexpression_p parm; don't
check_for_bare_parameter_packs in a subexpression.
(cp_parser_lambda_introducer): Use it.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/fold-lambda2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/84701] casting to ( unsigned typeof(variable) ) gives wrong results

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon Apr 30 21:21:32 2018
New Revision: 259780

URL: https://gcc.gnu.org/viewcvs?rev=259780=gcc=rev
Log:
PR c++/84701 - unsigned typeof.

* decl.c (grokdeclarator): Overhaul diagnostics for invalid use
of long/short/signed/unsigned.

Added:
trunk/gcc/testsuite/g++.dg/ext/typeof13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/g++.dg/cpp1z/decomp3.C

[Bug c++/85580] [8/9 Regression] "conflicting C language linkage declaration" warning for variables with identical names in `extern "C"` functions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-30
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|"conflicting C language |[8/9 Regression]
   |linkage declaration"|"conflicting C language
   |warning for variables with  |linkage declaration"
   |identical names in `extern  |warning for variables with
   |"C"` functions  |identical names in `extern
   ||"C"` functions
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r253622.

[Bug c++/85580] New: "conflicting C language linkage declaration" warning for variables with identical names in `extern "C"` functions

[freddie_chopin at op dot pl]

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

Bug ID: 85580
   Summary: "conflicting C language linkage declaration" warning
for variables with identical names in `extern "C"`
functions
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

Here's a minimal test case executed with 8.0.1-RC-20180427 (compiled for
arm-none-eabi target, but I think the problem is not target-specific):

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ cat test.cpp

extern "C"
{

void f1()
{
  union some_type{
char a[2];
int b;
  } variable;
}

void f2()
{
  union some_type{
char a[2];
int b;
  } variable;
}

}

$ arm-none-eabi-gcc test.cpp -c
test.cpp: In function 'void f2()':
test.cpp:17:5: warning: conflicting C language linkage declaration
'f2()::some_type variable'
   } variable;
 ^~~~
test.cpp:9:5: note: previous declaration 'f1()::some_type variable'
   } variable;
 ^~~~

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (bleeding-edge-toolchain) 8.0.1 20180427 (prerelease)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

For the problem to appear:
- functions with the types and variables have to be extern "C"
- the file must be C++
- there has to be both a type and a variable
- the variables must have identical names

The problem was spotted with ARM CMSIS headers, where similar pattern exists:
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/Core/Include/cmsis_gcc.h#L1929

Related discussion on mailing list:
https://gcc.gnu.org/ml/gcc/2018-04/msg00191.html

[Bug libstdc++/68397] std::tr1::expint fails in __expint_En_cont_frac for some long double arguments due to low __max_iter value

[emsr at gcc dot gnu.org]

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

--- Comment #6 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Mon Apr 30 19:51:13 2018
New Revision: 259777

URL: https://gcc.gnu.org/viewcvs?rev=259777=gcc=rev
Log:
2018-04-30  Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/pr66689 - comp_ellint_3 and ellint_3 return garbage values
* include/tr1/ell_integral.tcc: Correct the nu sign convention
in ellint_3 and comp_ellint_3.
* testsuite/tr1/5_numerical_facilities/special_functions/
06_comp_ellint_3/check_value.cc: Regen with correct values.
* testsuite/tr1/5_numerical_facilities/special_functions/
14_ellint_3/check_value.cc: Ditto.
* testsuite/special_functions/06_comp_ellint_3/check_value.cc: Ditto.
* testsuite/special_functions/13_ellint_3/check_value.cc: Ditto.
* testsuite/special_functions/06_comp_ellint_3/pr66689.cc: New.
* testsuite/special_functions/13_ellint_3/pr66689.cc: New.
* testsuite/tr1/5_numerical_facilities/special_functions/
06_comp_ellint_3/pr66689.cc: New.
* testsuite/tr1/5_numerical_facilities/special_functions/
14_ellint_3/pr66689.cc: New.

2018-04-30  Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/68397 std::tr1::expint fails ... long double arguments.
* include/tr1/exp_integral.tcc: Increase iteration limits.
* testsuite/tr1/5_numerical_facilities/special_functions/15_expint/
pr68397.cc: New test.
* testsuite/special_functions/14_expint/pr68397.cc: New test.

svn commit \ --This line, and those below, will be ignored--
  ChangeLog \ M ChangeLog M include/tr1/ell_integral.tcc A
testsuite/special_functions/06_comp_ellint_3/pr66689.cc A 
testsuite/special_functions/13_ellint_3/pr66689.cc A
testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/pr66689.cc
A 
testsuite/tr1/5_numerical_facilities/special_functions/14_ellint_3/pr66689.cc M
testsuite/special_functions/06_comp_ellint_3/check_value.cc M 
testsuite/special_functions/13_ellint_3/check_value.cc M
testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/check_value.cc
M 
testsuite/tr1/5_numerical_facilities/special_functions/14_ellint_3/check_value.cc
M include/tr1/exp_integral.tcc A 
testsuite/special_functions/14_expint/pr68397.cc A
testsuite/tr1/5_numerical_facilities/special_functions/15_expint/pr68397.cc
  include/tr1/ell_integral.tcc \
  testsuite/special_functions/06_comp_ellint_3/pr66689.cc \
  testsuite/special_functions/13_ellint_3/pr66689.cc \
 
testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/pr66689.cc
\
  testsuite/tr1/5_numerical_facilities/special_functions/14_ellint_3/pr66689.cc
\
  testsuite/special_functions/06_comp_ellint_3/check_value.cc \
  testsuite/special_functions/13_ellint_3/check_value.cc \
 
testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/check_value.cc
\
  testsuite/tr1/5_numerical_facilities/special_functio

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/special_functions/06_comp_ellint_3/pr66689.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/special_functions/13_ellint_3/pr66689.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/special_functions/14_expint/pr68397.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/pr66689.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/14_ellint_3/pr66689.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/15_expint/pr68397.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/tr1/ell_integral.tcc
branches/gcc-7-branch/libstdc++-v3/include/tr1/exp_integral.tcc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/special_functions/06_comp_ellint_3/check_value.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/special_functions/13_ellint_3/check_value.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/check_value.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/14_ellint_3/check_value.cc

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[jameskuyper at alumni dot caltech.edu]

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

--- Comment #53 from James Kuyper Jr.  
---
(In reply to Davin McCall from comment #52)
> (In reply to James Kuyper Jr. from comment #48)
> > > The "one special guarantee" clause appears in the section describing union
> > > member access via the "." or "->" operators, implying that it only applies
> > > to the access of union members via the union. ...
> > 
> > I find nothing objectionable about that statement - it is indeed impossible
> > to create code which relies upon the special guarantee in 6.5.2.3p6 without
> > accessing the union members via the '.' or '->' operators. However, I
> > believe that you mean something more restricted than what you're actually
> > saying, because the code given in the original bug report does in fact
> > access the union members via '.' operator, in the expressions  and
> > , to create a situation where, as I understand it, that special
> > guarantee is fully applicable.
> > Could you expand on your description of what you think is required, to make
> > it clear why it doesn't apply in this case?
> 
> It isn't clear that "" for example actually accesses either "u" or its
> member "s1", and I would argue that it doesn't for either.

I agree: that expression does not access u or s1. However, because those
pointers are passed to f(), which does dereference them, f() does accesses
those members, and it does so via the use of the '.' operator in the calling
routine. Therefore, you need, at a minimum, to modify "accesses via" to
"accesses directly via", in order to convey your intended meaning.

I don't see anything in the standard's wording of 6.5.2.3p6 to justify
restricting what it says to direct accesses - it says "it is permitted to
inspect", without specifying restrictions on how the inspection may be
performed.

The words "anywhere that a declaration of the completed type of the union
is visible." would become pointless with your interpretation. You already need
a visible complete declaration of the union to directly access it's members
without violating a constraint. Those words are only needed if the guarantee
was intended to apply even when the access is not direct.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[davmac at davmac dot org]

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

--- Comment #52 from Davin McCall  ---
(In reply to James Kuyper Jr. from comment #48)
> > The "one special guarantee" clause appears in the section describing union
> > member access via the "." or "->" operators, implying that it only applies
> > to the access of union members via the union. ...
> 
> I find nothing objectionable about that statement - it is indeed impossible
> to create code which relies upon the special guarantee in 6.5.2.3p6 without
> accessing the union members via the '.' or '->' operators. However, I
> believe that you mean something more restricted than what you're actually
> saying, because the code given in the original bug report does in fact
> access the union members via '.' operator, in the expressions  and
> , to create a situation where, as I understand it, that special
> guarantee is fully applicable.
> Could you expand on your description of what you think is required, to make
> it clear why it doesn't apply in this case?

It isn't clear that "" for example actually accesses either "u" or its
member "s1", and I would argue that it doesn't for either. I read it how (if I
understand correctly) GCC has up until now interpreted it: the "special
guarantee" is for expressions directly involving member access via the union.
Once you take the address of the member, and later dereference it via "*", you
are dealing with a different operator and the guarantee doesn't apply.

I'll admit that this is still making some assumptions, but it's an
interpretation that is far more at peace with the rest of the standard.

(In reply to Andrew Haley from comment #45)
> (In reply to Davin McCall from comment #44)
> > The "one special guarantee" clause appears in the section describing union
> > member access via the "." or "->" operators, implying that it only applies
> > to the access of union members via the union.
> 
> I don't believe that's what is intended, or that you can make such a
> conclusion based on the section in which the rule appears.  It applies
> to other accesses too, as is (somewhat) made clear by the rationale in
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n685.htm:

It certainly may not be what is intended by N685, but I think it's normally
reasonable to conclude that a statement in a particular section of a document
applies to that section and not more universally than that; in this case, the
"universal" interpretation flatly contradicts the strict aliasing rule and any
other rule which would otherwise disallow access, which seems extremely
problematic to me.

In general it appears the committee have asserted that the "universal"
interpretation (which since N685 requires visibility of the union declaration
to be effective) is the correct one, but my argument is that the actual text of
the standard strongly implies something different, and that the interpretation
being pushed instead turns another portion of the standard text into nonsense.
It's extremely problematic in my view that a more reasonable reading is
considered incorrect and that this can only be known with external knowledge
outside the text of the specification itself.

Never the less, I take your point.

[Bug tree-optimization/85579] [9 regression] SIGSEV in fortran test case gfortran.dg/pr51434.f90 starting with r259754

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64*-*-*
 CC||rguenth at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Host||powerpc64*-*-*
  Build||powerpc64*-*-*

--- Comment #1 from seurer at gcc dot gnu.org ---
This occurs on powerpc64 both LE and BE.

[Bug tree-optimization/85579] New: [9 regression] SIGSEV in fortran test case gfortran.dg/pr51434.f90 starting with r259754

[seurer at gcc dot gnu.org]

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

Bug ID: 85579
   Summary: [9 regression] SIGSEV in fortran test case
gfortran.dg/pr51434.f90 starting with r259754
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Sorry, I don't know enough about fortran to know whether there is something
wrong with the test case.

seurer@makalu-lp1:~/gcc/build/gcc-test2$
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pr51434.f90
-fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -pedantic-errors
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-lm -g3 -o ./pr51434.exe

seurer@makalu-lp1:~/gcc/build/gcc-test2$ gdb ./pr51434.exe 
(gdb) run
Starting program: /home/seurer/gcc/build/gcc-test2/./pr51434.exe 
Program received signal SIGSEGV, Segmentation fault.
0x1770 in bar () at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pr51434.f90:18
18 if (any(c%t /= ['a', 'b', 'c', 'd', 'e'])) stop 2
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-196.el7_4.2.ppc64 zlib-1.2.7-17.el7.ppc64
(gdb) where
#0  0x1770 in bar () at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pr51434.f90:18
#1  main (argc=, argv=) at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pr51434.f90:14
#2  0x3fffb7a36bec in .generic_start_main.isra.0 () from /lib64/libc.so.6
#3  0x3fffb7a36e14 in .__libc_start_main () from /lib64/libc.so.6
#4  0x in ?? ()

[Bug c++/84701] casting to ( unsigned typeof(variable) ) gives wrong results

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/58063] default arguments evaluated twice per call

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.9.4, 5.2.0, 6.0
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.4

--- Comment #17 from Jason Merrill  ---
This was fixed a while back.

[Bug c++/85039] [6/7 Regression] internal compiler error: in nested_anon_class_index, at cp/mangle.c:1626

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.5 |8.0

--- Comment #7 from Jason Merrill  ---
Closing; we generally don't backport fixes for invalid code.

[Bug go/85429] Several gotools tests FAIL with Solaris as

[ian at airs dot com]

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

--- Comment #9 from Ian Lance Taylor  ---
I suppose if worst comes to worst we can try it both ways.

[Bug lto/85574] [9 Regression] LTO bootstapped binaries differ

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On April 30, 2018 5:01:30 PM GMT+02:00, "hubicka at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
>
>Jan Hubicka  changed:
>
>   What|Removed |Added
>
> CC||hubicka at gcc dot gnu.org
>
>--- Comment #1 from Jan Hubicka  ---
>Attachement seems to be missing. How do I reproduce it?

You reproduce w/o attachment, just LTO bootstrap up to comparison stage and
then cmp cc1 or gengtype. Works fine on the branch, miscompares on trunk. 

>The partitioning changes are not really affecting any sorting.  The
>changes
>will be null with -flto-partitioning=

[Bug c++/85305] Parameter pack expression in lambda capture list fails as part of a fold expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/85575] Acceptance of invalid code: ordering of declaration statements with implicit typing

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #1)
> Ok, after discussion on the Intel Forum I found out that this is based on 
> Section 7.1.11p7 of the f2008 standard , Specification expression:
> 
> A variable in a specication expression shall have its type and type
> parameters, if any, specified by a previous
> declaration in the same scoping unit, by the implicit typing rules in
> effect for the scoping unit, or by host or use
> association. If a variable in a specification expression is typed by the
> implicit typing rules, its appearance in any
> subsequent type declaration statement shall confirm the implied type and
> type parameters.
> 
> But it is not clear whether the compiler actually has to detect this.

If it is a numbered constraint, then the compiler must detect the problem.
If it is unnumbered, then the above "shall"'s apply to the program(mer).
A compiler can, but is not required to report a problem.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[jameskuyper at alumni dot caltech.edu]

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

--- Comment #51 from James Kuyper Jr.  
---
(In reply to Andrew Haley from comment #49)
> (In reply to James Kuyper Jr. from comment #46)
> > (In reply to Andrew Haley from comment #42)
> > ...
> > > In order to use type-based alias analysis in any LTO framework it's
> > > necessary to save type information, and this is just more type
> > > information. ...
> > 
> > > ... The question is, I suppose, how to handle the scopes of
> > > union declarations.  I'd just treat them as being global, which in
> > > practice isn't unrealistic because such declarations are in header
> > > files in global scope and shared anyway.
> > 
> > Why not use the actual scope of the completed union declaration,
> > which is what the relevant rule refers to?
> 
> The principle of type-based alias analysis is that all you know about
> two types is their types, not the location of any code that uses them.
> There are no scopes.  The oracle, given only the types, has to say
> whether they alias or not, regardless of where those types are used in
> a program.  The location isn't an input to the oracle.
> 
> Bear in mind that inlining and other kinds of code motion happen, and
> code is often evaluated "outside" the scopes in which it was written
> and in a completely different order.  That's all perfectly normal
> optimization.
> 
> Besides, when the alias oracle is consulted, all that scope stuff has
> gone.  It's only relevant to the front end.

I was only pointing out that implementing this special guarantee where it
applies, and only where it applies, requires keeping information that must
already have been collected. If the current design discards that information
before performing the relevant optimizations, I can understand that this would
require a significant re-design - but the re-design takes the form of saving
information already collected, not of collecting additional information.

> > > So, if any union types with a common initial sequence are declared
> > > anywhere in a program, then their member types alias.
> > 
> > As I understand it, the visibility rule was added specifically for
> > the purpose of NOT requiring that the entire program be covered by
> > this exception.
> 
> I don't think so.  As I read it, it was a way of declaring to the
> compiler that they types are intended to alias.

By "the visibility rule", I mean, very specifically, the phrase "anywhere that
a declaration of the completed type of the union is visible". If the intent had
been to disable aliasing throughout the entire program, that intent could have
been expressed by simply removing those words entirely; if there was any doubt
that people would understand the absence of those words correctly, then they
could have been replaced with the phrase "anywhere, regardless of whether or
not the completed type of the union was visible". I don't see any plausible
reason for the committee to write "anywhere that a declaration of the completed
type of the union is visible", unless that phrase was intended to restrict
applicability of the special guarantee.

> > Knowledgeable people writing code intended to take advantage of this
> > feature of C are likely to carefully place completed declarations of
> > the union's type so they disable those optimizations only where they
> > need to be disabled, and to minimize the amount of code where this
> > exception would unnecessarily disable useful optimizations.
> 
> Perhaps so, yes, but in practice it'd be pretty hard to do that.
> Functions can only be defined in the other scope, and there's no way
> to undefine a union type. 

True, but failing to define the union type is quite trivial. If I were writing
code that used both struct types, but not the union type, and did nothing that
relied upon the fact that they can alias each other, I would simply not
#include the header that defines the completed union type, #including only the
header that defines the struct types. If I needed to put such code in the same
translation unit as code which actually needs the union declaration, I would
put the code that doesn't need it before the #include, and put the code that
does need it after the #include - but that would probably be more trouble than
it's worth.

[Bug web/85578] New: broken links in gcc-8.0.1-RC-20180427/INSTALL/specific.html, and out of date prerequisites.html

[andrewm.roberts at sky dot com]

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

Bug ID: 85578
   Summary: broken links in
gcc-8.0.1-RC-20180427/INSTALL/specific.html, and out
of date prerequisites.html
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrewm.roberts at sky dot com
  Target Milestone: ---

The file INSTALL/specific.html in gcc-8.0.1-RC-20180427
contains many broken links. All links that include target-x-x are broken,
only the simple ones like avr are working.

avr link is: 
file:///home/aroberts/gcc/gcc/gcc-8.0.1-RC-20180427/INSTALL/specific.html#avr
which references:


aarch64*-*-* link is:
file:///home/aroberts/gcc/gcc/gcc-8.0.1-RC-20180427/INSTALL/specific.html#aarch64-x-x
which fails to reference:


This is obviously broken. And seems to apply to all the none trivial links.

Also in prerequisites.html, are the versions for mpc, mpfr, gmp, isl etc ok,
or are they out of date?

I see that the download_prerequisites is referencing:
gmp='gmp-6.1.0.tar.bz2'
mpfr='mpfr-3.1.4.tar.bz2'
mpc='mpc-1.0.3.tar.gz'
isl='isl-0.18.tar.bz2'

[Bug target/85572] faster code for absolute value of __v2di

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 44042
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44042=edit
gcc8-pr85572.patch

Untested fix.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

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

--- Comment #50 from Andrew Haley  ---
(In reply to Andrew Haley from comment #49)
> 
> Perhaps so, yes, but in practice it'd be pretty hard to do that.
> Functions can only be defined in the other scope,

Should be "the outer scope"

> and there's no way
> to undefine a union type.  I guess you could be clever and put all of
> the functions which needed to know about the aliasing at the end of a
> translation unit.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

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

--- Comment #49 from Andrew Haley  ---
(In reply to James Kuyper Jr. from comment #46)
> (In reply to Andrew Haley from comment #42)
> ...
> > In order to use type-based alias analysis in any LTO framework it's
> > necessary to save type information, and this is just more type
> > information. ...
> 
> > ... The question is, I suppose, how to handle the scopes of
> > union declarations.  I'd just treat them as being global, which in
> > practice isn't unrealistic because such declarations are in header
> > files in global scope and shared anyway.
> 
> Why not use the actual scope of the completed union declaration,
> which is what the relevant rule refers to?

The principle of type-based alias analysis is that all you know about
two types is their types, not the location of any code that uses them.
There are no scopes.  The oracle, given only the types, has to say
whether they alias or not, regardless of where those types are used in
a program.  The location isn't an input to the oracle.

Bear in mind that inlining and other kinds of code motion happen, and
code is often evaluated "outside" the scopes in which it was written
and in a completely different order.  That's all perfectly normal
optimization.

Besides, when the alias oracle is consulted, all that scope stuff has
gone.  It's only relevant to the front end.  

> > So, if any union types with a common initial sequence are declared
> > anywhere in a program, then their member types alias.
> 
> As I understand it, the visibility rule was added specifically for
> the purpose of NOT requiring that the entire program be covered by
> this exception.

I don't think so.  As I read it, it was a way of declaring to the
compiler that they types are intended to alias.

> Knowledgeable people writing code intended to take advantage of this
> feature of C are likely to carefully place completed declarations of
> the union's type so they disable those optimizations only where they
> need to be disabled, and to minimize the amount of code where this
> exception would unnecessarily disable useful optimizations.

Perhaps so, yes, but in practice it'd be pretty hard to do that.
Functions can only be defined in the other scope, and there's no way
to undefine a union type.  I guess you could be clever and put all of
the functions which needed to know about the aliasing at the end of a
translation unit.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[jameskuyper at alumni dot caltech.edu]

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

--- Comment #48 from James Kuyper Jr.  
---
(In reply to Davin McCall from comment #44)
> > Well, perhaps not, but this is the language specification.
> 
> The "one special guarantee" clause appears in the section describing union
> member access via the "." or "->" operators, implying that it only applies
> to the access of union members via the union. ...

I find nothing objectionable about that statement - it is indeed impossible to
create code which relies upon the special guarantee in 6.5.2.3p6 without
accessing the union members via the '.' or '->' operators. However, I believe
that you mean something more restricted than what you're actually saying,
because the code given in the original bug report does in fact access the union
members via '.' operator, in the expressions  and , to create a
situation where, as I understand it, that special guarantee is fully
applicable.
Could you expand on your description of what you think is required, to make it
clear why it doesn't apply in this case?

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

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

--- Comment #47 from Andrew Haley  ---
(In reply to Richard Biener from comment #43)
> (In reply to Andrew Haley from comment #42)
> > 
> > So, if any union types with a common initial sequence are declared
> > anywhere in a program, then their member types alias.  Alternatively,
> > a tighter implementation might restrict such declarations to a
> > compilation unit, in which case the alias oracle would scan only the
> > union types declared in that unit.
> 
> So for the middle-end the easiest thing would be if the FE would comply
> to its existing semantics and for the initial sequences generate a
> transparent struct.  Thus,
> 
> union {
>  struct A { int i; float f; double z; } a;
>  struct B { int i; float f; void *p; } b;
> };
> 
> would cause the FE to "implement" struct A and B like
> 
>  struct __init_seq1 { int i; float f; };
>  struct A { struct __init_seq1 _transp_memb1; double z; } a;
>  struct B { struct __init_seq1 _transp_memb2; void *p; } b;
> 
> then everything would work as expected from an aliasing point of view.
> The difficulty is probably that argument passing of A and B might
> change depending on how the ABIs are defined and how the backend handles
> those wrapping structs.

Nice.  I've got to admit that's a clever, idea, but it's also a very
big gotcha.

> But as you can clearly see the above would be also a way for the user
> to get what the clause permits without the clause being present.  So
> I'm not sure why this clause was added.

That's somewhat explained by N685, which does contain the rationale.
In short: proposal before N685 was to allow *every* pair of pointers
to structures with a common initial sequence to alias.  The revised
version (which was accepted) restricts this to structures with a
common initial sequence where a union of these structures is visible
to the compiler.

> language specifications have defects ...

Yabbut, N685 was accepted and the proposal does explain why.  Maybe it
shouldn't have been done that way, but it was done, and it was done
deliberately, as far as I can see.

> > > When I read the language text then a union declaration in between
> > > two accesses will change the semantic of the second?
> > 
> > Not necessarily.  It would be correct to collect all union
> > declarations at the end of parsing and then use those to feed the
> > alias oracle.  There's no actual need to restrict their scope.  Sure,
> > it would lead to GCC being somewhat over-cautious, but that's OK.
> 
> given the TBAA oracle is filled on-demand it is important that both
> outcomes are allowed. 

Okay, I don't get this.  Why not simply say that if a union type with
the initial common sequence exists anywhere, it is as though it were
declared at the start of every TU.

> I still don't see how we can make it work easily in the middle-end.

I don't think I ever said it would be easy!  I am saying, though, that
it's not the end of TBAA as we know it, but a refinement in which a
front end can feed into the alias oracle sets of types that are known
to alias.

You can think of it as a declaration:

__alias__ {
  type_a, type_b, type_c
};

which is an additional input to the oracle.

[Bug fortran/85575] Acceptance of invalid code: ordering of declaration statements with implicit typing

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
Ok, after discussion on the Intel Forum I found out that this is based on 
Section 7.1.11p7 of the f2008 standard , Specification expression:

A variable in a specication expression shall have its type and type
parameters, if any, specified by a previous
declaration in the same scoping unit, by the implicit typing rules in
effect for the scoping unit, or by host or use
association. If a variable in a specification expression is typed by the
implicit typing rules, its appearance in any
subsequent type declaration statement shall confirm the implied type and
type parameters.

But it is not clear whether the compiler actually has to detect this.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[jameskuyper at alumni dot caltech.edu]

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

--- Comment #46 from James Kuyper Jr.  
---
(In reply to Andrew Haley from comment #42)
...
> In order to use type-based alias analysis in any LTO framework it's
> necessary to save type information, and this is just more type
> information. ...

Speaking from a developer's perspective rather than an implementor's
perspective, the implementation already needs to keep track of where the
union's completed definition is in scope, because it's only in those locations
where it would be permitted to define an object having the union's type. This
is just a different use for the same information; it shouldn't require storing
any additional information; nor should it require holding on to that
information for any longer than is already required.
As a matter of efficient implementation, rather than correctness, I think it
might be useful to store, for each struct type, a list of the union definitions
for which this might be an issue, a list that would not be needed for any other
reason. However, most of the time, that list would be empty - only when it's
not empty would the compiler need to review that list to determine which other
struct types might be permitted to alias this type, to a limited extent.

> ... The question is, I suppose, how to handle the scopes of
> union declarations.  I'd just treat them as being global, which in
> practice isn't unrealistic because such declarations are in header
> files in global scope and shared anyway.

Why not use the actual scope of the completed union declaration, which is what
the relevant rule refers to?

> So, if any union types with a common initial sequence are declared
> anywhere in a program, then their member types alias.

As I understand it, the visibility rule was added specifically for the purpose
of NOT requiring that the entire program be covered by this exception.
Knowledgeable people writing code intended to take advantage of this feature of
C are likely to carefully place completed declarations of the union's type so
they disable those optimizations only where they need to be disabled, and to
minimize the amount of code where this exception would unnecessarily disable
useful optimizations.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

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

--- Comment #45 from Andrew Haley  ---
(In reply to Davin McCall from comment #44)
> > Well, perhaps not, but this is the language specification.
> 
> The "one special guarantee" clause appears in the section describing union
> member access via the "." or "->" operators, implying that it only applies
> to the access of union members via the union.

I don't believe that's what is intended, or that you can make such a
conclusion based on the section in which the rule appears.  It applies
to other accesses too, as is (somewhat) made clear by the rationale in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n685.htm:

The proposed solution is to require that a union declaration be visible
if aliases through a common initial sequence (like the above) are possible.
Therefore the following TU provides this kind of aliasing if desired:

union utag {
  struct tag1 { int m1; double d2; } st1;
  struct tag2 { int m1; char c2; } st2;
};

int similar_func(struct tag1 *pst2, struct tag2 *pst3) {
  pst2->m1 = 2;
  pst3->m1 = 0;   /* might be an alias for pst2->m1 */
  return pst2->m1;
}

I know this is non-normative and not even in the standard, but it does
explain what was intended.

[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Yes that's why I confirmed the bug by changing the status to NEW.

[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules

[ixsci at yandex dot ru]

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

--- Comment #4 from Evgeniy Shcherbina  ---
Jonathan, yes it *should* be called as foo(1, 2) but the result is as if it is
called as foo(1, 1).

--- Comment #5 from Evgeniy Shcherbina  ---
Jonathan, yes it *should* be called as foo(1, 2) but the result is as if it is
called as foo(1, 1).

[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules

[ixsci at yandex dot ru]

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

--- Comment #4 from Evgeniy Shcherbina  ---
Jonathan, yes it *should* be called as foo(1, 2) but the result is as if it is
called as foo(1, 1).

--- Comment #5 from Evgeniy Shcherbina  ---
Jonathan, yes it *should* be called as foo(1, 2) but the result is as if it is
called as foo(1, 1).

[Bug c++/85573] gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders

[sylvain.bertrand at gmail dot com]

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

--- Comment #5 from Sylvain Bertrand  ---
On Mon, Apr 30, 2018 at 01:02:20PM +, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573
> 
> --- Comment #4 from Jonathan Wakely  ---
> 7.3.1 will never be released, it's a post-7.3.0 and pre-7.4.0 development
> snapshot.
> 
> If you are getting segfaults from snapshots now and you don't report them then
> the final release is likely to have the same segfaults.

Then 8.1 release which is supposed to be soon enough. No update on AMD shader
compiler in the mean time.

[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #19 from Jason Merrill  ---
Fixed for GCC 9.

[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects

[jason at gcc dot gnu.org]

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

--- Comment #18 from Jason Merrill  ---
Author: jason
Date: Mon Apr 30 15:21:01 2018
New Revision: 259772

URL: https://gcc.gnu.org/viewcvs?rev=259772=gcc=rev
Log:
PR c++/61982 - dead stores to destroyed objects.

gcc/cp/
* call.c (build_trivial_dtor_call): New, assigns a clobber.
(build_over_call, build_special_member_call): Use it.
* cp-tree.h: Declare it.
* init.c (build_delete): Remove trivial path.
gcc/
* gimplify.c (gimplify_modify_expr): Simplify complex lvalue on LHS
of clobber.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/lifetime-dse1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/gimplify.c

[Bug c/81405] [8 Regression] Buffer overflow when consolidating printing of out-of-order fix-it hints

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Mon Apr 30 15:01:56 2018
New Revision: 259768

URL: https://gcc.gnu.org/viewcvs?rev=259768=gcc=rev
Log:
Use char_span for return type of location_get_source_line

location_get_source_line returns a const char * that isn't 0-terminated,
writing back a length through an int * param.

This is error-prone, as all call-sites have to take into account the
lack of 0-termination, and respect the length of the buffer.

It's cleaner to bundle together this pointer+length state into a class,
so this patch does so, reusing the "char_span" class that I introduced
in r250187 (as part of the fix for PR c/81405).

The patch also adds assertions to all access to the char_span.

gcc/c-family/ChangeLog:
* c-format.c (get_corrected_substring): Update for
location_get_source_line returning a char_span.  Use a char_span
when handling the prefix of the correction.
* c-indentation.c (get_visual_column): Update for
location_get_source_line returning a char_span.
(get_first_nws_vis_column): Likewise.

gcc/ChangeLog:
* diagnostic-show-locus.c (layout::layout): Update for
location_get_source_line returning a char_span.
(struct char_span): Move to input.h.
(struct correction): Update for fields in char_span becoming
private.
(struct source_line): Update for location_get_source_line
returning a char_span.
(layout::print_line): Likewise.
* edit-context.c (edited_file::print_content): Likewise.
(edited_file::print_diff_hunk): Likewise.
(edited_file::print_run_of_changed_lines): Likewise.
(edited_file::get_num_lines): Likewise.
(edited_line::edited_line): Likewise.
* final.c (asm_show_source): Likewise.
* input.c (location_get_source_line): Convert return type
from const char * to char_span, losing the final "line_len"
param.
(dump_location_info): Update for the above.
(get_substring_ranges_for_loc): Likewise.  Use a char_span
when handling the literal within the line.
(test_reading_source_line): Update for location_get_source_line
returning a char_span.
* input.h (class char_span): Move here from
diagnostic-show-locus.c, converting from a struct to a class.
Make data members private.
(char_span::operator bool): New.
(char_span::length): New.
(char_span::get_buffer): New.
(char_span::operator[]): New.
(char_span::subspan): Make const.
(char_span::xstrdup): New.
(location_get_source_line): Convert return type from const char *
to char_span, losing the final "line_size" param.

gcc/testsuite/ChangeLog:
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
(test_show_locus): Update for location_get_source_line returning a
char_span.  Use char_span for handling words in the
"test_many_nested_locations" fix-it example.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/c-family/c-indentation.c
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/edit-context.c
trunk/gcc/final.c
trunk/gcc/input.c
trunk/gcc/input.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c

[Bug lto/85574] [9 Regression] LTO bootstapped binaries differ

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Jan Hubicka  ---
Attachement seems to be missing. How do I reproduce it?
The partitioning changes are not really affecting any sorting.  The changes
will be null with -flto-partitioning=

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

[joseph at codesourcery dot com]

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

--- Comment #14 from joseph at codesourcery dot com  ---
As I said in comment#10, I think the solution is to remove the specs 
making -mieee-fp imply -lieee.  (Principally the spec in gnu-user.h.  I 
don't think this should depend on what libc is in use.  No doubt the 
similar spec in m32r/linux.h should be changed similarly, though I'm not 
aware of a glibc port to m32r, don't know what libc was used with that 
port, and the Linux kernel port to m32r has now been removed along with 
several others for 4.17.)

[Bug c++/85577] list-initialization chooses initializer-list constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Clang and EDG accept it.

[Bug c++/85577] New: list-initialization chooses initializer-list constructor

[redi at gcc dot gnu.org]

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

Bug ID: 85577
   Summary: list-initialization chooses initializer-list
constructor
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

namespace std
{
  typedef long unsigned int size_t;

  template
class initializer_list
{
public:
  typedef _E value_type;
  typedef const _E& reference;
  typedef const _E& const_reference;
  typedef size_t size_type;
  typedef const _E* iterator;
  typedef const _E* const_iterator;

private:
  iterator _M_array;
  size_type _M_len;


  constexpr initializer_list(const_iterator __a, size_type __l)
  : _M_array(__a), _M_len(__l) { }

public:
  constexpr initializer_list() : _M_array(0), _M_len(0) { }


  constexpr size_type
  size() { return _M_len; }


  constexpr const_iterator
  begin() { return _M_array; }


  constexpr const_iterator
  end() { return begin() + size(); }
  };

  template T&& move(T& t) { return static_cast(t); }

  template
  struct vector {
vector(vector&&) noexcept { }
vector(initializer_list) = delete;
  };
}

struct A {
  A(A const&) = delete;
  A& operator=(A const&) = delete;
  A(A&&) = default;
  A& operator=(A&&) = default;
  A(std::vector&& v) : v{std::move(v)} { }

  std::vector v;
};


v.ii: In constructor ‘A::A(std::vector&&)’:
v.ii:54:41: error: use of deleted function
‘std::vector::vector(std::initializer_list) [with T = A]’
   A(std::vector&& v) : v{std::move(v)} { }
 ^
v.ii:45:5: note: declared here
 vector(initializer_list) = delete;
 ^~

The move constructor should be used, not the initialize-list one.

[Bug c++/85576] A template union containing a friend function causes non-template type used as a template error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-30
 Ever confirmed|0   |1

[Bug c++/85576] New: A template union containing a friend function causes non-template type used as a template error

[malcolm.parsons at gmail dot com]

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

Bug ID: 85576
   Summary: A template union containing a friend function causes
non-template type used as a template error
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: malcolm.parsons at gmail dot com
  Target Milestone: ---

For this code:

template 
union Union {
friend bool operator==(const Union& a, const Union& b) {
return true;
}
T t;
};

Union i;

GCC reports an error:

:9:10: error: non-template type 'Union' used as a template

 Union i;

  ^


Clang and MSVC both accept this code: https://godbolt.org/g/S9p7hw

[Bug fortran/85575] New: Acceptance of invalid code: ordering of declaration statements with implicit typing

[juergen.reuter at desy dot de]

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

Bug ID: 85575
   Summary: Acceptance of invalid code: ordering of declaration
statements with implicit typing
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

I think I saw discussions on this topic already on c.l.f. I am having the
following subroutine (and the recursive attribute doesn't play a role)
1 recursive function constr_quark_loopline(ho,sho) result(cl)
2   integer, dimension(sho), intent(in) :: ho
3   integer, dimension(sho) :: hor
4   integer, intent(in) :: sho
5   [...]
6 end function constr_quark_loopline

Intel gives an error message error #6415: This name cannot be assigned this
data type because it conflicts with prior uses of the name.   [SHO]

in the case this is an external procedure, or a module procedure with or
without 'implicit none' in the head of the module.

First of all, I would like to get it confirmed that this is really a
contradiction of the standard, and that the order of the declarations matters.
In case this is a module procedure without implicit none or an external
procedure, implicit typing rules apply and sho would be considered to be a
real, such that later specifying it as an integer is a contradiction. gfortran
and nagfor complain:

   integer, intent(in) :: sho  
1
Error: Symbol ‘sho’ at (1) already has basic type of REAL

and

Error: rec.f90, line 8: Symbol SHO has already been implicitly typed
   detected at SHO@

The strange thing (which seems a compiler bug to me) is that gfortran compiles
this code when it is a module procedure with 'implicit none'. This seems a 
(gfortran) compiler bug to me to accept this code. I see this behavior with all
gfortran versions that I can get a hold on, 4.8, 4.9., 5.4, 6.3, 7.3, 8.0 and
9.0. That is the reason I filed this report. Comments are appreciated.

And yes, of course, I know that having the declaration of sho first solves all
the problems, but this is 3rd-party code.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
Jason, should this be FIXED instead of SUSPENDED?

[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Testcase from PR 70395

struct NonCopyable {
  NonCopyable(const NonCopyable&) = delete;
  NonCopyable(NonCopyable&&) = delete;
  NonCopyable& operator=(const NonCopyable&) = delete;
  NonCopyable& operator=(NonCopyable&&) = delete;

  NonCopyable() {}

  ~NonCopyable() {} // to make it non-trivial
};

struct A {
  A(): _a{} {}
  ~A() {}

  NonCopyable _a[5];
} a;

[Bug c++/70395] [C++11] Error when initializing array of non-copyable non-trivial type in constructor initializer list

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> Probably a dup of PR 63707

I'll add this testcase there.

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

[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mosra at centrum dot cz

--- Comment #9 from Jonathan Wakely  ---
*** Bug 70395 has been marked as a duplicate of this bug. ***

[Bug c++/77840] List-initialization and copy-constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Closing as invalid based on my comments above.

[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|WAITING |NEW

--- Comment #3 from Jonathan Wakely  ---
"The initialization of a parameter, including every associated value
computation and side effect, is indeterminately sequenced with respect to that
of any other parameter."

That's indeterminately sequenced, not unsequenced:

"Evaluations A and B are indeterminately sequenced when either A is sequenced
before B or B is sequenced before A, but it is unspecified which. [ Note:
Indeterminately sequenced evaluations cannot overlap, but either could
be executed first. — end note ]"

So the function is called as foo(1, 2), but it's unspecified whether i==1 or
i==2 afterwards.

[Bug lto/85574] [9 Regression] LTO bootstapped binaries differ

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug lto/85574] New: [9 Regression] LTO bootstapped binaries differ

[rguenth at gcc dot gnu.org]

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

Bug ID: 85574
   Summary: [9 Regression] LTO bootstapped binaries differ
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: needs-bisection
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

See PR85571 (which is about LTO IL differences).  Binaries like cc1 and
build/gengtype differ between stage2 and stage3.  This is a regression from
GCC8
where they compare just fine (double-checked with and without checking for
c,c++ bootstrap-lto).

I tried the attached but it doesn't help so I suspect the partitioning changes
instead (unstable sorts?).

[Bug c++/85573] gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
7.3.1 will never be released, it's a post-7.3.0 and pre-7.4.0 development
snapshot.

If you are getting segfaults from snapshots now and you don't report them then
the final release is likely to have the same segfaults.

[Bug c++/85573] gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders

[sylvain.bertrand at gmail dot com]

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

--- Comment #3 from Sylvain Bertrand  ---
On Mon, Apr 30, 2018 at 12:43:04PM +, manuel.lauss at googlemail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573
> 
> Manuel Lauss  changed:
> 
>What|Removed |Added
> 
>  CC||manuel.lauss at googlemail 
> dot com
> 
> --- Comment #2 from Manuel Lauss  ---
> Works with gcc-7.3.1 for me, latest llvm git snapshot.

Then I guess I'll wait for the release of 7.3.1 or 8.1 then (will arrive soon I
guess). If it works, I'll notify the llvm "guys" to update their compilation
requirements to gcc 7.3.1 and gcc 8.1 (it was gcc 4.8.0).

I got many miscompilations resulting in segfaults in recent git gcc, that's why
I prefer to wait for an official release.

[Bug c++/85573] gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders

[manuel.lauss at googlemail dot com]

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

Manuel Lauss  changed:

   What|Removed |Added

 CC||manuel.lauss at googlemail dot 
com

--- Comment #2 from Manuel Lauss  ---
Works with gcc-7.3.1 for me, latest llvm git snapshot.

[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
On the gcc-8 branch cc1 and friends compare OK so this is a recent regression. 
Will try with checking enabled to be extra sure.  Then there are only few
changes on trunk that are suspicious.

+/* Compare types based on source file location.  */
+
+static int
+cmp_type_location (const void *p1_, const void *p2_)
+{
+  tree *p1 = (tree*)(const_cast(p1_));
+  tree *p2 = (tree*)(const_cast(p2_));
+  if (*p1 == *p2)
+return 0;
+
+  tree tname1 = TYPE_NAME (*p1);
+  tree tname2 = TYPE_NAME (*p2);
+
+  const char *f1 = DECL_SOURCE_FILE (tname1);
+  const char *f2 = DECL_SOURCE_FILE (tname2);
+
+  int r = strcmp (f1, f2);
+  if (r == 0)

this should probably split paths.

+  /* Register ODR types.  */
+  for (unsigned i = 0; i < odr_types.length (); i++)
+register_odr_type (odr_types[i]);

I suspect the order may have effects on code-generation.

[Bug c++/85573] gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-30
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
As requested when creating this bug, please read https://gcc.gnu.org/bugs and
provide the necessary information (at the very least the output of gcc -v and
preprocessed source).

[Bug c++/85573] New: gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders

[sylvain.bertrand at gmail dot com]

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

Bug ID: 85573
   Summary: gcc 7.3.0 cannot compile recent LLVM for AMD GPU
shaders
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sylvain.bertrand at gmail dot com
  Target Milestone: ---

I tried to compile a recent LLVM for AMD GPU shaders, but was unable due to the
compilation error reported here:
https://bugs.llvm.org/show_bug.cgi?id=37287

It seems the c++ used in recent LLVM hits something unimplemented in g++.

[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  ---
> 
> so different BB re-ordering / partitioning?

That would be probably best visible from bb-reorder dumps. However...
> 
> For example in the case of gengtype from stage2/stage3 .text has the same size
> but .debug_info size differs by one byte.  But gentype code differs as well:
> 
> @@ -2884,6 +2884,7 @@
>xx:  xx xx xx xx xx  xxllq  xx <_ZLxxpxxk_state_tokeni>
>xx:  xx xx xx xx xx  mov$0x1,%xxi
>xx:  xx xx xxmov%rax,%rxx
> +  xx:  xx xx xx xx mov%rax,(%rsp)

This is something else and such changes may make partitioning to diverge. So
perhaps
first debug this one?
>xx:  xx xx xx xx xx  xxllq  xx <_ZLxxpxxk_state_tokeni>
>xx:  xx xx xx xx xx  mov$0x2,%xxi
>xx:  xx xx xxmov%rax,%rbp
> ...
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
So even w/o the -f[no-]checking flags I see then when comparing stage2 and
stage3 cc1:

> readelf -S /abuild/rguenther/obj/prev-gcc/cc1 | grep -C 1 .text
   0008  0008  AX   0 0 8
  [14] .text PROGBITS 0057be60  0017be60
   00feb92a    AX   0 0 16
> readelf -S /abuild/rguenther/obj/gcc/cc1 | grep -C 1 .text
   0008  0008  AX   0 0 8
  [14] .text PROGBITS 0057be60  0017be60
   00feb5ba    AX   0 0 16

assembly shows (after stripping reloc offset differences - bah, objdump
should have a way to substitute zero for all of those):

@@ -11420,24 +11420,6 @@
   xx:  xx xx xxmov%rxx,%rdi
   xx:  xx xx xx xx xx  mov$0xb,%esi
   xx:  xx xx xx xx xx  xxllq  xx
<_Zxxtrxx_contains_struct_chxxk_xxilxx
PK9trxx_noxxtrxx_noxx_structure_enumPKciS4_>
-  xx:  xx xx xxmov%r8,%rdi
-  xx:  xx xx xx xx xx  xxllq  xx
<_ZLxxi_tag_bindingP9trxx_noxx.part.xx
>
-  xx:  xx xx xxmov%rxx,%rdi
-  xx:  xx xx xx xx xx  xxllq  xx
<_ZLxxi_symbol_bindingP9trxx_noxx.part
.xx>
-  xx:  xx xx xxmov%r8,%rdi
-  xx:  xx xx xx xx xx  xxllq  xx
<_ZLxxi_tag_bindingP9trxx_noxx.part.xx
>
-  xx:  xx xx xxmov%rxx,%rdi
-  xx:  xx xx xx xx xx  xxllq  xx
<_ZLxxi_symbol_bindingP9trxx_noxx.part
.xx>
-  xx:  xx xx xx xx xx  mov$0xxx,%xxx
-  xx:  xx xx xx xx xx  mov$0xxx,%esi
-  xx:  xx xx xx xx xx  mov$0xxx,%xxi
-  xx:  xx xx xx xx xx  xxllq  xx <_Zxxncy_xxortPKciS0_>
-  xx:  xx xx xx xx xx xx   mov$0xxx,%rxx
-  xx:  xx xx xx xx xx  mov$0xxx,%xxx
-  xx:  xx xx xx xx xx  mov$0xxx,%xxx
-  xx:  xx xx xxmov%rxx,%rdi
-  xx:  xx xx xx xx xx  mov$0x1,%esi
-  xx:  xx xx xx xx xx  xxllq  xx
<_Zxxtrxx_contains_struct_chxxk_xxilxxPK9trxx_noxxtrxx_noxx_structure_enumPKciS4_>
   xx:  xx xx xx xx xx xx   mov$0xxx,%rxx
   xx:  xx xx xx xx xx  mov$0xxx,%xxx
   xx:  xx xx xx xx xx  mov$0xxx,%xxx
@@ -11480,6 +11462,20 @@
   xx:  xx xx xx xx xx  mov$0xxx,%esi
   xx:  xx xx xxmov%rxx,%rdi
   xx:  xx xx xx xx xx  xxllq  xx
<_Zxxtrxx_chxxk_xxilxxPK9trxx_noxxPKciS3_z>
+  xx:  xx xx xxmov%r8,%rdi
+  xx:  xx xx xx xx xx  xxllq  xx
<_ZLxxi_tag_bindingP9trxx_noxx.part.xx>
+  xx:  xx xx xxmov%rxx,%rdi
+  xx:  xx xx xx xx xx  xxllq  xx
<_ZLxxi_symbol_bindingP9trxx_noxx.part.xx>
+  xx:  xx xx xx xx xx  mov$0xxx,%xxx
+  xx:  xx xx xx xx xx  mov$0xxx,%esi
+  xx:  xx xx xx xx xx  mov$0xxx,%xxi
+  xx:  xx xx xx xx xx  xxllq  xx <_Zxxncy_xxortPKciS0_>
+  xx:  xx xx xx xx xx xx   mov$0xxx,%rxx
+  xx:  xx xx xx xx xx  mov$0xxx,%xxx
+  xx:  xx xx xx xx xx  mov$0xxx,%xxx
+  xx:  xx xx xxmov%rxx,%rdi
+  xx:  xx xx xx xx xx  mov$0x1,%esi
+  xx:  xx xx xx xx xx  xxllq  xx
<_Zxxtrxx_contains_struct_chxxk_xxilxxPK9trxx_noxxtrxx_noxx_structure_enumPKciS4_>
   xx:  xx xx xx xx xx xx   mov$0xxx,%rxx
   xx:  xx xx xx xx xx  mov$0xxx,%xxx
   xx:  xx xx xx xx xx  mov$0xxx,%xxx
...

 xx <_ZLxx_parser_postfix_expressionPxx_parser.cold.xx>:
-  xx:  xx xx xx xx xx  xxllq  xx
<_ZN3vxxIxxva_hxxp6vl_ptrExxquick_pushERKb.isra.xx.part.xx>
+  xx:  xx xx xx xx xx  xxllq  xx
<_ZN3vxxIxxva_hxxp6vl_ptrEixEj.isra.xx.part.xx>
   xx:  xx xx xx xx xx xx   mov$0xxx,%rxx

so different BB re-ordering / partitioning?

For example in the case of gengtype from stage2/stage3 .text has the same size
but .debug_info size differs by one byte.  But gentype code differs as well:

@@ -2884,6 +2884,7 @@
   xx:  xx xx xx xx xx  xxllq  xx <_ZLxxpxxk_state_tokeni>
   xx:  xx xx xx xx xx  mov$0x1,%xxi
   xx:  xx xx xxmov%rax,%rxx
+  xx:  xx xx xx xx mov%rax,(%rsp)
   xx:  xx xx xx xx xx  xxllq  xx <_ZLxxpxxk_state_tokeni>
   xx:  xx xx xx xx xx  mov$0x2,%xxi
   xx:  xx xx xxmov%rax,%rbp
...

[Bug target/85572] faster code for absolute value of __v2di

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Hmm, looks like C doesn't like the conditional.  Eh.  Confirmed with C++ where
we expand to piecewise operation.

The target needs to provide abs patterns if that shouldn't happen.

[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Created attachment 44041
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44041=edit
patch

Like this.  Will fail as well because cc1 will differ (does not differ without
LTO).

[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Or more sophisticated allow to override/amend what we compare in the .mk
snippets
and compare $(exeext) instead of ($objext) for bootstrap-lto.

[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
The following should work:

Index: config/bootstrap-lto.mk
===
--- config/bootstrap-lto.mk (revision 259755)
+++ config/bootstrap-lto.mk (working copy)
@@ -1,5 +1,7 @@
 # This option enables LTO for stage2 and stage3 in slim mode

+do-compare = /bin/true
+
 STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1
 STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1
 STAGEprofile_CFLAGS += -flto=jobserver -frandom-seed=1

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[davmac at davmac dot org]

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

--- Comment #44 from Davin McCall  ---
> Well, perhaps not, but this is the language specification.

The "one special guarantee" clause appears in the section describing union
member access via the "." or "->" operators, implying that it only applies to
the access of union members via the union. As has been pointed out by others,
the guarantee is surely not meant to trump all other rules regarding access, so
this is a reasonable interpretation (since otherwise, it is totally unclear
when it does apply and what exactly "it is permitted" even means).

Note that without that clause, type punning structs via a union would
essentially be impossible (since layout is implementation defined or
unspecified). The "common initial sequence" requirement is the only part of the
standard which requires that structs with similar members have them layed out
in the same order and alignment. Since this only matters for type punning, it
again makes sense that this would be specified in the one section which
actually allows for type punning (even if only in a non-normative footnote) -
that is, union member access via a union. It's clear why it is needed for this,
but to extend that to any access of union members (including not via the union)
seems like a stretch. If that was intended, why isn't it specified in 6.5?

The only thing that suggests an alternative interpretation to what I've
described above is the requirement that the declaration of the completed type
of the union be visible, which is redundant if the access must be via the union
type. However, interpreting this to mean that the "special guarantee" applies
globally is far more problematic than assuming that the requirement is just
redundant.

[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
contrib/compare-debug strips off LTO sections but that would leave us with a
no-op compare.  On any target using non-native sections just stripping
.gnu.lto_.opts
will be difficult in such script, so we'd need to build a compare-lto tool
and use that.

But as said, comparing LTO bytecode is of questionable value and comparing the
binaries doesn't work...

[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Not yet fixed.  As we compare LTO bytecode but that includes the .opts section
we now have -f[no-]checking there...  We can't remove it there since we of
course want to have different settings at link-time.  A custom do-compare
script like bootstrap-debug.mk provides might be a workaround for this
particular
issue.

Maybe time to finally not compare LTO bytecode (but then we need to compare
binaries which we don't do - but we could now that we share the checksums).

OTOH stage2 and stage3 cc1 even differ in the size of the .text section...

So we have "real" bugs to fix here as well it seems ;)

[Bug target/85572] New: faster code for absolute value of __v2di

[kretz at kde dot org]

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

Bug ID: 85572
   Summary: faster code for absolute value of __v2di
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

The absolute value for 64-bit integer SSE vectors is only optimized when
AVX512VL is available. Test case (`-O2 -ffast-math` and one of -mavx512vl,
-msse4, or -msse2):

#include 

__v2di abs(__v2di x) {
return x < 0 ? -x : x;
}

With SSE4 I suggest:

abs(long long __vector(2)):
  pxor %xmm1, %xmm1
  pcmpgtq %xmm0, %xmm1
  pxor %xmm1, %xmm0
  psubq %xmm1, %xmm0
  ret

in C++:
auto neg = reinterpret_cast<__v2di>(x < 0);
return (x ^ neg) - neg;


Without SSE4:

abs(long long __vector(2)):
  movdqa %xmm0, %xmm2
  pxor %xmm1, %xmm1
  psrlq $63, %xmm2
  psubq %xmm2, %xmm1
  pxor %xmm1, %xmm0
  paddq %xmm2, %xmm0
  ret

in C++:
auto neg = -reinterpret_cast<__v2di>(reinterpret_cast<__v2du>(x) >> 63);
return (x ^ neg) - neg;


related issue for scalars: #67510

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[rguenth at gcc dot gnu.org]

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

--- Comment #43 from Richard Biener  ---
(In reply to Andrew Haley from comment #42)
> On 04/29/2018 05:42 PM, rguenther at suse dot de wrote:>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
> > 
> > --- Comment #41 from rguenther at suse dot de  ---
> > On April 29, 2018 1:51:58 PM GMT+02:00, "aph at gcc dot gnu.org"
> >  wrote:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
> >>
> >> --- Comment #40 from Andrew Haley  ---
> >> (In reply to rguent...@suse.de from comment #29)
> >>
> >>> Note I repeatedly said this part of the standard is just stupid.  It
> >> makes
> >>> most if not all type-based alias analysis useless.
> >>
> >> I don't think so.  It does mean that we'd have to feed all declared
> >> union types (or, at least the ones containing structs with common
> >> initial sequences) into the alias oracle.  While unpleasant, in that
> >> simply declaring a type without even declaring an object of that type
> >> changes code generation, it doesn't render all type-based alias
> >> analysis useless.
> > 
> > How do you handle this within the LTO framework?
> 
> In order to use type-based alias analysis in any LTO framework it's
> necessary to save type information, and this is just more type
> information.  The question is, I suppose, how to handle the scopes of
> union declarations.  I'd just treat them as being global, which in
> practice isn't unrealistic because such declarations are in header
> files in global scope and shared anyway.
> 
> So, if any union types with a common initial sequence are declared
> anywhere in a program, then their member types alias.  Alternatively,
> a tighter implementation might restrict such declarations to a
> compilation unit, in which case the alias oracle would scan only the
> union types declared in that unit.

So for the middle-end the easiest thing would be if the FE would comply
to its existing semantics and for the initial sequences generate a
transparent struct.  Thus,

union {
 struct A { int i; float f; double z; } a;
 struct B { int i; float f; void *p; } b;
};

would cause the FE to "implement" struct A and B like

 struct __init_seq1 { int i; float f; };
 struct A { struct __init_seq1 _transp_memb1; double z; } a;
 struct B { struct __init_seq1 _transp_memb2; void *p; } b;

then everything would work as expected from an aliasing point of view.
The difficulty is probably that argument passing of A and B might
change depending on how the ABIs are defined and how the backend handles
those wrapping structs.

But as you can clearly see the above would be also a way for the user
to get what the clause permits without the clause being present.  So
I'm not sure why this clause was added.

> >>> Which means I'll refuse any patches implementing it in a way that
> >>> affects default behavior.
> >>
> >> Maybe --pedantic or even --pedantic-aliasing?
> > 
> > Whatever you call it I doubt any working solution will fit nicely
> > into our existing TBAA framework.
> 
> Well, perhaps not, but this is the language specification.

language specifications have defects ...

> > When I read the language text then a union declaration in between
> > two accesses will change the semantic of the second?
> 
> Not necessarily.  It would be correct to collect all union
> declarations at the end of parsing and then use those to feed the
> alias oracle.  There's no actual need to restrict their scope.  Sure,
> it would lead to GCC being somewhat over-cautious, but that's OK.

given the TBAA oracle is filled on-demand it is important that both
outcomes are allowed.  I still don't see how we can make it work easily
in the middle-end.

For anyone wanting to make GCC comply I suggest the above sketched route
and start with looking how backends deal with this kind of wrapping in
their argument passing.

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[aph at gcc dot gnu.org]

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

--- Comment #42 from Andrew Haley  ---
On 04/29/2018 05:42 PM, rguenther at suse dot de wrote:>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
> 
> --- Comment #41 from rguenther at suse dot de  ---
> On April 29, 2018 1:51:58 PM GMT+02:00, "aph at gcc dot gnu.org"
>  wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>>
>> --- Comment #40 from Andrew Haley  ---
>> (In reply to rguent...@suse.de from comment #29)
>>
>>> Note I repeatedly said this part of the standard is just stupid.  It
>> makes
>>> most if not all type-based alias analysis useless.
>>
>> I don't think so.  It does mean that we'd have to feed all declared
>> union types (or, at least the ones containing structs with common
>> initial sequences) into the alias oracle.  While unpleasant, in that
>> simply declaring a type without even declaring an object of that type
>> changes code generation, it doesn't render all type-based alias
>> analysis useless.
> 
> How do you handle this within the LTO framework?

In order to use type-based alias analysis in any LTO framework it's
necessary to save type information, and this is just more type
information.  The question is, I suppose, how to handle the scopes of
union declarations.  I'd just treat them as being global, which in
practice isn't unrealistic because such declarations are in header
files in global scope and shared anyway.

So, if any union types with a common initial sequence are declared
anywhere in a program, then their member types alias.  Alternatively,
a tighter implementation might restrict such declarations to a
compilation unit, in which case the alias oracle would scan only the
union types declared in that unit.

>>> Which means I'll refuse any patches implementing it in a way that
>>> affects default behavior.
>>
>> Maybe --pedantic or even --pedantic-aliasing?
> 
> Whatever you call it I doubt any working solution will fit nicely
> into our existing TBAA framework.

Well, perhaps not, but this is the language specification.

> When I read the language text then a union declaration in between
> two accesses will change the semantic of the second?

Not necessarily.  It would be correct to collect all union
declarations at the end of parsing and then use those to feed the
alias oracle.  There's no actual need to restrict their scope.  Sure,
it would lead to GCC being somewhat over-cautious, but that's OK.

[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
(In reply to romain.naour from comment #16)
> Hi,
> 
> gcc 7.3.0 is affected by this bug but only on microblaze architecture, see
> [1].
> Do you plan to backport this patch on gcc 7.x?
> It is safe to do so without take the risk to break something with other
> architecture or optimization level?
> 
> Best regards,
> Romain
> 
> [1] http://lists.busybox.net/pipermail/buildroot/2018-April/220156.html

The bug isn't a regression so technically it doesn't qualify.  OTOH it
looks reasonably safe to backport and the bug is annoying.  Jakub, would
you be ok with a backport?

[Bug go/85429] Several gotools tests FAIL with Solaris as

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Ian Lance Taylor  ---
> Do you think you could work out a patch that handles the various different
> cases?

Sure, if I can figure out how to determine whether or not gas is in use.

[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules

[ixsci at yandex dot ru]

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

--- Comment #2 from Evgeniy Shcherbina  ---
There is 2 parameter calculations: "first" and "second", no matter what is
evaluated first or second, the "first" parameter should be initialized with `i
= 1`, and "second" with `i = 2`. So "first" should always be equal to 1 and
"second" to 2. Currently it works as if the value assignment to parameters is
done after the both arguments are calculated which to my knowledge is wrong.

Argument calculation and parameter assignment is an atomic step as far as other
parameters are concerned.

[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer

[romain.naour at smile dot fr]

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

--- Comment #16 from romain.naour at smile dot fr ---
Hi,

gcc 7.3.0 is affected by this bug but only on microblaze architecture, see [1].
Do you plan to backport this patch on gcc 7.x?
It is safe to do so without take the risk to break something with other
architecture or optimization level?

Best regards,
Romain

[1] http://lists.busybox.net/pipermail/buildroot/2018-April/220156.html

[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 30 08:18:03 2018
New Revision: 259755

URL: https://gcc.gnu.org/viewcvs?rev=259755=gcc=rev
Log:
2018-04-30  Richard Biener  

PR bootstrap/85571
* Makefile.tpl (STAGE3_CFLAGS): Use -fchecking=1.
(STAGE3_TFLAGS): Likewise.
(STAGEtrain_CFLAGS): Filter out -fchecking=1.
(STAGEtrain_TFLAGS): Likewise.
* Makefile.in: Regenerate.

* dwarf2out.c (gen_producer_string): Ignore -fchecking[=].

Modified:
trunk/ChangeLog
trunk/Makefile.in
trunk/Makefile.tpl
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-30
  Component|lto |bootstrap
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|ltobootstrap miscompare |[9 Regression]
   |with trunk and x86-64   |non-bootstrap-debug
   ||miscompare with trunk
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Happens as soon as we compare debug info thus any build-config
besides bootstrap-debug is affected.  Caused by

2018-04-26  Richard Biener  

* Makefile.tpl (STAGE1_TFLAGS): Add -fno-checking.
(STAGE2_CFLAGS): Likewise.
(STAGE2_TFLAGS): Likewise.
(STAGE3_CFLAGS): Add -fchecking.
(STAGE3_TFLAGS): Likewise.
(STAGEtrain_CFLAGS): Filter out -fchecking.
(STAGEtrain_TFLAGS): Likewise.
* Makefile.in: Re-generate.

I'm testing a (first step) fix.

[Bug middle-end/85567] [7/8/9 Regression] internal compiler error: in gimplify_modify_expr, at gimplify.c:5797 when using sincos()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-30
  Known to work||6.4.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.4
Summary|internal compiler error: in |[7/8/9 Regression] internal
   |gimplify_modify_expr, at|compiler error: in
   |gimplify.c:5797 when using  |gimplify_modify_expr, at
   |sincos()|gimplify.c:5797 when using
   ||sincos()
 Ever confirmed|0   |1
  Known to fail||7.1.0, 8.0.1

--- Comment #1 from Richard Biener  ---
Confirmed.  Happens during inlining when folding

# .MEM = VDEF <.MEM>
sincos (x_2(D), sinx_3(D), cosx_4(D));

which runs through the GENERIC call folder which replaces sincos with
cexpi:

*sinx_3(D) = IMAGPART_EXPR >;, *cosx_4(D)
= REALPART_EXPR >;

Mine.

[Bug middle-end/85563] [8/9 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|c   |middle-end
   Target Milestone|--- |8.2
Summary|[8 regression]  |[8/9 regression]
   |-Wmaybe-uninitialized false |-Wmaybe-uninitialized false
   |alarm regression with   |alarm regression with
   |__builtin_unreachable and   |__builtin_unreachable and
   |GCC 8   |GCC 8

[Bug middle-end/85560] Missed optimization in niter analysis for bit-by-bit variable zeroing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-30
  Component|rtl-optimization|middle-end
Summary|Missed optimization in  |Missed optimization in
   |bit-by-bit variable zeroing |niter analysis for
   ||bit-by-bit variable zeroing
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  GCC fails to prove the loop is finite.  This is a niter / SCEV
analysis issue.  It's a bit convoluted case so I'm not sure how we can handle
this easily.  GIMPLE:

   [local count: 955630224]:
  # a_10 = PHI 
  # bits_11 = PHI <1(2), bits_7(3)>
  _1 = ~bits_11;
  a_6 = _1 & a_10;
  bits_7 = bits_11 << 1;
  if (a_6 == 0)
goto ; [11.00%]
  else
goto ; [89.00%]

we do have the force-simulation code which in theory could also be used
to compute an upper bound rather than an exact niter count.  But then for
this case it needs to maintain fuzzy lattices (for bits).

[Bug c++/85558] ICE in make_rtl_for_nonlocal_decl when using static member of template class

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-30
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  clang complains:

t.C:4:17: error: friend declaration specifying a default argument must be a
  definition
friend void doInitUser(bool = triggerBug::doInit);
^

[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-30
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
If they are indeterminately sequenced then 2 is a valid result, no?  4 would be
only required if evaluation order is right-to-left.

[Bug sanitizer/85556] attribute no_sanitize does not accept multiple options as documented

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||documentation,
   ||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-30
 Ever confirmed|0   |1

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

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/85275] copyheader peels off almost the entire iteration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/85275] copyheader peels off almost the entire iteration

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 30 07:23:36 2018
New Revision: 259754

URL: https://gcc.gnu.org/viewcvs?rev=259754=gcc=rev
Log:
2018-04-30  Richard Biener  

PR tree-optimization/28364
PR tree-optimization/85275
* tree-ssa-loop-ch.c (ch_base::copy_headers): Stop after
copying first exit test.

* gcc.dg/tree-ssa/copy-headers-5.c: New testcase.
* gcc.dg/tree-ssa/predcom-8.c: Likewise.
* gcc.dg/tree-ssa/cunroll-13.c: Rewrite to gimple testcase.
* gcc.dg/tree-ssa/ivopt_mult_1.c: XFAIL.
* gcc.dg/tree-ssa/ivopt_mult_1g.c: Add gimple variant that
still passes.
* gcc.dg/tree-ssa/ivopt_mult_2.c: XFAIL.
* gcc.dg/tree-ssa/ivopt_mult_2g.c: Add gimple variant that
still passes.
* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust.
* gcc.dg/tree-ssa/20030710-1.c: Likewise.
* gcc.dg/tree-ssa/20030711-1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_1g.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_2g.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030710-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030711-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-13.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
trunk/gcc/tree-ssa-loop-ch.c

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

[rguenth at gcc dot gnu.org]

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

--- Comment #33 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 30 07:23:36 2018
New Revision: 259754

URL: https://gcc.gnu.org/viewcvs?rev=259754=gcc=rev
Log:
2018-04-30  Richard Biener  

PR tree-optimization/28364
PR tree-optimization/85275
* tree-ssa-loop-ch.c (ch_base::copy_headers): Stop after
copying first exit test.

* gcc.dg/tree-ssa/copy-headers-5.c: New testcase.
* gcc.dg/tree-ssa/predcom-8.c: Likewise.
* gcc.dg/tree-ssa/cunroll-13.c: Rewrite to gimple testcase.
* gcc.dg/tree-ssa/ivopt_mult_1.c: XFAIL.
* gcc.dg/tree-ssa/ivopt_mult_1g.c: Add gimple variant that
still passes.
* gcc.dg/tree-ssa/ivopt_mult_2.c: XFAIL.
* gcc.dg/tree-ssa/ivopt_mult_2g.c: Add gimple variant that
still passes.
* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust.
* gcc.dg/tree-ssa/20030710-1.c: Likewise.
* gcc.dg/tree-ssa/20030711-1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_1g.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_2g.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030710-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030711-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-13.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
trunk/gcc/tree-ssa-loop-ch.c

[Bug rtl-optimization/84842] [7/8/9 Regression] ICE in verify_target_availability, at sel-sched.c:1569

[amonakov at gcc dot gnu.org]

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

--- Comment #14 from Alexander Monakov  ---
Thanks. I think the root cause on this x86_64 testcase is different.

Arseny, in the meantime if by chance you have another x86_64 variant of this
failure that doesn't require -funroll-all-loops, please post it as well.