[Bug debug/49167] dwarf marker for function return instruction

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org
   Assignee|aoliva at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Alexandre Oliva from comment #5)
> I've been working on an off on this specific issue, and on various
> surrounding infrastructure issues, for a very long time.  Right now I'm not
> specifically working on it.

ok, taking the "right now" part as the operative part and moving you from the
assignee slot to the cc list

[Bug middle-end/89725] ICE in get_fnname_from_decl, at varasm.c:1723

[amker at gcc dot gnu.org]

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

--- Comment #6 from bin cheng  ---
(In reply to Richard Biener from comment #4)
> I think the issue is that the DDR is bogus - loop interchange computes
> data-refs
> for a deeper nest (including some outer loops) than it ends up doing
> dependence checking later on.  But we have access functions analyzed with
> respect to outer loops already.
> 
> I think it would be possible to handle this in data dependence computation,
> simply treating evolutions in outer loops as invariants.  Eventually the
> access functions evolving in outer loops can also be pruned?  We can't
> really undo SCEV analysis on them.
> 
> I think that Jakubs fix is too conservative though.
> 
> Since we fail when we cannot compute the "invalid" subscript distance at the
> moment the safest fix would probably to create the DDR with the loop-nest
> we originally analyzed?  Bin?
Unfortunately No.  The access functions are analyzed wrto outer loops in order
to cache find-data-reference process, thus save compilation time.  Actually, we
end up with computing ddr wrto deeper loop_nest here because computation with
the originally analyzed loop_nest has failed.  So this change won't do anything
other than compute the same DDRs twice (and both would fail).

There may be couple ways out.
1. Cancel the data reference caching by collecting DRs for loop_nest.  At this
stage, this might be the safest fix but very expensive.
2. Fix the DDR analysis code.  For example as you suggested, or maybe we can
simply bypass the irrelevant part when computing dir/dist vector?
3. Note we already prune_data_refs_not_in_loop, we can also prune the access
functions too.  Not sure if this is feasible.  Also not sure if it's useful
enough to be exposed as an tree-data-ref.h interface.  Will have a check.


> diff --git a/gcc/tree-data-ref.h b/gcc/tree-data-ref.h
> index 11aa806a64d..54651e903ff 100644
> --- a/gcc/tree-data-ref.h
> +++ b/gcc/tree-data-ref.h
> @@ -585,6 +585,7 @@ index_in_loop_nest (int var, vec loop_nest)
>  if (loopi->num == var)
>break;
>  
> +  gcc_assert (var_index < loop_nest.length ());
>return var_index;
>  }
Guess this code should be included anyway, right?

Thanks

[Bug c++/89880] compiles code that should not be compiled

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Related to PR 86564.

This is due to https://en.wikipedia.org/wiki/Most_vexing_parse .

[Bug c++/89880] New: compiles code that should not be compiled

[tiagomacarios at gmail dot com]

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

Bug ID: 89880
   Summary: compiles code that should not be compiled
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tiagomacarios at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/4cbr24

void f()
{
int a;
int b;
bool c;
if ((!((int(bool(a))) ^ (int(bool(b && !(c))) {}
}

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[schnetter at gmail dot com]

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

--- Comment #7 from Erik Schnetter  ---
I tried adding a fixinclude that #defines _Atomic to volatile if the system
header is included from C++, and this resolved the issue for me.

A possible implementation is described here
. I plan to submit a proper patch
to GCC next week.

[Bug bootstrap/89879] GCC fails to build on macOS 10.14.4

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug bootstrap/89879] GCC fails to build on macOS 10.14.4

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Also patches go to gcc-patches@ After reading
https://gcc.gnu.org/contribute.html .

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||schnetter at gmail dot com

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

[Bug c++/89858] crash with libmpfr.so.6

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
https://www.felixcloutier.com/x86/blsr

Says BMI1 is required.

Can you provide the output of /proc/cpuinfo on the host?

[Bug bootstrap/89879] New: GCC fails to build on macOS 10.14.4

[schnetter at gmail dot com]

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

Bug ID: 89879
   Summary: GCC fails to build on macOS 10.14.4
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schnetter at gmail dot com
  Target Milestone: ---

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

After upgrading to macOS 10.14.4, GCC 8.3.0 does not build any more. The issue
is unrelated to Spack; even a vanilla GCC fails to install.

This StackExchange issue

is a description of the problem including the actual error message. The
underlying problem is that a macOS header file uses the _Atomic keyword for C++
code, although this is only a C keyword. I assume that Clang defines _Atomic
even for C++ code as extension to the C++ standard.

The proper solution is probably adding a fixinclude for GCC.

[Bug target/83531] Build broken on macOS 10.13.2

[schnetter at gmail dot com]

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

Erik Schnetter  changed:

   What|Removed |Added

 CC||schnetter at gmail dot com

--- Comment #7 from Erik Schnetter  ---
I don't think that people didn't notice. I rather think that they gave up
building the sanitizer. See also
https://github.com/spack/spack/tree/develop/var/spack/repos/builtin/packages/gcc
and
https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/gcc/darwin/headers-10.13-fix.patch
, which includes this fix automatically when GCC is built via Spack.

[Bug c++/89868] -fsanitize=address inhibits C++ unhandled exception core dump

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Actually it comes from the shell.

e.g. from bash:
  if ((WIFSTOPPED (show->status) == 0) &&
  (WIFCONTINUED (show->status) == 0) &&
  WIFCORED (show->status))
fprintf (stream, _("(core dumped) "));

As WIFCORED is set on status.

WIFCORED is really a define for WCOREDUMP.

http://man7.org/linux/man-pages/man2/waitpid.2.html

So basically the kernel does not communicate why a core is not dumped to the
waiting (parent) process.

[Bug c++/62207] [7/8/9 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in tsubst_copy, at cp/pt.c

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #7 from Paolo Carlini  ---
Looking into it.

[Bug other/89860] liboffloadmic/runtime/offload_target.cpp:332]: (style) Array index 'i' is used before limits check.

[crazylht at gmail dot com]

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

--- Comment #2 from Hongtao.liu  ---

The code is like:

for (int i = 0; i < m_vars_total; i++) {
  // instead of m_vars[i].type.src we will use m_vars_extra[i].type_src

   if (i < vars_total) {

..

if (m_vars[i].type.dst == c_extended_type && i < vars_total)

..

   }

..

}

So the later ***i < vars_total*** is not actually needed.

[Bug ipa/89341] [7/8/9 Regression] ICE in get, at cgraph.h:1332

[JunMa at linux dot alibaba.com]

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

--- Comment #12 from JunMa  ---
(In reply to Jan Hubicka from comment #11)
> Removing the alias check seems correct to me.  The same body alias patch was
> long and needed special casing those aliases on quite few places. I am not
> at all sure why I added this one, but it definitly silences the diagnostics
> completely that is wrong.

we cannot remove the alias check here directly, since the definition and alias
field of target node is set to true in cgraph_node::create_alias. Consider:

static void __attribute__((weakref("bar"))) foo1(void); 
static void __attribute__((weakref("foo1"))) foo2(void);
void bar(); 

if alias check removed, gcc gives warning at foo2.

I have sent the patch to maillist， see
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01249.html， please have a look.

[Bug c++/89878] New: same specializations on a zero-initialized struct object as a non-type parameter treated as distinct

[msebor at gcc dot gnu.org]

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

Bug ID: 89878
   Summary: same specializations on a zero-initialized struct
object as a non-type parameter treated as distinct
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing a patch for bug 89833 I noticed that the C++ 2a test case below
is accepted even though it redefines the same function f() three times, each
time taking an argument of the same type: B, with the only difference
between them being the form of initialization of the non-type parameter.  The
mangling of each of the functions is also distinct when it should be the same.

$ cat u.C && gcc -c -Wall -Wextra -std=c++2a u.C && nm u.o
struct A { int a[3]; };

template  struct B { };

void f (B) { }
void f (B) { }
void f (B) { }
void f (B) { }
 T _Z1f1BIXtl1AEEE
0010 T _Z1f1BIXtl1AtlA3_iLi0E
0020 T _Z1f1BIXtl1AtlA3_iLi0ELi0E
0030 T _Z1f1BIXtl1AtlA3_iLi0ELi0ELi0E

[Bug c++/89868] -fsanitize=address inhibits C++ unhandled exception core dump

[jg at jguk dot org]

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

--- Comment #4 from Jonny Grant  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Jonny Grant from comment #2)
> > Ah that sounds possible. I imagine it is not GCC that would be the one that
> > controls the core dumping? Perhaps where ever that code is, it could just
> > say "Core too large (xyz MB) unable to dump".
> 
> That would be the kernel.

Hi Andrew
I had a look through kernel and /fs/binfmt_elf.c but couldn't spot where the
"Aborted (core dumped)" comes from, do you know by any chance?

[Bug target/89877] [ARC] miscompilation due to missing cc clobber in longlong.h: add_ssaaaa()/sub_ddmmss()

[vgupta at synopsys dot com]

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

Vineet Gupta  changed:

   What|Removed |Added

 CC||vgupta at synopsys dot com

--- Comment #1 from Vineet Gupta  ---
Created attachment 46052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46052=edit
proposed fix

patch to fix the issue.

[Bug middle-end/89621] [7/8 Regression] ICE with allocatable character and openmp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE with |[7/8 Regression] ICE with
   |allocatable character and   |allocatable character and
   |openmp  |openmp

--- Comment #6 from Jakub Jelinek  ---
Fixed for 9.1+ so far.

[Bug middle-end/89621] [7/8/9 Regression] ICE with allocatable character and openmp

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 28 22:33:29 2019
New Revision: 270009

URL: https://gcc.gnu.org/viewcvs?rev=270009=gcc=rev
Log:
PR middle-end/89621
* tree-inline.h (struct copy_body_data): Add
dont_remap_vla_if_no_change flag.
* tree-inline.c (remap_type_3, remap_type_2): New functions.
(remap_type): Don't remap vla types if id->dont_remap_vla_if_no_change
and remap_type_2 returns false.
* omp-low.c (new_omp_context): Set ctx->cb.dont_remap_vla_if_no_change.
Move ctx->cb.adjust_array_error_bounds setting to the outermost ctx
only from where it is copied to nested contexts.

* gfortran.dg/gomp/pr89621.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr89621.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c
trunk/gcc/tree-inline.h

[Bug c++/81506] Invalid declaration with decltype accepted

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
Thanks Martin. This reminds me that we should tell David that in some cases the
"waves" following the caret don't go on far enough. Or maybe he already knows
or maybe we should do that instead ;)

[Bug target/89877] New: [ARC] miscompilation due to missing cc clobber in longlong.h: add_ssaaaa()/sub_ddmmss()

[vgupta at synopsys dot com]

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

Bug ID: 89877
   Summary: [ARC] miscompilation due to missing cc clobber in
longlong.h: add_ss()/sub_ddmmss()
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vgupta at synopsys dot com
  Target Milestone: ---

Created attachment 46051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46051=edit
test case, build with -O2 to show issue

A glibc build with -mcpu=hs4x sowed weird print values for test case below
(originally showed in multibench test harness printing wrong values)

void main(int argc, char *argv[])
{
size_t total_time = 115424
double secs = (double)total_time/(double)1000;
printf("%s %d %lf\n", "secs", total_time, secs);  // prints 113.504
printf("%d\n", (size_t)secs);
}

The code path leads to glibc stdlib/divrem.c: __mpn_divrem() which in turn uses
target defined inline asm macros in stdlib/longlong.h (which in turns is
sync'ed from gcc include/longlong.h)

These inline macros clobber the cpu flags, but fail to add "cc" in clobber
list.
This causes gcc to schedule a flag setting CMP instruction (or ADD.f) before
the clobbering ADD.f/SUB.f instructions, causing a subsequent conditional
branch to use a stale flag.

__mpn_divrem:
...
.L135:
...
st-1,[r0]
cmp_s r10,-1<-- intended flag
sub   r0,r0,4
sub   r4,r2,r9
add.f r2, r18, r9   <-- clobbered
adc   r3, r4, 0
beq_s @.L72 <-- stale flag used

-mcpu=hs4x + cc clobber fix
---
st-1,[r0]
sub   r4,r2,r9
sub   r0,r0,4
add.f r2, r18, r9
adc   r3, r4, 0
cmp_s r10,-1<-- intended flag
beq_s @.L72 <-- right flag used

The issue doesn't happen with default -mpcu=hs38 as the instruction scheduling
already delays the CMP for some reason.

-mcpu=hs38
--
st-1,[r0]
sub   r4,r2,r9
sub   r0,r0,4
add.f r2, r18, r9
adc   r3, r4, 0
cmp_s r10,-1
beq_s @.L72

[Bug c/89872] GCC does not generate read access to volatile compound literal

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-28
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/58031] invalid class template partial specialization accepted where argument list identical to primary template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-28
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.3.0, 7.3.0,
   ||8.2.0, 9.0

--- Comment #1 from Martin Sebor  ---
Confirmed.

[Bug c++/89874] invalid conversion accepted in decltype in a template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
See pr47488 for the origin of the test case.

[Bug c++/89876] [8/9 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
I stumbled into it while working on a fix for bug 47488 for GCC 9, which in
turn was precipitated by bug 89833.

[Bug c++/89876] [8/9 Regression] ICE in convert_like_real on decltype expression involving string conversion to char*

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
Summary|ICE in convert_like_real on |[8/9 Regression] ICE in
   |decltype expression |convert_like_real on
   |involving string conversion |decltype expression
   |to char*|involving string conversion
   ||to char*
  Known to fail||8.3.0, 9.0

--- Comment #1 from Martin Sebor  ---
Bisection points to r254437:

r254437 | marxin | 2017-11-06 04:02:15 -0500 (Mon, 06 Nov 2017) | 25 lines

Instrument function exit with __builtin_unreachable in C++


Prior to that change GCC would reject the test case with a slightly better for
of an ICE:

t.C: In substitution of ‘template decltype (f(T(), "")) g(T) [with T =
int]’:
t.C:7:17:   required from here
t.C:5:13: warning: ISO C++ forbids converting a string constant to ‘char*’
[-Wwrite-strings]
 decltype (f (T (), "")) g (T) { }
   ~~^~
t.C: In instantiation of ‘decltype (f(T(), "")) g(T) [with T = int]’:
t.C:5:25: sorry, unimplemented: string literal in function template signature
 decltype (f (T (), "")) g (T) { }
 ^

[Bug target/89848] [8/9 Regression] ICE: in convert_op, at config/i386/i386.c:2099 with -O2 -msse2 -mtune=pentium3m

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
Fixed.

[Bug c++/89876] New: ICE in convert_like_real on decltype expression involving string conversion to char*

[msebor at gcc dot gnu.org]

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

Bug ID: 89876
   Summary: ICE in convert_like_real on decltype expression
involving string conversion to char*
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following ill-formed test case triggers an ICE in GCC 8 and 9:

$ cat u.C && gcc -S -Wall -Wextra u.C
template 
T f (T, char*);

template 
decltype (f (T (), "")) g (T) { }

void h () { g (0); }

u.C: In substitution of ‘template decltype (f(T(), "")) g(T) [with T =
int]’:
u.C:7:17:   required from here
u.C:5:20: warning: ISO C++ forbids converting a string constant to ‘char*’
[-Wwrite-strings]
5 | decltype (f (T (), "")) g (T) { }
  |^~
‘
Internal compiler error: Error reporting routines re-entered.
0xb7e259 string_conv_p(tree_node const*, tree_node const*, int)
/src/gcc/git-svn/gcc/cp/typeck.c:2243
0x8435b5 convert_like_real
/src/gcc/git-svn/gcc/cp/call.c:7449
0x8470b6 build_over_call
/src/gcc/git-svn/gcc/cp/call.c:8379
0x837221 build_new_function_call(tree_node*, vec**, int)
/src/gcc/git-svn/gcc/cp/call.c:4519
0xb20ec0 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/src/gcc/git-svn/gcc/cp/semantics.c:2585
0xaca585 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/src/gcc/git-svn/gcc/cp/pt.c:19022
0xab38ae tsubst(tree_node*, tree_node*, int, tree_node*)
/src/gcc/git-svn/gcc/cp/pt.c:15068
0x960b6c dump_template_bindings
/src/gcc/git-svn/gcc/cp/error.c:407
0x96747e dump_substitution
/src/gcc/git-svn/gcc/cp/error.c:1544
0x968a99 dump_function_decl
/src/gcc/git-svn/gcc/cp/error.c:1700
0x96617a dump_decl
/src/gcc/git-svn/gcc/cp/error.c:1278
0x96f216 decl_to_string
/src/gcc/git-svn/gcc/cp/error.c:3076
0x97239b cp_printer
/src/gcc/git-svn/gcc/cp/error.c:4090
0x23f7fef pp_format(pretty_printer*, text_info*)
/src/gcc/git-svn/gcc/pretty-print.c:1390
0x23f83f9 pp_format_verbatim(pretty_printer*, text_info*)
/src/gcc/git-svn/gcc/pretty-print.c:1452
0x23f8ac7 pp_verbatim(pretty_printer*, char const*, ...)
/src/gcc/git-svn/gcc/pretty-print.c:1671
0x970c67 print_instantiation_full_context
/src/gcc/git-svn/gcc/cp/error.c:3474
0x9711c0 maybe_print_instantiation_context
/src/gcc/git-svn/gcc/cp/error.c:3622
0x96fbda cp_diagnostic_starter
/src/gcc/git-svn/gcc/cp/error.c:3325
0x23d6c5b diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/src/gcc/git-svn/gcc/diagnostic.c:1016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/89848] [8/9 Regression] ICE: in convert_op, at config/i386/i386.c:2099 with -O2 -msse2 -mtune=pentium3m

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Mar 28 21:38:44 2019
New Revision: 270008

URL: https://gcc.gnu.org/viewcvs?rev=270008=gcc=rev
Log:
PR target/89848
* config/i386/i386.c (dimode_scalar_chain::make_vector_copies):
Also process XEXP (src, 0) of a shift insn.

testsuite/ChangeLog:

PR target/89848
* gcc.target/i386/pr89848.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89848.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/i386.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/66548] Invalid class member access expression in decltype sometimes accepted

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Mar 28 21:32:11 2019
New Revision: 270007

URL: https://gcc.gnu.org/viewcvs?rev=270007=gcc=rev
Log:
PR c++/66548 - Invalid class member access expression in decltype sometimes
accepted

gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype-pr66548.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype-pr66548.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/81506] Invalid declaration with decltype accepted

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Mar 28 21:20:18 2019
New Revision: 270006

URL: https://gcc.gnu.org/viewcvs?rev=270006=gcc=rev
Log:
PR c++/81506 - Invalid declaration with decltype accepted 

testsuite/ChangeLog:
* g++.dg/cpp0x/decltype-pr81506.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype-pr81506.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/81506] Invalid declaration with decltype accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||9.0
 Resolution|--- |FIXED
  Known to fail||8.3.0

--- Comment #2 from Martin Sebor  ---
This appears to have been fixed by r267165 (gcc 9.0.0):

r267165 | paolo | 2018-12-15 04:07:38 -0500 (Sat, 15 Dec 2018) | 16 lines

/cp
2018-12-15  Paolo Carlini  

PR c++/84644
* decl.c (check_tag_decl): A decltype with no declarator
doesn't declare anything.

[Bug c++/66548] Invalid class member access expression in decltype sometimes accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
This has been rejected since r231354:

r231354 | jason | 2015-12-06 23:35:14 -0500 (Sun, 06 Dec 2015) | 4 lines

Fix parse/no-type-defn1.C with -std=c++1z.

* parser.c (struct tentative_firewall): New.
(cp_parser_template_id, cp_parser_decltype_expr): Use it.

The equivalent code using __typeof__ is still accepted.  I opened bug 89875 for
it.

[Bug c++/89875] [7/8/9 Regression] invalid typeof reference to a member of an incomplete struct accepted at function scope

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
  Known to work||4.9.4
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=66548
Summary|invalid typeof reference to |[7/8/9 Regression] invalid
   |a member of an incomplete   |typeof reference to a
   |struct accepted at function |member of an incomplete
   |scope   |struct accepted at function
   ||scope
  Known to fail||5.1.0, 6.4.0, 7.3.0, 8.2.0,
   ||9.0

--- Comment #1 from Martin Sebor  ---
The full test case is:

struct Meow;

void f ()
{
  __typeof__ (Meow.purr) d;
}


Bisection points to r213952 (gcc 4.10.0):

r213952 | paolo | 2014-08-14 05:15:11 -0400 (Thu, 14 Aug 2014) | 34 lines

/gcc/cp
2014-08-14  Paolo Carlini  

* parser.c (cp_parser_init_declarator): Remove redundant check of
decl_specifiers->type.

[Bug c++/89875] New: invalid typeof reference to a member of an incomplete struct accepted at function scope

[msebor at gcc dot gnu.org]

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

Bug ID: 89875
   Summary: invalid typeof reference to a member of an incomplete
struct accepted at function scope
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following ill-formed test case modified from bug 66548 is still accepted by
GCC 9:

$ cat u.C && gcc -S -Wall -Wextra u.C

void f ()
{
  __typeof__ (Meow.purr) d;
}
u.C: In function ‘void f()’:
u.C:5:26: warning: unused variable ‘d’ [-Wunused-variable]
5 |   __typeof__ (Meow.purr) d;
  |  ^

[Bug fortran/82971] ICE in gfc_find_derived_vtab, at fortran/class.c:2214 ...

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|NEW |RESOLVED
 CC||janus at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from janus at gcc dot gnu.org ---
I can confirm the ICE up to version 8.2, but with current trunk I see:

5 |class(t), target :: z
  |1
Error: CLASS variable ‘z’ at (1) must be dummy, allocatable or pointer

[Bug c++/57943] [c++11] invalid decltype expression accepted in template default type

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
*** Bug 89874 has been marked as a duplicate of this bug. ***

[Bug c++/89874] invalid conversion accepted in decltype in a template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
  Known to fail||4.1.3, 4.3.5, 4.4.7, 4.8.5,
   ||4.9.4, 5.4.0, 6.4.0, 7.3.0,
   ||8.3.0, 9.0

--- Comment #1 from Martin Sebor  ---
This was never rejected going as far back as GCC 4.1.

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

[Bug c++/57943] [c++11] invalid decltype expression accepted in template default type

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-28
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.1.3, 4.3.5, 4.4.7, 4.8.5,
   ||4.9.4, 5.4.0, 6.4.0, 7.3.0,
   ||8.2.0, 9.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  This never worked correctly either with declype or __typeof__.

[Bug c++/89874] New: invalid conversion accepted in decltype in a template

[msebor at gcc dot gnu.org]

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

Bug ID: 89874
   Summary: invalid conversion accepted in decltype in a template
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

G++ accepts the following ill-formed program:

$ cat u.C && /gcc -S -Wall -Wextra u.C
char f (int);

template 
decltype (f ("123"))   // invalid: no conversion from const char* to int
g (T);

void h () { g (0); }

Clang prints:

u.C:4:11: error: no matching function for call to 'f'
decltype (f ("123"))   // invalid: no conversion from const char* to int
  ^
u.C:1:6: note: candidate function not viable: no known conversion from
  'const char [4]' to 'int' for 1st argument
char f (int);
 ^
u.C:7:13: error: no matching function for call to 'g'
void h () { g (0); }
^
2 errors generated.

[Bug c++/89873] internal compiler error: unexpected expression of kind implicit_conv_expr

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Started with r214396.

[Bug c++/89873] internal compiler error: unexpected expression of kind implicit_conv_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-28
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/89873] New: internal compiler error: unexpected expression of kind implicit_conv_expr

[mpolacek at gcc dot gnu.org]

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

Bug ID: 89873
   Summary: internal compiler error: unexpected expression of kind
implicit_conv_expr
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Split out of .

// { dg-do compile { target c++14 } }

template  bool b;

template  
struct C {
  template  friend int foo() noexcept(b<1>); // { dg-error "not
usable in a constant expression|different exception specifier" }
};

template  int foo() noexcept(b<1>);

auto a = C();

$ ./cc1plus -quiet noexcept1.C
noexcept1.C: In instantiation of ‘int foo()’:
noexcept1.C:7:34:   required from ‘struct C’
noexcept1.C:12:17:   required from here
noexcept1.C:7:34: internal compiler error: unexpected expression ‘b<1>’ of kind
implicit_conv_expr
7 |   template  friend int foo() noexcept(b<1>); // { dg-error
"not usable in a constant expression|different exception specifier" }
  |  ^~~
0x8ecf05 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5207
0x8ed7d8 cxx_eval_outermost_constant_expr
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5322
0x8ee06b cxx_constant_value(tree_node*, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5445
0x9b3530 build_noexcept_spec(tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/except.c:1292
0xb0c359 maybe_instantiate_noexcept(tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/pt.c:24274
0x93316e check_redeclaration_exception_specification
/home/mpolacek/src/gcc/gcc/cp/decl.c:1157
0x93a793 duplicate_decls(tree_node*, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/decl.c:2078
0xa1bc0a do_pushdecl
/home/mpolacek/src/gcc/gcc/cp/name-lookup.c:3034
0xa1c611 pushdecl(tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/name-lookup.c:3162
0xa1eb16 do_pushdecl_with_scope
/home/mpolacek/src/gcc/gcc/cp/name-lookup.c:3900
0xa23319 pushdecl_namespace_level(tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/name-lookup.c:5091
0xac8e40 tsubst_friend_function
/home/mpolacek/src/gcc/gcc/cp/pt.c:10417
0xacdac8 instantiate_class_template_1
/home/mpolacek/src/gcc/gcc/cp/pt.c:11404
0xacdd20 instantiate_class_template(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.c:11469
0xb976b1 complete_type(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/typeck.c:138
0xb976d6 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/typeck.c:150
0xbc8b21 build_functional_cast(tree_node*, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/typeck2.c:2272
0xa6ba2b cp_parser_functional_cast
/home/mpolacek/src/gcc/gcc/cp/parser.c:28373
0xa40cd4 cp_parser_postfix_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:7098
0xa4453f cp_parser_unary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:8469
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/89612] [7/8 Regression] internal compiler error: in push_access_scope, at cp/pt.c:237

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] internal |[7/8 Regression] internal
   |compiler error: in  |compiler error: in
   |push_access_scope, at   |push_access_scope, at
   |cp/pt.c:237 |cp/pt.c:237

--- Comment #8 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/89612] [7/8/9 Regression] internal compiler error: in push_access_scope, at cp/pt.c:237

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar 28 20:24:48 2019
New Revision: 270005

URL: https://gcc.gnu.org/viewcvs?rev=270005=gcc=rev
Log:
PR c++/89612 - ICE with member friend template with noexcept.
* pt.c (maybe_instantiate_noexcept): For function templates, use their
template result (function decl).  Don't set up local specializations.
Temporarily turn on processing_template_decl.  Update the template type
too.

* g++.dg/cpp0x/noexcept38.C: New test.
* g++.dg/cpp0x/noexcept39.C: New test.
* g++.dg/cpp1z/noexcept-type21.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/noexcept38.C
trunk/gcc/testsuite/g++.dg/cpp0x/noexcept39.C
trunk/gcc/testsuite/g++.dg/cpp1z/noexcept-type21.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/71796] Link error referencing compiler generated symbol __vtab_xxx

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||link-failure
 Status|NEW |RESOLVED
 CC||janus at gcc dot gnu.org
  Known to work||7.3.0
 Resolution|--- |FIXED
  Known to fail||6.5.0

--- Comment #6 from janus at gcc dot gnu.org ---
The problem is fixed since gfortran version 7. Closing.

[Bug fortran/65359] [OOP] undefined output with array and inheritance

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |RESOLVED
 CC||janus at gcc dot gnu.org
  Known to work||8.2.0
 Resolution|--- |FIXED
  Known to fail||7.3.0

--- Comment #2 from janus at gcc dot gnu.org ---
With 8.2.0 and trunk I get the correct output

 1st: -100-100-200-200
 2nd: -100-100-200-200
 3rd:   91  92  93  94
 4th:   91  92  93  94

without any valgrind errors. Apparently this has been fixed.

[Bug rtl-optimization/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||ra
 Target||x86
 Status|ASSIGNED|NEW
  Component|target  |rtl-optimization
   Assignee|ubizjak at gmail dot com   |unassigned at gcc dot 
gnu.org

--- Comment #16 from Uroš Bizjak  ---
The exposed target-related problem is fixed.

Recategorizing as RA problem.

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[uros at gcc dot gnu.org]

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

--- Comment #15 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Mar 28 19:33:22 2019
New Revision: 270004

URL: https://gcc.gnu.org/viewcvs?rev=270004=gcc=rev
Log:
PR target/89865
* config/i386/i386.md (RMW operation with LEA peephole):
Use LEAMODE mode attribute instead of SWI mode iterator for
LEA pattern.


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

[Bug fortran/29670] [meta-bug] fortran interfaces

[janus at gcc dot gnu.org]

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

Bug 62176 Summary: [OOP] Inconsistent resolution of GENERIC interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62176

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug fortran/62176] [OOP] Inconsistent resolution of GENERIC interface

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||janus at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> Reduced test
> [...]
> 
> The code compiles if the lines
> 
>   generic :: lle => string_less_equal_char, &
> char_less_equal_string
> 
> are commented. I cannot see how 'string_less_equal_char' and
> 'char_less_equal_string' are ambiguous for 'lle', but not for operator '<='.

Well, that's simply due to the different invocation syntax for both cases.

1) For the type-bound generic 'lle', the call looks like this:

str%lle(ch)

This matches both specific TBPs (which only differ in the position of the PASS
argument), therefore they are ambiguous in this context.

2) The operator '<=' is invoked by one of the two forms:

str <= ch
ch <= str

Here both specifics can be distinguished, so they are not ambiguous.


In summary, gfortran's behavior is perfectly fine. This is a non-bug.

[Bug target/89848] [8/9 Regression] ICE: in convert_op, at config/i386/i386.c:2099 with -O2 -msse2 -mtune=pentium3m

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Mar 28 19:15:58 2019
New Revision: 270003

URL: https://gcc.gnu.org/viewcvs?rev=270003=gcc=rev
Log:
PR target/89848
* config/i386/i386.c (dimode_scalar_chain::make_vector_copies):
Also process XEXP (src, 0) of a shift insn.

testsuite/ChangeLog:

PR target/89848
* gcc.target/i386/pr89848.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr89848.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89871] Wall + designated initializers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Seems to have been fixed by r265609.

[Bug c/89872] New: GCC does not generate read access to volatile compound literal

[pascal_cuoq at hotmail dot com]

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

Bug ID: 89872
   Summary: GCC does not generate read access to volatile compound
literal
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pascal_cuoq at hotmail dot com
  Target Milestone: ---

This report is similar to but different from my previous report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82340

Consider the C code below. The report is about the compilation of the functions
g and hg. The other functions are included only for discussion of the expected
behavior.

void f(void) {
volatile int y=1, z=2;
y + z;
}

void g(void)
{
  (volatile int){1} + (volatile int){2};
}

void k(void)
{
  (volatile int){1};
}

void hf(void)
{
for (int i = 0; i < 1000; i++) f();
}

void hg(void)
{
for (int i = 0; i < 1000; i++) g();
}

void hk(void)
{
for (int i = 0; i < 1000; i++) k();
}

When compiling with -O3, the versions trunk and 8.3 of GCC on Compiler Explorer
(https://gcc.godbolt.org/z/2Il4GG ) produce the following x86-64:

f:
movl$1, -8(%rsp)
movl$2, -4(%rsp)
movl-8(%rsp), %eax
movl-4(%rsp), %eax
ret
g:
ret
k:
movl$1, -4(%rsp)
movl-4(%rsp), %eax
ret
hf:
movl$1000, %eax
.L6:
movl$1, -8(%rsp)
movl$2, -4(%rsp)
movl-8(%rsp), %edx
movl-4(%rsp), %edx
subl$1, %eax
jne .L6
ret
hg:
ret
hk:
movl$1000, %eax
.L10:
movl$1, -4(%rsp)
movl-4(%rsp), %edx
subl$1, %eax
jne .L10
ret

The functions g and hg are compiled to “ret”. Because reading from a volatile
lvalue is an observable side-effect (C11 5.1.2.3:6
https://port70.net/~nsz/c/c11/n1570.html#5.1.2.3p6 ) I would have expected them
to be compiled more similarly to f and hf respectively.

[Bug c++/89871] New: Wall + designated initializers

[vincent.hamp at higaski dot at]

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

Bug ID: 89871
   Summary: Wall + designated initializers
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent.hamp at higaski dot at
  Target Milestone: ---

Created attachment 46050
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46050=edit
Example fails to compile with -Wall

Using a struct with an anonymous union and trying to assign to it using
designated initializers does not compile with -Wall.

So e.g. 
g++ -std=c++2a -Wall designated_init.cpp

produces
"internal compiler error: side-effects element in no-side-effects CONSTRUCTOR"

The error can be reproduced on 8.1, 8.2 and 8.3. The current trunk however
seems to work.

[Bug c++/89836] converted constant expression of type bool and explicit conversion functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed.

[Bug c++/89836] converted constant expression of type bool and explicit conversion functions

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar 28 18:23:18 2019
New Revision: 270002

URL: https://gcc.gnu.org/viewcvs?rev=270002=gcc=rev
Log:
PR c++/89836 - bool constant expression and explicit conversions.
* call.c (build_converted_constant_expr_internal): New function,
renamed from...
(build_converted_constant_expr): ...this.  New.
(build_converted_constant_bool_expr): New.
* cp-tree.h (build_converted_constant_bool_expr): Declare.
* decl.c (build_explicit_specifier): Call
build_converted_constant_bool_expr.

* g++.dg/cpp2a/explicit15.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/explicit15.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #11 from Wilco  ---
There is also something odd with the way the loop iterates, this doesn't look
right:

whilelo p0.s, x3, x4
incwx3
ptest   p1, p0.b
bne .L3

[Bug c++/89867] internal compiler error: in layout_type, at stor-layout.c:2578

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
processing_template_decl is false, but the type is still auto. Do we need to
treat all attributes like late ones, or just the late ones that way even when
!processing_template_decl and is_auto, something else?

[Bug c++/89867] internal compiler error: in layout_type, at stor-layout.c:2578

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-reduction |
 Target|arm-none-eabi   |
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started to ICE with r139798 when C++11 auto has been implemented I think.
Reduced testcase:
auto a __attribute__((__may_alias__)) = 1;
ICEs on all targets.

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Peter Bergner from comment #13)
> (In reply to Jakub Jelinek from comment #9)
> > Note, the r264897 change to the testcase was clearly bogus, because then the
> > testcase is really useless, the intent of the testcase was to check that all
> > (but the 8) peepholes did the right thing and there are no RMW cycles, with
> > all the loads and stores from RA (that were previously push/pop instead with
> > no other %sp changes) that is not tested anymore.
> 
> So given Segher's r265398 changed the code generated for
> gcc.target/i386/pr49095.c back to what is was before my r264897 change, are
> you saying we should just backout my change to the test case so it looks
> like what it did before my commit?

Yes, but only if r266385 wasn't in.  Now that it is in, it wouldn't match
anyway, so we need to find out if something can be done about it, or if we just
test for it some other way (rtl dump scan, -dP or whatever and specifically
differentiate the loads using the argument pointer as address vs. anything
else).

> So any issues since then are due only to Vlad's r266385?

I think so.

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #13 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #9)
> Note, the r264897 change to the testcase was clearly bogus, because then the
> testcase is really useless, the intent of the testcase was to check that all
> (but the 8) peepholes did the right thing and there are no RMW cycles, with
> all the loads and stores from RA (that were previously push/pop instead with
> no other %sp changes) that is not tested anymore.

So given Segher's r265398 changed the code generated for
gcc.target/i386/pr49095.c back to what is was before my r264897 change, are you
saying we should just backout my change to the test case so it looks like what
it did before my commit?

So any issues since then are due only to Vlad's r266385?

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Jakub Jelinek from comment #9)
> I suggest we apply my LEA patch (that is a clear improvement), and
> recategorize the PR as a RA regression.

Agreed.

[Bug rtl-optimization/89853] Regression of 525.x264_r at -O2 (and generic tuning) on AMD EPYC

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  ---
(In reply to Martin Jambor from comment #6)
> Hi, the assembly of the most affected function does not change at all, just
> its offset (is 0x10 bytes bigger).  Aligning the loops in the function a bit
> more avoids most of the slowdown but not quite all of it.  In any event,
> this is a microarchitectural problem that we probably cannot do anything
> about.  Sorry for the noise, I will check for this the next time before I
> report a problem.

We've seen similar issues on POWER, where a particular revision causes slight
size changes in a function that changes the function offset of some other later
function and that causes a performance change.  Unfortunately, just increasing
function alignment to eliminate that has other unintended performance issues.

Thanks for isolating the issue.

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #9)
> Note, the r264897 change to the testcase was clearly bogus, because then the
> testcase is really useless, the intent of the testcase was to check that all
> (but the 8) peepholes did the right thing and there are no RMW cycles, with
> all the loads and stores from RA (that were previously push/pop instead with
> no other %sp changes) that is not tested anymore.
I suggest we apply my LEA patch (that is a clear improvement), and recategorize
the PR as a RA regression.

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #8)
> (this is -Os, so that is what matters), r264897 made the generated code
> worse, then r265398 reverted it to the previously generated code and r266385
> made it even worse.

BTW: r266385 also regressed:

FAIL: gcc.target/i386/pr81563.c scan-assembler-times movl[t
]*-4(%ebp),[t ]*%edi 1
FAIL: gcc.target/i386/pr81563.c scan-assembler-times movl[t
]*-8(%ebp),[t ]*%esi 1

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Note, the r264897 change to the testcase was clearly bogus, because then the
testcase is really useless, the intent of the testcase was to check that all
(but the 8) peepholes did the right thing and there are no RMW cycles, with all
the loads and stores from RA (that were previously push/pop instead with no
other %sp changes) that is not tested anymore.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[jamborm at gcc dot gnu.org]

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

Bug 89853 Summary: Regression of 525.x264_r at -O2 (and generic tuning) on AMD 
EPYC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89853

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

[Bug rtl-optimization/89853] Regression of 525.x264_r at -O2 (and generic tuning) on AMD EPYC

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Martin Jambor  ---
Hi, the assembly of the most affected function does not change at all, just its
offset (is 0x10 bytes bigger).  Aligning the loops in the function a bit more
avoids most of the slowdown but not quite all of it.  In any event, this is a
microarchitectural problem that we probably cannot do anything about.  Sorry
for the noise, I will check for this the next time before I report a problem.

[Bug c/89812] [9 Regression] incorrect maximum in error: requested alignment ‘536870912’ exceeds maximum 2147483648

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 28 17:14:05 2019
New Revision: 270001

URL: https://gcc.gnu.org/viewcvs?rev=270001=gcc=rev
Log:
PR c/89812
* gcc.dg/attr-aligned-3.c: Limit the test to known ELF targets
other than AVR.  Add dg-options "".

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/attr-aligned-3.c

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Actually, there are only very few revisions since 8.x that change something on
this testcase with -Os -fno-shrink-wrap -masm=att
-fno-asynchronous-unwind-tables (the latter to be able to more accurately
compare *.s sizes).  GCC 8.3 emits code pretty similar to trunk immediately
before r264897, just scheduling decisions reorder some instructions, nothing
else.
ls -l pr49095.s{.8*,r2*}
-rw-rw-r--. 1 jakub jakub 16364 Mar 28 12:58 pr49095.s.8.3.1
-rw-rw-r--. 1 jakub jakub 16361 Mar 28 12:50 pr49095.s.r264892
-rw-rw-r--. 1 jakub jakub 17545 Mar 28 12:50 pr49095.s.r264897
-rw-rw-r--. 1 jakub jakub 17545 Mar 28 12:51 pr49095.s.r265393
-rw-rw-r--. 1 jakub jakub 16361 Mar 28 12:51 pr49095.s.r265398
-rw-rw-r--. 1 jakub jakub 16361 Mar 28 12:55 pr49095.s.r266382
-rw-rw-r--. 1 jakub jakub 18989 Mar 28 12:55 pr49095.s.r266385
-rw-rw-r--. 1 jakub jakub 18989 Mar 28 12:55 pr49095.s.r269951
r264892 is identical to r265398 and r266382, r264897 to r265393, and r266385 to
r269951.  Judging by both assembly size and .text size:
size pr49095.o.*
   textdata bss dec hex filename
   1585   0   01585 631 pr49095.o.8.3.1
   1585   0   01585 631 pr49095.o.r264892
   2066   0   02066 812 pr49095.o.r264897
   2066   0   02066 812 pr49095.o.r265393
   1585   0   01585 631 pr49095.o.r265398
   1585   0   01585 631 pr49095.o.r266382
   2545   0   02545 9f1 pr49095.o.r266385
   2545   0   02545 9f1 pr49095.o.r269951
(this is -Os, so that is what matters), r264897 made the generated code worse,
then r265398 reverted it to the previously generated code and r266385 made it
even worse.

[Bug c++/89868] -fsanitize=address inhibits C++ unhandled exception core dump

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Jonny Grant from comment #2)
> Ah that sounds possible. I imagine it is not GCC that would be the one that
> controls the core dumping? Perhaps where ever that code is, it could just
> say "Core too large (xyz MB) unable to dump".

That would be the kernel.

[Bug rtl-optimization/89853] Regression of 525.x264_r at -O2 (and generic tuning) on AMD EPYC

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
(In reply to Martin Liška from comment #4)
> Just for the record, my Ryzen machine periodic tester probably improved due
> to the revision:
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=158.377.0=41.
> 377.0=70.377.0=31.377.0
> 
> As seen, it's now about 5% faster than GCC8 branch.

Very interesting, thanks for that!  Since the two of you both used -O2 and
generic tuning (ie, same code), that would tend to agree with my speculation
that this is an AMD EPYC specific pipeline issue/hazard/... we're unluckily
hitting.  Agreed?  If so, I'm not sure we can really blame my patch, but if
someone could narrow down what the exact issue is that is causing the slowdown,
maybe we can mitigate it somehow.

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Ah, but that is only because r264897 adjusted the expected counts from 8 to
47/57 :(.

[Bug c++/77875] C++ core issue 1288

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Yes, probably, but it doesn't seem useful for T{i} to do anything except bind a
reference of type T to i. Issue 1521 seems to be a problem with the wording,
such that it doesn't apply to references, but I doubt it will be resolved by
saying that T{i} does anything surprising. But maybe I'm missing something.

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Well, the testcase (as many others) clearly shows that the generated code is
significantly worse after the combiner change.  The question is if we can do
something to improve it.

[Bug c++/77875] C++ core issue 1288

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Doesn't this depend on the resolution of Core 1521 (still "drafting"), dealing
with T{expr} where T is a reference type?  Which is what this PR is about:

void
f ()
{
  int i = 42;
  using T = int&;
  T t = T{i};
}

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #4)
> I don't see the testcase FAILing on i?86 though, just on x86_64, and there
> starting with Oct 2x (20th is still ok, 23rd fails, so likely r265398).

The testcase is very brittle, there certainly is the difference between gcc-8.4
and gcc-9.0 in generated code for 32bit target (as reported in Comment #0),
apparently undetected by the scan directives. That said, the testcase will
easily fail with a compiler using non-default target [1] or compile flags.

[1] https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg03664.html

[Bug debug/68771] Darwin: PGO + LTO + multiple threads creates corrupted profile info.

[iains at gcc dot gnu.org]

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

--- Comment #27 from Iain Sandoe  ---
(In reply to Daniel Vollmer from comment #26)
> (In reply to Iain Sandoe from comment #25)
> > (In reply to Daniel Vollmer from comment #24)
> > > (In reply to Iain Sandoe from comment #23)

> > Sadly, without a reproducer, it's hard to make progress - possibly more
> > complex control flow is needed - multiple function?
> 
> I've tried but not managed a simple reproducer yet.

> The "real" code definitely has more complex control flow, but is also in a
> shared-library that is in turn exposed / used by a Python extension.

So when you profile this, you have to profile it underneath Python?
i.e. you have no way to exercise the library's API to train it?

rather a lot of moving parts to nail down if it's the former.

[Bug target/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
I don't see the testcase FAILing on i?86 though, just on x86_64, and there
starting with Oct 2x (20th is still ok, 23rd fails, so likely r265398).
Let me have a look.

[Bug c++/55004] [meta-bug] constexpr issues

[jakub at gcc dot gnu.org]

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

Bug 89785 Summary: Incorrect "not a constant expression" error with switch 
statement that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89785

   What|Removed |Added

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

[Bug c++/89785] Incorrect "not a constant expression" error with switch statement that returns

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed for 9.1+.

[Bug c/79022] trunk/gcc/gengtype.h: create_nested_ptr_option: decl & defn don't match ?

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||89863

--- Comment #6 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #3)
> Adding a warning about this case seems genuinely useful, i.e. when the names
> match but in a different order.
> 

So, since this is closed, I guess someone™ should open a separate bug for that
part?

> I'm less convinced that warning about mismatches like void f(int number) and
> void f(int num) is useful, as it would just be noise in many cases.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
[Bug 89863] [meta-bug] Issues that cppcheck finds that gcc misses

[Bug debug/68771] Darwin: PGO + LTO + multiple threads creates corrupted profile info.

[zerolo at gmail dot com]

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

--- Comment #26 from Daniel Vollmer  ---
(In reply to Iain Sandoe from comment #25)
> (In reply to Daniel Vollmer from comment #24)
> > (In reply to Iain Sandoe from comment #23)
> > 
> > > My freshly-built 7.4 (bootstrapped with 10.1 xc effectively) doesn't
> > > reproduce it, neither do any other branches I have lying around - so we're
> > > not there yet.
> > > 
> > > I take it that the full code does fail with 8.3?
> > 
> > The full example fails with both the homebrew built 8.3, but also the
> > freshly compiled (on 10.14.4) 7.4.0, so I guess my smaller example is not
> > (as) representative as I'd hoped.
> 
> Sadly, without a reproducer, it's hard to make progress - possibly more
> complex control flow is needed - multiple function?

I've tried but not managed a simple reproducer yet.

The "real" code definitely has more complex control flow, but is also in a
shared-library that is in turn exposed / used by a Python extension.

[Bug target/85968] gcc/config/arc/arc.c:9805: bad test ?

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Gallager  ---
(In reply to Claudiu Zissulescu from comment #4)
> Yes we can close it, no need for backporting.
> 
> //Claudiu

OK cool.

[Bug c++/89870] C++ suggest header for abort()

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonny Grant from comment #2)
> Good point!
> 
> Any header would be a good start... but as it is a CPP file being compiled
> by g++ perhaps g++ should even suggest std::abort() and  ?

That's a matter of taste, not correctness or questionable code. There's nothing
wrong with including  and using ::abort.

[Bug c++/89870] C++ suggest header for abort()

[jg at jguk dot org]

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

--- Comment #2 from Jonny Grant  ---
Good point!

Any header would be a good start... but as it is a CPP file being compiled by
g++ perhaps g++ should even suggest std::abort() and  ?


eg suggestion:
test.cpp: In function 'int main()':
test.cpp:3:5: error: 'abort' was not declared in this scope
3 | abort();
  | ^
note: did you mean std::abort?
note: include '' or provide a declaration of 'abort'
  +++ |+#include 

[Bug c++/89785] Incorrect "not a constant expression" error with switch statement that returns

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 28 14:47:47 2019
New Revision: 269995

URL: https://gcc.gnu.org/viewcvs?rev=269995=gcc=rev
Log:
PR c++/89785
* constexpr.c (struct check_for_return_continue_data): New type.
(check_for_return_continue): New function.
(potential_constant_expression_1) : Walk
SWITCH_STMT_BODY to find RETURN_EXPRs or CONTINUE_STMTs not nested
in loop bodies and set *jump_target to that if found.

* g++.dg/cpp1y/constexpr-89785-1.C: New test.
* g++.dg/cpp1y/constexpr-89785-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-89785-1.C
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-89785-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89870] C++ suggest header for abort()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-28
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonny Grant from comment #0)
> trunk g++ does not suggest missing #include   (C++ style) header in
> the following code compiled as C++.

Good, because you called it unqualified and there's no using-directive or
using-declaration to make it visible. The correct header for that example is
.

[Bug libstdc++/88066] [7 Regression] Relative includes in bits/locale_conv.h should be prefixed

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Matthias Kretz from comment #9)
> Created attachment 46049 [details]
> test case
> 
> Let me present the counterargument. I.e. if I use -I. and have a file named
> as used internally by libstdc++, compilation breaks. Nothing in the C++
> standard forbids to create a bits/stl_vector.h file in my source tree,
> right? *evil grin*

Right, and I don't think we can even use <__bits/stl_vector.h> because I don't
think reserved names apply to headers.


> I'm a vocal fighter for "" includes... ;-)

Yes, I wasn't happy about this change. I think -I- is an annoyance (and not
supported by other gcc-like compilers anyway).

[Bug middle-end/89725] ICE in get_fnname_from_decl, at varasm.c:1723

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Thu Mar 28 14:40:56 2019
New Revision: 269994

URL: https://gcc.gnu.org/viewcvs?rev=269994=gcc=rev
Log:
optinfo-emit-json.cc: don't call get_fnname_from_decl (PR middle-end/89725)

optrecord_json_writer::optinfo_to_json can in theory be called from any
optimization pass, but currently uses get_fnname_from_decl, which
is RTL-specific.

In that PR, Jakub suggested using either DECL_ASSEMBLER_NAME or the
"printable name" (via current_function_name).

This patch makes it use DECL_ASSEMBLER_NAME.

gcc/ChangeLog:
PR middle-end/89725
* optinfo-emit-json.cc (optrecord_json_writer::optinfo_to_json):
Use DECL_ASSEMBLER_NAME rather than get_fnname_from_decl.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/optinfo-emit-json.cc

[Bug libstdc++/88066] [7 Regression] Relative includes in bits/locale_conv.h should be prefixed

[kretz at kde dot org]

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

Matthias Kretz  changed:

   What|Removed |Added

 CC||kretz at kde dot org

--- Comment #9 from Matthias Kretz  ---
Created attachment 46049
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46049=edit
test case

Let me present the counterargument. I.e. if I use -I. and have a file named as
used internally by libstdc++, compilation breaks. Nothing in the C++ standard
forbids to create a bits/stl_vector.h file in my source tree, right? *evil
grin*

I'm a vocal fighter for "" includes... ;-)

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #14 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #13)
> > FYI : On my environment it's not possible to produce an ICE with gcc-9
> > and several tested combinations of options / all tested configurations.

Confirmed, the ICE is gone since gfortran 6.


> > $ gfortran-9-20181021 -c pr52994.f90
> > pr52994.f90:43:29:
> >
> >43 |   a%left_halo(psi%arr) = -666
> >   | 1
> > Error: Different types in pointer assignment at (1); attempted assignment
> > of REAL(4) to INTEGER(4)
> 
> Note that I am surprised by the order of REAL(4) and INTEGER(4): AFAICT
> a%left_halo(psi%arr) is real and -666 an integer, isn't it?

The bigger problem is that the mentioned statement is not actually a pointer
assignment. left_halo returns a pointer, but the assignment concerns the target
of that pointer, not the pointer itself.

When changing to a real value, I get:

   32 |   a%left_halo(arr) = -666.
  |  1
Error: Different ranks in pointer assignment at (1)


Also this error is bogus. The assignment is valid AFAICS.

[Bug c++/89870] New: C++ suggest header for abort()

[jg at jguk dot org]

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

Bug ID: 89870
   Summary: C++ suggest header for abort()
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

trunk gcc can suggest the missing #include  header if the following
code is compiled as C.

trunk g++ does not suggest missing #include   (C++ style) header in
the following code compiled as C++.

Can the C++ header suggestion pick this up somehow?

int main()
{
abort();
}

Tested on godbolt trunk today

[C++]
#1 with x86-64 gcc (trunk)
: In function 'int main()':

:3:5: error: 'abort' was not declared in this scope

3 | abort();

  | ^

Compiler returned: 1



[C]
#1 with x86-64 gcc (trunk)
: In function 'main':

:3:5: warning: implicit declaration of function 'abort'
[-Wimplicit-function-declaration]

3 | abort();

  | ^

:3:5: warning: incompatible implicit declaration of built-in function
'abort'

:1:1: note: include '' or provide a declaration of 'abort'

  +++ |+#include 

1 | int main()

Compiler returned: 0

[Bug middle-end/89725] ICE in get_fnname_from_decl, at varasm.c:1723

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
I think the issue is that the DDR is bogus - loop interchange computes
data-refs
for a deeper nest (including some outer loops) than it ends up doing
dependence checking later on.  But we have access functions analyzed with
respect to outer loops already.

I think it would be possible to handle this in data dependence computation,
simply treating evolutions in outer loops as invariants.  Eventually the
access functions evolving in outer loops can also be pruned?  We can't
really undo SCEV analysis on them.

I think that Jakubs fix is too conservative though.

Since we fail when we cannot compute the "invalid" subscript distance at the
moment the safest fix would probably to create the DDR with the loop-nest
we originally analyzed?  Bin?

diff --git a/gcc/gimple-loop-interchange.cc b/gcc/gimple-loop-interchange.cc
index bb01a9b0d40..1f9b0c900d4 100644
--- a/gcc/gimple-loop-interchange.cc
+++ b/gcc/gimple-loop-interchange.cc
@@ -1995,6 +1995,7 @@ prepare_perfect_loop_nest (struct loop *loop, vec
*loop_nest,

   /* Prepare the data reference vector for the loop nest, pruning outer
  loops we cannot handle.  */
+  struct loop *dr_loop = start_loop;
   start_loop = prepare_data_references (start_loop, datarefs);
   if (!start_loop
   /* Check if there is no data reference.  */
@@ -2022,7 +2023,7 @@ prepare_perfect_loop_nest (struct loop *loop, vec
*loop_nest,
 if (loop != start_loop)
   prune_datarefs_not_in_loop (start_loop, *datarefs);

-if (find_loop_nest (start_loop, loop_nest)
+if (find_loop_nest (dr_loop, loop_nest)
&& tree_loop_interchange_compute_ddrs (*loop_nest, *datarefs, ddrs))
   {
if (dump_file && (dump_flags & TDF_DETAILS))


With the following the ICE reproduces for me on x86_64-linux with
just -O2 -floop-interchange -fno-tree-dce

diff --git a/gcc/tree-data-ref.h b/gcc/tree-data-ref.h
index 11aa806a64d..54651e903ff 100644
--- a/gcc/tree-data-ref.h
+++ b/gcc/tree-data-ref.h
@@ -585,6 +585,7 @@ index_in_loop_nest (int var, vec loop_nest)
 if (loopi->num == var)
   break;

+  gcc_assert (var_index < loop_nest.length ());
   return var_index;
 }

[Bug middle-end/89725] ICE in get_fnname_from_decl, at varasm.c:1723

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Candidate patch for the first part:
  https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01362.html

[Bug c++/89858] crash with libmpfr.so.6

[hans.buchmann at fhnw dot ch]

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

--- Comment #6 from Hans Buchmann  ---
Created attachment 46048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46048=edit
Disassemly

[Bug middle-end/89725] ICE in get_fnname_from_decl, at varasm.c:1723

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Mine.

[Bug c/79022] trunk/gcc/gengtype.h: create_nested_ptr_option: decl & defn don't match ?

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Thu Mar 28 13:42:48 2019
New Revision: 269990

URL: https://gcc.gnu.org/viewcvs?rev=269990=gcc=rev
Log:
PR c/79022 fix mismatch parameter order in declaratio

The declaration of create_nested_ptr_option in the header has the 'from'
and 'to' parameters in the opposite order from the definition in
gengtype.c:

  /* Return an options structure for a "nested_ptr" option.  */
  options_p
  create_nested_ptr_option (options_p next, type_p t,
const char *to, const char *from)

and the only caller in gengtype-parse.c:

  return create_nested_ptr_option (prev, ty, to, from);

This patch swaps the parameter names in the declaration.

PR c/79022
* gengtype.h (create_nested_ptr_option): Fix parameter names to match
definition.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gengtype.h