[Bug c/86768] gcc wrongly decides that variable is <=1 after "while (x>1 && blah)" construct.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
I can confirm the warning with GCC 8.2 and -O2 -m32 and the smaller test case
below.  GCC 9.0 currently doesn't trigger it due to bug 86631 (it does with
-Walloc-size-larger-than=2GB).

$ cat pr86768.c && gcc -O2 -Wall -S -m32 -fdump-tree-vrp2=/dev/stdout pr86768.c
| grep malloc
int f (int);

void* g (int i)
{
  for ( ; i > 1 && f (i); --i)
if (f (i) == 7)
 return 0;

  unsigned n = i - 2;
  unsigned *p = __builtin_malloc (n * sizeof *p);

  for (unsigned i = 0; i < n; ++i)
p[i] = i;

  return p;
}
  p_21 = __builtin_malloc (_4);
  p_65 = __builtin_malloc (4294967292);
pr86768.c: In function ‘g’:
pr86768.c:10:17: warning: argument 1 value ‘4294967292’ exceeds maximum object
size 2147483647 [-Walloc-size-larger-than=]
   unsigned *p = __builtin_malloc (n * sizeof *p);
 ^~~~
pr86768.c:10:17: note: in a call to built-in allocation function
‘__builtin_malloc’


But I think the warning is actually justified in this case.  Calling
g(1073741825, ...), for example, and the right argv (or the right definition of
f() in the smaller test case above) will set n = 1073741823 and end up calling
malloc (1073741823 * 4) or 4294967292.

To avoid the possibility of calling malloc() with an excessive argument
constrain argc value before computing nr_B2 (ot i and n in the small test
case), e.g., like so:

if (argc < 3 || __PTRDIFF_MAX__ / 4 < argc)
  return 1;

[Bug rtl-optimization/79688] ICE with a RTL test-case and -O1 provided

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> Confirmed that gcc ICEs, although is 'c' really the right component?

(thank you Marek for changing it to rtl-optimization in response to this)

[Bug c++/86769] g++ destroys condition variable in for statement too early

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #1 from Richard Smith  ---
For easy reproduction: https://godbolt.org/g/dfZFxz

This does not appear to be a regression: this example appears to be miscompiled
by every version of GCC back to at least 4.1.

[Bug debug/48886] VTA issues with > word size integers

[aoliva at gcc dot gnu.org]

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

--- Comment #2 from Alexandre Oliva  ---
FWIW, I've just tried the testcase in the description with trunk, with -g alone
and with -O2, and got a full pass on x86_64- and i686-linux-gnu.

[Bug c++/86769] New: g++ destroys condition variable in for statement too early

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 86769
   Summary: g++ destroys condition variable in for statement too
early
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Testcase:

struct X { ~X(); operator bool(); };
void f(X &);
void g() { for (; X x = X(); f(x)); }

GCC miscompiles this by destroying the 'x' variable before the call to 'f(x)'.
Per C++ [stmt.for]p1, the above is equivalent to

while (X x = X()) {
  f(x);
}

So the 'x' variable should be destroyed *after* the third operand of the
for-statement is evaluated, not before.

[Bug target/86763] [8/9 Regression] Wrong code comparing member of copy of a 237 byte object with nontrivial default constructor on x86-64 arch

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||mjambor at suse dot cz

--- Comment #2 from H.J. Lu  ---
This is caused by r255510.

[Bug c++/86761] Code corruption with missing pointer return

[r.j.dejong at student dot utwente.nl]

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

--- Comment #5 from Hans de Jong  ---
(In reply to Marek Polacek from comment #3)
> You can use -fsanitize-undefined-trap-on-error if you don't want to link
> libubsan.

Thanks, this has been very useful. I see the sanitizer doubles the executable
size to perform all the run-time checks, but significantly less with the simple
illegal instruction trap.

(In reply to Jonathan Wakely from comment #4)
> (In reply to Hans de Jong from comment #0)
> > Code runs fine on GCC, despite the warning.
> 
> In C the behaviour of a non-void function that fails to return anything is
> only undefined if the return value is used by the caller.
> 
> > Code runs only on G++ with no optimizations. Unpredictable fatal behaviour
> > occurs on various optimization levels.
> 
> In C++ standard it's undefined behaviour if a non-void function fails to
> return anything, even if the return value is not used by the caller. 
> 
> Because you're compiling C++ the behaviour is undefined. The compiler can
> assume that the function is never called, because if it was called it would
> produce undefined behaviour.
> 
> > hard to track down since the function "setFlags" was nested 3 levels down in
> > the code.
> 
> I don't understand how that can make any difference, the warning tells you
> where the missing return is. That's the location you need to fix.

I understand the discrepancy now that I've been seeing. I'm transitioning a
embedded project from C to C++ actually because the language is more strict, so
it sounds I shot myself in the foot on this one. 

Having said that, I suppose it depends from what direction one is used to
debugging. In my case I expected the compiler to at least evaluate up to the
offending call, and/or execute as many parts around it. But in fact it removed
a whole bunch of code at a top level of the program, which at first was very
confusing. Some of these "changes" do not have to result in crashing results,
but for example the code ends up in a finite for loop that is overflowing, or
while single-stepping I saw that a function call towards the offending piece of
code was redirected to another function.

If you put the warning at face value as a cause then of course it is obvious. I
suppose it's not a compiler bug in the sense that you cannot expect the
compiler to create a correct program given that the input program is not
correct. 

However my report is initiated by the (implicit) hiding of compound statements
and redirection of function calls that I've seen and whether that is desirable,
especially since this seems to be different from the more predictable behaviour
of GCC 7. 

Certainly the sanitizer helps in catching undefined behaviour more explicitly.

[Bug libstdc++/86751] [6/7/8 Regression] Ambiguous operator= overload for std::pair

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[6/7/8/9 Regression]|[6/7/8 Regression]
   |Ambiguous operator= |Ambiguous operator=
   |overload for std::pair |T2>

--- Comment #3 from Jonathan Wakely  ---
Only fixed on trunk so far.

[Bug libstdc++/86751] [6/7/8/9 Regression] Ambiguous operator= overload for std::pair

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 31 22:31:20 2018
New Revision: 263185

URL: https://gcc.gnu.org/viewcvs?rev=263185=gcc=rev
Log:
PR libstdc++/86751 default assignment operators for std::pair

The solution for PR 77537 causes ambiguities due to the extra copy
assignment operator taking a __nonesuch_no_braces parameter. By making
the base class non-assignable we don't need the extra deleted overload
in std::pair. The copy assignment operator will be implicitly deleted
(and the move assignment operator not declared) as needed. Without the
additional user-provided operator in std::pair the ambiguity is avoided.

PR libstdc++/86751
* include/bits/stl_pair.h (__pair_base): New class with deleted copy
assignment operator.
(pair): Derive from __pair_base.
(pair::operator=): Remove deleted overload.
* python/libstdcxx/v6/printers.py (StdPairPrinter): New pretty printer
so that new base class isn't shown in GDB.
* testsuite/20_util/pair/86751.cc: New test.
* testsuite/20_util/pair/ref_assign.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/pair/86751.cc
trunk/libstdc++-v3/testsuite/20_util/pair/ref_assign.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_pair.h
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py

[Bug libstdc++/77537] [6 Regression] pair constructors do not properly SFINAE

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
Author: redi
Date: Tue Jul 31 22:31:20 2018
New Revision: 263185

URL: https://gcc.gnu.org/viewcvs?rev=263185=gcc=rev
Log:
PR libstdc++/86751 default assignment operators for std::pair

The solution for PR 77537 causes ambiguities due to the extra copy
assignment operator taking a __nonesuch_no_braces parameter. By making
the base class non-assignable we don't need the extra deleted overload
in std::pair. The copy assignment operator will be implicitly deleted
(and the move assignment operator not declared) as needed. Without the
additional user-provided operator in std::pair the ambiguity is avoided.

PR libstdc++/86751
* include/bits/stl_pair.h (__pair_base): New class with deleted copy
assignment operator.
(pair): Derive from __pair_base.
(pair::operator=): Remove deleted overload.
* python/libstdcxx/v6/printers.py (StdPairPrinter): New pretty printer
so that new base class isn't shown in GDB.
* testsuite/20_util/pair/86751.cc: New test.
* testsuite/20_util/pair/ref_assign.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/pair/86751.cc
trunk/libstdc++-v3/testsuite/20_util/pair/ref_assign.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_pair.h
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py

[Bug c/86768] New: gcc wrongly decides that variable is <=1 after "while (x>1 && blah)" construct.

[Emmanuel.Thome at inria dot fr]

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

Bug ID: 86768
   Summary: gcc wrongly decides that variable is <=1 after "while
(x>1 && blah)" construct.
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Emmanuel.Thome at inria dot fr
  Target Milestone: ---

Created attachment 44477
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44477=edit
test program (wrong diagnostic emitted with -m32 -O3 only)

I have a construct of the following form (comes from actual code, test case
attached).

// check argc >= 3
while (argc > 1 && argv[1][0] == '-') {
  // do something and then argc--, or maybe call exit()
}
// do code that relies on argc >= 3

As presented, it looks kinda weird, but I could as well make the condition be:

while (argc > 1 && argv[1][0] == '-' && foo(argc))

with foo(argc) being outside the compilation unit. So we could be in a
situation where because of the way foo() acts, the post-condition argc>=3 holds
anyway (and the test argc>1 is pointless).

However, I get the following with -m32 -O3: (note: nr_B2 is argc-2)

localhost $ gcc -m32 -O3  /tmp/t.c -W -Wall -c
/tmp/t.c: In function ‘blah’:
/tmp/t.c:32:10: warning: argument 1 value ‘4294967292’ exceeds maximum object
size 2147483647 [-Walloc-size-larger-than=]
 B2 = malloc(nr_B2 * sizeof(unsigned long));
  ^
In file included from /tmp/t.c:2:
/usr/include/stdlib.h:539:14: note: in a call to allocation function ‘malloc’
declared here
 extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
  ^~

Meaning that gcc has decided that the post-condition argc==1 holds after the
while loop. I think that this is an incorrect guess.

[Bug c++/86767] continue statements in constexpr functions causes unbounded looping

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-31
 Ever confirmed|0   |1

[Bug c++/86767] New: continue statements in constexpr functions causes unbounded looping

[syang0 at cs dot stanford.edu]

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

Bug ID: 86767
   Summary: continue statements in constexpr functions causes
unbounded looping
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syang0 at cs dot stanford.edu
  Target Milestone: ---

Created attachment 44476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44476=edit
main.cc

The constexpr function below fails to evaluate at compile-time and causes
unbounded looping on the inner for-loop, despite it having a very well defined
bound [0, 10).

The cause seems to be related to the "continue" statement in the outer for loop
of the constexpr function. If I remove the "continue" completely, the code
compiles fine. If I remove the constexpr requirement for "num" variable in
main() (which stores the return value), it compiles and runs fine without
hanging.

This problem reproduces in g++ versions 8.2, 8.1, 7.3, 7.2, 7.1, 6.3, and 5.5
and was compiled with the command 'g++ --std=c++17 main.cc'


constexpr int
sampleFn()
{
for (int i = 0; i < 10; ++i) {
continue;

// Should never run and is well bounded, but compiler hangs here
for (int j = 0; j < 10; ++j ) {}
}

return 10;
}

void test()
{
// Removing 'constexpr' allows compilation to proceed
constexpr int num = sampleFn();
}

[Bug testsuite/86766] New: new test case c-c++-common/spec-barrier-1.c introduced in r263168 fails

[seurer at gcc dot gnu.org]

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

Bug ID: 86766
   Summary: new test case c-c++-common/spec-barrier-1.c introduced
in r263168 fails
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make -k check-gcc RUNTESTFLAGS=dg.exp=c-c++-common/spec-barrier-1.c

# of expected passes1
# of expected passes3
# of unexpected failures1
# of unexpected failures3
FAIL: c-c++-common/spec-barrier-1.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/spec-barrier-1.c  -std=gnu++98 (test for excess errors)
FAIL: c-c++-common/spec-barrier-1.c  -std=gnu++11 (test for excess errors)
FAIL: c-c++-common/spec-barrier-1.c  -std=gnu++14 (test for excess errors)


spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk-bootstrap/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-trunk-bootstrap/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk-bootstrap/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk-bootstrap/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk-bootstrap/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=gnu++11 -O
-L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/./libitm/.libs
-lm -o ./spec-barrier-1.exe
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:
In function 'int main()':
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:21:42:
warning: this target does not define a speculation barrier; your program will
still execute correctly, but incorrect speculation may not be be restricted
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:23:42:
warning: this target does not define a speculation barrier; your program will
still execute correctly, but incorrect speculation may not be be restricted
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:25:42:
warning: this target does not define a speculation barrier; your program will
still execute correctly, but incorrect speculation may not be be restricted
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:27:42:
warning: this target does not define a speculation barrier; your program will
still execute correctly, but incorrect speculation may not be be restricted
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:29:42:
warning: this target does not define a speculation barrier; your program will
still execute correctly, but incorrect speculation may not be be restricted
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:31:42:
warning: this target does not define a speculation barrier; your program will
still execute correctly, but incorrect speculation may not be be restricted
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:34:42:
warning: this target does not define a speculation barrier; your program will
still execute correctly, but incorrect speculation may not be be restricted
FAIL: c-c++-common/spec-barrier-1.c  -std=gnu++11 (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:21:42:
warning: this target does not define a speculation barrier; your program will
still execute correctly, but incorrect speculation may not be be restricted
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:23:42:
warning: this target does not define a speculation barrier; your program will
still execute correctly, but incorrect speculation may not be be restricted
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:25:42:
warning: this target does not define a speculation barrier; your program will
still execute correctly, but incorrect speculation may not be be restricted
/home/seurer/gcc/gcc-trunk-bootstrap/gcc/testsuite/c-c++-common/spec-barrier-1.c:27:42:
warning: this target does not define a 

[Bug libstdc++/59253] Python pretty printer should be improved for unique_ptr, shared_ptr and map

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Is it possible you were using a really old version of GDB that doesn't
understand the display hint?

def display_hint (self):
return 'map'

That causes GDB to display:

$1 = std::map with 3 elements = {["bar"] = 2, ["baz"] = 3, ["foo"] = 1}

instead of:

$1 = std::map with 3 elements = {[0] = "bar", [1] = 2, [2] = "baz", [3] = 3,
[4] = "foo", [5] = 1}

[Bug target/86763] [8/9 Regression] Wrong code comparing member of copy of a 237 byte object with nontrivial default constructor on x86-64 arch

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-31
Summary|Wrong code comparing member |[8/9 Regression] Wrong code
   |of copy of a 237 byte   |comparing member of copy of
   |object with nontrivial  |a 237 byte object with
   |default constructor on  |nontrivial default
   |x86-64 arch |constructor on x86-64 arch
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
gimple is the same for -O vs -O2, so the issue is either RTL or target.

[Bug libstdc++/59253] Python pretty printer should be improved for unique_ptr, shared_ptr and map

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-07-31
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
(In reply to Léo Terziman from comment #0)
> Moreover, in std::map, the keys and
> values are mixed together in the same list instead of producing a list of
> pairs with 'first' and 'second' attributes.

I don't know what you mean by "mixed together in the same list", they are
printed as [key] = value, [key] = value, [key] = value e.g.

$1 = std::map with 3 elements = {["bar"] = 2, ["baz"] = 3, ["foo"] = 1}


With your patch I get:

$1 = std::map with 3 elements = {[{first = "bar", second = 2}] = {first =
"baz", second = 3}, [{first = "foo", second = 1}] = }

This is not an improvement!


The smart pointer printers have been improved for gcc-8, do you still think
something needs to be changed?

[Bug c++/86761] Code corruption with missing pointer return

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Hans de Jong from comment #0)
> Code runs fine on GCC, despite the warning.

In C the behaviour of a non-void function that fails to return anything is only
undefined if the return value is used by the caller.

> Code runs only on G++ with no optimizations. Unpredictable fatal behaviour
> occurs on various optimization levels.

In C++ standard it's undefined behaviour if a non-void function fails to return
anything, even if the return value is not used by the caller. 

Because you're compiling C++ the behaviour is undefined. The compiler can
assume that the function is never called, because if it was called it would
produce undefined behaviour.

> hard to track down since the function "setFlags" was nested 3 levels down in
> the code.

I don't understand how that can make any difference, the warning tells you
where the missing return is. That's the location you need to fix.

[Bug c/86765] New: invalid -Wmisleading-indentation for double macro expansion with pragmas

[ndesaulniers at google dot com]

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

Bug ID: 86765
   Summary: invalid -Wmisleading-indentation for double macro
expansion with pragmas
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ndesaulniers at google dot com
  Target Milestone: ---

Developing a patch for the Linux kernel, I hit a -Wmisleading-indentation
warning for a particular configuration in gcc 6, 7, and 8.

This is the paired down test case: https://godbolt.org/g/b5dsqH

Looking at the output, the warning is technically correct (puts() was called
unconditionally), but I don't think the compiled code is.  Compared to clang,
clang compiles the conditional check (as expected), but gcc does not.

The kernel patch is trying to add compiler specific pragma's to ignore
clang-7's -Wreturn-stack-address.  We could be better about not emitted
_Pragma's for push/pop if we're not clang, but this still seems like a
miscompilation from gcc to me.

Is there a special rule about GNU statement expressions [0] that I'm missing?

[0] https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

[Bug tree-optimization/86764] New: missing -Wstringop-truncation writing to the last array member

[msebor at gcc dot gnu.org]

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

Bug ID: 86764
   Summary: missing -Wstringop-truncation writing to the last
array member
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As reported in https://lkml.org/lkml/2018/7/30/605, GCC fails to issue
-Wstringop-truncation in the last call to strncpy, yet it issues a
-Wstringop-overflow for the same call when the size is increased by one.  Both
warnings should be issued consistently.

$ cat c.c && gcc -O2 -S -Wall c.c
#include 

struct logical_input {
union {
struct {/* valid when type == INPUT_TYPE_KBD */
/* strings can be non null-terminated */
char press_str[sizeof(void *) + sizeof(int)] /*
__attribute__((nonstring)) to tell gcc this is alright */;
char repeat_str[sizeof(void *) + sizeof(int)];
char release_str[sizeof(void *) + sizeof(int)];
} kbd;
} u;
};

void panel_bind_key(struct logical_input *key, const char *press,
 const char *repeat,
 const char *release)
{
strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
strncpy(key->u.kbd.release_str, release, sizeof(key->u.kbd.release_str));
}

void foo (struct logical_input *key, const char *press,
  const char *repeat,
  const char *release)
{
strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str) + 1);
strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str) + 1);
strncpy(key->u.kbd.release_str, release, sizeof(key->u.kbd.release_str) +
1);
}

In file included from /usr/include/string.h:630,
 from c.c:1:
c.c: In function ‘panel_bind_key’:
c.c:19:5: warning: ‘__builtin_strncpy’ specified bound 12 equals destination
size [-Wstringop-truncation]
 strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
 ^~~
c.c:20:5: warning: ‘__builtin_strncpy’ specified bound 12 equals destination
size [-Wstringop-truncation]
 strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
 ^~~
c.c: In function ‘foo’:
c.c:28:5: warning: ‘__builtin_strncpy’ writing 13 bytes into a region of size
12 overflows the destination [-Wstringop-overflow=]
 strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str) + 1);
 ^~~
c.c:29:5: warning: ‘__builtin_strncpy’ writing 13 bytes into a region of size
12 overflows the destination [-Wstringop-overflow=]
 strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str) + 1);
 ^~~
c.c:30:5: warning: ‘__builtin_strncpy’ writing 13 bytes into a region of size
12 overflows the destination [-Wstringop-overflow=]
 strncpy(key->u.kbd.release_str, release, sizeof(key->u.kbd.release_str) +
1);
 ^~~

[Bug c++/86763] New: Wrong code comparing member of copy of a 237 byte object with nontrivial default constructor on x86-64 arch

[curlypaul924 at gmail dot com]

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

Bug ID: 86763
   Summary: Wrong code comparing member of copy of a 237 byte
object with nontrivial default constructor on x86-64
arch
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: curlypaul924 at gmail dot com
  Target Milestone: ---

Created attachment 44475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44475=edit
.ii file generated from t4.cpp

The following program produces an incorrect result on GCC 8.1 and 8.2.  It
succeeds on 7.2.

AFAICT, the problem is that the comparison happens before the object has been
copied.  The compiler could compare using the temporary stored in rdx, but it
instead compares using the value at [rsp+8], which isn't yet written to.

This happens when using -march=x86-64, but does not happen on -march=core2 or
newer.  In these cases, memcpy is used to do the copy, and the comparison
happens after the call to memcpy.

Moreover, GCC misses an opportunity to optimize away the copy altogether. 
Clang 6.0.0 does optimize away the copy.

The misplaced comparison happens at -O2 or higher; at -O1, the comparison is
done after the copy.

#include 
#include 
#include 
struct ID {
  uint64_t value;
};
uint64_t value(ID id) { return id.value; }
uint64_t gen { 1000 };
struct Msg {
  uint64_t time;
  ID id;
};
struct V {
  V() { }
  V(Msg const & msg) : msg(msg) { }
  Msg & get() { return msg; }
  Msg msg;
  char pad[237 - sizeof(Msg)];
};
struct T : V { using V::V; };
Msg init_msg() {
  Msg msg;
  timespec t;
  clock_gettime(CLOCK_REALTIME, );
  msg.time = t.tv_sec + t.tv_nsec;
  msg.id.value = ++gen;
  return msg;
}
int main() {
  T t;
  t = init_msg();
  assert(value(t.get().id) == 1001);
}

$ g++-8.1 -std=c++14 -O2 -Wall -Werror -march=x86-64 -save-temps -v t4.cpp
Using built-in specs.   
COLLECT_GCC=/usr/local/bin/g++-8.1  
COLLECT_LTO_WRAPPER=/opt/gcc/8.1/libexec/gcc/x86_64-linux-gnu/8.1.0/lto-wrapper 
Target: x86_64-linux-gnu
Configured with: /home/pbrannan/git/theme_infra/packaging/gcc-8.1.0/configure
--prefix=/opt/gcc/8.1 --enable-languages=c,c++ --with-pkgversion='Thesys GCC
8.1.0 for Ubuntu 16.04' --enable-shared --enable-gnu-unique-object
--enable-threads=posix --enable-checking=release --disable-vtable-verify
--enable-lto --with-ab
i=m64 --enable-multiarch --disable-multilib --with-build-config=bootstrap-lto
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu  
Thread model: posix 
gcc version 8.1.0 (Thesys GCC 8.1.0 for Ubuntu 16.04)   
COLLECT_GCC_OPTIONS='-std=c++14' '-O2' '-Wall' '-Werror' '-march=x86-64'
'-save-temps' '-v' '-shared-libgcc' 
 /opt/gcc/8.1/libexec/gcc/x86_64-linux-gnu/8.1.0/cc1plus -E -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE t4.cpp -march=x86-64 -std=c++14
-Wall -Werror -O2 -fpch-preprocess -o t4.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0

/opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/x86_64-linux-gnu

/opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/backward
 /opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/include
 /usr/local/include
 /opt/gcc/8.1/include
 /opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c++14' '-O2' '-Wall' '-Werror' '-march=x86-64'
'-save-temps' '-v' '-shared-libgcc'
 /opt/gcc/8.1/libexec/gcc/x86_64-linux-gnu/8.1.0/cc1plus -fpreprocessed t4.ii
-quiet -dumpbase t4.cpp -march=x86-64 -auxbase t4 -O2 -Wall -Werror -std=c++14
-version -o t4.s
GNU C++14 (Thesys GCC 8.1.0 for Ubuntu 16.04) version 8.1.0 (x86_64-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Thesys GCC 8.1.0 for Ubuntu 16.04) version 8.1.0 (x86_64-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6724e7d270573c4346dc08c31ad9ce91
COLLECT_GCC_OPTIONS='-std=c++14' '-O2' '-Wall' 

[Bug c++/86761] Code corruption with missing pointer return

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
You can use -fsanitize-undefined-trap-on-error if you don't want to link
libubsan.

[Bug c++/86761] Code corruption with missing pointer return

[r.j.dejong at student dot utwente.nl]

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

--- Comment #2 from Hans de Jong  ---
Unfortunately option -fsanitize=undefined does not link while using the
arm-none-eabi cross compiler, since a typical embedded target does not have
enough memory for such run-time libraries.

In order to catch these kind of errors during compilation time, I will have to
enable -Werror instead as a work-around, which is a sane thing to do
nonetheless.

I would like to point out that GCC 8.1 removes the complete compound statement
with the offending call. GCC 7.x did not exhibit this behaviour. Does this
still fall under the umbrella of unpredictable behaviour? It becomes harder to
track down these kind of errors when the proximity from offending code
increases.

[Bug target/86762] New: Using -fstack-protector-all causes SIGSEV with gcc-8

[shane at isara dot com]

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

Bug ID: 86762
   Summary: Using -fstack-protector-all causes SIGSEV with gcc-8
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shane at isara dot com
  Target Milestone: ---

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

Using gcc-8 from brew on macOS 10.13.6 a simple main program causes SIGSEV with
-fstack-protector-all. We have confirmed this is not the case using gcc-7 and
is only an issue on macOS (didn't check other versions of the OS).

The program is just as follows:
int main (int argv, char **arc)
{
(void) argv;
(void) argc;
return 0;
}

compiled with:
gcc-8 main.c -O3 -o tst -Wall -Wextra -fstack-protector-all --save-temps

causes:
fish: './tst' terminated by signal SIGSEGV (Address boundary error)


gcc-8 -v:
Using built-in specs.
COLLECT_GCC=gcc-8
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/8.2.0/libexec/gcc/x86_64-apple-darwin17.7.0/8.2.0/lto-wrapper
Target: x86_64-apple-darwin17.7.0
Configured with: ../configure --build=x86_64-apple-darwin17.7.0
--prefix=/usr/local/Cellar/gcc/8.2.0
--libdir=/usr/local/Cellar/gcc/8.2.0/lib/gcc/8
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-8
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC
8.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-nls
Thread model: posix
gcc version 8.2.0 (Homebrew GCC 8.2.0)

[Bug target/86758] [9 Regression] ICE in replace_stmt compiling gcc.target/i386/pr84309.c

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Testing a fix.

[Bug c++/86761] Code corruption with missing pointer return

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
It is undefined behavior after falling through without a return (to a non void
return type).

>Although the warning is a good pointer to this error, it was hard to track 
>down since the function "setFlags" was nested 3 levels down in the code.

You can use -fsanatizer=undefined to find this behavior at runtime.

[Bug c++/86761] New: Code corruption with missing pointer return

[r.j.dejong at student dot utwente.nl]

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

Bug ID: 86761
   Summary: Code corruption with missing pointer return
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: r.j.dejong at student dot utwente.nl
  Target Milestone: ---

Created attachment 44473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44473=edit
g++ -O3 -save-temps bug.c

GCC version: 8.1.0 (Arch builds)
System: x86-64 and arm-none-eabi compilers
Compile options (x86): gcc -O3 -Wall bug.c
Command line:

hans-pc% gcc -O3 bug.c -Wall
bug.c: In function ‘setFlags’:
bug.c:7:1: warning: control reaches end of non-void function [-Wreturn-type]
hans-pc% ./a.out  
0 == 0
1 == 1
2 == 2
hans-pc% g++ -O0 bug.c
bug.c: In function ‘uint8_t* setFlags(uint8_t)’:
bug.c:7:1: warning: no return statement in function returning non-void
[-Wreturn-type]
hans-pc% ./a.out
0 == 0
1 == 1
2 == 2
hans-pc% g++ -O1 bug.c
bug.c: In function ‘uint8_t* setFlags(uint8_t)’:
bug.c:7:1: warning: no return statement in function returning non-void
[-Wreturn-type]
hans-pc% ./a.out
hans-pc% # No output
hans-pc% g++ -O3 bug.c
bug.c: In function ‘uint8_t* setFlags(uint8_t)’:
bug.c:7:1: warning: no return statement in function returning non-void
[-Wreturn-type]
hans-pc% ./a.out 
zsh: segmentation fault (core dumped)  ./a.out

Comments:

Code runs fine on GCC, despite the warning.
Code runs only on G++ with no optimizations. Unpredictable fatal behaviour
occurs on various optimization levels.
Originally the function getFlags and setFlags were in a class, but outside a
class the fault still occurs.

When debugging in my application, I've seen non-terminating fixed length for
loops and if branches completely stripped from assembly with the offending
function call. Although the warning is a good pointer to this error, it was
hard to track down since the function "setFlags" was nested 3 levels down in
the code.

The code runs fine with GCC 7.x branches. I've been unable to test GCC 8.2 or
9.0 builds.

[Bug target/86758] [9 Regression] ICE in replace_stmt compiling gcc.target/i386/pr84309.c

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

[Bug fortran/57160] short-circuit IF only with -ffrontend-optimize

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #13 from janus at gcc dot gnu.org ---
It should be noted that ifort (version 18.3) gives a nice runtime error for the
code in comment 0 with the proper checking flags:

$ ifort -check all -traceback c0.f90 
$ ./a.out 
forrtl: severe (408): fort: (7): Attempt to use pointer M when it is not
associated with a target

Image  PCRoutineLineSource  
a.out  004056C0  Unknown   Unknown  Unknown
a.out  00402CA3  m1_mp_s1_   8  c0.f90
a.out  00402DAE  MAIN__ 16  c0.f90
a.out  00402BAE  Unknown   Unknown  Unknown
libc-2.23.so   7FF4052CF830  __libc_start_main Unknown  Unknown
a.out  00402AA9  Unknown   Unknown  Unknown


This underlines once more that the code is actually invalid (in case there was
still doubt about that).

[Bug target/86758] [9 Regression] ICE in replace_stmt compiling gcc.target/i386/pr84309.c

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|x86_64-linux|x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-31
 CC||ro at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #2 from Rainer Orth  ---
Indeed: I'm seeing the same on i386-pc-solaris2.11, happened between 20180730
(r263069) and 20180731 (r263163).

Obviously caused by Richard Sandiford's recent patch series.

[Bug middle-end/86705] [7/8/9 Regression] pr45678-2.c ICE with msp430-elf -mlarge

[jozefl at gcc dot gnu.org]

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

--- Comment #2 from jozefl at gcc dot gnu.org ---
Author: jozefl
Date: Tue Jul 31 18:17:00 2018
New Revision: 263177

URL: https://gcc.gnu.org/viewcvs?rev=263177=gcc=rev
Log:
PR middle-end/86705

* gcc/cfgexpand.c (set_parm_rtl): Use the alignment of Pmode when
MAX_SUPPORTED_STACK_ALIGNMENT would otherwise be exceeded by the
requested variable alignment.
(expand_one_ssa_partition): Likewise.
(expand_one_var): Likewise.


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

[Bug fortran/86760] [8/9 Regression] FORTRAN: polymorphic arrays inside a user-defined type generate segmentation faults

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
Likely r251949.

[Bug fortran/86760] [8/9 Regression] FORTRAN: polymorphic arrays inside a user-defined type generate segmentation faults

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||7.3.1
   Keywords||wrong-code
   Last reconfirmed||2018-07-31
 Ever confirmed|0   |1
Summary|FORTRAN: polymorphic arrays |[8/9 Regression] FORTRAN:
   |inside a user-defined type  |polymorphic arrays inside a
   |generate segmentation   |user-defined type generate
   |faults  |segmentation faults
   Target Milestone|--- |8.3
  Known to fail||8.2.0, 9.0

--- Comment #1 from Dominique d'Humieres  ---
The segfault appeared between revisions r251946 (2017-09-10, OK) and r251980
(2017-09-11, segfault).

[Bug fortran/86760] New: FORTRAN: polymorphic arrays inside a user-defined type generate segmentation faults

[hansec at uw dot edu]

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

Bug ID: 86760
   Summary: FORTRAN: polymorphic arrays inside a user-defined type
generate segmentation faults
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hansec at uw dot edu
  Target Milestone: ---

Created attachment 44472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44472=edit
Minimal test case

The attached code produces a segmentation fault when running on MacOS (10.13.6)
and Ubuntu (16.04.4 LTS "GNU/Linux 4.4.0-130-generic x86_64"). The segmentation
fault is produced with GCC 8.1.0 and 8.2.0 when optimization is enabled (-O1 or
greater). It is not produced when optimization is disabled. As far as I can
tell the error is not produced when the source is compiled with GCC 7.x or
earlier. Usage of this pattern has not produced an issue until now with my
production code and the minimal test case attached works as expected with GCC
7.3.0 and 5.4.0.

The crash occurs during the process of deallocating internal structures in a
user-defined type that contains a polymorphic array of pointers where each
pointer element in the array may be a different class. In the attached example,
an object of this type is created and then the deallocation process is
performed deallocating each object in the array after it's local deallocation
method is called. With GFortran 8.1.0 and 8.2.0 the process generates a
segmentation fault on the second item in the array. Note that if a local
intermediary array is used as in the bound method "destroy_local" the
segmentation fault is not produced. Also, note that even though this method
allows different classes in the array only one class is used in this case.

Platform information:

MacOS (10.13.6)-

"uname -a" output (host info removed):

Darwin  17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018;
root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64

"gfortran -v" output:

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-8_2/libexec/gcc/x86_64-apple-darwin17.7.0/8.2.0/lto-wrapper
Target: x86_64-apple-darwin17.7.0
Configured with: ../configure --prefix=/opt/gcc-8_2 --with-gmp=/opt/gcc-8_2
--with-mpfr=/opt/gcc-8_2 --with-mpc=/opt/gcc-8_2 --with-isl=/opt/gcc-8_2
--enable-checking=release --enable-languages=c,c++,fortran
--enable-threads=posix
Thread model: posix
gcc version 8.2.0 (GCC)

Ubuntu (16.04.4)-

"uname -a" output (host info removed):

Linux  4.4.0-130-generic #156-Ubuntu SMP Thu Jun 14 08:53:28 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux

"gfortran -v" output:

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-8_1/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/opt/gcc-8_1 --with-gmp=/opt/gcc-8_1
--with-mpfr=/opt/gcc-8_1 --with-mpc=/opt/gcc-8_1 --with-isl=/opt/gcc-8_1
--enable-checking=release --enable-languages=c,c++,fortran
--enable-threads=posix
Thread model: posix
gcc version 8.1.0 (GCC)

[Bug sanitizer/86759] New: ThreadSanitizer: unsupported VMA range on ppc64le

[mpolacek at gcc dot gnu.org]

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

Bug ID: 86759
   Summary: ThreadSanitizer: unsupported VMA range on ppc64le
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

TSan doesn't seem to work on ppc64le with kernel-4.14:

x.c:
int main () { }

# ./xgcc -B. -B ../powerpc64le-unknown-linux-gnu/libsanitizer/tsan/ -B
../powerpc64le-unknown-linux-gnu/libsanitizer/tsan/.libs/
-Wl,-rpath=../powerpc64le-unknown-linux-gnu/libsanitizer/tsan/.libs/ x.c
-fsanitize=thread
# ./a.out 
FATAL: ThreadSanitizer: unsupported VMA range
FATAL: Found 47 - Supported 44 and 46

Target: powerpc64le-unknown-linux-gnu
Configured with: /root/gcc/configure --enable-languages=c,c++
--enable-checking=yes -with-system-zlib --disable-bootstrap --disable-libvtv
--disable-libitm --disable-libgomp --disable-libcc1 --disable-libstdcxx-pch
--disable-libssp --disable-isl --disable-libmpx
Thread model: posix
gcc version 9.0.0 20180731 (experimental) (GCC)

[Bug target/86758] [9 Regression] ICE in replace_stmt compiling gcc.target/i386/pr84309.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-linux

--- Comment #1 from Martin Sebor  ---
Same ICE also seen when compiling gcc.dg/pr84452.c.

[Bug target/86758] New: [9 Regression] ICE in replace_stmt compiling gcc.target/i386/pr84309.c

[msebor at gcc dot gnu.org]

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

Bug ID: 86758
   Summary: [9 Regression] ICE in replace_stmt compiling
gcc.target/i386/pr84309.c
   Product: gcc
   Version: 9.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 following ICE has popped up in recent x86_64-linux test suite runs:

$ gcc -Ofast -S -Wall -mavx -mno-avx2
/ssd/src/gcc/svn/gcc/testsuite/gcc.target/i386/pr84309.c
during GIMPLE pass: vect
/ssd/src/gcc/svn/gcc/testsuite/gcc.target/i386/pr84309.c: In function ‘foo’:
/ssd/src/gcc/svn/gcc/testsuite/gcc.target/i386/pr84309.c:10:1: internal
compiler error: in replace_stmt, at tree-vectorizer.c:611
 foo (void)
 ^~~
0x13c2922 vec_info::replace_stmt(gimple_stmt_iterator*, _stmt_vec_info*,
gimple*)
/ssd/src/gcc/svn/gcc/tree-vectorizer.c:611
0x13657fb vectorizable_simd_clone_call
/ssd/src/gcc/svn/gcc/tree-vect-stmts.c:4375
0x1378f28 vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*, bool*,
_slp_tree*, _slp_instance*)
/ssd/src/gcc/svn/gcc/tree-vect-stmts.c:9758
0x139c58b vect_transform_loop_stmt
/ssd/src/gcc/svn/gcc/tree-vect-loop.c:8263
0x139d20d vect_transform_loop(_loop_vec_info*)
/ssd/src/gcc/svn/gcc/tree-vect-loop.c:8477
0x13c3817 try_vectorize_loop_1
/ssd/src/gcc/svn/gcc/tree-vectorizer.c:945
0x13c3a9d try_vectorize_loop
/ssd/src/gcc/svn/gcc/tree-vectorizer.c:998
0x13c3c78 vectorize_loops()
/ssd/src/gcc/svn/gcc/tree-vectorizer.c:1077
0x1252263 execute
/ssd/src/gcc/svn/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/86741] [9 Regression] ICE in vrp_prop::check_mem_ref building glibc for i686-gnu

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
Fixed via r263166.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 86741 Summary: [9 Regression] ICE in vrp_prop::check_mem_ref building glibc 
for i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86741

   What|Removed |Added

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

[Bug middle-end/86757] New: [og8,nvptx] gangprivate related regressions

[cesar at gcc dot gnu.org]

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

Bug ID: 86757
   Summary: [og8,nvptx] gangprivate related regressions
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cesar at gcc dot gnu.org
  Target Milestone: ---

The goacc_parlevel patches have been backported to openacc-gcc-8-branch in git
revision 6781e2dd99. For the most part, the patches applied cleanly, however, I
had to xfail the following tests in libgomp.oacc-c-c++-common because they fail
with -O0:

   loop-gwv-1.c
   loop-red-gwv-1.c
   loop-red-w-2.c

These tests work on trunk at -O0. I believe the problem was introduced with the
gangprivate patch. When I deactivated the gangprivate patch by modifying
nvptx.c:nvptx_goacc_expand_accel_var to always return NULL_RTX, those test
cases started passing.

I suspect this bug crept into og8 because those aforementioned tests were
originally skipped altogether at -O0 because they contained inline PTX assembly
code, which wasn't optimized away by the host compiler unless the program is
built with -O1 or greater. The goacc_parlevel changes replace the inline PTX
code with builtin functions that get expanded by the backend, which enables
those tests to run at -O0.

[Bug libstdc++/86597] directory_entry::exist et al forget to clear the error_code.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-31
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/86756] Don't define __cpp_lib_filesystem unless --enable-libstdcxx-filesystem-ts

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-31
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Same for  and __cpp_lib_experimental_filesystem.

[Bug libstdc++/86756] New: Don't define __cpp_lib_filesystem unless --enable-libstdcxx-filesystem-ts

[redi at gcc dot gnu.org]

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

Bug ID: 86756
   Summary: Don't define __cpp_lib_filesystem unless
--enable-libstdcxx-filesystem-ts
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Currently the  header is installed unconditionally, even if the
libstdc++fs.a library is not installed.

Either the headers should not be installed, or the feature test macro should
not be defined.

[Bug tree-optimization/86741] [9 Regression] ICE in vrp_prop::check_mem_ref building glibc for i686-gnu

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Tue Jul 31 16:47:39 2018
New Revision: 263166

URL: https://gcc.gnu.org/viewcvs?rev=263166=gcc=rev
Log:
PR tree-optimization/86741 - ICE in -Warray-bounds indexing into an object of
incomplete type

gcc/ChangeLog:

PR tree-optimization/86741
* tree-vrp.c (vrp_prop::check_mem_ref): Avoid incomplete types.

gcc/testsuite/ChangeLog:

PR tree-optimization/86741
* gcc.dg/Warray-bounds-33.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-33.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug tree-optimization/86749] [9 Regression] Gcc miscompiles at -O3 with sse4 on valid code

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

[Bug sanitizer/86755] New: [ASAN] Libasan failed to be build for arm with -mthumb and -fno-omit-frame-pointer

[d.khalikov at partner dot samsung.com]

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

Bug ID: 86755
   Summary: [ASAN] Libasan failed to be build for arm with -mthumb
and -fno-omit-frame-pointer
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.khalikov at partner dot samsung.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 44471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44471=edit
Reduced test case

GCC fails to build libasan with -mthumb and -fno-omit-frame-pointer

../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function
'__sanitizer::uptr __sanitizer::internal_clone(int (*)(void*), void*, int,
void*, int*, void*, int*)':
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:1540:1: error: r7
cannot be used in asm here
 }

The problem is inside internal_clone function defined for arm.

Reduced test case:

$cat clone.cc
#define __NR_clone 120
#define __NR_exit 1

using uptr = unsigned int;
unsigned int EINVAL = 1;
uptr internal_clone(int (*fn)(void *), void *child_stack, int flags, void *arg,
int *parent_tidptr, void *newtls, int *child_tidptr) {
  unsigned int res;
  if (!fn || !child_stack)
return -EINVAL;
  child_stack = (char *)child_stack - 2 * sizeof(unsigned int);
  ((unsigned int *)child_stack)[0] = (uptr)fn;
  ((unsigned int *)child_stack)[1] = (uptr)arg;
  register int r0 __asm__("r0") = flags;
  register void *r1 __asm__("r1") = child_stack;
  register int *r2 __asm__("r2") = parent_tidptr;
  register void *r3 __asm__("r3") = newtls;
  register int *r4 __asm__("r4") = child_tidptr;
  register int r7 __asm__("r7") = __NR_clone;

#if __ARM_ARCH > 4 || defined (__ARM_ARCH_4T__)
# define ARCH_HAS_BX
#endif
#if __ARM_ARCH > 4
# define ARCH_HAS_BLX
#endif

#ifdef ARCH_HAS_BX
# ifdef ARCH_HAS_BLX
#  define BLX(R) "blx "  #R "\n"
# else
#  define BLX(R) "mov lr, pc; bx " #R "\n"
# endif
#else
# define BLX(R)  "mov lr, pc; mov pc," #R "\n"
#endif

  __asm__ __volatile__(
   /* %r0 = syscall(%r7 = SYSCALL(clone),
*   %r0 = flags,
*   %r1 = child_stack,
*   %r2 = parent_tidptr,
*   %r3  = new_tls,
*   %r4 = child_tidptr)
*/

   /* Do the system call */
   "swi 0x0\n"

   /* if (%r0 != 0)
*   return %r0;
*/
   "cmp r0, #0\n"
   "bne 1f\n"

   /* In the child, now. Call "fn(arg)". */
   "ldr r0, [sp, #4]\n"
   "ldr ip, [sp], #8\n"
   BLX(ip)
   /* Call _exit(%r0). */
   "mov r7, %7\n"
   "swi 0x0\n"
   "1:\n"
   "mov %0, r0\n"
   : "=r"(res)
   : "r"(r0), "r"(r1), "r"(r2), "r"(r3), "r"(r4), "r"(r7),
 "i"(__NR_exit)
   : "memory");
  return res;
} 


$armv7l-linux-gnueabi-g++ -o clone.s clone.cc -fno-omit-frame-pointer -mthumb
-S
clone.cc: In function ‘uptr internal_clone(int (*)(void*), void*, int, void*,
int*, void*, int*)’:
clone.cc:70:1: error: r7 cannot be used in asm here

Regarding to arm ABI, r7 register is using for syscall number, r0 for return
value, and r1 - r6 for syscall arguments, by the way r7 for arm with THUMB2
mode is using as frame pointer and it looks like we have a conflict in this
case. As far as I understood, GCC has a special check inside IRA 
if (!TEST_HARD_REG_BIT (crtl->asm_clobbers, HARD_FRAME_POINTER_REGNUM)), which
does not allow to have frame pointer register as clobber register. 

In other way, there is no issue with clang:
clang++ -target armv7l -S -o clone.s  clone.cc -mthumb -fno-omit-frame-pointer

So, looks like we can save syscall number in r8 register, move it to r7 before
we the interruption, and restore the value in the parent task. 

 register int r8 __asm__("r8") = __NR_clone;

  __asm__ __volatile__(
   /* %r0 = syscall(%r7 = SYSCALL(clone),
*   %r0 = flags,
*   %r1 = child_stack,
*   %r2 = parent_tidptr,
*   %r3  = new_tls,
*   %r4 = child_tidptr)
*/

   "push {r7}\n"
  

[Bug c/77328] incorrect caret location in -Wformat calling printf via a macro

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||7.3.0, 8.2.0, 9.0

--- Comment #3 from Martin Sebor  ---
GCC 8 and 9 output for the test case is slightly different (underlining the
sprintf argument is a nice improvement) but still not what it should be:

pr77328.c: In function ‘f’:
pr77328.c:7:30: warning: format ‘%i’ expects argument of type ‘int’, but
argument 4 has type ‘double’ [-Wformat=]
   __builtin_sprintf (d, "%i %i", 1, 2.0);
 ~^  ~~~
 %f
pr77328.c:9:9: warning: format ‘%i’ expects argument of type ‘int’, but
argument 4 has type ‘double’ [-Wformat=]
   P (d, "%i %i", 1, 2.0);
 ^~~ ~~~
pr77328.c:5:45: note: in definition of macro ‘P’
 #define P(d, f, a, b) __builtin_sprintf (d, f, a, b)
 ^

[Bug debug/86687] Wrong debug information for string types passed as parameters

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries  ---
Author: vries
Date: Tue Jul 31 15:37:11 2018
New Revision: 263164

URL: https://gcc.gnu.org/viewcvs?rev=263164=gcc=rev
Log:
[c++] Fix DECL_BY_REFERENCE of clone parms

Consider test.C compiled at -O0 -g:
...
class string {
public:
  string (const char *p) { this->p = p ; }
  string (const string ) { this->p = s.p; }

private:
  const char *p;
};

class foo {
public:
  foo (string dir_hint) {}
};

int
main (void)
{
  std::string s = "This is just a string";
  foo bar(s);
  return 0;
}
...

When parsing foo::foo, the dir_hint parameter gets a DECL_ARG_TYPE of
'struct string & restrict'.  Then during finish_struct, we call
clone_constructors_and_destructors and create clones for foo::foo, and
set the DECL_ARG_TYPE in the same way.

Later on, during finish_function, cp_genericize is called for the original
foo::foo, which sets the type of parm dir_hint to DECL_ARG_TYPE, and sets
DECL_BY_REFERENCE of dir_hint to 1.

After that, during maybe_clone_body update_cloned_parm is called with:
...
(gdb) call debug_generic_expr (parm.typed.type)
struct string & restrict
(gdb) call debug_generic_expr (cloned_parm.typed.type)
struct string
...
The type of the cloned_parm is then set to the type of parm, but
DECL_BY_REFERENCE is not set.

When doing cp_genericize for the clone later on,
TREE_ADDRESSABLE (TREE_TYPE ()) is no longer true for the updated type for
the parm, so DECL_BY_REFERENCE is not set there either.

The missing DECL_BY_REFERENCE on cloned_parm causes incorrect debug info to be
generated.

This patch fixes the problem by copying DECL_BY_REFERENCE in
update_cloned_parm.

Bootstrapped and reg-tested on x86_64.

2018-07-31  Tom de Vries  

PR debug/86687
* optimize.c (update_cloned_parm): Copy DECL_BY_REFERENCE.

* g++.dg/guality/pr86687.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/guality/pr86687.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/optimize.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/86738] [8/9 Regression] gcc 8.2: Internal compiler error memcpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
Bisection points to r259458:

PR c++/84463
* typeck.c (cp_build_addr_expr_1): Move handling of offsetof-like
tricks from here to ...
* cp-gimplify.c (cp_fold) : ... here.  Only use it
if INDIRECT_REF's operand is INTEGER_CST cast to pointer type.

[Bug libstdc++/67791] Crash using std::thread and iostream with dynamic loading of a shared library

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Link your main executable with libpthread.so

[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #11)
> Thanks for the explanation. Note that
> 
> % gfcp pr86735.f90 -Ofast -march=skylake -Wall -Wextra -fcheck=all

That probably just means that -fcheck prevents the optimization passes from
applying AVX512 instructions. Please cut the noise!

[Bug libstdc++/67791] Crash using std::thread and iostream with dynamic loading of a shared library

[andreas.go...@tu-dresden.de]

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

Andreas G  changed:

   What|Removed |Added

 CC||andreas.go...@tu-dresden.de

--- Comment #5 from Andreas G  ---
I encountered the same problem using g++ 8.1.0 and libstdc++ 6.0.25. 

I just raised the following stack overflow ticket, before I found this bug
report:

https://stackoverflow.com/questions/51209268/using-stdthread-in-a-library-loaded-with-dlopen-leads-to-a-sigsev

Is there any any plan for a fix?

Best,

Andreas

[Bug debug/77589] [6/7 Regression] fortran: Missing DW_AT_byte_stride for an array record field selection

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries  ---
(In reply to Jakub Jelinek from comment #10)
> AFAIK Kevin Buettner has the GDB support for it pretty much written but not
> yet submitted.

Mentioned this at https://sourceware.org/bugzilla/show_bug.cgi?id=22399#c1

[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> If you build for haswell or skylake architecture, that executable will
> not run on ivybridge, of course.

Thanks for the explanation. Note that

% gfcp pr86735.f90 -Ofast -march=skylake -Wall -Wextra -fcheck=all
% ./a.out
   1   2   3   4   5   6   
   7   8   9  10  11  12  13   
  14  15  16
   1   2   3   4   5   6   
   7   8   9  10  11  12  13   
  14  15  16

[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #8)
> On x86_64-apple-darwin17 without access to avx512, I see
> 
>[..]
> 
> Is this the same bug or should I file a new one?

That is not a bug at all. You apparently have an ivybridge processor, so with
that flag you get the expected output.

If you build for haswell or skylake architecture, that executable will not run
on ivybridge, of course.

[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Dominique d'Humieres from comment #8)
> On x86_64-apple-darwin17 without access to avx512, I see
> 
> Is this the same bug or should I file a new one?

Please file a new one.

[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
On x86_64-apple-darwin17 without access to avx512, I see

% gfcp pr86735.f90 -Ofast -march=skylake
% ./a.out
   1   2   3   4   5   6   
   7   8   9  10  11  12  13   
  14  15  16

Program received signal SIGILL: Illegal instruction.

and

% gfcp pr86735.f90 -Ofast -march=haswell
% ./a.out
   1   2   3   4   5   6   
   7   8   9  10  11  12  13   
  14  15  16

Program received signal SIGILL: Illegal instruction.

but

% gfcp pr86735.f90 -Ofast -march=ivybridge
% ./a.out
   1   2   3   4   5   6   
   7   8   9  10  11  12  13   
  14  15  16
   1   2   3   4   5   6   
   7   8   9  10  11  12  13   
  14  15  16

Is this the same bug or should I file a new one?

[Bug target/86640] [8/9 regression] ICE in combine

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
Author: segher
Date: Tue Jul 31 14:01:29 2018
New Revision: 263114

URL: https://gcc.gnu.org/viewcvs?rev=263114=gcc=rev
Log:
arm: Testcase for PR86640


gcc/testsuite/
PR target/86640
* gcc.target/arm/pr86640.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr86640.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/86754] [meta-bug] Memory leaks at run time

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-31
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Set to NEW.

[Bug fortran/86754] New: [meta-bug] Memory leaks at run time

[dominiq at lps dot ens.fr]

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

Bug ID: 86754
   Summary: [meta-bug] Memory leaks at run time
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

While sorting the gfortran bugs I have marked several memory leaks at run time
as blocking pr68800. As pointed in pr68800 comment 2, this is incorrect.

This meta-bug will collect memory leaks at run time.

[Bug target/86753] gcc.target/aarch64/sve/vcond_[45].c fail after recent combine patch

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Target||aarch64-linux-gnu
Summary|gcc.target/aarch64/sve/vcon |gcc.target/aarch64/sve/vcon
   |d_[45.c |d_[45].c fail after recent
   ||combine patch

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
gcc.target/aarch64/sve/vcond_4.c and
gcc.target/aarch64/sve/vcond_5.c fail after r263067.
The change is an improvement in the sense that it replaces
two consecutive instructions (a comparison and an AND)
with two independent instructions (two comparisons),
so it's not a problem with the patch.

What we really want here is a single predicated comparison
that's used for both the load and the select.  However,
that would need support for conditional comparisons
(perhaps along the lines of the IFN_COND_* arithmetic
functions) and would also need us to ditch the nested
comparison in VEC_COND_EXPRs.

[Bug target/50077] large model (-mcmodel=large) is broken on *86*-apple-darwin*

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #2)

> clang seems to support -mcmodel=large - at least at 3.1 - so any necessary
> ld64/dyld support is available.

That's an incorrect assumption on my part, although clang produces object files
without error. (for -c) it seems that the static linker cannot consume them.

On Darwin16 (and Dominique reports similar on D17):
For -mcmodel=medium and -mcmodel=large we get relocation fails at link time.

So, it seems that we should;
(a) disable tests using -mcmodel={medium,large} for current darwin
(b) possibly modify the darwin-specific option parsing to warn that these are
unsupported and reset the value to "small".

[Bug target/86753] New: gcc.target/aarch64/sve/vcond_[45.c

[rsandifo at gcc dot gnu.org]

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

Bug ID: 86753
   Summary: gcc.target/aarch64/sve/vcond_[45.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

[Bug target/86752] New: FAIL: gcc.target/i386/avx2-cvt-2.c

[hjl.tools at gmail dot com]

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

Bug ID: 86752
   Summary: FAIL: gcc.target/i386/avx2-cvt-2.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com, wei3.xiao at intel dot com
  Target Milestone: ---
Target: i386,x86-64

For

---
#define N 16
float f[N];
double d[N];
int n[N];

__attribute__((noinline)) void
f3 (void)
{
  int i;
  for (i = 0; i < N; i++)
d[i] = f[i];
}
---

r263067 improved -O3 -mavx2 -mtune=generic -m64 from

.cfi_startproc
vmovaps f(%rip), %xmm2
vmovaps f+32(%rip), %xmm3
vinsertf128 $0x1, f+16(%rip), %ymm2, %ymm0
vcvtps2pd   %xmm0, %ymm1
vextractf128$0x1, %ymm0, %xmm0
vmovaps %xmm1, d(%rip)
vextractf128$0x1, %ymm1, d+16(%rip)
vcvtps2pd   %xmm0, %ymm0
vmovaps %xmm0, d+32(%rip)
vextractf128$0x1, %ymm0, d+48(%rip)
vinsertf128 $0x1, f+48(%rip), %ymm3, %ymm0
vcvtps2pd   %xmm0, %ymm1
vextractf128$0x1, %ymm0, %xmm0
vmovaps %xmm1, d+64(%rip)
vextractf128$0x1, %ymm1, d+80(%rip)
vcvtps2pd   %xmm0, %ymm0
vmovaps %xmm0, d+96(%rip)
vextractf128$0x1, %ymm0, d+112(%rip)
vzeroupper
ret
.cfi_endproc

to

.cfi_startproc
vcvtps2pd   f(%rip), %ymm0
vmovaps %xmm0, d(%rip)
vextractf128$0x1, %ymm0, d+16(%rip)
vcvtps2pd   f+16(%rip), %ymm0
vmovaps %xmm0, d+32(%rip)
vextractf128$0x1, %ymm0, d+48(%rip)
vcvtps2pd   f+32(%rip), %ymm0
vextractf128$0x1, %ymm0, d+80(%rip)
vmovaps %xmm0, d+64(%rip)
vcvtps2pd   f+48(%rip), %ymm0
vextractf128$0x1, %ymm0, d+112(%rip)
vmovaps %xmm0, d+96(%rip)
vzeroupper
ret
.cfi_endproc

This lead to

FAIL: gcc.target/i386/avx2-cvt-2.c scan-assembler
vcvtps2pd[^\n\r]*(%xmm[^\n\r]*%ymm|ymm[^\n\r]*xmm)
FAIL: gcc.target/i386/avx-cvt-2.c scan-assembler
vcvtps2pd[^\n\r]*(%xmm[^\n\r]*%ymm|ymm[^\n\r]*xmm)

For -m32, we generate:

.cfi_startproc
vmovups f, %xmm2
vinsertf128 $0x1, f+16, %ymm2, %ymm0
vmovups f+32, %xmm3
vextractf128$0x1, %ymm0, %xmm0
vcvtps2pd   %xmm2, %ymm1
vmovups %xmm1, d
vextractf128$0x1, %ymm1, d+16
vcvtps2pd   %xmm0, %ymm0
vcvtps2pd   %xmm3, %ymm1
vmovups %xmm0, d+32
vextractf128$0x1, %ymm0, d+48
vinsertf128 $0x1, f+48, %ymm3, %ymm0
vmovups %xmm1, d+64
vextractf128$0x1, %ymm1, d+80
vextractf128$0x1, %ymm0, %xmm0
vcvtps2pd   %xmm0, %ymm0
vmovups %xmm0, d+96
vextractf128$0x1, %ymm0, d+112
vzeroupper
ret
.cfi_endproc

which is caused by different tuning options for -mtune=generic -m32.

[Bug libstdc++/86751] [6/7/8/9 Regression] Ambiguous operator= overload for std::pair

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-31
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
Summary|Ambiguous operator= |[6/7/8/9 Regression]
   |overload for std::pair |overload for std::pair
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Jonathan Wakely  ---
Confirmed. Seems easier to fix than I expected it to be ...

[Bug fortran/25829] [F03] Asynchronous IO support

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #47 from Christophe Lyon  ---
Since Andre has just reverted the patch, the regression I noticed should be
fixed, but here it is anyway:
On armeb-none-linux-gnueabihf
--with-mode arm
--with-cpu cortex-a9
--with-fpu neon-fp16
FAIL:gfortran.dg/array_constructor_8.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL:gfortran.dg/array_constructor_8.f90   -O3 -g  execution test

[Bug tree-optimization/86749] [9 Regression] Gcc miscompiles at -O3 with sse4 on valid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-*-*, i?86-*-*
   Priority|P3  |P1
  Known to work||8.1.0
Version|unknown |9.0

[Bug c++/86747] [8/9 Regression] rejects-valid with redundant friend declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P2
Version|unknown |8.2.0
   Target Milestone|--- |8.3
  Known to fail||8.1.0

[Bug libstdc++/86751] New: Ambiguous operator= overload for std::pair

[m.cencora at gmail dot com]

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

Bug ID: 86751
   Summary: Ambiguous operator= overload for std::pair
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

Following program does not compile since gcc 6.3
(this looks similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79141)

#include 

struct dummy
{
template 
operator T() const
{
return {};
}
};

int main()
{
dummy d;
std::pair s;
s = d;
}

Following error is produced:

: In function 'int main()':

:16:9: error: ambiguous overload for 'operator=' (operand types are
'std::pair' and 'dummy')

 s = d;

 ^

In file included from
/opt/compiler-explorer/gcc-6.3.0/include/c++/6.3.0/utility:70:0,

 from :1:

/opt/compiler-explorer/gcc-6.3.0/include/c++/6.3.0/bits/stl_pair.h:359:7: note:
candidate: std::pair<_T1, _T2>& std::pair<_T1, _T2>::operator=(typename
std::conditional,
std::is_copy_assignable<_T2> >::value, const std::pair<_T1, _T2>&, const
std::__nonesuch&>::type) [with _T1 = int; _T2 = int; typename
std::conditional,
std::is_copy_assignable<_T2> >::value, const std::pair<_T1, _T2>&, const
std::__nonesuch&>::type = const std::pair&]

   operator=(typename conditional<

   ^~~~

/opt/compiler-explorer/gcc-6.3.0/include/c++/6.3.0/bits/stl_pair.h:370:7: note:
candidate: std::pair<_T1, _T2>& std::pair<_T1, _T2>::operator=(typename
std::conditional,
std::is_copy_assignable<_T2> > >::value, const std::pair<_T1, _T2>&, const
std::__nonesuch&>::type) [with _T1 = int; _T2 = int; typename
std::conditional,
std::is_copy_assignable<_T2> > >::value, const std::pair<_T1, _T2>&, const
std::__nonesuch&>::type = const std::__nonesuch&] 

   operator=(typename conditional<

   ^~~~

/opt/compiler-explorer/gcc-6.3.0/include/c++/6.3.0/bits/stl_pair.h:376:7: note:
candidate: std::pair<_T1, _T2>& std::pair<_T1, _T2>::operator=(typename
std::conditional,
std::is_move_assignable<_T2> >::value, std::pair<_T1, _T2>&&,
std::__nonesuch&&>::type) [with _T1 = int; _T2 = int; typename
std::conditional,
std::is_move_assignable<_T2> >::value, std::pair<_T1, _T2>&&,
std::__nonesuch&&>::type = std::pair&&]

   operator=(typename conditional<

   ^~~~

[Bug c++/86730] use of deleted copy constructor (I am not using it)

[asif_bahrainwala at hotmail dot com]

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

--- Comment #2 from Asif  ---
Hi,
thanks for the quick update, I will consider this issue resolved.

"if a converting constructor was used, is then used to direct-initialize the
object"  (I am using this in my code, thought that this was getting around the
bug)

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #16 from Iain Sandoe  ---
[...]
> I am going to suggest that this is dup-ed to 81033 (and please try the revised
> patch there - I already checked it's OK on x86-64-linux [for at least the
> config we use on our build servers]).

I've now bootstrapped the revised patch on x86_64-apple-darwin11.4.2,
x86_64-pc-linux-gnu, i386-pc-solaris2.11, and sparc-sun-solaris2.11.

The libgcc_s.dylib link failures are gone on Darwin and no regressions
elsewhere.

Thanks.
Rainer

[Bug gcov-profile/83200] Unable to manipulate (prefix, strip) coverage/profile data file (.gcda) paths at compile time

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Liška  ---
Note that starting from r261199 we accept variables for -fprofile-dir=path
option. I hope it can be used in your scenario. For now I'm not planning to add
another options to make it even more complex.

[Bug gcov-profile/85338] [GCOV] Type conversion leads to incorrect coverage in printf

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug gcov-profile/85372] [GCOV] Wrong coverage with setjmp and longjmp function

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug gcov-profile/85350] [GCOV] wrong coverage when using constant variable in struct declaration

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug gcov-profile/83813] [GCOV] unsigned char in a union lead to incorrect coverage in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[marxin at gcc dot gnu.org]

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

Bug 86653 Summary: UBSAN error: cp/parser.c:11760:19: runtime error: load of 
value 10, which is not a valid value for type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86653

   What|Removed |Added

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

[Bug c++/86653] UBSAN error: cp/parser.c:11760:19: runtime error: load of value 10, which is not a valid value for type 'bool'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug gcov-profile/85217] [GCOV] A no side effect statement between a break statement and a continue statement will lead to incorrect code coverage in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug gcov-profile/84758] Wrong coverage for quite simple CFG

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug gcov-profile/85370] [GCOV] Wrong coverage with the target_clones attribute

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug gcov-profile/85332] [GCOV] wrong coverage with do-while in switch-case statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug gcov-profile/85350] [GCOV] wrong coverage when using constant variable in struct declaration

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue Jul 31 10:34:36 2018
New Revision: 263113

URL: https://gcc.gnu.org/viewcvs?rev=263113=gcc=rev
Log:
GCOV: add cache for streamed locations.

2018-07-31  Martin Liska  

PR gcov-profile/85338
PR gcov-profile/85350
PR gcov-profile/85372
* profile.c (struct location_triplet): New.
(struct location_triplet_hash): Likewise.
(output_location): Do not output a BB that
is already recorded for a line.
(branch_prob): Use streamed_locations.
2018-07-31  Martin Liska  

PR gcov-profile/85338
PR gcov-profile/85350
PR gcov-profile/85372
* gcc.misc-tests/gcov-pr85338.c: New test.
* gcc.misc-tests/gcov-pr85350.c: New test.
* gcc.misc-tests/gcov-pr85372.c: New test.

Added:
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85338.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85350.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85372.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/profile.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/85372] [GCOV] Wrong coverage with setjmp and longjmp function

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue Jul 31 10:34:36 2018
New Revision: 263113

URL: https://gcc.gnu.org/viewcvs?rev=263113=gcc=rev
Log:
GCOV: add cache for streamed locations.

2018-07-31  Martin Liska  

PR gcov-profile/85338
PR gcov-profile/85350
PR gcov-profile/85372
* profile.c (struct location_triplet): New.
(struct location_triplet_hash): Likewise.
(output_location): Do not output a BB that
is already recorded for a line.
(branch_prob): Use streamed_locations.
2018-07-31  Martin Liska  

PR gcov-profile/85338
PR gcov-profile/85350
PR gcov-profile/85372
* gcc.misc-tests/gcov-pr85338.c: New test.
* gcc.misc-tests/gcov-pr85350.c: New test.
* gcc.misc-tests/gcov-pr85372.c: New test.

Added:
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85338.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85350.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85372.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/profile.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/85338] [GCOV] Type conversion leads to incorrect coverage in printf

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue Jul 31 10:34:36 2018
New Revision: 263113

URL: https://gcc.gnu.org/viewcvs?rev=263113=gcc=rev
Log:
GCOV: add cache for streamed locations.

2018-07-31  Martin Liska  

PR gcov-profile/85338
PR gcov-profile/85350
PR gcov-profile/85372
* profile.c (struct location_triplet): New.
(struct location_triplet_hash): Likewise.
(output_location): Do not output a BB that
is already recorded for a line.
(branch_prob): Use streamed_locations.
2018-07-31  Martin Liska  

PR gcov-profile/85338
PR gcov-profile/85350
PR gcov-profile/85372
* gcc.misc-tests/gcov-pr85338.c: New test.
* gcc.misc-tests/gcov-pr85350.c: New test.
* gcc.misc-tests/gcov-pr85372.c: New test.

Added:
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85338.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85350.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85372.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/profile.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/85332] [GCOV] wrong coverage with do-while in switch-case statement

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue Jul 31 10:33:21 2018
New Revision: 263111

URL: https://gcc.gnu.org/viewcvs?rev=263111=gcc=rev
Log:
Fix GCOV CFG related issues.

2018-07-31  Martin Liska  

PR gcov-profile/83813
PR gcov-profile/84758
PR gcov-profile/85217
PR gcov-profile/85332
* profile.c (branch_prob): Do not record GOTO expressions
for GIMPLE statements which locations are already streamed.
2018-07-31  Martin Liska  

PR gcov-profile/83813
PR gcov-profile/84758
PR gcov-profile/85217
PR gcov-profile/85332
* gcc.misc-tests/gcov-pr83813.c: New test.
* gcc.misc-tests/gcov-pr84758.c: New test.
* gcc.misc-tests/gcov-pr85217.c: New test.
* gcc.misc-tests/gcov-pr85332.c: New test.

Added:
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr83813.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr84758.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85217.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85332.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/profile.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/85370] [GCOV] Wrong coverage with the target_clones attribute

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue Jul 31 10:34:02 2018
New Revision: 263112

URL: https://gcc.gnu.org/viewcvs?rev=263112=gcc=rev
Log:
Fix target clones (PR gcov-profile/85370).

2018-07-31  Martin Liska  

PR gcov-profile/85370
* coverage.c (coverage_begin_function): Do not mark target
clones as artificial functions.

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

[Bug gcov-profile/84758] Wrong coverage for quite simple CFG

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue Jul 31 10:33:21 2018
New Revision: 263111

URL: https://gcc.gnu.org/viewcvs?rev=263111=gcc=rev
Log:
Fix GCOV CFG related issues.

2018-07-31  Martin Liska  

PR gcov-profile/83813
PR gcov-profile/84758
PR gcov-profile/85217
PR gcov-profile/85332
* profile.c (branch_prob): Do not record GOTO expressions
for GIMPLE statements which locations are already streamed.
2018-07-31  Martin Liska  

PR gcov-profile/83813
PR gcov-profile/84758
PR gcov-profile/85217
PR gcov-profile/85332
* gcc.misc-tests/gcov-pr83813.c: New test.
* gcc.misc-tests/gcov-pr84758.c: New test.
* gcc.misc-tests/gcov-pr85217.c: New test.
* gcc.misc-tests/gcov-pr85332.c: New test.

Added:
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr83813.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr84758.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85217.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85332.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/profile.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/83813] [GCOV] unsigned char in a union lead to incorrect coverage in gcov

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Tue Jul 31 10:33:21 2018
New Revision: 263111

URL: https://gcc.gnu.org/viewcvs?rev=263111=gcc=rev
Log:
Fix GCOV CFG related issues.

2018-07-31  Martin Liska  

PR gcov-profile/83813
PR gcov-profile/84758
PR gcov-profile/85217
PR gcov-profile/85332
* profile.c (branch_prob): Do not record GOTO expressions
for GIMPLE statements which locations are already streamed.
2018-07-31  Martin Liska  

PR gcov-profile/83813
PR gcov-profile/84758
PR gcov-profile/85217
PR gcov-profile/85332
* gcc.misc-tests/gcov-pr83813.c: New test.
* gcc.misc-tests/gcov-pr84758.c: New test.
* gcc.misc-tests/gcov-pr85217.c: New test.
* gcc.misc-tests/gcov-pr85332.c: New test.

Added:
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr83813.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr84758.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85217.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85332.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/profile.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/85217] [GCOV] A no side effect statement between a break statement and a continue statement will lead to incorrect code coverage in gcov

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Tue Jul 31 10:33:21 2018
New Revision: 263111

URL: https://gcc.gnu.org/viewcvs?rev=263111=gcc=rev
Log:
Fix GCOV CFG related issues.

2018-07-31  Martin Liska  

PR gcov-profile/83813
PR gcov-profile/84758
PR gcov-profile/85217
PR gcov-profile/85332
* profile.c (branch_prob): Do not record GOTO expressions
for GIMPLE statements which locations are already streamed.
2018-07-31  Martin Liska  

PR gcov-profile/83813
PR gcov-profile/84758
PR gcov-profile/85217
PR gcov-profile/85332
* gcc.misc-tests/gcov-pr83813.c: New test.
* gcc.misc-tests/gcov-pr84758.c: New test.
* gcc.misc-tests/gcov-pr85217.c: New test.
* gcc.misc-tests/gcov-pr85332.c: New test.

Added:
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr83813.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr84758.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85217.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-pr85332.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/profile.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/86740] [8/9 Regression] ICE with hana and nested lambdas (likely a regression, tsubst_copy, at cp/pt.c:15325)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||needs-reduction
   Priority|P3  |P2
 Status|WAITING |NEW
   Target Milestone|--- |8.3
Summary|ICE with hana and nested|[8/9 Regression] ICE with
   |lambdas (likely a   |hana and nested lambdas
   |regression, tsubst_copy, at |(likely a regression,
   |cp/pt.c:15325)  |tsubst_copy, at
   ||cp/pt.c:15325)
  Known to fail||8.2.0, 9.0

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

[Bug c++/86653] UBSAN error: cp/parser.c:11760:19: runtime error: load of value 10, which is not a valid value for type 'bool'

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue Jul 31 10:32:13 2018
New Revision: 263110

URL: https://gcc.gnu.org/viewcvs?rev=263110=gcc=rev
Log:
Fix an UBSAN error in cp/parse.c (PR c++/86653).

2018-07-31  Martin Liska  

PR c++/86653
* parser.c (cp_parser_condition): Initialize non_constant_p
to false.

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

[Bug libstdc++/60555] std::system_category().default_error_condition() doesn't map system errno values to std::generic_category()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|5.5 |9.0
   Severity|enhancement |normal

[Bug libstdc++/60555] std::system_category().default_error_condition() doesn't map system errno values to std::generic_category()

[s_gccbugzilla at nedprod dot com]

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

--- Comment #9 from Niall Douglas  ---
Transferring over from #86750:

--- cut ---

Got bitten by this yet again today in Boost.Outcome and the P1031 LLFIO
reference implementation, so despite it being already reported at #60555, I'd
like to get this fixed already. It's been four years of writing libstdc++
specific workarounds, no fix on the horizon :(

This should not fail. It does on libstdc++ 9.0 trunk:

```
#include 
#include 
#include 

bool test()
{
return std::error_code(EEXIST, std::system_category()) ==
std::errc::file_exists;
}

int main()
{
std::cout << test() << std::endl;
assert(test() == true);
return 0;
}
```

https://wandbox.org/permlink/jYpIIMlXKJ4zX3ud


Jonathan says in #60555 'The standard also says "What constitutes
correspondence for any given operating system is unspecified."' for mapping
POSIX error codes onto generic codes. However the full text for
system_category() is actually:

```
If the argument ev corresponds to a POSIX errno value posv, the function shall
return error_condition(posv, generic_category()). Otherwise, the function shall
return error_condition(ev, system_category()). What constitutes correspondence
for any given operating system is unspecified.

[ Note: The number of potential system error codes is large and unbounded, and
some may not correspond to any POSIX errno value. Thus implementations are
given latitude in determining correspondence. — end note ]
```

So what the standard means here is that on POSIX systems, system_category is by
definition a superset of generic_category. All generic_category codes are
guaranteed to map onto system_category if the system is POSIX compliant. The
reverse is not the case, because the POSIX implementation may have proprietary
error codes which have no valid mapping in generic_category.

My test program above compares a system category error code of EEXIST - which
is a POSIX error code - to the generic code errc::file_exists. This is supposed
to return true. See the equivalent Boost.System based test example
https://wandbox.org/permlink/FQ9u6DtTkw2Uno1A and it indeed works correctly.

Windows, despite not being POSIX, also gets this right:

```
#include 
#include 
#include 

#include 

bool test()
{
return std::error_code(ERROR_FILE_EXISTS, std::system_category()) ==
std::errc::file_exists;
}

int main()
{
std::cout << test() << std::endl;
assert(test() == true);
return 0;
}
```

Please fix libstdc++.

[Bug debug/77589] [6/7 Regression] fortran: Missing DW_AT_byte_stride for an array record field selection

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Yes, since r251949, because gfortran changed ABI.
That doesn't mean DW_OP_GNU_variable_value isn't emitted in other cases, and
AFAIK Kevin Buettner has the GDB support for it pretty much written but not yet
submitted.

[Bug libstdc++/86750] libstdc++ std::system_category() does not map onto std::generic_category()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
.

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

[Bug libstdc++/60555] std::system_category().default_error_condition() doesn't map system errno values to std::generic_category()

[redi at gcc dot gnu.org]

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

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

[Bug debug/77589] [6/7 Regression] fortran: Missing DW_AT_byte_stride for an array record field selection

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #9 from Tom de Vries  ---
(In reply to Jakub Jelinek from comment #8)
> Fixed for 7+ (assuming GDB will get DW_OP_GNU_variable_value support added
> soon).
> No plans to backport this.

It looks like we've stopped generating DW_OP_GNU_variable_value for this
example at some point:
...
$ ( cc=gfortran; $cc --version; $cc -g test.f90 -save-temps -dA && grep
variable_value test.s )
GNU Fortran (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
Copyright (C) 2017 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.

.byte   0xfd# DW_OP_GNU_variable_value
$
$( cc=./install/bin/gfortran; $cc --version; $cc -g test.f90 -save-temps -dA &&
grep variable_value test.s )
GNU Fortran (GCC) 9.0.0 20180717 (experimental)
Copyright (C) 2018 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 libstdc++/60555] std::system_category().default_error_condition() doesn't map system errno values to std::generic_category()

[s_gccbugzilla at nedprod dot com]

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

Niall Douglas  changed:

   What|Removed |Added

 CC||s_gccbugzilla at nedprod dot 
com

--- Comment #7 from Niall Douglas  ---
Related #86750

[Bug libstdc++/86750] New: libstdc++ std::system_category() does not map onto std::generic_category()

[s_gccbugzilla at nedprod dot com]

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

Bug ID: 86750
   Summary: libstdc++ std::system_category() does not map onto
std::generic_category()
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s_gccbugzilla at nedprod dot com
  Target Milestone: ---

Got bitten by this yet again today in Boost.Outcome and the P1031 LLFIO
reference implementation, so despite it being already reported at #60555, I'd
like to get this fixed already. It's been four years of writing libstdc++
specific workarounds, no fix on the horizon :(

This should not fail. It does on libstdc++ 9.0 trunk:

```
#include 
#include 
#include 

bool test()
{
return std::error_code(EEXIST, std::system_category()) ==
std::errc::file_exists;
}

int main()
{
std::cout << test() << std::endl;
assert(test() == true);
return 0;
}
```

https://wandbox.org/permlink/jYpIIMlXKJ4zX3ud


Jonathan says in #60555 'The standard also says "What constitutes
correspondence for any given operating system is unspecified."' for mapping
POSIX error codes onto generic codes. However the full text for
system_category() is actually:

```
If the argument ev corresponds to a POSIX errno value posv, the function shall
return error_condition(posv, generic_category()). Otherwise, the function shall
return error_condition(ev, system_category()). What constitutes correspondence
for any given operating system is unspecified.

[ Note: The number of potential system error codes is large and unbounded, and
some may not correspond to any POSIX errno value. Thus implementations are
given latitude in determining correspondence. — end note ]
```

So what the standard means here is that on POSIX systems, system_category is by
definition a superset of generic_category. All generic_category codes are
guaranteed to map onto system_category if the system is POSIX compliant. The
reverse is not the case, because the POSIX implementation may have proprietary
error codes which have no valid mapping in generic_category.

My test program above compares a system category error code of EEXIST - which
is a POSIX error code - to the generic code errc::file_exists. This is supposed
to return true. See the equivalent Boost.System based test example
https://wandbox.org/permlink/FQ9u6DtTkw2Uno1A and it indeed works correctly.

Windows, despite not being POSIX, also gets this right:

```
#include 
#include 
#include 

#include 

bool test()
{
return std::error_code(ERROR_FILE_EXISTS, std::system_category()) ==
std::errc::file_exists;
}

int main()
{
std::cout << test() << std::endl;
assert(test() == true);
return 0;
}
```

Please fix libstdc++.