[Bug c++/85027] New: ICE on invalid C++ code: in instantiate_type, at cp/class.c:8062

[su at cs dot ucdavis.edu]

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

Bug ID: 85027
   Summary: ICE on invalid C++ code: in instantiate_type, at
cp/class.c:8062
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It seems to affect all versions since at least as early as 4.x. 

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/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 8.0.1 20180321 (experimental) [trunk revision 258722] (GCC)
$
$ g++tk tmp.cpp
tmp.cpp:3:18: internal compiler error: in instantiate_type, at cp/class.c:8062
 int t = A::A ? : 0;
  ^
0x6f4360 instantiate_type(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/class.c:8062
0x6cffea perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc-source-trunk/gcc/cp/call.c:10628
0x6dfc83 build_conditional_expr_1
../../gcc-source-trunk/gcc/cp/call.c:4962
0x6e1b2c build_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
../../gcc-source-trunk/gcc/cp/call.c:5399
0x90b513 build_x_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
../../gcc-source-trunk/gcc/cp/typeck.c:6565
0x810ee3 cp_parser_question_colon_clause
../../gcc-source-trunk/gcc/cp/parser.c:9456
0x8100c6 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9492
0x8110b3 cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9770
0x8115d7 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:21928
0x8147cb cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:21868
0x8385d3 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19677
0x83a1bf cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:13065
0x83b108 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12883
0x847034 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12780
0x8459b6 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12656
0x845cd3 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4561
0x845cd3 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:39017
0x98fe15 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1132
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$





struct A { static int a; };

// should have been: 
// int t = A::a ? : 0;
int t = A::A ? : 0;

[Bug fortran/70870] Segmentation violation in gfc_assign_data_value

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
Hmm.

[Bug fortran/77941] ICE in expand_expr_addr_expr_1, at expr.c:7805

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
The code in comment #1 compiles with trunk on x86_64-*-freebsd.
I can even start the executable, but killed it as I have no
need to exhaust memory on my sytem.  As the ICE is gone
(probably related to Janne's charlen patch), I think this
can be closed.

[Bug c++/84942] [6/7/8 Regression] internal compiler error: in fold_convert_const_int_from_real, at fold-const.c:2011

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 CC||aoliva at gcc dot gnu.org
 Ever confirmed|1   |0

--- Comment #4 from Alexandre Oliva  ---
This patch fixes the 'auto' parsing problem:
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01141.html

[Bug target/85026] New: [7 Regression] Error: branch out of range on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

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

Bug ID: 85026
   Summary: [7 Regression] Error: branch out of range on
arm-linux-gnueabihf
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

[seen when building the simutrans package on Debian/Ubuntu armhf], can be
worked around building with -O1. works with the gcc-6-branch and current trunk.
successfully built with GCC 7.1 as well.

$cat wegbauer.ii
template  class a;
class b;
struct c {
  typedef a 
};
template  struct e { typedef typename d::f iter; };
class h {
public:
  void __attribute__((noreturn)) i();
} ab;
template  class a {
public:
  typedef b *f;
  b [](unsigned m) {
if (ac)
  ab.i();
return ad[m];
  }
  f n() { return ad; }
  f m_fn3();
  b *ad;
  unsigned ac;
};
class b {
public:
  short j;
  short k;
  signed l;
} __attribute__((__packed__));
void o(a , b , b ) {
  p2 = p = m[0];
  if (bool at = false)
;
  else
for (c::g au(m);; at = true)
  if (bool av = false)
;
  else
for (e::iter aw = au.n(), ax = au.m_fn3(); ax;
 av ? (void)0 : (void)0)
  if (bool ay = 0)
;
  else
for (b az = *aw; !ay; ay = true) {
  if (p2.j)
p2.j = az.j;
  else if (p.j)
p.j = az.j;
  if (p2.k)
p2.k = az.k;
  else if (az.k > p.k)
p.k = az.k;
  if (az.l < p2.l)
if (az.l > p.l)
  p.l = az.l;
}
}

$ g++-7 -std=gnu++11 -Wall -O2 -fstack-protector-strong -c wegbauer.ii 
/tmp/ccqJ02vk.s: Assembler messages:
/tmp/ccqJ02vk.s:30: Error: branch out of range

GCC configured with
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-objc-gc=auto --enable-multiarch --enable-multilib
--disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16
--with-float=hard --with-mode=thumb --disable-werror --enable-multilib
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf

[Bug c++/84943] [8 Regression] internal compiler error: in build_call_a, at cp/call.c:374

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #3 from Alexandre Oliva  ---
Created attachment 43729
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43729=edit
candidate patch

Mine.  Patch I'm testing

[Bug c++/81311] [7/8 Regression] An std::ref argument calls copy constructor instead of template constructor in C++17 mode

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Mar 22 03:53:19 2018
New Revision: 258755

URL: https://gcc.gnu.org/viewcvs?rev=258755=gcc=rev
Log:
PR c++/81311 - wrong C++17 overload resolution.

* call.c (build_user_type_conversion_1): Remove C++17 code.
(conv_binds_ref_to_prvalue): New.
(build_over_call): Handle C++17 copy elision.
(build_special_member_call): Only do C++17 copy elision here if the
argument is already the right type.

Added:
trunk/gcc/testsuite/g++.dg/overload/conv-op2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c/82967] "did you mean" suggestions are way too suggestive

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-22
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug target/85025] New: libgcc/config/i386/shadow-stack-unwind.h is wrong

[hjl.tools at gmail dot com]

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

Bug ID: 85025
   Summary: libgcc/config/i386/shadow-stack-unwind.h is wrong
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
  Target Milestone: ---

libgcc/config/i386/shadow-stack-unwind.h has

/* Unwind the shadow stack for EH.  */
#undef _Unwind_Frames_Extra
#define _Unwind_Frames_Extra(x) \
  do\
{   \
  _Unwind_Word ssp = _get_ssp ();   \
  if (ssp != 0) \
{   \
  _Unwind_Word tmp = (x);   \
  while (tmp > 255) \
{   \
  _inc_ssp (tmp);   \
^^^ This should be 255.
  tmp -= 255;   \
}   \
  _inc_ssp (tmp);   \
}   \
}   \
while (0)

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #13 from Steve Kargl  ---
On Thu, Mar 22, 2018 at 12:44:25AM +, w.clodius at icloud dot com wrote:
> --- Comment #12 from William Clodius  ---
> FWIW I was told on comp.lang.fortran that the code is erroneous because of
> 
> "The error message doesn't make much sense to me, but I think Note 12.2 
> in section 12.4.3.1 contains a clue to what's going on. It states: "
> 
> "An interface body cannot be used to describe the interface of an 
> internal procedure, a module procedure that is not a separate module 
> procedure, or an intrinsic procedure because the interfaces of such 
> procedures are already explicit.” 

gfortran was not checking

  /* C1246 (R1225) MODULE shall appear only in the function-stmt or
 subroutine-stmt of a module subprogram or of a nonabstract interface
 body that is declared in the scoping unit of a module or submodule.  */

so you had invalid code reaching other parts of the compiler.  It
still reaches that part because gfortran tries it's best to make sense
of possibly invalid code and continues to run a sequence of matchers.  It
queues up error messages.  It then spews them to the terminal.  Invalid
code may lead to an appropriate error message and a number of run-on
nonsense error messages.  It may also lead to an erronous error message
because it was queued by a previous matcher and not cleared.

[Bug go/85024] applyRelocations not implemented for alpha-linux-gnu

[amu at alum dot mit.edu]

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

--- Comment #2 from Aaron M. Ucko  ---
Great, thanks!  FTR, I'm fine without a backport here.

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[w.clodius at icloud dot com]

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

--- Comment #12 from William Clodius  ---
FWIW I was told on comp.lang.fortran that the code is erroneous because of

"The error message doesn't make much sense to me, but I think Note 12.2 
in section 12.4.3.1 contains a clue to what's going on. It states: "

"An interface body cannot be used to describe the interface of an 
internal procedure, a module procedure that is not a separate module 
procedure, or an intrinsic procedure because the interfaces of such 
procedures are already explicit.” 

Still the wording of the original error message suggests that there is an
inconsistency in the matching process.


> On Mar 21, 2018, at 2:24 PM, sgk at troutmask dot apl.washington.edu 
>  wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84922
> 
> --- Comment #8 from Steve Kargl  ---
> On Wed, Mar 21, 2018 at 08:11:29PM +, w.clodius at icloud dot com wrote:
>> --- Comment #6 from William Clodius  ---
>> My version of gfortran, 7.1, doesn’t give the first message, which is 
>> correct.
>> The second message is incorrect. Either the clashing procedures should not be
>> compared further, or the comparison of the shapes of the arguments should 
>> find
>> that they match.
> 
> Of course, 7.1 does give the first message, as I just fixed
> the issue.  But, I need to pull out a copy of the Standard
> to make sure the patch is correct.
> 
> One still gets the second error message as gfortran runs
> a sequence of matchers in parse the code.  She issues
> all errors that she finds, where some are run-on errors.
> Fix the first and others go away.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug go/85024] applyRelocations not implemented for alpha-linux-gnu

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
This was fixed on mainline by https://golang.org/cl/46391 aka
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01505.html.  The fix will be in
GCC 8.  It would likely to be easy to backport the patch to GCC 7.

[Bug c++/84269] More suggestions for missing #include

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
Another one, from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82967#c1

#include 

void test (float pf, float inff)
{
  assert (pf == inff);
}


: In function 'test':
:5:3: warning: implicit declaration of function 'assert'; did you mean
'sqrt'? [-Wimplicit-function-declaration]
   assert (pf == inff);
   ^~
   sqrt

We should suggest including  for this.

[Bug c/82967] "did you mean" suggestions are way too suggestive

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

--- Comment #1 from David Malcolm  ---
Another example:

#include 

void test (float pf, float inff)
{
  assert (pf == inff);
}


: In function 'test':
:5:3: warning: implicit declaration of function 'assert'; did you mean
'sqrt'? [-Wimplicit-function-declaration]
   assert (pf == inff);
   ^~
   sqrt

(ideally we ought to suggest including  for this one, but even so,
the suggestion is unreasonable)

[Bug fortran/65428] ICE on nest array constructor

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Francois-Xavier Coudert from comment #1)
> The original example is Fortran 2003 (array constructor with type
> specification). Here is a pure Fortran 95 example, which is also an
> ice-on-valid-code:
> 
>   integer :: i
>   print *, (/ (/ (i, i=1,0) /) /)
>   end
> 

I looked at this quickly.  It seems the reduction of the
inner array constructor to a zero size array does not set
ts.type to BT_INTEGER or any other type.  It is left as
BT_UNKNOWN.  So, when the second array constructor is
handed a zero sized array with unknown type, gfortran hits
gcc_unreachable() in trans-types.c(gfc_typenode_for_spec).

Changing the above code to

  integer :: i
  print *, (/ integer :: (/ (i, i = 1, 0) /) /)
  end

one gets the right answer.  So, this PR is fixed by
finding where to set the type to the implied-do-objects
type.

[Bug go/85024] New: applyRelocations not implemented for alpha-linux-gnu

[ucko at debian dot org]

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

Bug ID: 85024
   Summary: applyRelocations not implemented for alpha-linux-gnu
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ucko at debian dot org
CC: cmang at google dot com
  Target Milestone: ---

As seen in
https://buildd.debian.org/status/fetch.php?pkg=debos=alpha=1.0.0%2Bgit20180112.6e577d4-1=1519745141=0,
applyRelocations is not implemented for alpha-linux-gnu, at least as of
Debian's 7.3.0-5:

# github.com/sjoerdsimons/ostree-go/pkg/glibobject
cannot load DWARF output from
$WORK/github.com/sjoerdsimons/ostree-go/pkg/glibobject/_obj//_cgo_.o:
applyRelocations: not implemented

Could you please take a look?  https://github.com/golang/go/issues/18959
appears related, but claims to have been already fixed for gccgo, though maybe
not on alpha.

Thanks!

[Bug tree-optimization/84956] ICE in replace_block_by, at tree-ssa-tail-merge.c:1546

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)
> Created attachment 43722 [details]
> Tentative patch

Bootstrapped and reg-tested on x86_64, no issues found.

[Bug c++/71965] [6/7/8 regression] [concepts] Substitution error *after* failure to satisfy an earlier constraint

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Keywords||deferred
   Assignee|aoliva at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #10 from Alexandre Oliva  ---
Ok, the work-around is in place, the concepts implementation proper remains
lacking but fixing it is too much of a revamp for GCC 8, so I'm marking this
bug as deferred.

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[kargl at gcc dot gnu.org]

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

--- Comment #11 from kargl at gcc dot gnu.org ---
Patch submitted.

[Bug c/84999] [7 Regression] ICE in make_vector_type, at tree.c:9561

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE in |[7 Regression] ICE in
   |make_vector_type, at|make_vector_type, at
   |tree.c:9561 |tree.c:9561

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[joseph at codesourcery dot com]

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

--- Comment #12 from joseph at codesourcery dot com  ---
On Wed, 21 Mar 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> Joseph, any suggestions?  You mentioned that older versions of glibc
> didn't provide 16-byte alignment in i386 malloc; maybe there are other
> systems with the same issue that could equally benefit from some fix?

The fix in glibc was to increase malloc alignment for i386.  This is an 
area where properly supporting a feature (_Float128 and _Decimal128, both 
of which are 16-byte aligned on i386) requires cooperation between the 
compiler and library - in this case, even without other library support 
for those types, users can still legitimately expect memory from malloc to 
be suitably aligned for them, and for max_align_t to have suitable 
alignment for them.

[Bug c++/84642] [6/7/8 Regression] ICE: segfault reading through NULL current_template_parms in synthesize_implicit_template_parm

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Mar 21 22:08:19 2018
New Revision: 258748

URL: https://gcc.gnu.org/viewcvs?rev=258748=gcc=rev
Log:
[PR c++/84610,84642] recover from implicit template parms gracefully

If we get a parse error during an attempted fully implicit function
template parse, and need to skip to the end of the statement or block,
we may discard the function parms scope rather than the enclosing
injected implicit template parms scope.  If we rollback a tentative
parse and try something else, we'll no longer be in a function parms
scope, but rather in a template parms scope, but we may still attempt
to synthesize implicit template parms and then fail the assert that
checks we're in a function parms scope.

This patch introduces an alternative to
finish_fully_implicit_template_p, to be used during error recovery,
that floats the implicit template parm scope to the top so that it
gets discarded as we finish and discard the failed implicit template
data, while other scopes are retained as expected.  It also clears the
implicit template parser data as we finish the template, so that it
doesn't linger on referencing discarded or used scopes and parms.

for gcc/cp/ChangeLog

PR c++/84610
PR c++/84642
* parser.c (abort_fully_implicit_template_p): New.
(cp_parser_skip_to_end_of_statement): Use it.
(cp_parser_skip_to_end_of_block_or_statement): Likewise.
(finish_fully_implicit_template_p): Clear
implicit_template_parms and implicit_template_scope.

for  gcc/testsuite/ChangeLog

PR c++/84610
PR c++/84642
* g++.dg/cpp0x/pr84610.C: New.
* g++.dg/cpp0x/pr84642.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr84610.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr84642.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71965] [6/7/8 regression] [concepts] Substitution error *after* failure to satisfy an earlier constraint

[aoliva at gcc dot gnu.org]

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

--- Comment #9 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Mar 21 22:08:34 2018
New Revision: 258749

URL: https://gcc.gnu.org/viewcvs?rev=258749=gcc=rev
Log:
[PR c++/71965] silence multi-dim array init sorry without tf_error

We shouldn't substitute templates into short-circuited-out concepts
constraints, but we do, and to add insult to injury, we issue a
sorry() error when a concept that shouldn't even have been substituted
attempts to perform a multi-dimensional array initialization with a
new{} expression.

Although fixing the requirements short-circuiting is probably too
risky at this point, we can get closer to the intended effect by
silencing that sorry just as we silence other errors.

for  gcc/cp/ChangeLog

PR c++/71965
* init.c (build_vec_init): Silence error, former sorry,
without tf_error.

for  gcc/testsuite/ChangeLog

PR c++/71965
* g++.dg/concepts/pr71965.C: New.

Added:
trunk/gcc/testsuite/g++.dg/concepts/pr71965.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84610] [6/7/8 Regression] ICE in synthesize_implicit_template_parm, at cp/parser.c:38843

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Mar 21 22:08:19 2018
New Revision: 258748

URL: https://gcc.gnu.org/viewcvs?rev=258748=gcc=rev
Log:
[PR c++/84610,84642] recover from implicit template parms gracefully

If we get a parse error during an attempted fully implicit function
template parse, and need to skip to the end of the statement or block,
we may discard the function parms scope rather than the enclosing
injected implicit template parms scope.  If we rollback a tentative
parse and try something else, we'll no longer be in a function parms
scope, but rather in a template parms scope, but we may still attempt
to synthesize implicit template parms and then fail the assert that
checks we're in a function parms scope.

This patch introduces an alternative to
finish_fully_implicit_template_p, to be used during error recovery,
that floats the implicit template parm scope to the top so that it
gets discarded as we finish and discard the failed implicit template
data, while other scopes are retained as expected.  It also clears the
implicit template parser data as we finish the template, so that it
doesn't linger on referencing discarded or used scopes and parms.

for gcc/cp/ChangeLog

PR c++/84610
PR c++/84642
* parser.c (abort_fully_implicit_template_p): New.
(cp_parser_skip_to_end_of_statement): Use it.
(cp_parser_skip_to_end_of_block_or_statement): Likewise.
(finish_fully_implicit_template_p): Clear
implicit_template_parms and implicit_template_scope.

for  gcc/testsuite/ChangeLog

PR c++/84610
PR c++/84642
* g++.dg/cpp0x/pr84610.C: New.
* g++.dg/cpp0x/pr84642.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr84610.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr84642.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/84997] Optimize integer operations on floating point constants without -ffast-math

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
On Wed, 21 Mar 2018, antoshkka at gmail dot com wrote:

> unsigned test02(unsigned lhs) {
> return lhs + 2.0; // No signed overflow
> }

If lhs is UINT_MAX or UINT_MAX - 1, the conversion from double to unsigned 
should raise FE_INVALID, i.e. optimizing to integer addition is only valid 
for -fno-trapping-math.

[Bug middle-end/84997] Optimize integer operations on floating point constants without -ffast-math

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Wed, 21 Mar 2018, rguenth at gcc dot gnu.org wrote:

> > That would need -fno-trapping-math, because if the addition results in a 
> > double value larger than INT_MAX, under Annex F the conversion back to int 
> > is defined to raise FE_INVALID along with producing an unspecified value.
> 
> If it produces an unspecified value it doesn't raise undefined behavior, 
> right?

In the presence of Annex F, it doesn't raise undefined behavior.

In the absence of Annex F it does raise undefined behavior (but I don't 
think we want -fno-trapping-math to mean it's undefined, just that the 
FE_INVALID exception might be missing).

[Bug c/84999] [7/8 Regression] ICE in make_vector_type, at tree.c:9561

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 21 21:48:47 2018
New Revision: 258747

URL: https://gcc.gnu.org/viewcvs?rev=258747=gcc=rev
Log:
PR c/84999
* c-typeck.c (build_binary_op): If c_common_type_for_size fails when
building vector comparison, diagnose it and return error_mark_node.

* c-c++-common/pr84999.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr84999.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[bergner at gcc dot gnu.org]

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

--- Comment #24 from Peter Bergner  ---
(In reply to Peter Bergner from comment #23)
> This regtested fine on BE for me with no regressions.  My LE
> bootstrap/regtest is still running.

My LE bootstrap and regtesting were clean too.  Just waiting on Kaushik to
verify the patch fixes the ICE on GCC 7.

[Bug c++/84972] [6/7 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:5545

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE: |[6/7 Regression] ICE: tree
   |tree check: expected class  |check: expected class
   |'type', have 'exceptional'  |'type', have 'exceptional'
   |(error_mark) in |(error_mark) in
   |extended_tree, at   |extended_tree, at
   |tree.h:5545 |tree.h:5545

--- Comment #10 from Paolo Carlini  ---
Fixed in trunk.

[Bug c++/84972] [6/7/8 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:5545

[paolo at gcc dot gnu.org]

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

--- Comment #9 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Mar 21 21:19:03 2018
New Revision: 258746

URL: https://gcc.gnu.org/viewcvs?rev=258746=gcc=rev
Log:
/cp
2018-03-21  Paolo Carlini  

PR c++/84972
* decl.c (maybe_deduce_size_from_array_init): Set TREE_TYPE to
error_mark_node when check_array_designated_initializer fails.

/testsuite
2018-03-21  Paolo Carlini  

PR c++/84972
* g++.dg/ext/desig10.C: New.

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

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Wed, Mar 21, 2018 at 01:23:32PM -0700, Steve Kargl wrote:
> On Wed, Mar 21, 2018 at 08:11:29PM +, w.clodius at icloud dot com wrote:
> > --- Comment #6 from William Clodius  ---
> > My version of gfortran, 7.1, doesn’t give the first message, which is 
> > correct.
> > The second message is incorrect. Either the clashing procedures should not 
> > be
> > compared further, or the comparison of the shapes of the arguments should 
> > find
> > that they match.
> 
> Of course, 7.1 does give the first message, as I just fixed

not

> the issue.  But, I need to pull out a copy of the Standard
> to make sure the patch is correct.


Whoops.

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Wed, Mar 21, 2018 at 08:15:57PM +, dominiq at lps dot ens.fr wrote:
> >subroutine copy_byte_data(data, copy)
> >1
> > Error: Shape mismatch in argument 'data' at (1)
> 
> It would be nice to skip this error.

-fmax-errors=1 will do the trick.

> > Not sure if this is correct, though.
> 
> Note that I have spent some time this afternoon marking any PR with 
> "interface"
> in the summary as blocking the meta-bug pr29670.

Some of those errors can't be fixed without a major 
rewrite of the gfortran frontend.  The problem
comes down to parsing into red-black trees is done
almost exclusively without resolution.  Attributes
for symbols get coelesced into a single gfc_symbol.

module
  dimension k(4)
  contains
function k
   real k
   k = 1
end function 
end module

These are 2 different 'k' entities.  gfortran thinks it
is a function return an array of 4 elements.

[Bug fortran/84957] [8 Regression] ICE in gfc_sym_type, at fortran/trans-types.c:2255

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Thomas Koenig  ---
Fixed, closing.

[Bug fortran/84957] [8 Regression] ICE in gfc_sym_type, at fortran/trans-types.c:2255

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Mar 21 21:12:41 2018
New Revision: 258745

URL: https://gcc.gnu.org/viewcvs?rev=258745=gcc=rev
Log:
2018-03-21  Thomas Koenig  
Harald Anlauf  

PR fortran/84957
* trans-types.c (gfc_sym_type): Do not dereference NULL pointer.

2018-03-21  Thomas Koenig  
Harald Anlauf  

PR fortran/84957
* gfortran.dg/pr84957.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr84957.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84961] [7 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE error: |[7 Regression] ICE error:
   |SSA_NAME_DEF_STMT is wrong  |SSA_NAME_DEF_STMT is wrong

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/84982] [8 Regression] logically inverting bools into local array results in bitwise negation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/84960] [8 Regression] ICE in GIMPLE pass: isolate-paths

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/84811] [8 Regression] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #27 from rsandifo at gcc dot gnu.org  
---
Patch applied.

[Bug tree-optimization/84960] [8 Regression] ICE in GIMPLE pass: isolate-paths

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 21 20:53:16 2018
New Revision: 258744

URL: https://gcc.gnu.org/viewcvs?rev=258744=gcc=rev
Log:
PR tree-optimization/84960
* tree-cfg.c (remove_bb): Don't move forced labels into bb->prev_bb
if it is ENTRY block, move them into single succ of ENTRY in that case.

* gcc.c-torture/compile/pr84960.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr84960.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug tree-optimization/84811] [8 Regression] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[rsandifo at gcc dot gnu.org]

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

--- Comment #26 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Wed Mar 21 20:52:15 2018
New Revision: 258743

URL: https://gcc.gnu.org/viewcvs?rev=258743=gcc=rev
Log:
poly_span_traits fixes (PR 84811)

This patch fixes incorrect results for HOST_WIDE_INT positions
at opposite extremes when used with HOST_WIDE_INT sizes.  It also
fixes UB when comparing such positions with unsigned HOST_WIDE_INT
sizes (although the results in that case were wrapv-correct).

2018-03-20  Richard Sandiford  

gcc/
PR tree-optimization/84811
* poly-int.h (poly_span_traits): Remove the T3 parameter and
promote HOST_WIDE_INT T2 - T1 results to unsigned HOST_WIDE_INT.
(maybe_in_range_p, known_in_range_p, ranges_known_overlap_p):
(known_subrange_p): Update accordingly.  Cast each value involved
in the size comparison, rather than casting the result of the
subtraction.

gcc/testsuite/
PR tree-optimization/84811
* gcc.dg/torture/pr84811.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr84811.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/poly-int.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84957] [8 Regression] ICE in gfc_sym_type, at fortran/trans-types.c:2255

[anlauf at gmx dot de]

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

--- Comment #3 from Harald Anlauf  ---
Patch posted at

https://gcc.gnu.org/ml/fortran/2018-03/msg00117.html

[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from Jonathan Wakely  ---
> (In reply to Jonathan Wakely from comment #9)
>> So GCC's definition of max_align_t is not consistent with malloc in Solaris
>
> Oh, I'm assuming here that the definition of max_align_t is coming from GCC's
> .

Thanks for that reminder: I'd completely forgotten about
gcc/ginclude/stddef.h and only looked at the system header.  That header
includes

  /* _Float128 is defined as a basic type, so max_align_t must be
 sufficiently aligned for it.  This code must work in C++, so we
 use __float128 here; that is only available on some
 architectures, but only on i386 is extra alignment needed for
 __float128.  */
#ifdef __i386__
  __float128 __max_align_f128
__attribute__((__aligned__(__alignof(__float128;
#endif

(which  of course doesn't have), introduced in

https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00652.html

> Wherever that max_align_t definitions comes from, it should match what malloc
> does.

I don't think that's necessarily true:

* According to the i386 psABI, p.8, Table 2.1, support for __float128 is
  optional.

* Studio 12.6 cc doesn't support it:

  https://docs.oracle.com/cd/E77782_01/html/E77792/gqexw.html#OSGCCgqexp

* Thus neither does the system malloc.  Even if this could be changed
  for (say) Solaris 11.5 (I'll check about this once discussion of this
  bug is finished), that leaves us with older Solaris versions.

As an experiment, I've disabled the __float128/i386 part of the
max_align_t definition in gcc/ginclude/stdlib.h.  Not unexpectedly, the
current test PASSes now:

-FAIL: experimental/memory_resource/resource_adaptor.cc execution test

while another FAILs:

+FAIL: gcc.dg/float128-align.c (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/floatn-align.h:17:1: error:
static assertion failed: "max_align_t must be at least as aligned as _Float*
types"

I'm uncertain how to deal with this: of course we could xfail the
current test and be done with it, but perhaps there are other options?

Joseph, any suggestions?  You mentioned that older versions of glibc
didn't provide 16-byte alignment in i386 malloc; maybe there are other
systems with the same issue that could equally benefit from some fix?

Rainer

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Wed, Mar 21, 2018 at 08:11:29PM +, w.clodius at icloud dot com wrote:
> --- Comment #6 from William Clodius  ---
> My version of gfortran, 7.1, doesn’t give the first message, which is correct.
> The second message is incorrect. Either the clashing procedures should not be
> compared further, or the comparison of the shapes of the arguments should find
> that they match.

Of course, 7.1 does give the first message, as I just fixed
the issue.  But, I need to pull out a copy of the Standard
to make sure the patch is correct.

One still gets the second error message as gfortran runs
a sequence of matchers in parse the code.  She issues
all errors that she finds, where some are run-on errors.
Fix the first and others go away.

[Bug tree-optimization/84982] [8 Regression] logically inverting bools into local array results in bitwise negation

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 21 20:20:40 2018
New Revision: 258742

URL: https://gcc.gnu.org/viewcvs?rev=258742=gcc=rev
Log:
PR tree-optimization/84982
* gimple-ssa-store-merging.c (invert_op): Handle boolean inversion
by flipping the least significant bit rather than all bits from
bitpos to bitpos + bitsize - 1.

* c-c++-common/pr84982.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr84982.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84961] [7/8 Regression] ICE error: SSA_NAME_DEF_STMT is wrong

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 21 20:19:33 2018
New Revision: 258741

URL: https://gcc.gnu.org/viewcvs?rev=258741=gcc=rev
Log:
PR c++/84961
* cp-tree.h (genericize_compound_lvalue): Declare.
* typeck.c (genericize_compound_lvalue): New function.
(unary_complex_lvalue, cp_build_modify_expr): Use it.
* semantics.c (finish_asm_stmt): Replace MODIFY_EXPR, PREINCREMENT_EXPR
and PREDECREMENT_EXPR in output and "m" constrained input operands with
COMPOUND_EXPR.  Call cxx_mark_addressable on the rightmost
COMPOUND_EXPR operand.

* c-c++-common/pr43690.c: Don't expect errors on "m" (--x) and
"m" (++x) in C++.
* g++.dg/torture/pr84961-1.C: New test.
* g++.dg/torture/pr84961-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr84961-1.C
trunk/gcc/testsuite/g++.dg/torture/pr84961-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr43690.c

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> My version of gfortran gives
>
> gfcx -c a.f90
> a.f90:4:38:
>
>module subroutine copy_byte_data(data, copy)
>  1
> a.f90:12:31:
>
>subroutine copy_byte_data(data, copy)
>   2   
> Error: Procedure 'copy_byte_data' defined in interface body at (1) clashes
> with internal procedure defined at (2)
>a.f90:12:36:

It seems your version has a non disclosed patch almost fixing this PR!-)

>subroutine copy_byte_data(data, copy)
>1
> Error: Shape mismatch in argument 'data' at (1)

It would be nice to skip this error.

> Not sure if this is correct, though.

Note that I have spent some time this afternoon marking any PR with "interface"
in the summary as blocking the meta-bug pr29670.

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[w.clodius at icloud dot com]

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

--- Comment #6 from William Clodius  ---
My version of gfortran, 7.1, doesn’t give the first message, which is correct.
The second message is incorrect. Either the clashing procedures should not be
compared further, or the comparison of the shapes of the arguments should find
that they match.

> On Mar 21, 2018, at 12:59 PM, kargl at gcc dot gnu.org 
>  wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84922
> 
> kargl at gcc dot gnu.org changed:
> 
>   What|Removed |Added
> 
> CC||kargl at gcc dot gnu.org
> 
> --- Comment #4 from kargl at gcc dot gnu.org ---
> My version of gfortran gives
> 
> gfcx -c a.f90
> a.f90:4:38:
> 
>   module subroutine copy_byte_data(data, copy)
>  1
> a.f90:12:31:
> 
>   subroutine copy_byte_data(data, copy)
>   2   
> Error: Procedure 'copy_byte_data' defined in interface body at (1) clashes 
> with
> internal procedure defined at (2)
> a.f90:12:36:
> 
>   subroutine copy_byte_data(data, copy)
>1
> Error: Shape mismatch in argument 'data' at (1)
> 
> Not sure if this is correct, though.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[w.clodius at icloud dot com]

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

--- Comment #5 from William Clodius  ---
The code is definitely invalid, but the misleading error message did result in
significant time lost by assuming the message was correct as to the problem.
Note several other attempts to fix the problem resulted in the same message. 

> On Mar 21, 2018, at 7:28 AM, dominiq at lps dot ens.fr 
>  wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84922
> 
> Dominique d'Humieres  changed:
> 
>   What|Removed |Added
> 
>   Priority|P3  |P4
> Status|UNCONFIRMED |NEW
>   Last reconfirmed||2018-03-21
>   Target Milestone|--- |8.0
> Ever confirmed|0   |1
> 
> --- Comment #3 from Dominique d'Humieres  ---
> Confirmed from 6.4.0 up to trunk (8.0). The code compiles if the interface is
> removed from the module or the subroutine copy_byte_data is moved from the
> CONTAINS to its own TU.
> 
> As hinted in comment 1, I think the code is invalid, but it should be rejected
> with a better error message.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug c++/85008] [8 Regression] internal compiler error: lang_* check: failed in decl_cloned_function_p, at cp/class.c:4577

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Wed Mar 21 19:22:10 2018
New Revision: 258738

URL: https://gcc.gnu.org/viewcvs?rev=258738=gcc=rev
Log:
[PR c++/85008] ICE looking for clone

https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01129.html
PR c++/85008
* tree.c (decl_linkage): Use DECL_CLONED_FUNCTION_P.
* decl2.c (vague_linkage_p): Likewise.

PR c++/85008
* g++.dg/pr85008.C: New.

Added:
trunk/gcc/testsuite/g++.dg/pr85008.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84912] __builtin_divde* produce Internal Compiler Error when compiled -m32

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

[Bug c++/85008] [8 Regression] internal compiler error: lang_* check: failed in decl_cloned_function_p, at cp/class.c:4577

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed r258738.

[Bug target/84912] __builtin_divde* produce Internal Compiler Error when compiled -m32

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
(In reply to Peter Bergner from comment #3)
> +  bool nonvoid = TREE_TYPE (TREE_TYPE (fndecl)) != void_type_node;

Cut and pasted too much, please ignore the unneeded line above.

[Bug target/84912] __builtin_divde* produce Internal Compiler Error when compiled -m32

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
The following patch changes the ICE to an error:

[bergner@makalu-lp1 PR84912]$ cat divde.i
long
div_de (long a, long b)
{
  return __builtin_divde (a, b);
}
[bergner@makalu-lp1 PR84912]$
/home/bergner/gcc/build/gcc-fsf-mainline-mcpu-debug/./gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-mcpu-debug/./gcc/ -m32 -O1 -S
-mcpu=power7 divde.i
divde.i: In function ‘div_de’:
divde.i:4:10: error: builtin ‘__builtin_divde’ is only valid in 64-bit mode
   return __builtin_divde (a, b);
  ^~

Ditto for the other builtins.

Index: rs6000.c
===
--- rs6000.c(revision 258722)
+++ rs6000.c(working copy)
@@ -14076,6 +14076,21 @@ rs6000_expand_binop_builtin (enum insn_c
   if (arg0 == error_mark_node || arg1 == error_mark_node)
 return const0_rtx;

+  if (!TARGET_POWERPC64
+  && (icode == CODE_FOR_dive_di
+ || icode == CODE_FOR_diveo_di
+ || icode == CODE_FOR_diveu_di
+ || icode == CODE_FOR_diveuo_di))
+{
+  tree fndecl = TREE_OPERAND (CALL_EXPR_FN (exp), 0);
+  bool nonvoid = TREE_TYPE (TREE_TYPE (fndecl)) != void_type_node;
+  enum rs6000_builtins fcode = (enum rs6000_builtins) DECL_FUNCTION_CODE
(fndecl);
+  size_t uns_fcode = (size_t)fcode;
+  const char *name = rs6000_builtin_info[uns_fcode].name;
+  error ("builtin %qs is only valid in 64-bit mode", name);
+  return const0_rtx;
+}
+
   if (icode == CODE_FOR_altivec_vcfux
   || icode == CODE_FOR_altivec_vcfsx
   || icode == CODE_FOR_altivec_vctsxs

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
I suspect __attribute__((deprecated)) doesn't work quite the way you would like
in C++ either.  It only happens to do what you expect (i.e., not trigger a
warning) in the case in comment #0 but not in others, and the difference in its
effect based on its position seems too subtle to me to be intuitive or
desirable.

$ cat u.C && gcc -S -Wall -Wextra -Wpedantic u.C
struct __attribute__((deprecated)) A { };

__attribute__((deprecated)) struct A a0;   // -Wdeprecated-declarations (C++
only)
struct A __attribute__((deprecated)) a1;   // -Wdeprecated-declarations (C++
only)
struct A a2 __attribute__((deprecated));   // no warning here (both C and C++)

u.C:3:38: warning: ‘A’ is deprecated [-Wdeprecated-declarations]
 __attribute__((deprecated)) struct A a0;   // -Wdeprecated-declarations (C++
only)
  ^~
u.C:1:36: note: declared here
 struct __attribute__((deprecated)) A { };
^
u.C:4:38: warning: ‘A’ is deprecated [-Wdeprecated-declarations]
 struct A __attribute__((deprecated)) a1;   // -Wdeprecated-declarations (C++
only)
  ^~
u.C:1:36: note: declared here
 struct __attribute__((deprecated)) A { };
^

In C, the above emits no warnings, so that would let you do what you want to do
for objects.  But it doesn't behave the same way for functions, so it doesn't
make it possible to declare deprecated API that uses a deprecated struct
without triggering a deprecated warning:

struct __attribute__((deprecated)) A { int i; };

__attribute__((deprecated)) void f (struct A);   // -Wdeprecated-declarations
void __attribute__((deprecated)) g (struct A);   // -Wdeprecated-declarations
void h (struct A) __attribute__((deprecated));   // -Wdeprecated-declarations
(C only)

u.C:3:44: warning: ‘A’ is deprecated [-Wdeprecated-declarations]
 __attribute__((deprecated)) void f (struct A);   // -Wdeprecated-declarations
^
u.C:1:36: note: declared here
 struct __attribute__((deprecated)) A { int i; };
^
u.C:4:44: warning: ‘A’ is deprecated [-Wdeprecated-declarations]
 void __attribute__((deprecated)) g (struct A);   // -Wdeprecated-declarations
^
u.C:1:36: note: declared here
 struct __attribute__((deprecated)) A { int i; };
^
u.C:5:16: warning: ‘A’ is deprecated [-Wdeprecated-declarations]
 void h (struct A) __attribute__((deprecated));   // -Wdeprecated-declarations
(C only)
^
u.C:1:36: note: declared here
 struct __attribute__((deprecated)) A { int i; };
^


I would like the attributes to work consistently regardless of their placement
(where it's allowed) and regardless of the language.  I don't yet know to what
extent that will be possible.  I hope to look into it in stage 1.

[Bug fortran/84922] fortran reports inconsistency in rank of arguments in interface and contained procedures

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
My version of gfortran gives

gfcx -c a.f90
a.f90:4:38:

   module subroutine copy_byte_data(data, copy)
  1
a.f90:12:31:

   subroutine copy_byte_data(data, copy)
   2   
Error: Procedure 'copy_byte_data' defined in interface body at (1) clashes with
internal procedure defined at (2)
a.f90:12:36:

   subroutine copy_byte_data(data, copy)
1
Error: Shape mismatch in argument 'data' at (1)

Not sure if this is correct, though.

[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c

[bergner at gcc dot gnu.org]

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

--- Comment #23 from Peter Bergner  ---
Created attachment 43728
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43728=edit
Backport of trunk patch to GCC 7

Kaushik, can you verify the attached backported patch fixes the ICE on GCC 7?

This regtested fine on BE for me with no regressions.  My LE bootstrap/regtest
is still running.

[Bug fortran/32770] [Meta-bug] -fdefault-integer-8 issues

[jb at gcc dot gnu.org]

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

Bug 84615 Summary: [8 Regression] Executable Segfault for some tests compiled 
with -m32 after r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84615

   What|Removed |Added

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

[Bug fortran/84615] [8 Regression] Executable Segfault for some tests compiled with -m32 after r256284

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #21 from Janne Blomqvist  ---
Fixed on trunk, closing.

[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins

[dilyan.palauzov at aegee dot org]

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

--- Comment #2 from Дилян Палаузов  ---
gcc-ar always uses the latest plugin:

$ cat t.c
  #include 
  int main() {
printf("Z\n");
  }

$ x86_64-pc-linux-gnu-gcc-6.4.1  -flto t.c -C -o t.o
$ strace gcc-ar rc t.a t.o   prints:
stat("/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/liblto_plugin.so",
0x7fff52b52030) = -1 ENOENT (No such file or directory)
stat("/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so",
{st_mode=S_IFREG|0755, st_size=95328, ...}) = 0
access("/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so",
R_OK) = 0

$ strace gcc-nm t.aprints:

stat("/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/liblto_plugin.so",
0x7ffd682c9970) = -1 ENOENT (N
o such file or directory)
stat("/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so",
{st_mode=S_IFREG|0755, st_size=95328, ...}) = 0
access("/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so",
R_OK) = 0

it seems that the last installed liblto_plugin.so version is used, even if old
gcc did the object file.

[Bug fortran/84615] [8 Regression] Executable Segfault for some tests compiled with -m32 after r256284

[jb at gcc dot gnu.org]

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

--- Comment #20 from Janne Blomqvist  ---
Author: jb
Date: Wed Mar 21 18:46:44 2018
New Revision: 258736

URL: https://gcc.gnu.org/viewcvs?rev=258736=gcc=rev
Log:
PR 84615 Regressions due to type mismatch with character functions

Since the kind of the hidden character length variable is not part of
the character variable definition, we must ensure that character
lengths are always of the same kind in interfaces, regardless of how
they were declared in the source. This patch ensures this when calling
a procedure.

Regtested on x86_64-pc-linux-gnu and i686-pc-linux-gnu.

gcc/fortran/ChangeLog:

2018-03-21  Janne Blomqvist  

PR fortran/84615
* trans-expr.c (gfc_conv_procedure_call): Convert charlen to
gfc_charlen_type_node when calling procedure.

gcc/testsuite/ChangeLog:

2018-03-21  Janne Blomqvist  

PR fortran/84615
* gfortran.dg/char_result_17.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/char_result_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/54551] DF resets some DEBUG_INSNs unnecessarily

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=54693
 Resolution|--- |FIXED

--- Comment #9 from Eric Gallager  ---
(In reply to Alexandre Oliva from comment #6)
> Fixed in the trunk.  Backporting to 4.7...

Since 4.7 is closed, this sounds FIXED.

[Bug rtl-optimization/47389] ICE: in calc_dfs_tree, at dominance.c:395 with -fno-combine-stack-adjustments -fno-dse -fno-tree-forwprop

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=53602
 Resolution|--- |FIXED

--- Comment #9 from Eric Gallager  ---
Sounds fixed, since the branches being discussed for backporting are closed.

[Bug c++/84994] Missing accessor hint for private field at -O1 and above when -g is enabled

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|9.0 |8.0

[Bug c++/84994] Missing accessor hint for private field at -O1 and above when -g is enabled

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by r258731.

[Bug c++/84994] Missing accessor hint for private field at -O1 and above when -g is enabled

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Wed Mar 21 18:21:39 2018
New Revision: 258731

URL: https://gcc.gnu.org/viewcvs?rev=258731=gcc=rev
Log:
C++: show private field accessor hints with -g and optimization (PR c++/84994)

gcc/cp/ChangeLog:
PR c++/84994
* constexpr.c (constexpr_fn_retval): Make non-"static".
* cp-tree.h (constexpr_fn_retval): New decl.
* search.c (direct_accessor_p): Update leading comment.
(reference_accessor_p): Likewise.
(field_accessor_p): Replace check that function body is a
RETURN_EXPR with a call to constexpr_fn_retval.  Fix
indentation of "field_type" decl.

gcc/testsuite/ChangeLog:
PR c++/84994
* g++.dg/other/accessor-fixits-1.C: Move to...
* g++.dg/torture/accessor-fixits-1.C: ...here.
* g++.dg/other/accessor-fixits-2.C: Move to...
* g++.dg/torture/accessor-fixits-2.C: ...here.
* g++.dg/other/accessor-fixits-3.C: Move to...
* g++.dg/torture/accessor-fixits-3.C: ...here.
* g++.dg/other/accessor-fixits-4.C: Move to...
* g++.dg/torture/accessor-fixits-4.C: ...here.
* g++.dg/other/accessor-fixits-5.C: Move to...
* g++.dg/torture/accessor-fixits-5.C: ...here.
* g++.dg/torture/accessor-fixits-6.C: New testcase.
* g++.dg/torture/accessor-fixits-7.C: New testcase.
* g++.dg/torture/accessor-fixits-8.C: New testcase.


Added:
trunk/gcc/testsuite/g++.dg/torture/accessor-fixits-1.C
trunk/gcc/testsuite/g++.dg/torture/accessor-fixits-2.C
trunk/gcc/testsuite/g++.dg/torture/accessor-fixits-3.C
trunk/gcc/testsuite/g++.dg/torture/accessor-fixits-4.C
trunk/gcc/testsuite/g++.dg/torture/accessor-fixits-5.C
trunk/gcc/testsuite/g++.dg/torture/accessor-fixits-6.C
trunk/gcc/testsuite/g++.dg/torture/accessor-fixits-7.C
trunk/gcc/testsuite/g++.dg/torture/accessor-fixits-8.C
Removed:
trunk/gcc/testsuite/g++.dg/other/accessor-fixits-1.C
trunk/gcc/testsuite/g++.dg/other/accessor-fixits-2.C
trunk/gcc/testsuite/g++.dg/other/accessor-fixits-3.C
trunk/gcc/testsuite/g++.dg/other/accessor-fixits-4.C
trunk/gcc/testsuite/g++.dg/other/accessor-fixits-5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/search.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84926] error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64

[dilyan.palauzov at aegee dot org]

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

Дилян Палаузов  changed:

   What|Removed |Added

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

--- Comment #4 from Дилян Палаузов  ---
Why does COLLECT_GCC_OPTIONS show '-march=x86-64', but
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html does not show x86-64 as
valid option for -march?

Why doesn't 'make CFLAGS="--verbose -march=native -flto"' work, in terms of
detecting that ssse3 is available and there is no conflict?

The latter prints:



make[3]: Leaving directory '/git/postgresql/src/backend'
gcc --verbose -march=native -flto -I../../src/port -DFRONTEND
-I../../src/include  -D_GNU_SOURCE -I/usr/local/include/libxml2   -c -o
pg_crc32c_sse42.o pg_crc32c_sse42.c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: ./configure --enable-threads=posix --enable-nls
--enable-interpreter --with-system-zlib --enable-libgcj-multifile
--enable-languages=all --enable-targets=all --with-system-unwind --without-x
--with-linker-hash-style=gnu --disable-multilib --enable-shared
--with-build-config='bootstrap-lto bootstrap-O3'
Thread model: posix
gcc version 7.3.1 20180316 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-march=native' '-flto' '-I' '../../src/port' '-D'
'FRONTEND' '-I' '../../src/include' '-D' '_GNU_SOURCE' '-I'
'/usr/local/include/libxml2' '-c' '-o' 'pg_crc32c_sse42.o'
 /usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/cc1 -quiet -v -I
../../src/port -I ../../src/include -I /usr/local/include/libxml2 -imultiarch
x86_64-linux-gnu -D FRONTEND -D _GNU_SOURCE pg_crc32c_sse42.c -march=nocona
-mmmx -mno-3dnow -msse -msse2 -msse3 -mno-ssse3 -mno-sse4a -mcx16 -msahf
-mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma
-mno-fma4 -mno-xop -mno-bmi -mno-sgx -mno-bmi2 -mno-tbm -mno-avx -mno-avx2
-mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
-mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt
-mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1
-mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw
-mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps
-mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid --param
l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096
-mtune=nocona -quiet -dumpbase pg_crc32c_sse42.c -auxbase-strip
pg_crc32c_sse42.o -version -flto -o /tmp/cch1CzQr.s
GNU C11 (GCC) version 7.3.1 20180316 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180316, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 ../../src/port
 ../../src/include
 /usr/local/include/libxml2
 /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C11 (GCC) version 7.3.1 20180316 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180316, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e97c32a4d3c4d8b00665455dd270ad26
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0,
 from pg_crc32c_sse42.c:19:
pg_crc32c_sse42.c: In function ‘pg_comp_crc32c_sse42’:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:846:1: error:
inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific
option mismatch
 _mm_crc32_u64 (unsigned long long __C, unsigned long long __V)
 ^
pg_crc32c_sse42.c:37:18: note: called from here
   crc = (uint32) _mm_crc32_u64(crc, *((const uint64 *) p));
  ^
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0,
 from pg_crc32c_sse42.c:19:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:839:1: error:
inlining failed in call to always_inline ‘_mm_crc32_u32’: target specific
option mismatch
 _mm_crc32_u32 (unsigned int __C, unsigned int __V)
 ^
pg_crc32c_sse42.c:44:7: note: called from here
   crc = _mm_crc32_u32(crc, *((const unsigned int *) p));
   ^
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0,
 from 

[Bug target/84912] __builtin_divde* produce Internal Compiler Error when compiled -m32

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-21
 CC||bergner at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Peter Bergner  ---
Confirmed.

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[daniel.kruegler at googlemail dot com]

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

--- Comment #6 from Daniel Krügler  ---
(In reply to Martin Sebor from comment #5)
> Would the solution described in bug 79078 comment 14 do what you're looking
> for?

Yes, that sounds plausible. But I'm just wondering: Don't you consider the
current attribute behaviour reasonable enough to make [[deprecated]] behave
equivalent? This would solve the problem more directly and is presumably easier
to understand from a user perspective.

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Would the solution described in bug 79078 comment 14 do what you're looking
for?

[Bug c++/70410] no uninitialized variable warning if 'offsetof' is used in expression

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

--- Comment #3 from Eric Gallager  ---
(In reply to Sergey Podobry from comment #2)
> It seems to fixed since gcc6.

k, changing resolution to FIXED then.

[Bug middle-end/51982] Shrink-wrapping opportunity

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Yes, the only two calls in the resulting machine code are both to unicode_eq.

Splitting the ranges (and then assigning volatile regs to the first half)
hurts if it doesn't end up helping shrink-wrapping.

There also is the problem that some pseudos are already coalesced earlier (at
expand time even) while in fact they are independent (some will naturally end
up in r3, the return register, while others need to be non-volatile).

[Bug c++/81311] [7/8 Regression] An std::ref argument calls copy constructor instead of template constructor in C++17 mode

[jason at gcc dot gnu.org]

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

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 target/84826] ICE in extract_insn, at recog.c:2304 on arm-linux-gnueabi

[sudi at gcc dot gnu.org]

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

--- Comment #9 from sudi at gcc dot gnu.org ---
Proposed patch
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01120.html

[Bug target/83497] [8 Regression] CPU2000 172.mgrid starts failing with r254730

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Pat Haugen  ---
I have confirmed that this is indeed just a precision difference due to a
different mix and order of instructions for the computation in the RESID loop,
valid reassociation with -ffast-math. The difference is then compounded as the
benchmark iterates over the values.

The specdiff command for mgrid specifies an absolute tolerance of "-a 1e-12"
and uses the absolute difference when seeing if two values are within the
specified tolerance. In this case they were not.

[Bug jit/84288] Support jit on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  ---
Author: ro
Date: Wed Mar 21 17:39:16 2018
New Revision: 258727

URL: https://gcc.gnu.org/viewcvs?rev=258727=gcc=rev
Log:
Enable jit on Solaris: soname option and EXTRA_GCC_LIBS (PR jit/84288)

gcc/jit:
PR jit/84288
* Make-lang.in ($(LIBGCCJIT_FILENAME)): Add $(EXTRA_GCC_LIBS).

gcc:
PR jit/84288
* configure.ac (gcc_cv_ld_soname) <*-*-solaris2*>: Set.
* configure: Regenerate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure   (contents, props changed)
trunk/gcc/configure.ac
trunk/gcc/jit/ChangeLog
trunk/gcc/jit/Make-lang.in

[Bug middle-end/51982] Shrink-wrapping opportunity

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
(In reply to David Edelsohn from comment #3)
> The function lookup_unicode should be shrink-wrapped to not create a stack
> frame if unicode_eq is not called, which is the common case
> 
> if (!PyUnicode_CheckExact(key)) {
> return lookdict(mp, key, hash, value_addr);
> }

I'm guessing lookdict() above is inlined so not a call...


> i = (size_t)hash & mask;
> ep = [i];
> if (ep->me_key == NULL || ep->me_key == key) {
> *value_addr = >me_value;
> return ep;
> }
> /* - Postpone frame creation until this point. -- */
> if (ep->me_key == dummy)
> freeslot = ep;
> else {
> if (ep->me_hash == hash && unicode_eq(ep->me_key, key)) {
> *value_addr = >me_value;
> return ep;
> }
> freeslot = NULL;
> }

For us to postpone frame creation to the point you specify above, we'd need to
split all of the pseudos that are live at that point and who are live across a
call (ie, pseudos that IRA will attempt to assign to a
non-volatile/callee-saved register).  That would allow IRA to use a volatile
reg for the split pseudo above the frame setup point and a non-volatile reg for
the split pseudo after the frame setup point.
Of course we'd need to inhibit coalescing the copy away.

Doesn't IRA have code that tries to do such a thing?  /me goes off to have a
look.

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler  ---
(In reply to Martin Sebor from comment #3)
> I find the [[deprecated]] behavior for the test cases here reasonable and
> useful: the struct type is declared deprecated and so its subsequent uses
> are diagnosed.

In general I would agree, but not here, because the second usage (old2) itself
is deprecated. This is a scenario that happens rather often: An older API get's
deprecated and part of that old API was Old2 and old2. You have provided a new
API (Not shown in the examples), but for a while you want to support the old,
deprecated API. What you want to realize is that the *user* of the old API
get's the warning. But now the plain declaration of the old API get's this
warning, too. THis is IMO annoying and the attribute behaviour seems preferable
to me.

> What I think is missing is a way for the author of a deprecated type (but
> not its users) to define objects of the type without triggering the warning,
> analogous to how it can be done for functions.  

Yes, that's what I was trying to argue about above.

I would expect the following
> to do it but it doesn't:
> 
> $ cat u.C && gcc -S -Wall -Wextra -Wpedantic u.C
> struct S { };
> 
> S a [[deprecated]];// expect no warning here
> 
> struct [[deprecated]] S;   // nor here
> 
> S b;   // expect -Wdeprecated-declarations here

I agree, but this is different from my example where b itself is also declared
deprecated.

> // Expected behavior:
> 
> int f () { return 0; }
> 
> [[deprecated]] int i = f  ();   // no warning
> 
> [[deprecated]] int f ();// no warning
> 
> int j = f ();   // -Wdeprecated-declarations
> u.C:5:23: warning: type attributes ignored after type is already defined
> [-Wattributes]
>  struct [[deprecated]] S;   // nor here
>^
> u.C:18:12: warning: ‘int f()’ is deprecated [-Wdeprecated-declarations]
>  int j = f ();   // -Wdeprecated-declarations
> ^
> u.C:12:5: note: declared here
>  int f () { return 0; }
>  ^
> Daniel, does this make sense to you?

These two latter examples make sense to me, but not the behaviour for my case.

[Bug target/82989] [6/7/8 regression] Inexplicable use of NEON for 64-bit math

[sudi at gcc dot gnu.org]

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

--- Comment #22 from sudi at gcc dot gnu.org ---
Author: sudi
Date: Wed Mar 21 17:14:48 2018
New Revision: 258723

URL: https://gcc.gnu.org/viewcvs?rev=258723=gcc=rev
Log:
[ARM] Fix test pr82989.c for big endian and mthumb

The test pr82989.c which was added in one of previous commits is failing for
mthumb and big-endian configurations. The aim of this test was to check that
NEON instructions are not being used for simple shift operations. The scanning
of lsl and lsr instructions and checking its counts were just too restrictive
for different configurations. So I have now simplified the test to only check
for the absence of NEON instructions.

*** gcc/testsuite/ChangeLog ***

2018-03-21  Sudakshina Das  

PR target/82989
* gcc.target/arm/pr82989.c: Change dg scan-assembly directives.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/pr82989.c

[Bug target/84882] -mstrict-align on aarch64 should not be RejectNegative

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug c++/84968] [8 Regression] ICE in strip_typedefs_expr, at cp/tree.c:1792

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Slightly adjusted testcase, so that it is less invalid.
struct S {
  template 
  void foo ()
  try {} catch (int () noexcept (({ union B a; true; }))) {}
};

With the template  line commented out, we reject it
aggregate ‘S::foo()::B a’ has incomplete type and cannot be defined
If there is union B {}; before struct S, it is accepted both as a template or
as non-template, with union B {} a; true; in template it is error-recovery:
pr84968.C: In member function ‘void S::foo()’:
pr84968.C:4:45: error: types may not be defined in an exception-specification
   try {} catch (int () noexcept (({ union B {} a; true; }))) {}
 ^
pr84968.C:4:59: internal compiler error: in strip_typedefs_expr, at
cp/tree.c:1792
   try {} catch (int () noexcept (({ union B {} a; true; }))) {}
   ^

Apparently strip_typedef_exprs isn't prepared to handle STMT_EXPR body, in
particular STATEMENT_LIST.  Is that the way to go?

[Bug c++/79078] Warnings from deprecated attribute are too noisy

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
I think that would work well.

[Bug c++/79078] Warnings from deprecated attribute are too noisy

[msebor at gcc dot gnu.org]

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

--- Comment #14 from Martin Sebor  ---
For non-member functions that are part of a class API I would like to see about
getting the following to work for types (as it already does for functions):

1) define a class with no attribute
2) define the API that uses the class without triggering warnings
3) declare the class [[deprecated]]
4) have any subsequent uses of the class trigger warnings

Like this:

$ cat u.C && gcc -S -Wall -Wextra -Wpedantic u.C
struct A;

int f (A*);

int i = f (0);

struct A { };

int g (A); // no warning

int j = g (A ());  // no warning

struct [[deprecated]] A;   // add attribute, expect no warning

int h (A); // expect warning

u.C:13:23: warning: type attributes ignored after type is already defined
[-Wattributes]
 struct [[deprecated]] A;   // add attribute, expect no warning
   ^

Currently it doesn't work because for structs, GCC doesn't apply attributes
from declarations, only on definitions (this is bug 81756, at least in part).

Does it resolve the outstanding issues?  Are there any concerns with it?

[Bug target/83660] ICE with vec_extract inside expression statement

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
--- gcc/config/rs6000/rs6000-c.c.jj 2018-03-15 08:36:26.526776571 +0100
+++ gcc/config/rs6000/rs6000-c.c2018-03-21 17:10:04.340935624 +0100
@@ -6649,6 +6649,14 @@ altivec_resolve_overloaded_builtin (loca
   stmt = convert (innerptrtype, stmt);
   stmt = build_binary_op (loc, PLUS_EXPR, stmt, arg2, 1);
   stmt = build_indirect_ref (loc, stmt, RO_NULL);
+  if (c_dialect_cxx ())
+   {
+ /* Add a CLEANUP_POINT_EXPR for the above TARGET_EXPR, as it doesn't
+need to live after the INDIRECT_REF.  Force side-effects, so that
+it isn't optimized away.  */
+ TREE_SIDE_EFFECTS (stmt) = 1;
+ stmt = build1_loc (loc, CLEANUP_POINT_EXPR, TREE_TYPE (stmt), stmt);
+   }

   return stmt;
 }

seems to fix this, maybe in some cases it would be enough to force
TREE_SIDE_EFFECTS, e.g. on this testcase finish_stmt_expr_expr has:
  /* Wrap it in a CLEANUP_POINT_EXPR and add it to the list like a
 normal statement, but don't convert to void or actually add
 the EXPR_STMT.  */
  if (TREE_CODE (expr) != CLEANUP_POINT_EXPR)
expr = maybe_cleanup_point_expr (expr);

Without TREE_SIDE_EFFECTS though maybe_cleanup_point_expr doesn't add anything,
and even if we add it ourselves (e.g. the above patch with TREE_SIDE_EFFECTS
(stmt) = 1; removed), then cp_fold will optimize the CLEANUP_POINT_EXPR away. 
And the CLEANUP_POINT_EXPR is essential during gimplification, so that we know
where the TARGET_EXPR decl rs6000 has added actually dies and where we can emit
the clobber.

Note, for ALTIVEC_BUILTIN_VEC_INSERT it contains similar code, but I'm afraid I
have no idea where to insert that CLEANUP_POINT_EXPR, because it does:
  stmt = build_indirect_ref (loc, stmt, RO_NULL);
  stmt = build2 (MODIFY_EXPR, TREE_TYPE (stmt), stmt,
 convert (TREE_TYPE (stmt), arg0));
  stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
and decl is the TARGET_EXPRs temporary.  The return value of the builtin is
non-lvalue though, right?  So maybe just wrapping that similarly to the above
would work, or wrap the last argument of the COMPOUND_EXPR into NON_LVALUE_EXPR
or something similar first?

[Bug bootstrap/85020] [8 Regression] gcc fails to bootstrap with profiledbootstrap and --with-build-config=bootstrap-lto

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Can reproduce.  The best thing would be to place some strategic asserts in
dwarf2out.c that trigger when we output "relocations" during early dwarf out.
I'll see to that tomorrow.

Note there are some related acats FAILs that might be easier to analyze.

[Bug c++/84782] Rejects a maybe C++ code snippet

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
They don't look like duplicates to me. PR 70431 involves a union, no SFINAE,
and a completely different error message.

[Bug c++/84222] [6/7 Regression] [[deprecated]] class complains about internal class usage

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-21
 Ever confirmed|0   |1

--- Comment #10 from Martin Sebor  ---
Let me change the Status to New since it's fixed for GCC 8.

Jakub, do you expect to backport the patch to older branches?

[Bug c++/84804] [8 Regression] ICE with lambda in default argument

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Wed Mar 21 15:58:00 2018
New Revision: 258722

URL: https://gcc.gnu.org/viewcvs?rev=258722=gcc=rev
Log:
[PR c++/84804] ICE with default arg, template friend & lambda

https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01108.html
PR c++/84804
* name-lookup.c (do_pushtag): Permit lambdas to be pushed into
complete classes.


PR c++/84804
* g++.dg/lookup/pr84804.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr84804.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84804] [8 Regression] ICE with lambda in default argument

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed r258722.

[Bug c++/84782] Rejects a maybe C++ code snippet

[raphael.kubo.da.costa at intel dot com]

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

Raphael Kubo da Costa  changed:

   What|Removed |Added

 CC||raphael.kubo.da.costa@intel
   ||.com

--- Comment #3 from Raphael Kubo da Costa  ---
Given the file name used in the original report and how this bug was mentioned
in the chromium-packager mailing list, I think this is a duplicate of bug
70431.

[Bug bootstrap/85020] [8 Regression] gcc fails to bootstrap with profiledbootstrap and --with-build-config=bootstrap-lto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
 CC||rguenth at gcc dot gnu.org
Version|unknown |8.0.1
   Target Milestone|--- |8.0

--- Comment #1 from Richard Biener  ---
Somehow messes up early debug (locations are emitted early via some path). 
Trying to reproduce.

[Bug inline-asm/85022] internal compiler error: in write_dependence_p, at alias.c:3003

[vegard.nossum at oracle dot com]

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

Vegard Nossum  changed:

   What|Removed |Added

  Component|c++ |inline-asm

--- Comment #1 from Vegard Nossum  ---
Also fails for C:

struct b extern c;
void a() {
  asm("" : "+m"(c));
}

$ cc1 -O1
 a
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   


Assembling functions:
   aduring RTL pass: cse1

: In function 'a':
:4:1: internal compiler error: in write_dependence_p, at alias.c:3003
0xd58993 write_dependence_p
/home/vegard/git/gcc/gcc/alias.c:3001
0xd59d07 canon_anti_dependence(rtx_def const*, bool, rtx_def const*,
machine_mode, rtx_def*)
/home/vegard/git/gcc/gcc/alias.c:3092

[Bug target/83660] ICE with vec_extract inside expression statement

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
I think the issue is that gimplify_cleanup_point_expr when walking the
body_sequence to look for WCE stmts doesn't traverse GIMPLE_BIND sub-stmts.

Or it is not supposed to do that and the GENERIC is at fault, mis-matching
cleanup_points somehow:

 < = {
const unsigned int _B1 = 32;

<>;
*((unsigned int *) _EXPR  + 8);
  }>>;

here the outer cleanup_point is relevant, and the stmt expression generating
the GIMPLE_BIND.  Is there a cleanup_point missing in that scope?

Other than that I don't know very much of this logic.

[Bug sanitizer/85023] [8 regression] many ICE failures with asan test cases starting with r258664

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Dup.

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

[Bug sanitizer/85018] [8 Regression] Many sanitizer tests ICE since r258681

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
*** Bug 85023 has been marked as a duplicate of this bug. ***

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
I find the [[deprecated]] behavior for the test cases here reasonable and
useful: the struct type is declared deprecated and so its subsequent uses are
diagnosed.

What I think is missing is a way for the author of a deprecated type (but not
its users) to define objects of the type without triggering the warning,
analogous to how it can be done for functions.  I would expect the following to
do it but it doesn't:

$ cat u.C && gcc -S -Wall -Wextra -Wpedantic u.C
struct S { };

S a [[deprecated]];// expect no warning here

struct [[deprecated]] S;   // nor here

S b;   // expect -Wdeprecated-declarations here


// Expected behavior:

int f () { return 0; }

[[deprecated]] int i = f  ();   // no warning

[[deprecated]] int f ();// no warning

int j = f ();   // -Wdeprecated-declarations
u.C:5:23: warning: type attributes ignored after type is already defined
[-Wattributes]
 struct [[deprecated]] S;   // nor here
   ^
u.C:18:12: warning: ‘int f()’ is deprecated [-Wdeprecated-declarations]
 int j = f ();   // -Wdeprecated-declarations
^
u.C:12:5: note: declared here
 int f () { return 0; }
 ^


Daniel, does this make sense to you?

[Bug sanitizer/85023] New: [8 regression] many ICE failures with asan test cases starting with r258664

[seurer at gcc dot gnu.org]

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

Bug ID: 85023
   Summary: [8 regression] many ICE failures with asan test cases
starting with r258664
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I am seeing this on powerpc64 both be and le.  There are hundreds of these
failures for most if not all the asan test cases.  Here is one example:

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test3/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test3/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test3/gcc/testsuite/g++.dg/asan/pr78651.C
-fsanitize=address -g
-I/home/seurer/gcc/gcc-test3/gcc/testsuite/../../libsanitizer/include
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test3/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test3/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test3/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test3/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test3/libstdc++-v3/testsuite/util -fmessage-length=0 -O1
-fpic
-B/home/seurer/gcc/build/gcc-test3/powerpc64-unknown-linux-gnu/./libsanitizer/
-B/home/seurer/gcc/build/gcc-test3/powerpc64-unknown-linux-gnu/./libsanitizer/asan/
-L/home/seurer/gcc/build/gcc-test3/powerpc64-unknown-linux-gnu/./libsanitizer/asan/.libs
-L/home/seurer/gcc/build/gcc-test3/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test3/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test3/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test3/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-test3/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./pr78651.exe
/home/seurer/gcc/gcc-test3/gcc/testsuite/g++.dg/asan/pr78651.C:26:1: internal
compiler error: in assemble_variable, at varasm.c:2297
0x10ff1737 assemble_variable(tree_node*, int, int, int)
/home/seurer/gcc/gcc-test3/gcc/varasm.c:2297
0x1071667b dw2_output_indirect_constant_1
/home/seurer/gcc/gcc-test3/gcc/dwarf2asm.c:976
0x1071667b dw2_output_indirect_constants()
/home/seurer/gcc/gcc-test3/gcc/dwarf2asm.c:999


Full list of failures:

> FAIL: c-c++-common/asan/aggressive-opts.c   -O3 -fomit-frame-pointer 
> -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler 
> error)
> FAIL: c-c++-common/asan/aggressive-opts.c   -O3 -fomit-frame-pointer 
> -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler 
> error)
> FAIL: c-c++-common/asan/aggressive-opts.c   -O3 -g  (internal compiler error)
> FAIL: c-c++-common/asan/aggressive-opts.c   -O3 -g  (internal compiler error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O1  (internal compiler 
> error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O1  (internal compiler 
> error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O2  (internal compiler 
> error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O2  (internal compiler 
> error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O2 -flto 
> -fno-use-linker-plugin -flto-partition=none  (internal compiler error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O2 -flto 
> -fno-use-linker-plugin -flto-partition=none  (internal compiler error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O2 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O2 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O3 -fomit-frame-pointer 
> -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler 
> error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O3 -fomit-frame-pointer 
> -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler 
> error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O3 -g  (internal 
> compiler error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -O3 -g  (internal 
> compiler error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -Os  (internal compiler 
> error)
> FAIL: c-c++-common/asan/alloca_loop_unpoisoning.c   -Os  (internal compiler 
> error)
> FAIL: c-c++-common/asan/asan-interface-1.c   -O1  (internal compiler error)
> FAIL: c-c++-common/asan/asan-interface-1.c   -O1  (internal compiler error)
> FAIL: c-c++-common/asan/asan-interface-1.c   -O2  (internal 

[Bug c++/85014] [6/7/8 Regression] internal compiler error: in lookup_base, at cp/search.c:185

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started with r179156.

[Bug c++/85015] [8 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in build_int_cst, at tree.c:1360

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/85022] New: internal compiler error: in write_dependence_p, at alias.c:3003

[vegard.nossum at oracle dot com]

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

Bug ID: 85022
   Summary: internal compiler error: in write_dependence_p, at
alias.c:3003
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at oracle dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---

Input:

class b extern c;
void a() {
  asm("" : "+m"(c));
}

Output:

$ cc1plus -O1
 void a()
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   


Assembling functions:
   void a()during RTL pass: cse1

: In function 'void a()':
:4:1: internal compiler error: in write_dependence_p, at alias.c:3003
0x16a44f3 write_dependence_p
/home/vegard/git/gcc/gcc/alias.c:3001
0x16a5867 canon_anti_dependence(rtx_def const*, bool, rtx_def const*,
machine_mode, rtx_def*)
/home/vegard/git/gcc/gcc/alias.c:3092
0x5153789 check_dependence
/home/vegard/git/gcc/gcc/cse.c:1816
0x5153789 invalidate
/home/vegard/git/gcc/gcc/cse.c:1946
0x518e226 cse_insn
/home/vegard/git/gcc/gcc/cse.c:5832
0x519b4b7 cse_extended_basic_block
/home/vegard/git/gcc/gcc/cse.c:6610
0x519b4b7 cse_main
/home/vegard/git/gcc/gcc/cse.c:6789
0x51a15bf rest_of_handle_cse
/home/vegard/git/gcc/gcc/cse.c:7619
0x51a15bf execute
/home/vegard/git/gcc/gcc/cse.c:7662
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Version:

GNU C++14 (GCC) version 8.0.1 20180306 (experimental) (x86_64-pc-linux-gnu)

7.3.0 compiles it to just a "ret" and clang fails with:

:3:17: error: dereference of pointer to incomplete type 'class b'
  asm("" : "+m"(c));
^
:1:7: note: forward declaration of 'b'
class b extern c;
  ^
1 error generated.
Compiler returned: 1