[Bug c++/69433] missing -Wreturn-local-addr assigning address of a local to a static

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> Hmm, I don't know how GCC can detect this except with optimizations because
> the assignment to s happens at runtime.

Well there's already other warnings that rely on optimizations... confirming
that this warning would be nice to have.

[Bug c++/69020] wrong ADL for attribute cleanup functions

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> I agree, but as long as the feature is exposed to users it seems that it
> should work in unsurprising ways (i.e., follow the C++ lookup rules). 
> Otherwise, if we don't want C++ programmers to use it, a possible simple fix
> is to reject the attribute in C++.  Alternatively, we could reject it when
> the referenced function is dependent to keep it working in the cases we know
> work correctly and prevent unexpected results in the others.  Or we can fix
> it and issue a warning suggesting to use a destructor.  I'm fine with any of
> these solutions and I'm happy to work up a patch (in fact, I already started
> working on it hoping for a simple fix).

Confirmed, I'd prefer the solution of issuing a warning

[Bug sanitizer/81986] sanitizer detects negation of large number in string.c

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 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
  Component|libfortran  |sanitizer

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Vittorio Zecca from comment #0)
> ! from test case pr66311.f90
> ! must be compiled and run
> ! libgfortran/runtime/string.c:199:11: runtime error: negation of
> 0x8000 cannot be represented in type '__int128';
> cast to an unsigned type to negate this value to itself
>   character(len=100) :: buffer
>   write(buffer,*) -huge(0_16)-1
>   end

Doesn't look like a gfortran problem other than gfortran uses GCC's
__int128 type and its middle/backend machinery.  If you compile
your code with -fdump-tree-original, you get in a.f90.003t.original

{
  static integer(kind=16) C.3427 = -0x8000;

  _gfortran_transfer_integer_write (_parm.0, , 16);
}

Changing your code to

  character(len=100) :: buffer
  write(buffer,*) -huge(0_4)-1
  print '(A,Z8)', trim(buffer)// ' 0x', -huge(0_4)-1
  end

where I added the print statement gives

troutmask:sgk[264] gfortran6 -static -o z -fdump-tree-original a.f90 && ./z
 -2147483648 0x8000

and a.f90.003t.original contains

{
  static integer(kind=4) C.3427 = -2147483648;

  _gfortran_transfer_integer_write (_parm.0, , 4);
}

Note the difference between using a decimal representation for the
constant and the hexidecimal representation in the *.original file.

But, a more interesting result occurs for

int
main(void)
{
   __int128 i,j;
   i =   ((__int128)1)  << 127;
   j = (-((__int128)1)) << 127;
   return 0;
}

% /usr/local/bin/gcc6 -fdump-tree-original -c a.c
%/ cat a.c.003t.original

;; Function main (null)
;; enabled by -tree-original

{
  __int128 i;
  __int128 j;

__int128 i;
__int128 j;
  i = -0x8000;
  j = -0x8000;
}
return 0;

Why is this interesting?  Well, consider the simpler case 

int
main(void)
{
   int i,j;
   i =   ((int)1) << 31;
   j = -(((int)1) << 31);
   return 0;
}

/usr/local/bin/gcc6 -fdump-tree-original -c a.c
a.c: In function 'main':
a.c:9:8: warning: integer overflow in expression [-Woverflow]
j = -(((int)1)<<31);
^

%cat a.c.003t.original

;; Function main (null)
;; enabled by -tree-original


{
  int i;
  int j;

int i;
int j;
  i = -2147483648;
  j = -2147483648(OVF);
  return 0;
}

Note, both the warning that GCC issues and the (OVF) annotation.

So, in summary, not a gfortran.  Someone needs to teach the sanitizers
about GCC's __int128 or someone needs to fix the handling of __int128
to mirror the behavior observed for a plain old int.

[Bug target/81833] [7/8 Regression] PowerPC: VSX: Miscompiles ffmpeg's scalarproduct_int16_vsx at -O1

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
The "altivec_vsumsws" pattern for little endian isn't working as intended. 
This needs to be rewritten.  So does the "altivec_vsum2sws" pattern.  I'll work
on a patch early next week.

[Bug target/81833] [7/8 Regression] PowerPC: VSX: Miscompiles ffmpeg's scalarproduct_int16_vsx at -O1

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-25
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Bill Schmidt  ---
Confirmed, also fails on trunk.

[Bug target/81990] New: Should -finstrument-control-flow -mcet generate ENDBR for function with __attribute__ ((interrupt))?

[hjl.tools at gmail dot com]

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

Bug ID: 81990
   Summary: Should -finstrument-control-flow -mcet generate ENDBR
for function with __attribute__ ((interrupt))?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---

Are ENDBR needed for interrupt handlers at all?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -finstrument-control-flow -mcet bugs

[Bug target/81989] New: Should -finstrument-control-flow -mcet generate ENDBR for function with __attribute__ ((naked))?

[hjl.tools at gmail dot com]

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

Bug ID: 81989
   Summary: Should -finstrument-control-flow -mcet generate ENDBR
for function with __attribute__ ((naked))?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---
Target: x86

Should -finstrument-control-flow -mcet generate ENDBR for function with
__attribute__ ((naked))?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -finstrument-control-flow -mcet bugs

[Bug target/81504] [7/8 Regression] gcc-7 regression: vec_st in loop misoptimized

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Fixed on trunk so far.  Will commit backport in about a week.

[Bug driver/81519] Enhancement: Add --help=target-distcc or similar to dump clean, optimal CFLAGS without using -march=native

[daniel.santos at pobox dot com]

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

--- Comment #6 from Daniel Santos  ---
(In reply to Martin Liška from comment #4)
> Ok, so I've briefly investigated source code and providing such information
> is definitely not a simple task :/

Sorry for my late response and thanks for looking into this.  I too was a bit
daunted when I started to investigate this just for the i386 back-end as there
were a lot of twists and turns, 64-bit bitmasks that were out of bits requiring
hack-arounds to add new processors, etc.

Maybe a nice-to-have would be a generic middle-end mechanism to manage this for
all back-ends in a universal fashion so that this type of thing would be much
easier to handle.  Of course, that would require an awfully large amount of
analysis in order to create a design that works *and* makes sense for everyone,
but such a design could also do a better job of things such as representing the
linage of a microarchitecture, accessing the processor_costs, etc.

[Bug c/81871] bogus attribute alloc_align accepted

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed; I'd prefer a warning from -Wattributes personally.

[Bug c/81851] missing -Wduplicated-branches on if and return statements with no else

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #2 from Eric Gallager  ---
(In reply to Marek Polacek from comment #1)
> Definitely not a bug, I never intended that the warning detects the latter
> case.  And it's not an easy enhancement, either.

Yeah it's not really what I think of as "branches" when there's no else. And
sometimes I write code like that on purpose.

[Bug c/79204] improve -Woverflow by mentioning types and values

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
  Known to work||8.0
 Resolution|--- |FIXED

--- Comment #1 from Eric Gallager  ---
IIRC one of either you or Marek fixed this for gcc8:

$ /usr/local/bin/gcc -c -S -Wall 79204.c
79204.c:4:11: warning: overflow in conversion from ‘int’ to ‘T {aka signed
char}’ changes value from ‘28782’ to ‘110’ [-Woverflow]
 #define N (X * Y)
   ^
79204.c:6:7: note: in expansion of macro ‘N’
 T x = N;
   ^
$

[Bug c++/68571] provide __builtin_cookie_size

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug c++/41423] missing warning for an uncallable function template

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed that g++ still doesn't warn.

[Bug target/81988] [7/8 Regression] sparc64: emits STD instruction with odd register

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce, depends on selected CPU type, occurs for -mcpu= v9, m8, or
niagara3/4/7.

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[misty at brew dot sh]

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

--- Comment #9 from Misty De Meo  ---
My VM has two cores, and repros this problem.

I reported this to Apple, who assigned the bug ID rdar://33924943. It was
reported to me that Apple engineers believed it was fixed in the latest beta,
but it is still reproducing.

[Bug c++/81607] [6 Regression] Conditional operator: "type mismatch in shift expression" error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[6/7 Regression]|[6 Regression] Conditional
   |Conditional operator: "type |operator: "type mismatch in
   |mismatch in shift   |shift expression" error
   |expression" error   |

--- Comment #14 from Marek Polacek  ---
Fixed.

[Bug c++/81607] [6/7 Regression] Conditional operator: "type mismatch in shift expression" error

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Fri Aug 25 16:31:50 2017
New Revision: 251358

URL: https://gcc.gnu.org/viewcvs?rev=251358=gcc=rev
Log:
PR c++/81607
* cp-gimplify.c (cp_fold): If folding exposed a branch of
a COND_EXPR, convert it to the original type of the COND_EXPR, if
they differ.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/other/bitfield6.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/cp-gimplify.c

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[msebor at gcc dot gnu.org]

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

--- Comment #18 from Martin Sebor  ---
GDB already has a C++ parser.  It just isn't good enough.  It understands that
B and B are one and the same type but it interprets
A<2> and A<2u> as distinct.  In my view, this is not just a limitation but a
bug.

But to be clear, my argument isn't so much against changing GCC but rather that
the right solution is to fix/enhance GDB.  Changing GCC is just a workaround,
and it isn't even a very good one given that GCC 7 already emits a different
symbol.

In any event, you don't need my approval to propose a change to GCC.  You need
the approval of the C++ debug info maintainer(s).

[Bug lto/81816] ICE in lto1 with -fopenmp offloading and nested #pragma omp target

[igor.venevtsev at intel dot com]

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

--- Comment #3 from Igor Venevtsev  ---
Created attachment 42049
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42049=edit
Proposed so-called 'patch';)

I've got an idea to replace target construct by its body in outer context. It
fixes ICE, but breaks a lot of OpenACC tests;) And yes, without ICE nested
target region will be lowered to GOMP_target_ext() call in target context and
this behavior is undefined according to OpenMP specification. Maybe the place
of transformation is not correct or else the transformation itself is
absolutely wrong. I attached the 'patch' in hope it could be useful.

[Bug lto/81816] ICE in lto1 with -fopenmp offloading and nested #pragma omp target

[igor.venevtsev at intel dot com]

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

--- Comment #2 from Igor Venevtsev  ---
Created attachment 42048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42048=edit
simple reproducer

[Bug target/81988] New: [7/8 Regression] sparc64: emits STD instruction with odd register

[jcowgill+gcc at jcowgill dot uk]

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

Bug ID: 81988
   Summary: [7/8 Regression] sparc64: emits STD instruction with
odd register
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcowgill+gcc at jcowgill dot uk
  Target Milestone: ---

Created attachment 42047
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42047=edit
testcase

FFmpeg in Debian fails to build on sparc64 with GCC 7 and when I tried using
the latest GCC 8. It fails with an assembler message:

> /tmp/cc4Rj2im.s: Assembler messages:
> /tmp/cc4Rj2im.s:38973: Error: Illegal operands
> /tmp/cc4Rj2im.s:39002: Error: Illegal operands
> /tmp/cc4Rj2im.s:39098: Error: Illegal operands
> /tmp/cc4Rj2im.s:39120: Error: Illegal operands

I've attached a reduced testcase which fails on GCC 7 and 8 with the same kind
of error. This issue is an STD instruction which tries to store an odd numbered
register which is not allowed:

> !(insn 237 287 280 (set (mem/c:DI (reg:DI 28 %i4 [334]) [7 %sfp+-9016 S8 A64])
> !(reg:DI 39 %f7 [+-4 ])) "reduce.c":13 125 {*movdi_insn_sp64}
> ! (expr_list:REG_DEAD (reg:DI 28 %i4 [334])
> !(expr_list:REG_DEAD (reg:SI 40 %f8)
> !(nil
>   std %f7, [%i4]  ! 237   *movdi_insn_sp64/9  [length = 1]

The testcase should be compiled using:
> gcc -fPIE -fstack-protector-all -O3 -c reduce.c

James

[Bug tree-optimization/81987] New: ICE in verify_ssa with -O3 -march=skylake-avx512

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 81987
   Summary: ICE in verify_ssa with -O3 -march=skylake-avx512
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

g++ -O3 -march=skylake-avx512 fails with ICE in verify_ssa with error:
definition in block 11 does not dominate use in block 2

There are several trackers with the same error message, but some of them fails
only with -O2 -floop-nest-optimize option (69675, 79483), other were fixed
(71252). So i don't know, if this bug is duplicate or not.

>$ cat repr.cpp
extern short var_1;
extern const short var_3;
extern unsigned long int var_9;
extern short var_13;
extern const unsigned long int var_15;
extern const unsigned long int var_37;
extern unsigned long int var_40;
extern long long int var_47;
extern short var_48;
extern const short var_54;
extern long long int var_79;
extern long long int var_81;
extern long long int var_94;
extern long long int var_95;
extern long long int var_701;
extern unsigned long int var_786;
extern short var_788;
extern long long int var_844;

struct struct_1 {
short member_1_2 : 30;
static long long int member_1_3;
};

extern struct_1 struct_obj_6;
extern struct_1 struct_obj_8;

void foo() {
  int a = var_3 <= 602154393864UL;
  if (var_81 ? 0 : var_3 && var_9)
;
  else {
var_94 = 0;
if (var_3 && var_48 || var_13) {
  if (var_48)
var_95 = 0;
  short b((236446151776511UL + var_3) * (2 ? var_13 : 0) || var_1);
  struct_obj_8.member_1_2 = b;
  if (var_15) {
if (var_81)
  if (var_47)
;
  else if (var_40)
var_701 = 0;
  } else {
if (var_40)
  var_79 = 0;
if (var_54) {
  if (var_37)
var_786 = 0;
  else
var_788 = 0;
  struct_obj_6.member_1_3 =
  (236446151776511UL + var_3) * (2 ? var_13 : 0);
}
  }
  if ((236446151776511UL + var_3) * (2 ? var_13 : 0))
var_844 = 0;
}
  }
}

Error:
>g++ -O3 -march=skylake-avx512 -c repr.cpp
repr.cpp: In function ‘void foo()’:
repr.cpp:28:6: error: definition in block 11 does not dominate use in block 2
 void foo() {
  ^~~
for SSA_NAME: _10 in statement:
slsr_104 = _10 * 236446151776511;
during GIMPLE pass: slsr
repr.cpp:28:6: internal compiler error: verify_ssa failed
0x1095c1b verify_ssa(bool, bool)
/home/vsevolod/workspace/gcc-dev/trunk/gcc/tree-ssa.c:1188
0xd7ad1d execute_function_todo
/home/vsevolod/workspace/gcc-dev/trunk/gcc/passes.c:1999
0xd7b619 execute_todo
/home/vsevolod/workspace/gcc-dev/trunk/gcc/passes.c:2046

GCC version is 251301

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On August 25, 2017 4:14:05 PM GMT+02:00, "ro at CeBiTec dot Uni-Bielefeld.DE"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
>
>--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE dot Uni-Bielefeld.DE> ---
>> --- Comment #1 from rguenther at suse dot de de> ---
>[...]
>>>collect2: fatal error: ld terminated with signal 11 [Segmentation
>>>Fault]
>>>compilation terminated.
>>>ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [1] has
>>>invalid type [
>>>SHT_NULL ]
>>>ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [5] contains
>>>both
>>>SHF_EXCLUDE and SHF_ALLOC flags: SHF_EXCLUDE ignored
>[...]
>>>Clearly a SEGV isn't the best error handling, and I'm not yet certain
>>>if the
>>>errors
>>>are benign.  OTOH, I don't yet know why the objects are created this
>>>way.
>>
>> They are created that way to make my life easier. They are supposed
>to be valid
>> ELF objects and they are according to the specs and my
>interpretation. 
>
>My reading is different and corroborates the Solaris ld warnings:
>
>* for SHT_NULL, the ELF gABI 4.1 is pretty explicit:
>
>  p. 4-13, p.57:
>
>  SHT_NULL
>
>  This value marks the section header as inactive; it does not
>  have an associated section. Other members of the section
>  header have undefined values.

Yep, exactly as intended. Those sections are removed, their section table entry
is thus inactive. They are not removed from there because changing section
indices requires rewriting relocation section data. 

>* SHF_EXCLUDE is a later addition, also included in the Solaris Linker
>  and Libraries Guide:
>
> 
>http://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-94076.html#OSLLGchapter6-10675
>
>  SHF_EXCLUDE
>
>  This section is excluded from input to the link-edit of an executable
>  or shared object. This flag is ignored if the SHF_ALLOC flag is also
>  set, or if relocations exist against the section.

Intended. The SHF_ALLOC flag is probably spurious, eventually added by gas? Can
you dump the section header of the affected section? 

>  This is identical to the wording in the binutils PR which introduced
>  this flag:
>
>  PR gas/11600:
>  Support SHF_EXCLUDE
>  https://sourceware.org/bugzilla/show_bug.cgi?id=11600
>
>Seems far from clear to me that those are valid ELF objects: the
>warnings seem totally appropriate.

About the flag mixing probably yes. 

Do you have an idea what it segfaults on? OpenSolaris should have the source
available? 

>Rainer

[Bug pch/80572] crash reporting warning from precompiled header

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||ice-on-valid-code
 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
  Component|c++ |pch
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
I can't reproduce this bug; it compiles successfully for me with neither ICE
nor warning. Maybe it has something to do with differing contents of system
headers? I'm on i386-apple-darwin9.8.0.

[Bug target/81504] [7/8 Regression] gcc-7 regression: vec_st in loop misoptimized

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Author: wschmidt
Date: Fri Aug 25 15:08:30 2017
New Revision: 251355

URL: https://gcc.gnu.org/viewcvs?rev=251355=gcc=rev
Log:
2017-08-25  Bill Schmidt  

PR target/81504
* config/rs6000/rs6000-p8swap.c (find_alignment_op): Add reference
parameter and_insn and return it.
(recombine_lvx_pattern): Insert a copy to ensure availability of
the base register of the copied masking operation at the point of
the instruction replacement.
(recombine_stvx_pattern): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-p8swap.c

[Bug c++/79001] spurious "defined but not used" warning with explicit instantiation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed that g++ warns for "f" but not "g"

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic, openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-25
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #10 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to Jeffrey Walton from comment #4)
> > (For what its worth, I understand the compiler writers are always right.
> > They are demi-gods in my little corner of the universe :)
> 
> You can also be a compiler writer:
> https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
> 
> For what is worth, I understand the point by Andrew that without -fopenmp,
> the #pragmas are effectively ignored, thus the warning seems useful. Perhaps
> it would be more useful a specific -Wopenmp-pragmas  that says:
> 
>  warning: ignoring '#pragma omp parallel' without '-fopenmp'
> [-Wopenmp-pragmas]
> 
> But it seems more important to fix PR53431, if someone has time for that.
> 
> The zero-column ":0" in the diagnostic is also a bug.

Confirming these points.

[Bug c++/68160] Can bind packed field if it's packed with #pragma pack(push, 1)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed. I think this is related to bug 60972.

[Bug c++/58798] class with a class reference member generates unjustified warning

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Gallager  ---
(In reply to Szikra from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > Because the warning isn't controlled by the -Wpacked option. If it was, it
> > would say [-Wpacked] after the warning. I think that's a bug, every warning
> > should be controlled by some -Wxxx option.
> 
> Thanks, good to know. So does this require a separate bug report, or can
> someone change the status and confirm this one?

Confirmed that the warning should be controlled by -Wpacked. I also noticed
this in bug 60972.

[Bug c++/78679] Produce a warning on `int + string literal`

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
There's a -Wunused-variable warning at least:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 78679.cc
78679.cc: In function ‘int main()’:
78679.cc:3:7: warning: unused variable ‘a’ [-Wunused-variable]
  auto a = 6 + ".txt";
   ^
$

...and once you try to do anything with 'a' to use it to silence the
-Wunused-variable warning, it quickly turns into other issues:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 78679.cc
78679.cc: In function ‘int main()’:
78679.cc:4:9: error: invalid conversion from ‘const char*’ to ‘int’
[-fpermissive]
  return a;
 ^
$

So I guess confirmed that g++ could warn earlier about the addition, too, to
prevent it from leading to further issues. Might be related to requests for a
-Wstring-plus-int, but in reverse order.

[Bug middle-end/81931] [8 regression] r251260 breaks many tests on powerpc64

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #14 from nsz at gcc dot gnu.org ---
*** Bug 81982 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/81982] [arm] libstdc++ miscompiled, constant propagation is broken on native arm

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from nsz at gcc dot gnu.org ---
you are right it's a dup and fixed.

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

[Bug c++/63458] myclassobj >> charac compiles without warning, EVEN though ONLY operator>>(std::string&) exists

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Gallager  ---
(In reply to Marc Glisse from comment #1)
> You forgot to mark your operator bool as explicit.

That's bug 60135, I think.

(In reply to mqi30097 from comment #0)
> Why no warning whatsoever??
> 
> //= go.cpp ==
> #include 
> 
> class Mystream
> {
> public:
>   Mystream(std::istream& is1) : is{is1} {}
>   Mystream& operator>>(std::string&);
>   operator bool();
> private:
>   std::istream& is;
> };
> 
> Mystream& Mystream::operator>>(std::string& s)
> {
>   is >> s;
>   return *this;
> }
> 
> Mystream::operator bool()
> {
>   return is.good();
> }
> 
> int main()
> {
>   Mystream ms(std::cin);
> 
>   char ch;
>   while (ms >> ch) { // WHY NO WARNING?
> std::cout << ch << '\n';
>   }
>   return 0;
> }
> 
> //= end of go.cpp ==
> 
> Compile with:
> c++ -std=c++11 -o go go.cpp
> 
> To "fix" the program:
> Change declaration in main from 
>   char ch;
> to 
>   std::string ch; 
> 
> Why no warning?
> Thanks.

I get a warning:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -Weffc++ -std=c++11 63458.cc
63458.cc: In function ‘int main()’:
63458.cc:29:12: warning: ‘ch’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
  while (ms >> ch) { // WHY NO WARNING?
 ~~~^
$

(In reply to Marek Polacek from comment #4)
> Yeah, shifting booleans is a weird thing to do.  So is multiplication or
> dividing booleans - and we don't warn on that either.

Yeah I'd expect -Wbool-operation to catch it, but it doesn't. So confirmed that
-Wbool-operation could be improved.

[Bug c++/63519] missing Wparenthesis warning for x binary_op bool ?:

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
g++ now prints a warning from -Wint-in-bool-context for it:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 63519.cc
63519.cc: In function ‘int foo(bool, int, int, int)’:
63519.cc:3:11: warning: ‘*’ in boolean context, suggest ‘&&’ instead
[-Wint-in-bool-context]
  return x * a ? y : z;
 ~~^~~
$

Confirming that a warning from -Wparentheses is still missing though. Also the
-Wint-in-bool-context one could do better and add a fix-it hint, seeing as it
already has a suggestion in the message.

[Bug c++/60135] add option to warn if ctor/conversion declared implicit

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-25
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Eric Gallager  ---
Confirming as an enhancement. Call it "-Wsuggest-explicit" perhaps?

[Bug c++/77796] tautological compare warning emitted for inherited static method comparisons

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed. Also, it seems weird that the warning underlines all of B::destroy,
but only the "A" in A::destroy:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 77796.cc
77796.cc:11:12: warning: self-comparison always evaluates to true
[-Wtautological-compare]
 B::destroy == A::destroy ? 0 : 1
 ~~~^~~~
$

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from rguenther at suse dot de  ---
[...]
>>collect2: fatal error: ld terminated with signal 11 [Segmentation
>>Fault]
>>compilation terminated.
>>ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [1] has
>>invalid type [
>>SHT_NULL ]
>>ld: warning: file /var/tmp//ccOFDEXadebugobjtem: section [5] contains
>>both
>>SHF_EXCLUDE and SHF_ALLOC flags: SHF_EXCLUDE ignored
[...]
>>Clearly a SEGV isn't the best error handling, and I'm not yet certain
>>if the
>>errors
>>are benign.  OTOH, I don't yet know why the objects are created this
>>way.
>
> They are created that way to make my life easier. They are supposed to be 
> valid
> ELF objects and they are according to the specs and my interpretation. 

My reading is different and corroborates the Solaris ld warnings:

* for SHT_NULL, the ELF gABI 4.1 is pretty explicit:

  p. 4-13, p.57:

  SHT_NULL

  This value marks the section header as inactive; it does not
  have an associated section. Other members of the section
  header have undefined values.

* SHF_EXCLUDE is a later addition, also included in the Solaris Linker
  and Libraries Guide:

 
http://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-94076.html#OSLLGchapter6-10675

  SHF_EXCLUDE

  This section is excluded from input to the link-edit of an executable
  or shared object. This flag is ignored if the SHF_ALLOC flag is also
  set, or if relocations exist against the section.

  This is identical to the wording in the binutils PR which introduced
  this flag:

  PR gas/11600:
  Support SHF_EXCLUDE
  https://sourceware.org/bugzilla/show_bug.cgi?id=11600

Seems far from clear to me that those are valid ELF objects: the
warnings seem totally appropriate.

Rainer

[Bug libfortran/81986] New: sanitizer detects negation of large number in string.c

[zeccav at gmail dot com]

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

Bug ID: 81986
   Summary: sanitizer detects negation of large number in string.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
 Build: trunk 251201

! from test case pr66311.f90
! must be compiled and run
! libgfortran/runtime/string.c:199:11: runtime error: negation of
0x8000 cannot be represented in type '__int128';
cast to an unsigned type to negate this value to itself
  character(len=100) :: buffer
  write(buffer,*) -huge(0_16)-1
  end

[Bug c++/67858] g++-5.1.1 warns about unused variable only when optimization flag is used

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
  Known to work||8.0
 Resolution|--- |WORKSFORME

--- Comment #2 from Eric Gallager  ---
I get no warnings with any of the optimization levels I tried, and I tried all
of them.

[Bug libfortran/81985] New: several sanitizer undefined runtime errors in sanitized libgfortran

[zeccav at gmail dot com]

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

Bug ID: 81985
   Summary: several sanitizer undefined runtime errors in
sanitized libgfortran
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
 Build: trunk 251201

! test case mvbits_1.f90
! several sanitizer undefined runtime errors in sanitized libgfortran
! must be compiled and run
!../../../gcc/libgfortran/intrinsics/mvbits.c:48:30: runtime error: left shift
of negative value -1
!../../../gcc/libgfortran/intrinsics/mvbits.c:48:30: runtime error: left shift
of negative value -1
!../../../gcc/libgfortran/intrinsics/mvbits.c:46:61: runtime error: left shift
of 1 by 31 places cannot be represented in type 'int'
!../../../gcc/libgfortran/intrinsics/mvbits.c:46:50: runtime error: signed
integer overflow: -2147483648 - 1 cannot be represented in type 'int'
!../../../gcc/libgfortran/generated/pow_i4_i4.c:66:10: runtime error: signed
integer overflow: 32768 * 65536 cannot be represented in type 'int'
!../../../gcc/libgfortran/intrinsics/mvbits.c:48:30: runtime error: left shift
of negative value -1
!../../../gcc/libgfortran/generated/pow_i4_i4.c:69:8: runtime error: signed
integer overflow: 65536 * 65536 cannot be represented in type 'int'
!../../../gcc/libgfortran/intrinsics/mvbits.c:46:61: runtime error: left shift
of 1 by 63 places cannot be represented in type 'long int'
!../../../gcc/libgfortran/intrinsics/mvbits.c:46:50: runtime error: signed
integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long
int'
!../../../gcc/libgfortran/generated/pow_i8_i8.c:66:10: runtime error: signed
integer overflow: 2147483648 * 4294967296 cannot be represented in type 'long
int'
!../../../gcc/libgfortran/intrinsics/mvbits.c:48:30: runtime error: left shift
of negative value -1
!../../../gcc/libgfortran/generated/pow_i8_i8.c:69:8: runtime error: signed
integer overflow: 4294967296 * 4294967296 cannot be represented in type 'long
int'
implicit none
integer(1) i1,j1
integer(2) i2,j2
integer(4) i4,j4
integer(8) i8,j8
integer ibits,n

ibits=bit_size(1_1)
do n=1,ibits
   i1=-1
   call mvbits(1_1, 0,n,i1,0)
   j1=-1-2_1**n+2
   if(i1.ne.j1)call abort
enddo
ibits=bit_size(1_2)
do n=1,ibits
   i2=-1
   call mvbits(1_2, 0,n,i2,0)
   j2=-1-2_2**n+2
   if(i2.ne.j2)call abort
enddo
ibits=bit_size(1_4)
do n=1,ibits
   i4=-1
   call mvbits(1_4, 0,n,i4,0)
   j4=-1-2_4**n+2
   if(i4.ne.j4)call abort
enddo
ibits=bit_size(1_8)
do n=1,ibits
   i8=-1
   call mvbits(1_8, 0,n,i8,0)
   j8=-1-2_8**n+2
   if(i8.ne.j8)call abort
enddo
end

[Bug libfortran/81984] New: NULL string pointer dereferencing forces undefined behaviour in libgfortran

[zeccav at gmail dot com]

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

Bug ID: 81984
   Summary: NULL string pointer dereferencing forces undefined
behaviour in libgfortran
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
 Build: trunk 251201

! From test case allocate_deferred_char_scalar_1.f03
! Contributed by Tobias Burnus  
! Must be compiled and run with sanitized libgfortran
! NULL string pointer dereferencing forces undefined behaviour in libgfortran 
! libgfortran/intrinsics/string_intrinsics_inc.c:90:7: runtime error: null
pointer passed as argument 1, which is declared to never be null
! string_intrinsics_inc.c:90 is "res = MEMCMP (s1, s2, ((len1 < len2) ? len1 :
len2));"
! len1 is probably zero so the operation is undefined but harmless
! A fix could be "res = len1==0 ? 0 : MEMCMP (s1, s2, ((len1 < len2) ? len1 :
len2));"
  character(len=:), pointer :: str4
  logical l
  nullify(str4)
  l= str4=='12a56b78'
  end

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Eric Gallager]

On 8/25/17, Szabolcs Nagy  wrote:
> On 16/08/17 18:38, Joseph Myers wrote:
>> On Wed, 16 Aug 2017, Eric Gallager wrote:
>>> I see Richi redid all his 7.2 release changes; does that imply that
>>> the server restore is now complete?
>>
>> No, there's still a search process ongoing to identify corrupted or
>> missing files by comparison with the last backup.
>>
>> My expectation is that all the other Bugzilla changes from 13 and 14
>> August UTC need redoing manually (recreating bugs with new numbers in the
>>
>> case of new bugs filed during that period, if those bugs are still
>> relevant, repeating comments, etc. - and possibly recreating accounts for
>>
>> people who created accounts and filed bugs during that period).  But I
>> haven't seen any official announcement from overseers to all affected
>> projects (for both GCC and Sourceware Bugzillas) yet.
>>
>
> can i resubmit my lost bug reports now?
>
>

Yes, please do. Joseph said the restore was done in a comment on bug web/81846:

http://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01718.html

[Bug sanitizer/81981] [8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Looks like the problem is that since that revision in .uninit there's
UBSAN_PTR (, 0);
and so the warning probably thinks that t escapes and so doesn't warn.

[Bug libfortran/81983] New: sanitizer detects undefined runtime error in libbacktrace

[zeccav at gmail dot com]

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

Bug ID: 81983
   Summary: sanitizer detects undefined runtime error in
libbacktrace
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
 Build: trunk 251201

! sanitizer detects runtime error in libbacktrace
! This file MUST NOT be compiled with -g option
! Must be compiled with -fsanitize=address,undefined and sanitized libgfortran
and libbacktrace
! libbacktrace/dwarf.c:2662:9: runtime error: null pointer passed as argument
2, which is declared to never be null
! dwarf.c:2662 "entry = bsearch (, ddata->addrs, ddata->addrs_count,"
! ddata->addrs_count is probably zero so operation is undefined but harmless
! possible fix "entry=NULL; 
!   if(ddata->addrs_count) entry=bsearch (, ddata->addrs,
ddata->addrs_count,"
  INTEGER, ALLOCATABLE :: arr(:)
  ALLOCATE (arr(5))
  ALLOCATE (arr(6))
  END

[Bug middle-end/81931] [8 regression] r251260 breaks many tests on powerpc64

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #13 from Markus Trippelsdorf  ---
Fixed.

[Bug tree-optimization/81982] [arm] libstdc++ miscompiled, constant propagation is broken on native arm

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #4 from Markus Trippelsdorf  ---
Must be a dup of PR81931, which is already fixed.

[Bug tree-optimization/81982] [arm] libstdc++ miscompiled, constant propagation is broken on native arm

[nsz at gcc dot gnu.org]

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

--- Comment #3 from nsz at gcc dot gnu.org ---
Created attachment 42046
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42046=edit
last matching output (objsz1) from -fdump-tree-all

[Bug tree-optimization/81982] [arm] libstdc++ miscompiled, constant propagation is broken on native arm

[nsz at gcc dot gnu.org]

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

--- Comment #2 from nsz at gcc dot gnu.org ---
Created attachment 42045
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42045=edit
bad ccp1 output from -fdump-tree-all

[Bug tree-optimization/81982] [arm] libstdc++ miscompiled, constant propagation is broken on native arm

[nsz at gcc dot gnu.org]

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

--- Comment #1 from nsz at gcc dot gnu.org ---
Created attachment 42044
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42044=edit
good ccp1 output from -fdump-tree-all

[Bug tree-optimization/81982] New: [arm] libstdc++ miscompiled, constant propagation is broken on native arm

[nsz at gcc dot gnu.org]

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

Bug ID: 81982
   Summary: [arm] libstdc++ miscompiled, constant propagation is
broken on native arm
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42043
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42043=edit
preprocessed libstdc++/libsupc++/guard.cc

since
https://gcc.gnu.org/viewcvs/gcc?view=revision=251260

i see gcc miscompiling guard.cc, but only if the gcc is
native arm-*-linux-gnu, a cross compiler compiles it correctly.

the difference between the native and cross compiler
first shows up at ccp1 in -ftree-dump-all, so i
suspect that tree-ssa-ccp.c got miscompiled in the
native gcc, but i'll need to investigate that further,
meanwhile the diff of the ccp1 output is

--- guard.ii.032t.ccp1.good 2017-08-24 18:41:32.875600385 +0100
+++ guard.ii.032t.ccp1.bad  2017-08-24 18:41:23.503495848 +0100
@@ -235,7 +235,21 @@

 ;; Function __cxxabiv1::__cxa_guard_acquire (__cxa_guard_acquire,
funcdef_no=227, decl_uid=6043, cgraph_uid=225, symbol_order=227)

+Folding predicate 0 != 0 to 0
+Folding predicate 0 != 0 to 0
+Folding predicate 1 != 0 to 1
+Folding predicate 0 != 0 to 0
+Folding predicate 1 != 0 to 1
+Removing basic block 7
+Removing basic block 9
+Removing basic block 18
+Removing basic block 13
 Removing basic block 16
+Merging blocks 6 and 8
+Merging blocks 11 and 12
+Removing basic block 14
+Merging blocks 6 and 10
+Merging blocks 11 and 15
 __cxxabiv1::__cxa_guard_acquire (__guard * g)
 {
   int D.13418;
@@ -254,8 +268,6 @@
   int _1;
   unsigned int pending_bit.3_2;
   unsigned int newv.8_6;
-  bool _7;
-  int _11;
   int _12;
   bool _21;
   bool retval.1_22;
@@ -263,8 +275,6 @@
   int _25;
   unsigned char _28;
   unsigned char _30;
-  bool retval.2_34;
-  bool retval.7_37;
   bool _47;
   int _48;
   int _50;
@@ -274,13 +284,7 @@
   char _55;
   int _56;
   __complex__ unsigned int _74;
-  unsigned int _75;
-  unsigned int _76;
-  int _77;
   __complex__ unsigned int _80;
-  unsigned int _81;
-  unsigned int _82;
-  int _83;

[100.00%] [count: INV]:
   _30 = __atomic_load_1 (g_18(D), 2);
@@ -293,7 +297,7 @@

[0.00%] [count: INV]:
   // predicted unlikely by early return (on trees) predictor.
-  goto ; [INV] [count: INV]
+  goto ; [INV] [count: INV]

[100.00%] [count: INV]:
   _47 = __gthrw___pthread_key_create != 0B;
@@ -304,7 +308,7 @@
   if (retval.1_22 != 0)
 goto ; [INV] [count: INV]
   else
-goto ; [INV] [count: INV]
+goto ; [INV] [count: INV]

[100.00%] [count: INV]:
   __u.__i = 0;
@@ -319,107 +323,50 @@
[0.00%] [count: INV]:
   pending_bit.3_2 = (unsigned int) _52;
   _74 = ATOMIC_COMPARE_EXCHANGE (g_18(D), 0, pending_bit.3_2, 4, 4, 2);
-  _75 = IMAGPART_EXPR <_74>;
-  retval.2_34 = (bool) _75;
-  _76 = REALPART_EXPR <_74>;
-  _77 = VIEW_CONVERT_EXPR(_76);
-  if (retval.2_34 != 0)
+  if (_52 == 0)
 goto ; [INV] [count: INV]
   else
 goto ; [INV] [count: INV]

[0.00%] [count: INV]:
-  // predicted unlikely by early return (on trees) predictor.
-  goto ; [INV] [count: INV]
-
-   [0.00%] [count: INV]:
-  if (_77 == 1)
-goto ; [INV] [count: INV]
-  else
-goto ; [INV] [count: INV]
-
-   [0.00%] [count: INV]:
-  // predicted unlikely by early return (on trees) predictor.
-  goto ; [INV] [count: INV]
-
-   [0.00%] [count: INV]:
-  if (_52 == _77)
-goto ; [INV] [count: INV]
-  else
-goto ; [INV] [count: INV]
-
-   [0.00%] [count: INV]:
-  newv_35 = _50 | _77;
-  newv.8_6 = (unsigned int) newv_35;
-  _80 = ATOMIC_COMPARE_EXCHANGE (g_18(D), _76, newv.8_6, 4, 4, 2);
-  _81 = IMAGPART_EXPR <_80>;
-  _7 = (bool) _81;
-  _82 = REALPART_EXPR <_80>;
-  _83 = VIEW_CONVERT_EXPR(_82);
-  retval.7_37 = ~_7;
-  if (retval.7_37 != 0)
-goto ; [INV] [count: INV]
-  else
-goto ; [INV] [count: INV]
-
-   [0.00%] [count: INV]:
-  if (_83 == 1)
-goto ; [INV] [count: INV]
-  else
-goto ; [INV] [count: INV]
-
-   [0.00%] [count: INV]:
-  // predicted unlikely by early return (on trees) predictor.
-  goto ; [INV] [count: INV]
-
-   [0.00%] [count: INV]:
-  if (_83 == 0)
-goto ; [INV] [count: INV]
-  else
-goto ; [INV] [count: INV]
-
-   [0.00%] [count: INV]:
+  newv.8_6 = (unsigned int) _50;
+  _80 = ATOMIC_COMPARE_EXCHANGE (g_18(D), 0, newv.8_6, 4, 4, 2);
   // predicted unlikely by continue predictor.
   goto ; [INV] [count: INV]

-   [0.00%] [count: INV]:
-  # expected_84 = PHI <_77(10), newv_35(14), newv_35(11)>
-  syscall (240, g_18(D), 0, expected_84, 0);
+   [0.00%] [count: INV]:
+  syscall (240, g_18(D), 0, 0, 0);
   goto ; [INV] [count: INV]

-   [0.00%] [count: INV]:
-  # _11 = PHI <1(7), 0(9), 0(13)>
-  goto ; [INV] [count: INV]
-
-   [100.00%] [count: INV]:
+   

[Bug sanitizer/81981] [8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Started with r250656.

[Bug sanitizer/81981] New: [8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

Bug ID: 81981
   Summary: [8 Regression] -fsanitize=undefined makes a
-Wmaybe-uninitialized warning disappear
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
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: ---

Consider:

int foo (int i)
{
  int t[1], u[1];
  int n = 0;

  if (i)
{
  t[n] = i;
  u[0] = i;
}

  return t[0] + u[0];
}

With gcc (Debian 20170823-1) 8.0.0 20170823 (experimental) [trunk revision
251306], I get:

zira% gcc-snapshot -Wmaybe-uninitialized -O2 -c tst.c -fsanitize=undefined
tst.c: In function 'foo':
tst.c:12:15: warning: 'u[0]' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   return t[0] + u[0];
  ~^~

zira% gcc-snapshot -Wmaybe-uninitialized -O2 -c tst.c 
tst.c: In function 'foo':
tst.c:12:15: warning: 'u[0]' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   return t[0] + u[0];
  ~^~
tst.c:12:15: warning: 't[0]' may be used uninitialized in this function
[-Wmaybe-uninitialized]

i.e. with -fsanitize=undefined, I do not get the warning on t[0].

This is a regression. No such problem with GCC 7.2.0, 6.4.0 and 5.4.1.

[Bug c/81980] Spurious -Wmissing-format-attribute warning in 32-bit mode

[sgunderson at bigfoot dot com]

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

--- Comment #1 from sgunderson at bigfoot dot com ---
Forgot to say: Also present in trunk r251306 and all the way back to at least
4.8.

[Bug c/81980] New: Spurious -Wmissing-format-attribute warning in 32-bit mode

[sgunderson at bigfoot dot com]

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

Bug ID: 81980
   Summary: Spurious -Wmissing-format-attribute warning in 32-bit
mode
   Product: gcc
   Version: 7.2.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,

The following (reduced) code gives a warning if and only if I add -m32:

atum17:~> cat test.c
#include 

char a;
void set_message(const char *fmt, va_list ap)
  __attribute__((format(printf, 1, 0)));
void set_message_by_errcode(va_list ap) { set_message(, ap); }

atum17:~> gcc -Wmissing-format-attribute -c test.c 
atum17:~> gcc -Wmissing-format-attribute -c test.c -m32
test.cc: In function ‘void set_message_by_errcode(va_list)’:
test.cc:6:61: warning: function ‘void set_message_by_errcode(va_list)’ might be
a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
 void set_message_by_errcode(va_list ap) { set_message(, ap); }
 ^

I believe the warning is spurious, since there's no way you could construct a
valid printf format attribute for set_message_by_errcode (it doesn't take in a
string parameter).

This holds for both C and C++.

atum17:~> gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-1'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Debian 7.2.0-1)

[Bug target/81921] [5/6/7 Regression] Fails to always-inline intrinsics with -flto

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Fri Aug 25 12:32:54 2017
New Revision: 251351

URL: https://gcc.gnu.org/viewcvs?rev=251351=gcc=rev
Log:
Retabify 2017-08-24  Richard Biener  
PR target/81921

Modified:
trunk/gcc/ChangeLog

[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #9 from Alan Modra  ---
Fixed

[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749

[amodra at gcc dot gnu.org]

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

--- Comment #8 from Alan Modra  ---
Author: amodra
Date: Fri Aug 25 12:21:00 2017
New Revision: 251349

URL: https://gcc.gnu.org/viewcvs?rev=251349=gcc=rev
Log:
PR81747, ICE in operator[]

PR rtl-optimization/81747
* cse.c (cse_extended_basic_block): Don't attempt to record
equivalences for degenerate conditional branches that branch
to their fall-through.

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

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Szabolcs Nagy]

On 16/08/17 18:38, Joseph Myers wrote:
> On Wed, 16 Aug 2017, Eric Gallager wrote:
>> I see Richi redid all his 7.2 release changes; does that imply that
>> the server restore is now complete?
> 
> No, there's still a search process ongoing to identify corrupted or 
> missing files by comparison with the last backup.
> 
> My expectation is that all the other Bugzilla changes from 13 and 14 
> August UTC need redoing manually (recreating bugs with new numbers in the 
> case of new bugs filed during that period, if those bugs are still 
> relevant, repeating comments, etc. - and possibly recreating accounts for 
> people who created accounts and filed bugs during that period).  But I 
> haven't seen any official announcement from overseers to all affected 
> projects (for both GCC and Sourceware Bugzillas) yet.
> 

can i resubmit my lost bug reports now?

[Bug other/81979] New: [8 Regression] Assembler messages: Error: can't resolve `.got2' {.got2 section} - `.LCF0' {.text.unlikely section}

[asolokha at gmx dot com]

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

Bug ID: 81979
   Summary: [8 Regression] Assembler messages: Error: can't
resolve `.got2' {.got2 section} - `.LCF0'
{.text.unlikely section}
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpcspe-*-linux-gnu*

gas 2.28.1 rejects the code generated by gcc-8.0.0-alpha20170820 snapshot
(r251211) w/ -fPIC -O2 -freorder-blocks-and-partition for the following
snippet:

int du;

void
xf (int ee)
{
  int cq;

  while (cq < 1)
{
  int ox;

  for (ox = 0; ox < 4; ++ox)
cq /= (ee != 0) ? 2 : ee;
}

  du = 1;
  for (;;)
{
}
}

% powerpc-e500v2-linux-gnuspe-gcc-8.0.0-alpha20170820 -fPIC -O2
-freorder-blocks-and-partition -c v8qdkqlm.c
/tmp/cchaREkd.s: Assembler messages:
/tmp/cchaREkd.s:15: Error: can't resolve `.got2' {.got2 section} - `.LCF0'
{.text.unlikely section}

[Bug c++/67371] Never executed "throw" in constexpr function fails to compile

[benni.buch at gmail dot com]

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

Benjamin Buch  changed:

   What|Removed |Added

 CC||benni.buch at gmail dot com

--- Comment #14 from Benjamin Buch  ---
Please reopen!

Only a part of this bug is fixed:


constexpr int f(){
if(false) throw 0;
return 0;
}

int main(){
constexpr auto i = f();
}


is OK now, but


constexpr int f(){
if(true) return 0;
throw 0;
}

int main(){
constexpr auto i = f();
}


still fails.

Tested with:

$ g++ --version 
g++ (GCC) 8.0.0 20170818 (experimental) 
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.

[Bug sanitizer/79200] Race-Condition in Address Santitizer (RT_PREEMPT-Kernel only?)

[tommapson at gmx dot de]

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

--- Comment #6 from tommapson at gmx dot de ---
(Since I do not know whether this is a bug in the realtime-kernel or the
compiler, I also reported it in the kernel bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=196767).

[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #2 from Vincent Lefèvre  ---
Another test case:

int foo (void)
{
  int i = 0, t;

  if (i > 0)
t = i;

  if (t != 0)
return 1;

  return 0;
}

int main (void)
{
  return foo () + foo () + foo () + foo ();
}

With -O1, I get 1 warning for foo and 1 for main.
With -O2, I get 1 warning for foo and 4 for main.

The warnings for main disappear if I add __attribute__((noinline)) on foo.
Surprisingly, they also disappear if I just remove the code related to variable
i.

Tested with:
gcc (Debian 20170823-1) 8.0.0 20170823 (experimental) [trunk revision 251306]

[Bug sanitizer/79200] Race-Condition in Address Santitizer (RT_PREEMPT-Kernel only?)

[tommapson at gmx dot de]

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

tommapson at gmx dot de changed:

   What|Removed |Added

Summary|Race-Condition in Address   |Race-Condition in Address
   |Santitizer  |Santitizer
   ||(RT_PREEMPT-Kernel only?)

--- Comment #5 from tommapson at gmx dot de ---
The problem can be reproduced on Debian 9 using the realtime kernel shipped by
Debian:

$ uname -a
Linux myhost 4.9.0-3-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.30-2+deb9u2
(2017-06-26) x86_64 GNU/Linux

$ gcc --version
gcc (Debian 6.3.0-18) 6.3.0 20170516



When booting the non-rt-kernel 4.9.0-3-amd64, the problem disappears - using
the same binary of main.

As described initially: Without -fsanitize=address the problem is gone, too.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from rguenther at suse dot de  ---
[...]
> They are created that way to make my life easier. They are supposed to be 
> valid
> ELF objects and they are according to the specs and my interpretation. 

do you have a reference in how this way of constructing them helps?
Solaris elfdump complains heavily, at least.  I'll check further to
either confirm they are indeed valid or find word to the contrary.

Rainer

[Bug libstdc++/81857] istreambuf_iterator not work as input iterator

[abominable-snowman at yandex dot ru]

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

--- Comment #3 from Petr Ovtchenkov  ---
Created attachment 42042
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42042=edit
proposed test for issue

https://gcc.gnu.org/ml/libstdc++/2017-08/msg00036.html

May be worth to add (see issue2471) words to copy_n spec:

 "copy_n return result + n (i.e. increment OutputIterator n times) and
  increment InputIterator max(0, n - 1)."

to avoid ambiguity?

[Bug c++/81975] Unpacking two packs via alias erroneously complains about mismatched argument packs

[griwes at griwes dot info]

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

--- Comment #1 from Michał Dominiak  ---
I have made a mistake in the original testcase in the original email, here's a
correction email sent to the reflector:
http://lists.isocpp.org/core/2017/08/2828.php.

Barry's minimization of the failing code already eliminates the mistake; I'm
just providing the reply to make sure there's no confusion about the
differences between the original testcase and Barry's version.

Now, an interesting artifact of this is that both T and V fail, but U somehow
succeeds, which makes it seem like the compiler is sometimes *assuming* that
the size of a pack is 1; this'd be consistent with the Clang error message,
where it always says that one of the packs has just one element.

[Bug fortran/81974] [8 Regression] ICE verify_gimple failed type mismatch in binary expression

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-25
 CC||marxin at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|ICE verify_gimple failed|[8 Regression] ICE
   |type mismatch in binary |verify_gimple failed  type
   |expression  |mismatch in binary
   ||expression
 Ever confirmed|0   |1
  Known to fail||8.0

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