[Bug c++/81976] bad is_standard_layout/has_unique_object_representations results with a chain of empty bases

[P at draigBrady dot com]

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

--- Comment #4 from Pádraig Brady  ---
According to the previous comment this depends on PR 82764
and the target milestone is 7.4

[Bug c/85623] New: strncmp() warns about attribute 'nonstring' incorrectly in -Wstringop-overflow

[gandalf at winds dot org]

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

Bug ID: 85623
   Summary: strncmp() warns about attribute 'nonstring'
incorrectly in -Wstringop-overflow
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gandalf at winds dot org
  Target Milestone: ---

The following code emits a warning when using strncmp() to compare a small
quoted string with a "char data[4]" array declared __attribute__((nonstring)).

The warning only appears if the quoted string is smaller than the size of the
data[] array. My use of the data[] array is intended to act like a
NUL-terminated string unless it is 4 bytes long, at which point it is
non-NUL-terminated. This is the expected behavior when using strncpy() to fill
(and truncate) arbitrary strings into a fixed-sized char[] array. I understand
I can let GCC know of this intent by marking the array with
__attribute__((nonstring)).

My anticipated fix for GCC is that this warning should only appear with
strcmp() and not strncmp().


extern char *strncpy (char *, const char *, long);
extern int strncmp (const char *, const char *, long);

extern __attribute__((nonstring)) char data[4];

void test(char *string)
{
  if(strncmp(data, "??", sizeof(data)))
strncpy(data, string, sizeof(data));
}

# gcc -O3 test.c -c -Wall
test.c: In function ‘test’:
test.c:8:6: warning: ‘__builtin_strcmp’ argument 1 declared attribute
‘nonstring’ [-Wstringop-overflow=]
   if(strncmp(data, "??", sizeof(data)))
  ^
test.c:4:40: note: argument ‘data’ declared here


Incidentally, changing the "??" to "" or to a variable of type char* does
not cause the warning.

In my understanding, strncmp() is the correct function to use here because the
size (3rd arg) does not overflow the length of data[4]. Nothing has overflowed
here to warrant a stringop-overflow warning.

I'm also unsure why the warning says '__builtin_strcmp' when strncmp() instead
of strcmp() is being used.

Removing the __attribute__((nonstring)) causes strncpy() to warn instead:


extern char *strncpy (char *, const char *, long);
extern int strncmp (const char *, const char *, long);

extern char data[4];

void test(char *string)
{
  if(strncmp(data, "??", sizeof(data)))
strncpy(data, string, sizeof(data));
}

# gcc -O3 test.c -c -Wall
test.c: In function ‘test’:
test.c:9:5: warning: ‘strncpy’ specified bound 4 equals destination size
[-Wstringop-truncation]
 strncpy(data, string, sizeof(data));
 ^~~


Conclusion: If GCC 8+ intends that we mark non-NUL-terminated strings with
__attribute__((nonstring)) going forward, then there needs to be a way to
cleanly use strncmp() to compare strings saved with strncpy() without any
warnings.

[Bug other/85622] New: gcc-8.1.0/NEWS says it's not released yet

[hp at gcc dot gnu.org]

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

Bug ID: 85622
   Summary: gcc-8.1.0/NEWS says it's not released yet
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Target Milestone: ---

In the gcc-8.1.0 tarball, the file NEWS contains, near the top:
"As of this time no releases of GCC 8 have yet been made."
further down:
"Disclaimer: GCC 8 has not been released yet, so this document is a
work-in-progress."
The NEWS file says it's autogenerated and those two lines come from paragraphs
that indicate that they're generated from 
and  respectively.

Not sure how to fix that accurately, but perhaps by adjusting the
release-checklist (wherever that lives) so "update the index.html and
gcc-N/changes.html web pages" come before "execute the release script"?

[Bug c++/59655] incorrect diagnostic on templatized function with lambda parameter

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
   Last reconfirmed|2017-10-01 00:00:00 |2018-5-3
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80916

--- Comment #1 from Jonathan Wakely  ---
A smaller testcase:

template struct trait { static constexpr bool value = false; };

struct thread {
  template
thread(T t)
{
  static_assert(trait::value, "trait");

  foo(t);
}

  template void foo(T) { return; }
};

int main()
{
  thread t([](int) { });
}


used.cc: In instantiation of 'thread::thread(T) [with T =
main()::; U = {}]':
used.cc:17:23:   required from here
used.cc:7:21: error: static assertion failed: trait
   static_assert(trait::value, "trait");
 ^~~~
used.cc:12:29: error: 'void thread::foo(T) [with T = main()::]',
declared using local type 'main()::', is used but never defined
[-fpermissive]
   template void foo(T) { return; }
 ^~~
used.cc:12:29: warning: 'void thread::foo(T) [with T = main()::]'
used but never defined

[Bug c++/60277] Bogus "inline function virtual ..." used but never defined

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-02
 Ever confirmed|0   |1

[Bug libgcc/85621] savms/resms have executable stack (lack GNU-stack marking)

[daniel.santos at pobox dot com]

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

Daniel Santos  changed:

   What|Removed |Added

 CC||daniel.santos at pobox dot com

--- Comment #3 from Daniel Santos  ---
Hello guys.

These save/restore stubs are for 64-bit Wine and I don't know of anything else
that will use them.

I'm having a bit of trouble finding documentation on this section, but I did
find a thread suggesting that it should be documented
(https://sourceware.org/ml/gnu-gabi/2016-q1/msg1.html :)  I guess I need to
dig into binutils sources for info?  What exactly does adding this section do?

Thanks

[Bug libgcc/85621] savms/resms have executable stack (lack GNU-stack marking)

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||jakub at redhat dot com,
   ||zorry at gentoo dot org

--- Comment #2 from Sergei Trofimovich  ---
Magnus posted very similar patch:
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00011.html

[Bug middle-end/85620] Missing ENDBR after swapcontext

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-02
 CC||igor.v.tsimbalist at intel dot 
com
 Blocks||81652
Summary|swapcontext isn't marked|Missing ENDBR after
   |return twice|swapcontext
 Ever confirmed|0   |1

--- Comment #5 from H.J. Lu  ---
[hjl@gnu-skx-1 ucontext-1]$ cat y.i
struct ucontext;
typedef struct ucontext ucontext_t;

extern int swapcontext (ucontext_t *__restrict __oucp,
const ucontext_t *__restrict __ucp);

extern int res;

void
foo (ucontext_t *oucp, ucontext_t *ucp)
{
  res = swapcontext (oucp, ucp);
}
[hjl@gnu-skx-1 ucontext-1]$ make y.s
/export/build/gnu/gcc-8-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-8-test/build-x86_64-linux/gcc/ -O2  -fcf-protection -S
y.i
[hjl@gnu-skx-1 ucontext-1]$ cat y.s
.file   "y.i"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
endbr64
subq$8, %rsp
.cfi_def_cfa_offset 16
callswapcontext  <<<<<<< This may return via indirect branch.
<<<<<<<<<<< Need ENDBR here.
movl%eax, res(%rip)
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
    .size   foo, .-foo
.ident  "GCC: (GNU) 8.1.1 20180502"
.section.note.GNU-stack,"",@progbits
.section.note.gnu.property,"a"
.align 8
.long1f - 0f
.long4f - 1f
.long5
0:
.string  "GNU"
1:
.align 8
.long0xc002
.long3f - 2f
2:
.long0x3
3:
.align 8
4:
[hjl@gnu-skx-1 ucontext-1]$


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full bugs

[Bug target/85582] [9 Regression] wrong code at -O1 and above on x86_64-linux-gnu in 32-bit mode

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/85582] [9 Regression] wrong code at -O1 and above on x86_64-linux-gnu in 32-bit mode

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed May  2 21:56:17 2018
New Revision: 259862

URL: https://gcc.gnu.org/viewcvs?rev=259862=gcc=rev
Log:
PR target/85582
* config/i386/i386.md (*ashl3_doubleword_mask,
*ashl3_doubleword_mask_1, *3_doubleword_mask,
*3_doubleword_mask_1): In condition require that
the highest significant bit of the shift count mask is clear.  In
check whether and[sq]i3 is needed verify that all significant bits
of the shift count other than the highest are set.

* gcc.c-torture/execute/pr85582-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr85582-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/85472] Regex match bug

[haberg-1 at telia dot com]

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

--- Comment #22 from Hans Åberg  ---
(In reply to Tim Shen from comment #16)
> ...I meant to observe whether the example triggers a O(k^2) behavior. It
> should be less than quadratic. ...

> Here is the updated example, to re-arrange the expression to a tree, not a
> chain of "|" operators.

The matching itself that I do is linear O(k): I used a version of your example
for my program, timing the part in question for various values, dividing with N
and N^2, where N is the difference of the input numbers, making it easy to see
if it is O(k) or O(k^2).

However, in your example, the DFA lexing is quadratic, probably because I use
unordered_set objects that here gets size proportional to N. Thus this ought to
be optimized. So you might check if that might be an issue in the C++ library.

[Bug libgcc/85621] savms/resms have executable stack (lack GNU-stack marking)

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  ---
Created attachment 44053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44053=edit
0001-i386-savms-resms-mark-stack-non-executable-PR85621.patch

[Bug libgcc/85621] New: savms/resms have executable stack (lack GNU-stack marking)

[slyfox at inbox dot ru]

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

Bug ID: 85621
   Summary: savms/resms have executable stack (lack GNU-stack
marking)
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

Detected by gentoo's scanelf when building gcc-8.0.1:

 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:avx_savms64.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:avx_resms64.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:avx_resms64x.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:avx_savms64f.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:avx_resms64f.o
 * !WX --- ---
usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:avx_resms64fx.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:sse_savms64.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:sse_resms64.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:sse_resms64x.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:sse_savms64f.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:sse_resms64f.o
 * !WX --- ---
usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/32/libgcc.a:sse_resms64fx.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:avx_savms64.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:avx_resms64.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:avx_resms64x.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:avx_savms64f.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:avx_resms64f.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:avx_resms64fx.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:sse_savms64.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:sse_resms64.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:sse_resms64x.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:sse_savms64f.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:sse_resms64f.o
 * !WX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/libgcc.a:sse_resms64fx.o

My guess is that libgcc/config/i386 files:
   resms64.h  resms64f.h  resms64fx.h  resms64x.h  savms64.h  savms64f.h
require something like:

#if defined(__ELF__) && defined(__linux__)
.section .note.GNU-stack,"",%progbits
.previous
#endif

Thanks!

[Bug target/85613] [8/9 regression] FAIL: gfortran.dg/pr51434.f90 -O1 execution test

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
.

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

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

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

--- Comment #7 from Andreas Schwab  ---
*** Bug 85613 has been marked as a duplicate of this bug. ***

[Bug ipa/85607] [9 Regression] ice in add_type, at ipa-icf.c:1583

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|ice in add_type, at |[9 Regression] ice in
   |ipa-icf.c:1583  |add_type, at ipa-icf.c:1583

[Bug middle-end/85620] swapcontext isn't marked return twice

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to H.J. Lu from comment #3)
> Technically, swapcontext only returns once, but not when it is called.
> In that sense, it returns twice.

Huh?  For the purpose of ECF_RETURNS_TWICE, swapcontext does not need to be
marked as such.  ECF_RETURNS_TWICE is only needed for CFG reasons.

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

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #6 from Harald Anlauf  ---
(In reply to Richard Biener from comment #5)
> FE issue I believe.

It looks like the testcase got corrupted.

Testing with another compiler shows that it is invalid as is.  E.g.,

% nagfor pr51434.f90
NAG Fortran Compiler Release 6.1(Tozai) Build 6106
Error: pr51434.f90, line 9: Dimension 1 of value for array T has extent 18
instead of 5
Errors in declarations, no further processing for FOO
Error: pr51434.f90, line 13: USE of module FOO which has errors
Errors in declarations, no further processing for BAR
[NAG Fortran Compiler error termination, 2 errors]


Replacing the line

  character(len=1):: t(n) = transfer('abcde ', s)   

by

  character(len=1):: t(n) = transfer('abcde', s)

makes it work properly.

[Bug middle-end/85620] getcontext is wrongly marked return twice

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Technically, swapcontext only returns once, but not when it is called.
In that sense, it returns twice.

[Bug middle-end/85620] getcontext is wrongly marked return twice

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
http://pubs.opengroup.org/onlinepubs/007904975/functions/getcontext.html

If the ucp argument was created with getcontext(), program execution continues
as if the corresponding call of getcontext() had just returned. 

That means it does return twice.

[Bug middle-end/85620] getcontext is wrongly marked return twice

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
getcontext does return twice.  Swapcontext only returns once.

If you get the current context, and then latter on swap the context, you just
returned to the place where getcontext is called.  you do setcontext (or
swapcontext again), you get the swapcontext context.  That is it only ever
returns once.

[Bug middle-end/85620] New: getcontext is wrongly marked return twice

[hjl.tools at gmail dot com]

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

Bug ID: 85620
   Summary: getcontext is wrongly marked return twice
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

special_function_p has

  /* ECF_RETURNS_TWICE is safe even for -ffreestanding.  */
  if (! strcmp (tname, "setjmp")
  || ! strcmp (tname, "sigsetjmp")
  || ! strcmp (name, "savectx")
  || ! strcmp (name, "vfork")
  || ! strcmp (name, "getcontext"))
  getcontext never returns twice.
Instead swapcontext may return twice.
flags |= ECF_RETURNS_TWICE;

[Bug ipa/85617] Wunused-but-set-variable does not analyze variables passed to functions

[danielgutson at gmail dot com]

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

--- Comment #2 from Daniel Gutson  ---
(In reply to Andrew Pinski from comment #1)
> I doubt we want to make this warning to be flow sensitive at all.  There are
> many other warnings which are flow sensitive and they change behavior
> between different releases of GCC and implementing this warning this way
> will do just that too.

Sorry I don't get the issue. Are you saying that similar features suffered
breakage between releases , and because of that, this feature should not be
implemented because it may suffer the same fate?

[Bug ipa/85617] Wunused-but-set-variable does not analyze variables passed to functions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
I doubt we want to make this warning to be flow sensitive at all.  There are
many other warnings which are flow sensitive and they change behavior between
different releases of GCC and implementing this warning this way will do just
that too.

[Bug middle-end/85619] New: Inconsistent descriptions for new warning options in GCC 8.1.0

[julien at trigofacile dot com]

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

Bug ID: 85619
   Summary: Inconsistent descriptions for new warning options in
GCC 8.1.0
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julien at trigofacile dot com
  Target Milestone: ---

In GCC 8.1.0 documentation
(https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html):

1/ -Wif-not-aligned is said to be included by default in documentation, but
Release Changes mention its inclusion in -Wall.  So, is it really the case? 
(Also note a typo "This is is enabled by default." in documentation.)

2/ -Wstringop-truncation and -Wpacked-not-aligned are said to be included in
-Wall in Release Changes but documentation does not mention them in -Wall.

[Bug c++/85618] New: Zero initialized non constant stack array causes internal compile error

[zefzsoftwares at hotmail dot com]

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

Bug ID: 85618
   Summary: Zero initialized non constant stack array causes
internal compile error
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zefzsoftwares at hotmail dot com
  Target Milestone: ---

Following code to reproduce compile error:

  void function(int size) {
 bool myArray[size][size] = {};
  }

Compilation example: https://godbolt.org/g/VfDvsr

Fails with the following error:
"
  during RTL pass: expand

  : In function 'void function(std::vector)':

  :4:9: internal compiler error: in make_decl_rtl, at varasm.c:1322

  bool myArray[arg.size()][arg.size()] = {};

   ^~~

  mmap: Invalid argument
"

Removing the = {} initializer and using a memset() instead is a work-around.
Regression bug since it compiles fine with GCC 7

[Bug libstdc++/68197] negative index to ios_base::iword lead to unpredictable result

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
GCC 9 will set badbit in the stream state on invalid indices.

[Bug libstdc++/68197] negative index to ios_base::iword lead to unpredictable result

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Wed May  2 19:04:55 2018
New Revision: 259854

URL: https://gcc.gnu.org/viewcvs?rev=259854=gcc=rev
Log:
PR libstdc++/68197 fail on negative iword/pword indices

The suggested resolution of LWG 3083 is to make invalid indices
undefined, but we can fairly easily check for them and treat them as
errors in the same way as allocation failure. This avoids a segfault or
worse, setting an error flag on the stream instead.

PR libstdc++/68197
* include/bits/ios_base.h (ios_base::iword, ios_base::pword): Cast
indices to unsigned.
* src/c++11/ios.cc (ios_base::_M_grow_words): Treat negative indices
as failure. Refactor error handling.
* testsuite/27_io/ios_base/storage/68197.cc: New.

Added:
trunk/libstdc++-v3/testsuite/27_io/ios_base/storage/68197.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/ios_base.h
trunk/libstdc++-v3/src/c++11/ios.cc

[Bug ipa/85617] New: Wunused-but-set-variable does not analyze variables passed to functions

[danielgutson at gmail dot com]

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

Bug ID: 85617
   Summary: Wunused-but-set-variable does not analyze variables
passed to functions
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danielgutson at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The following code

void f(int& x)
{
x = 1;
}

int main()
{
int a;
f(a);
//a = 1;
}

should warn about 'a' assigned but never used in main. Shouldn't be this helped
by IPA?

[Bug target/85616] New: ARM target using -O2 may cause unaligned access

[denis_second at hotmail dot com]

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

Bug ID: 85616
   Summary: ARM target using -O2 may cause unaligned access
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis_second at hotmail dot com
  Target Milestone: ---

Created attachment 44052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44052=edit
c file

The 32-bit arm target using "-O2" optimization option may combine single stores
into a multi store without respecting the alignment requirement of stm
instruction.
ARM reference:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html

The following output was produced using gcc version 6.3.1

simple code to recreate the issue:

extern "C" bool bugTest(unsigned char *buf_start)
{
register unsigned int item1 asm("r2") = *(unsigned int *) _start[12];
register unsigned int item2asm("r3")= *(unsigned int *) _start[16];
*(unsigned int *) _start[0] = item1;
*(unsigned int *) _start[4] = item2;

return 1;
}

gcc -march=armv7-a -O2 -o stm.o stm.c

objdump stm.o

 :
   0:   e590200cldr r2, [r0, #12]
   4:   e5903010ldr r3, [r0, #16]
   8:   e88cstm r0, {r2, r3} <-- causing unaligned access if
buf_start wasn't on a word boundary
   c:   e12fff1ebx  lr


If I turn off peephole2 optimization I get the expected assembly

gcc -march=armv7-a -O2 -fno-peephole2 -o stm.o stm.c

 :
   0:   e590200cldr r2, [r0, #12]
   4:   e5903010ldr r3, [r0, #16]
   8:   e5802000str r2, [r0]
   c:   e5803004str r3, [r0, #4]
  10:   e12fff1ebx  lr

[Bug tree-optimization/85615] [8/9 Regression] ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
r247578

[Bug tree-optimization/85615] [8/9 Regression] ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-02
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |8.2
Summary|ICE at -O2 and above on |[8/9 Regression] ICE at -O2
   |valid code on   |and above on valid code on
   |x86_64-linux-gnu: in|x86_64-linux-gnu: in
   |dfs_enumerate_from, at  |dfs_enumerate_from, at
   |cfganal.c:1197  |cfganal.c:1197
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/85615] New: ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[helloqirun at gmail dot com]

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

Bug ID: 85615
   Summary: ICE at -O2 and above on valid code on
x86_64-linux-gnu: in dfs_enumerate_from, at
cfganal.c:1197
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

As the title. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180502 (experimental) [trunk revision 259838] (GCC)



$ gcc-trunk -O2 abc.c
during GIMPLE pass: vrp
abc.c: In function ‘fn1’:
abc.c:3:6: internal compiler error: in dfs_enumerate_from, at cfganal.c:1197
 void fn1() {
  ^~~
0x5fc743 dfs_enumerate_from(basic_block_def*, int, bool (*)(basic_block_def
const*, void const*), basic_block_def**, int, void const*)
../../gcc/gcc/cfganal.c:1197
0xe97e21 determine_bb_domination_status(loop*, basic_block_def*)
../../gcc/gcc/tree-ssa-threadupdate.c:1501
0xe9a541 thread_through_loop_header
../../gcc/gcc/tree-ssa-threadupdate.c:1648
0xe9a541 thread_through_all_blocks(bool)
../../gcc/gcc/tree-ssa-threadupdate.c:2391
0xf2ddb5 execute_vrp
../../gcc/gcc/tree-vrp.c:7050
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 abc.c
long a, d;
int b, c;
void fn1() {
  int e = -1L, f = 2, g = 8;
  for (;;) {
for (; b; g++)
  ;
int i;
for (; c;) {
  i = 5;
  for (; e >= 1; i--)
;
}
d = f ?: a;
if (d) {
  e = 0;
  for (; i;)
for (; g < 3; f++)
  ;
}
  }
}

[Bug c++/68374] G++ -Wshadow doesn't warn about static member shadowing

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |9.0

--- Comment #8 from Paolo Carlini  ---
Fully fixed in trunk.

[Bug c++/68374] G++ -Wshadow doesn't warn about static member shadowing

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed May  2 18:15:56 2018
New Revision: 259853

URL: https://gcc.gnu.org/viewcvs?rev=259853=gcc=rev
Log:
/cp
2018-05-02  Paolo Carlini  
Jason Merrill  

PR c++/68374
* name-lookup.c (check_local_shadow): Don't handle static old
declarations in the block handling locals shadowing locals.

/testsuite
2018-05-02  Paolo Carlini  
Jason Merrill  

PR c++/68374
* g++.dg/warn/Wshadow-13.C: New.
* g++.dg/warn/Wshadow-14.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wshadow-13.C
trunk/gcc/testsuite/g++.dg/warn/Wshadow-14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c/82695] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.12)

[drikosev at gmail dot com]

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

--- Comment #3 from Ev Drikos  ---
gcc 8.1 on macos 10.13.4 successfully passes this test.

Thanks,
Ev. Drikos

[Bug libgomp/82428] Builtins for openacc gang/worker/vector id/size

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #8 from Tom de Vries  ---
Patch committed, marking resolved-fixed.

[Bug testsuite/83791] Move tests to libgomp.c-c++-common

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #4 from Tom de Vries  ---
Patch modifying test-cases committed, marking resolved-fixed.

[Bug libgomp/85411] [openacc] Move GOMP_OPENACC_DIM parsing out of nvptx plugin

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #3 from Tom de Vries  ---
Patch with test-cases committed, marking resolved-fixed.

[Bug testsuite/83791] Move tests to libgomp.c-c++-common

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Author: vries
Date: Wed May  2 17:53:43 2018
New Revision: 259851

URL: https://gcc.gnu.org/viewcvs?rev=259851=gcc=rev
Log:
[libgomp, testsuite] Move tests to libgomp.c-c++-common

2018-05-02  Tom de Vries  

PR testsuite/83791
* testsuite/libgomp.c++/udr-9.C: Update.
* testsuite/libgomp.c++/atomic-16.C: Remove.
* testsuite/libgomp.c++/cancel-taskgroup-2.C: Remove.
* testsuite/libgomp.c++/loop-13.C: Remove.
* testsuite/libgomp.c++/loop-14.C: Remove.
* testsuite/libgomp.c++/loop-15.C: Remove.
* testsuite/libgomp.c++/monotonic-1.C: Remove.
* testsuite/libgomp.c++/monotonic-2.C: Remove.
* testsuite/libgomp.c++/nonmonotonic-1.C: Remove.
* testsuite/libgomp.c++/nonmonotonic-2.C: Remove.
* testsuite/libgomp.c++/ordered-1.C: Remove.
* testsuite/libgomp.c++/pr45784.C: Remove.
* testsuite/libgomp.c++/pr64824.C: Remove.
* testsuite/libgomp.c++/pr64868.C: Remove.
* testsuite/libgomp.c++/pr66199-1.C: Remove.
* testsuite/libgomp.c++/pr66199-2.C: Remove.
* testsuite/libgomp.c++/pr66199-3.C: Remove.
* testsuite/libgomp.c++/pr66199-4.C: Remove.
* testsuite/libgomp.c++/pr66199-5.C: Remove.
* testsuite/libgomp.c++/pr66199-6.C: Remove.
* testsuite/libgomp.c++/pr66199-7.C: Remove.
* testsuite/libgomp.c++/pr66199-8.C: Remove.
* testsuite/libgomp.c++/pr66199-9.C: Remove.
* testsuite/libgomp.c++/pr69389.C: Remove.
* testsuite/libgomp.c++/simd10.C: Remove.
* testsuite/libgomp.c++/simd11.C: Remove.
* testsuite/libgomp.c++/simd12.C: Remove.
* testsuite/libgomp.c++/simd13.C: Remove.
* testsuite/libgomp.c++/target-1.C: Remove.
* testsuite/libgomp.c++/target-3.C: Remove.
* testsuite/libgomp.c++/target-4.C: Remove.
* testsuite/libgomp.c++/target-5.C: Remove.
* testsuite/libgomp.c++/taskgroup-1.C: Remove.
* testsuite/libgomp.c++/taskloop-1.C: Remove.
* testsuite/libgomp.c++/taskloop-2.C: Remove.
* testsuite/libgomp.c++/taskloop-3.C: Remove.
* testsuite/libgomp.c++/taskloop-4.C: Remove.
* testsuite/libgomp.c++/udr-9.C: Remove.
* testsuite/libgomp.c++/for-10.C: Remove.
* testsuite/libgomp.c++/for-11.C: Remove.
* testsuite/libgomp.c++/for-12.C: Remove.
* testsuite/libgomp.c++/for-13.C: Remove.
* testsuite/libgomp.c++/for-14.C: Remove.
* testsuite/libgomp.c++/for-9.C: Remove.
* testsuite/libgomp.c/atomic-18.c: Move ...
* testsuite/libgomp.c-c++-common/atomic-18.c: ... here.
* testsuite/libgomp.c/cancel-taskgroup-2.c: Move ...
* testsuite/libgomp.c-c++-common/cancel-taskgroup-2.c: here.
* testsuite/libgomp.c/loop-13.c: Move ...
* testsuite/libgomp.c-c++-common/loop-13.c: ... here.
* testsuite/libgomp.c/loop-14.c: Move ...
* testsuite/libgomp.c-c++-common/loop-14.c: ... here.
* testsuite/libgomp.c/loop-15.c: Remove.
* testsuite/libgomp.c-c++-common/loop-15.c: New test.
* testsuite/libgomp.c/monotonic-1.c: Move ...
* testsuite/libgomp.c-c++-common/monotonic-1.c: ... here.
* testsuite/libgomp.c/monotonic-2.c: Move ...
* testsuite/libgomp.c-c++-common/monotonic-2.c: ... here.
* testsuite/libgomp.c/nonmonotonic-1.c: Move ...
* testsuite/libgomp.c-c++-common/nonmonotonic-1.c: ... here.
* testsuite/libgomp.c/nonmonotonic-2.c: Move ...
* testsuite/libgomp.c-c++-common/nonmonotonic-2.c: ... here.
* testsuite/libgomp.c/ordered-4.c: Move ...
* testsuite/libgomp.c-c++-common/ordered-4.c: ... here.
* testsuite/libgomp.c/pr45784.c: Move ...
* testsuite/libgomp.c-c++-common/pr45784.c: ... here.
* testsuite/libgomp.c/pr64824.c: Move ...
* testsuite/libgomp.c-c++-common/pr64824.c: ... here.
* testsuite/libgomp.c/pr64868.c: Move ...
* testsuite/libgomp.c-c++-common/pr64868.c: ... here.
* testsuite/libgomp.c/pr66199-1.c: Move ...
* testsuite/libgomp.c-c++-common/pr66199-1.c: ... here.
* testsuite/libgomp.c/pr66199-2.c: Move ...
* testsuite/libgomp.c-c++-common/pr66199-2.c: ... here.
* testsuite/libgomp.c/pr66199-3.c: Move ...
* testsuite/libgomp.c-c++-common/pr66199-3.c: ... here.
* testsuite/libgomp.c/pr66199-4.c: Move ...
* testsuite/libgomp.c-c++-common/pr66199-4.c: ... here.
* testsuite/libgomp.c/pr66199-5.c: Move ...
* testsuite/libgomp.c-c++-common/pr66199-5.c: ... here.
* testsuite/libgomp.c/pr66199-6.c: Move ...
* testsuite/libgomp.c-c++-common/pr66199-6.c: ... here.
* testsuite/libgomp.c/pr66199-7.c: Move ...
* testsuite/libgomp.c-c++-common/pr66199-7.c: ... here.

[Bug libgomp/85411] [openacc] Move GOMP_OPENACC_DIM parsing out of nvptx plugin

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Author: vries
Date: Wed May  2 17:53:56 2018
New Revision: 259852

URL: https://gcc.gnu.org/viewcvs?rev=259852=gcc=rev
Log:
[openacc] Move GOMP_OPENACC_DIM parsing out of nvptx plugin

2018-05-02  Tom de Vries  

PR libgomp/85411
* plugin/plugin-nvptx.c (nvptx_exec): Move parsing of
GOMP_OPENACC_DIM ...
* env.c (parse_gomp_openacc_dim): ... here.  New function.
(initialize_env): Call parse_gomp_openacc_dim.
(goacc_default_dims): Define.
* libgomp.h (goacc_default_dims): Declare.
* oacc-plugin.c (GOMP_PLUGIN_acc_default_dim): New function.
* oacc-plugin.h (GOMP_PLUGIN_acc_default_dim): Declare.
* libgomp.map: New version "GOMP_PLUGIN_1.2". Add
GOMP_PLUGIN_acc_default_dim.
* testsuite/libgomp.oacc-c-c++-common/loop-default-runtime.c: New test.
* testsuite/libgomp.oacc-c-c++-common/loop-default.h: New test.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-default-runtime.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-default.h
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/env.c
trunk/libgomp/libgomp.h
trunk/libgomp/libgomp.map
trunk/libgomp/oacc-plugin.c
trunk/libgomp/oacc-plugin.h
trunk/libgomp/plugin/plugin-nvptx.c

[Bug libgomp/82428] Builtins for openacc gang/worker/vector id/size

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
Author: vries
Date: Wed May  2 17:53:29 2018
New Revision: 259850

URL: https://gcc.gnu.org/viewcvs?rev=259850=gcc=rev
Log:
[openacc] Add __builtin_goacc_parlevel_{id,size}

2018-05-02  Tom de Vries  

PR libgomp/82428
* builtins.def (DEF_GOACC_BUILTIN_ONLY): Define.
* omp-builtins.def (BUILT_IN_GOACC_PARLEVEL_ID)
(BUILT_IN_GOACC_PARLEVEL_SIZE): New builtin.
* builtins.c (expand_builtin_goacc_parlevel_id_size): New function.
(expand_builtin): Call expand_builtin_goacc_parlevel_id_size.
* doc/extend.texi (Other Builtins): Add __builtin_goacc_parlevel_id and
__builtin_goacc_parlevel_size.

* f95-lang.c (DEF_GOACC_BUILTIN_ONLY): Define.

* c-c++-common/goacc/builtin-goacc-parlevel-id-size-2.c: New test.
* c-c++-common/goacc/builtin-goacc-parlevel-id-size.c: New test.

* testsuite/libgomp.oacc-c-c++-common/gang-static-2.c: Use
__builtin_goacc_parlevel_{id,size}.
* testsuite/libgomp.oacc-c-c++-common/loop-auto-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-dim-default.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-g-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-g-2.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-gwv-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-red-g-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-red-v-2.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-red-w-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-red-w-2.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-red-wv-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-v-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-w-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/loop-wv-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Same.
* testsuite/libgomp.oacc-c-c++-common/routine-g-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/routine-gwv-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/routine-v-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/routine-w-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/routine-wv-1.c: Same.
* testsuite/libgomp.oacc-c-c++-common/routine-wv-2.c: Same.
* testsuite/libgomp.oacc-c-c++-common/tile-1.c: Same.

Added:
trunk/gcc/testsuite/c-c++-common/goacc/builtin-goacc-parlevel-id-size-2.c
trunk/gcc/testsuite/c-c++-common/goacc/builtin-goacc-parlevel-id-size.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/builtins.def
trunk/gcc/doc/extend.texi
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c
trunk/gcc/omp-builtins.def
trunk/gcc/testsuite/ChangeLog
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-static-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-auto-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-dim-default.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-g-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-g-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-gwv-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-g-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-v-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-w-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-w-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-wv-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-v-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-w-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-wv-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-dims.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/routine-g-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/routine-gwv-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/routine-v-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/routine-w-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/routine-wv-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/routine-wv-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/tile-1.c

[Bug c/30552] gcc crashes when compiling examples with GNU statement expressions in VLAs (also involved: nested functions declared K)

[law at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey A. Law  ---
Author: law
Date: Wed May  2 17:22:26 2018
New Revision: 259849

URL: https://gcc.gnu.org/viewcvs?rev=259849=gcc=rev
Log:
PR c/30552
* c-decl.c (old_style_parameter_scope): New function.
* c-parser.c (c_parser_postfix_expression): Check for statement
expressions in old-style function parameter list declarations.
* c-parser.h (old_style_parameter_scope): New extern declaration.

PR c/30552
* gcc.dg/noncompile/pr30552-1.c: New test.
* gcc.dg/noncompile/pr30552-2.c: New test.
* gcc.dg/noncompile/pr30552-3.c: New test.
* gcc.dg/noncompile/pr30552-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/noncompile/pr30552-1.c
trunk/gcc/testsuite/gcc.dg/noncompile/pr30552-2.c
trunk/gcc/testsuite/gcc.dg/noncompile/pr30552-3.c
trunk/gcc/testsuite/gcc.dg/noncompile/pr30552-4.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-parser.h
trunk/gcc/testsuite/ChangeLog

[Bug other/85614] New: Documentation: -fdump-tree should mention "original"

[krblock at computer dot org]

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

Bug ID: 85614
   Summary: Documentation: -fdump-tree should mention "original"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krblock at computer dot org
  Target Milestone: ---

In the -fdump-tree option a "switch" is specified to select when you want the
dump. To determine the "switch", it suggests "-fdump-passes" be used. However,
this does not list "original" which is also a possible choice. This should be
explicitly listed in the documentation. Not sure if there are other not listed
"switches". Also the term "switch" is odd. "pass" might be a more intuitive
name.

https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html

-fdump-tree-all
-fdump-tree-switch
-fdump-tree-switch-options
-fdump-tree-switch-options=filename

...

1. Invoke GCC with -fdump-passes and in the stderr output look for a code that
corresponds to the pass you are interested in. For example, the codes
tree-evrp, tree-vrp1, and tree-vrp2 correspond to the three Value Range
Propagation passes. The number at the end distinguishes distinct invocations of
the same pass.

[Bug fortran/85507] [6/7/8/9 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2258

[zbeekman at gmail dot com]

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

--- Comment #14 from Zaak  ---
Damn, it would have been nice if this patch made it in.

[Bug libstdc++/83860] valarray replacement type breaks with auto and more than one operation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||8.1.0

--- Comment #10 from Jonathan Wakely  ---
The original testcase works on trunk, although it's still possible to create
dangling references from valarray expressions by using `auto` (especially in
functions returning `auto` or `decltype(auto)` which end up returning an
expression template referring to a local valarray on the function's stack).

[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #11 from Jonathan Wakely  ---
The original testcase works on trunk, although it's still possible to create
dangling references from valarray expressions by using `auto` (especially in
functions returning `auto` or `decltype(auto)` which end up returning an
expression template referring to a local valarray on the function's stack).

[Bug libstdc++/83860] valarray replacement type breaks with auto and more than one operation

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Wed May  2 16:41:46 2018
New Revision: 259844

URL: https://gcc.gnu.org/viewcvs?rev=259844=gcc=rev
Log:
PR libstdc++/83860 avoid dangling references in valarray closure types

Store nested closures by value not by reference, to prevent holding
invalid references to temporaries that have been destroyed. This
changes the layout of the closure types, so change their linkage names,
but moving them to a different namespace.

PR libstdc++/57997
PR libstdc++/83860
* include/bits/gslice_array.h (gslice_array): Define default
constructor as deleted, as per C++11 standard.
* include/bits/mask_array.h (mask_array): Likewise.
* include/bits/slice_array.h (slice_array): Likewise.
* include/bits/valarray_after.h (_GBase, _GClos, _IBase, _IClos): Move
to namespace __detail.
(_GBase::_M_expr, _IBase::_M_expr): Use _ValArrayRef for type of data
members.
* include/bits/valarray_before.h (_ValArrayRef): New helper for type
of data members in closure objects.
(_FunBase, _ValFunClos, _RefFunClos, _UnBase, _UnClos, _BinBase)
(_BinBase2, _BinBase1, _BinClos, _SBase, _SClos): Move to namespace
__detail.
(_FunBase::_M_expr, _UnBase::_M_expr, _BinBase::_M_expr1)
(_BinBase::_M_expr2, _BinBase2::_M_expr1, _BinBase1::_M_expr2)
(_SBase::_M_expr): Use _ValArrayRef for type of data members.
* include/std/valarray (_UnClos, _BinClos, _SClos, _GClos, _IClos)
(_ValFunClos, _RefFunClos): Move to namespace __detail and add
using-declarations to namespace std.
* testsuite/26_numerics/valarray/83860.cc: New.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/valarray/83860.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/gslice_array.h
trunk/libstdc++-v3/include/bits/mask_array.h
trunk/libstdc++-v3/include/bits/slice_array.h
trunk/libstdc++-v3/include/bits/valarray_after.h
trunk/libstdc++-v3/include/bits/valarray_before.h
trunk/libstdc++-v3/include/std/valarray

[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Wed May  2 16:41:46 2018
New Revision: 259844

URL: https://gcc.gnu.org/viewcvs?rev=259844=gcc=rev
Log:
PR libstdc++/83860 avoid dangling references in valarray closure types

Store nested closures by value not by reference, to prevent holding
invalid references to temporaries that have been destroyed. This
changes the layout of the closure types, so change their linkage names,
but moving them to a different namespace.

PR libstdc++/57997
PR libstdc++/83860
* include/bits/gslice_array.h (gslice_array): Define default
constructor as deleted, as per C++11 standard.
* include/bits/mask_array.h (mask_array): Likewise.
* include/bits/slice_array.h (slice_array): Likewise.
* include/bits/valarray_after.h (_GBase, _GClos, _IBase, _IClos): Move
to namespace __detail.
(_GBase::_M_expr, _IBase::_M_expr): Use _ValArrayRef for type of data
members.
* include/bits/valarray_before.h (_ValArrayRef): New helper for type
of data members in closure objects.
(_FunBase, _ValFunClos, _RefFunClos, _UnBase, _UnClos, _BinBase)
(_BinBase2, _BinBase1, _BinClos, _SBase, _SClos): Move to namespace
__detail.
(_FunBase::_M_expr, _UnBase::_M_expr, _BinBase::_M_expr1)
(_BinBase::_M_expr2, _BinBase2::_M_expr1, _BinBase1::_M_expr2)
(_SBase::_M_expr): Use _ValArrayRef for type of data members.
* include/std/valarray (_UnClos, _BinClos, _SClos, _GClos, _IClos)
(_ValFunClos, _RefFunClos): Move to namespace __detail and add
using-declarations to namespace std.
* testsuite/26_numerics/valarray/83860.cc: New.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/valarray/83860.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/gslice_array.h
trunk/libstdc++-v3/include/bits/mask_array.h
trunk/libstdc++-v3/include/bits/slice_array.h
trunk/libstdc++-v3/include/bits/valarray_after.h
trunk/libstdc++-v3/include/bits/valarray_before.h
trunk/libstdc++-v3/include/std/valarray

[Bug libstdc++/70080] gslice_array's copy constructor doesn't work correctly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-02
 Ever confirmed|0   |1

[Bug libstdc++/69608] strsteambuf copy ctor and assignment inaccessible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
I've made strstreams movable for GCC 9 and requested a new LWG issue.

[Bug tree-optimization/85605] Potentially missing optimization under x64 and ARM: seemingly unnecessary branch in codegen

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|x86_64-*-*, i?86-*-*, arm   |x86_64-*-*, i?86-*-*, arm,
   ||aarch64*-*-*
  Component|rtl-optimization|tree-optimization

--- Comment #2 from Andrew Pinski  ---
There might be a duplicate of this bug already but:
CMP1 ? true : CMP2;

Can be transformed into:
CMP1 | CMP2

This needs PHIOPT to do the optimization, either via match or manually.

[Bug libstdc++/69608] strsteambuf copy ctor and assignment inaccessible

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Wed May  2 16:25:44 2018
New Revision: 259842

URL: https://gcc.gnu.org/viewcvs?rev=259842=gcc=rev
Log:
PR libstdc++/69608 Move semantics for strstreambuf

In libstdc++ the deprecated char* streams are non-copyable, as was
required pre-C++11.

Since C++11 the standard implies that those streams should be copyable,
but doesn't specify the effects of copying them. This is surely a
defect, so for consistency with other implementations this change makes
them movable, but not copyable.

PR libstdc++/69608
* include/backward/strstream (strstreambuf): Define move constructor
and move assignment operator.
(istrstream, ostrstream, strstream): Likewise.
* testsuite/backward/strstream_move.cc: New.

Added:
trunk/libstdc++-v3/testsuite/backward/strstream_move.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/backward/strstream

[Bug target/85613] New: [8/9 regression] FAIL: gfortran.dg/pr51434.f90 -O1 execution test

[sch...@linux-m68k.org]

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

Bug ID: 85613
   Summary: [8/9 regression] FAIL: gfortran.dg/pr51434.f90   -O1
execution test
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: powerpc*-*-*

The test crashes at -O1, but not on other opt levels.  The offset from
.LANCHOR0 is miscalculated for the A.1.2066 object, at -O1 there is another
object (c.2059) placed before it.

-O2 vs -O1:
.globl __foo_MOD_s
.globl __foo_MOD___vtab_foo_A
.globl __foo_MOD___def_init_foo_A
-   .setc.2059,__foo_MOD___def_init_foo_A
.section.rodata
.align 2
.set.LANCHOR0,. + 0
@@ -86,6 +81,28 @@ options.3.2073:
.long   1
.long   0
.long   31
+   .type   c.2059, @object
+   .size   c.2059, 12
+c.2059:
+   .long   5
+   .ascii  "a"
+   .ascii  "b"
+   .ascii  "c"
+   .ascii  "d"
+   .ascii  "e"
+   .ascii  " "
+   .ascii  " "
+   .ascii  " "
+   .ascii  " "
+   .ascii  " "
+   .ascii  " "
+   .ascii  " "
+   .ascii  " "
+   .ascii  " "
+   .ascii  " "
+   .ascii  " "
+   .ascii  " "
+   .ascii  " "
.type   A.1.2066, @object
.size   A.1.2066, 20
 A.1.2066:

[Bug c/79586] missing -Wdeprecated depending on position of attribute

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80400,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80398,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82200

--- Comment #2 from Eric Gallager  ---
See bug 80400, bug 80398, and bug 82200 for more bugs about misplaced
attributes.

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

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

--- Comment #9 from Tim Shen  ---
Fixed in GCC 8.1.

[Bug fortran/78798] [cleanup] some int-valued functions should be bool

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
It'd be cool if GCC had a warning flag ("-Wsuggest-bool" perhaps?) to help find
cases like these.

[Bug target/85593] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #3 from Ramana Radhakrishnan  ---
Changing the testcase to indicate the clobbered register r3 makes the test pass
but that is wrong in a naked function. Extended inline assembler *cannot* be
used within a naked function because you inadvertently could end up requiring a
stack slot and therefore cause the function to require a prologue and epilogue
which is exactly contrary to what we want with the naked function ! 

I *think* the problem really is the fact that you have ipa-ra coming along and
deciding that r3 isn't used at all in the naked function . You can see the
problem disappear with -fno-ipa-ra but that is not a workaround I would
recommend using in your general C flags , because you are using a hammer
disabling a nice optimization to make something like the example "work". 

Thus I think what you want is to get rid of naked functions in general and
write the whole thing in assembler and stop faffing about with naked functions
in general. IIRC there is a hook for ipa-ra that says what registers can be
clobbered : can't find it immediately. I suppose for naked functions it is
*all* registers.



regards
Ramana

[Bug c++/85612] New: ADL lookup with parameter pack and defaulted argument not considered ambiguous

[barry.revzin at gmail dot com]

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

Bug ID: 85612
   Summary: ADL lookup with parameter pack and defaulted argument
not considered ambiguous
   Product: gcc
   Version: 7.2.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: ---

Hopefully-minimal example:

#ifdef WORKS
template 
R foo(T&&...) {
return 0;
}
#else
template 
decltype(auto) foo(T&&...) {
return 0;
}
#endif

namespace N { 
struct X { };

template 
void foo(T&&...) = delete;
}

int main() {
foo(N::X{});
}

gcc accepts this program with -DWORKS, but this should be ambiguous between
::foo and N::foo. It correctly rejects without -DWORKS. clang rejects in both
cases. 

The parameter pack is significant somehow too, if the parameter list were just
T&& instead of T&&..., gcc rejects as ambiguous with -DWORKS too.

[Bug fortran/85599] invalid optimization: function not always evaluated in logical expression

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Wed, May 02, 2018 at 08:53:27AM +, janus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
> 
> --- Comment #4 from janus at gcc dot gnu.org ---
> (In reply to kargl from comment #1)
> > The behavior may not be buggy, and it's best not to depend
> > on side-effects.  From F2018,
> > 
> > 10.1.5.4.2 Evaluation of logical intrinsic operations
> > 
> >   Once the interpretation of a logical intrinsic operation is
> >   established, the processor may evaluate any other expression
> >   that is logically equivalent, provided that the integrity of
> >   parentheses in any expression is not violated.
> > 
> >   Two expressions of type logical are logically equivalent
> >   if their values are equal for all possible values of their
> >   primaries.
> > 
> 
> Thanks for the standard quote, Steve. It certainly goes in
> the right direction, but I feel like it's not quite to the point.
> 
> Some other (possibly) relevant passages I found in the 2008 standard:
> 
> *
> 7.1.7 Evaluation of operands
> 1 It is not necessary for a processor to evaluate all of the operands of an
> expression, or to evaluate entirely each operand, if the value of the
> expression can be determined otherwise.
> *

The above is actually the clause I went looking for, but I was
short on time yesterday.  I think that this is the one along with
the description of evaluation of a logical expression that 
applies.

> That also sounds like optimizing away the function call might be valid, but
> then there is also this one:
> 
> *
> 7.1.4 Evaluation of operations
> 2 The evaluation of a function reference shall neither affect nor be affected
> by the evaluation of any other entity within the statement.
> *

You could be right in that this clause applies.  I, however,
tend to think that this is meant to prevent a side effect 
such as

program foo
   integer i, j
   integer, external :: ping, pong
   common /ah/i
   i = 1
   j = ping() + pong()  ! ping() changes value of i
   print *, pong(), j   ! which effects the output of pong()
   i = 1
   j = pong() + ping()
   print *, pong(), j
end program foo

function ping() result(n)
   integer k
   common /ah/ k
   k = k + 1
   n = 42
end function ping

function pong() result(n)
   common /ah/ m
   if (m > 0) then
  n = m
   else
  n = 0
   end if
end function pong

Yes, it is admittedly a contrived example.  It is also possible
for a compiler to replace

j = 0 * ping() + pong()

with simply

j = pong()

where ping() is never evaluated.  I'll note that gfortran currently
will evaluate ping(), but if ping() takes ages to compute it might
be nice to have -ffrontend-optimize remove its evaluation.

> What worries me most is that other compilers choose different implementations.
> Can this kind of code really be processor-dependent?

Yes, that is troublesome.

[Bug tree-optimization/85611] New: Suboptimal code generation for (potentially) redundant atomic loads

[hiraditya at msn dot com]

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

Bug ID: 85611
   Summary: Suboptimal code generation for (potentially) redundant
atomic loads
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

$ cat test.cpp
#include 

std::atomic atomic_var{100};
int somevar;
bool cond;

void run1() {
auto a = atomic_var.load(std::memory_order_relaxed);
auto b = atomic_var.load(std::memory_order_relaxed);
   // Some code using a and b;
}

void run2() {
if (atomic_var.load(std::memory_order_relaxed) == 2 && cond) {
 if (atomic_var.load(std::memory_order_relaxed) * somevar > 3) {
   /*...*/
 }
}
}


$ g++-7 -O3 -std=c++17 -S -o - test.cpp -fno-exceptions

.text
.align 4,0x90
.globl __Z4run1v
__Z4run1v:
LFB339:
movl_atomic_var(%rip), %eax
movl_atomic_var(%rip), %eax
ret
LFE339:
.align 4,0x90
.globl __Z4run2v
__Z4run2v:
LFB340:
movl_atomic_var(%rip), %eax
cmpl$2, %eax
je  L5
L3:
ret
.align 4,0x90
L5:
cmpb$0, _cond(%rip)
je  L3
movl_atomic_var(%rip), %eax
ret

[Bug tree-optimization/85610] New: Unable to optimize away mov followed by compare into a cmpb in case of atomic_load

[hiraditya at msn dot com]

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

Bug ID: 85610
   Summary: Unable to optimize away mov followed by compare into a
cmpb in case of atomic_load
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

$ cat test.cpp

#include 
std::atomic flag_atomic{false};

extern void f1();
extern void f2();

void foo() {
bool b = flag_atomic.load(std::memory_order_relaxed);
if (b == false) {
f1();
} else {
f2();
}   
}


$ g++-7 -O3 -S -o - test.cpp -std=c++14

__Z3foov:
LFB342:
  movzbl  _flag_atomic(%rip), %eax
  testb %al, %al 
  je  L4  
  jmp __Z2f2v
  .align 4,0x90
L4:
  jmp __Z2f1v


We could just use `cmpb $0, _flag_atomic(%rip)` and avoid a register in this
case. When _flag_atomic is a scalar boolean global variable, that's what
happens.

[Bug tree-optimization/85597] [6/7/8 Regression] internal compiler error: in compute_live_loop_exits, at tree-ssa-loop-manip.c:229

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[6/7/8/9 Regression]|[6/7/8 Regression] internal
   |internal compiler error: in |compiler error: in
   |compute_live_loop_exits, at |compute_live_loop_exits, at
   |tree-ssa-loop-manip.c:229   |tree-ssa-loop-manip.c:229
  Known to fail||8.1.0

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/85597] [6/7/8/9 Regression] internal compiler error: in compute_live_loop_exits, at tree-ssa-loop-manip.c:229

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed May  2 14:19:51 2018
New Revision: 259840

URL: https://gcc.gnu.org/viewcvs?rev=259840=gcc=rev
Log:
2018-05-02  Richard Biener  

PR tree-optimization/85597
* tree-vect-stmts.c (vectorizable_operation): For ternary SLP
do not use split vect_get_vec_defs call but call vect_get_slp_defs
directly.

* gcc.dg/vect/pr85597.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr85597.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug lto/85609] lto_check_version should print file name when linking a static lib

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
There's no way to easily dump them since the sections where they are included
are compressed...  We do not know the file name in the archive but only its
byte offset.

There's currently a dumping too in development that should eventually solve
the "print the LTO version of a file" issue.

[Bug fortran/85599] invalid optimization: function not always evaluated in logical expression

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
I also asked for advice on c.l.f.:

https://groups.google.com/forum/#!topic/comp.lang.fortran/fXP1c0u57So

[Bug lto/85609] New: lto_check_version should print file name when linking a static lib

[cand at gmx dot com]

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

Bug ID: 85609
   Summary: lto_check_version should print file name when linking
a static lib
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cand at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The current error message is not very helpful when linking against a static lib
instead of object files:
"lto1: fatal error: bytecode stream in file 'libwebkitfltk.a' generated with
LTO version 4.0 instead of the expected 6.0"

In this case, the lib has 3268 .o files. If the file is a lib, the error
message should include the .o file's filename too.

--
Is there any way to examine a file's LTO version? I tried dumping sections with
readelf, but nothing jumped at me.

[Bug libstdc++/69388] Allow functexcept.cc definitions to be replaced

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|8.2 |---

[Bug testsuite/85106] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #12 from Tom de Vries  ---
patches with test-cases committed, marking resolved-fixed.

[Bug libstdc++/69608] strsteambuf copy ctor and assignment inaccessible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-02
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Martin Sebor from comment #0)
> As far as I can see, the C++ standard doesn't prevent the copying of
> strstreambuf objects.  With the resolution of issue 421 these copies should
> have (almost) well-defined semantics.  But the following program fails to
> compile with the latest libstdc++.
> 
> That said, I'm not sure it's a good idea for the standard to require
> implementations to accept the program.  If it did, it seems that the two
> copies would share the same underlying character buffer (courtesy of issue
> 421).  Accessing the buffer in the copy would be undefined after the copied
> strstreambuf object was destroyed.

Simply removing the private copy constructor and copy assignment operator
allows the program to compile, but with undefined behaviour:

==16384== Memcheck, a memory error detector
==16384== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16384== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==16384== Command: ./a.out
==16384== 
==16384== Invalid free() / delete / delete[] / realloc()
==16384==at 0x4C2F6B8: operator delete[](void*) (vg_replace_malloc.c:621)
==16384==by 0x4EE0D08: std::strstreambuf::~strstreambuf()
(strstream.cc:117)
==16384==by 0x400773: main (ss.cc:5)
==16384==  Address 0x5ad0cd0 is 0 bytes inside a block of size 32 free'd
==16384==at 0x4C2F6B8: operator delete[](void*) (vg_replace_malloc.c:621)
==16384==by 0x4EE0D08: std::strstreambuf::~strstreambuf()
(strstream.cc:117)
==16384==by 0x400764: main (ss.cc:6)
==16384==  Block was alloc'd at
==16384==at 0x4C2E8B7: operator new[](unsigned long)
(vg_replace_malloc.c:423)
==16384==by 0x4EE0C5C: std::strstreambuf::strstreambuf(long)
(strstream.cc:61)
==16384==by 0x400742: main (ss.cc:6)
==16384== 
==16384== 
==16384== HEAP SUMMARY:
==16384== in use at exit: 16 bytes in 1 blocks
==16384==   total heap usage: 3 allocs, 3 frees, 72,752 bytes allocated
==16384== 
==16384== LEAK SUMMARY:
==16384==definitely lost: 16 bytes in 1 blocks
==16384==indirectly lost: 0 bytes in 0 blocks
==16384==  possibly lost: 0 bytes in 0 blocks
==16384==still reachable: 0 bytes in 0 blocks
==16384== suppressed: 0 bytes in 0 blocks
==16384== Rerun with --leak-check=full to see details of leaked memory
==16384== 
==16384== For counts of detected and suppressed errors, rerun with: -v
==16384== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)



> If this hasn't been discussed in LWG yet
> it might be worth bringing it up.

I'll do so.

> strstreambuf may be deprecated but the
> same concern applies to similar user-defined classes that publicly derive
> from basic_streambuf and expose an accsible copy ctor or assignment operator
> of their own.

User-defined classes are responsible for defining their own copy operations
correctly. The issue as I see it is that strstreambuf fails to do that. If
user-defined classes fail to do that it's the user's problem.

[Bug testsuite/85106] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries  ---
Author: vries
Date: Wed May  2 12:16:32 2018
New Revision: 259838

URL: https://gcc.gnu.org/viewcvs?rev=259838=gcc=rev
Log:
[testsuite] Add scan-ltrans-tree-dump

2018-05-02  Tom de Vries  

PR testsuite/85106
* gcc.dg/ipa/ipa-icf-38.c: Use scan-ltrans-tree-dump.
* lib/scanltranstree.exp: New file.
* lib/target-supports.exp (scan-ltrans-tree-dump_required_options)
(scan-ltrans-tree-dump-times_required_options)
(scan-ltrans-tree-dump-not_required_options)
(scan-ltrans-tree-dump-dem_required_options)
(scan-ltrans-tree-dump-dem-not_required_options): New proc.
* lib/gcc-dg.exp: Include scanltranstree.exp.

* testsuite/lib/libatomic.exp: Include scanltranstree.exp.

* testsuite/lib/libgomp.exp: Include scanltranstree.exp.

* testsuite/lib/libitm.exp: Include scanltranstree.exp.

* testsuite/lib/libvtv.exp: Include scanltranstree.exp.

* doc/sourcebuild.texi (Commands for use in dg-final, Scan optimization
dump files): Add ltrans-tree.

Added:
trunk/gcc/testsuite/lib/scanltranstree.exp
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
trunk/gcc/testsuite/lib/gcc-dg.exp
trunk/gcc/testsuite/lib/target-supports.exp
trunk/libatomic/ChangeLog
trunk/libatomic/testsuite/lib/libatomic.exp
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/lib/libgomp.exp
trunk/libitm/ChangeLog
trunk/libitm/testsuite/lib/libitm.exp
trunk/libvtv/ChangeLog
trunk/libvtv/testsuite/lib/libvtv.exp

[Bug testsuite/85106] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries  ---
Author: vries
Date: Wed May  2 12:16:15 2018
New Revision: 259837

URL: https://gcc.gnu.org/viewcvs?rev=259837=gcc=rev
Log:
[testsuite] Add scan-wpa-ipa-dump

2018-05-02  Tom de Vries  

PR testsuite/85106
* gcc.dg/ipa/ipa-icf-38.c: New test.
* gcc.dg/ipa/ipa-icf-38a.c: New test.
* lib/scandump.exp (dump-base): New proc.
(scan-dump, scan-dump-times, scan-dump-not, scan-dump-dem)
(scan-dump-dem-not): Add and handle parameter for suffix of the dump
base.
* lib/scanipa.exp: Add "" argument to scan-dump calls.
* lib/scanlang.exp: Same.
* lib/scanrtl.exp: Same.
* lib/scantree.exp: Same.
* lib/scanwpaipa.exp: New file.
* lib/gcc-dg.exp: Include scanwpaipa.exp.

* testsuite/lib/libatomic.exp: Include scanwpaipa.exp.

* testsuite/lib/libgomp.exp: Include scanwpaipa.exp.

* testsuite/lib/libitm.exp: Include scanwpaipa.exp.

* testsuite/lib/libvtv.exp: Include scanwpaipa.exp.

* doc/sourcebuild.texi (Commands for use in dg-final, Scan optimization
dump files): Add wpa-ipa.

Added:
trunk/gcc/testsuite/gcc.dg/ipa/ipa-icf-38.c
trunk/gcc/testsuite/gcc.dg/ipa/ipa-icf-38a.c
trunk/gcc/testsuite/lib/scanwpaipa.exp
  - copied, changed from r259833, trunk/gcc/testsuite/lib/scanipa.exp
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/gcc-dg.exp
trunk/gcc/testsuite/lib/scandump.exp
trunk/gcc/testsuite/lib/scanipa.exp
trunk/gcc/testsuite/lib/scanlang.exp
trunk/gcc/testsuite/lib/scanrtl.exp
trunk/gcc/testsuite/lib/scantree.exp
trunk/libatomic/ChangeLog
trunk/libatomic/testsuite/lib/libatomic.exp
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/lib/libgomp.exp
trunk/libitm/ChangeLog
trunk/libitm/testsuite/lib/libitm.exp
trunk/libvtv/ChangeLog
trunk/libvtv/testsuite/lib/libvtv.exp

[Bug fortran/84640] gcc/fortran/simplify.c:2587:9: runtime error: pointer index expression with base 0x0000090de160 overflowed to 0xffffffffc0632960

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from David Binderman  ---
I am seeing something similar when compiling the fortran test suite:

./../trunk/gcc/fortran/simplify.c:2174:9: runtime error: pointer index
expression with base 0x0b26c478 overflowed to 0xfffc05abee0f7cb8

Source code file gfortran.dg/array_simplify_1.f90 seems to demonstrate
the problem.

[Bug middle-end/85586] [8/9 Regression] Optimizer produces different result on -O2 and -O3

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #7 from Christophe Lyon  ---
Hi Richard,
The new testcase fails on armeb when gcc is configured --with-fpu neon-fp16:
FAIL: gcc.dg/vect/pr85586.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"LOOP VECTORIZED" 1
FAIL: gcc.dg/vect/pr85586.c scan-tree-dump-times vect "LOOP VECTORIZED" 1


GCC configure flags:
--target armeb-none-linux-gnueabihf
--with-mode arm
--with-cpu cortex-a9
--with-fpu neon-fp16


Using vfpv3-d16-fp16 as default fpu skips that part of the test.

[Bug libstdc++/80676] [DR 2995] basic_stringbuf does not use initial capacity of SSO string

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|8.2 |---

[Bug fortran/85599] invalid optimization: function not always evaluated in logical expression

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> What worries me most is that other compilers choose different
> implementations. Can this kind of code really be processor-dependent?

Most other compilers that I tried actually behave different than gfortran,
calling 'check' twice in the test case of comment #0 (ifort, flang, PGI).

The only compiler that behaves like gfortran and optimizes the second call out
is the Oracle compiler (sunf95).

All gfortran versions since at least 4.4 behave in the same way.

[Bug c++/85604] Default template arguments in friend class template declarations should not be allowed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-02
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I thought this was a duplicate of an existing bug but I can only find PR 59480

[Bug fortran/85599] invalid optimization: function not always evaluated in logical expression

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
Another variant, this time with the (non-std) intrinsic function AND:


program lazy

   logical :: flag

   flag = .false.
   flag = AND(check(), flag)
   flag = AND(flag, check())

contains

   logical function check()
  integer, save :: i = 1
  print *, "check", i
  i = i + 1
  check = .true.
   end function

end


This calls 'check' twice, as I would expect, and -fdump-tree-original shows
that it is translated to this pseudo C code:

  flag = check () & flag;
  flag = check () & flag;

While the original test case translates to:

  flag = check () && flag;
  flag = flag && check ();

Changing the operand order (as done in the first case) does not matter here.
Obviously the crucial difference is the use of & vs &&.

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||gcc-bugs at marehr dot 
dialup.fu-b
   ||erlin.de

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

[Bug libstdc++/80165] Constexpr tuple of variant doesn't work

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #7 from Jonathan Wakely  ---
This was fixed by r249706

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

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Tim, can this be closed as fixed in GCC 8.1? Is there more to do?

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|ASSIGNED|NEW
  Component|tree-optimization   |fortran
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #5 from Richard Biener  ---
FE issue I believe.

[Bug libstdc++/80165] Constexpr tuple of variant doesn't work

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|8.2 |8.0

--- Comment #6 from Jonathan Wakely  ---
This is fixed in GCC 8.1 and not going to be backported to gcc-7-branch.

[Bug c/85608] ubsan in cse.c:2194

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Problem seems to occur sometime before revision 258870.

[Bug c/85608] New: ubsan in cse.c:2194

[dcb314 at hotmail dot com]

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

Bug ID: 85608
   Summary: ubsan in cse.c:2194
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

From the gcc testsuite, the file gcc.dg/pr82596.c, when compiled
by a recent ubsan version of trunk gcc, does this:

$ ~/gcc/results.259742.ubsan/bin/gcc -c -O2 -w ./gcc.dg/pr82596.c
../../trunk/gcc/cse.c:2194:34: runtime error: signed integer overflow: 1 -
-9223372036854775807 cannot be represented in type 'long int'
$

case.c:2194 is this line:

   360 kenner   offset = (get_integer_term (x) - get_integer_term
(p->exp));

I'll have my usual go at finding a range of revisions and a short test case.

[Bug target/85519] [nvptx, openacc, openmp, testsuite] Recursive tests may fail due to thread stack limit

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #4)
> Committed to trunk.
> 
> Approved for 8.2. [ 8.1 release is targeted for Wednesday, May 2nd. ]

Backported to gcc-8-branch after 8.1 release.

Marking resolved-fixed.

[Bug target/85519] [nvptx, openacc, openmp, testsuite] Recursive tests may fail due to thread stack limit

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
Author: vries
Date: Wed May  2 10:55:07 2018
New Revision: 259834

URL: https://gcc.gnu.org/viewcvs?rev=259834=gcc=rev
Log:
backport "[nvptx, libgomp, testsuite] Reduce recursion depth in
declare_target-{1,2}.f90"

2018-05-02  Tom de Vries  

backport from trunk:
2018-04-26  Tom de Vries  

PR target/85519
* testsuite/libgomp.fortran/examples-4/declare_target-1.f90: Reduce
recursion depth from 25 to 23.
* testsuite/libgomp.fortran/examples-4/declare_target-2.f90: Same.

Modified:
branches/gcc-8-branch/libgomp/ChangeLog
   
branches/gcc-8-branch/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90
   
branches/gcc-8-branch/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-2.f90

[Bug libstdc++/69365] LWG DR2367 (constrained pair default constructor)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
The GCC 5 branch has been closed for some time so we missed the chance to
change it.

[Bug libstdc++/71660] [6/7/8/9 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
Summary|[6/7/8/9 regression]|[6/7/8/9 regression]
   |alignment of|alignment of std::atomic<8
   |std::atomic<8/9 byte|byte primitive type> (long
   |primitive type> (long long, |long, double) is wrong on
   |double) is wrong on x86 |x86

--- Comment #20 from Jonathan Wakely  ---
As discussed above, I'm closing this as not-a-bug. The change to std::atomic
alignment was intentional and is necessary. It would be nice to be consistent
with _Atomic but we seem to be in agreement that the C front end should change,
not std::atomic.

[Bug c++/85607] ice in add_type, at ipa-icf.c:1583

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Bug seems to occur between revisions 259747 and 259789.

Code is only a few lines already, so no reduction required.

[Bug c++/85607] New: ice in add_type, at ipa-icf.c:1583

[dcb314 at hotmail dot com]

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

Bug ID: 85607
   Summary: ice in add_type, at ipa-icf.c:1583
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

>From the gcc test suite, the file g++.dg/warn/incomplete1.C, when compiled
with flag -O2 on recent gcc trunk, does this:

during IPA pass: icf
./g++.dg/warn/incomplete1.C:22:1: internal compiler error: in add_type, at
ipa-i
cf.c:1583
 }
 ^
0x7d3202 ipa_icf::sem_item::add_type(tree_node const*, inchash::hash&)
../../trunk/gcc/ipa-icf.c:1583
0x1a4853b ipa_icf::sem_function::hash_stmt(gimple*, inchash::hash&)
../../trunk/gcc/ipa-icf.c:1658
0x1a4853b ipa_icf::sem_function::init()
../../trunk/gcc/ipa-icf.c:1432
0x1a5045d ipa_icf::sem_function::parse(cgraph_node*, bitmap_obstack*)
../../trunk/gcc/ipa-icf.c:1717

I'll have my usual go at finding a range of revisions and a small test case.

[Bug target/85606] New: Assembly file generated for ARM Cortex-M0 should not specify `.arch armv6-m` at all or use `.arch armv6s-m`

[freddie_chopin at op dot pl]

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

Bug ID: 85606
   Summary: Assembly file generated for ARM Cortex-M0 should not
specify `.arch armv6-m` at all or use `.arch armv6s-m`
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---
Target: arm-none-eabi

This issue is inspired by following bug report for GAS -
https://sourceware.org/bugzilla/show_bug.cgi?id=23126

Following test case works perfectly fine for GCC 5, 6 and 7, however it fails
with GCC 8.0.1 20180427:

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

$ cat svc.cpp 
__attribute__ ((naked))
int supervisorCall(int (& function)(int, int, int, int), const int argument1,
const int argument2, const int argument3,
const int argument4)
{
asm volatile
(
"   mov r12, r0 \n"
"   ldr r0, [sp]\n"
"   svc 0   \n"
"   \n"
"   bx  lr  \n"
);

__builtin_unreachable();

// suppress warnings
(void)function;
(void)argument1;
(void)argument2;
(void)argument3;
(void)argument4;
}
$ arm-none-eabi-g++ -c svc.cpp -mcpu=cortex-m0 -save-temps
svc.s: Assembler messages:
svc.s:31: Error: SVC is not permitted on this architecture
$ diff -u svc-7.s svc.s 
--- svc-7.s 2018-05-01 20:14:09.031910734 +0200
+++ svc.s   2018-05-01 20:16:36.751143427 +0200
@@ -12,6 +12,7 @@
.text
.align  1
.global _Z14supervisorCallRFiE
+   .arch armv6-m
.syntax unified
.code   16
.thumb_func
@@ -37,4 +38,4 @@
.cantunwind
.fnend
.size   _Z14supervisorCallRFiE,
.-_Z14supervisorCallRFiE
-   .ident  "GCC: (bleeding-edge-toolchain) 7.3.0"
+   .ident  "GCC: (bleeding-edge-toolchain) 8.0.1 20180427 (prerelease)"
$ cat svc.s 
.cpu cortex-m0
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 6
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file   "svc.cpp"
.text
.align  1
.global _Z14supervisorCallRFiE
.arch armv6-m
.syntax unified
.code   16
.thumb_func
.fpu softvfp
.type   _Z14supervisorCallRFiE, %function
_Z14supervisorCallRFiE:
.fnstart
.LFB0:
@ Naked Function: prologue and epilogue provided by programmer.
@ args = 4, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
.syntax divided
@ 12 "svc.cpp" 1
mov r12, r0 
ldr r0, [sp]
svc 0   

bx  lr  

@ 0 "" 2
.thumb
.syntax unified
.cantunwind
.fnend
.size   _Z14supervisorCallRFiE,
.-_Z14supervisorCallRFiE
.ident  "GCC: (bleeding-edge-toolchain) 8.0.1 20180427 (prerelease)"

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

(svc-7.s is a temp file generated with GCC 7.3.0)

Nick Clifton in his comment
(https://sourceware.org/bugzilla/show_bug.cgi?id=23126#c4) to the mentioned GAS
bug report suggested that GCC 8 should either specify just `.cpu` (behaviour as
in previous versions) or specify `.arch armv6s-m` instead of `.arch armv6-m`.
Personally I think the first option should be more reliable in that case,
however this is just a guess.

[Bug c++/85587] [8/9 Regression] bogus error: ‘F’ was not declared in this scope

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.0 |8.2

--- Comment #3 from Jakub Jelinek  ---
GCC 8.1 has been released.

[Bug libstdc++/79422] Use ACX_BUGURL for error in snprintf_lite.cc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|8.2 |---

[Bug libstdc++/77866] Add SystemTap probe points to libstdc++

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|8.2 |---

[Bug c++/84974] [8/9 Regression] ICE: Segmentation fault (ovl_first()/location_of())

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.0 |8.2

--- Comment #2 from Jakub Jelinek  ---
GCC 8.1 has been released.

[Bug fortran/66366] [OOP] ICE on invalid with non-allocatable CLASS variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.0 |8.2

--- Comment #7 from Jakub Jelinek  ---
GCC 8.1 has been released.

[Bug fortran/80291] [OOP] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:6662

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.0 |8.2

--- Comment #10 from Jakub Jelinek  ---
GCC 8.1 has been released.

[Bug fortran/83999] [8/9 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.0 |8.2

--- Comment #6 from Jakub Jelinek  ---
GCC 8.1 has been released.