[Bug middle-end/80764] [8 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in verify_loop_structure, at cfgloop.c:1644)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-pc-linux-gnu
  Component|c   |middle-end
Version|unknown |8.0
   Target Milestone|--- |8.0
Summary|ICE at -O3 in both 32-bit   |[8 Regression] ICE at -O3
   |and 64-bit modes on |in both 32-bit and 64-bit
   |x86_64-linux-gnu (internal  |modes on x86_64-linux-gnu
   |compiler error: in  |(internal compiler error:
   |verify_loop_structure, at   |in verify_loop_structure,
   |cfgloop.c:1644) |at cfgloop.c:1644)

[Bug middle-end/77721] -Wformat-truncation not uses arg range for converted vars

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|patch   |
 Status|ASSIGNED|NEW

--- Comment #6 from Martin Sebor  ---
The warning isn't issued at -Wformat-truncation=1 anymore but the underlying
problem still exists and can be seen at -Wformat-truncation=2 (see below).  As
mentined in comment #4, there is no patch for it, and I'm not working on one. 
The problem may clear up once the new VRP implementation lands.

$ gcc -O2 -S -Wall -Woverflow -Wconversion -Wpedantic -Wformat-truncation=2 -xc
t.c
t.c: In function ‘foo’:
t.c:7:21: warning: ‘%3u’ directive output may be truncated writing between 3
and 10 bytes into a region of size 4 [-Wformat-truncation=]
 snprintf(p, 4, "%3u", j);
 ^~~
t.c:7:5: note: ‘snprintf’ output between 4 and 11 bytes into a destination of
size 4
 snprintf(p, 4, "%3u", j);
 ^~~~
t.c: In function ‘bar’:
t.c:15:21: warning: ‘%3u’ directive output may be truncated writing between 3
and 10 bytes into a region of size 4 [-Wformat-truncation=]
 snprintf(p, 4, "%3u", k);
 ^~~
t.c:15:20: note: using the range [0, 4294967295] for directive argument
 snprintf(p, 4, "%3u", k);
^
t.c:15:5: note: ‘snprintf’ output between 4 and 11 bytes into a destination of
size 4
 snprintf(p, 4, "%3u", k);
 ^~~~

[Bug rtl-optimization/79286] [7 Regression] ira and lra wrong code at -O2 and -Os on i686-linux

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
   |patches/2017-02/msg00050.ht |patches/2017-02/msg00133.ht
   |ml  |ml

--- Comment #13 from Alan Modra  ---
I think we're done here.

[Bug fortran/80741] [Regression 7/8] incorrect behaviour of rewind with namelist

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle  ---
My initial looks are seeing a DTIO related frontend issue but this is not
causing the regression as far as I can tell.

I have looked at several other intervening patches and don't see anything
obvious, so I am starting a regression hunt.

If anyone beats me to it, report here, I will be monitoring this bug.

BTW, thanks James for the report. Much appreciated.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

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

--- Comment #27 from Jerry DeLisle  ---
(In reply to Rainer Orth from comment #15)
> The new testcase FAILs on 64-bit Solaris/SPARC:
> 
> +FAIL: gfortran.dg/dtio_26.f03   -O0  execution test

See if fixed on trunk now after commit to fix 80767.

[Bug fortran/80674] trunk/gcc/fortran/trans-stmt.c:2578]: (style) Redundant condition

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |8.0
   Severity|normal  |minor

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

[Bug libfortran/80727] [7/8 Regression] Crash of runtime gfortran library during integer transformation

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon May 15 23:48:39 2017
New Revision: 248080

URL: https://gcc.gnu.org/viewcvs?rev=248080=gcc=rev
Log:
2017-05-15  Jerry DeLisle  

PR libgfortran/80727
* transfer.c (read_sf_internal): Remove bogus code to detect EOR.
(read_block_form): For internal units, generate EOR if no more
bytes left in unit and we are trying to read with ADVANCE='NO'.

* gfortran.dg/read_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/read_3.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

[Bug fortran/80674] trunk/gcc/fortran/trans-stmt.c:2578]: (style) Redundant condition

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 15 23:46:23 2017
New Revision: 248079

URL: https://gcc.gnu.org/viewcvs?rev=248079=gcc=rev
Log:
2017-05-15  Steven G. Kargl  

PR fortran/80674
* trans-stmt.c (gfc_trans_integer_select): Remove redundant condition.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c

[Bug rtl-optimization/80770] New: suboptimal code negating a 1-bit _Bool field

[msebor at gcc dot gnu.org]

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

Bug ID: 80770
   Summary: suboptimal code negating a 1-bit _Bool field
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

For all targets I tried (powerpc64, sparcv9, and x86_64), GCC emits worse code
for the negation of a 1-bit _Bool field than it does for the equivalent _Bool
(non-bit) field.  The following test case shows the difference.  The code for
fb1 should look the same as the code for fb2.  A _Bool bit-field is typically
used as a (space) optimization so emitting bigger and slower code defeats its
sole purpose.

Clang emits the same code for both function for the same targets.

$ cat a.c && gcc -O2 -S -Wall -Wextra -Wconversion -o/dev/stdout a.c
struct S {
  _Bool b1: 1;
  _Bool b;
};

void fb1 (struct S *s)
{
  s->b1 = !s->b1;
}

void fb (struct S *s)
{
  s->b = !s->b;
}

.file   "a.c"
.text
.p2align 4,,15
.globl  fb1
.type   fb1, @function
fb1:
.LFB0:
.cfi_startproc
movzbl  (%rdi), %eax
movl%eax, %edx
andl$-2, %eax
andl$1, %edx
xorl$1, %edx
orl %edx, %eax
movb%al, (%rdi)
ret
.cfi_endproc
.LFE0:
.size   fb1, .-fb1
.p2align 4,,15
.globl  fb
.type   fb, @function
fb:
.LFB1:
.cfi_startproc
xorb$1, 1(%rdi)
ret
.cfi_endproc
.LFE1:
.size   fb, .-fb
.ident  "GCC: (GNU) 7.0.1 20170418 (experimental)"
.section.note.GNU-stack,"",@progbits
tmp$

[Bug fortran/80752] [5/6/7/8 Regression] ICE with wrong type initialization

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.  Thanks for bug report.

[Bug fortran/80752] [5/6/7/8 Regression] ICE with wrong type initialization

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 15 23:02:42 2017
New Revision: 248078

URL: https://gcc.gnu.org/viewcvs?rev=248078=gcc=rev
Log:
2017-05-15  Steven G. Kargl  

PR fortran/80752
* expr.c (gfc_generate_initializer):  If type conversion fails,
check for error and return NULL.

2017-05-15  Steven G. Kargl  

PR fortran/80752
gfortran.dg/pr80752.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr80752.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/expr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #2 from Daniel Santos  ---
Actually, I just realized that it won't help to move do_test.S into ms-sysv.c
as inline asm because each test still needs a unique ms-sysv-generated.h header
that's generated by the output of gen.cc.  Although I suppose it's possible to
generate all of the headers in advance (with unique names) and then set the
header name in the options with -DGEN_HEADER_NAME=name.h -- that will have its
own set of issues.

[Bug fortran/80752] [5/6/7/8 Regression] ICE with wrong type initialization

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 15 20:43:25 2017
New Revision: 248076

URL: https://gcc.gnu.org/viewcvs?rev=248076=gcc=rev
Log:
2017-05-15  Steven G. Kargl  

PR fortran/80752
* expr.c (gfc_generate_initializer):  If type conversion fails,
check for error and return NULL.

2017-05-15  Steven G. Kargl  

PR fortran/80752
gfortran.dg/pr80752.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr80752.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/80767] Eager instantiation of generic lambda body when not required

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is another manifestation of bug 71117.

[Bug libfortran/80602] Reduce stack usage for blocked matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
I just committed r248074 which I suspect is the same problem
(the fix for PR 80765).

If you could just upgrade to the most recent trunk (only
need to upgrade libgfortran, really) an check if the fix
also works for you, that would be great.

[Bug c++/79369] namespace definition with qualified id

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Author: nathan
Date: Mon May 15 20:26:19 2017
New Revision: 248075

URL: https://gcc.gnu.org/viewcvs?rev=248075=gcc=rev
Log:
PR c++/79369
* g++.dg/cpp1z/nested-namespace-def1.C: Adjust.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1z/nested-namespace-def1.C

[Bug libfortran/80602] Reduce stack usage for blocked matmul

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #5 from Pat Haugen  ---
(In reply to Thomas Koenig from comment #3)
> Author: tkoenig
> Date: Mon May  8 17:56:13 2017
> New Revision: 247753

This revision introduced a couple problems with SPEC on PowerPC. Both failures
happen for -m32 only.

1) CPU2000 178.galgel now fails with a verification error (i.e. incorrect
output).

2) CPU2006 465.tonto segfaults when running.

I'll add more detail as I continue digging...

[Bug tree-optimization/80769] Invalid delayed string length computation in tree-ssa-strlen.c

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-15
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Testing a patch.

[Bug fortran/80765] [8 Regression] 178.galgel in SPEC CPU 2000 fails to run

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
Committed fix (see https://gcc.gnu.org/ml/fortran/2017-05/msg00078.html ).

Closing as fixed.

[Bug fortran/80765] [8 Regression] 178.galgel in SPEC CPU 2000 fails to run

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Author: tkoenig
Date: Mon May 15 20:06:06 2017
New Revision: 248074

URL: https://gcc.gnu.org/viewcvs?rev=248074=gcc=rev
Log:
2017-05-15  Thomas Koenig  

PR fortran/80765
* m4/matmul_internal.m4: Set bystride to correct value in
vector-matrix multiplicatin for later calculation of buffer
size.
* generated/matmul_c10.c: Regenerated.
* generated/matmul_c16.c: Regenerated.
* generated/matmul_c4.c: Regenerated.
* generated/matmul_c8.c: Regenerated.
* generated/matmul_i1.c: Regenerated.
* generated/matmul_i16.c: Regenerated.
* generated/matmul_i2.c: Regenerated.
* generated/matmul_i4.c: Regenerated.
* generated/matmul_i8.c: Regenerated.
* generated/matmul_r10.c: Regenerated.
* generated/matmul_r16.c: Regenerated.
* generated/matmul_r4.c: Regenerated.
* generated/matmul_r8.c: Regenerated.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/matmul_c10.c
trunk/libgfortran/generated/matmul_c16.c
trunk/libgfortran/generated/matmul_c4.c
trunk/libgfortran/generated/matmul_c8.c
trunk/libgfortran/generated/matmul_i1.c
trunk/libgfortran/generated/matmul_i16.c
trunk/libgfortran/generated/matmul_i2.c
trunk/libgfortran/generated/matmul_i4.c
trunk/libgfortran/generated/matmul_i8.c
trunk/libgfortran/generated/matmul_r10.c
trunk/libgfortran/generated/matmul_r16.c
trunk/libgfortran/generated/matmul_r4.c
trunk/libgfortran/generated/matmul_r8.c
trunk/libgfortran/m4/matmul_internal.m4

[Bug c++/79369] namespace definition with qualified id

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Patch committed to trunk r248073.

[Bug target/63261] Microblaze 4.9.1, Error: PC relative branch to label which is not in the instruction space

[thomas.petazz...@free-electrons.com]

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

--- Comment #1 from Thomas Petazzoni  ---
This bug still exists in gcc 5.4.0 on Microblaze.

[Bug c++/79369] namespace definition with qualified id

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Mon May 15 19:35:52 2017
New Revision: 248073

URL: https://gcc.gnu.org/viewcvs?rev=248073=gcc=rev
Log:
gcc/cp/
PR c++/79369
* cp-tree.h (DECL_NAMESPACE_INLINE_P): New.
* name-lookup.h (push_namespace): Return int, add make_inline arg.
* name-lookup.c (push_namespace): Deal with inline directly.
Return pushed count.
* parser.c (cp_parser_namespace_definition): Adjust for
push_namespace change.

gcc/testsuite/
* g++.dg/cpp0x/pr65558.C: Adjust diagnostic location.
* g++.dg/cpp0x/pr79369.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr79369.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/name-lookup.h
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/pr65558.C

[Bug fortran/80752] [5/6/7/8 Regression] ICE with wrong type initialization

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 15 19:34:52 2017
New Revision: 248072

URL: https://gcc.gnu.org/viewcvs?rev=248072=gcc=rev
Log:
2017-05-15  Steven G. Kargl  

PR fortran/80752
* expr.c (gfc_generate_initializer):  If type conversion fails,
check for error and return NULL.

2017-05-15  Steven G. Kargl  

PR fortran/80752
gfortran.dg/pr80752.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr80752.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/80752] [5/6/7/8 Regression] ICE with wrong type initialization

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

[Bug rtl-optimization/80425] Extra inter-unit register move with zero-extension

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
Mostly fixed, an issue from Comment #4 remains, although *zero_extendsidi2
pattern now reads:

(define_insn "*zero_extendsidi2"
  [(set (match_operand:DI 0 "nonimmediate_operand"
"=r,?r,?o,r   ,o,?*Ym,?!*y,?r ,?r,?*Yi,*x,*x,*v,*r")
(zero_extend:DI
 (match_operand:SI 1 "x86_64_zext_operand"
"0 ,rm,r ,rmWz,0,r   ,m   ,*Yj,*x,r   ,m ,*x,*v,*k")))]

LRA starts with:

7: r96:DI=zero_extend([`a'])
   12: r92:V8DI#0=r95:V16SI>>r96:DI
  REG_DEAD r96:DI
  REG_DEAD r95:V16SI

and creates:

7: ax:DI=zero_extend([`a'])
   21: [bp:DI-0x38]=ax:DI
   22: xmm1:DI=[bp:DI-0x38]
   12: xmm0:V16SI=xmm0:V16SI>>xmm1:DI

xmm0 could be zero-extended directly from memory.

[Bug rtl-optimization/80425] Extra inter-unit register move with zero-extension

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
Author: uros
Date: Mon May 15 19:04:35 2017
New Revision: 248070

URL: https://gcc.gnu.org/viewcvs?rev=248070=gcc=rev
Log:
* config/i386.i386.md (*zero_extendsidi2): Do not penalize
non-interunit SSE move alternatives with '?'.
(zero-extendsidi peephole2): New peephole to skip intermediate
general register in SSE zero-extend sequence.

testsuite/ChangeLog:

* gcc.target/i386/pr80425-1.c: New test.
* gcc.target/i386/pr80425-2.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr80425-1.c
trunk/gcc/testsuite/gcc.target/i386/pr80425-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/80737] variant as class member resulting to compile errors

[timshen at gcc dot gnu.org]

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

--- Comment #6 from Tim Shen  ---
(In reply to TC from comment #5)
> (In reply to Tim Shen from comment #3)
> > (In reply to TC from comment #1)
> > > Looks like the constraint on the convert-everything constructor needs to
> > > check for is_same, variant> first and short circuit if that's
> > > true.
> > 
> > I'm not quite sure whether we need that short circuit - it's in a SFINAE
> > environment, so if anything goes wrong, there shouldn't be a hard error.
> > Therefore even if I agree that we should check is_same,
> > variant> first, that shouldn't affect the correctness.
> 
> I'm not sure I agree. As http://stackoverflow.com/a/43963065/2756719 points
> out, when you attempt to copy a variant, as part of overload resolution
> the code attempts to check if you can convert a variant to any; that in
> turn queries whether variant is copy constructible,

On this part I agree, that is: if there isn't a short circuiting, then a
instantiation circle will happen: variant(_Tp&&), then any(const
variant&), then is_nothrow_move_constructible, then
variant(_Tp&&).

> and we are very close to turtling all the way down.

The question is: how does the compiler handle an instantiation circle, and can
we rely on that handling?

Clang sees the instantiation circle and bailed out nicely, bascically rewinds
the instantiation stack and SFINAEed out variant(_Tp&&). However, GCC issued a
hard error.

I asked Richard Smith about what's the intended behavior here, and the answer
is that the standard doesn't talk about this.

> 
> It does seem like there might be a frontend problem here, though.

To conclude, there is a front-end implementation mismatch that cause this code
not to compile on GCC. For consistency with other places in libstdc++, I'll
short-circuit the SFINAE expression.

In addition, https://godbolt.org/g/AxUv16 reveals a weird GCC behavior
(with/without -DBUG) that might be a separate bug.

[Bug tree-optimization/80769] New: Invalid delayed string length computation in tree-ssa-strlen.c

[rsandifo at gcc dot gnu.org]

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

Bug ID: 80769
   Summary: Invalid delayed string length computation in
tree-ssa-strlen.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

This testcase below (which uses strlenopt.h in gcc/testsuite/gcc.dg) fails at
-O2 but passes with -O0.  tree-ssa-strlen.c isn't invalidating delayed string
lengths when "x" is added to the end.


#define USE_GNU
#include "strlenopt.h"

__attribute__((noinline, noclone)) int
bar (char *p1, const char *q)
{
  strcpy (p1, "abcde");
  char *p2 = strchr (p1, '\0');
  strcpy (p2, q);
  char *p3 = strchr (p2, '\0');
  memcpy (p3, "x", 2);
  return strlen (p1);
}

int
main (void)
{
  char buffer[10];
  int res = bar (buffer, "foo");
  if (strcmp (buffer, "abcdefoox") != 0 || res != 9)
abort ();
  return 0;
}

[Bug fortran/80752] [5/6/7/8 Regression] ICE with wrong type initialization

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Mon, May 15, 2017 at 05:57:38PM +, kargl at gcc dot gnu.org wrote:
> 
> --- Comment #2 from kargl at gcc dot gnu.org ---
> Here's two possible patches.
>
Here's a 3rd possible patch, and it appears to do what is
needed.

Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (revision 248066)
+++ gcc/fortran/expr.c  (working copy)
@@ -4395,7 +4395,12 @@ gfc_generate_initializer (gfc_typespec *
  if ((comp->ts.type != tmp->ts.type
   || comp->ts.kind != tmp->ts.kind)
  && !comp->attr.pointer && !comp->attr.proc_pointer)
-   gfc_convert_type_warn (ctor->expr, >ts, 2, false);
+   {
+ bool val;
+ val = gfc_convert_type_warn (ctor->expr, >ts, 1, false);
+ if (val == false)
+   return NULL;
+   }
}

   if (comp->attr.allocatable

[Bug rtl-optimization/80754] invalid smull instructions generated after r247881

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-15
 CC||wilco at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from wilco at gcc dot gnu.org ---
(In reply to Richard Earnshaw from comment #1)
> I suspect this has just revealed a latent issue.
> 
> How can it be right for the register allocator to assign the same register
> to *two* different output operands?

The problem is that lra-remat doesn't check whether scratch registers have been
allocated to the same register as the destination when rematerializing an
instruction into a move:

smull r8, r2, r1, r3  (r8 is a scratch, r2 is dest)
mov r8, r2
->
smull r8, r8, r1, r3

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #1 from Daniel Santos  ---
(In reply to Rainer Orth from comment #0)
> It seems to me that ms-sysv.exp is seriously misguided in trying to do all
> its compilations manually instead of using
> dg-test/dg-runtest/gcc_target_compile
> which whould nicely avoid all those issues.

Well, this was my introduction to DejaGnu and the test harness.  I found that
none of these support doing a build when there is more than one object file --
in my case, I'm linking the output of both ms-sysv.c and do_test.S.  However,
this test started out with multiple .c files and I was able to reduce it down
to one.  I'm going to see if there's a way to cleanly do my assembly inline and
reduce it down to a single translation unit which gc-runtest, et. al. will work
with.  Otherwise, I'll have to fix the .struct, CFLAGS and multiple warnings.

If I'm wrong about the single object file thing, please point me in the right
direction.

> The new gcc.target/x86_64/abi/ms-sysv tests FAIL in various e.g. on
> i386-pc-solaris2.*
> and i686-pc-linux-gnu:
> 
> * In those 32-bit-default configurations, the 32-bit multilib is skipped as
>   unsupported as expected (although the UNSUPPORTED entry in gcc.sum occurs
>   e.g. 45 times for -j48 testing instead of only once),

Sadly, I discovered that by not using the standard test functions that I had to
cook up my own parallelism scheme, otherwise all of my tests would run once for
each -j!  I think that this issue is fixable though.

[Bug fortran/80752] [5/6/7/8 Regression] ICE with wrong type initialization

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Here's two possible patches.  The first possible patch
converts the reported error from an internal error to a
fatal error.

Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c (revision 248066)
+++ gcc/fortran/intrinsic.c (working copy)
@@ -4900,7 +4900,7 @@ gfc_convert_type (gfc_expr *expr, gfc_ty
The possible values are:

  1 Generate a gfc_error()
- 2 Generate a gfc_internal_error().
+ 2 Generate a gfc_fatal_error().

'wflag' controls the warning related to conversion.  */

@@ -5064,7 +5064,7 @@ bad:
   return false;
 }

-  gfc_internal_error ("Can't convert %qs to %qs at %L",
+  gfc_fatal_error ("Can't convert %qs to %qs at %L",
  gfc_typename (_ts), gfc_typename (ts),
  >where);
   /* Not reached */

The second possible patch allows the gfortran to continue
processing the code, but the error is repeated 3 times.

Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (revision 248066)
+++ gcc/fortran/expr.c  (working copy)
@@ -4395,7 +4395,7 @@ gfc_generate_initializer (gfc_typespec *
  if ((comp->ts.type != tmp->ts.type
   || comp->ts.kind != tmp->ts.kind)
  && !comp->attr.pointer && !comp->attr.proc_pointer)
-   gfc_convert_type_warn (ctor->expr, >ts, 2, false);
+   gfc_convert_type_warn (ctor->expr, >ts, 1, false);
}

   if (comp->attr.allocatable

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
On Mon, 15 May 2017, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730
> 
> --- Comment #5 from Martin Sebor  ---
> I"m not sure I understand what you're saying.  Your comment that "the
> initializer *as 
> converted* must be a constant expression (and, thus, to be an address 
> constant, must be of pointer type)" makes it sound as an argument for 
> rejecting
> '_Bool b = "";' which would mean that you think '_Bool b = a;' should be
> rejected as well.  But your other comment that you'd "consider it appropriate
> to handle implicit conversions in initializers exactly the same as casts are
> handled" sounds as though you think '_Bool b = "";' should be accepted 
> (because
> '_Bool b = (_Bool)"";' is accepted).  So I'm not sure what to make of it.

I think both '_Bool b = "";' and '_Bool b = (_Bool)"";' should be handled 
the same, regarding what's accepted with what options and what 
diagnostics.  I don't think the standard should be interpreted in a way 
that handles them differently or that requires either of them to be 
accepted.  Actually accepting them is fairly harmless.  (Those particular 
cases don't involve anything *forbidden* in a constant expression, such as 
a function call, so don't actually require a pedwarn-if-pedantic, although 
I think such a diagnostic with -pedantic makes sense.)

> The most useful behavior is to accept all three with a pedantic warning.  It
> makes it easy to port code to GCC that was written to one of these compilers,
> while also making it possible to find out about portability problems when
> porting to other compilers.  Do you agree with this as a goal to work toward?

Yes.

Re: [Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

[Joseph Myers]

On Mon, 15 May 2017, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730
> 
> --- Comment #5 from Martin Sebor  ---
> I"m not sure I understand what you're saying.  Your comment that "the
> initializer *as 
> converted* must be a constant expression (and, thus, to be an address 
> constant, must be of pointer type)" makes it sound as an argument for 
> rejecting
> '_Bool b = "";' which would mean that you think '_Bool b = a;' should be
> rejected as well.  But your other comment that you'd "consider it appropriate
> to handle implicit conversions in initializers exactly the same as casts are
> handled" sounds as though you think '_Bool b = "";' should be accepted 
> (because
> '_Bool b = (_Bool)"";' is accepted).  So I'm not sure what to make of it.

I think both '_Bool b = "";' and '_Bool b = (_Bool)"";' should be handled 
the same, regarding what's accepted with what options and what 
diagnostics.  I don't think the standard should be interpreted in a way 
that handles them differently or that requires either of them to be 
accepted.  Actually accepting them is fairly harmless.  (Those particular 
cases don't involve anything *forbidden* in a constant expression, such as 
a function call, so don't actually require a pedwarn-if-pedantic, although 
I think such a diagnostic with -pedantic makes sense.)

> The most useful behavior is to accept all three with a pedantic warning.  It
> makes it easy to port code to GCC that was written to one of these compilers,
> while also making it possible to find out about portability problems when
> porting to other compilers.  Do you agree with this as a goal to work toward?

Yes.

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug fortran/80741] [Regression 7/8] incorrect behaviour of rewind with namelist

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-15
 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
Summary|incorrect behaviour of  |[Regression 7/8] incorrect
   |rewind with namelist|behaviour of rewind with
   ||namelist
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
Confirmed and a regression

[Bug rtl-optimization/80747] [6/7/8 Regression] gcc.dg/tree-ssa/tailrecursion-4.c fails with ICE when compiled with options "-fprofile-use -freorder-blocks-and-partition"

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Hi Zhangwen,

That patch looks correct.  The explanation maybe not: the problem happens
if the earliest "end" is the entry block itself, not a real BB (that is,
if we start the function with a newly inserted jump).  We could detect
just that, and/or we can add some extra asserts; or do as in your patch,
that looks fine to me as well.

A few minor comments for when you submit the patch:

-- It is spelled "default", not "defualt";
-- We don't use "yoda conditions" in GCC ("0 == x");
-- You shouldn't use 0 but instead use BB_UNPARTITIONED.

Thanks for finding the problem and making a patch!

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #14 from Steve Kargl  ---
On Mon, May 15, 2017 at 04:57:37PM +, zeccav at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392
> 
> --- Comment #13 from Vittorio Zecca  ---
> Steve, you know why I do not like you.

Because I point out your flaws?  Instead of your passive aggressive
comment:

>>  Still in 7.1.0 and in trunk 8.0.0!
>>  Will it ever be fixed?

Try something like

  I was going through some old bug reports and found
  PR 50392 still open.  I tested the patch in comment #4,
  and it appears to fix the problem.  Could someone review
  and commit the patch?

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

[zeccav at gmail dot com]

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

--- Comment #13 from Vittorio Zecca  ---
Steve, you know why I do not like you.
If you are so sensitive please take care of the sensitivity of people
submitting bugs
and do not call them "idiot".
But this is not relevant here.

What is relevant is that I just ran "make check-fortran" and it was
almost clean,
except for another NULL pointer dereferencing at check.c with coarrays.
I just opened a new bug 80768.
For what regards me you are welcome to look into it and provide me with a
patch.

[Bug fortran/80768] New: NULL pointer dereferenced in gfc_check_num_images at fortran/check.c

[zeccav at gmail dot com]

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

Bug ID: 80768
   Summary: NULL pointer dereferenced in gfc_check_num_images at
fortran/check.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! NULL pointer dereferenced in gfc_check_num_images at fortran/check.c:5150
! gfortran 8.0.0 trunk 247930 
! Target: x86_64-pc-linux-gnu
! must be compiled with option -fcoarray=single
! check.c:5150 if (!gfc_notify_std (GFC_STD_F2008_TS, "FAILED= argument to
NUM_IMAGES at %L", >where))
! pointer "distance" is NULL
! double checked with "gcc_assert(distance);" that fails producing the ICE
!
  k5 = num_images(failed=.false.)
  end
!f951: internal compiler error: in gfc_check_num_images, at
fortran/check.c:5150
!0x5f84c0 gfc_check_num_images(gfc_expr*, gfc_expr*)
!   ../../gcc/fortran/check.c:5150
!0x6e69d8 do_check
!   ../../gcc/fortran/intrinsic.c:263
!0x6ee74a check_specific
!   ../../gcc/fortran/intrinsic.c:4525
!0x6fab7b gfc_intrinsic_func_interface(gfc_expr*, int)
!   ../../gcc/fortran/intrinsic.c:4761
!0x85b8ab resolve_unknown_f
!   ../../gcc/fortran/resolve.c:2723
!0x8a08a0 resolve_function
!   ../../gcc/fortran/resolve.c:3025
!0x898ca6 gfc_resolve_expr(gfc_expr*)
!   ../../gcc/fortran/resolve.c:6505
!0x8db4ed gfc_resolve_code(gfc_code*, gfc_namespace*)
!   ../../gcc/fortran/resolve.c:10848
!0x8e3073 resolve_codes
!   ../../gcc/fortran/resolve.c:16060
!0x881ecd gfc_resolve(gfc_namespace*)
!   ../../gcc/fortran/resolve.c:16095
!0x812848 resolve_all_program_units
!   ../../gcc/fortran/parse.c:6013
!0x829f80 gfc_parse_file()
!   ../../gcc/fortran/parse.c:6260
!0x96f9a9 gfc_be_parse_file
!   ../../gcc/fortran/f95-lang.c:204
!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++/80763] -O3 causes error: inline clone in same comdat group list

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from David Binderman  ---
Problem seems to be between revision 236957 and 236961,
but I can't pin it down further. svn info tells me I
am at revision 236961, but the last revision was 236947 ??

Jason seems to have been doing something to templates
somewhere near there. Maybe they can offer further advice or
at very least eliminate themselves from the list of suspects.

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I"m not sure I understand what you're saying.  Your comment that "the
initializer *as 
converted* must be a constant expression (and, thus, to be an address 
constant, must be of pointer type)" makes it sound as an argument for rejecting
'_Bool b = "";' which would mean that you think '_Bool b = a;' should be
rejected as well.  But your other comment that you'd "consider it appropriate
to handle implicit conversions in initializers exactly the same as casts are
handled" sounds as though you think '_Bool b = "";' should be accepted (because
'_Bool b = (_Bool)"";' is accepted).  So I'm not sure what to make of it.

The point I am trying to make is that the GCC behavior, besides being
inconsistent, is not friendly or useful, no mater how one interprets the intent
of the standard.  Taking the three cases:

  _Bool b0 = "";// rejected by GCC with an error
  _Bool b1 = !"";   // accepted by GCC without a warning

  const char a[] = "";
  _Bool b2 = a; // accepted with -Waddress

in each the initializer is the result of converting an address constant to
_Bool.

IBM XLC and Oracle c99 warn on the first and third and reject the second with
an error.  That's just as unhelpful as what GCC does.

Clang, ICC, and even Visual C, accept all three (Clang issues
-Wpointer-bool-conversion for the third, the other two are silent).  That's
much better.

The most useful behavior is to accept all three with a pedantic warning.  It
makes it easy to port code to GCC that was written to one of these compilers,
while also making it possible to find out about portability problems when
porting to other compilers.  Do you agree with this as a goal to work toward?

[Bug c++/80605] [7/8 Regression] Bad is_standard_layout result with empty base classes

[ed at catmur dot co.uk]

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

--- Comment #8 from Ed Catmur  ---
Looks to have been fixed by r247816.

[Bug fortran/80766] [7/8 Regression] ICE with type bound procedures returning an array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||6.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-05-15
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|[7 Regression] ICE with |[7/8 Regression] ICE with
   |type bound procedures   |type bound procedures
   |returning an array  |returning an array
   Target Milestone|--- |7.2
  Known to fail||7.1.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed, likely r241403 (pr69566).

[Bug c++/80737] variant as class member resulting to compile errors

[rs2740 at gmail dot com]

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

--- Comment #5 from TC  ---
(In reply to Tim Shen from comment #3)
> (In reply to TC from comment #1)
> > Looks like the constraint on the convert-everything constructor needs to
> > check for is_same, variant> first and short circuit if that's
> > true.
> 
> I'm not quite sure whether we need that short circuit - it's in a SFINAE
> environment, so if anything goes wrong, there shouldn't be a hard error.
> Therefore even if I agree that we should check is_same,
> variant> first, that shouldn't affect the correctness.

I'm not sure I agree. As http://stackoverflow.com/a/43963065/2756719 points
out, when you attempt to copy a variant, as part of overload resolution
the code attempts to check if you can convert a variant to any; that in
turn queries whether variant is copy constructible, and we are very close
to turtling all the way down.

It does seem like there might be a frontend problem here, though.

[Bug libstdc++/80762] is_constructible<filesystem::path, void> gives hard error with clang

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-15
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
And this fails even with GCC:

#include 

int main()
{
  using std::experimental::filesystem::path;

  static_assert( !std::is_constructible::value, "");
}

[Bug c/65430] Missing -Wsequence-point warning with COMPOUND_EXPRs

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Well, that's not quite right because of e.g. unevaluated || operand.

[Bug c++/80763] -O3 causes error: inline clone in same comdat group list

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Problem now seems to be between revision 236947 and 236961.

Continuing the search.

[Bug c/65430] Missing -Wsequence-point warning with COMPOUND_EXPRs

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
This ought to fix both problems:

--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -10443,6 +10443,7 @@ tree
 c_process_expr_stmt (location_t loc, tree expr)
 {
   tree exprv;
+  tree orig_expr = expr;

   if (!expr)
 return NULL_TREE;
@@ -10450,7 +10451,7 @@ c_process_expr_stmt (location_t loc, tree expr)
   expr = c_fully_fold (expr, false, NULL);

   if (warn_sequence_point)
-verify_sequence_points (expr);
+verify_sequence_points (orig_expr);

   if (TREE_TYPE (expr) != error_mark_node
   && !COMPLETE_OR_VOID_TYPE_P (TREE_TYPE (expr))
@@ -10462,7 +10463,7 @@ c_process_expr_stmt (location_t loc, tree expr)
  out which is the result.  */
   if (!STATEMENT_LIST_STMT_EXPR (cur_stmt_list)
   && warn_unused_value)
-emit_side_effect_warnings (EXPR_LOC_OR_LOC (expr, loc), expr);
+emit_side_effect_warnings (EXPR_LOC_OR_LOC (orig_expr, loc), orig_expr);

   exprv = expr;
   while (TREE_CODE (exprv) == COMPOUND_EXPR)

[Bug c++/80767] New: Eager instantiation of member template when not required

[barry.revzin at gmail dot com]

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

Bug ID: 80767
   Summary: Eager instantiation of member template when not
required
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Here's a simplifed example of overloading taking from StackOverflow question
http://stackoverflow.com/q/43982799/2069064:

template  
struct overloader : Fs...
{
overloader(Fs... fs) 
: Fs(fs)...
{ } 

using Fs::operator()...;
};

struct a { void foo() { } };
struct b { void bar() { } };
struct c { void bar() { } };

struct CallFoo {
auto operator()(a x) const { x.foo(); }
};

int main() {
overloader{
#ifdef BUG
[](a x) { x.foo(); },
#else
CallFoo{},
#endif
[](auto x) { x.bar(); }
}(a{});
}

If BUG is not defined, this compiles fine. But if BUG is defined (which just
swaps a lambda for an equivalent funject), the generic lambda's call operator
is instantiated (even though the non-generic lambda should be preferred) and
the program fails to compile with:

foo.cxx: In instantiation of ‘main():: [with auto:1 = a]’:
foo.cxx:26:18:   required by substitution of ‘template constexpr
main()::::operator decltype (((const
main()::*)((const main()::*
const)0))->operator()(static_cast())) (*)(auto:1)() const
[with auto:1 = a]’
foo.cxx:27:10:   required from here
foo.cxx:26:24: error: ‘struct a’ has no member named ‘bar’
 [](auto x) { x.bar(); }
  ~~^~~

[Bug fortran/80766] New: [7 Regression] ICE with type bound procedures returning an array

[vladimir.fuka at gmail dot com]

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

Bug ID: 80766
   Summary: [7 Regression] ICE with type bound procedures
returning an array
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com
  Target Milestone: ---

The following:

module m1

  type :: base
  contains
 procedure :: fun
  end type

  type, extends(base) :: child
  end type

contains

  function fun(o) result(res)
real :: res(3)
class(base) :: o

res = 0
  end function
end module


module m2
contains

  subroutine sub(o)
use m1
class(child) :: o
real :: res(3)

res = o%fun()
  end subroutine
end module


causes:

> gfortran-7 -cpp ice12.f90  -c
ice12.f90:30:0:

 res = o%fun()

internal compiler error: in fold_convert_loc, at fold-const.c:2303
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


in gfortran 7.1.1 (from the OpenSUSE GCC devel repository)

It does not ICE if the subroutine is external or in module m1. It does not ICE
if the base is used instead of child. It does not ICE if the function returns a
scalar.

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl  ---
On Mon, May 15, 2017 at 02:27:04PM +, zeccav at gmail dot com wrote:
> 
> --- Comment #11 from Vittorio Zecca  ---
> You still around, Steven?
> I cannot say I missed you.

I've never left, and you're more than welcomed to delete
all my patches from your copy of gfortran as you can
obviously to better. 

% grep -i kargl gcc/fortran/ChangeLog-2011 | wc -l
  15
% grep -i kargl gcc/fortran/ChangeLog-2012 | wc -l
   3
% grep -i kargl gcc/fortran/ChangeLog-2013 | wc -l
   3
% grep -i kargl gcc/fortran/ChangeLog-2015 | wc -l
  62
% grep -i kargl gcc/fortran/ChangeLog-2016 | wc -l
  53
% grep -i kargl gcc/fortran/ChangeLog | wc -l
   1
% grep -i kargl libgfortran/ChangeLog-2013 | wc -l
   1
% grep -i kargl libgfortran/ChangeLog-2014 | wc -l
   2
% grep -i kargl libgfortran/ChangeLog-2015 | wc -l
   2
% grep -i kargl libgfortran/ChangeLog-2016 | wc -l
   1
% grep -i kargl libgfortran/ChangeLog | wc -l
   1

I do find posts of the form

>  Still in 7.1.0 and in trunk 8.0.0!
>  Will it ever be fixed?

to be rather condescending.  There is a dwindling number of
gfortran developers, and posts like yours is a contributing
reason.

[Bug ipa/80728] IPA-reference suppresses compiler memory barrier

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On May 15, 2017 4:43:04 PM GMT+02:00, "amonakov at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
>
>--- Comment #6 from Alexander Monakov  ---
>I think a possible approach is to add a new cgraph_node flag (or a
>multi-bit
>field, if we want to track presence of acquire/release/seq-cst compiler
>barriers separately), handle asms and atomics specially in
>cgraphbuild.c to set
>that flag, and finally use the new flag in ipa-reference.c?

Yes.  Something like that.  Let's see if Honza has any comments.

[Bug sanitizer/80659] [7/8 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
(In reply to Martin Liška from comment #6)
> Marek, can you please take a look why the VAR_DECL built from the expr_stmt
> is not assigned in a BIND_EXPR?

In C, non-static compound literals aren't pushed into any scope, so the
BIND_EXPR doesn't have that VAR_DECL.  But instead of pushing such complits
into any scope we might just mark it as an artificial decl; I noticed

 1647   if (!DECL_ARTIFICIAL (decl) && gimplify_ctxp->live_switch_vars)
 1648 gimplify_ctxp->live_switch_vars->add (decl);
 1649 }

so I think this should fix it:

--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -5265,6 +5265,7 @@ build_compound_literal (location_t loc, tree type, tree
init, bool non_const)
   TREE_READONLY (decl) = (TYPE_READONLY (type)
  || (TREE_CODE (type) == ARRAY_TYPE
  && TYPE_READONLY (TREE_TYPE (type;
+  DECL_ARTIFICIAL (decl) = 1;
   store_init_value (loc, decl, init, NULL_TREE);

   if (TREE_CODE (type) == ARRAY_TYPE && !COMPLETE_TYPE_P (type))
@@ -5297,7 +5298,6 @@ build_compound_literal (location_t loc, tree type, tree
init, bool non_const)
   set_compound_literal_name (decl);
   DECL_DEFER_OUTPUT (decl) = 1;
   DECL_COMDAT (decl) = 1;
-  DECL_ARTIFICIAL (decl) = 1;
   DECL_IGNORED_P (decl) = 1;
   pushdecl (decl);
   rest_of_decl_compilation (decl, 1, 0);

[Bug fortran/80765] New: [8 Regression] 178.galgel in SPEC CPU 2000 fails to run

[hjl.tools at gmail dot com]

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

Bug ID: 80765
   Summary: [8 Regression] 178.galgel in SPEC CPU 2000 fails to
run
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: tkoenig at gcc dot gnu.org
  Target Milestone: ---
Target: i386

On Linux/i686, r247753 caused 178.galgel in SPEC CPU 2000 fails to run:

...
 Solution by global spectral Galerkin method.


 Parameters:

 Aspect ratio (length/height) =  4.000
 Prandtl number   = 0.1500E-01

 Number of basis functions in x-direction =  33
 Number of basis functions in z-direction =  11




Program received signal SIGSEGV, Segmentation fault.
0xf7ed2a02 in matmul_r8_avx2 (retarray=, a=, 
b=, try_blas=, blas_limit=, 
gemm=)
at ../../../../src-trunk/libgfortran/generated/matmul_r8.c:911
911   t1[l - ll + 1 + ((i - ii + 1) << 8) - 257] =
(gdb) 

=> 0xf7ed2a02 <+2658>:  vmovsd %xmm2,(%edi,%ecx,8)

(gdb) p $edi
$5 = 0
(gdb) p/x $ecx
$7 = 0x2000
(gdb) p/x 0x2000 * 8
$10 = 0x0

[Bug c/80764] New: ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in verify_loop_structure, at cfgloop.c:1644)

[chengniansun at gmail dot com]

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

Bug ID: 80764
   Summary: ICE at -O3 in both 32-bit and 64-bit modes on
x86_64-linux-gnu (internal compiler error: in
verify_loop_structure, at cfgloop.c:1644)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170515 (experimental) [trunk revision 248042] (GCC) 
$ gcc-trunk -O3 small.c
small.c: In function ‘fn1.part.0’:
small.c:12:1: error: size of loop 9 should be 6, not 7
 }
 ^
small.c:12:1: error: loop 10’s latch does not have an edge to its header
small.c:12:1: internal compiler error: in verify_loop_structure, at
cfgloop.c:1644
0x7ba18a verify_loop_structure()
../../gcc-source-trunk/gcc/cfgloop.c:1644
0xb2ae3a execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1984
0xb2b855 execute_todo
../../gcc-source-trunk/gcc/passes.c:2022
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.
$ cat small.c
int b, d, f, h;
char e;
int fn1();
int main() { return fn1(); }
int fn1(int p1) {
  for (; d;)
for (; e < 3;) {
  for (; h;)
b = fn1(0);
  return f;
}
}
$

[Bug c++/80763] -O3 causes error: inline clone in same comdat group list

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
>The problem seems to exist between revisions 247438 and 247811.
>I'll have a go at trying to reduce that range.

I'm wrong with my range of revisions. Problem now seems to exist sometime 
before revision 236961.

I haven't got revisions from before that one. It will take some
time to generate them. I'll report back in the next day or two, unless
someone wants to volunteer to find the offending revision.

[Bug c++/80763] -O3 causes error: inline clone in same comdat group list

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Here is the reduced code

struct b {
  virtual ~b();
};
struct c {
  virtual unsigned d(unsigned, unsigned);
  virtual unsigned f(unsigned, unsigned, unsigned, unsigned) = 0;
};
template  class i : e, c {
public:
  float *g[e::h];
  unsigned d(unsigned k, unsigned) {
bool j;
j ? f(k, k, 1, 1) : 0;
  }
};
struct l : b {
  enum { h };
};
class n : i {
  unsigned f(unsigned, unsigned, unsigned, unsigned) {
float *m = g[0];
float a[512];
m[0] = a[0];
  }
  virtual void o();
};
void n::o() {}

[Bug c++/80763] New: -O3 causes error: inline clone in same comdat group list

[dcb314 at hotmail dot com]

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

Bug ID: 80763
   Summary: -O3 causes error: inline clone in same comdat group
list
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 41360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41360=edit
gzipped C++ source code

The attached code does this with -O3

wavetable.cpp:622:1: error: inline clone in same comdat group list
_ZThn232_N12calf_plugins22wavetable_audio_module7processE.artificial_thunk.36/3381
(_ZThn232_N12calf_plugins22wavetable_audio_module7processE.artificial_thunk.36)
@0x7f866b098b80
  Type: function definition analyzed
  Visibility:
comdat_group:_ZN12calf_plugins12audio_moduleINS_18wavetable_metadataEE13process_sliceEjj
artificial
  Same comdat group as:
_ZThn232_N12calf_plugins22wavetable_audio_module7processE.artificial_thunk.36/3301
  next sharing asm name: 3301
  References: 
  Referring: 
  Function
_ZThn232_N12calf_plugins22wavetable_audio_module7processE.artificial_thunk.36/3381
is inline copy in virtual uint32_t
calf_plugins::audio_module::_ZThn232_N12calf_plugins12audio_moduleINS_18wavetable_metadataEE13process_sliceEjj(uint32_t,
uint32_t)/2956
  Clone of
_ZThn232_N12calf_plugins22wavetable_audio_module7processE.artificial_thunk.36/3301
  Availability: local
  First run: 0
  Function flags: local
  Thunk fixed offset -232 virtual value 0 has virtual offset 0)
  Called by:
_ZN12calf_plugins12audio_moduleINS_18wavetable_metadataEE13process_sliceEjj/3380
(speculative) (inlined) (3.90 per call) (can throw external) 
  Calls:
_ZN12calf_plugins22wavetable_audio_module7processE.constprop.35/3300 (3.90
per call) 
wavetable.cpp:622:1: internal compiler error: verify_cgraph_node failed
0x9853ab cgraph_node::verify_node()
../../trunk/gcc/cgraph.c:3507
0x979724 symtab_node::verify()
../../trunk/gcc/symtab.c:1191
0x979724 symtab_node::verify_symtab_nodes()
../../trunk/gcc/symtab.c:1211
0x98daa3 symtab_node::checking_verify_symtab_nodes()
../../trunk/gcc/cgraph.h:613

The problem seems to exist between revisions 247438 and 247811.
I'll have a go at trying to reduce that range.

I'll also have a go at reducing the code.

[Bug ipa/80728] IPA-reference suppresses compiler memory barrier

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
I think a possible approach is to add a new cgraph_node flag (or a multi-bit
field, if we want to track presence of acquire/release/seq-cst compiler
barriers separately), handle asms and atomics specially in cgraphbuild.c to set
that flag, and finally use the new flag in ipa-reference.c?

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

[zeccav at gmail dot com]

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

--- Comment #11 from Vittorio Zecca  ---
You still around, Steven?
I cannot say I missed you.

Nobody asked me to apply those fixes, I imagined that Tobias Burnus,
their author,
would try them and eventually apply them.
It seems that it did not happen.

Anyway, I just applied the patches to the trunk 8.0.0 level 247930 and
the ICE disappeared.

[Bug libstdc++/80762] New: is_constructible<filesystem::path, void> gives hard error with clang

[redi at gcc dot gnu.org]

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

Bug ID: 80762
   Summary: is_constructible gives hard
error with clang
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

int main()
{
  static_assert(
  !std::is_constructible::value,
  "");
}

This fails to compile with Clang:


In file included from fs.cc:1:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/experimental/filesystem:38:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/experimental/bits/fs_fwd.h:37:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/system_error:41:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/stdexcept:38:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/exception:171:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/bits/nested_exception.h:40:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/bits/move.h:57:
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/type_traits:144:14:
error: ambiguous partial specializations of '__constructible_from'
: public conditional<_B1::value, _B2, _B1>::type
 ^
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/experimental/bits/fs_path.h:124:17:
note: in instantiation of template class
'std::__and_ >,
std::experimental::filesystem::v1::__cxx11::path::__constructible_from >' requested here
std::enable_if<__and_<__not_>,
   ^
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/experimental/bits/fs_path.h:194:27:
note: in instantiation of template type alias '_Path' requested here
 typename _Require = _Path<_Source>>
 ^
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/experimental/bits/fs_path.h:195:7:
note: in instantiation of default argument for 'path' required here
  path(_Source const& __source)
  ^
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/type_traits:970:28:
note: while substituting deduced template arguments into function template
'path'
  [with _Source = void, _Require = (no value)]
 = decltype(::new _Tp(declval<_Arg>()))>
  ^
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/type_traits:971:24:
note: in instantiation of default argument for
'__test' required
  here
  static true_type __test(int);
   ^~~
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/type_traits:981:24:
note: (skipping 3 contexts in backtrace; use -ftemplate-backtrace-limit=0 to
see all)
  typedef decltype(__test<_Tp, _Arg>(0)) type;
   ^
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/type_traits:1068:14:
note: in instantiation of template class
 
'std::__is_direct_constructible_new_safe' requested here
: public conditional::value,
 ^
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/type_traits:1076:14:
note: in instantiation of template class
 
'std::__is_direct_constructible_new' requested here
: public __is_direct_constructible_new<_Tp, _Arg>::type
 ^
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/type_traits:1116:14:
note: in instantiation of template class
 
'std::__is_direct_constructible' requested here
: public __is_direct_constructible<_Tp, _Arg>
 ^
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../include/c++/6.3.1/type_traits:1127:14:
note: in instantiation of template class
'std::__is_constructible_impl' requested here
: public __is_constructible_impl<_Tp, _Args...>::type
 ^
fs.cc:6:13: note: in instantiation of template class
'std::is_constructible'
requested here
  !std::is_constructible::value,
 

[Bug libstdc++/80761] std::set<T,C,A>::insert_return_type uses wrong iterator type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for 7.2

[Bug libstdc++/80761] std::set<T,C,A>::insert_return_type uses wrong iterator type

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon May 15 14:01:38 2017
New Revision: 248063

URL: https://gcc.gnu.org/viewcvs?rev=248063=gcc=rev
Log:
Fix order and types of members in C++17 insert_return_type structs

PR libstdc++/80761
* include/bits/node_handle.h (_Node_insert_return): Reorder members.
(tuple_size, tuple_element): Remove partial specializations.
* include/bits/stl_tree.h (_Rb_tree::insert_return_type): Use
const_iterator for std::set.
* testsuite/23_containers/map/modifiers/extract.cc: New.
* testsuite/23_containers/set/modifiers/extract.cc: New.
* testsuite/23_containers/unordered_map/modifiers/extract.cc: New.
* testsuite/23_containers/unordered_set/modifiers/extract.cc: New.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/node_handle.h
branches/gcc-7-branch/libstdc++-v3/include/bits/stl_tree.h
   
branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/map/modifiers/extract.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/set/modifiers/extract.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/unordered_map/modifiers/extract.cc
   
branches/gcc-7-branch/libstdc++-v3/testsuite/23_containers/unordered_set/modifiers/extract.cc

[Bug rtl-optimization/80754] invalid smull instructions generated after r247881

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org
  Component|target  |rtl-optimization

--- Comment #1 from Richard Earnshaw  ---
I suspect this has just revealed a latent issue.

How can it be right for the register allocator to assign the same register to
*two* different output operands?

[Bug libstdc++/80761] std::set<T,C,A>::insert_return_type uses wrong iterator type

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon May 15 13:47:40 2017
New Revision: 248062

URL: https://gcc.gnu.org/viewcvs?rev=248062=gcc=rev
Log:
Fix order and types of members in C++17 insert_return_type structs

PR libstdc++/80761
* include/bits/node_handle.h (_Node_insert_return): Reorder members.
(tuple_size, tuple_element): Remove partial specializations.
* include/bits/stl_tree.h (_Rb_tree::insert_return_type): Use
const_iterator for std::set.
* testsuite/23_containers/map/modifiers/extract.cc: New.
* testsuite/23_containers/set/modifiers/extract.cc: New.
* testsuite/23_containers/unordered_map/modifiers/extract.cc: New.
* testsuite/23_containers/unordered_set/modifiers/extract.cc: New.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/node_handle.h
trunk/libstdc++-v3/include/bits/stl_tree.h
trunk/libstdc++-v3/testsuite/23_containers/map/modifiers/extract.cc
trunk/libstdc++-v3/testsuite/23_containers/set/modifiers/extract.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/modifiers/extract.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/modifiers/extract.cc

[Bug c/80756] missing diagnostic on non-constant expression with function call such as fabs or fma in initializer

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
On Mon, 15 May 2017, nsz at gcc dot gnu.org wrote:

> fabs and fma identifiers are reserved for the implementation and it is valid 
> to
> treat them as constant expression in initializers based on c99 6.6p10

The calls violate the requirement for constant expressions not to contain 
function calls, hence the pedwarns-if-pedantic being necessary for this 
code.

[Bug ipa/80735] IPA: SRA inhibits constant propagation of structs across multiple function calls

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-15
 CC||jamborm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Jambor  ---
Confirmed and probably not easily fixable in the current IPA-SRA
framework.  IPA SRA changes the IRA in a way that would require jump
functions from aggregate to scalar arguments to work, and we don't
have those.

I would hate to raise overly optimistic expectation but I am working
on a rewrite of IPA-SRA that will make it a real IPA stage and that
should allow it and IPA-CP not to step on each other's toes, with a
little bit of effort.

Thanks for proving the example, it will be useful.

[Bug c/80756] missing diagnostic on non-constant expression with function call such as fabs or fma in initializer

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
On Mon, 15 May 2017, vincent-gcc at vinc17 dot net wrote:

> GCC misses a diagnostic when the fabs() or fma() function is used in an
> initializer. For instance, consider:

There are pedwarns-if-pedantic for these cases.

> Note that  is not included, so that fabs() and fma() must not be
> regarded as special. But even when these functions are regarded as ISO C's
> specified ones, the diagnostic should probably still be present (it seems that
> the C standard does not make an exception for such functions, unfortunately).

The reservations with external linkage in C99/C11 7.1.3#1 are not 
conditional on whether the corresponding header is included.  (Only C90 
Amendment 1 had such reservations conditional on inclusion of the 
corresponding header, for the new functions it added, and that condition 
would only be relevant with -std=iso9899:199409.)

[Bug ipa/79849] diagnostics: typo in "type %qT itself violate the C++ One Definition Rule"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-15
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I'll prepare a patch for that.

[Bug ipa/79850] diagnostics: typo in "fields has different layout"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-15
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I'll prepare a patch for that.

[Bug c/80756] missing diagnostic on non-constant expression with function call such as fabs or fma in initializer

[vincent-gcc at vinc17 dot net]

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

--- Comment #4 from Vincent Lefèvre  ---
(In reply to nsz from comment #3)
> fabs and fma identifiers are reserved for the implementation and it is valid
> to treat them as constant expression in initializers based on c99 6.6p10

Well, if  is included, perhaps, but this would need to be documented as
an implementation-defined behavior. The GCC manual Section 4 "C
Implementation-Defined Behavior" doesn't seem to document such constant
expressions and when they are available.

If  is not included, there should be at least a warning because fabs()
or fma() is used without including the header first, thus potentially yielding
unexpected results and obscure bugs.

[Bug driver/31468] Calling gcc with empty output filename can remove crt0.o (crt1.o on linux)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||5.4.0, 6.3.0, 7.1.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk so far.

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Sat, 13 May 2017, msebor at gcc dot gnu.org wrote:

> I don't see what purpose rejecting
> 
>   bool b = "";
> 
> serves when
> 
>   bool b = !!"";
> 
> or even
> 
>   bool b = "" ? 1 : 0;
> 
> are accepted.

My comment is specifically about what's valid in the standard.  I don't 
think any of those should be considered valid standard C.  What's accepted 
beyond that, based on folding to a constant, is a separate matter (various 
things that aren't constant expressions are accepted in various contexts 
with pedwarns-if-pedantic because of existing code that makes use of 
them).

[Bug c/80756] missing diagnostic on non-constant expression with function call such as fabs or fma in initializer

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #3 from nsz at gcc dot gnu.org ---
fabs and fma identifiers are reserved for the implementation and it is valid to
treat them as constant expression in initializers based on c99 6.6p10

i think the gcc behaviour is reasonable.

[Bug libstdc++/80761] std::set<T,C,A>::insert_return_type uses wrong iterator type

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(and the order of the structure members is also wrong)

[Bug ipa/80728] IPA-reference suppresses compiler memory barrier

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Mon, 15 May 2017, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
> 
> --- Comment #4 from Alexander Monakov  ---
> ipa-reference.c has:
> 
> /* Set of all interesting module statics.  A bit is set for every module
>static we are considering.  This is added to the local info when asm
>code is found that clobbers all memory.  */
> static bitmap all_module_statics;
> 
> 
> but I don't see where the code implementing the last statement in the comment
> is.
> I only see how indirect calls are handled (and I think barriers due to atomics
> and asms can be handled in a similar fashion).

Yeah, the comment refers to the old implementation (which likely was 
fine).  The new implementation simply uses the ipa_ref lists instead
of walking stmts.

[Bug libstdc++/80761] std::set<T,C,A>::insert_return_type uses wrong iterator type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-15
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug translation/80760] Suggested clarification of an error message

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-15
  Component|tree-optimization   |translation
 Ever confirmed|0   |1

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

[Bug ipa/80728] IPA-reference suppresses compiler memory barrier

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
ipa-reference.c has:

/* Set of all interesting module statics.  A bit is set for every module
   static we are considering.  This is added to the local info when asm
   code is found that clobbers all memory.  */
static bitmap all_module_statics;


but I don't see where the code implementing the last statement in the comment
is.
I only see how indirect calls are handled (and I think barriers due to atomics
and asms can be handled in a similar fashion).

[Bug libstdc++/80761] New: std::set<T,C,A>::insert_return_type uses wrong iterator type

[redi at gcc dot gnu.org]

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

Bug ID: 80761
   Summary: std::set::insert_return_type uses wrong
iterator type
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

int main()
{
  auto [ins, pos, node] = std::set::insert_return_type{};
  static_assert( std::is_same_v );
  static_assert( std::is_same_v );
  static_assert( std::is_same_v );
}


ins.cc: In function ‘int main()’:
ins.cc:7:3: error: static assertion failed
   static_assert( std::is_same_v );
   ^

[Bug driver/31468] Calling gcc with empty output filename can remove crt0.o (crt1.o on linux)

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Mon May 15 12:48:35 2017
New Revision: 248060

URL: https://gcc.gnu.org/viewcvs?rev=248060=gcc=rev
Log:
Do not allow empty argument of -o option (PR driver/31468).

2017-05-15  Martin Liska  

PR driver/31468
* gcc.c (process_command): Do not allow empty argument of -o option.

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

[Bug fortran/80757] Internal compiler error when omitting upper subscript of a character substring in a module subroutine

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-15
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, all releases I have (4.5.0+) do ICE.

[Bug fortran/80752] [5/6/7/8 Regression] ICE with wrong type initialization

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-15
 CC||burnus at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|ICE with wrong type |[5/6/7/8 Regression] ICE
   |initialization  |with wrong type
   ||initialization
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r218068.

[Bug rtl-optimization/80747] [6/7/8 Regression] gcc.dg/tree-ssa/tailrecursion-4.c fails with ICE when compiled with options "-fprofile-use -freorder-blocks-and-partition"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-15
 CC||marxin at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
Summary|gcc.dg/tree-ssa/tailrecursi |[6/7/8 Regression]
   |on-4.c fails with ICE when  |gcc.dg/tree-ssa/tailrecursi
   |compiled with options   |on-4.c fails with ICE when
   |"-fprofile-use  |compiled with options
   |-freorder-blocks-and-partit |"-fprofile-use
   |ion"|-freorder-blocks-and-partit
   ||ion"
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with r228318 and can be reproduced on x86_64-linux-gnu.

[Bug c++/67147] [concepts] ICE on checking concept with default template arguments

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
(In reply to Tom Honermann from comment #2)
> The following bug looks likely to be related:
> - Bug 80746 - [concepts] ICE evaluating constraints for concepts with
> dependent template parameters

Started with the same revision.

[Bug tree-optimization/80760] New: Suggested clarification of an error message

[goeran at uddeborg dot se]

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

Bug ID: 80760
   Summary: Suggested clarification of an error message
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goeran at uddeborg dot se
  Target Milestone: ---

The message

  "% parameter is not a power of two %d"

(from
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/tree-ssa-loop-prefetch.c?view=markup#l2038)
caused a bit of confusion during our translation into Swedish.  We now realise
the %d will become the size which is not a power of two.  But we still feel the
message is a bit strange, with the word "two" directly followed by a number. 
Could I suggest a clarification.  Perhaps

  "% parameter is %d which is not a power of two"

or at least a colon to separate the size from the message proper

  "% parameter is not a power of two: %d"

[Bug c++/80746] [concepts] ICE evaluating constraints for concepts with dependent template parameters

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-15
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with r226713.

[Bug middle-end/80743] [8 Regression] ICE in estimate_node_size_and_time, at ipa-inline-analysis.c:3385

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-15
 CC||marxin at gcc dot gnu.org
Summary|ice in  |[8 Regression] ICE in
   |estimate_node_size_and_time |estimate_node_size_and_time
   |, at|, at
   |ipa-inline-analysis.c:3385  |ipa-inline-analysis.c:3385
 Ever confirmed|0   |1

--- Comment #7 from Martin Liška  ---
Confirmed, caused by the revision mentioned in the last comment.

[Bug target/80742] attribute target no- does not work

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-05-15
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Even setting -mno-sse2 does not cause error. However this works as expected:

$ cat ~/Programming/testcases/pr80742.c && ./xgcc -B.
~/Programming/testcases/pr80742.c

typedef float __m128 __attribute__ ((vector_size (16)));

__attribute__((target("no-sse"))) __m128 func (__m128 x, __m128 y)
{
__m128 xmm0 = x, xmm1 = y, xmm2;
xmm0 = __builtin_ia32_xorps (xmm1, xmm1);
return xmm0;
}
/home/marxin/Programming/testcases/pr80742.c: In function ‘func’:
/home/marxin/Programming/testcases/pr80742.c:5:1: error: SSE register return
with SSE disabled
 {
 ^

Negative meaning of option is definitely supported. That said, may I close the
PR?

[Bug sanitizer/80659] [7/8 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
Ok, Richi's reply to the patch:

```
I think the C FE and/or ASAN should be fixed instead.  Seems to work
fine with C++.
```

In C it looks as follows:

{
  switch (a)
{
  {
int c;

case 2:;
(int *) &<<< Unknown tree: compound_literal_expr
int D.2118[0] = {}; >>>;
int c;
  }
}
}

while in C++:

{
  {
switch (a)
  {
{
  int c;

  case 2:;
  < >;
int c;
}
  }
  }
}

Marek, can you please take a look why the VAR_DECL built from the expr_stmt is
not assigned in a BIND_EXPR?

[Bug target/80732] target_clones does not work with dlsym

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug target/80732] target_clones does not work with dlsym

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2017-5-15
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
  Known to fail||6.3.0, 7.1.0

--- Comment #1 from Martin Liška  ---
Confirmed, I'll take a look.

[Bug tree-optimization/80758] isnan/isfinite/isinf value propagation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-15
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Long on (my) TODO list.  Simplest version would propagate
fpclassify () bits plus signbit ().  Special values might be interesting as
well ("not zero",
one, minus one, integer).

General value-range propagation might be doable but is more work.

SSA info needs to be enhanced to record FP stuff.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug testsuite/80759] New: gcc.target/x86_64/abi/ms-sysv FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 80759
   Summary: gcc.target/x86_64/abi/ms-sysv FAILs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: daniel.santos at pobox dot com
  Target Milestone: ---
Target: i?86-*-*

The new gcc.target/x86_64/abi/ms-sysv tests FAIL in various e.g. on
i386-pc-solaris2.*
and i686-pc-linux-gnu:

* In those 32-bit-default configurations, the 32-bit multilib is skipped as
  unsupported as expected (although the UNSUPPORTED entry in gcc.sum occurs
  e.g. 45 times for -j48 testing instead of only once), but for the 64-bit
  multilib, I get

WARNING: Could not build
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c.
WARNING: Could not build
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c.
WARNING: Could not build
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c.
WARNING: Could not build
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c.
FAIL: gcc.target/x86_64/abi/ms-sysv CFLAGS="-O0 -g3" generator_args="-p0-5
--omit-rbp-clobbers"
FAIL: gcc.target/x86_64/abi/ms-sysv CFLAGS="-O2" generator_args="-p0-5"
FAIL: gcc.target/x86_64/abi/ms-sysv CFLAGS="-mcall-ms2sysv-xlogues -O0 -g3"
generator_args="-p0-5 --omit-rbp-clobbers"
FAIL: gcc.target/x86_64/abi/ms-sysv CFLAGS="-mcall-ms2sysv-xlogues -O2"
generator_args="-p0-5"

  Looking at gcc.log, I find that both the generator (which seems ok) *and*
  the testcases are compiled without the 64-bit multlib flag (-m64), leading
  to a failing 32-bit compilation of the testcase:

spawn /var/gcc/regression/trunk/12-gcc/build/gcc/xgcc
-B/var/gcc/regression/trunk/12-gcc/build/gcc/
-I/var/gcc/regression/trunk/12-gcc/build/gcc/testsuite/gcc4/ms-sysv
-I/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv -O0
-g3 -Wall -c -o
/var/gcc/regression/trunk/12-gcc/build/gcc/testsuite/gcc4/ms-sysv/ms-sysv.o
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c^M
^[[01m^[[K/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:62:3:^[[m^[[K
^[[01;31m^[[Kerror: ^[[m^[[K#error Test only valid on x86_64^M
 # ^[[01;31m^[[Kerror^[[m^[[K Test only valid on x86_64^M
   ^[[01;31m^[[K^^[[m^[[K^M
^[[01m^[[K/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:102:5:^[[m^[[K
^[[01;31m^[[Kerror: ^[[m^[[Kunknown type name '^[[01m^[[K__uint128_t^[[m^[[K'^M
 ^[[01;31m^[[K__uint128_t^[[m^[[K sseregs[10];^M
 ^[[01;31m^[[K^~~^[[m^[[K^M
^[[01m^[[K/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:234:34:^[[m^[[K
^[[01;31m^[[Kerror: ^[[m^[[Kunknown type name '^[[01m^[[K__uint128_t^[[m^[[K'^M
 static int compare_reg128 (const ^[[01;31m^[[K__uint128_t^[[m^[[K *a, const
__uint128_t *b,^M
  ^[[01;31m^[[K^~~^[[m^[[K^M
^[[01m^[[K/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:234:56:^[[m^[[K
^[[01;31m^[[Kerror: ^[[m^[[Kunknown type name '^[[01m^[[K__uint128_t^[[m^[[K'^M
 static int compare_reg128 (const __uint128_t *a, const
^[[01;31m^[[K__uint128_t^[[m^[[K *b,^M
   
^[[01;31m^[[K^~~^[[m^[[K^M
WARNING: Could not build
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c.

  Apart from lacking the -m64 flag here, the compiler invocations have lost
  -fno-diagnostics-show-caret -fdiagnostics-color=never, leading to unreadable
  log output.

* do-test.S only works with gas: if I try to compile it manually with Solaris
  /bin/as -m64, I get

Assembler: 
"/var/tmp//cce6X86d.s", line 339 : Illegal mnemonic
Near line: " .struct 0"
"/var/tmp//cce6X86d.s", line 339 : Syntax error
Near line: " .struct 0"
"/var/tmp//cce6X86d.s", line 341 : Illegal mnemonic
Near line: " .struct test_data_save + 224"
"/var/tmp//cce6X86d.s", line 341 : Syntax error
Near line: " .struct test_data_save + 224"
"/var/tmp//cce6X86d.s", line 343 : Illegal mnemonic
Near line: " .struct test_data_save + 448"
"/var/tmp//cce6X86d.s", line 343 : Syntax error
Near line: " .struct test_data_save + 448"
"/var/tmp//cce6X86d.s", line 345 : Illegal mnemonic
Near line: " .struct test_data_save + 672"
"/var/tmp//cce6X86d.s", line 345 : Syntax error
Near line: " .struct test_data_save + 672"
"/var/tmp//cce6X86d.s", line 347 : Illegal mnemonic
Near line: " .struct test_data_save + 680"
"/var/tmp//cce6X86d.s", line 347 : Syntax error
Near line: " .struct test_data_save + 680"

[Bug tree-optimization/80758] New: isnan/isfinite/isinf value propagation

[drepper.fsp+rhbz at gmail dot com]

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

Bug ID: 80758
   Summary: isnan/isfinite/isinf value propagation
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drepper.fsp+rhbz at gmail dot com
  Target Milestone: ---

Consider the following code:

#define isnan(x) __builtin_isnan(x)
#define isfinite(x) __builtin_isfinite(x)

int f(double a, double b)
{
  if (!isfinite(a) || !isfinite(b))
return 0;
  double c = a + b;
  return isnan(c) ? 0 : 1;
}

For x86-64 with the current trunk version (and probably all previous versions)
the generated code looks something like this:

.cfi_startproc
vmovq   .LC0(%rip), %xmm2
vmovapd %xmm0, %xmm4
vmovsd  .LC1(%rip), %xmm3
xorl%eax, %eax
vandpd  %xmm2, %xmm4, %xmm4
vucomisd%xmm4, %xmm3
jb  .L5
vandpd  %xmm1, %xmm2, %xmm2
vucomisd%xmm2, %xmm3
jb  .L5
vaddsd  %xmm1, %xmm0, %xmm0
xorl%eax, %eax
vucomisd%xmm0, %xmm0
setnp   %al
.L5:
ret
.cfi_endproc

The issue here is that the sum of two finite values will never be NaN.  It can
be ±Inf but not NaN.  The VRP information should contain necessary information
and use it in the __builtin_isnan code generation.

[Bug c/80756] missing diagnostic on non-constant expression with function call such as fabs or fma in initializer

[vincent-gcc at vinc17 dot net]

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

--- Comment #2 from Vincent Lefèvre  ---
(In reply to Vincent Lefèvre from comment #1)
> The cause seems to be that the functions are builtins:
> 
> $ gcc-snapshot -std=c99 -c tst-cst.c
[...]

Oops, incomplete copy-paste. It should have been:

$ gcc-snapshot -std=c99 -c tst-cst.c -fno-builtin
tst-cst.c: In function 'f':
tst-cst.c:7:21: error: initializer element is not constant
   static double x = fabs (3.0);
 ^~~~
tst-cst.c:8:21: error: initializer element is not constant
   static double y = fma (2.0, 3.0, 4.0);
 ^~~
tst-cst.c:9:21: error: initializer element is not constant
   static double z = foo (2.0, 3.0, 4.0);
 ^~~

Without the -fno-builtin, the diagnostic for fabs() and fma() are missing.

[Bug middle-end/80743] ice in estimate_node_size_and_time, at ipa-inline-analysis.c:3385

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #6 from David Binderman  ---
Revision 247417 by hubicka looks to be the problem.

Perhaps hubicka can offer us some advice ?

[Bug c/80756] missing diagnostic on non-constant expression with function call such as fabs or fma in initializer

[vincent-gcc at vinc17 dot net]

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

--- Comment #1 from Vincent Lefèvre  ---
The cause seems to be that the functions are builtins:

$ gcc-snapshot -std=c99 -c tst-cst.c
tst-cst.c: In function 'f':
tst-cst.c:7:21: error: initializer element is not constant
   static double x = fabs (3.0);
 ^~~~
tst-cst.c:8:21: error: initializer element is not constant
   static double y = fma (2.0, 3.0, 4.0);
 ^~~
tst-cst.c:9:21: error: initializer element is not constant
   static double z = foo (2.0, 3.0, 4.0);
 ^~~

But I think that this is wrong. The use of -std=c99 shouldn't allow builtin
functions when they would give a different result (and even without -std=c99,
as this would be confusing). On this point, Clang has the same issue.