[Bug inline-asm/87733] local register variable not honored with earlyclobber

[kkylheku at gmail dot com]

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

Kaz Kylheku  changed:

   What|Removed |Added

 CC||kkylheku at gmail dot com

--- Comment #9 from Kaz Kylheku  ---
Can someone kindly point out where this is fixed? What commit(s)?

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw  ---
Created attachment 45979
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45979=edit
moduleinfo alignment

(In reply to John David Anglin from comment #2)
> Might add that there are quite a few unaligned accesses:

I guess that forcing the ModuleInfo type alignment to 1 is not helping (see
patch).

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Might add that there are quite a few unaligned accesses:
runnable.exe(15999): unaligned access to 0x001d080d at
ip=0x00100357
runnable.exe(15999): unaligned access to 0x0021f439 at
ip=0x00100357
runnable.exe(15999): unaligned access to 0x0021f44d at
ip=0x00100357

(gdb) disass 0x10035c-16,0x10035c+16
Dump of assembler code from 0x10034c to 0x10036c:
   0x0010034c
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+0>: 
  ldo 40(sp),sp
   0x00100350
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+4>: 
  stw r19,-20(sp)
   0x00100354
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+8>: 
  ldw 0(r26),ret0
   0x00100358
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+12>:
  bb,<,n ret0,15,0x100374
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+40>
   0x0010035c
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+16>:
  stw r0,-38(sp)
   0x00100360
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+20>:
  ldw -38(sp),ret0
   0x00100364
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+24>:
  stw r0,-34(sp)
   0x00100368
<_D6object10ModuleInfo15importedModulesMxFNaNbNdNiZAyPS6object10ModuleInfo+28>:
  ldw -34(sp),ret1

(gdb) break *0x10035c
Breakpoint 3 at 0x10035c: file ../../../../gcc/libphobos/libdruntime/object.d,
line 1562.

(gdb) list ../../../../gcc/libphobos/libdruntime/object.d:1562
1557return flags & MIunitTest ?
*cast(typeof(return)*)addrOf(MIunitTest) : null;
1558}
1559
1560@property immutable(ModuleInfo*)[] importedModules() nothrow pure
@nogc
1561{
1562if (flags & MIimportedModules)
1563{
1564auto p = cast(size_t*)addrOf(MIimportedModules);
1565return (cast(immutable(ModuleInfo*)*)(p + 1))[0 .. *p];
1566}

[Bug rtl-optimization/89721] __builtin_mffs sometimes optimized away

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

[Bug d/89735] FAIL: gdc.dg/runnable.d -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
(gdb) p obj
$3 = {{{fieldA = 0 '\000', fieldB = 0 '\000', fieldC = 0 '\000'},
_complete = 2}}
(gdb) p 
$4 = (runnable.S186 *) 0xf8d0268c
(gdb) x/x 0xf8d0268c
0xf8d0268c: 0x0002

Looks like endian issue.

[Bug d/89735] New: FAIL: gdc.dg/runnable.d -O0 execution test

[danglin at gcc dot gnu.org]

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

Bug ID: 89735
   Summary: FAIL: gdc.dg/runnable.d   -O0  execution test
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

me/dave/gnu/gcc/objdir/gcc/testsuite/gdc/../../
/home/dave/gnu/gcc/gcc/gcc/tests
uite/gdc.dg/runnable.d -fno-diagnostics-show-caret
-fno-diagnostics-show-line-nu
mbers -fdiagnostics-color=never
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./lib
phobos/libdruntime
-I/home/dave/gnu/gcc/gcc/gcc/testsuite/../../libphobos/libdru
ntime -I/home/dave/gnu/gcc/gcc/gcc/testsuite/../../libphobos/src
-I/home/dave/gn
u/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
-I/home/dave/gnu
/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc
++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/d
ave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -O0
/home/dave/gnu/gcc/gcc/gcc/tests
uite/gdc.dg/imports/runnable.d
-B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libp
hobos/src -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libphobos/src/.libs
-L/ho
me/dave/gnu/gcc/objdir/hppa-linux-gnu/./libphobos/libdruntime/.libs
-L/home/dave
/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs -lm -o ./runnable.exe
PASS: gdc.dg/runnable.d   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libphobo
s/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libphobos/libdruntime/.li
bs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs:/home/dave/
gnu/gcc/objdir/gcc:.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libphobos/src/.l
ibs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libphobos/libdruntime/.libs:/home
/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/
objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home
/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-
linux-gnu/libphobos/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.
libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc
/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc:/home/dave/gnu/gcc/objdir/hpp
a-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libs
sp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libphobos/src/.libs:/home/dave
/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linu
x-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/
./prev-gcc
Execution timeout is: 300
spawn [open ...]
core.exception.AssertError@/home/dave/gnu/gcc/gcc/gcc/testsuite/gdc.dg/runnable.
d(895): Assertion failure

../../../../gcc/libphobos/libdruntime/gcc/deh.d:499 _d_throw [0xf69b7]
../../../../gcc/libphobos/libdruntime/core/exception.d:441 onAssertError
[0xdd1a
b]
../../../../gcc/libphobos/libdruntime/core/exception.d:641 _d_assert [0xddc47]
??:? void runnable.check186(const(runnable.S186), byte) [0x1ce43]
??:? void runnable.test186a(uint) [0x1d04f]
??:? void runnable.test186() [0x1d423]
??:? _Dmain [0x23987]
1.00
2.00
3.00
Construct: this=0xfa1248d0
Check: this=0xfa1248d0 a=0xfa1248d0
Check: this=0xfa1248d0 a=0xfa1248d0
Here
this=0xf8bf90b8
this=0xf8bf90b8
FAIL: gdc.dg/runnable.d   -O0  execution test

(gdb) break /home/dave/gnu/gcc/gcc/gcc/testsuite/gdc.dg/runnable.d:895
Breakpoint 2 at 0x1ccf4: file
/home/dave/gnu/gcc/gcc/gcc/testsuite/gdc.dg/runnable.d, line 895.
(gdb) r
Starting program: /home/dave/gnu/gcc/objdir/gcc/testsuite/gdc/runnable.exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/hppa-linux-gnu/libthread_db.so.1".
[New Thread 0xf77e7100 (LWP 16000)]
[New Thread 0xf6fe6100 (LWP 16001)]
[New Thread 0xf67e5100 (LWP 16002)]
1.00
2.00
3.00
Construct: this=0xf8d02610
Check: this=0xf8d02610 a=0xf8d02610
Check: this=0xf8d02610 a=0xf8d02610
Here
this=0xf8bf90b8
this=0xf8bf90b8

Thread 1 "runnable.exe" hit Breakpoint 2,
runnable.check186(const(runnable.S186), byte) (obj=..., fieldB=0 '\000')
at /home/dave/gnu/gcc/gcc/gcc/testsuite/gdc.dg/runnable.d:895
895 assert(obj.fieldA == 2);
(gdb) p obj
$1 = {{{fieldA = 0 '\000', fieldB = 0 '\000', fieldC = 0 '\000'},
_complete = 2}}
(gdb) bt
#0  runnable.check186(const(runnable.S186), byte) (obj=..., fieldB=0 '\000')
at /home/dave/gnu/gcc/gcc/gcc/testsuite/gdc.dg/runnable.d:895
#1  0x0001cf60 in runnable.test186a(uint) (val=2)
at /home/dave/gnu/gcc/gcc/gcc/testsuite/gdc.dg/runnable.d:905
#2  0x0001d334 in runnable.test186() ()
at /home/dave/gnu/gcc/gcc/gcc/testsuite/gdc.dg/runnable.d:923
#3  

[Bug c/89734] const qualifier on return type not erased inside __typeof__

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
This doesn't need typeof.  The following much simpler test demonstrates 
this regression.

typedef const int CI;
CI f (void);
const int f (void);

[Bug c/39985] Type qualifiers not actually ignored on function return type

[pskocik at gmail dot com]

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

pskocik at gmail dot com changed:

   What|Removed |Added

 CC||pskocik at gmail dot com

--- Comment #8 from pskocik at gmail dot com ---
(In reply to Eric Gallager from comment #6)
> (In reply to jos...@codesourcery.com from comment #5)
> > In C, in C11 mode, type qualifiers are completely ignored on function 
> > return types, including not affecting type compatibility, after my commit:
> > 
> > r236231 | jsm28 | 2016-05-13 21:35:39 + (Fri, 13 May 2016) | 46 lines
> > 
> > Implement C11 DR#423 resolution (ignore function return type qualifiers).
> 
> So can this be closed then?

As of 8.2, it doesn't appear to work properly yet.

It looks like the top level qualifs on the return type aren't being ignored
if the return type is sealed in a typedef or __typeof.

typedef int const ic_tp;
int const f(); //ignores the const here
ic_tp f(); //breaks because the const isn't ignored here

Same with:

int const f(); //ignored here
__typeof(int const) f(); //not ignored here

The examples in Godbolt: https://gcc.godbolt.org/z/GVvkmJ

[Bug c/89734] New: const qualifier on return type not erased inside __typeof__

[pascal_cuoq at hotmail dot com]

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

Bug ID: 89734
   Summary: const qualifier on return type not erased inside
__typeof__
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pascal_cuoq at hotmail dot com
  Target Milestone: ---

I think that this report is related to the implementation of a resolution from
DR 423 in 2017: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985#c5

I would expect the following C program to be accepted:

#define CONST(x) __typeof__(const __typeof__(x))
#define POINTER(x) __typeof__(__typeof__(x) *)
#define ARRAY(x, n) __typeof__(__typeof__(x)[n])
#define FUNCTION(x, y) __typeof__(__typeof__(y)(__typeof__(x)))

extern int (* const p(int))[5];

FUNCTION(int, CONST(POINTER(ARRAY(int,5 p;

According to Compiler Explorer, it is accepted by Clang, and by GCC version up
to 6.3, but not by GCC version 7 and above, which complains:

error: conflicting types for 'p'

Compiler Explorer link: https://gcc.godbolt.org/z/c_9JTu

This may be related to how function types are handled inside __typeof__. If the
const attribute is not erased inside __typeof__, then it would not match the
type build for a plain declaration, where the const attribute is erased since
revision 236231.

If that were the case, then a solution would be to make the __typeof__
extension more uniform with the rest of the language.

Find the right hire

[Melvin]

Find the right hire






















   





  
Should you wish not to receive any promotional email in the future, please 
click UNSUBSCRIBE.如閣下不欲收到本公司的宣傳郵件，請按不訂閱。
  

[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
The following patch generates errors for the testcases when one
of the TRANSFER arguments is a procedure (but not a pointer):

Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 269717)
+++ gcc/fortran/check.c (working copy)
@@ -5551,6 +5551,24 @@
   return false;
 }

+  if (source->ts.type == BT_PROCEDURE
+  && !source->symtree->n.sym->attr.pointer)
+{
+  gfc_error ("% argument of % intrinsic at %L "
+ "must not be a %s", >where,
+gfc_basic_typename (source->ts.type));
+  return false;
+}
+
+  if (mold->ts.type == BT_PROCEDURE
+  && !mold->symtree->n.sym->attr.pointer)
+{
+  gfc_error ("% argument of % intrinsic at %L "
+ "must not be a %s", >where,
+gfc_basic_typename (mold->ts.type));
+  return false;
+}
+
   if (size != NULL)
 {
   if (!type_check (size, 2, BT_INTEGER))

Needs regtesting.

[Bug c++/89729] [g++ 8] -Wclass-memaccess warning

[chantry.xavier at gmail dot com]

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

--- Comment #3 from Xavier  ---
(In reply to Martin Sebor from comment #1)

Thanks a lot for the detailed explanation, it's much clearer now.
Wclass-memaccess does look sane.
script_data_t is apparently manipulated from both C and C++ code, which might
explain why it's done this way.
We can either disable the warning in this case or use a (void *) so no problem.

(In reply to Jonathan Wakely from comment #2)
> You should use the gcc-help mailing list for questions like this, because
> you're not reporting a bug.

You're right, sorry about that.

[Bug libstdc++/77691] [7/8/9 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[danglin at gcc dot gnu.org]

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

--- Comment #31 from John David Anglin  ---
The patch didn't the fail on hppa64-hp-hpux11.11 but the error has changed:

/test/gnu/gcc/gcc/libstdc++-v3/testsuite/experimental/memory_resource/resource_a
daptor.cc:64: void test05(): Assertion 'aligned(p)' failed.
FAIL: experimental/memory_resource/resource_adaptor.cc execution test

The patched also introduced:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89732

[Bug fortran/60091] Misleading error messages in rank-2 pointer assignment to rank-1 target

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||anlauf at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from anlauf at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/60091] Misleading error messages in rank-2 pointer assignment to rank-1 target

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Fri Mar 15 22:20:20 2019
New Revision: 269717

URL: https://gcc.gnu.org/viewcvs?rev=269717=gcc=rev
Log:
2019-03-15  Harald Anlauf  

PR fortran/60091
* expr.c (gfc_check_pointer_assign): Correct and improve error
messages for invalid pointer assignments.

PR fortran/60091
* gfortran.dg/pointer_remapping_3.f08: Adjust error messages.
* gfortran.dg/pointer_remapping_7.f90: Adjust error message.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pointer_remapping_3.f08
trunk/gcc/testsuite/gfortran.dg/pointer_remapping_7.f90

[Bug rtl-optimization/89721] __builtin_mffs sometimes optimized away

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Fixed on trunk so far.

[Bug rtl-optimization/89721] __builtin_mffs sometimes optimized away

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Fri Mar 15 22:09:15 2019
New Revision: 269716

URL: https://gcc.gnu.org/viewcvs?rev=269716=gcc=rev
Log:
LRA: side_effects_p stmts' output is not invariant (PR89721)

PR89721 shows LRA treating an unspec_volatile's result as invariant,
which of course isn't correct.  This patch fixes it.


PR rtl-optimization/89721
* lra-constraints (invariant_p): Return false if side_effects_p holds.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug libstdc++/89732] FAIL: experimental/memory_resource/new_delete_resource.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Yup, that would explain the failure then. I'll make the changes to this test to
work with that patch.

[Bug rtl-optimization/89487] [7/8 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hgreving at google dot com

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

[Bug inline-asm/89731] [7/8 Regression] GCC crashing when mixing AVX inline asm with macros and C.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Jakub Jelinek  ---
Actually, PR89487 is the real fix for this.

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

[Bug rtl-optimization/89487] [7/8 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.4 |7.5
Summary|[8 Regression] ICE in   |[7/8 Regression] ICE in
   |expand_expr_addr_expr_1, at |expand_expr_addr_expr_1, at
   |expr.c:7993 |expr.c:7993

[Bug inline-asm/89731] [7/8 Regression] GCC crashing when mixing AVX inline asm with macros and C.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |7.5
Summary|GCC crashing when mixing|[7/8 Regression] GCC
   |AVX inline asm with macros  |crashing when mixing AVX
   |and C.  |inline asm with macros and
   ||C.

--- Comment #5 from Jakub Jelinek  ---
Started to ICE with r221532.

[Bug inline-asm/89731] GCC crashing when mixing AVX inline asm with macros and C.

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Reduced testcase:

typedef int __v8si __attribute__((__vector_size__(8 * sizeof (int;
void bar (int);

void
foo (void)
{
  register __v8si b asm("ymm0");
  for (int c = 0; c < 4; ++c)
bar (b[c]);
}

[Bug libstdc++/89732] FAIL: experimental/memory_resource/new_delete_resource.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2019-03-15 4:50 p.m., redi at gcc dot gnu.org wrote:
> Have you applied the patch from Bug 77691 comment 30?
I have it installed.

[Bug inline-asm/89731] GCC crashing when mixing AVX inline asm with macros and C.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Doesn't reproduce on the trunk starting with r269361, likely just latent
though.

[Bug libstdc++/89732] FAIL: experimental/memory_resource/new_delete_resource.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to John David Anglin from comment #0)
> Revision 269442 was okay.

Are you sure? Neither the test nor the code it tests have changed since then.

Have you applied the patch from Bug 77691 comment 30? That could cause this (by
invalidating the assumption in the test, meaning this test needs to be
corrected if we commit that patch).

[Bug regression/89733] New: [7/8/9 Regression] False positive -Wuninitialized in C++14+ mode

[nok.raven at gmail dot com]

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

Bug ID: 89733
   Summary: [7/8/9 Regression] False positive -Wuninitialized in
C++14+ mode
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nok.raven at gmail dot com
  Target Milestone: ---
  Host: x86_64
Target: x86_64

Hello,

The -Wuninitialized warning comes from one of Boost.Spirit tests in C++14+ mode
with GCC 7/8/9. GCC's ASan and UBSan does not detect violations. Clang's
-Wuninitialized and sanitizers also report nothing.

I have double checked the things, the member
(https://github.com/boostorg/spirit/blob/ae49b5c3d15d9105ce4d0f10378c7693dcaa5ae6/include/boost/spirit/home/lex/lexer/lexertl/functor_data.hpp#L400)
is not explicitly initialized in the class constructor (with explicit
initialization the warning is gone), but it is not accessed before an
assignment (checked by wrapping the value type with a boost::optional and
replacing reads to .value(), warning is already gone with the change).

I am sorry I do not have a minimal repro. Every time I try to reduce the test,
the warning either turns into -Wmaybe-uninitialized or is gone. The shortest
one I got is https://wandbox.org/permlink/yTLyG6C6arXfFlJz

```
#include 
#include 
#include 

namespace lex = boost::spirit::lex;
namespace qi = boost::spirit::qi;
namespace mpl = boost::mpl;

typedef lex::lexertl::token > token_type;
typedef lex::lexertl::actor_lexer lexer_type;
typedef lex::lexer::iterator_type iterator_type;

int main()
{
char const* s = "123.";
char const* first = s;
char const* last  = s + std::strlen(s);

lex::lexer lexer;
lex::token_def integer; integer = "[0-9]+"; lexer.self += integer;
qi::rule grammar = integer;

lex::tokenize_and_parse(first, last, lexer, grammar);
}
```

$ g++ -O1 -std=c++14 repro.cpp -I. -Werror=uninitialized
In file included from ./boost/spirit/home/lex/lexer/lexertl/lexer.hpp:22,
 from ./boost/spirit/home/lex/lexer_lexertl.hpp:16,
 from ./boost/spirit/include/lex_lexertl.hpp:16,
 from repro.cpp:1:
./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp: In function 'bool
boost::spirit::lex::tokenize_and_parse(Iterator&, Iterator, const Lexer&, const
ParserExpr&) [with Iterator = const char*; Lexer =
boost::spirit::lex::lexer > > >; ParserExpr =
boost::spirit::qi::rule >, boost::spirit::lex::lexertl::detail::data,
const char*, mpl_::bool_, mpl_::bool_ > > >]':
./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:276:15: error:
'.boost::spirit::lex::lexertl::detail::data, mpl_::bool_,
boost::variant,
boost::iterator_range, boost::mpl::l_item, int,
boost::mpl::l_end> > > > >::end_' is used uninitialized in this function
[-Werror=uninitialized]
 class data
   ^~~~

For a full test: Download Boost 1.69, unpack it, invoke

cd boost_1_69_0
./bootstrap
./b2 headers
g++ -O1 -std=c++14 libs/spirit/test/lex/regression_syntax_error.cpp -I.
-Werror=uninitialized


PS: There are bunch of -Wmaybe-uninitialized warnings related to
boost::optional usage in other tests on master (Boost 1.70 Beta) that also
seems to be false positives.

[Bug c++/89705] [7/8/9 Regression] ICE in convert_like_real, at cp/call.c:7334

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Another testcase with an lvalue reference:

struct W { operator const volatile int(); };
const int& i = W();

But I think all those testcases are invalid, because [dcl.init.ref] says: If T1
is reference-related to T2, cv1 shall be the same cv-qualification as, or
greater cv-qualification than, cv2.

[Bug c++/89729] [g++ 8] -Wclass-memaccess warning

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Xavier from comment #0)
> There are already many bugs about this one, but since I am not expert on
> C++, I would like to have your advice.

[...]

> What's the correct way in gnu++98 to do this ?

[...]

> The other bugs mention cast to void * as a workaround, this does seem to
> work, even with a simple C cast. Is this also acceptable in my case for both
> memset and memcpy ?

You should use the gcc-help mailing list for questions like this, because
you're not reporting a bug.

[Bug inline-asm/89731] GCC crashing when mixing AVX inline asm with macros and C.

[hgreving at google dot com]

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

--- Comment #2 from Hendrik Greving  ---
Created attachment 45978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45978=edit
Pre-processed test case.

[Bug inline-asm/89731] GCC crashing when mixing AVX inline asm with macros and C.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-03-15
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
waiting for the testcase.

[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline

[kelvin at gcc dot gnu.org]

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

--- Comment #16 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Fri Mar 15 19:52:43 2019
New Revision: 269715

URL: https://gcc.gnu.org/viewcvs?rev=269715=gcc=rev
Log:
gcc/ChangeLog:

2019-03-15  Kelvin Nilsen  

PR target/87532
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
When handling vec_extract, use modular arithmetic to allow
constant selectors greater than vector length.
* config/rs6000/rs6000.c (rs6000_expand_vector_extract): Allow
V1TImode vectors to have constant selector values greater than 0.
Use modular arithmetic to compute vector index.
(rs6000_split_vec_extract_var): Use modular arithmetic to compute
index for in-memory vectors.  Correct code generation for
in-register vectors.
(altivec_expand_vec_ext_builtin): Use modular arithmetic to
compute index.

gcc/testsuite/ChangeLog:

2019-03-15  Kelvin Nilsen  

PR target/87532
* gcc.target/powerpc/fold-vec-extract-char.p8.c: Modify expected
instruction selection.
* gcc.target/powerpc/fold-vec-extract-int.p8.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-short.p8.c: Likewise.
* gcc.target/powerpc/pr87532-mc.c: New test.
* gcc.target/powerpc/pr87532.c: New test.
* gcc.target/powerpc/vec-extract-v16qiu-v2.h: New test.
* gcc.target/powerpc/vec-extract-v16qiu-v2a.c: New test.
* gcc.target/powerpc/vec-extract-v16qiu-v2b.c: New test.
* gcc.target/powerpc/vsx-builtin-10a.c: New test.
* gcc.target/powerpc/vsx-builtin-10b.c: New test.
* gcc.target/powerpc/vsx-builtin-11a.c: New test.
* gcc.target/powerpc/vsx-builtin-11b.c: New test.
* gcc.target/powerpc/vsx-builtin-12a.c: New test.
* gcc.target/powerpc/vsx-builtin-12b.c: New test.
* gcc.target/powerpc/vsx-builtin-13a.c: New test.
* gcc.target/powerpc/vsx-builtin-13b.c: New test.
* gcc.target/powerpc/vsx-builtin-14a.c: New test.
* gcc.target/powerpc/vsx-builtin-14b.c: New test.
* gcc.target/powerpc/vsx-builtin-15a.c: New test.
* gcc.target/powerpc/vsx-builtin-15b.c: New test.
* gcc.target/powerpc/vsx-builtin-16a.c: New test.
* gcc.target/powerpc/vsx-builtin-16b.c: New test.
* gcc.target/powerpc/vsx-builtin-17a.c: New test.
* gcc.target/powerpc/vsx-builtin-17b.c: New test.
* gcc.target/powerpc/vsx-builtin-18a.c: New test.
* gcc.target/powerpc/vsx-builtin-18b.c: New test.
* gcc.target/powerpc/vsx-builtin-19a.c: New test.
* gcc.target/powerpc/vsx-builtin-19b.c: New test.
* gcc.target/powerpc/vsx-builtin-20a.c: New test.
* gcc.target/powerpc/vsx-builtin-20b.c: New test.
* gcc.target/powerpc/vsx-builtin-9a.c: New test.
* gcc.target/powerpc/vsx-builtin-9b.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr87532-mc.c
trunk/gcc/testsuite/gcc.target/powerpc/pr87532.c
trunk/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2.h
trunk/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2a.c
trunk/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-19a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-19b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-9a.c
trunk/gcc/testsuite/gcc.target/powerpc/vsx-builtin-9b.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p8.c

[Bug libstdc++/89732] New: FAIL: experimental/memory_resource/new_delete_resource.cc execution test

[danglin at gcc dot gnu.org]

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

Bug ID: 89732
   Summary: FAIL:
experimental/memory_resource/new_delete_resource.cc
execution test
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gc
c -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/tes
t/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/objd
ir/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu64/gcc/gcc-9/hppa6
4-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-9/hppa64-hp-hpux11.11/lib/ -isystem
/op
t/gnu64/gcc/gcc-9/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-9/hppa
64-hp-hpux11.11/sys-include -fchecking=1
-B/test/gnu/gcc/objdir/hppa64-hp-hpux11
.11/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column
-ffunction-sect
ions -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++
-I/test/gnu/gcc/objdir/h
ppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objd
ir/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/lib
supc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/lib
stdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc
-include bits/stdc++.h -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/filesystem/.libs
-lm -o ./new_delete_resource.exe
PASS: experimental/memory_resource/new_delete_resource.cc (test for excess
errors)
Setting LD_LIBRARY_PATH to
:/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
spawn [open ...]
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc:130:
void test03(): Assertion 'bytes_allocated == max(3, alignof(short))' failed.
FAIL: experimental/memory_resource/new_delete_resource.cc execution test
extra_tool_flags are:
  -include bits/stdc++.h

Revision 269442 was okay.

[Bug inline-asm/89731] New: GCC crashing when mixing AVX inline asm with macros and C.

[hgreving at google dot com]

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

Bug ID: 89731
   Summary: GCC crashing when mixing AVX inline asm with macros
and C.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hgreving at google dot com
  Target Milestone: ---

gcc --version
gcc (Debian 7.3.0-5) 7.3.0

Reproducer, see attachment:

gcc -o test -m64 -mavx -c -O3 x86_code.i
/usr/local/google/home/hgreving/dynamorio/src/core/arch/x86_code.c: In function
‘write_ymm_aux’:
/usr/local/google/home/hgreving/dynamorio/src/core/arch/x86_code.c:569:355:
internal compiler error: in expand_expr_addr_expr_1, at expr.c:7855
 CASE_MOVE_TO_YMM_VEX(buffer, 0)
   
   
   
   
   ^ 
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c/89667] initializers for character string arrays (char *[]) appear to reside in protected storage

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Fri, 15 Mar 2019, rick at regreer dot net wrote:

> But can you explain why:
> 
>  static char *foo[] = { (char []){"this compiles ..."} };
> 
>  void but() { static char *bar[] = { (char []){"this doesn't!"} }; }
> 
> I.e, why is the (char []) a non-constant element when it appears in a
> function?

A compound literal outside a function is an object with static storage 
duration, so has a constant address.

A compound literal inside a function is an object with automatic storage 
duration, so has an address (on the stack) only determined on entry to the 
function, so cannot be used in a static initializer.

[Bug c++/87481] [7/8/9 Regression] Endless loop with optimisation in C++17

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 45977
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45977=edit
gcc9-pr87481.patch

Updated patch based on mailing list and IRC feedback.

[Bug tree-optimization/89730] New: -flive-patching=inline-only-static should grant always_inline attribute for extern function

[qinzhao at gcc dot gnu.org]

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

Bug ID: 89730
   Summary: -flive-patching=inline-only-static should grant
always_inline attribute for extern function
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

for the following small testing case:

extern int sum, n, m;
extern inline __attribute__((always_inline)) int foo (int a);

inline __attribute__((always_inline)) int foo (int a) 
{
  return a + n;
}

static int bar (int b)
{
  return b * m;
}

int main()
{
  sum = foo (m) + bar (n); 
  return 0;
}

with the latest upstream gcc9:

/home/qinzhao/Install/latest/bin/gcc -O3 -flive-patching=inline-only-static
-fdump-tree-einline -fdump-ipa-inline -fopt-info-inline-all=inline.txt t.c
t.c: In function ‘main’:
t.c:7:43: error: inlining failed in call to always_inline ‘foo’: function has
external linkage when the user requests only inlining static for live patching
7 | inline __attribute__((always_inline)) int foo (int a)
  |   ^~~
t.c:20:9: note: called from here
   20 |   sum = foo (m) + bar (n);
  | ^~~
t.c:7:43: error: inlining failed in call to always_inline ‘foo’: function has
external linkage when the user requests only inlining static for live patching
7 | inline __attribute__((always_inline)) int foo (int a)
  |   ^~~
t.c:20:9: note: called from here
   20 |   sum = foo (m) + bar (n);
  | ^~~

We should grant extern alway_inline routine to be inlined even with
-flive-patching=inline-only-static.

[Bug d/88724] FAIL: gdc.dg/compilable.d -O0 (test for excess errors)

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw  ---
(In reply to dave.anglin from comment #2)
> On 2019-03-15 12:48 p.m., ibuclaw at gdcproject dot org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88724
> >
> > --- Comment #1 from Iain Buclaw  ---
> > The system headers (stdlib.h, time.h, stdint.h, etc...) will need to be 
> > ported
> > to druntime, are these available anywhere?
> I guess I could send headers for hpux11.11 to you privately.  They are not
> online.  The machine
> I use for testing isn't available for general access.  I could check around.
> 
> At the moment, I'm more concerned about the 32-bit test failures for d on
> linux.  For some reason,
> the test results on 64-bit hpux are way better on 32-bit linux or hpux:
> https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg01307.html
> https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg02011.html

That would be because of check_effective_target_d_runtime.  If false, then all
runnable tests would be demoted to compile-only.

[Bug d/88724] FAIL: gdc.dg/compilable.d -O0 (test for excess errors)

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2019-03-15 12:48 p.m., ibuclaw at gdcproject dot org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88724
>
> --- Comment #1 from Iain Buclaw  ---
> The system headers (stdlib.h, time.h, stdint.h, etc...) will need to be ported
> to druntime, are these available anywhere?
I guess I could send headers for hpux11.11 to you privately.  They are not
online.  The machine
I use for testing isn't available for general access.  I could check around.

At the moment, I'm more concerned about the 32-bit test failures for d on
linux.  For some reason,
the test results on 64-bit hpux are way better on 32-bit linux or hpux:
https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg01307.html
https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg02011.html

[Bug d/88724] FAIL: gdc.dg/compilable.d -O0 (test for excess errors)

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
The system headers (stdlib.h, time.h, stdint.h, etc...) will need to be ported
to druntime, are these available anywhere?

[Bug c++/60702] thread_local initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Created attachment 45976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45976=edit
gcc9-pr60702.patch

Untested fix.

[Bug c++/89729] [g++ 8] -Wclass-memaccess warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Declaring a default ctor for a class like script_data_t in attachment 45975
means that objects of the class need to be constructed and initialized using
the default ctor.  Calling memset to zero-out an object of such a class
suggests the caller might be treating the class as a plain old C struct which
it shouldn't be: it could bypass the ctor and fail to begin the object's
lifetime or break invariants previously established by the ctor.

Similarly, declaring a class copy assignment operator private means that the
class is not meant to be copy-assignable.  Calling memcpy on an object of such
a class could violate invariants established by its ctor/assignment operator.

The warning points out these potential bugs.  It's meant to help avoid them
especially when C code is transitioning to C++, e.g., when an object of C++
class is added as a member of a plain C struct (imagine what might happen if a
std::string member were added to script_data_t).

In the test case in attachment 45975, d2 is initialized on declaration:

  void script_data_init_empty(script_data_t *data)
  {
script_data_t d2; // ctor initializes (e.g., clears)
// p_clear(, 1);   // should not be necessary (done by ctor)
// memcpy(data, , sizeof(d2));   // unsafe

// if data points to an already initialized script_data_t object
// destroy it first:
data->~script_data_t()

// ...and then create a new object in its place by using
// the implicitly provided copy ctor (or just create a new
// one if data points to uninitialized memory):
new (data) script_data_t (d2);
  }

But judging by the name of the function I would expect it to be a no-op in C++:
there should be no need to call it to initialize a script_data_t object: its
ctor does it.  Simply declaring an object of the class initializes it.  The
same is true for objects dynamically allocated via a new expression.  If you
allocate memory for those objects using malloc then initialize them using
placement new as shown above (and remember to destroy them by explicitly
calling the dtor before freeing the memory.

It's also possible (even likely) that script_data_t is poorly designed and that
calling memset/memcpy on it is, in fact, safe and necessary.  A class that
declares a private copy assignment probably isn't meant to be constructible
either and so it should also make its copy constructor inaccessible (by
declaring it private in C++ 98).  Either way, when dealing with a poorly
designed class that can't be easily fixed, casting the pointer to it to void*
before passing it to memcpy/memset suppresses the warning:

  #define p_clear(p, count)   
\
({ (typeof(*(p)) *)memset((void*)(p), 0, sizeof(*(p)) * (count)); })

You can also use #pragma GCC diagnostic to suppress the warning before each
such access (and restore it afterwards):

void script_data_init_empty(script_data_t *data)
{
script_data_t d2;
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wclass-memaccess"
p_clear(, 1); // no warning here
#pragma GCC diagnostic pop

memcpy(data, , sizeof(d2));   // warning here
}

[Bug c++/60702] thread_local initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
When looking at GIMPLE dump on:
struct S { S (); ~S (); int i; };
thread_local S s;
struct T { static thread_local S u; } t;
thread_local S T::u;

S *f1 () { return  }
int *f2 () { return  }
S *f3 () { return  }
int *f4 () { return  }
S *f5 () { return ::u; }
int *f6 () { return ::u.i; }
template 
S *f7 () { return  }
template 
int *f8 () { return  }
template 
S *f9 () { return  }
template 
int *f10 () { return  }
template 
S *f11 () { return ::u; }
template 
int *f12 () { return ::u.i; }
void foo ()
{
  f7<0> ();
  f8<0> ();
  f9<0> ();
  f10<0> ();
  f11<0> ();
  f12<0> ();
}

the following patch fixes all but f12:
--- gcc/cp/typeck.c.jj  2019-03-13 21:21:27.0 +0100
+++ gcc/cp/typeck.c 2019-03-15 16:23:27.582046214 +0100
@@ -2443,6 +2443,16 @@ build_class_member_access_expr (cp_expr
   /* A static data member.  */
   result = member;
   mark_exp_read (object);
+
+  tree wrap;
+  if (!cp_unevaluated_operand
+ && !processing_template_decl
+ && CP_DECL_THREAD_LOCAL_P (result)
+ && (wrap = get_tls_wrapper_fn (result)))
+   /* Replace an evaluated use of the thread_local variable with
+  a call to its wrapper.  */
+   result = build_cxx_call (wrap, 0, NULL, tf_warning_or_error);
+
   /* If OBJECT has side-effects, they are supposed to occur.  */
   if (TREE_SIDE_EFFECTS (object))
result = build2 (COMPOUND_EXPR, TREE_TYPE (result), object, result);

[Bug c++/89729] New: [g++ 8] -Wclass-memaccess warning

[chantry.xavier at gmail dot com]

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

Bug ID: 89729
   Summary: [g++ 8] -Wclass-memaccess warning
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chantry.xavier at gmail dot com
  Target Milestone: ---

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

There are already many bugs about this one, but since I am not expert on C++, I
would like to have your advice.

g++ -std=gnu++98 -c -Wall memaccess-short.cc 

memaccess-short.cc: In function ‘void script_data_init_empty(script_data_t*)’:
memaccess-short.cc:14:61: warning: ‘void* memset(void*, int, size_t)’ clearing
an object of type ‘script_data_t’ {aka ‘struct script_data_t’} with no trivial
copy-assignment; use value-initialization instead [-Wclass-memaccess]
 ({ (typeof(*(p)) *)memset((p), 0, sizeof(*(p)) * (count)); })
 ^
memaccess-short.cc:19:5: note: in expansion of macro ‘p_clear’
 p_clear(, 1);
 ^~~
memaccess-short.cc:4:16: note: ‘script_data_t’ {aka ‘struct script_data_t’}
declared here
 typedef struct script_data_t {
^
memaccess-short.cc:20:33: warning: ‘void* memcpy(void*, const void*, size_t)’
writing to an object of type ‘script_data_t’ {aka ‘struct script_data_t’} with
no trivial copy-assignment [-Wclass-memaccess]
 memcpy(data, , sizeof(d2));
 ^
memaccess-short.cc:4:16: note: ‘script_data_t’ {aka ‘struct script_data_t’}
declared here
 typedef struct script_data_t {
^

I know this is a mix of C and C++ code so not very clean.
What's the correct way in gnu++98 to do this ?

p_clear is in a C header, but I can either write a variant for C++ (using
ifdef), or maybe even directly replace the p_clear calls from C++ files.

The other bugs mention cast to void * as a workaround, this does seem to work,
even with a simple C cast. Is this also acceptable in my case for both memset
and memcpy ?

[Bug c++/89630] [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

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

[Bug c++/89715] ICE deep in C++ frontend building g++.dg/cpp0x/cond1.C

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Jakub Jelinek  ---
I'm 100% certain it is a dup.

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

[Bug c++/89715] ICE deep in C++ frontend building g++.dg/cpp0x/cond1.C

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Segher Boessenkool  ---
The testcase as mentioned is

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/g%2B%2B.dg/cpp0x/alias-decl-64.C;h=019eb2697501a7cbf9273538fc588779bf186ef3;hb=HEAD

and it shows up if you bootstrap --with-cpu=power7.

[Bug c++/89722] [8/9 regression] strange warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Martin Sebor from comment #6)
> But the code above doesn't trigger either warning when compiled as C.  I
> think that suggests that either the manual should be updated to explain the
> difference or the two front ends should be made to behave the same way.  As

C++ is clear that a prvalue of non-class type is cv-unqualified, I assume
that's also true in C. But it matters less for C, because (except for
extensions like __typeof__) the cv-qualifiers of an rvalue don't really matter.
In C++ they affect overloading, template argument deduction, decltype results
etc.

> a data point, Clang doesn't warn in either C or C++ modes on this code so I
> wonder if G++ is being overly pedantic here, especially in the typeof cases.

As I noted in PR 80544 comment 0, EDG warns about casts to cv-qualified scalar
types, and was my inspiration for our warning.

[Bug target/89726] [7/8/9 Regression] Incorrect inlined version of 'ceil' for 32bit

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 45974
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45974=edit
gcc9-pr89726.patch

Untested fix.

[Bug libstdc++/89728] New: ctype is underconstrained

[antoshkka at gmail dot com]

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

Bug ID: 89728
   Summary: ctype is underconstrained
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Because of that overloads from [locale.convenience] compile well with creepy
charT template arguments like std::string:

std::tolower(std::string{}, std::locale::classic());


That leads to runtime exceptions (bad cast to ctype>)
instead of a compile time.


Some other standard library implementations are more restrictive and do not
allow such weird template parameters for ctype:

error: implicit instantiation of undefined template
'std::__1::ctype >'

[Bug middle-end/71509] Bitfield causes load hit store with larger store than load

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to rguent...@suse.de from comment #8)
> On Fri, 15 Mar 2019, luoxhu at cn dot ibm.com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
> > 
> > Xiong Hu XS Luo  changed:
> > 
> >What|Removed |Added
> > 
> >  CC||guojiufu at gcc dot 
> > gnu.org,
> >||rguenth at gcc dot gnu.org
> > 
> > --- Comment #7 from Xiong Hu XS Luo  ---
> > Hi Richard, trying to figure out the issue recently, but get some questions
> > need your help. How is the status of the "proposed simple lowering of 
> > bitfield
> > accesses on GIMPLE", please? 
> 
> There are finished patches in a few variants but all of them show issues
> in the testsuite, mostly around missed optimizations IIRC.  It has been
> quite some time since I last looked at this but IIRC Andrew Pinski said
> he's got sth for GCC 10 so you might want to ask him.

Yes I do, I am planing on submitting the new pass once GCC 10 has opened up.

[Bug debug/88534] [9 Regression] internal compiler error: in tree_add_const_value_attribute, at dwarf2out.c:20246

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #12 from Alexandre Oliva  ---
Fixed

[Bug c++/60702] thread_local initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||leppkes at stce dot 
rwth-aachen.de

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

[Bug c++/89727] static thread_local ODR use broken

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
Found it.

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

[Bug debug/88534] [9 Regression] internal compiler error: in tree_add_const_value_attribute, at dwarf2out.c:20246

[aoliva at gcc dot gnu.org]

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

--- Comment #11 from Alexandre Oliva  ---
Author: aoliva
Date: Fri Mar 15 13:56:55 2019
New Revision: 269709

URL: https://gcc.gnu.org/viewcvs?rev=269709=gcc=rev
Log:
[PR88534] accept VAR_DECL in class literal template parms

P0732R2 / C++ 2a introduce class literals as template parameters.  The
front-end uses VAR_DECLs constructed from such literals to bind the
template PARM_DECLs, but dwarf2out.c used to reject such VAR_DECLs.

Taking DECL_INITIAL from such VAR_DECLs enables the generation of
DW_AT_const_value for them, at least when the class literal can
actually be represented as such.


for  gcc/ChangeLog

PR c++/88534
PR c++/88537
* dwarf2out.c (generic_parameter_die): Follow DECL_INITIAL of
VAR_DECL args.

for  gcc/testsuite/ChangeLog

PR c++/88534
PR c++/88537
* g++.dg/cpp2a/pr88534.C: New.
* g++.dg/cpp2a/pr88537.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/pr88534.C
trunk/gcc/testsuite/g++.dg/cpp2a/pr88537.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88537] class nontype template parameter debug mode crash in dwarf2out.c

[aoliva at gcc dot gnu.org]

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

--- Comment #2 from Alexandre Oliva  ---
Author: aoliva
Date: Fri Mar 15 13:56:55 2019
New Revision: 269709

URL: https://gcc.gnu.org/viewcvs?rev=269709=gcc=rev
Log:
[PR88534] accept VAR_DECL in class literal template parms

P0732R2 / C++ 2a introduce class literals as template parameters.  The
front-end uses VAR_DECLs constructed from such literals to bind the
template PARM_DECLs, but dwarf2out.c used to reject such VAR_DECLs.

Taking DECL_INITIAL from such VAR_DECLs enables the generation of
DW_AT_const_value for them, at least when the class literal can
actually be represented as such.


for  gcc/ChangeLog

PR c++/88534
PR c++/88537
* dwarf2out.c (generic_parameter_die): Follow DECL_INITIAL of
VAR_DECL args.

for  gcc/testsuite/ChangeLog

PR c++/88534
PR c++/88537
* g++.dg/cpp2a/pr88534.C: New.
* g++.dg/cpp2a/pr88537.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/pr88534.C
trunk/gcc/testsuite/g++.dg/cpp2a/pr88537.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89727] static thread_local ODR use broken

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Yes, and it's a dup of an existing bug.

[Bug d/88990] ICE in get_symbol_decl, at d/decl.cc:1097

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Buclaw  ---
Fixed in r269708.

[Bug fortran/89707] [F03] PDT with procedure pointer component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-15
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed with GCC8 and trunk (9.0).

[Bug d/88990] ICE in get_symbol_decl, at d/decl.cc:1097

[ibuclaw at gcc dot gnu.org]

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

--- Comment #2 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Fri Mar 15 13:37:07 2019
New Revision: 269708

URL: https://gcc.gnu.org/viewcvs?rev=269708=gcc=rev
Log:
PR d/88990
d/dmd: Merge upstream dmd 8d4c876c6

The extern storage class flag was wrongly propagated to function scope
when starting the semantic pass on the body.

Fixes https://gcc.gnu.org/PR88990

Reviewed-on: https://github.com/dlang/dmd/pull/9452

Added:
trunk/gcc/testsuite/gdc.test/runnable/test19734.d
trunk/gcc/testsuite/gdc.test/runnable/test19735.d
Modified:
trunk/gcc/d/dmd/MERGE
trunk/gcc/d/dmd/declaration.c
trunk/gcc/d/dmd/func.c

[Bug target/89726] [7/8/9 Regression] Incorrect inlined version of 'ceil' for 32bit

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
I believe the ix86_expand_floorceildf_32 changes of
https://gcc.gnu.org/ml/gcc-patches/2006-10/msg01611.html
meant to fix this, but it isn't clear why it actually didn't fail the test.
Certainly I don't see how:
  if (x2 < x)
-   x2 += 1;
+   x2 -= -1;
could make a difference, when x2 is -1.0 and x is less than -0.0 and greater
than -1.0, it is the x - x = x + (-x) = +0.0 case for any finite x.
We could certainly add another ix86_sse_copysign_to_positive call for the ceil
case after the compensation, which would be just another ior, the question is
if we can do better.

[Bug c/71598] Wrong optimization with aliasing enums

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Created attachment 45973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45973=edit
patch I am testing

I am testing the following.  I needed to adjust the testcase a bit to make
the C++ FE happy, in particular casting the arguments to the function to
pointer-to-enum type and storing an enum member rather than an integer
(the conversion on the return stmts seems to work):

enum e1 { c1 };

__attribute__((noinline,noclone))
int f(enum e1 *p, unsigned *q)
{
  *p = c1;
  *q = 2;
  return *p;
}

int main()
{
  unsigned x;

  if (f((enum e1 *), ) != 2)
__builtin_abort();
  return 0;
}

[Bug c++/89722] [8/9 regression] strange warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-15
 Ever confirmed|0   |1

--- Comment #10 from Jonathan Wakely  ---
(In reply to Xavier from comment #9)
> We are compiling with -std=gnu++98 so decltype is not available there.

But __decltype is.

> And the "+ 0" trick does not seem to work correctly.

It will cause integer promotion for types with smaller rank than int.

> Do you have a solution that works with -std=gnu++98 ?

__decltype


But I think we want to suppress the warning for (__typeof__(expr))x
(we do still want to strip the qualifiers from the result type, just not warn).

[Bug target/89650] [9 Regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:1055 since r269119

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Bug target/87561] [9 Regression] 416.gamess is slower by ~10% starting from r264866 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
433.milc 9180336   27.4 *9180349   26.3 S
433.milc 9180335   27.4 S9180340   27.0 *
433.milc 9180344   26.7 S9180334   27.5 S
450.soplex   8340225   37.1 *8340223   37.5 S
450.soplex   8340226   36.9 S8340228   36.5 S
450.soplex   8340223   37.4 S8340223   37.3 *
482.sphinx3 19490386   50.5 *   19490392   49.8 S
482.sphinx3 19490384   50.7 S   19490374   52.1 *
482.sphinx3 19490394   49.5 S   19490368   53.0 S

comparing the fastest runtimes makes this a progression for both 433.milc
and 482.sphinx3 and no difference for 450.soplex.

I'll post the patch.

For GCC 10 we'd want to play with applying the cost model to the whole
loop nest instead.

[Bug target/89726] [7/8/9 Regression] Incorrect inlined version of 'ceil' for 32bit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |7.5
Summary|Incorrect inlined version   |[7/8/9 Regression]
   |of 'ceil' for 32bit |Incorrect inlined version
   ||of 'ceil' for 32bit

--- Comment #5 from Jakub Jelinek  ---
Started with r237074.  I'll have a look.

[Bug c++/89727] static thread_local ODR use broken

[leppkes at stce dot rwth-aachen.de]

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

--- Comment #2 from Klaus Leppkes  ---
So from Richard Biener's post
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89727#c1), it looks like
_ZTWN1B1aE
[
$>c++filt  "_ZTWN1B1aE"
TLS wrapper function for B::a
]
is the correct accessor (which internally will call the initializer) and a.i is
a direct reference without the wrapper?

So this looks a frontend problem, right?

[Bug middle-end/89726] Incorrect inlined version of 'ceil' for 32bit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2019-03-15
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
Now I can reproduce, but we are talking about
/* PR middle-end/89726 */
/* { dg-do run } */
/* { dg-options "-O2" } */
/* { dg-additional-options "-msse2 -mfpmath=sse" { target sse2_runtime } } */

double a = -0.9;

int
main ()
{
  asm ("" : "+m" (a));
  if (__builtin_signbit (__builtin_ceil (a)) == 0)
__builtin_abort ();
  return 0;
}
and the -mfpmath=sse there is essential, which hasn't been mentioned initially.

[Bug middle-end/89726] Incorrect inlined version of 'ceil' for 32bit

[xan at igalia dot com]

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

--- Comment #3 from Xan Lopez  ---
FWIW, the previous testcase I was using, which is a bit more convoluted, is
this one:

#include 
#include 

double mathCeil(double n)
{
return ceil(n);
}

int main()
{
double a = -0.9;
double result = mathCeil(a);

if (signbit(result))
printf("CORRECT: result is %f\n", result);
else
printf("ERROR: result is %f (should be -0)\n", result);

return 0;
}

Testing, compiling with SSE2 instead of x87, gives:

niraikanai:~/js/32bit%/home/xan/gccbuild/bin/gcc -march=pentium4 -msse2
-mfpmath=sse -m32 -O2 -fPIC -o ceil ceil.c -lm
niraikanai:~/js/32bit%./ceil
ERROR: result is 0.00 (should be -0)
niraikanai:~/js/32bit%/home/xan/gccbuild/bin/gcc -march=pentium4 -msse2
-mfpmath=sse -m32 -O2 -o ceil ceil.c -lm  
niraikanai:~/js/32bit%./ceil
CORRECT: result is -0.00
niraikanai:~/js/32bit%

Apparently in this case what makes the error show up is passing the -fPIC flag.

[Bug middle-end/89726] Incorrect inlined version of 'ceil' for 32bit

[xan at igalia dot com]

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

--- Comment #2 from Xan Lopez  ---
(In reply to Jakub Jelinek from comment #1)
> This is just incorrect expectations.
> "The signbit macro returns a nonzero value if and only if the sign of its
> argument value is negative."
> says the standard and gcc implements that exactly like that.
> In i387 math, it just returns 0x200 instead of 1 you are expecting to see.
> And, as on Unix the exit codes are just 0 to 255, (unsigned char) 0x200 is 0.
> Perhaps you mean to return signbit (...) != 0 or return !!signbit (...)?

Hi Jakub,

perhaps the reduction is not perfectly clear, my bad. The actual problem we are
seeing (or we think we are seeing) is that the result of ceil() is not the same
for the same code in 32bit ad 64bit builds. In particular for an input of -0.9
we see -0 for 64bit, and +0 for 32bit (which, I believe, is incorrect). So even
without using signbit or unix exit codes the value we are getting from ceil
seems to be wrong.

(This was found in a JavaScriptCore test, which was compiled with SSE2 (so no
x87 math) after this patch was applied:
https://bugs.webkit.org/show_bug.cgi?id=194853)

[Bug c++/89722] [8/9 regression] strange warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]

[chantry.xavier at gmail dot com]

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

--- Comment #9 from Xavier  ---
We are compiling with -std=gnu++98 so decltype is not available there.

And the "+ 0" trick does not seem to work correctly.

% cat toto.c
#include 

int main(void) {
char data[128];
printf("%ju\n", sizeof(typeof(*data)));
printf("%ju\n", sizeof(typeof(*data + 0)));
printf("%ju\n", sizeof(typeof((*data) + 0)));
return 0;
}

% ./a.out
1
4
4

Do you have a solution that works with -std=gnu++98 ?

[Bug middle-end/89726] Incorrect inlined version of 'ceil' for 32bit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
This is just incorrect expectations.
"The signbit macro returns a nonzero value if and only if the sign of its
argument value is negative."
says the standard and gcc implements that exactly like that.
In i387 math, it just returns 0x200 instead of 1 you are expecting to see.
And, as on Unix the exit codes are just 0 to 255, (unsigned char) 0x200 is 0.
Perhaps you mean to return signbit (...) != 0 or return !!signbit (...)?

[Bug c++/89727] static thread_local ODR use broken

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-15
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
.original shows the difference:

struct B b;
  <::operator<< ((struct __ostream_type *)
std::basic_ostream::operator<< ((struct basic_ostream *)
std::basic_ostream::operator<< (, a.i), endl), flush) >;
  <::operator<< ((struct basic_ostream *)
std::basic_ostream::operator<< (, _ZTWN1B1aE ()->i), endl) >;
  <::operator<< ((struct basic_ostream *)
std::basic_ostream::operator<< (, a.i), endl) >;

note how we perform the access differently for B::a.i vs. b.a.i,
unexpected to me.

[Bug c++/89722] [8/9 regression] strange warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Martin Sebor from comment #6)
> But the code above doesn't trigger either warning when compiled as C.

Because I only added it for C++, see r248432 and PR 80544.

I don't think I considered cases like this, because I don't think I realised
__typeof__ keeps cv-qualifiers.

I suppose it would be possible to suppress the warning when the target type
being cast to is a typeof expression.

[Bug target/87561] [9 Regression] 416.gamess is slower by ~10% starting from r264866 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
So I tested this with a one-off run of SPEC CPU 2006 on a Haswell machine
which shows the expected improvement on 416.gamess but also eventual
regressions for 433.milc (340s -> 343s), 450.soplex (223s -> 226s)
and 482.sphinx3 (383s -> 391s).  Re-checking those with a 3-run now.

[Bug c++/89727] New: static thread_local ODR use broken

[leppkes at stce dot rwth-aachen.de]

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

Bug ID: 89727
   Summary: static thread_local ODR use broken
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leppkes at stce dot rwth-aachen.de
  Target Milestone: ---

Created attachment 45972
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45972=edit
minimal example of incorrect behavior (static member B::a should be initialized
before first usage).

In the bug example, there are 3 uses of a static thread_local member. 
>From my understanding to the C++ Standard, the compiler should initialize the
member before first use (ODR Rule).

Clang and Intel C++ Compiler behave correct from my understanding. GNU C++
initializes too late.

~/gcc_bug$ g++ test.cpp; ./a.out 
0
constructing A.
42
42
~/gcc_bug$ icc test.cpp; ./a.out 
constructing A.
42
42
42
~/gcc_bug$ clang++ test.cpp; ./a.out 
constructing A.
42
42
42

[Bug c/89723] Bogus maybe-uninitialized warning with -Og

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-15
 Blocks||24639
 Ever confirmed|0   |1

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

[CHECK]: examining phi: _10 = PHI <0(13), 0(10), ki_8(14), ki_9(15)>
[CHECK]: Found unguarded use: return _10;

   [local count: 116465650]:
  if (r_11(D) == 0B)
goto ; [18.09%]
  else
goto ; [81.91%]

   [local count: 21068636]:
  goto ; [100.00%]

   [local count: 95397014]:
  goto ; [100.00%]

...

   [local count: 1073741824]:
  # index_6 = PHI 
  # n_7 = PHI 
  # ki_9 = PHI 
  if (n_7 != 0B)
goto ; [96.34%]
  else
goto ; [3.66%]

   [local count: 39298952]:

   [local count: 116465651]:
  # _10 = PHI <0(13), 0(10), ki_8(14), ki_9(15)>
  return _10;

so the issue is we fail to jump-thread the condition in BB 6 (fail to
eliminate the loop header test).  This is because with -Og we do not
perform any jump threading.

We might want to change this but at -Og we definitely do not want to
duplicate blocks.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/89726] New: Incorrect inlined version of 'ceil' for 32bit

[xan at igalia dot com]

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

Bug ID: 89726
   Summary: Incorrect inlined version of 'ceil' for 32bit
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xan at igalia dot com
  Target Milestone: ---

Using GCC 9.0.1 20190314 (experimental) (GCC) on GNU/Linux x86-64. When
compiling the following program:

#include 
#include 

int main(int argc, const char* argv[])
{
if (argc != 2) abort();
return signbit(ceil(atof(argv[1])));
}

For 32bit the ceil operation for a negative number (say, -0.9) gives +0 instead
of -0, which is incorrect. As in:

niraikanai:~/js/32bit%/home/xan/gccbuild/bin/gcc -O2 -o ceil ceil.c -lm 
niraikanai:~/js/32bit%./ceil -0.9 && echo bad  
niraikanai:~/js/32bit%/home/xan/gccbuild/bin/gcc -O2 -m32 -o ceil ceil.c -lm
niraikanai:~/js/32bit%./ceil -0.9 && echo bad   
bad
niraikanai:~/js/32bit%

This is also present, at least, in the 8.x series.

[Bug c++/89722] [8/9 regression] strange warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.4

--- Comment #7 from Richard Biener  ---
So everything works as designed?  Then please close as WONTFIX.

[Bug tree-optimization/89720] [9 Regression] Spurious -Warray-bounds warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |9.0

[Bug c++/89715] ICE deep in C++ frontend building g++.dg/cpp0x/cond1.C

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-03-15
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
No testcase.

[Bug testsuite/85368] [8 regression] phi-opt-11 test fails on IBM Z

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
Author: rguenth
Date: Fri Mar 15 11:07:53 2019
New Revision: 269704

URL: https://gcc.gnu.org/viewcvs?rev=269704=gcc=rev
Log:
2019-03-15  Richard Biener  

Backport from mainline
2019-03-06  Richard Biener  

PR testsuite/89551
* gcc.dg/uninit-pred-8_b.c: Force logical-op-non-short-circuit
the way that makes the testcase PASS.

2018-11-30  Jakub Jelinek  

PR testsuite/85368
* params.def (PARAM_LOGICAL_OP_NON_SHORT_CIRCUIT): New param.
* tree-ssa-ifcombine.c (ifcombine_ifandif): If
--param logical-op-non-short-circuit is present, override
LOGICAL_OP_NON_SHORT_CIRCUIT value from the param.
* fold-const.c (fold_range_test, fold_truth_andor): Likewise.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/fold-const.c
branches/gcc-8-branch/gcc/params.def
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.dg/uninit-pred-8_b.c
branches/gcc-8-branch/gcc/tree-ssa-ifcombine.c

[Bug middle-end/89551] [9 regression] Test case gcc.dg/uninit-pred-8_b.c fails after r269302

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri Mar 15 11:07:53 2019
New Revision: 269704

URL: https://gcc.gnu.org/viewcvs?rev=269704=gcc=rev
Log:
2019-03-15  Richard Biener  

Backport from mainline
2019-03-06  Richard Biener  

PR testsuite/89551
* gcc.dg/uninit-pred-8_b.c: Force logical-op-non-short-circuit
the way that makes the testcase PASS.

2018-11-30  Jakub Jelinek  

PR testsuite/85368
* params.def (PARAM_LOGICAL_OP_NON_SHORT_CIRCUIT): New param.
* tree-ssa-ifcombine.c (ifcombine_ifandif): If
--param logical-op-non-short-circuit is present, override
LOGICAL_OP_NON_SHORT_CIRCUIT value from the param.
* fold-const.c (fold_range_test, fold_truth_andor): Likewise.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/fold-const.c
branches/gcc-8-branch/gcc/params.def
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.dg/uninit-pred-8_b.c
branches/gcc-8-branch/gcc/tree-ssa-ifcombine.c

[Bug fortran/89724] [9 Regression] Fortran diagnostics give wrong line number because of math-vector-fortran.h header file

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45971=edit
gcc9-pr89724.patch

Patch so far tested just with make check-gfortran but not whole
bootstrap/regtest.

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[abel at gcc dot gnu.org]

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

--- Comment #17 from Andrey Belevantsev  ---
(In reply to Martin Liška from comment #16)
> Andrey: Can you please send a patch for it into gcc-patches mailing list?

Sure, I've sent the patch.

[Bug c/89667] initializers for character string arrays (char *[]) appear to reside in protected storage

[rick at regreer dot net]

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

--- Comment #3 from Rick Greer  ---
Thanks guys, the compound literal works for me.

But can you explain why:

 static char *foo[] = { (char []){"this compiles ..."} };

 void but() { static char *bar[] = { (char []){"this doesn't!"} }; }

I.e, why is the (char []) a non-constant element when it appears in a
function?

[Bug target/89719] [9 regression] gcc.target/aarch64/spellcheck_[456].c testsuite failures

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

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

[Bug c/71598] Wrong optimization with aliasing enums

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> I see.  Do you prefer a langhook solution that would "fix" this only
> for C/C++ and LTO then?

That sounds like the best approach to me, but I'm no expert here.

> OK, I see.  VRP still expects it to exist though (just not for
> pointer types).  Anyhow, I'm probably leaning towards looking at
> TYPE_SIZE.  Hopefully "incomplete" enums do not exist ;)

Yes, sorry, we do call set_min_and_max_values_for_integral_type to set the
bounds on them so you're probably running into the dreaded circularity.

[Bug target/89719] [9 regression] gcc.target/aarch64/spellcheck_[456].c testsuite failures

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Mar 15 09:50:11 2019
New Revision: 269703

URL: https://gcc.gnu.org/viewcvs?rev=269703=gcc=rev
Log:
[AArch64] PR target/89719 Adjust gcc.target/aarch64/spellcheck*.c tests

As of recently the -march,-mcpu,-mtune strings in the error messages are
now quoted.
This patch adjusts the testcases in gcc.target/aarch64/ that had started
failing due to that change.

PR target/89719
* gcc.target/aarch64/spellcheck_4.c: Adjust dg-error string.
* gcc.target/aarch64/spellcheck_5.c: Likewise.
* gcc.target/aarch64/spellcheck_6.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_4.c
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_5.c
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_6.c

[Bug c/71598] Wrong optimization with aliasing enums

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Fri, 15 Mar 2019, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
> 
> --- Comment #9 from Eric Botcazou  ---
> > Btw, I tried to use TREE_TYPE (TYPE_MIN_VALUE ()) of the ENUMERAL_TYPE but
> > that breaks with Ada (bah, no libbacktrace support there...):
> 
> Probably because of:
> 
>   /* Note that the bounds are updated at the end of this function
>  to avoid an infinite recursion since they refer to the type.  */
>   goto discrete_type;
> 
> > That is, input from language frontend maintainers is still needed as to
> > how to get at the integer type an enum type has to be compatible with
> > TBAA-wise and how to query whether there is any.  For the above Ada issue
> > the code could be amended to simply not do anything special for
> > ENUMERAL_TYPE without a TYPE_MIN_VALUE.
> 
> In Ada, enumeration and integer types are totally unrelated to each other.

I see.  Do you prefer a langhook solution that would "fix" this only
for C/C++ and LTO then?

> > I didn't yet try to debug what the Ada issue above is and what weird
> > kind of ENUMERAL_TYPEs Ada has ...
> 
> We probably don't set TYPE_MIN_VALUE at all to avoid the circularity.

OK, I see.  VRP still expects it to exist though (just not for
pointer types).  Anyhow, I'm probably leaning towards looking at
TYPE_SIZE.  Hopefully "incomplete" enums do not exist ;)

[Bug c++/89709] [9 Regression] ICE with constexpr and "-O"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/89709] [9 Regression] ICE with constexpr and "-O"

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 15 09:23:11 2019
New Revision: 269702

URL: https://gcc.gnu.org/viewcvs?rev=269702=gcc=rev
Log:
PR c++/89709
* tree.c (inchash::add_expr): Strip any location wrappers.
* fold-const.c (operand_equal_p): Move stripping of location wrapper
after hash verification.

* g++.dg/cpp0x/constexpr-89709.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-89709.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c/71598] Wrong optimization with aliasing enums

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
> Btw, I tried to use TREE_TYPE (TYPE_MIN_VALUE ()) of the ENUMERAL_TYPE but
> that breaks with Ada (bah, no libbacktrace support there...):

Probably because of:

  /* Note that the bounds are updated at the end of this function
 to avoid an infinite recursion since they refer to the type.  */
  goto discrete_type;

> That is, input from language frontend maintainers is still needed as to
> how to get at the integer type an enum type has to be compatible with
> TBAA-wise and how to query whether there is any.  For the above Ada issue
> the code could be amended to simply not do anything special for
> ENUMERAL_TYPE without a TYPE_MIN_VALUE.

In Ada, enumeration and integer types are totally unrelated to each other.

> I didn't yet try to debug what the Ada issue above is and what weird
> kind of ENUMERAL_TYPEs Ada has ...

We probably don't set TYPE_MIN_VALUE at all to avoid the circularity.

[Bug middle-end/89551] [9 regression] Test case gcc.dg/uninit-pred-8_b.c fails after r269302

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
*** Bug 89717 has been marked as a duplicate of this bug. ***

[Bug middle-end/89717] Test case gcc.dg/uninit-pred-8_b.c fails after r269650

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/71509] Bitfield causes load hit store with larger store than load

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Fri, 15 Mar 2019, luoxhu at cn dot ibm.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
> 
> Xiong Hu XS Luo  changed:
> 
>What|Removed |Added
> 
>  CC||guojiufu at gcc dot gnu.org,
>||rguenth at gcc dot gnu.org
> 
> --- Comment #7 from Xiong Hu XS Luo  ---
> Hi Richard, trying to figure out the issue recently, but get some questions
> need your help. How is the status of the "proposed simple lowering of bitfield
> accesses on GIMPLE", please? 

There are finished patches in a few variants but all of them show issues
in the testsuite, mostly around missed optimizations IIRC.  It has been
quite some time since I last looked at this but IIRC Andrew Pinski said
he's got sth for GCC 10 so you might want to ask him.

> for "less conservative about DECL_BIT_FIELD_REPRESENTATIVE", do you mean we
> choose large mode in GIMPLE stage, and make the decision when in target?
> Thanks.

DECL_BIT_FIELD_REPRESENTATIVE was mainly added for strict volatile
bitfield accesses as well as to avoid data races as specified by the
C++ memory model.  So in some cases we might be able to widen the
accesses (and we can shorten them in any case if we compute this is a good
idea).

> PS: As a newbie, can you tell how did you do to "Widening the representative"
> :),  I am a bit confused about the best mode and where to process it, 
> sometimes
> big mode is better and sometimes smaller mode is better(from Segher's
> comments).

Yeah, get_best_mode is a big pile of *** and this issue is very hard to
compute locally.  I suppose for the best decision you'd need to
look at the whole program (or at least the whole function) in a
flow-sensitive manner.  One of the lowering tries I did was to integrate
the lowering with the SRA pass which is said to eventually get
flow-sensitive analysis at some point (but at least does whole-function
analysis already).

[Bug c/71598] Wrong optimization with aliasing enums

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Btw, I tried to use TREE_TYPE (TYPE_MIN_VALUE ()) of the ENUMERAL_TYPE but
that breaks with Ada (bah, no libbacktrace support there...):

make[3]: ***
[/space/rguenther/src/svn/trunk/gcc/ada/gcc-interface/Make-lang.in:1033:
ada/libgnat/a-except.o] Error 1
+===GNAT BUG DETECTED==+
| 9.0.1 20190314 (experimental) (x86_64-pc-linux-gnu) Storage_Error stack
overflow or erroneous memory access|
| Error detected at lib-xref-spark_specific.adb:39:37  |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report


btw, fixing this in get_alias_set would make this transitive (but exact
behavior is still implementation defined!).

That is, input from language frontend maintainers is still needed as to
how to get at the integer type an enum type has to be compatible with
TBAA-wise and how to query whether there is any.  For the above Ada issue
the code could be amended to simply not do anything special for
ENUMERAL_TYPE without a TYPE_MIN_VALUE.

For C I guess the type of TYPE_MIN_VALUE matches the type the enum is
compatible with, for C++ I would hope so as well.  Testcases covering
also -fshort-enum should be easy to write.

Note anything involving a langhook is going to not work with LTO.

Note another possibility would be (given that most FEs, including LTO,
make unsigned and signed type variants compatible) to look at the
ENUMERAL_TYPEs mode and use the corresponding (unsigned) integer type
as compatible type.  That may not work for under-aligned enums though
where the mode may end up as BLKmode...  which means we'd need to look
at TYPE_SIZE instead.

I didn't yet try to debug what the Ada issue above is and what weird
kind of ENUMERAL_TYPEs Ada has ...

[Bug fortran/89724] [9 Regression] Fortran diagnostics give wrong line number because of math-vector-fortran.h header file

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
This is actually not much related to the -fpre-include stuff, but is a general
bug in the continuation handling.

If I do:
!
!
!
include 'continuation_9.f90'
then it will show:
f951: Warning: ‘&’ not allowed by itself in line 6
f951: Warning: ‘&’ not allowed by itself in line 7
f951: Warning: ‘&’ not allowed by itself in line 8
rather than:
f951: Warning: ‘&’ not allowed by itself in line 3
f951: Warning: ‘&’ not allowed by itself in line 4
f951: Warning: ‘&’ not allowed by itself in line 5
when I compile continuation_9.f90 directly.

load_line has linenum and current_line static int vars that are simply
incremented across all files sourced in rather than being reset when we call
another load_file, or updated e.g. from preprocessor comments.

[Bug other/89712] Documentation contains unsupported options (-fdump-class-hierarchy and -fdump-translation-unit)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
Summary|[8/9 Regression]|Documentation contains
   |Documentation contains  |unsupported options
   |unsupported options |(-fdump-class-hierarchy and
   |(-fdump-class-hierarchy and |-fdump-translation-unit)
   |-fdump-translation-unit)|
  Known to fail|9.0 |

--- Comment #8 from Martin Liška  ---
Usually we do not remove options, but leave them to be no-op. However, these
options are designed for C++ FE developers, so Nathan decided to remove them.

[Bug other/89712] [8/9 Regression] Documentation contains unsupported options (-fdump-class-hierarchy and -fdump-translation-unit)

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Fri Mar 15 08:36:15 2019
New Revision: 269701

URL: https://gcc.gnu.org/viewcvs?rev=269701=gcc=rev
Log:
Subject: Backport r269684

2019-03-15  Martin Liska  

PR other/89712
* doc/invoke.texi: Remove -fdump-class-hierarchy option.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/doc/invoke.texi