[Bug rtl-optimization/81595] New: [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)

[asolokha at gmx dot com]

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

Bug ID: 81595
   Summary: [8 Regression] ICE: verify_flow_info failed (error:
multiple hot/cold transitions found)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-8.0.0-alpha20170723 snapshot ICEs when compiling the following snippet w/
-O2 (-O3, -Ofast):

void
lo (int *bo, int *og, int *cv, int nk, int ac)
{
  while (nk != 0)
{
  if (*bo != 0)
{
  int he = 1;

 a6:
  if (*og != 0)
{
  while (he < 2)
{
  he = 0;
  bo = (int *)
 qa:
  ++he;
}
  while (*cv != 0)
{
}
}
  he /= 0;
}
  else
{
  *cv /= (*cv != 0) ? 2 : 0;
  while (ac < 1)
{
  *og = 0;
  if (ac != 0)
goto a6;
  ++ac;
}
  goto qa;
}
  }
}

% x86_64-pc-linux-gnu-gcc-8.0.0-alpha20170723 -O2 -w -c cdcoibzd.c
cdcoibzd.c: In function 'lo':
cdcoibzd.c:39:1: error: multiple hot/cold transitions found (bb 11)
 }
 ^
cdcoibzd.c:39:1: error: multiple hot/cold transitions found (bb 12)
during RTL pass: bbro
cdcoibzd.c:39:1: internal compiler error: verify_flow_info failed

This PR can be a duplicate of PR81301 and/or PR81559.

[Bug c++/81587] GCC doesn't warn about calling functions that don't exist

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
GCC does warn for unused types and variables in local scope so it makes sense
that it also warn for unused functions declared in local scope.  You might want
to open a new bug report and request a warning for locally declared but unused
functions.

$ cat t.C && gcc -S -Wall t.C
void f (void)
{
  typedef int I;
  int i;
  void g ();
}
t.C: In function ‘void f()’:
t.C:4:7: warning: unused variable ‘i’ [-Wunused-variable]
   int i;
   ^
t.C:3:15: warning: typedef ‘I’ locally defined but not used
[-Wunused-local-typedefs]
   typedef int I;
   ^

[Bug target/79252] Improve code generation of vec_insert on PowerPC ISA 2.07 (i.e. power8)

[zoltan at hidvegi dot com]

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

--- Comment #2 from Zoltan Hidvegi  ---
Created attachment 41855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41855=edit
Possible vec_insert implementation

The attached code shows two implementation for inserting a byte to a variable
position, and one for inserting a halfword. The byte insert functions can also
be modified for halfword and word. It is for little-endian, could be modified
for big-endian. Usually I try to pack multiple values into a register and use a
single mtvsrd instead of multiple mtvsrd instructions.

Note that vec_unpackl actually generates vupkh... I never understood the logic
for this, but that's how it is. Also the Power Architecture 64-bit ELFv2 API
Spec document says that "vec_insert (v, 3, x) is equivalent to v[3] = x" which
is probably not correct, the arguments are not in the right order, and v is not
modified, instead the results is returned.

I haven't tested this code much, not sure which is faster, these are just ideas
what could be done, which should be way better than the store versions that
cannot even use store forwarding because a byte store is not forwarded to a
vector load.

[Bug c++/81586] valgrind error in output_buffer_append_r with -Wall

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01866.html

[Bug target/81594] Optimize PowerPC vector set and store

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/81594] Optimize PowerPC vector set and store

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 41854
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41854=edit
Proposed patch to fix the problem

[Bug target/81594] Optimize PowerPC vector set and store

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-27
 CC||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/81593] Optimize PowerPC vector set from vector extract

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-27
 Ever confirmed|0   |1

[Bug target/81594] New: Optimize PowerPC vector set and store

[meissner at gcc dot gnu.org]

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

Bug ID: 81594
   Summary: Optimize PowerPC vector set and store
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41853
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41853=edit
Example code that code be optimized.

On PowerPC VSX systems, optimize cases where the user creates a V2DI or V2DF
vector and then immediately stores the values away and does not use the vector
created i registers, to just to the stores directly.

[Bug target/81593] Optimize PowerPC vector set from vector extract

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 41852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41852=edit
Proposed patch to fix the problem

Checked on power7 big endian and power8 little endian.

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[sje at gcc dot gnu.org]

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

--- Comment #18 from Steve Ellcey  ---
See https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01862.html for a proposed
patch to update the tests.

[Bug target/81593] New: Optimize PowerPC vector set from vector extract

[meissner at gcc dot gnu.org]

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

Bug ID: 81593
   Summary: Optimize PowerPC vector set from vector extract
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41851=edit
File to show the problem.

If we doing a vector set for 64-bit DF/DI mode values on PowerPC VSX system,
and one or both of the values used in the set came from a vector extract, we
can optimize things to do only one XXPERMDI instead of doing 3 XXPERMDI's (2 to
isolate each element, and a third to recombine them back together again).

[Bug c++/81587] GCC doesn't warn about calling functions that don't exist

[jg at jguk dot org]

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

--- Comment #3 from Jonny Grant  ---
Ok. Had expected unused declarations to be a warning

[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[icenowy at aosc dot io]

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

--- Comment #12 from Icenowy Zheng  ---
(In reply to Wilco from comment #11)
> (In reply to Icenowy Zheng from comment #10)
> > In my environment (glibc 2.25, and both the building scripts of glibc and
> > gcc have -fomit-frame-pointer automatically enabled), this bug is not fully
> > resolved yet.
> > 
> > With GCC upgraded to 6.4.0, GDB debugger started to work correctly. (With
> > GCC 6.3.0 GDB cannot even work and segfault at unwind code in libgcc).
> > 
> > However, if I still build GCC with -fomit-frame-pointer in CFLAGS, the
> > backtrace() function of glibc cannot work, and segfault at line 240 of
> > libgcc/unwind-dw2.c .
> > 
> > By reading the source code, I think the unwind code is still trying to get
> > CFA from the register x29, and when debugging I found that the x29 register
> > in the unwind context is 0 (because of -fomit-frame-pointer), so line 240 is
> > dereferencing a NULL pointer, so it segfaulted.
> > 
> > Maybe the behavior that accessing x29 register to get CFA is not correct?
> 
> Well if everything built with -fomit-frame-pointer then it is definitely
> wrong to read x29. Can you give more info similar to comment #3?

I didn't remember a lot as this issue is already fixed in our build system by
removing -fomit-frame-pointer.

But I remember part of the stacktrace:

_Unwind_GetGR(index=29) at libgcc/unwind-dw2.c:240 <= segfault here
_Unwind_GetPtr(index=29) at libgcc/unwind-dw2.c:251
uw_update_context_1() at libgcc/unwind-dw2.c:1410
_Unwind_Backtrace() at libgcc/unwind.inc (line number forgot)
backtrace() in libc.so.6

[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[wdijkstr at arm dot com]

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

--- Comment #11 from Wilco  ---
(In reply to Icenowy Zheng from comment #10)
> In my environment (glibc 2.25, and both the building scripts of glibc and
> gcc have -fomit-frame-pointer automatically enabled), this bug is not fully
> resolved yet.
> 
> With GCC upgraded to 6.4.0, GDB debugger started to work correctly. (With
> GCC 6.3.0 GDB cannot even work and segfault at unwind code in libgcc).
> 
> However, if I still build GCC with -fomit-frame-pointer in CFLAGS, the
> backtrace() function of glibc cannot work, and segfault at line 240 of
> libgcc/unwind-dw2.c .
> 
> By reading the source code, I think the unwind code is still trying to get
> CFA from the register x29, and when debugging I found that the x29 register
> in the unwind context is 0 (because of -fomit-frame-pointer), so line 240 is
> dereferencing a NULL pointer, so it segfaulted.
> 
> Maybe the behavior that accessing x29 register to get CFA is not correct?

Well if everything built with -fomit-frame-pointer then it is definitely wrong
to read x29. Can you give more info similar to comment #3?

[Bug tree-optimization/81588] [7/8 Regression] Wrong code at -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/81586] valgrind error in output_buffer_append_r with -Wall

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Let me fix it.

[Bug c++/81586] valgrind error in output_buffer_append_r with -Wall

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I don't see a problem with the code in maybe_warn.  It does this:

  /* Buffer for the directive in the host character set (used when
 the source character set is different).  */
  char hostdir[32];
  ...
  return fmtwarn (dirloc, pargrange, NULL,
  info.warnopt (), fmtstr, dir.len,
  target_to_host (hostdir, sizeof hostdir, dir.beg),
  res.min, navail);

The call being made has fmtstr = "%<%.*s%> directive output truncated writing
%wu bytes into a region of size %wu", dir.len = 73, and hostdir =
"af_get_next_segv end of file..." (with strlen (hostdir) == 31).  With that,
while the "%.*s" directive in fmtstr says to read at most 73 bytes from
hostdir, since hostdir is only 31 characters long, the directive should read
exactly that many and no more than that.

I think the bug is actually in pp_format where the "%.*s" directive is handled:

case '.':
  {
int n;
const char *s;

/* We handle '%.Ns' and '%.*s' or '%M$.*N$s'
   (where M == N + 1).  The format string should be verified
   already from the first phase.  */
p++;
if (ISDIGIT (*p))
  {
char *end;
n = strtoul (p, , 10);
p = end;
gcc_assert (*p == 's');
  }
else
  {
gcc_assert (*p == '*');
p++;
gcc_assert (*p == 's');
n = va_arg (*text->args_ptr, int);
^

Here n is extracted from the variable argument list (the corresponding argument
is dir.len).

/* This consumes a second entry in the formatters array.  */
gcc_assert (formatters[argno] == formatters[argno+1]);
argno++;
  }

s = va_arg (*text->args_ptr, const char *);
pp_append_text (pp, s, s + n);
^

Here s points to hostdir and n is 73, but strlen(s) is just 31.  This code
doesn't handle the precision correctly.  The precision is the maximum number of
non-nul characters to print.  The fix is to set n to be no greater than
strlen(s):

if (strlen (s) < n)
  n = strlen (s);
pp_append_text (pp, s, s + n);

[Bug tree-optimization/81592] spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-27
 CC||msebor at gcc dot gnu.org
  Component|rtl-optimization|tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed, even without the sanitizer.  This is another case where the range
information computed by the value range propagation pass is not exposed outside
of it.  The same problem causes a false positive with -Walloca-larger-than but
interestingly not with -Wstringop-overflow which sees the right range.

To avoid the false positive cast the argument to unsigned int and use %u to
format it.  For whatever reason, the cast exposes the correct range even after
VRP1.

The -Walloca and -Wformat-overflow passes run after VRP1 but before VRP2 so the
range must become available then.  I at one point looked into running the
-Wformat-overflow pass later but, IIRC, ran into some problems.  It might be
worth looking into again.  Then again, I'm thinking about running the pass as
part of strlen which also runs before VRP2, so relying on running it that late
would prevent it from using the strlen pass data.

$ cat x.c && gcc-7 -O2 -S -Wall -Walloca-larger-than=59 x.c
void f (void*);

void g (long expiry, long now)
{
  unsigned long timo;

  if (now < expiry) {
timo = expiry - now;
if (timo < 60)
  f (__builtin_alloca (timo));
  }
}

void h (long expiry, long now)
{
  unsigned long timo;

  if (now < expiry) {
timo = expiry - now;
if (timo < 60)
  f (__builtin_memset ( + 1, 0, timo));
  }
}

x.c: In function ‘g’:
x.c:10:7: warning: unbounded use of ‘alloca’ [-Walloca-larger-than=]
   f (__builtin_alloca (timo));
   ^~~
x.c: In function ‘h’:
x.c:21:7: warning: ‘__builtin_memset’: writing between 1 and 59 bytes into a
region of size 0 overflows the destination [-Wstringop-overflow=]
   f (__builtin_memset ( + 1, 0, timo));
   ^~~~


The top of trunk also prints the following for the alloca case (not sure what's
changed since 7.1):

x.c: In function ‘g’:
x.c:10:7: warning: argument to ‘alloca’ may be too large
[-Walloca-larger-than=]
   f (__builtin_alloca (timo));
   ^~~
x.c:10:7: note: limit is 59 bytes, but argument may be as large as
9223372036854775807

[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[icenowy at aosc dot io]

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

Icenowy Zheng  changed:

   What|Removed |Added

 CC||icenowy at aosc dot io

--- Comment #10 from Icenowy Zheng  ---
In my environment (glibc 2.25, and both the building scripts of glibc and gcc
have -fomit-frame-pointer automatically enabled), this bug is not fully
resolved yet.

With GCC upgraded to 6.4.0, GDB debugger started to work correctly. (With GCC
6.3.0 GDB cannot even work and segfault at unwind code in libgcc).

However, if I still build GCC with -fomit-frame-pointer in CFLAGS, the
backtrace() function of glibc cannot work, and segfault at line 240 of
libgcc/unwind-dw2.c .

By reading the source code, I think the unwind code is still trying to get CFA
from the register x29, and when debugging I found that the x29 register in the
unwind context is 0 (because of -fomit-frame-pointer), so line 240 is
dereferencing a NULL pointer, so it segfaulted.

Maybe the behavior that accessing x29 register to get CFA is not correct?

[Bug c++/81514] g++.dg/lookup/missing-std-include-2.C FAILs on Solaris

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01858.html

[Bug c++/81586] valgrind error in output_buffer_append_r with -Wall

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-27
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, following patch will be needed:

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 644cf7e33b1..72ec10a77b9 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -2500,7 +2500,7 @@ maybe_warn (substring_loc , source_range
*pargrange,
  : G_("%<%.*s%> directive writing %wu bytes "
   "into a region of size %wu")));
  return fmtwarn (dirloc, pargrange, NULL,
- info.warnopt (), fmtstr, dir.len,
+ info.warnopt (), fmtstr, MIN (dir.len, 31),
  target_to_host (hostdir, sizeof hostdir, dir.beg),
  res.min, navail);
}

I'm not sure about the constant (maybe 32) and there are multiple invocations
of the fmtwarn function. Leaving to Martin.

[Bug c++/81587] GCC doesn't warn about calling functions that don't exist

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Martin Liška from comment #1)
> These are declarations of nested functions, you're not using them. 

Actually they are not nested functions but rather considered part of the
namespace that the function is enclosed in.  That is they reference functions
that are part of that namespace.  Like:

Assuming C++:
int f(void){return 1;}

int g(void)
{
  int f(int);  // Here f refers to ::f(int)
  return f(1);  // Here f refers to ::f(int) rather than the above function
::f(void);
}

 CUT 
This is valid and well defined code if int f(int); is defined in a different
translation unit.

Now GCC should warn about this code but that is a different issue.

[Bug rtl-optimization/81592] New: spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow

[arnd at linaro dot org]

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

Bug ID: 81592
   Summary: spurious -Wformat-overflow warning with
-fsanitize=signed-integer-overflow
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

While testing the linux kernel with -fsanitize=signed-integer-overflow, I ran
into a bogus warning for sprintf format overflow for
security/keys/proc.c:proc_keys_show.

I have reduced the source file to this code snippet:

/* aarch64-linux-gcc-7.1.1 -O2 -c test.c -Wall -fno-strict-overflow 
-Wstrict-overflow=2 -fsanitize=signed-integer-overflow */
#include 

int proc_keys_show(long expiry, long now)
{
unsigned long timo;
char xbuf[4];

if (now < expiry) {
timo = expiry - now;
if (timo < 60)
sprintf(xbuf, "%lus", timo);
}

return 0;
}

When building with either -fwrapv or -fsanitize=signed-integer-overflow, I get
this warning:

test.c: In function '_proc_keys_show':
test.c:12:19: warning: '%lu' directive writing between 1 and 20 bytes into a
region of size 4 [-Wformat-overflow=]
sprintf(xbuf, "%lus", timo);
   ^~~
test.c:12:18: note: directive argument in the range [1, 18446744073709551615]
sprintf(xbuf, "%lus", timo);
  ^~
test.c:12:4: note: 'sprintf' output between 3 and 22 bytes into a destination
of size 4
sprintf(xbuf, "%lus", timo);
^~~


Building with just "-O2 -Wstrict-overflow=2" produces a different warning that
is also surprising:

test.c: In function '_proc_keys_show':
test.c:11:6: warning: assuming signed overflow does not occur when simplifying
conditional [-Wstrict-overflow]
   if (timo < 60)


As Jim Wilson mentioned on IRC, the first comparison here clearly determines
that no signed overflow can happen, and apparently that leads to the second
comparison being done using signed arithmetic, but then the compiler decides to
use a signed comparison and incorrectly assumes that it might have overflown.

This seems to be related to pr 79257 and pr 78969, but both of them are
sufficiently different that I decided to open a separate report here.

[Bug libgomp/81591] New: segmentation fault when using priorities of nested tasks

[sistek at seznam dot cz]

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

Bug ID: 81591
   Summary: segmentation fault when using priorities of nested
tasks
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sistek at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Hello,

we develop the PLASMA numerical library (https://bitbucket.org/icl/plasma)
using OpenMP tasks. We are suffering from a problem with tasks with priorities
in the recent GOMP library.

In particular, if we prescribe priorities on nested tasks, the code sometimes
produces a segfault in the priority_list_downgrade_task function.

I attach the output from gdb below. It seems that the 
priority_queue_lookup_priority
function returns NULL on line 941 of task.c
Then, in the following call to the
priority_list_downgrade_task
function on line 942, the empty pointer is accessed, resulting in the
exception.

Is it a bug in gomp or on our side?

Thank you very much for your help.

Best wishes,

Jakub Sistek


Thread 1 "test" received signal SIGSEGV, Segmentation fault.
0x7393b220 in priority_list_downgrade_task (list=0x0, list=0x0,
child_task=0x7fffa4000a70, type=PQ_CHILDREN) at
../../../gcc_svn/libgomp/task.c:876
876   if (list->tasks == node)
(gdb) where
#0  0x7393b220 in priority_list_downgrade_task (list=0x0, list=0x0,
child_task=0x7fffa4000a70, type=PQ_CHILDREN) at
../../../gcc_svn/libgomp/task.c:876
#1  priority_queue_downgrade_task (task=0x7fffa4000a70, head=0xecfb08,
type=PQ_CHILDREN) at ../../../gcc_svn/libgomp/task.c:942
#2  gomp_task_run_pre (team=, parent=0xecfb00,
child_task=0x7fffa4000a70) at ../../../gcc_svn/libgomp/task.c:972
#3  GOMP_taskwait () at ../../../gcc_svn/libgomp/task.c:1359
#4  0x77a51c99 in plasma_pdamax () from
/home/sistek/programming/plasma_jakub_sistek/lib/libplasma.so
#5  0x77a2d80c in plasma_omp_dsgesv () from
/home/sistek/programming/plasma_jakub_sistek/lib/libplasma.so
#6  0x77a2ede7 in plasma_dsgesv._omp_fn () from
/home/sistek/programming/plasma_jakub_sistek/lib/libplasma.so
#7  0x73937a6f in GOMP_parallel (fn=0x77a2e4cc
, data=0x7fffca10, num_threads=4, flags=0)
at ../../../gcc_svn/libgomp/parallel.c:168
#8  0x77a2ca8e in plasma_dsgesv () from
/home/sistek/programming/plasma_jakub_sistek/lib/libplasma.so
#9  0x005f96f9 in test_dsgesv ()
#10 0x0049ce3b in run_routine ()
#11 0x0049c89b in test_routine ()
#12 0x0049c446 in main ()
(gdb)

[Bug target/81590] AVX512 run-time test failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-27
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
The run-time CPUID checks in

FAIL: gcc.target/i386/avx512vl-vpermb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpermi2b-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpermt2b-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmaddhuq-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmaddluq-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmultishiftqb-2.c execution test

are incorrect. avx512vl-vpermb-2.c has

#define AVX512VL
#define AVX512F_LEN 256
#define AVX512F_LEN_HALF 128
#include "avx512vbmi-vpermb-2.c"

It runs on processors with AVX512VL.  But avx512vbmi-vpermb-2.c has

#define AVX512VBMI

#include "avx512f-helper.h"

which needs AVX512VBMI.

[Bug c++/81587] GCC doesn't warn about calling functions that don't exist

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Liška  ---
> 
> int main (void)
> {
> float random_name(double haystack, double needle);
> void* missingf(float test);
> 

Hello.

These are declarations of nested functions, you're not using them. Thus the
compiler does not complain. Closing as invalid.

[Bug target/81590] New: AVX512 run-time test failures

[hjl.tools at gmail dot com]

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

Bug ID: 81590
   Summary: AVX512 run-time test failures
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: pavel.v.chupin at gmail dot com
  Target Milestone: ---
Target: x86-64

On Skylake server running Fedora 25/x86-64, r250630 gave:

FAIL: gcc.target/i386/avx512vl-vpermb-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpermi2b-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpermt2b-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmaddhuq-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmaddluq-2.c execution test
FAIL: gcc.target/i386/avx512vl-vpmultishiftqb-2.c execution test
FAIL: libgomp.c/for-3.c execution test
FAIL: libgomp.c/for-5.c execution test
FAIL: libgomp.fortran/target7.f90   -O0  execution test
FAIL: libgomp.fortran/target7.f90   -O1  execution test
FAIL: libgomp.fortran/target7.f90   -O2  execution test
FAIL: libgomp.fortran/target7.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.fortran/target7.f90   -O3 -g  execution test
FAIL: libgomp.fortran/target7.f90   -Os  execution test
FAIL: libgomp.fortran/target8.f90   -O0  execution test
FAIL: libgomp.fortran/target8.f90   -O1  execution test
FAIL: libgomp.fortran/target8.f90   -O2  execution test
FAIL: libgomp.fortran/target8.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.fortran/target8.f90   -O3 -g  execution test
FAIL: libgomp.fortran/target8.f90   -Os  execution test

[hlu@gkliclel217 testsuite]$ gdb ./avx512vl-vpermb-2.exeGNU gdb (GDB) Fedora
7.12.1-48.fc25
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./avx512vl-vpermb-2.exe...done.
(gdb) r
Starting program:
/export/users/hjl/build/gcc/build-x86_64-linux/gcc/testsuite/avx512vl-vpermb-2.exe
 
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.24-9.fc25.x86_64

Program received signal SIGILL, Illegal instruction.
test_256 ()
at
/export/users/hjl/git/gcc/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermb-2.c:38
38res1.x = INTRINSIC (_permutexvar_epi8) (s1.x, s2.x);
(gdb) bt
#0  test_256 ()
at
/export/users/hjl/git/gcc/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermb-2.c:38
#1  0x0040090b in avx512vl_test ()
at
/export/users/hjl/git/gcc/gcc/testsuite/gcc.target/i386/avx512f-helper.h:154
#2  do_test ()
at
/export/users/hjl/git/gcc/gcc/testsuite/gcc.target/i386/avx512vl-check.h:10
#3  0x0040044a in main ()
at
/export/users/hjl/git/gcc/gcc/testsuite/gcc.target/i386/avx512vl-check.h:31
(gdb)

[Bug fortran/53971] [OOP] Class container - reverse order of _vtab and _data

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #2)
> Any progress?

Guess not; closing for being stuck in WAITING for so long

[Bug c/49053] Please add an option to catch empty statements (-Wempty-statement ?)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #1)
> Sorry, I don't understand what bug this is catching. ";;" is inoffensive. My
> fear is that this will trigger a lot for non-buggy code precisely because of
> conditional macro expansion.

Yeah I do this sometimes on purpose, closing as WONTFIX

[Bug debug/81570] create_pseudo_cfg assumes that INCOMING_FRAME_SP_OFFSET is a constant

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01851.html

[Bug middle-end/39284] Computed gotos combined too aggressively

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #16 from Eric Gallager  ---
(In reply to Kai Tietz from comment #14)
> I think we can close that bug for now.
> Patch won't be backported.

OK, closed

[Bug tree-optimization/81588] [7/8 Regression] Wrong code at -O2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-27
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |7.2
Summary|Wrong code at -O2   |[7/8 Regression] Wrong code
   ||at -O2
 Ever confirmed|0   |1

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

[Bug c++/50645] old issue - deprecated conversion from string to char*

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #6 from Eric Gallager  ---
(In reply to mike.c from comment #1)
> The quick fix:
> 
> #pragma GCC diagnostic ignored "-Wwrite-strings"
> 
> ... of course eliminates the warnings -- but logically, you DO WANT A
> WARNING when you should be declaring
> 
> const char* (and you forget const)
> 
> but LOGICALLY you don't want I warning when passing a string literal to a
> char* parameter in a function.

Related: bug 61579

(In reply to Jonathan Wakely from comment #5)
> two points:
> 
> 1) the component for this bug should surely be c++, since the "deprecated
> conversion" warning is only issued by the C++ front end, the C front end says
> 
> passing argument 1 of ‘myfunction’ discards ‘const’ qualifier from pointer
> target type
> 
> and even then, only with -Wwrite-strings, which is not enabled by -Wall
> -Wextra
> 
> 2) unlike the PR's summary, the warning says "deprecated conversion from
> string CONSTANT to 'char*'" (emphasis mine) which should be a pretty big
> clue that it's warning you about a real problem.
> 
> I can't see any good reason this PR isn't INVALID, but will go for WAITING
> in case you have a better case to make for changing the current behaviour,
> which is entirely consistent with the C++ standard.

Closing as INVALID then since reporter never came back and made a better case

[Bug c/45784] gcc OpenMP - error: invalid controlling predicate

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul 27 19:13:42 2017
New Revision: 250635

URL: https://gcc.gnu.org/viewcvs?rev=250635=gcc=rev
Log:
PR c/45784
* c-omp.c (c_finish_omp_for): If the condition is wrapped in
rhs of COMPOUND_EXPR(s), skip them and readd their lhs into
new COMPOUND_EXPRs around the rhs of the comparison.

* testsuite/libgomp.c/pr45784.c: New test.
* testsuite/libgomp.c++/pr45784.C: New test.

Added:
trunk/libgomp/testsuite/libgomp.c++/pr45784.C
trunk/libgomp/testsuite/libgomp.c/pr45784.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-omp.c
trunk/libgomp/ChangeLog

[Bug rtl-optimization/25221] reload bailing out even when some regs are still available

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #6 from Eric Gallager  ---
(In reply to Steven Bosscher from comment #5)
> Deserves a new look with IRA and LRA... Still a problem here?

Reporter never replied; closing for being stuck in WAITING so long

[Bug lto/50432] lto1.exe: internal compiler error: in cgraph_mark_functions_to_output, at cgraphunit.c:1173 when build Qt4.7.4 rcc

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Eric Gallager  ---
(In reply to Kai Tietz from comment #3)
> So bug can be closed AFAIU?

Guess so.

[Bug libstdc++/79162] [7/8 Regression] [C++17] ambiguity in string assignment due to string_view overload

[daniel.kruegler at googlemail dot com]

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

--- Comment #16 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #15)
> Thanks, Daniel. Let's reopen this to make the T -> const T& changes.

I'm now working at that problem, thereby also attempting to implement the full
P/R of LWG 2946.

[Bug c/81577] -ftrack-macro-expansion=0 causes spurious “this ‘else’ clause does not guard” with -Wall

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-27
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed with trunk

[Bug c++/52900] Compile source using Boost header with -static -flto -std=c++11 breaks

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #9 from Eric Gallager  ---
(In reply to Paolo Carlini from comment #8)
> Note, per the bug submitting instructions, no URLs, please. If you are still
> having problems in this area please add here a minimized (there are many
> tools available for that, see our wiki) self-contained testcase.

Reporter never minimized it and the URL 404s. Closing.

[Bug c++/81589] Possible False-Positive with decltype

[hunter at openrobotics dot org]

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

--- Comment #1 from Hunter L. Allen  ---
Created attachment 41850
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41850=edit
preprocesed file (compressed)

[Bug c++/81589] New: Possible False-Positive with decltype

[hunter at openrobotics dot org]

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

Bug ID: 81589
   Summary: Possible False-Positive with decltype
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hunter at openrobotics dot org
  Target Milestone: ---

I can confirm that this effects GCC-8.0 svn as well (have not tested with
GCC-6).

There's a header file which compiles just fine with GCC-5.4.0 (and GCC-4.9.4),
but fails to compile with GCC-7.1.1 and GCC-8.0.

Please note that I'm only reporting this because of the inconsistency.

error: decltype cannot resolve address of overloaded function

The problematic line is reported as this one:

using arguments = typename tuple_tail<
  typename function_traits::arguments>::type;

In this context:

#include 
#include 
#include 

namespace rclcpp
{

namespace runction_traits
{

template
struct tuple_tail;

template
struct tuple_tail>
{
  using type = std::tuple;
};

// std::function
template
struct function_traits
{
  using arguments = typename tuple_tail<
  typename function_traits::arguments>::type;

  static constexpr std::size_t arity = std::tuple_size::value;

  template
  using argument_type = typename std::tuple_element::type;

  using return_type = typename function_traits::return_type;
};

/* other structs follow */
}

}

I'll attach the precompiler output from my computer with GCC 8 on it.

I'll also note that our library, rclcpp, does compile with GCC 8, but, when we
try to compile our tests or use the library elsewhere, the compiler throws
errors.

I'm super hesitant in reporting this, but I just can't see anything wrong in
the code, and the inconsistency is certainly an issue. It should error in GCC
5.4 if it's "bad" code (also note that the code is being compiled with the same
standard, C++-14).

[Bug fortran/24546] [meta-bug] gfortran debugging problems

[egallager at gcc dot gnu.org]

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

Bug 40040 Summary: gfortran invalid DW_AT_location for overridable variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040

   What|Removed |Added

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

[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #16 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #15)
> Is this fixed by revision 158612? If yes, please close this PR as FIXED.

No reply, guessing it was.

[Bug other/81582] -Wimplicit-fallthrough= wrong warning with -save-temps

[gjl at gcc dot gnu.org]

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

--- Comment #9 from Georg-Johann Lay  ---
With -fdirectives-only locations go bananas:

#include 

int f1 (int x)
{
switch (x)
{
case 1: x++; // FALLTHRU
case 2: x--; /* FALLTHRU */
case 3: x++; // line #9
case 4: return x;
default:
break;
}
return 0;
} // line #15

$ gcc foo.c -W -save-temps -S -fdirectives-only
foo.c: In function 'f1':
foo.c:16:14: warning: this statement may fall through [-Wimplicit-fallthrough=]

  ^ 
foo.c:18:5: note: here

 ^   

The case 1/2 warnings are silenced, but the (correct) warning for case 3 is
thrown at lines 16 and 18 for a file with only 15 source lines.

[Bug fortran/41827] [Cleanup] Remove SET_EXPR_LOCATION in gfc_trans_code

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||openmp
 Status|WAITING |SUSPENDED
 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #4)
> Moving to waiting.

SUSPENDED would probably be better

[Bug tree-optimization/81588] New: Wrong code at -O2

[babokin at gmail dot com]

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

Bug ID: 81588
   Summary: Wrong code at -O2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250630, x86_64.

> cat f.cpp
#include 
long int var_34 = 5011877430933453486L;
unsigned short var_82 = 24847;
long int var_58 = 1;
void foo() {
  if (var_82 > var_34 ^ true + (var_34 < 0))
var_58 = 0;
}
int main() {
  foo();
  printf("%ld\n", var_58);
  return 0;
}

> g++ -O0 f.cpp -o out; ./out
0

> g++ -O2 f.cpp -o out; ./out
1

[Bug c++/81514] g++.dg/lookup/missing-std-include-2.C FAILs on Solaris

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
I'm able to reproduce this on Linux by replacing:

  #include 

with:

  namespace std
  {
extern int sprintf (char *dst, const char *format, ...);
  };

On Linux, the include of stdio.h seems to have been effectively doing this
(amongst many other things):

  extern int sprintf (char *dst, const char *format, ...);
  namespace std
  {
using ::sprintf;
  };

and this gets rejected in consider_binding_level by this clause:

  /* Skip anticipated decls of builtin functions.  */
  if (TREE_CODE (d) == FUNCTION_DECL
  && DECL_BUILT_IN (d)
  && DECL_ANTICIPATED (d))
{

Presumably Solaris' headers doing something like the other thing above.

Am working on a fix.

[Bug c++/81587] New: GCC doesn't warn about calling functions that don't exist

[jg at jguk dot org]

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

Bug ID: 81587
   Summary: GCC doesn't warn about calling functions that don't
exist
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

The following seems strange, I don't see any warnings.

I had expected:

main.cpp: In function ‘int main()’:
main.cpp:7:22: error: ‘random_name’ was not declared in this scope
float random_name(double haystack, double needle);  
  ^
main.cpp:8:22: error: ‘missingf’ was not declared in this scope
 void* missingf(float test);
  ^


I'm surprised that I don't need to actually have a return variable, or even
pass a parameter. It's the same compiled wtih G++ or GCC.

//g++ -O2 -Wall -Wextra -Wpedantic -o main main.cpp

#include 

int main (void)
{
float random_name(double haystack, double needle);
void* missingf(float test);

printf("hello\n");

return 0;
}

[Bug c++/81586] valgrind error in output_buffer_append_r with -Wall

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
The following much reduced C++ code seems to demonstrate the bug:

extern "C" int snprintf(char *, unsigned long, const char *...) ;
struct  S {
char * a;
};
void f( S * af)
{
snprintf(af->a, sizeof(af), "af_get_next_segv end of file reading
segmen
t tail AFF file is truncated 0");
}

[Bug c++/81514] g++.dg/lookup/missing-std-include-2.C FAILs on Solaris

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-27
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c/45784] gcc OpenMP - error: invalid controlling predicate

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c/64762] [OpenACC] Bogus "expected '#pragma acc' clause before 'independent'"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
I can't reproduce this bug, it compiles successfully with neither warning nor
error with gcc8.
Closing.

[Bug c++/81586] New: valgrind error in output_buffer_append_r with -Wall

[dcb314 at hotmail dot com]

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

Bug ID: 81586
   Summary: valgrind error in output_buffer_append_r with -Wall
   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 41848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41848=edit
C++ source code

The attached C++ code, when compiled by recent gcc trunk and 
compiler flag -Wall, does this:

==19553== Conditional jump or move depends on uninitialised value(s)
==19553==at 0x1227643: output_buffer_append_r (pretty-print.h:128)
==19553==by 0x1227643: pp_append_r (pretty-print.c:258)
==19553==by 0x1227643: pp_append_text(pretty_printer*, char const*, char
con
st*) (pretty-print.c:892)
==19553==by 0x12285E9: pp_format(pretty_printer*, text_info*)
(pretty-print.
c:670)

The bug seems to have been created between revisions 243987 and 249539.

[Bug c/53075] -Werror=pedantic should be equivalent to -pedantic-errors

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug middle-end/68034] Print warning when memset is optimized out

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-27
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  This would be a useful feature to have.  The challenge with such a
warning is avoiding excessive false positives due to prior transformations.

[Bug objc/40864] Designated initializers for multi-dimensional arrays fail in Objective-C

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug objc/77481] @finally not executed if exception not caught or rethrown

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
I have to remove the '-static' for it to work, and when I do, it fails in cases
2, 3, and 4 for me on i386-apple-darwin9.8.0:

$ for n in $(seq 1 4); do echo executing case $n; gcc -DF=$n finally.m
-fobjc-exceptions -lobjc -static && ./a.out ; echo $?; echo ; done
executing case 1
/var/tmp//ccYBJZE4.s:74:FATAL:incompatible feature used: directive
.objc_cat_cls_meth (must specify "-dynamic" to be used)
1

executing case 2
/var/tmp//ccwUJaps.s:78:FATAL:incompatible feature used: directive
.objc_cat_cls_meth (must specify "-dynamic" to be used)
1

executing case 3
/var/tmp//ccFvcf5x.s:92:FATAL:incompatible feature used: directive
.objc_cat_cls_meth (must specify "-dynamic" to be used)
1

executing case 4
/var/tmp//ccA54Xxu.s:78:FATAL:incompatible feature used: directive
.objc_cat_cls_meth (must specify "-dynamic" to be used)
1

$ for n in $(seq 1 4); do echo executing case $n; gcc -DF=$n finally.m
-fobjc-exceptions -lobjc && ./a.out ; echo $?; echo ; done
executing case 1
trying
finalizing
done
0

executing case 2
trying
objc[40891]: objc_exception_throw failed
Illegal instruction
132

executing case 3
trying
objc[40900]: objc_exception_throw failed
Illegal instruction
132

executing case 4
trying
objc[40908]: objc_exception_throw failed
Illegal instruction
132

$

So confirming.

[Bug objc/77428] incorrect 'set but not used' warning with @throw

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug target/53716] Intentional or bug? Inconsistencies in error diagnostics in function redeclaration involving stdcall attribute

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Target||i386-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-27
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug objc/53943] Compiler ICE with -fobjc-direct-dispatch flag on Linux

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Konstantin Osipov from comment #2)
> kostja@atlas ~ % gcc -fobjc-direct-dispatch foo.m -lobjc

You still left off the -fobjc-exceptions flag

[Bug libobjc/67455] Inheriting from Object (with GNU runtime) doesn't provide alloc, init, or new, rendering methods useless

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-27
 CC||egallager at gcc dot gnu.org
  Component|objc|libobjc
Summary|Inheriting from Object  |Inheriting from Object
   |doesn't provide alloc, init |(with GNU runtime) doesn't
   |or new rendering methods|provide alloc, init, or
   |usless  |new, rendering methods
   ||useless
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
The only warning I get when compiling the program is:

$ /usr/local/bin/gcc -o 67455 67455.m -lobjc
67455.m: In function ‘main’:
67455.m:51:2: warning: incompatible implicit declaration of built-in function
‘printf’
  printf("Initial Value: %d\n", [aTestObject value]);
  ^~
67455.m:51:2: note: include ‘’ or provide a declaration of ‘printf’
$

When running it, I get this output:

$ ./67455
Initial Value: 0
+45 Value: 45
-63 Value: -18
+103 Value: 85
$

After including , when explicitly specifying the runtime flag, I only
get the warning with -fgnu-runtime, which leads to a crash when running it:

$ /usr/local/bin/gcc -fnext-runtime -o 67455_next 67455.m -lobjc
$ ./67455_next
Initial Value: 0
+45 Value: 45
-63 Value: -18
+103 Value: 85
$ /usr/local/bin/gcc -fgnu-runtime -o 67455_gnu 67455.m -lobjc
67455.m: In function ‘-[TestObject init]’:
67455.m:21:2: warning: ‘Object’ may not respond to ‘-init’
  if ((self = [super init]))
  ^~
67455.m:21:2: warning: (Messages without a matching method signature
67455.m:21:2: warning: will be assumed to return ‘id’ and accept
67455.m:21:2: warning: ‘...’ as arguments.)
67455.m: In function ‘main’:
67455.m:51:2: warning: ‘TestObject’ may not respond to ‘+alloc’
  TestObject *aTestObject = [[TestObject alloc] init];
  ^~
$ ./67455_gnu
Bus error
$

So confirming for the GNU runtime. Since it's a runtime issue, changing
component to libobjc. Feel free to change back if I'm wrong.

[Bug objc/53943] Compiler ICE with -fobjc-direct-dispatch flag on Linux

[kostja.osipov at gmail dot com]

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

--- Comment #2 from Konstantin Osipov  ---
kostja@atlas ~ % gcc -fobjc-direct-dispatch foo.m -lobjc
foo.m: In function ‘main’:
foo.m:14:9: internal compiler error: Segmentation fault
 @throw [Interface new];
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
kostja@atlas ~ % gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug target/81585] fastcall/stdcall attribute conflict not detected on distinct declarations of the same function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
See also bug 53716 for questions arising due to the inconsistent handling of
these conflicts.

[Bug target/81585] New: fastcall/stdcall attribute conflict not detected on distinct declarations of the same function

[msebor at gcc dot gnu.org]

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

Bug ID: 81585
   Summary: fastcall/stdcall attribute conflict not detected on
distinct declarations of the same function
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The i386 back-end makes an effort to detect mutually exclusive function
attribute combinations such as fastcall and stdcall but it missed those that
result from merging such attributes from distinct declarations.  Those then
lead to type errors later on.

The back-end also rejects these conflicting declaration with an error.  That
makes sense to me but it's inconsistent with how GCC treats other such
conflicts (they are typically diagnosed with -Wattributes, with the conflicting
attribute being dropped in favor of the original; i.e., the first one wins).

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic -m32 x.c
void __attribute__ ((fastcall, stdcall)) f (void);

void __attribute__ ((fastcall)) g (void);

void __attribute__ ((stdcall)) g (void);
x.c:1:1: error: stdcall and fastcall attributes are not compatible
 void __attribute__ ((fastcall, stdcall)) f (void);
 ^~~~
x.c:5:32: error: conflicting types for ‘g’
 void __attribute__ ((stdcall)) g (void);
^
x.c:3:33: note: previous declaration of ‘g’ was here
 void __attribute__ ((fastcall)) g (void);
 ^

[Bug objc/57428] Objective C exceptions completely broken in gcc 4.7

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
Runs without crashing on me on Darwin with gcc8:

$ /usr/local/bin/gcc 57428.m -fobjc-exceptions -o 57428 -lobjc
$ ./57428
objc[40723]: Class Object is implemented in both /usr/lib/libobjc.A.dylib and
/private/var/root/gcc_bugs/./57428. Using implementation from
/private/var/root/gcc_bugs/./57428.
Catch(Frob *)
$

Closing as WORKSFORME

[Bug objc/53943] Compiler ICE with -fobjc-direct-dispatch flag on Linux

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
On Darwin it does this:

$ /usr/local/bin/gcc -fobjc-direct-dispatch 53943.m -lobjc
53943.m: In function ‘main’:
53943.m:14:2: error: ‘-fobjc-exceptions’ is required to enable Objective-C
exception syntax
  @throw [Interface new];
  ^
$ /usr/local/bin/gcc -fobjc-direct-dispatch -fobjc-exceptions 53943.m -lobjc
$

I don't have Linux to test; could you try again with adding the
-fobjc-exceptions flag on your machine?

[Bug tree-optimization/81573] [8 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On July 27, 2017 4:39:45 PM GMT+02:00, "seurer at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81573
>
>--- Comment #7 from seurer at gcc dot gnu.org ---
>The problem in the test case is that the code assumes "char" is signed.
> On
>power it is not.  So "b" starts at 0, is decremented to 255, and
>...etc...  
>The for loop will run forever.

Sorry.  Can you commit the obvious fix making it explicitly signed char?

[Bug objc/53345] some OPT_Wformat is enabled by default

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #1)
> This affects in particular the objc FE:
> 
> Executing on host: /home/manuel/test4/187442M/build/gcc/xgcc
> -B/home/manuel/test4/187442M/build/gcc/
> /home/manuel/test4/src/gcc/testsuite/gcc.dg/warn-nsstring.c 
> -fno-diagnostics-show-caret-ansi -pedantic-errors -S  -m32 -o
> warn-nsstring.s(timeout = 300)
> FAIL: gcc.dg/warn-nsstring.c  (test for warnings, line 4)
> FAIL: gcc.dg/warn-nsstring.c  (test for warnings, line 5)
> PASS: gcc.dg/warn-nsstring.c (test for excess errors)

I can't reproduce with that exact command, but I can if I force Objective-C:

$ /usr/local/bin/gcc -fno-diagnostics-show-caret-ansi -pedantic-errors -S 
-m32 -o warn-nsstring.s
/private/var/root/gcc-git/gcc/testsuite/gcc.dg/warn-nsstring.c 
$ /usr/local/bin/gcc -x objective-c -fno-diagnostics-show-caret -c -ansi
-pedantic-errors -S  -m32 -o warn-nsstring.s
/private/var/root/gcc-git/gcc/testsuite/gcc.dg/warn-nsstring.c 
/private/var/root/gcc-git/gcc/testsuite/gcc.dg/warn-nsstring.c:4:1: error:
format string argument is not a string type
/private/var/root/gcc-git/gcc/testsuite/gcc.dg/warn-nsstring.c:5:1: error:
format string argument is not a string type
$

So, confirmed since the 2nd command errors.

[Bug objc/25361] structures containing vectors are not encoded correctly

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||egallager at gcc dot gnu.org

--- Comment #10 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #9)
> objc.dg-struct-layout-encoding-1/t026_main.m seems to pass on all platforms
> I have looked at. The other tests pass on several platforms, except
> Intel/AMD ones (see pr45989).

pr45989 has been closed; can this one be closed now too?

[Bug objc/24867] many N^2 loops in objc frontend

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Nathan Froyd from comment #5)
> Subject: Bug 24867
> 
> Author: froydnj
> Date: Sat Jul  3 19:00:52 2010
> New Revision: 161777
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=161777
> Log:
>   PR objc/24867
>   * objc-act.c (build_sized_array_type): New function.
>   (add_objc_string): Use it.
>   (generate_protocol_list): Likewise.
>   (generate_objc_image_info): Likewise.
>   (add_field_decl): New function.
>   (objc_build_struct): Use a VEC rather than building a TREE_LIST.
>   (generate_struct_by_value_array): Use add_field_decl.
>   (build_objc_symtab_template): Likewise.
>   (build_module_descriptor): Likewise.
>   (build_objc_exception_stuff): Likewise.
>   (build_protocol_template): Likewise.
>   (build_method_prototype_list_template): Likewise.
>   (build_method_prototype_template): Likewise.
>   (build_category_template): Likewise.
>   (build_selector_template): Likewise.
>   (build_class_template): Likewise.
>   (build_super_template): Likewise.
>   (build_ivar_template): Likewise.
>   (build_ivar_list_template): Likewise.
>   (build_method_list_template): Likewise.
>   (build_method_template): Likewise.
> 
> Modified:
> trunk/gcc/objc/ChangeLog
> trunk/gcc/objc/objc-act.c

Did this fix it?

[Bug c/60100] warning disappears when preprocessed source is compiled

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #12 from Eric Gallager  ---
(In reply to lavr from comment #10)
> > I guess also a dup of PR57201.
> 
> While I can agree these cases (and the one mentioned within PR57201) look
> similar, the gravity of the disappearing warning in case of a mismatched
> type is more severe than an unused variable or no-effect code...

The fact that PR57201 was originally about an unused variable is irrelevant,
it's the bug for warnings disappearing like this in general. Closing this as a
duplicate of it.

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

[Bug c/57201] Using --save-temps affects whether warning is printed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||lavr at ncbi dot nlm.nih.gov

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

[Bug c/57821] 'array is too large' error is missing when sizetype overflows

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #12 from Eric Gallager  ---
Error is printed for me on i386-apple-darwin9.8.0, whether building 32-bit or
64-bit:

$ /usr/local/bin/gcc -m32 -c 30455.c
30455.c:6:1: error: size of array is too large
 };
 ^
$ /usr/local/bin/gcc -m64 -c 30455.c
30455.c:6:1: error: size of array is too large
 };
 ^
$

Is this still a bug for others?

[Bug hsa/81477] HSA offloading regressions: "function cannot be cloned"

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|marxin at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #2 from Martin Jambor  ---
(In reply to Thomas Schwinge from comment #0)
> I noticed that with HSA offloading enabled, as of r250048 ("Avoid global
> optimize flag checks in LTO")

This is a bug in that commit, versionable flag should be independent
of optimization level.  I am testing a fix.

[Bug c/47901] -Wall should not imply -Wformat-zero-length by default

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #10 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #8)
> I still think it may be fine moving this warning to -Wextra, since it gives
> false positives and when it does, they are hard to avoid.
> 
> Anders, you may get to convince more people by sending a patch to
> gcc-patches with your reasoning.

Confirming

[Bug c/81417] -Wsign-compare should print types being compared

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
There is more to fix, e.g. diagnostic with ?:, so not marking as resolved just
yet.

[Bug c/81417] -Wsign-compare should print types being compared

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Thu Jul 27 15:02:17 2017
New Revision: 250630

URL: https://gcc.gnu.org/viewcvs?rev=250630=gcc=rev
Log:
PR c/81417
* c-warn.c (warn_for_sign_compare): Tweak the warning message.  Print
the types.

* c-c++-common/Wsign-compare-1.c: New test.
* g++.dg/warn/Wsign-compare-2.C: Update dg-warning.
* g++.dg/warn/Wsign-compare-4.C: Likewise.
* g++.dg/warn/Wsign-compare-6.C: Likewise.
* g++.dg/warn/compare1.C: Likewise.
* gcc.dg/compare1.c: Likewise.
* gcc.dg/compare2.c: Likewise.
* gcc.dg/compare4.c: Likewise.
* gcc.dg/compare5.c: Likewise.
* gcc.dg/pr35430.c: Likewise.
* gcc.dg/pr60087.c: Likewise.

Added:
trunk/gcc/testsuite/c-c++-common/Wsign-compare-1.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wsign-compare-2.C
trunk/gcc/testsuite/g++.dg/warn/Wsign-compare-4.C
trunk/gcc/testsuite/g++.dg/warn/Wsign-compare-6.C
trunk/gcc/testsuite/g++.dg/warn/compare1.C
trunk/gcc/testsuite/gcc.dg/compare1.c
trunk/gcc/testsuite/gcc.dg/compare2.c
trunk/gcc/testsuite/gcc.dg/compare4.c
trunk/gcc/testsuite/gcc.dg/compare5.c
trunk/gcc/testsuite/gcc.dg/pr35430.c
trunk/gcc/testsuite/gcc.dg/pr60087.c

[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions

[matt at godbolt dot org]

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

--- Comment #32 from Matt Godbolt  ---
Thanks! One thing, I probably misunderstand this, but you've put 7.1 in "known
to work" above: is this on purpose? 7.1 is the version the issue comes up in, I
assume it'll be fixed in an upcoming 7.2 release?

[Bug tree-optimization/81573] [8 Regression] wrong code at -O3 on x86_64-linux-gnu

[seurer at gcc dot gnu.org]

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

--- Comment #7 from seurer at gcc dot gnu.org ---
The problem in the test case is that the code assumes "char" is signed.  On
power it is not.  So "b" starts at 0, is decremented to 255, and ...etc...  
The for loop will run forever.

[Bug c/81306] valgrind error for function warn_for_multistatement_macros in file c-warn.c line 2474

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
It works, so mine.

[Bug c++/81574] ICE on valid C++14 code: in canonicalize_component_ref, at gimplify.c:2481

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug tree-optimization/81573] [8 Regression] wrong code at -O3 on x86_64-linux-gnu

[seurer at gcc dot gnu.org]

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

--- Comment #6 from seurer at gcc dot gnu.org ---
And it is run multiple times which means make check takes forever.

WARNING: program timed out.
FAIL: gcc.dg/torture/pr81573.c   -O0  execution test
. . .
WARNING: program timed out.
FAIL: gcc.dg/torture/pr81573.c   -O1  execution test
. . .
WARNING: program timed out.
FAIL: gcc.dg/torture/pr81573.c   -O2  execution test
. . .

[Bug tree-optimization/81573] [8 Regression] wrong code at -O3 on x86_64-linux-gnu

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #5 from seurer at gcc dot gnu.org ---
That new test case (gcc.dg/torture/pr81573.c) times out when run on powerpc64.

[Bug other/81582] -Wimplicit-fallthrough= wrong warning with -save-temps

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
The reason it is shown in the diagnostics is that the diagnostic code opens the
original, non-preprocessed source (if available) and prints the line from
there.
If you don't have the source around, say compile with -xc - and pipe the source
on stdin, or move the preprocessed source somewhere else and compile there,
such as with distcc, then you obviously don't get that comment printed.
That doesn't mean the comments aren't irrecovably lost.  There are many other
things used by warnings lost during preprocessing, macro contexts, formatting
for -Wmisleading-indentation and many others.
We just need to teach users that preprocessing is a destructive thing.
I've been trying to convince e.g. the ccache people to use -fdirectives-only
preprocessing, but they aren't listening.

[Bug c++/81575] [7/8 Regression] ICE on C++ code: in cp_build_addr_expr_1, at cp/typeck.c:5793

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |7.2
Summary|ICE on C++ code: in |[7/8 Regression] ICE on C++
   |cp_build_addr_expr_1, at|code: in
   |cp/typeck.c:5793|cp_build_addr_expr_1, at
   ||cp/typeck.c:5793

--- Comment #2 from Jakub Jelinek  ---
Weird, at least clang 5.0.0 (trunk 304785) accepts it with
warning: incompatible pointer to integer conversion assigning to 'int' from
'const class (anonymous class at pr81575.C:1:1) *'
pedwarn.
The ICE started with r246954.  Before that it was rejected with:
pr81575.C:6:8: error: invalid use of non-lvalue array
   c += a;
^
pr81575.C:6:8: error:   in evaluation of ‘operator+=(int, class [1])’

[Bug other/81582] -Wimplicit-fallthrough= wrong warning with -save-temps

[gjl at gcc dot gnu.org]

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

--- Comment #7 from Georg-Johann Lay  ---
(In reply to Jakub Jelinek from comment #6)
> If you are preprocessing without -C and without -fdirectives-only, then
> comments are gone, so you really can't use them to inhibit the warning.

Yes, so -Wimplicit-fallthrough is really fragile.  And the information is
obviously available somewhere[tm] as the diagnostic displays it, adding even
more confusion.

This might all be acceptable if -Wimplicit-fallthrough had to be enabled by
hand, but it is enabled per default with -W (and yes, I know that's
documented).  It's still questionable to have such stuff enabled per default
given its fragility.

I am understanding all this from a GCC internal development perspective, but
not when I am taking the perspective of an ordinary user.

[Bug middle-end/81564] ICE in group_case_labels_stmt()

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #4 from Peter Bergner  ---
Closing as fixed.

[Bug middle-end/81564] ICE in group_case_labels_stmt()

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #3 from Peter Bergner  ---
Fixed.

[Bug middle-end/81564] ICE in group_case_labels_stmt()

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
Author: bergner
Date: Thu Jul 27 14:05:14 2017
New Revision: 250628

URL: https://gcc.gnu.org/viewcvs?rev=250628=gcc=rev
Log:
gcc/
PR middle-end/81564
* tree-cfg.c (group_case_labels_stmt): Handle already deleted blocks.

gcc/testsuite/
PR middle-end/81564
* gcc.dg/pr81564.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr81564.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug libstdc++/81584] New: Pretty Printer for string* doesn't work

[ghjghj530-bubu at yahoo dot de]

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

Bug ID: 81584
   Summary: Pretty Printer for string* doesn't work
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ghjghj530-bubu at yahoo dot de
  Target Milestone: ---

GCC 6.3, GDB 7.10, building with: -D_GLIBCXX_USE_CXX11_ABI=1

Code:
std::string fooVar = "hello world";
std::string* pFooVar = 

(gdb) p pFooVar
p pFooVar
$4 = Traceback (most recent call last):
  File "*\gdb-7.10/python\libstdcxx\v6\printers.py", line xx, in to_string
reptype = gdb.lookup_type (str (realtype) + '::_Rep').pointer ()
gdb.error: No type named std::__cxx11::string *::_Rep.


I changed the python script to this and it worked for me:

def __init__(self, typename, val):
self.val = val

def to_string(self):
# Make sure  and string* works, too.
type = self.val.type
if type.code == gdb.TYPE_CODE_REF or type.code == gdb.TYPE_CODE_PTR:
type = type.target ()

# Change to original printer to make string* work: Check for new/old
string after dereferencing
typeName = str(type)
new_string = typeName.find("::__cxx11::basic_string") != -1 or
typeName.find("::__cxx11::string") != -1

# Calculate the length of the string so that to_string returns the
string according to length, 
# not according to first null encountered.
ptr = self.val ['_M_dataplus']['_M_p']
if new_string:
..
..

[Bug c/61727] #pragma simd is undocumented

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-27
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug other/81582] -Wimplicit-fallthrough= wrong warning with -save-temps

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
If you are preprocessing without -C and without -fdirectives-only, then
comments are gone, so you really can't use them to inhibit the warning.

[Bug c++/81574] ICE on valid C++14 code: in canonicalize_component_ref, at gimplify.c:2481

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Bet the initializer isn't through function-to-pointer conversion
(decay_conversion or whatever else invokes it), but no idea where that should
be done etc.

[Bug c++/81574] ICE on valid C++14 code: in canonicalize_component_ref, at gimplify.c:2481

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
r244055 still rejects this:
error: cannot bind non-const lvalue reference of type ‘void (*&)()’ to an
rvalue of type ‘void (*)()’
And r244056 started to ICE.

[Bug tree-optimization/81494] [8 Regression] 454.calculix miscompares with -Ofast after r249919

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Bug tree-optimization/81573] [8 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/81573] [8 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Jul 27 13:46:07 2017
New Revision: 250627

URL: https://gcc.gnu.org/viewcvs?rev=250627=gcc=rev
Log:
2017-07-27  Richard Biener  

PR tree-optimization/81573
PR tree-optimization/81494
* tree-vect-loop.c (vect_create_epilog_for_reduction): Handle
multi defuse cycle case.

* gcc.dg/torture/pr81573.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr81573.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/81494] [8 Regression] 454.calculix miscompares with -Ofast after r249919

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu Jul 27 13:46:07 2017
New Revision: 250627

URL: https://gcc.gnu.org/viewcvs?rev=250627=gcc=rev
Log:
2017-07-27  Richard Biener  

PR tree-optimization/81573
PR tree-optimization/81494
* tree-vect-loop.c (vect_create_epilog_for_reduction): Handle
multi defuse cycle case.

* gcc.dg/torture/pr81573.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr81573.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/81571] [8 Regression] ICE at -O3 in both 32-bit and 64-bit modes (internal compiler error: in as_a, at is-a.h:192)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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