[Bug bootstrap/81710] New: build fail with glibc 2.26 due to removing ucontext/sigaltstack struct tags

[abominable-snowman at yandex dot ru]

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

Bug ID: 81710
   Summary: build fail with glibc 2.26 due to removing
ucontext/sigaltstack struct tags
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abominable-snowman at yandex dot ru
  Target Milestone: ---

Created attachment 41921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41921&action=edit
patch to fix

gcc 6.4.0 fail to compile with glibc 2.26 headers.

"struct ucontext" and "struct sigaltstack" not come from sys/ucontext.h since
glibc 2.26, use ucontext_t amd stack_t instead.

See

commit d57cb31910ca5c200e4172276749a7f8bd17ae3c
Author: Joseph Myers 
Date:   Wed Jun 28 10:33:23 2017 +

Miscellaneous sys/ucontext.h namespace fixes (bug 21457).

commit 251287734e89a52da3db682a8241eb6bccc050c9
Author: Joseph Myers 
Date:   Mon Jun 26 22:03:58 2017 +

Rename struct ucontext tag (bug 21457).

in glibc.

[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-04
 CC||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |7.3
Summary|ICE in  |[7/8 Regression] ICE in
   |gimple_get_virt_method_for_ |gimple_get_virt_method_for_
   |vtable  |vtable
 Ever confirmed|0   |1

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

[Bug bootstrap/81711] New: __res_state is a struct and a function in glibc 2.26

[abominable-snowman at yandex dot ru]

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

Bug ID: 81711
   Summary: __res_state is a struct and a function in glibc 2.26
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abominable-snowman at yandex dot ru
  Target Milestone: ---

Created attachment 41922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41922&action=edit
patch to fix

__res_state is a struct and function. Compiler should have
a chance to distinguish ones.

res_state defined as "struct __res_state *" in glibc, so
let's use it.

See resolv/resolv.h:

extern struct __res_state *__res_state(void) __attribute__ ((__const__));

and resolv/bits/types/res_state.h:

struct __res_state {
...
};

typedef struct __res_state *res_state;

[Bug tree-optimization/81705] UBSAN: yet another false positive

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-04
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug other/81712] New: gcc does not compile when using glib 2.26 (everything works fine with 2.25)

[igor at chub dot in]

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

Bug ID: 81712
   Summary: gcc does not compile when using glib 2.26 (everything
works fine with 2.25)
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor at chub dot in
  Target Milestone: ---

The compilation process stops with the following error message:


./md-unwind-support.h: In function 'x86_64_fallback_frame_state':
./md-unwind-support.h:65:47: error: dereferencing pointer to incomplete type
'struct ucontext'
   sc = (struct sigcontext *) (void *) &uc_->uc_mcontext;
   ^~
make[3]: Leaving directory
`/disk2/build/gcc-7.1.0-build/x86_64-pc-linux-gnu/libgcc'
make[3]: *** [unwind-dw2.o] Error 1
make[2]: Leaving directory `/disk2/build/gcc-7.1.0-build'
make[2]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/disk2/build/gcc-7.1.0-build'
make[1]: *** [all] Error 2

[Bug bootstrap/81711] __res_state is a struct and a function in glibc 2.26

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Comment on attachment 41922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41922
patch to fix

This patch should go upstream first.  Note gcc 7.2 is about to release in a few
weeks so it might already have a fix.

[Bug other/81712] gcc does not compile when using glib 2.26 (everything works fine with 2.25)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This might already be fixed for 7.2.0.

[Bug other/81712] gcc does not compile when using glib 2.26 (everything works fine with 2.25)

[igor at chub dot in]

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

--- Comment #2 from Igor Chubin  ---
Perfect. I'll try to build gcc-7.2-RC-20170802

[Bug tree-optimization/81705] UBSAN: yet another false positive

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
I don't see this with g++-7 which has

(void) (a = (-516151698 - NON_LVALUE_EXPR ) - -NON_LVALUE_EXPR )

trunks produces

(void) (a = -516151698 - (-NON_LVALUE_EXPR  + NON_LVALUE_EXPR ))

[Bug sanitizer/81711] __res_state is a struct and a function in glibc 2.26

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
This has been fixed already.

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

[Bug sanitizer/81066] sanitizer_stoptheworld_linux_libcdep.cc:276:22: error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be defined

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||abominable-snowman at yandex 
dot r
   ||u

--- Comment #17 from Jakub Jelinek  ---
*** Bug 81711 has been marked as a duplicate of this bug. ***

[Bug middle-end/81698] expand_case uses wrong edge as default edge

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-04
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  It's not guaranteed to be the first edge, only the first case
label.

[Bug testsuite/81699] [8 regression] gcc.dg/tree-ssa/reassoc-23.c fails starting with r250853

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/81701] -fstack-arrays hehavior does not match documentation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #1 from Richard Biener  ---
Documentation.  Promoting to .data is better but doesn't work for recursive
functions.

[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2

[Bug other/81712] gcc does not compile when using glib 2.26 (everything works fine with 2.25)

[igor at chub dot in]

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

--- Comment #3 from Igor Chubin  ---
Perfect. I'll try to build gcc-7.2-RC-20170802

[Bug tree-optimization/81703] memcpy folding defeats strlen optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-04
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think there's a duplicate of this bug.  Note the user could have written the
code in the same way as the folding produces so a) is the only real fix.

[Bug tree-optimization/81704] strncpy folding defeats strlen optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-04
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
See comment in other bug.

[Bug libstdc++/81706] std::sin vectorization bug

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-04
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|c++ |libstdc++
Version|unknown |7.1.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The C library sin is vectorized by being appropriately annotated with OpenMP
SIMD attributes.  This isn't the case for the libstdc++ variant which ends up
calling
__builtin_sinf:

  using ::sin;

  inline float
  sin(float __x)
  { return __builtin_sinf(__x); }

why the using ::sin and then still dispatching to the builtin?

[Bug other/81712] gcc does not compile when using glib 2.26 (everything works fine with 2.25)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||7.1.1
 Resolution|--- |FIXED
  Known to fail||7.1.0

--- Comment #4 from Richard Biener  ---
Yes, I think that part works now.

[Bug bootstrap/81710] build fail with glibc 2.26 due to removing ucontext/sigaltstack struct tags

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||6.4.1
 Resolution|--- |FIXED
  Known to fail||6.4.0

--- Comment #1 from Richard Biener  ---
This has been fixed on the GCC 6 branch.

[Bug middle-end/81705] [8 Regression] UBSAN: yet another false positive

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1
  Component|tree-optimization   |middle-end
  Known to work||7.1.1
   Target Milestone|--- |8.0
Summary|UBSAN: yet another false|[8 Regression] UBSAN: yet
   |positive|another false positive
  Known to fail||8.0

[Bug middle-end/81705] [8 Regression] UBSAN: yet another false positive

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Created by associate, thus mine.

[Bug bootstrap/81710] build fail with glibc 2.26 due to removing ucontext/sigaltstack struct tags

[abominable-snowman at yandex dot ru]

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

Petr Ovtchenkov  changed:

   What|Removed |Added

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

--- Comment #2 from Petr Ovtchenkov  ---
Bug 81066 may has relation to this.

[Bug middle-end/81705] [8 Regression] UBSAN: yet another false positive

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Oops.  Simple mistake in my recent patch.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 250865)
+++ gcc/fold-const.c(working copy)
@@ -9629,7 +9629,9 @@ fold_binary_loc (location_t loc,
  else if ((var0 && minus_var1
&& ! operand_equal_p (var0, minus_var1, 0))
   || (minus_var0 && var1
-  && ! operand_equal_p (minus_var0, var1, 0)))
+  && ! operand_equal_p (minus_var0, var1, 0))
+  || (minus_var0 && minus_var1
+  && ! operand_equal_p (minus_var0, minus_var1, 0)))
ok = false;
}

[Bug libstdc++/81706] std::sin vectorization bug

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41923&action=edit
gcc8-pr81706.patch

The reason for why cmath does this is that C++ wants to have sin overloads. 
And the problem is that we have the simd attributes only on ::sinf, ::sin etc.,
but not on __builtin_sinf, __builtin_sin etc.
So, either we change libstdc++ like with this untested patch, or change the
compiler, so that when seeing a matching decl for a builtin which has simd
attribute on it, we duplicate the attribute to the __builtin_* decl too.

[Bug bootstrap/81710] build fail with glibc 2.26 due to removing ucontext/sigaltstack struct tags

[jakub at gcc dot gnu.org]

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

Petr Ovtchenkov  changed:

   What|Removed |Added

  Attachment #41921|0   |1
   is patch||
  Attachment #41921|application/mbox|text/plain
  mime type||

--- Comment #3 from Jakub Jelinek  ---
The fix was r249957.

[Bug sanitizer/81697] Incorrect ASan global variables alignment on arm

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||m.ostapenko at samsung dot com

--- Comment #2 from Maxim Ostapenko  ---
Same for PPC that also uses section anchors.

[Bug hsa/81713] New: BIT_FIELD_REF produced by Brig FE do not pass new verification

[jamborm at gcc dot gnu.org]

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

Bug ID: 81713
   Summary: BIT_FIELD_REF produced by Brig FE do not pass new
verification
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Running brig FE testsuite reveals new failures:

FAIL: brig.dg/test/gimple/packed.hsail (internal compiler error)
FAIL: brig.dg/test/gimple/packed.hsail (test for excess errors)
FAIL: brig.dg/test/gimple/vector.hsail (internal compiler error)
FAIL: brig.dg/test/gimple/vector.hsail (test for excess errors)

They started with r250659, which makes BIT_FIELD_REF operand checking
stricter and the IL generated by brig FE seems to run afoul of them
with the following error:

brig1: error: invalid position or size operand to BIT_FIELD_REF
BIT_FIELD_REF 

Size and position operands of BIT_FIELD_REF must be compatible with
bitsizetype now.

[Bug hsa/81713] BIT_FIELD_REF produced by Brig FE do not pass new verification

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||pekka.jaaskelainen@parmance
   ||.com

--- Comment #1 from Martin Jambor  ---
Adding Pekka to CC who might fix this quicker than me.

[Bug c++/81714] New: incorrect location for uninitialised variable

[akim.demaille at gmail dot com]

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

Bug ID: 81714
   Summary: incorrect location for uninitialised variable
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akim.demaille at gmail dot com
  Target Milestone: ---

Hi,

This seems to be different from #55874 and #60350, but I might be wrong.  The
caret-display makes it particularly visible.  This affects GCC 4.9, 5.4.0,
6.3.0, and 7.1.1.

$ cat /tmp/foo.cc
int main()
{
  int i;
  return i + 42;
}
$ g++-mp-7 -Wall /tmp/foo.cc
/tmp/foo.cc: In function 'int main()':
/tmp/foo.cc:4:14: warning: 'i' is used uninitialized in this function
[-Wuninitialized]
   return i + 42;
  ^~
$ gcc-mp-7 --version
gcc-mp-7 (MacPorts gcc7 7-20170622_0) 7.1.
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.

$ g++-mp-6 -Wall /tmp/foo.cc
/tmp/foo.cc: In function 'int main()':
/tmp/foo.cc:4:14: warning: 'i' is used uninitialized in this function
[-Wuninitialized]
   return i + 42;
  ^~
$ g++-mp-5 -Wall /tmp/foo.cc
/tmp/foo.cc: In function 'int main()':
/tmp/foo.cc:4:14: warning: 'i' is used uninitialized in this function
[-Wuninitialized]
   return i + 42;
  ^
$ g++-mp-4.9 -Wall /tmp/foo.cc
/tmp/foo.cc: In function 'int main()':
/tmp/foo.cc:4:14: warning: 'i' is used uninitialized in this function
[-Wuninitialized]
   return i + 42;
  ^


In C mode, GCC is not affected, but the location is not very accurate either.

$ cat /tmp/foo.c
int main()
{
  int i;
  return i + 42;
}
$ gcc-mp-7 -Wall /tmp/foo.c
/tmp/foo.c: In function 'main':
/tmp/foo.c:4:12: warning: 'i' is used uninitialized in this function
[-Wuninitialized]
   return i + 42;
  ~~^~~~

It seems somewhat specific to this particular warning.


$ cat /tmp/foo.cc
int main()
{
  [[deprecated]]
  int a;
  return 1 + a;
}
$ g++-mp-7 -Wall /tmp/foo.cc -std=c++14
/tmp/foo.cc: In function 'int main()':
/tmp/foo.cc:5:14: warning: 'a' is deprecated [-Wdeprecated-declarations]
   return 1 + a;
  ^
/tmp/foo.cc:4:9: note: declared here
 int a;
 ^
/tmp/foo.cc:5:14: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
   return 1 + a;
  ^



Cheers!

[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
I'll have a look.  The assert on in_lto_p is scary though :-)

[Bug c++/81668] LTO ODR warnings are not helpful

[sgunderson at bigfoot dot com]

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

--- Comment #2 from sgunderson at bigfoot dot com ---
Running with -fno-diagnostics-show-caret does not help any:

../include/violite.h:288:8: warning: type ‘struct st_vio’ violates the C++ One
Definition Rule [-Wodr]
../include/violite.h:288:0: note: a different type is defined in another
translation unit
../include/violite.h:339:46: note: the first difference of corresponding
definitions is field ‘viodelete’
../include/violite.h:339:0: note: a field of same name but different type is
defined in another translation unit

It's hard for me to look at the preprocessed source code, because I don't know
what to preprocess. Like I said, there's probably a thousand translation units
including this .h file; how would I know which one to look through to find the
two differing definitions?

[Bug c++/81668] LTO ODR warnings are not helpful

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to sgunderson from comment #2)
> Running with -fno-diagnostics-show-caret does not help any:
> 
> ../include/violite.h:288:8: warning: type ‘struct st_vio’ violates the C++
> One Definition Rule [-Wodr]
> ../include/violite.h:288:0: note: a different type is defined in another
> translation unit
> ../include/violite.h:339:46: note: the first difference of corresponding
> definitions is field ‘viodelete’
> ../include/violite.h:339:0: note: a field of same name but different type is
> defined in another translation unit
> 
> It's hard for me to look at the preprocessed source code, because I don't
> know what to preprocess. Like I said, there's probably a thousand
> translation units including this .h file; how would I know which one to look
> through to find the two differing definitions?

You cannot expect anyone to debug MySQL for you. 
I don't see any bug, all relevant information is in the warnings.
It is up to you to figure out the rest.

[Bug sanitizer/81715] New: asan-stack=1 redzone allocation is too inflexible

[arnd at linaro dot org]

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

Bug ID: 81715
   Summary: asan-stack=1 redzone allocation is too inflexible
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot 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: ---

In the Linux kernel, we have several instances of code exceeding the permitted
stack frame limit (usually 1kb or 2kb per function) when asan-stack=1 is used.

A typical pattern is something like

extern void f_multiple(unsigned char *arg, unsigned long count);
static inline void f_single(unsigned char arg)
{
  f_multiple(&arg, 1);
}
void g(void)
{
 f_single(0);
 f_single(1);
 f_single(2);
 /* ... */
 f_single(100);
}

gcc -Wall -c test.c -O2 -fsanitize=kernel-address --param asan-stack=1
-Wframe-larger-than=0
test.c: In function ‘g’:
test.c:15:1: warning: the frame size of 288 bytes is larger than 0 bytes
[-Wframe-larger-than=]

Here, each call to f_single() allocates a new stack location for its argument,
and adds a 32-byte redzone before and after each byte to catch out-of-bounds
access on the pointer.

In comparison, clang/llvm appears to to better in two ways here:

1. As of
https://github.com/llvm-mirror/llvm/commit/daa1bf3b74054#diff-a6f91f41a097bdf01d36783f8bec4ed6R43,
the redzone size is dynamically adapted to the object size, using only 16 bytes
for variables up to four bytes, but also using much larger redzones for large
stack objects.

2. In some cases, the stack for the temporary objects gets reused between
calls, leading to the stack usage to no longer scale linearly with the number
of calls to the inline helper.

I have a workaround for the kernel that marks all inline functions as
__attribute__((noinline)) when I found a code path that has an excessive stack
usage with asan-stack using an affected gcc version (gcc-4.9 and higher, I have
not tried versions higher than 7.1.1).

It would be good to improve the stack frame allocation here in a future gcc
release so we can turn off that workaround again in the kernel when using newer
compilers.

[Bug middle-end/81705] [8 Regression] UBSAN: yet another false positive

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/81705] [8 Regression] UBSAN: yet another false positive

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri Aug  4 10:33:39 2017
New Revision: 250866

URL: https://gcc.gnu.org/viewcvs?rev=250866&root=gcc&view=rev
Log:
2017-08-04  Richard Biener  

PR middle-end/81705
* fold-const.c (fold_binary_loc): Properly restrict
minus_var0 && minus_var1 case when associating undefined overflow
entities.

* c-c++-common/ubsan/pr81705.c: New testcase.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr81705.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/81706] std::sin vectorization bug

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41923&action=edit
gcc8-pr81706.patch

The reason for why cmath does this is that C++ wants to have sin overloads. 
And the problem is that we have the simd attributes only on ::sinf, ::sin etc.,
but not on __builtin_sinf, __builtin_sin etc.
So, either we change libstdc++ like with this untested patch, or change the
compiler, so that when seeing a matching decl for a builtin which has simd
attribute on it, we duplicate the attribute to the __builtin_* decl too.

--- Comment #3 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 41923 [details]
> gcc8-pr81706.patch
> 
> The reason for why cmath does this is that C++ wants to have sin overloads. 
> And the problem is that we have the simd attributes only on ::sinf, ::sin
> etc., but not on __builtin_sinf, __builtin_sin etc.
> So, either we change libstdc++ like with this untested patch, or change the
> compiler, so that when seeing a matching decl for a builtin which has simd
> attribute on it, we duplicate the attribute to the __builtin_* decl too.

I'd prefer the attached patch to libstdc++ (which is incomplete of course).

[Bug hsa/81713] BIT_FIELD_REF produced by Brig FE do not pass new verification

[pekka.jaaskelainen at parmance dot com]

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

--- Comment #2 from Pekka Jääskeläinen  
---
https://github.com/linehill/gccbrig/commit/feab8a56be8cbe3b95f4dd121e7db4306f75655e.patch
 I will commit this a bit later unless you wish to fix it sooner.

[Bug tree-optimization/81136] [8 Regression] ICE: in vect_update_misalignment_for_peel, at tree-vect-data-refs.c:910

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Fri Aug  4 10:42:53 2017
New Revision: 250870

URL: https://gcc.gnu.org/viewcvs?rev=250870&root=gcc&view=rev
Log:
Pool alignment information for common bases

This patch is a follow-on to the fix for PR81136.  The testcase for that
PR shows that we can (correctly) calculate different base alignments
for two data_references but still tell that their misalignments wrt the
vector size are equal.  This is because we calculate the base alignments
for each dr individually, without looking at the other drs, and in
general the alignment we calculate is only guaranteed if the dr's DR_REF
actually occurs.

This is working as designed, but it does expose a missed opportunity.
We know that if a vectorised loop is reached, all statements in that
loop execute at least once, so it should be safe to pool the alignment
information for all the statements we're vectorising.  The only catch is
that DR_REFs for masked loads and stores only occur if the mask value is
nonzero.  For example, in:

struct s __attribute__((aligned(32))) {
  int misaligner;
  int array[N];
};

int *ptr;
for (int i = 0; i < n; ++i)
  ptr[i] = c[i] ? ((struct s *) (ptr - 1))->array[i] : 0;

we can only guarantee that ptr points to a "struct s" if at least
one c[i] is true.

This patch adds a DR_IS_CONDITIONAL_IN_STMT flag to record whether
the DR_REF is guaranteed to occur every time that the statement
executes to completion.  It then pools the alignment information
for references that aren't conditional in this sense.

2017-08-04  Richard Sandiford  

gcc/
PR tree-optimization/81136
* tree-vectorizer.h: Include tree-hash-traits.h.
(vec_base_alignments): New typedef.
(vec_info): Add a base_alignments field.
(vect_record_base_alignments): Declare.
* tree-data-ref.h (data_reference): Add an is_conditional_in_stmt
field.
(DR_IS_CONDITIONAL_IN_STMT): New macro.
(create_data_ref): Add an is_conditional_in_stmt argument.
* tree-data-ref.c (create_data_ref): Likewise.  Use it to initialize
the is_conditional_in_stmt field.
(data_ref_loc): Add an is_conditional_in_stmt field.
(get_references_in_stmt): Set the is_conditional_in_stmt field.
(find_data_references_in_stmt): Update call to create_data_ref.
(graphite_find_data_references_in_stmt): Likewise.
* tree-ssa-loop-prefetch.c (determine_loop_nest_reuse): Likewise.
* tree-vect-data-refs.c (vect_analyze_data_refs): Likewise.
(vect_record_base_alignment): New function.
(vect_record_base_alignments): Likewise.
(vect_compute_data_ref_alignment): Adjust base_addr and aligned_to
for nested statements even if we fail to compute a misalignment.
Use pooled base alignments for unconditional references.
(vect_find_same_alignment_drs): Compare base addresses instead
of base objects.
(vect_analyze_data_refs_alignment): Call vect_record_base_alignments.
* tree-vect-slp.c (vect_slp_analyze_bb_1): Likewise.

gcc/testsuite/
PR tree-optimization/81136
* gcc.dg/vect/pr81136.c: Add scan test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr81136.c
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-data-ref.h
trunk/gcc/tree-ssa-loop-prefetch.c
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vectorizer.h

[Bug libstdc++/81706] std::sin vectorization bug

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
The C/C++ FE change would be something like:
--- gcc/tree.c.jj   2017-07-29 09:48:40.0 +0200
+++ gcc/tree.c  2017-08-04 12:06:35.636072718 +0200
@@ -5022,8 +5022,8 @@ attribute_value_equal (const_tree attr1,
 TREE_VALUE (attr2)) == 1);
 }

-  if ((flag_openmp || flag_openmp_simd)
-  && TREE_VALUE (attr1) && TREE_VALUE (attr2)
+  if (TREE_VALUE (attr1)
+  && TREE_VALUE (attr2)
   && TREE_CODE (TREE_VALUE (attr1)) == OMP_CLAUSE
   && TREE_CODE (TREE_VALUE (attr2)) == OMP_CLAUSE)
 return omp_declare_simd_clauses_equal (TREE_VALUE (attr1),
--- gcc/cp/decl.c.jj2017-08-01 19:23:10.0 +0200
+++ gcc/cp/decl.c   2017-08-04 12:44:44.773780568 +0200
@@ -2456,6 +2456,35 @@ next_arg:;
  break;
}
}
+
+ tree s = lookup_attribute ("omp declare simd",
+DECL_ATTRIBUTES (newdecl));
+ if (s)
+   {
+ tree b = builtin_decl_explicit (DECL_FUNCTION_CODE (newdecl));
+ if (b)
+   {
+ tree s2 = lookup_attribute ("omp declare simd",
+ DECL_ATTRIBUTES (b));
+ while (s)
+   {
+ tree s3;
+ for (s3 = s2; s3;
+  s3 = lookup_attribute ("omp declare simd",
+ TREE_CHAIN (s3)))
+   if (attribute_value_equal (s, s3))
+ break;
+ if (!s3)
+   {
+ s3 = copy_node (s);
+ TREE_CHAIN (s3) = DECL_ATTRIBUTES (b);
+ DECL_ATTRIBUTES (b) = s3;
+   }
+ s = lookup_attribute ("omp declare simd",
+   TREE_CHAIN (s));
+   }
+   }
+   }
}
   if (new_defines_function)
/* If defining a function declared with other language
--- gcc/c/c-decl.c.jj   2017-07-31 11:31:15.0 +0200
+++ gcc/c/c-decl.c  2017-08-04 12:39:48.113226134 +0200
@@ -2566,6 +2566,36 @@ merge_decls (tree newdecl, tree olddecl,
set_builtin_decl_declared_p (fncode, true);
  break;
}
+
+ tree s = lookup_attribute ("omp declare simd",
+DECL_ATTRIBUTES (newdecl));
+ if (s)
+   {
+ tree b
+   = builtin_decl_explicit (DECL_FUNCTION_CODE (newdecl));
+ if (b)
+   {
+ tree s2 = lookup_attribute ("omp declare simd",
+ DECL_ATTRIBUTES (b));
+ while (s)
+   {
+ tree s3;
+ for (s3 = s2; s3;
+  s3 = lookup_attribute ("omp declare simd",
+ TREE_CHAIN (s3)))
+   if (attribute_value_equal (s, s3))
+ break;
+ if (!s3)
+   {
+ tree s3 = copy_node (s);
+ TREE_CHAIN (s3) = DECL_ATTRIBUTES (b);
+ DECL_ATTRIBUTES (b) = s3;
+   }
+ s = lookup_attribute ("omp declare simd",
+   TREE_CHAIN (s));
+   }
+   }
+   }
}
}
  else

and has the advantage that any other uses of __builtin_* would work that way.
As for the libstdc++-v3 patch, why is it incomplete?  I've just changed the
cases where glibc has
routines with simd attribute (which is only for float/double routines, not for
long double, and
only those changed in the patch).

[Bug libstdc++/81706] std::sin vectorization bug

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Fri, 4 Aug 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81706
> 
> --- Comment #4 from Jakub Jelinek  ---
> The C/C++ FE change would be something like:
> --- gcc/tree.c.jj   2017-07-29 09:48:40.0 +0200
> +++ gcc/tree.c  2017-08-04 12:06:35.636072718 +0200
> @@ -5022,8 +5022,8 @@ attribute_value_equal (const_tree attr1,
>  TREE_VALUE (attr2)) == 1);
>  }
> 
> -  if ((flag_openmp || flag_openmp_simd)
> -  && TREE_VALUE (attr1) && TREE_VALUE (attr2)
> +  if (TREE_VALUE (attr1)
> +  && TREE_VALUE (attr2)
>&& TREE_CODE (TREE_VALUE (attr1)) == OMP_CLAUSE
>&& TREE_CODE (TREE_VALUE (attr2)) == OMP_CLAUSE)
>  return omp_declare_simd_clauses_equal (TREE_VALUE (attr1),
> --- gcc/cp/decl.c.jj2017-08-01 19:23:10.0 +0200
> +++ gcc/cp/decl.c   2017-08-04 12:44:44.773780568 +0200
> @@ -2456,6 +2456,35 @@ next_arg:;
>   break;
> }
> }
> +
> + tree s = lookup_attribute ("omp declare simd",
> +DECL_ATTRIBUTES (newdecl));
> + if (s)
> +   {
> + tree b = builtin_decl_explicit (DECL_FUNCTION_CODE (newdecl));
> + if (b)
> +   {
> + tree s2 = lookup_attribute ("omp declare simd",
> + DECL_ATTRIBUTES (b));
> + while (s)
> +   {
> + tree s3;
> + for (s3 = s2; s3;
> +  s3 = lookup_attribute ("omp declare simd",
> + TREE_CHAIN (s3)))
> +   if (attribute_value_equal (s, s3))
> + break;
> + if (!s3)
> +   {
> + s3 = copy_node (s);
> + TREE_CHAIN (s3) = DECL_ATTRIBUTES (b);
> + DECL_ATTRIBUTES (b) = s3;
> +   }
> + s = lookup_attribute ("omp declare simd",
> +   TREE_CHAIN (s));
> +   }
> +   }
> +   }
> }
>if (new_defines_function)
> /* If defining a function declared with other language
> --- gcc/c/c-decl.c.jj   2017-07-31 11:31:15.0 +0200
> +++ gcc/c/c-decl.c  2017-08-04 12:39:48.113226134 +0200
> @@ -2566,6 +2566,36 @@ merge_decls (tree newdecl, tree olddecl,
> set_builtin_decl_declared_p (fncode, true);
>   break;
> }
> +
> + tree s = lookup_attribute ("omp declare simd",
> +DECL_ATTRIBUTES (newdecl));
> + if (s)
> +   {
> + tree b
> +   = builtin_decl_explicit (DECL_FUNCTION_CODE 
> (newdecl));
> + if (b)
> +   {
> + tree s2 = lookup_attribute ("omp declare simd",
> + DECL_ATTRIBUTES (b));
> + while (s)
> +   {
> + tree s3;
> + for (s3 = s2; s3;
> +  s3 = lookup_attribute ("omp declare simd",
> + TREE_CHAIN (s3)))
> +   if (attribute_value_equal (s, s3))
> + break;
> + if (!s3)
> +   {
> + tree s3 = copy_node (s);
> + TREE_CHAIN (s3) = DECL_ATTRIBUTES (b);
> + DECL_ATTRIBUTES (b) = s3;
> +   }
> + s = lookup_attribute ("omp declare simd",
> +   TREE_CHAIN (s));
> +   }
> +   }
> +   }
> }
> }
>   else
> 
> and has the advantage that any other uses of __builtin_* would work that way.

True, but it removes the ability to avoid the vectorized variant with
using the __builtin_ variant ;)  I think we never move attributes on
the C library header prototypes to our builtins, do we?

> As for the libstdc++-v3 patch, why is it incomplete?  I've just changed the
> cases where glibc has
> routines with simd attribute (which is only for float/double routines, not for
> long double, and
> only those changed in the patch).

Oh, I was just looking for consistent handling -- where we have using ::X
use ::X instead of a builtin.

[Bug c++/81716] New: Bogus -Wlto warning with forward-declared pointers

[sgunderson at bigfoot dot com]

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

Bug ID: 81716
   Summary: Bogus -Wlto warning with forward-declared pointers
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sgunderson at bigfoot dot com
  Target Milestone: ---

Hi,

It seems that if you forward-declare a class in one translation unit (and use
pointers to it), it will count as a different type for LTO detection purposes,
which doesn't sound right. Might there be that it implicitly gets a type of
nullptr_t? Or something else?

gcc version 8.0.0 20170618 (experimental) [trunk revision 249349] (Debian
20170618-1) 

atum17:~> cat test1.cc
class S;
extern S *q[10];

void foo(S *t)
{
  q[0] = nullptr;
}
atum17:~> cat test2.cc
#include 

class S {
  int m;
};
extern S *q[10];

void bar(S *t)
{
printf("%p\n", q[0]);
}
atum17:~> /usr/lib/gcc-snapshot/bin/g++ -Wall -O2 -flto  -o test.so test1.cc
test2.cc   
test2.cc:6:11: warning: type of 'q' does not match original declaration
[-Wlto-type-mismatch]
 extern S *q[10];
   ^
test1.cc:2:11: note: 'q' was previously declared here
 extern S *q[10];
   ^
test1.cc:2:11: note: code may be misoptimized unless -fno-strict-aliasing is
used
/usr/lib/x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status

[Bug libstdc++/81706] std::sin vectorization bug

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #5)
> True, but it removes the ability to avoid the vectorized variant with
> using the __builtin_ variant ;)

Do we ever want to generate less efficient code when using __builtin_* compared
to when not using it?

>  I think we never move attributes on
> the C library header prototypes to our builtins, do we?

We don't right now, but a related precedent is set_builtin_user_assembler_name,
if you do:
double cos (double) __asm ("foobar");
then __builtin_cos will either be expanded inline, or, if calling the library
routine, will call foobar.

> > As for the libstdc++-v3 patch, why is it incomplete?  I've just changed the
> > cases where glibc has
> > routines with simd attribute (which is only for float/double routines, not 
> > for
> > long double, and
> > only those changed in the patch).
> 
> Oh, I was just looking for consistent handling -- where we have using ::X
> use ::X instead of a builtin.

The more we change, the more we risk something breaks, the __builtin_* calls
were there for a reason.

[Bug libstdc++/81706] std::sin vectorization bug

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Fri, 4 Aug 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81706
> 
> --- Comment #6 from Jakub Jelinek  ---
> (In reply to rguent...@suse.de from comment #5)
> > True, but it removes the ability to avoid the vectorized variant with
> > using the __builtin_ variant ;)
> 
> Do we ever want to generate less efficient code when using __builtin_* 
> compared
> to when not using it?

No idea ;)  The simd clone attribute looks like a library implementation
thing and using __builtin_sin doesn't end up using a libraries inline
wrapper called sin () either.

> >  I think we never move attributes on
> > the C library header prototypes to our builtins, do we?
> 
> We don't right now, but a related precedent is 
> set_builtin_user_assembler_name,
> if you do:
> double cos (double) __asm ("foobar");
> then __builtin_cos will either be expanded inline, or, if calling the library
> routine, will call foobar.

I see, that's definitely interesting.  But it won't end up as the
extern inline cos if the library provides one.

Also should __builtin_sin () behavior depend on whether you include
math.h or not?  I think not.

That said, I have no very strong opinion here so you can propose this
to the ml if you like.

> > > As for the libstdc++-v3 patch, why is it incomplete?  I've just changed 
> > > the
> > > cases where glibc has
> > > routines with simd attribute (which is only for float/double routines, 
> > > not for
> > > long double, and
> > > only those changed in the patch).
> > 
> > Oh, I was just looking for consistent handling -- where we have using ::X
> > use ::X instead of a builtin.
> 
> The more we change, the more we risk something breaks, the __builtin_* calls
> were there for a reason.

Sure, but we have to keep matching glibc or other libcs providing 
vectorized variants then and adjust libstdc++ (of past releases?)?

[Bug middle-end/81695] [5/6/7/8 Regression] internal compiler error: in size_binop_loc, at fold-const.c:1768

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Fri Aug  4 11:28:04 2017
New Revision: 250871

URL: https://gcc.gnu.org/viewcvs?rev=250871&root=gcc&view=rev
Log:
PR middle-end/81695
* fold-const.c (fold_indirect_ref_1): For ((int *)&a + 4 -> a[1],
perform the computation in offset_int.

* gcc.dg/pr81695.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr81695.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/81695] [5/6/7 Regression] internal compiler error: in size_binop_loc, at fold-const.c:1768

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[5/6/7/8 Regression]|[5/6/7 Regression] internal
   |internal compiler error: in |compiler error: in
   |size_binop_loc, at  |size_binop_loc, at
   |fold-const.c:1768   |fold-const.c:1768

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

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[dcb314 at hotmail dot com]

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

--- Comment #17 from David Binderman  ---
(In reply to Bill Schmidt from comment #16)
> Check out the code from http://gcc.gnu.org/svn/gcc/branches/gcc-7-branch to
> see if the problem exists there.  From what I can see from this discussion
> it will not.

I confirm I see no problem for the little piece of code with gcc-7 branch. 
Full linux kernel build with gcc-7 branch in progress.

I think I need to understand svn branches and how they relate to 
revision numbers better. I'll do some reading.

[Bug c/81687] Compiler drops label in OpenMP region

[protze at itc dot rwth-aachen.de]

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

--- Comment #5 from Joachim Protze  ---
Jakub, thank you for the quick solution!

I successfully applied your patch to the sources from 7.1 release tarball. 

The two test cases you added are built and linked successfully. I can also
successfully build my other test cases.

[Bug go/81617] mksigtab.sh fails to resolve NSIG with glibc 2.26

[ian at gcc dot gnu.org]

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

--- Comment #5 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Aug  4 12:29:55 2017
New Revision: 250872

URL: https://gcc.gnu.org/viewcvs?rev=250872&root=gcc&view=rev
Log:
PR go/81617
libgo: change mksigtab to recognize glibc 2.26 NSIG expression

Fixes golang/go#21147
Fixes GCC PR 81617

Reviewed-on: https://go-review.googlesource.com/52611

Modified:
branches/gcc-7-branch/libgo/mksigtab.sh

[Bug middle-end/81698] expand_case uses wrong edge as default edge

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 41924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41924&action=edit
gcc8-pr81698.patch

Untested fix.

[Bug c++/81716] Bogus -Wlto warning with forward-declared pointers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Hmm, Honza?  The pointer magic in alias.c should make this well-defined, no? 
Pointer to incomplete == pointer to void.

[Bug c++/81717] New: [c++ concepts] - simple "define function if not defined" code doesn't compile, no errors generated

[jordok at wp dot pl]

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

Bug ID: 81717
   Summary: [c++ concepts] - simple "define function if not
defined" code doesn't compile, no errors generated
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jordok at wp dot pl
  Target Milestone: ---

Created attachment 41925
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41925&action=edit
Minimal code to reproduce

Simple usage of keyword `requires` (C++ concepts) to define a function only if
it's not already defined causes compilation failure.

Code attached is a minimal example of situation in which compilation fails, but
no error is generated.
g++ --version:  g++.exe (MinGW.org GCC-6.3.0-1) 6.3.0
OS : Windows 7 (x64)
Compiling with command: g++ -Wall -fconcepts source.cpp

Which generates no text output and no files. Are generated.


Checked also here: http://coliru.stacked-crooked.com/a/16466d6c732d9f21
Same source code compiled with:
g++ -std=c++17 -fconcepts -Wall -Wextra main.cpp && ./a.out

main.cpp: In function 'bool foo(A)':
main.cpp:6:12: warning: unused parameter 'a' [-Wunused-parameter]
 bool foo(A a) {
^
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

In this IDE (Coliru), g++ --version gives:
g++ (GCC) 7.1.0

[Bug c++/81717] [c++ concepts] - simple "define function if not defined" code doesn't compile, no errors generated

[jordok at wp dot pl]

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

--- Comment #1 from Przemysław Czechowski  ---
Created attachment 41926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41926&action=edit
Generated with g++ -save-temps ...

[Bug c++/81718] New: g++ segfault when creating type alias

[adrienstalain at hotmail dot fr]

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

Bug ID: 81718
   Summary: g++ segfault when creating type alias
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrienstalain at hotmail dot fr
  Target Milestone: ---

Created attachment 41927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41927&action=edit
source file

* command to reproduce
$ g++ file.cc

* Compiler Output:
```
file.cc:8:63: internal compiler error: Segmentation fault
 template  using Ref = TRef::value>;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```


* gcc version 7.1.1 20170630 (GCC) 
* Target: x86_64-pc-linux-gnu
* Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp

I think that in this case, the preprocessed file is not needed.

[Bug c++/81668] LTO ODR warnings are not helpful

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
(In reply to sgunderson from comment #2)

> file; how would I know which one to look
> through to find the two differing definitions?

One thing to try might be to add static_assert() statements to the header(s)
that define these allegedly incompatible symbols (such as struct st_vio) and
using C++ or GCC type traits verify that they and all their members are in fact
of the expected type, independent of any macros (like MYSQL_VIO).  If you can
then compile all the translation units successfully without LTO and still get
errors with LTO that would suggest a bug in GCC and might also give more
information to debug it.  Otherwise, errors without LTO should point to the
translation units that define the symbols in incompatible ways.

[Bug preprocessor/45599] Remove all code applying to obsolete "#pragma once"

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
I'd just go for RESOLVED INVALID. We don't want to remove the code that
implements a supported feature.

[Bug c++/81719] New: Range-based for loop on short fixed size array generates long unrolled loop

[jzwinck at gmail dot com]

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

Bug ID: 81719
   Summary: Range-based for loop on short fixed size array
generates long unrolled loop
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jzwinck at gmail dot com
  Target Milestone: ---

C++11 range-based for loops over arrays of size known at compile time result in
 bloated, branchy, and unreachable code with -O3 optimization.  For example:

typedef int Items[2];

struct ItemArray
{
Items items;
int sum_x2() const;
};

int ItemArray::sum_x2() const
{
int total = 0;
for (int item : items)
{
total += item;
}
return total;
}

Clang compiles the above to [mov, add, ret].  GCC with -O2 compiles it to a few
more than that, and with -O3, a whopping 81 instructions.  Add -march=haswell
and behold about 130 instructions to add two ints.

GCC (all versions, 4 to 7) generates code to handle a variable-sized array up
to about 6 to 14 elements, depending on -march.  The number of elements is
known at compile time to be 2 (other small values also elicit the bug).  GCC
should generate three instructions in both -O2 and -O3.  It actually does, if
sum_x2() is a free function instead of a member function.  The problem also
goes away if you use a C-style loop.

There are lots of permutations of this, including using a range-based for loop
to assign a common value to every element of an array whose size is known at
compile time (120 instructions to assign a single int:
https://godbolt.org/g/BGYggD).

Discussion on Stack Overflow:
https://stackoverflow.com/questions/45496987/gcc-optimizes-fixed-range-based-for-loop-as-if-it-had-longer-variable-length

[Bug hsa/81713] BIT_FIELD_REF produced by Brig FE do not pass new verification

[pekka.jaaskelainen at parmance dot com]

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

--- Comment #3 from Pekka Jääskeläinen  
---
Committed in r250874.

[Bug hsa/81713] BIT_FIELD_REF produced by Brig FE do not pass new verification

[visit0r at gcc dot gnu.org]

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

--- Comment #4 from visit0r at gcc dot gnu.org ---
Author: visit0r
Date: Fri Aug  4 15:50:14 2017
New Revision: 250874

URL: https://gcc.gnu.org/viewcvs?rev=250874&root=gcc&view=rev
Log:
Fix PR 81713
 * brigfrontend/brig-basic-inst-handler.cc: replace build_int_cst with
   bitsize_int in building BIT_FIELD_REF.
 * brigfrontend/brig-code-entry-handler.cc: likewise.


Modified:
trunk/gcc/brig/ChangeLog
trunk/gcc/brig/brigfrontend/brig-basic-inst-handler.cc
trunk/gcc/brig/brigfrontend/brig-code-entry-handler.cc

[Bug target/81720] New: [arm] Invalid code generation

[oarias at knights dot ucf.edu]

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

Bug ID: 81720
   Summary: [arm] Invalid code generation
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oarias at knights dot ucf.edu
  Target Milestone: ---

Created attachment 41928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41928&action=edit
Testcase to generate the bug.

Greetings,

Yesterday, I ran into a problem with the compiler issuing invalid instructions
when compiling code with optimization levels of -O2 or higher. I narrowed it
down to the following testcase [attached]:

int main(void) {
volatile unsigned int read_value = *((volatile unsigned
int*)0x);
return 0;
}

When compiled with

$ arm-none-eabi-gcc -S -c testcase.c -O1 -mthumb -mno-thumb-interwork
-mcpu=cortex-m4

The following assembly is generated [trimmed, see full attachment]:

main:
@ Volatile: function does not return.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
movsr3, #0
ldr r3, [r3]
.inst   0xdeff
.size   main, .-main

The .inst 0xdeff should definitely not be there. Any code that happens after
the dereference takes place is never emitted by the compiler. The dereference
in question is actually valid for the target I am working with [bare-metal ARM
system]. Of course, the assembler happily picks this up and creates object
files with the erroneous code.

I am using the following gcc:

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (Arch Repository) 7.1.0
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.

Which has been compiled as:
$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/7.1.0/lto-wrapper
Target: arm-none-eabi
Configured with: /build/arm-none-eabi-gcc/src/gcc-7-20170504/configure
--target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi
--with-native-system-header-dir=/include --libexecdir=/usr/lib
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib
--with-newlib --with-headers=/usr/arm-none-eabi/include
--with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc
--with-isl --with-libelf --enable-gnu-indirect-function
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='Arch Repository' --with-bugurl=https://bugs.archlinux.org/
--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 7.1.0 (Arch Repository) 


Any advice? Thank you.

Cheers,
Orlando.

[Bug target/81720] [arm] Invalid code generation

[oarias at knights dot ucf.edu]

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

--- Comment #1 from Orlando Arias  ---
Created attachment 41929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41929&action=edit
Compiler output with erroneous assembly listing.

[Bug target/81720] [arm] Invalid code generation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Use -fno-delete-null-pointer-checks as this is a null pointer and deferencing
null pointers are undefined in C.

[Bug target/81720] [arm] Invalid code generation

[oarias at knights dot ucf.edu]

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

Orlando Arias  changed:

   What|Removed |Added

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

--- Comment #3 from Orlando Arias  ---
(In reply to Andrew Pinski from comment #2)
> Use -fno-delete-null-pointer-checks as this is a null pointer and
> deferencing null pointers are undefined in C.

Greetings,

Except that for bare metal targets, address 0 can actually point to a valid
object. As such, the dereference is legal by the C standard itself. What you
are requesting your users to do here is to issue a compiler flag so that code
that they expect to work one way actually performs the way they expect it to.
Furthermore, this particular piece of code worked as expected in previous
versions of the compiler. 

As such, instead of closing this as invalid, my suggestion is to actually
disable this option by default on bare metal targets [which GCC has a quite a
few of, by the way]. Thank you.

Cheers,
Orlando.

[Bug target/81720] [arm] Invalid code generation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
You can have -fno-delete-null-pointer-checks in a specs file which disables it
by default for your target 

Again not a bug.

[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Martin Jambor  ---
This is a devirtualization issue and I tend to think that the correct
fix is to remove the assert.  But I'd like to know what Honza thinks
about it.  The situation is as follows:

Looking into release_ssa dump, we see a static initializer calling a
constructor:

  Type_matcher, Res*>::Type_matcher (&MEM[(struct Fa*)&_x].D.2542,
&_ZTI3Foo);

Note the second parameter, which is a result of typeid C++ operator
(line 97 of the testcase).  My patch with which this starts to ICE is
able to extract aggregate values from its constructor, which comes
down to:

  { &MEM[(void *)&_ZTVN10__cxxabiv117__class_type_infoE + 16B], &_ZTS3Foo }

No field_decl in the constructor is called _vptr, by the way.

The Type_matcher constructor then calls virtual method __do_catch of
that second parameter (called t), which in turn results into the
following gimple sequence:

  ...
  _1 = t_8(D)->_vptr.type_info;
  _2 = *_1;
  ...
  OBJ_TYPE_REF(_2;(const struct type_info)t_8(D)->0) (t_8(D), _3, 0B, 0);

ipa_find_agg_cst_for_param now figures out that at offset zero of t
there is &MEM[(void *)&_ZTVN10__cxxabiv117__class_type_infoE + 16B]
and vtable_pointer_value_to_vtable then identifies
_ZTVN10__cxxabiv117__class_type_infoE as the virtual table.

But that thing has NULL DECL_INITIAL, which we only expect in LTO and
so ICE.  I do not quite understand how it is supposed to be
initialized, there is no construction of it in the dump either.  But
then I do not really know how C++ RTTI works...

But that is the fundamental question.  If we cannot get at the values
of that virtual table, we can only remove the assert, inf not, we can
try to extract them somehow.  Honza?

[Bug target/81720] [arm] Invalid code generation

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Resolution|INVALID |WONTFIX

--- Comment #5 from Richard Earnshaw  ---
Bare metal target compilers should still respect the standard, which is quite
clear that dereferencing NULL is undefined.  Some users of the compiler expect
this behaviour.  It's not about to change.

You have an option you can use, so use it.

[Bug preprocessor/45599] Remove all code applying to obsolete "#pragma once"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #6)
> I'd just go for RESOLVED INVALID. We don't want to remove the code that
> implements a supported feature.

OK, doing so.

[Bug c++/81721] New: precompiled header : internal compiler error: Segmentation fault

[juro.bystricky at intel dot com]

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

Bug ID: 81721
   Summary: precompiled header : internal compiler error:
Segmentation fault
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juro.bystricky at intel dot com
  Target Milestone: ---

Created attachment 41930
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41930&action=edit
symacros.h to corroborate the bug report

Given two simple files "precompiled.h" and "main.cpp" :

$ cat precompiled.h
#ifndef PRECOMPILED_H
#define PRECOMPILED_H

#include 

#endif // PRECOMPILED_H


$ cat main.cpp 
#include "precompiled.h"

class Version {
public:
void major() {}
};
int main(void){ return 0;}

The following sequence will generate a segmentation fault:

$ g++  -x c++-header precompiled.h
$ g++  -H main.cpp

main.cpp:5:2: internal compiler error: Segmentation fault
  void major() {}
  ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


In order to reproduce this, you also need to have /usr/include/sys/sysmacros.h
containing (file attached):


/* Caution: The text of this deprecation message is unquoted, so that
   #symbol can be substituted.  (It is converted to a string by
   __SYSMACROS_DM1.)  This means the message must be a sequence of
   complete pp-tokens; in particular, English contractions (it's,
   can't) cannot be used.

   The message has been manually word-wrapped to fit in 80 columns
   when output by GCC 5 and 6.  The first line is shorter to leave
   some room for the "foo.c:23: warning:" annotation.  */
#define __SYSMACROS_DM(symbol) __SYSMACROS_DM1 \
 (In the GNU C Library, #symbol is defined\n\
  by . For historical compatibility, it is\n\
  currently defined by  as well, but we plan to\n\
  remove this soon.  To use #symbol, include \n\
  directly.  If you did not intend to use a system-defined macro\n\
  #symbol, you should undefine it after including .)

  

After some debugging, I found the segmentation fault was caused in libcpp/lex.c
(cpp_spell_token):

  case SPELL_IDENT:
if (forstring)
  {
  memcpy (buffer, NODE_NAME (token->val.node.spelling),
   NODE_LEN (token->val.node.spelling));
  buffer += NODE_LEN (token->val.node.spelling);
  }

In particular, the code barfs on NODE_NAME (token->val.node.spelling), because
the code implicitly assumes token->type == CPP_NAME.
However, the routine actually gets CPP_NOT (which we got from parsing
sysmacros.h "If you did not intend" sentence).

A ***very*** crude fix/POC is to do something like this in libcpp/lex.c:

  case SPELL_IDENT:
if (forstring)
  {
if (token->type == CPP_NAME)
  {
memcpy (buffer, NODE_NAME (token->val.node.spelling),
NODE_LEN (token->val.node.spelling));
buffer += NODE_LEN (token->val.node.spelling);
  }
if (token->type == CPP_NOT)
  {
memcpy(buffer, "not", 3);
buffer += 3;
break;
  } 
}

There is, of course, a more generic way to handle this for other token->types,
not just CPP_NOT, providing that token->types other than CPP_NAME are legal in
this routine/context and this is where the fix should be applied. 

BTW, there are two workarounds for this error, either pre-compile the headers
with -save-temps:

$ g++ -save-temps -x c++-header precompiled.h
$ g++ -H main.cpp

Or explicitly include #include  before #include "precompiled.h"

We may get this instead:

main.cpp:5:13: warning: In the GNU C Library, "major" is defined
 by . For historical compatibility, it is
 currently defined by  as well, but we plan to
 remove this soon. To use "major", include 
 directly. If you did not intend to use a system-defined macro
 "major", you should undefine it after including .
  void major() {}
 ^~~~


(For more details please see
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11738 )

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #41920|0   |1
is obsolete||

--- Comment #23 from H.J. Lu  ---
Comment on attachment 41920
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41920
A binutils patch

This has been replaced by users/hjl/gprel branch at

https://sourceware.org/git/?p=binutils-gdb.git;a=summary

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hjl.tools at gmail dot com]

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

--- Comment #24 from H.J. Lu  ---
(In reply to Andy Lutomirski from comment #20)
> 
> Can someone elaborate on what the @GPREL suffix actually means?

"%seg:foo@GPREL" is used to address symbol, foo, relative to __gp. foo is
addressed by %seg + offset of foo relative to __gp.  Linker sets __gp to
the middle of GP section which contains definitions of symbols with GPREL
relocations.  Run-time should load address of __gp into segment register,
%seg before accessing foo via "%seg:foo@GPREL".

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hjl.tools at gmail dot com]

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

--- Comment #25 from H.J. Lu  ---
Comment on attachment 41920
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41920
A binutils patch

This has been replaced by users/hjl/gprel/master branch at

https://sourceware.org/git/?p=binutils-gdb.git;a=summary

[Bug target/81720] [arm] Invalid code generation

[oarias at knights dot ucf.edu]

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

--- Comment #6 from Orlando Arias  ---
(In reply to Richard Earnshaw from comment #5)
> Bare metal target compilers should still respect the standard, which is
> quite clear that dereferencing NULL is undefined.  Some users of the
> compiler expect this behaviour.  It's not about to change.
> 
> You have an option you can use, so use it.

Greetings,

I will accept this as proper closure for the bug [not the RESOLVED INVALID from
before]. There are also other ways to work around the issue, such as by
defining symbols in the linker script [how MSP430 does it]. At this point the
compiler can't tell what is being dereferenced and make decisions based on that
[which also explains why I did not run into this issue sooner]. I will however
restate, you are likely [silently in some cases] breaking someone's code by
enforcing this behaviour in bare metal though. Thank you.

Cheers,
Orlando.

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

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Aug  4 17:48:57 2017
New Revision: 250875

URL: https://gcc.gnu.org/viewcvs?rev=250875&root=gcc&view=rev
Log:
i386: Rewrite check for AVX512 features

Add a new file, avx512-check.h, to check all AVX512 features.  The test
is skipped if any requested AVX512 features are unavailable.

PR target/81590
* gcc.target/i386/avx512-check.h: New file.
* gcc.target/i386/avx5124fmaps-check.h: Removed.
* gcc.target/i386/avx5124vnniw-check.h: Likewise.
* gcc.target/i386/avx512cd-check.h: Likewise.
* gcc.target/i386/avx512ifma-check.h: Likewise.
* gcc.target/i386/avx512vbmi-check.h: Likewise.
* gcc.target/i386/avx512vpopcntdq-check.h: Likewise.
* gcc.target/i386/avx512bw-check.h: Rewrite.
* gcc.target/i386/avx512dq-check.h: Likewise.
* gcc.target/i386/avx512er-check.h: Likewise.
* gcc.target/i386/avx512f-check.h: Likewise.
* gcc.target/i386/avx512vl-check.h: Likewise.
* gcc.target/i386/avx512f-helper.h: Include "avx512-check.h"
only.
(test_512): Removed.
(avx512*_test): Likewise.
* gcc.target/i386/avx512f-pr71559.c (TEST): Undef.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512-check.h
Removed:
trunk/gcc/testsuite/gcc.target/i386/avx5124fmaps-check.h
trunk/gcc/testsuite/gcc.target/i386/avx5124vnniw-check.h
trunk/gcc/testsuite/gcc.target/i386/avx512cd-check.h
trunk/gcc/testsuite/gcc.target/i386/avx512ifma-check.h
trunk/gcc/testsuite/gcc.target/i386/avx512vbmi-check.h
trunk/gcc/testsuite/gcc.target/i386/avx512vpopcntdq-check.h
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx512bw-check.h
trunk/gcc/testsuite/gcc.target/i386/avx512dq-check.h
trunk/gcc/testsuite/gcc.target/i386/avx512er-check.h
trunk/gcc/testsuite/gcc.target/i386/avx512f-check.h
trunk/gcc/testsuite/gcc.target/i386/avx512f-helper.h
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr71559.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-check.h

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

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed.

[Bug fortran/44292] [libgfortran ABI breakage] Increase internal size of RECL= of the OPEN statement

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #6 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #5)
> Hi Jerry,
> 
> should we also look at this when we bump the library number?

Sure, but I will have to start over to find the places since things have moved
around.

[Bug fortran/52387] I/O output of write after nonadvancing read

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #13 from Jerry DeLisle  ---
(In reply to Eric Gallager from comment #12)
> (In reply to Dominique d'Humieres from comment #11)
> > > Tobias, any further information on this one?
> > 
> > Any news after more than one year?
> 
> Guess not, closing for being stuck in WAITING for so long

Although we have had no feedback from Standards people, I was actually starting
to look at this a few days ago.  The issue is one of squeezing my personal time
to work on these things. I do think we should unless I discover a major pain to
do it.

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hpa at zytor dot com]

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

--- Comment #26 from H. Peter Anvin  ---
@GPREL (altough it probably should be @GPOFF by analogy with @TPOFF?) gives the
linker an option to distinguish the relocations which need to be adjusted at
link/load time and the ones that don't.

We have our own way of doing that for the Linux kernel, but I'm guessing H.J.
wants a more general solution.

@TPOFF would do the same thing for %fs, so @GPOFF would presumably be used for
%gs (the other way around for i386...)

[Bug c++/81660] Add -Wexceptions warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-04
Summary|Learn GCC -Wexceptions  |Add -Wexceptions warning
 Ever confirmed|0   |1

[Bug c++/81674] gcc cannot detect missing initialisers for fields in constructors

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
There are several bugs about this already, please search for duplicates.

[Bug libstdc++/81482] by-value lambda capture in remove_if

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to kloetzl from comment #2)
> I don't think that the runtime cost of the copies is measurable. My bigger
> issue is that this quirks exposes the internal behaviour of the algorithm
> implementation; In this case the fact that remove_if calls find_if. My
> expectation would be that the standard algorithms are opaque.

It doesn't expose that it calls find_if, it could call some other internal
helper which makes the copies. Just because there are copies doesn't mean
find_if is used.

And changing the algorithm to make no copies would not make it opaque, because
the lack of copies would be observable. As the standard says, whether copies
are made or not is unspecified. So if you want to treat them as opaque, don't
do something that depends on the internal details, use them as suggested by the
note in the standard.

> Another solution might be to implement a compiler warning: If a lambda is
> mutable, captures by value and gets passed to a standard algorithm, produce
> a warning. This will not catch all problematic cases with internal copies of
> the predicate but might avoid the biggest pitfalls.

That seems far too specific a warning to be useful.

[Bug libstdc++/81706] std::sin vectorization bug

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #1)
> The C library sin is vectorized by being appropriately annotated with OpenMP
> SIMD attributes.  This isn't the case for the libstdc++ variant which ends
> up calling
> __builtin_sinf:
> 
>   using ::sin;
> 
>   inline float
>   sin(float __x)
>   { return __builtin_sinf(__x); }
> 
> why the using ::sin and then still dispatching to the builtin?

The using directive makes ::sin(double) available as std::sin(double), that's
orthogonal to calling __builtin_sinf for std::sin(float).

[Bug c++/81608] incompatible declarations of the same extern function at different scopes accepted

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
See PR 69855 comment 2 - is this a dup?

[Bug c++/81634] Some types are incorrectly detected as not standard layout

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-04
 Ever confirmed|0   |1

[Bug tree-optimization/57371] Simplify (double)i != 0

[ygribov at gcc dot gnu.org]

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

--- Comment #5 from Yury Gribov  ---
Author: ygribov
Date: Fri Aug  4 20:29:12 2017
New Revision: 250877

URL: https://gcc.gnu.org/viewcvs?rev=250877&root=gcc&view=rev
Log:
Remove useless floating point casts in comparisons.

2017-08-04  Yury Gribov  

PR tree-optimization/57371

gcc/
* match.pd: New pattern.

gcc/testsuite/
* c-c++-common/pr57371-1.c: New test.
* c-c++-common/pr57371-2.c: New test.
* c-c++-common/pr57371-3.c: New test.
* c-c++-common/pr57371-4.c: New test.
* gcc.dg/pr57371-5.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/pr57371-1.c
trunk/gcc/testsuite/c-c++-common/pr57371-2.c
trunk/gcc/testsuite/c-c++-common/pr57371-3.c
trunk/gcc/testsuite/c-c++-common/pr57371-4.c
trunk/gcc/testsuite/gcc.dg/pr57371-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hjl.tools at gmail dot com]

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

--- Comment #27 from H.J. Lu  ---
(In reply to H. Peter Anvin from comment #26)
> @GPREL (altough it probably should be @GPOFF by analogy with @TPOFF?) gives
> the linker an option to distinguish the relocations which need to be
> adjusted at link/load time and the ones that don't.
> 

The GP offset is fixed at link-time.

> We have our own way of doing that for the Linux kernel, but I'm guessing
> H.J. wants a more general solution.
> 

It makes __seg_fs and __seg_gs easier to use:

[hjl@gnu-6 gprel-1]$ cat x.c
int __seg_gs foo;

int
get_foo (void)
{
  return foo;
}

void
set_foo (int x)
{
  foo = x;
}

static int __seg_gs bar;

int
get_bar (void)
{
  return bar;
}

void
set_bar (int x)
{
  bar = x;
}
[hjl@gnu-6 gprel-1]$ cat foo.c
#define _GNU_SOURCE
#include 
#include 
#include 
#include 

extern int __seg_gs foo;
extern int __gp;
extern int get_foo (void);
extern void set_foo (int);
extern int get_bar (void);
extern void set_bar (int);

int
setup_gp (void *p)
{
  return syscall (SYS_arch_prctl, ARCH_SET_GS, p);
}

int
main ()
{
  setup_gp (&__gp);
  printf ("foo: %d\n", foo);
  printf ("foo: %d\n", get_foo ());
  foo = 30;
  printf ("foo: %d\n", foo);
  printf ("foo: %d\n", get_foo ());
  set_foo (-30);
  printf ("foo: %d\n", foo);
  printf ("foo: %d\n", get_foo ());
  printf ("bar: %d\n", get_bar ());
  set_bar (-30);
  printf ("bar: %d\n", get_bar ());
  return 0;
}
[hjl@gnu-6 gprel-1]$ make
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mgprel -g -O2 -c -o x.o
x.c
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mgprel -g -O2 -c -o foo.o
foo.c
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mgprel -o x x.o foo.o
./x
foo: 0
foo: 0
foo: 30
foo: 30
foo: -30
foo: -30
bar: 0
bar: -30
[hjl@gnu-6 gprel-1]$

[Bug c++/81608] incompatible declarations of the same extern function at different scopes accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
It looks that way.  Thanks for the pointer!

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

[Bug c++/69855] Missing diagnostic for overload that only differs by return type

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

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

[Bug middle-end/81705] [8 Regression] UBSAN: yet another false positive

[babokin at gmail dot com]

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

--- Comment #7 from Dmitry Babokin  ---
That's an excellent new! This means UBSAN becomes finally fully functional in
GCC. No known false positives anymore (on quite large test base). Great job and
thank you!

[Bug c++/79790] [C++17] ICE class template argument deduction failed

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Aug  4 22:13:46 2017
New Revision: 250882

URL: https://gcc.gnu.org/viewcvs?rev=250882&root=gcc&view=rev
Log:
/cp
2017-08-04  Paolo Carlini  

PR c++/79790
* pt.c (do_class_deduction): Handle the case of no viable implicit
deduction guides; simplify the code generating implicit deduction
guides.

/testsuite
2017-08-04  Paolo Carlini  

PR c++/79790
* g++.dg/cpp1z/class-deduction42.C: New.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79790] [C++17] ICE class template argument deduction failed

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Aug  4 22:15:48 2017
New Revision: 250883

URL: https://gcc.gnu.org/viewcvs?rev=250883&root=gcc&view=rev
Log:
/cp
2017-08-04  Paolo Carlini  

PR c++/79790
* pt.c (do_class_deduction): Handle the case of no viable implicit
deduction guides; simplify the code generating implicit deduction
guides.

/testsuite
2017-08-04  Paolo Carlini  

PR c++/79790
* g++.dg/cpp1z/class-deduction42.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction43.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/79790] [C++17] ICE class template argument deduction failed

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #8 from Paolo Carlini  ---
Fixed. Note: new testcase in g++.dg/cpp1z/class-deduction43.C, sorry about the
split commit.

[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450

[jrtc27 at jrtc27 dot com]

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

James Clarke  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e, jrtc27 at jrtc27 dot com

--- Comment #4 from James Clarke  ---
Ping; I just ran into this today on powerpc-linux-gnuspe (a package in Debian
fails to build because of it[0]), and -mtune=native is trying to use "ppc8548"
rather than "8548". Seems like this bug should at least be confirmed.

[0]
https://buildd.debian.org/status/fetch.php?pkg=mptp&arch=powerpcspe&ver=0.2.2-1&stamp=1490178731&raw=0

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[luto at kernel dot org]

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

--- Comment #28 from Andy Lutomirski  ---
hjl, I don't understand what problem you're trying to solve here.  Your patch
makes it relatively straightforward to access global variables using __seg_gs
if the environment sets up the %gs base exactly the way GCC wants it to be set
up.

Why is this useful?

As far as I know, anyone using __seg_gs is trying to do something that is
outside the scope of what normal C code does.  They have some addressing model
that they want to use, and they're probably trying to access data that is *not*
a normal global variable.  On Linux, we want to use __seg_gs to access *percpu*
data, which is allocated by a fancy percpu allocator and relocated by the
kernel's internal relocation processing.  The latter is indeed based on data
emitted by binutils, but it is *not* a conventional ELF relocation engine.  It
will, of course, adapt as needed.

When I do:

extern int __seg_gs [insert more addressing details here?] variable;

int val = variable;

I am *not* trying to access something that would necessarily be credibly
defined by:

int __seg_gs [whatever] variable;

I'm trying to access something that is defined by a mechanism that is
completely invisible to gcc, may involve linker script magic, and may well
involve magic page table manipulation.

Also, please do not consider the stack cookie at %gs:0x28 to be a design
constraint in any respect.  We're talking about using a new GCC version to
solve problems that aren't cleanly solved on existing GCC.  That new GCC can
and should fix the silly stack cookie addressing, too, so it stops getting in
the way.

[Bug c++/81722] New: [7/8 Regression] memory hog building c++ on i686-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 81722
   Summary: [7/8 Regression] memory hog building c++ on
i686-linux-gnu
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41931&action=edit
preprocessed source

seen with the 7.2 release candidate on i686-linux-gnu, configured defaulting to
PIE. Lowering the optimization to -O1 or -O0 doesn't help. extracted from the
mpqc3 package.

$ g++ -std=c++11 -g -O2 -std=c++11 -c twobody_intermediates_ta.ii
In file included from
/<>/src/lib/chemistry/qc/lcao/transform_factory.h:223:0,
 from
/<>/src/lib/chemistry/qc/mbptr12/r12wfnworld.h:40,
 from
/<>/src/lib/chemistry/qc/mbptr12/r12int_eval.h:32,
 from
/<>/src/lib/chemistry/qc/mbptr12/twobody_intermediates_ta.cc:37:
/<>/src/lib/chemistry/qc/lcao/transform_tbint.h:212:89: warning:
dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
   virtual void check_int_symm(double threshold =
TwoBodyMOIntsTransform::zero_integral) throw (ProgrammingError) =0;
   
 ^
virtual memory exhausted: Operation not permitted

breaking in gdb:

#0  0x08905b11 in check_qualified_type (cand=0xc3a65540, base=0xe97c92a0,
type_quals=0)
at ../../src/gcc/tree.c:6536
#1  0x08905c12 in get_qualified_type (type=0xe97c92a0, type_quals=0)
at ../../src/gcc/tree.c:6615
#2  0x08911976 in build_qualified_type (type=0xe97c92a0, type_quals=0)
at ../../src/gcc/tree.c:6630
#3  0x082c300e in cp_build_qualified_type_real (type=0xe97c92a0, type_quals=0,
complain=3)
at ../../src/gcc/cp/tree.c:1250
#4  0x0827e4a0 in same_type_ignoring_top_level_qualifiers_p (type1=0xab82a180, 
type1@entry=0xe97c92a0, type2=type2@entry=0xe97c92a0)
at ../../src/gcc/cp/typeck.c:1466
#5  0x0827e4e8 in same_type_ignoring_top_level_qualifiers_p (type1=0xe97c92a0, 
type2=0xe97c92a0) at ../../src/gcc/cp/typeck.c:1462
#6  0x081c16a2 in is_properly_derived_from (derived=0xe97c92a0,
base=0xe97c92a0)
at ../../src/gcc/cp/call.c:8963
#7  0x081c29e7 in compare_ics (ics1=, ics1@entry=0xb0664a4, 
ics2=, ics2@entry=0xb0655d4) at ../../src/gcc/cp/call.c:9341
#8  0x081c67e5 in joust (cand1=cand1@entry=0xb06651c,
cand2=cand2@entry=0xb06564c, 
warn=warn@entry=false, complain=3) at ../../src/gcc/cp/call.c:9560
#9  0x081c76f2 in joust (complain=3, warn=false, cand2=,
cand1=0xb06651c)
at ../../src/gcc/cp/call.c:9998
#10 tourney (candidates=0xb06651c, complain=complain@entry=3)
at ../../src/gcc/cp/call.c:9962
#11 0x081cd18c in perform_overload_resolution (fn=fn@entry=0xe97dacbc,
args=0x82c9376c, 
candidates=candidates@entry=0xcf0c, any_viable_p=0xcf0b,
complain=3)
at ../../src/gcc/cp/call.c:4152
#12 0x081cd24a in build_new_function_call (fn=0xe97dacbc, args=0xcfec, 
koenig_p=false, complain=3) at ../../src/gcc/cp/call.c:4232
#13 0x082a8ba4 in finish_call_expr (fn=0xe97dacbc, args=0xcfec, 
disallow_virtual=false, koenig_p=false, complain=3)
at ../../src/gcc/cp/semantics.c:2454
#14 0x0820b18a in tsubst_copy_and_build (t=, args=, 
complain=, in_decl=, function_p=, 
integral_constant_expression_p=) at
../../src/gcc/cp/pt.c:17444
#15 0x081ffb6b in tsubst_expr (t=0xe98092ac, args=0x85f0aaf0, complain=3, 
in_decl=0xe97f6f70, integral_constant_expression_p=false)
at ../../src/gcc/cp/pt.c:16550
#16 0x081ff42b in tsubst_expr (t=0xe9805b54, args=0x85f0aaf0, complain=3, 
in_decl=0xe97f6f70, integral_constant_expression_p=false)
at ../../src/gcc/cp/pt.c:15815
#17 0x081ff83f in tsubst_expr (t=, args=0x85f0aaf0, complain=3, 
in_decl=0xe97f6f70, integral_constant_expression_p=false)
at ../../src/gcc/cp/pt.c:15801
#18 0x081ff9f8 in tsubst_expr (t=0xe9802850, args=0x85f0aaf0, complain=3, 
in_decl=0xe97f6f70, integral_constant_expression_p=false)
at ../../src/gcc/cp/pt.c:16027
#19 0x081fe0c5 in instantiate_decl (d=, defer_ok=, 
expl_inst_class_mem_p=) at ../../src/gcc/cp/pt.c:22986
#20 0x0821aaed in instantiate_pending_templates (retries=2) at
../../src/gcc/cp/pt.c:23107
#21 0x08239e3c in c_parse_final_cleanups () at ../../src/gcc/cp/decl2.c:4527
#22 0x086faf1d in compile_file () at ../../src/gcc/toplev.c:467
#23 0x081bc1dd in do_compile () at ../../src/gcc/toplev.c:2003
#24 toplev::main (this=0xd4ae, argc=, argv=)
at ../../src/gcc/toplev.c:2137
#25 0x081be461 in main (argc=20, argv=0xd574) at ../../src/gcc/main.c:39

[Bug c++/81722] [7/8 Regression] memory hog building c++ on i686-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 Target|i686-linux-gnu  |i686-linux-gnu,
   ||arm-linux-gnueabihf

--- Comment #1 from Matthias Klose  ---
seen also on arm-linux-gnueabihf, so maybe 32bit specific. 64bit builds
succeed.

[Bug fortran/81723] New: [7/8 Regression] fortran build doesn't terminate on 64bit targets

[doko at gcc dot gnu.org]

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

Bug ID: 81723
   Summary: [7/8 Regression] fortran build doesn't terminate on
64bit targets
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen when building the cernlib package on 64bit targets. the build succeeds on
32bit targets.

[...]
gfortran csqrtk.F
gfortran cwerf64.F

Session terminated, terminating shell... ...terminated.
make[1]: *** wait: No child processes.  Stop.
make[1]: *** Waiting for unfinished jobs
make[1]: *** wait: No child processes.  Stop.
Makefile:322: recipe for target 'archive/cwerf64.o' failed
make[5]: *** [archive/cwerf64.o] Terminated

complete build logs at
https://launchpad.net/ubuntu/+source/cernlib/20061220+dfsg3-4.3build1

the build doesn't show the command line parameters, need to complete this
report ...

[Bug middle-end/81705] [8 Regression] UBSAN: yet another false positive

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On August 5, 2017 12:01:06 AM GMT+02:00, babokin at gmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81705
>
>--- Comment #7 from Dmitry Babokin  ---
>That's an excellent new! This means UBSAN becomes finally fully
>functional in
>GCC. No known false positives anymore (on quite large test base). Great
>job and
>thank you!

Thank you for reporting the issues!