[Bug debug/81623] New: [8 Regression] FAIL: g++.dg/debug/debug9.C -gstabs -O3 (test for excess errors)

[marxin at gcc dot gnu.org]

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

Bug ID: 81623
   Summary: [8 Regression] FAIL: g++.dg/debug/debug9.C -gstabs -O3
(test for excess errors)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at ucw dot cz
  Target Milestone: ---

Starting from r249885, the test-case fails:

g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/debug/debug9.C -gstabs
-O3 -c
/tmp/ccY5CXGf.s: Assembler messages:
/tmp/ccY5CXGf.s:194: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `.LFBB1' {.text.startup section}
/tmp/ccY5CXGf.s:195: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `.LFBB1' {.text.startup section}

[Bug rtl-optimization/81625] New: GCC v4.7 ... v8 is bloating code by > 25% compared to v3.4

[gjl at gcc dot gnu.org]

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

Bug ID: 81625
   Summary: GCC v4.7 ... v8 is bloating code by > 25% compared to
v3.4
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41867
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41867=edit
snake-i.c: C test case.

The attached test case, compiled for code size

$ avr-gcc snake-i.c -mmcu=atmega168 -Os -S -dp -ffunction-sections -o
snake-i_$${v}.s

Gives the following sizes with different compiler versions:

avr-gcc (GCC) 3.4.6
   textdata bss dec hex filename
672   0   0 672 2a0 snake-i_20060421.o

avr-gcc (GCC) 4.7.2
   textdata bss dec hex filename
854   0   0 854 356 snake-i_4.7.2.o

avr-gcc (GCC) 4.9.2 20140912 (prerelease)
   textdata bss dec hex filename
894   0   0 894 37e snake-i_4.9.2-pre1.o

avr-gcc (GCC) 5.2.1 20150816
   textdata bss dec hex filename
876   0   0 876 36c snake-i_5.2.1.o

avr-gcc (GCC) 6.4.1 20170726
   textdata bss dec hex filename
852   0   0 852 354 snake-i_6.4.1.o

avr-gcc (GCC) 7.1.1 20170725
   textdata bss dec hex filename
850   0   0 850 352 snake-i_7.1.1.o

avr-gcc (GCC) 8.0.0 20170718 (experimental)
   textdata bss dec hex filename
852   0   0 852 354 snake-i_8.0_2017-07-19.o

Hence, compared to 3.4.6, we have the following bloat factor:

3.4.6: 672
4.7.2: 854 = +27%
4.9.2: 894 = +33%
5.2.1: 876 = +30%
6.4.1: 852 = +26%
7.1.1: 850 = +26%
8.0.0: 852 = +26%

Mostly due to bad register selection; multiple expensive address computations
(for address that's just 1 after the already computed address), missed
post-increment opportunity, ...

Note that the code from 3.4.6 is already sub-optimal so there is even more room
for improvement.

Just some samples:

if (s->changed.text)
{
s->changed.text = 0;
sb->str[0] = s->game.level + '0';
sb->str[1] = '\n';
u16_to_string (sb->str+2, s->game.score);
}

3.4.6:

tst r24  ;  421 tstqi   [length = 1]
breq .L20;  422 branch  [length = 1]
std Z+6,__zero_reg__ ;  426 *movqi/3[length = 1]
; Compute address of sb->str to Y=r28.
subi r28,lo8(-(67))  ;  428 *addhi3/4   [length = 2]
sbci r29,hi8(-(67))
ldd r24,Z+7  ;  429 *movqi/4[length = 1]
; Using post-increment to store '0' + ...
subi r24,lo8(-(48))  ;  430 addqi3/2[length = 1]
st Y+,r24;  431 *movqi/3[length = 1]
ldi r24,lo8(10)  ;  434 *movqi/2[length = 1]
; Dito to store '\n'.
st Y+,r24;  435 *movqi/3[length = 1]
ldd r22,Z+8  ;  438 *movhi/2[length = 2]
ldd r23,Z+9
; Now has sb->str + 2 to pass in r24.
movw r24,r28 ;  439 *movhi/1[length = 1]
call u16_to_string   ;  440 call_value_insn/3   [length = 2]
.L20:
/* epilogue: frame size=0 */


8.0.0:

tst r24  ;  296 cmpqi3/1[length = 1]
brne .+2 ;  297 branch  [length = 2]
rjmp .L20
; Using reg X=r26 which doesn't support X+const addressing, all described
; in LEGITIMIZE_RELOAD_ADDRESS.  So it adds 6 and after access has to
; subtract 6 again
adiw r26,6   ;  299 movqi_insn/3[length = 3]
st X,__zero_reg__
sbiw r26,6
; Computes address in Z=r30 as Y+67
movw r30,r28 ;  397 *movhi/1[length = 1]
subi r30,-67 ;  300 addhi3_clobber/2[length = 2]
sbci r31,-1
; Still using X.
adiw r26,7   ;  301 movqi_insn/4[length = 3]
ld r24,X
sbiw r26,7
subi r24,lo8(-(48))  ;  302 addqi3/2[length = 1]
; Store '0' +...
st Z,r24 ;  303 movqi_insn/3[length = 1]
; What the dickens? Z++ after store to Z, why not just Z+ above?
adiw r30,1   ;  304 *addhi3/3   [length = 1]
ldi r24,lo8(10)  ;  305 movqi_insn/2[length = 1]
st Z,r24 ;  306 movqi_insn/3[length = 1]
; Still using X
adiw r26,8   ;  307 *movhi/3[length = 3]
ld r22,X+
ld r23,X
; Moving Y to r24 and computing Y+67 *again*
movw r24,r28 ;  399 *movhi/1[length = 1]
subi r24,-69 ;  310 *addhi3/4   [length = 2]
sbci r25,-1
/* epilogue start */
; 7 * POP for epilogue
jmp u16_to_string;  311 call_value_insn/4   [length = 2]


A second spot with crazy expensive code; both code bloat and slow execution:

[Bug testsuite/81626] New: Need effective target omp_target

[vries at gcc dot gnu.org]

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

Bug ID: 81626
   Summary: Need effective target omp_target
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When we build a compiler with nvptx accelerator for openacc testing and test
libgomp, we run into 308 FAIL/UNRESOLVED like this:
...
FAIL: libgomp.fortran/target8.f90   -Os  (test for excess errors)
UNRESOLVED: libgomp.fortran/target8.f90   -Os  compilation failed to produce
executable
...

The failure in more detail is a missing symbol __nvptx_uni:
...
unresolved symbol __nvptx_uni
collect2: error: ld returned 1 exit status
mkoffload: fatal error: x86_64-none-linux-gnu-accel-nvptx-none-gcc returned 1
exit status
compilation terminated.
...

In order to run openmp nvptx offloading test, we need to compile all nvptx code
with -mgomp. Compiling libgcc with -mgomp provides the missing symbol.

Since the compiler as we configure it for openacc testing does not provide any
multilibs with -mgomp, openmp nvptx offloading testing is not supported. 

If we add an effective target that tests if openmp offloading testing is
supported, then we can use it to report UNSUPPORTED instead of FAIL/UNRESOLVED.

[Bug target/81492] internal compiler error: Segmentation fault (ia64 target with "-O1 -g" and __attribute__((optimize("O3"))))

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Martin Liška  ---
Good, so it's known issue PR75750 which is fixed in GCC 6.4:

commit ca9024ae9128af5bba2f2c770c5551ad02715ccf
Author: jakub 
Date:   Fri May 5 21:29:10 2017 +

Backported from mainline
2017-02-21  Jakub Jelinek  

PR target/79570
* sel-sched.c (moveup_expr_cached): Don't call sel_bb_head
on temporarily removed DEBUG_INSNs.

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


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-6-branch@247673
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug testsuite/81624] [8 Regression] FAIL: gcc.target/i386/pr59501-3a.c scan-assembler-not and[^\n\r]*sp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug debug/81623] [8 Regression] FAIL: g++.dg/debug/debug9.C -gstabs -O3 (test for excess errors)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #11 from Georg-Johann Lay  ---
This cannot be fixed in GCC as C++ doesn't support ISO/IEC DTR 18037 named
address spaces.  This feature requires that the C++ front-end knows about ASes
and handles them properly.  This doesn't imply that ASes are exposed on
language level; knowing about ASes "internally" would be sufficient.  As it's
pretty much clear that C++ WG21 will never accept such qualifiers (not even the
C WG14) did, just close this as WON'T FIX.

All that can be done is proposing work-arounds: Use "Embedded-C++" coding
convention that avoids VTABLEs, or use a device that can host .rodata in flash
like families -mmcu=avrtiny and -mmcu=avrxmega3.

[Bug c/81629] New: redefined memcpy leads to segmentation fault

[frederic.besson at inria dot fr]

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

Bug ID: 81629
   Summary: redefined memcpy leads to segmentation fault
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederic.besson at inria dot fr
  Target Milestone: ---

Hi,

The simple code below crashes with  internal compiler error: Segmentation
fault.
It seems gcc does not like the redefinition of memcpy.


extern unsigned long long memcpy(unsigned long long, unsigned long long,
unsigned long long);

void foo(unsigned long long ctx, unsigned long long output)
{
  memcpy(ctx + 2LLU, ctx,  1U);
  return;
}


Best regards,

[Bug c++/81607] 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 #6 from Marek Polacek  ---
Actually I think richi's fix is the right one.  Let me test.

[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Jan Hubicka  ---
*** Bug 81623 has been marked as a duplicate of this bug. ***

[Bug debug/81623] [8 Regression] FAIL: g++.dg/debug/debug9.C -gstabs -O3 (test for excess errors)

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||hubicka at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Jan Hubicka  ---
This is bug in stabs output - I am not sure if we can support debug info for
split functions there somehow. Added some info to PR81307

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

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

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Mon, 31 Jul 2017, mpolacek at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607
> 
> --- Comment #6 from Marek Polacek  ---
> Actually I think richi's fix is the right one.  Let me test.

Note for aggregate types fold_const might just ICE so I'm not 100% sure
we don't need some more guards on it.  Like if type != expected-type or 
so?

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2010-05-30 05:38:00 |2017-7-31
 CC||jvdelisle at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  ---
Hi Jerry,

should we also look at this when we bump the library number?

[Bug hsa/81477] HSA offloading regressions: "function cannot be cloned"

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
Author: jamborm
Date: Mon Jul 31 11:18:31 2017
New Revision: 250738

URL: https://gcc.gnu.org/viewcvs?rev=250738=gcc=rev
Log:
[PR 81477] Set versionable regardless of optimization level

2017-07-31  Martin Jambor  

PR hsa/81477
* ipa-fnsummary.c (ipa_fn_summary_generate): Set versionable
regardless of optimization level.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-fnsummary.c

[Bug testsuite/81626] Need effective target omp_target

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Ugh, that is going to be a maintainance nightmare for the testsuite.
Why and how are you configuring your accel compiler without the OpenMP support?

[Bug c++/81607] 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 #8 from Marek Polacek  ---
I'm actually testing this

--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -2314,9 +2314,9 @@ cp_fold (tree x)

   /* A COND_EXPR might have incompatible types in branches if one or both
 arms are bitfields.  If folding exposed such a branch, fix it up.  */
-  if (TREE_CODE (x) != code)
-   if (tree type = is_bitfield_expr_with_lowered_type (x))
- x = fold_convert (type, x);
+  if (TREE_CODE (x) != code
+ && !useless_type_conversion_p (TREE_TYPE (org_x), TREE_TYPE (x)))
+   x = fold_convert (TREE_TYPE (org_x), x);

   break;

so I hope that case is covered.  We'll see.

[Bug c/81629] redefined memcpy leads to segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|ASSIGNED|NEW
  Component|middle-end  |c
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Oh.  The real issue is that the FE registers the function with the bogus
prototype as builtin.  So gimple_builtin_call_types_compatible_p sees the call
matches
the prototype.

That this is BUILT_IN_MEMCPY is simply a lie by the FE.

Still invalid input.

We also do not even warn about the bogus prototype given.

[Bug c/81630] New: powl returns values with insufficient accuracy

[kakehi at waseda dot jp]

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

Bug ID: 81630
   Summary: powl returns values with insufficient accuracy
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kakehi at waseda dot jp
  Target Milestone: ---

Created attachment 41870
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41870=edit
compare powl(t,N) with exp2l(N*log2l(t))

I calculated powl(t,N) where t= (N+1)/N, N: an integer value 2^n (n: positive
integer) to get an approximation to Napier's constant.
Here is some results:
  n  powl(t, N)exp2l(N*log2l(t))
 25: 2.7182817879534639155837683e+00  2.7182817879534906457209692e+00
 26: 2.7182818082062409458920377e+00  2.7182818082062676638861742e+00
 27: 2.7182818183325918449770586e+00  2.7182818183326563803766523e+00
 28: 2.7182818233957862993910304e+00  2.7182818233958507905551755e+00
 29: 2.7182818259273639105617903e+00  2.7182818259274480086548631e+00
 30: 2.7182818271931621957604452e+00  2.7182818271932466208488932e+00
 31: 2.7182818278260525070993969e+00  2.7182818278261459278132700e+00
 32: 2.7182818278260525070993969e+00  2.7182818281425955814038786e+00
 33: 2.7182818278260525070993969e+00  2.7182818283008204083076031e+00
 34: 2.7182818278260525070993969e+00  2.7182818283799328217594654e+00
 35: 2.7182818278260525070993969e+00  2.7182818284194890285938168e+00
As you see, powl(t,N) values have saturated when n>30, where exp2l(N*log2l(t)),
which is a formula mathematically equivalent to powl(t,N), produces increasing
values in converging to Napier's constant.

The values are obtained by the program "comparePow.c":

#include 
#include 
#include 
/*  checking the powl function.
*/

int main(int argc, char *argv[]){
  if( argc==1 ){ printf("usage: $ comparePOW n [m]"); exit(-1);}
  int n= atoi(argv[1]), m;
  if( argc==2 ) m= n; else m= atoi(argv[2]);
  for(int i= n; i<=m; i++){
long double N=powl(2.0, (long double)i);
if( N==N+1 ){ printf("too large N\n"); exit(-1); }
long double t= (N+1)/N;
long double powlx= powl(t,N);
long double powly= exp2l(N*log2l(t));
printf("%3d: %.25Le  %.25Le\n", i, powlx, powly);
  }

  return 0;

}

by running it with the command "./a.out 25 35".

The command "gcc -v" produces:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/c++/4.2.1
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[Bug target/81614] Should -mtune-ctrl=partial_reg_stall be turned by default?

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
As a historical note, X86_TUNE_PARTIAL_REG_STALL was moved to historical relics
at the time both current designs (Penium 4 and Athlon) were using
PARTIAL_REG_DEPENDENCY. I believed that main reason for this design was good
perofrmance for 16bit code which is no longer a priority.

It should have been pulled back when this concept was re-introduced for Pentium
M and Cores (which i did not notice :)

[Bug tree-optimization/81627] [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from amker at gcc dot gnu.org ---
Sorry for the breakage.  I will investigate this.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.2

[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 31 08:24:58 2017
New Revision: 250728

URL: https://gcc.gnu.org/viewcvs?rev=250728=gcc=rev
Log:
PR sanitizer/81604
* ubsan.c (ubsan_type_descriptor): For UBSAN_PRINT_ARRAY don't
change type to the element type, instead add eltype variable and
use it where we are interested in the element type.

* c-c++-common/ubsan/pr81604.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr81604.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/ubsan.c

[Bug c++/81607] 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

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Started with r234384.

[Bug tree-optimization/49857] Put constant switch-tables into flash

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #17 from Georg-Johann Lay  ---
Giving up on this.  A working solution as patch series is here, so anyone can
pick it up.

http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01804.html
http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01808.html
http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01810.html

Note that it only can be done for artificial data -- or you have to make sure
that the data is not accessed by inline asm by different means (and of course,
no pointers must escape, and a respective hook must not be called from within
the C++ front-end).

avr-part approval:
http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01835.html

gcc-part rejection as "too specific":
http://gcc.gnu.org/ml/gcc-patches/2017-07/msg01879.html

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

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Mon, 31 Jul 2017, mpolacek at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607
> 
> --- Comment #8 from Marek Polacek  ---
> I'm actually testing this
> 
> --- a/gcc/cp/cp-gimplify.c
> +++ b/gcc/cp/cp-gimplify.c
> @@ -2314,9 +2314,9 @@ cp_fold (tree x)
> 
>/* A COND_EXPR might have incompatible types in branches if one or both
>  arms are bitfields.  If folding exposed such a branch, fix it up.  */
> -  if (TREE_CODE (x) != code)
> -   if (tree type = is_bitfield_expr_with_lowered_type (x))
> - x = fold_convert (type, x);
> +  if (TREE_CODE (x) != code
> + && !useless_type_conversion_p (TREE_TYPE (org_x), TREE_TYPE (x)))
> +   x = fold_convert (TREE_TYPE (org_x), x);
> 
>break;
> 
> so I hope that case is covered.  We'll see.

Yeah, hopefully the FE doesn't mess up types for aggregates ;)

useless_type_conversion_p should be fine in the gimplify hook.

[Bug middle-end/81629] redefined memcpy leads to segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-31
  Component|c   |middle-end
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Use -ffreestanding or -fno-builtin-memcpy.

We ICE because gimple_builtin_call_types_compatible_p doesn't detect the arg
mismatch.

[Bug target/81614] Should -mtune-ctrl=partial_reg_stall be turned by default?

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #6 from Jan Hubicka  ---
There are two flags (which I believe was introduced by me)
 - partial-reg-stall which models behavior of PentiumPro where partial writes
   to register were cheap as long as the partially written register was never
   used in wider mode as the stall.
 - partial-reg-dependency which models later CPUs where partial writes are
   handled as read-mody-write instructions and thus slow even if the result
   is used only in same width as write.

   This was design of Athlons.

The first flag avoids random optimizations which replace full sized instruction
by part size (for example xol $1, eax is not changed to xorb to save size).
Still we could generate partial register stalls out of combine.

The second is trying to make sure we always read full register (by movzx). 

We set those as: 

DEF_TUNE (X86_TUNE_PARTIAL_REG_STALL, "partial_reg_stall", m_PPRO)
DEF_TUNE (X86_TUNE_PARTIAL_REG_DEPENDENCY, "partial_reg_dependency",
  m_P4_NOCONA | m_CORE_ALL | m_BONNELL | m_SILVERMONT | m_INTEL
  | m_KNL | m_AMD_MULTIPLE | m_GENERIC)

I would say that it makes no sense to have both X86_TUNE_PARTIAL_REG_STALL and
X86_TUNE_PARTIAL_REG_DEPENDENCY set on one chip.
According to Fog's manual indeed Core and later chips can rename partial
registers again so they should be moved to X86_TUNE_PARTIAL_REG_STALL category
and we should try to fix possible regressions.

In the testcase given, for X86_TUNE_PARTIAL_REG_DEPENDENCY we ought to emit the
dependency breaking instruction to clear full register before partial write 
when optimizing for speed.

All AMD chips since Athlon are however X86_TUNE_PARTIAL_REG_DEPENDENCY design
so for generic we will need to check what are the tradeoffs.  I would say that
X86_TUNE_PARTIAL_REG_DEPENDENCY is in general more conservative and works well
for (X86_TUNE_PARTIAL_REG_STALL chips as the cases we produce partial write
(sete) are relatively rare.

[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression] ICE in |[7 Regression] ICE in
   |push_reload, at |push_reload, at
   |reload.c:1350   |reload.c:1350

--- Comment #17 from Arseny Solokha  ---
-mno-lra has been recently removed on the 8 branch.

[Bug rtl-optimization/81625] GCC v4.7 ... v8 is bloating code by > 25% compared to v3.4

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 41868
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41868=edit
Assembly as generated by 3.4.6 for reference.

[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 31 08:46:29 2017
New Revision: 250729

URL: https://gcc.gnu.org/viewcvs?rev=250729=gcc=rev
Log:
PR sanitizer/81604
* ubsan.c (ubsan_type_descriptor): For UBSAN_PRINT_ARRAY don't
change type to the element type, instead add eltype variable and
use it where we are interested in the element type.

* c-c++-common/ubsan/pr81604.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/c-c++-common/ubsan/pr81604.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/ubsan.c

[Bug sanitizer/81530] [8 Regression] ICE in add_stmt in gcc/cp/semantics.c:387

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug c/81629] redefined memcpy leads to segmentation fault

[frederic.besson at inria dot fr]

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

--- Comment #1 from Frédéric Besson  ---
Created attachment 41869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41869=edit
preprcessed source

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
0x0088d7d5 in cp_fold (x=)
at /tmp/trunk/gcc/cp/cp-gimplify.c:2251
2251x = fold_build2_loc (loc, code, TREE_TYPE (x), op0, op1);
Value returned is $25 = (tree_node *) 0x769e6640
(gdb) p debug_generic_expr (op1)
a
$26 = void
(gdb) p debug_generic_expr (op0)
(long int) d.c
$27 = void
(gdb) p debug_generic_expr (x)
(1 ? (int) (long int) d.c : 0) << a
$28 = void

because we run into

static tree
cp_fold (tree x)
{
...
case VEC_COND_EXPR:
case COND_EXPR:
...
  /* A COND_EXPR might have incompatible types in branches if one or both
 arms are bitfields.  If folding exposed such a branch, fix it up.  */
  if (TREE_CODE (x) != code)
if (tree type = is_bitfield_expr_with_lowered_type (x))
  x = fold_convert (type, x);

and fold (int) (long int) d.c to (long int) d.c here.

C++ FE bug.

Not sure why this isn't simply the following as we surely have to preserve
the type of the COND_EXPR when folding.

Index: gcc/cp/cp-gimplify.c
===
--- gcc/cp/cp-gimplify.c(revision 250725)
+++ gcc/cp/cp-gimplify.c(working copy)
@@ -2314,8 +2314,7 @@ cp_fold (tree x)
   /* A COND_EXPR might have incompatible types in branches if one or both
 arms are bitfields.  If folding exposed such a branch, fix it up.  */
   if (TREE_CODE (x) != code)
-   if (tree type = is_bitfield_expr_with_lowered_type (x))
- x = fold_convert (type, x);
+   x = fold_convert (TREE_TYPE (org_x), x);

   break;


Leaving to C++ folks.

[Bug tree-optimization/81627] New: ICE on valid code at -O3: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707

[su at cs dot ucdavis.edu]

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

Bug ID: 81627
   Summary: ICE on valid code at -O3: in
check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:707
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170731 (experimental) [trunk revision 250725] (GCC)
$
$ gcc-trunk -O2 small.c; ./a.out
$
$ gcc-trunk -O3 small.c
during GIMPLE pass: pcom
small.c: In function ‘fn1’:
small.c:3:6: internal compiler error: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:707
 void fn1 ()
  ^~~
0xdd5aed check_loop_closed_ssa_use
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:706
0xdd8b5e verify_loop_closed_ssa(bool)
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:751
0xb6b1a9 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:2008
0xb6bac9 execute_todo
../../gcc-source-trunk/gcc/passes.c:2044
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


-


int a, b, c, d[6], e, f;

void fn1 ()
{ 
  for (b = 1; b < 5; b++)
{ 
  for (c = 0; c < 5; c++)
d[b] = e;
  if (a)
f++;
  d[b + 1] = 1;
}
}

int main ()
{ 
  fn1 ();
  return 0;
}

[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 31 08:56:03 2017
New Revision: 250732

URL: https://gcc.gnu.org/viewcvs?rev=250732=gcc=rev
Log:
PR sanitizer/81604
* ubsan.c (ubsan_type_descriptor): For UBSAN_PRINT_ARRAY don't
change type to the element type, instead add eltype variable and
use it where we are interested in the element type.

* c-c++-common/ubsan/pr81604.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/ubsan/pr81604.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/ubsan.c

[Bug target/81628] New: Backport r250637 and r250638 to the powerpcspe* target

[asolokha at gmx dot com]

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

Bug ID: 81628
   Summary: Backport r250637 and r250638 to the powerpcspe* target
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: andrewjenner at gcc dot gnu.org, charlet at gcc dot gnu.org
  Target Milestone: ---
Target: powerpcspe-*-linux-gnu*

Revisions r250637 and r250638 remove -mno-lra (i.e. reload-based RA) from the
rs6000 target, leaving -mlra as a stub. They also remove -mlra from one
testcase specific to SPE targets.

However, SPE support was factored out to its own target during the stage 1 of
the gcc 8 branch lefiteme, after the point when LRA had been switched on for
rs6000 by default, so -mlra and -mno-lra still make difference there. AFAICT,
tests in testsuite/gcc.target/powerpc are shared by both targets now, so the
changes in testsuite by the aforementioned revisions also affect both of them.
Furtunately, changes in testsuite made there are safe, as they don't change RA
used by the SPE target when compiling them.

Nevertheless, it seems reasonable to disable reload for SPE as well, until two
targets did not diverge too much.

[Bug fortran/81581] runtime checks for DIM argument of intrinsic SUM missing

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Fixed on trunk, closing.

[Bug c/81629] redefined memcpy leads to segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
We'll need something like -Wincompatible-library-redeclaration.  If the user
declares a library function and that declaration is not compatible, shout.

[Bug tree-optimization/81588] [7/8 Regression] Wrong code at -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #41860|0   |1
is obsolete||

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

Untested fix - second attempt.

[Bug c++/81607] 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 #5 from Marek Polacek  ---
cp_genericize_r does this fix-up too, and so has to cp_fold, but apparently
what's in cp_fold isn't enough.

[Bug sanitizer/81604] Ubsan type reporting can be bogus in some cases

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 31 09:29:58 2017
New Revision: 250733

URL: https://gcc.gnu.org/viewcvs?rev=250733=gcc=rev
Log:
PR sanitizer/81604
* ubsan.c (ubsan_type_descriptor): For UBSAN_PRINT_ARRAY don't
change type to the element type, instead add eltype variable and
use it where we are interested in the element type.

* c-c++-common/ubsan/pr81604.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/c-c++-common/ubsan/pr81604.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/ubsan.c

[Bug c/81631] New: -Wcast-qual false positive for pointer to array

[gcc17 at cwde dot de]

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

Bug ID: 81631
   Summary: -Wcast-qual false positive for pointer to array
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc17 at cwde dot de
  Target Milestone: ---

Hi,

--
typedef int footype[6];

extern void const * bar;

void baz(void)
{
  footype const * x;
  x = (footype const *) bar;
}
--

with -Wcast-qual, this yields

--
$ gcc -Wcast-qual -c foo.c
foo.c:12:7: warning: cast discards 'const' qualifier from pointer target type
[-Wcast-qual]
   x = (footype const *) bar;
   ^
--

If "footype" is any other type than an array, I don't get the warning. I tested
gcc 4.5.1, 6.3.0, 7.1.0, on cygwin and Debian, all show this behavior. clang
doesn't warn.

[Bug tree-optimization/81297] [8 Regression] ICE in get_single_symbol

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So we fold (plus -1 -2147483648) with type 'int' and TYPE_OVERFLOW_WRAPS.  That
gets int_const_binop to set TREE_OVERFLOW (because generally fold only looks at
the SIGN and not TYPE_OVERFLOW_* when setting TREE_OVERFLOW).

The unfortunate thing here is that the overflow prevails in sth non-constant at
the end.  But recursively walking all trees to weed out TREE_OVERFLOW after
each folding to non-constant looks awkward (and might even lead to more
folding!?).

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 250725)
+++ gcc/fold-const.c(working copy)
@@ -9107,8 +9107,8 @@ expr_not_equal_to (tree t, const wide_in
Return the folded expression if folding is successful.  Otherwise,
return NULL_TREE.  */

-tree
-fold_binary_loc (location_t loc,
+static tree
+fold_binary_loc_1 (location_t loc,
 enum tree_code code, tree type, tree op0, tree op1)
 {
   enum tree_code_class kind = TREE_CODE_CLASS (code);
@@ -11177,6 +11177,31 @@ fold_binary_loc (location_t loc,
 } /* switch (code) */
 }

+static tree
+drop_tree_overflow_r (tree *expr_p, int *ws, void *)
+{
+  if (TREE_OVERFLOW_P (*expr_p))
+{
+  *expr_p = drop_tree_overflow (*expr_p);
+  *ws = 0;
+}
+  else if (! EXPR_P (*expr_p))
+*ws = 0;
+  return NULL_TREE;
+}
+
+tree
+fold_binary_loc (location_t loc,
+enum tree_code code, tree type, tree op0, tree op1)
+{
+  tree res = fold_binary_loc_1 (loc, code, type, op0, op1);
+  if (res && ! TREE_CONSTANT (res))
+walk_tree (, drop_tree_overflow_r, NULL, NULL);
+ 
+  return res;
+}
+
+
 /* Callback for walk_tree, looking for LABEL_EXPR.  Return *TP if it is
a LABEL_EXPR; otherwise return NULL_TREE.  Do not check the subtrees
of GOTO_EXPR.  */


note we're not properly re-building/folding subtrees here so fold checking
might be unhappy.  It's also not clear that just ignoring TREE_CONSTANT
exprs is enough if you consider folding two non-constant but with dropped
overflow parts to a constant afterwards...

So I'm going to remove the assert in VRP that I added mainly for the
-fstrict-overflow removal as a sanity check.

[Bug testsuite/81624] New: [8 Regression] FAIL: gcc.target/i386/pr59501-3a.c scan-assembler-not and[^\n\r]*sp

[marxin at gcc dot gnu.org]

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

Bug ID: 81624
   Summary: [8 Regression] FAIL: gcc.target/i386/pr59501-3a.c
scan-assembler-not and[^\n\r]*sp
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hjl at gcc dot gnu.org
  Target Milestone: ---

Starting from r250084, the test-case fails.

Thanks.

[Bug tree-optimization/81592] spurious -Wformat-overflow warning with -fsanitize=signed-integer-overflow

[arnd at linaro dot org]

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

--- Comment #2 from Arnd Bergmann  ---
I have scanned the linux kernel sources for related bogus warnings and found
six others like this one that do not show up using gcc-7.1.1 without UBSAN but
do show up with UBSAN added in:

security/keys/proc.c: In function 'proc_keys_show':
security/keys/proc.c:232:19: error: '%lu' directive writing between 1 and 20
bytes into a region of size 16 [-Werror=format-overflow=]
sound/soc/fsl/fsl_sai.c: In function 'fsl_sai_probe':
sound/soc/fsl/fsl_sai.c:837:21: error: '%d' directive writing between 1 and 10
bytes into a region of size 4 [-Werror=format-overflow=]
drivers/block/cciss.c: In function 'cciss_init_one':
drivers/block/cciss.c:5039:28: error: '%d' directive writing between 1 and 10
bytes into a region of size 3 [-Werror=format-overflow=]
sound/isa/gus/gus_mem_proc.c: In function 'snd_gf1_mem_proc_init':
sound/isa/gus/gus_mem_proc.c:72:27: error: '%i' directive writing between 1 and
10 bytes into a region of size 8 [-Werror=format-overflow=]
sound/isa/gus/gus_mem_proc.c:72:18: note: directive argument in the range [0,
2147483646]
drivers/net/ethernet/marvell/mvneta_bm.c: In function 'mvneta_bm_probe':
drivers/net/ethernet/marvell/mvneta_bm.c:306:17: error: ',capacity' directive
writing 9 bytes into a region of size between 1 and 10
[-Werror=format-overflow=]
drivers/net/ethernet/marvell/mvneta_bm.c:306:3: note: 'sprintf' output between
15 and 24 bytes into a destination of size 15
drivers/pnp/pnpbios/proc.c: In function 'pnpbios_proc_exit':
drivers/pnp/pnpbios/proc.c:338:18: error: '%02x' directive writing between 2
and 8 bytes into a region of size 3 [-Werror=format-overflow=]
drivers/pnp/pnpbios/proc.c:338:17: note: directive argument in the range [0,
2147483646]
drivers/mfd/max77620.c: In function 'max77620_probe':
drivers/mfd/max77620.c:282:25: error: '%d' directive writing between 1 and 10
bytes into a region of size 7 [-Werror=format-overflow=]

These are all similarly bogus to the original warning, in all cases it seems
that gcc normally has no problems identifying the range. I can provide
preprocessed source files for all instances if that helps.

[Bug c/81630] powl returns values with insufficient accuracy

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse  ---
> Apple LLVM version 8.1.0 (clang-802.0.42)

That's not gcc.

[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Adding to CC people who can know how initialization of TLS stack protection
canary should work.

[Bug tree-optimization/81603] Various compiler UB on very large constant offsets

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 31 08:22:14 2017
New Revision: 250727

URL: https://gcc.gnu.org/viewcvs?rev=250727=gcc=rev
Log:
PR tree-optimization/81603
* ipa-polymorphic-call.c
(ipa_polymorphic_call_context::ipa_polymorphic_call_context): Perform
offset arithmetic in offset_int, bail out if the resulting bit offset
doesn't fit into shwi.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-polymorphic-call.c

[Bug tree-optimization/81627] [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org
Version|unknown |8.0
   Target Milestone|--- |8.0
Summary|ICE on valid code at -O3:   |[8 Regression] ICE on valid
   |in  |code at -O3: in
   |check_loop_closed_ssa_use,  |check_loop_closed_ssa_use,
   |at  |at
   |tree-ssa-loop-manip.c:707   |tree-ssa-loop-manip.c:707

--- Comment #1 from Richard Biener  ---
pcom -> Bin.

[Bug sanitizer/81530] [8 Regression] ICE in add_stmt in gcc/cp/semantics.c:387

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Mon Jul 31 08:53:00 2017
New Revision: 250730

URL: https://gcc.gnu.org/viewcvs?rev=250730=gcc=rev
Log:
Do UBSAN sanitization just when current_function_decl != NULL_TREE (PR
sanitize/81530).

2017-07-31  Martin Liska  

PR sanitize/81530
* cp-gimplify.c (cp_genericize): Guard condition with flag_sanitize_p
also with current_function_decl non-null equality.
* cp-ubsan.c (cp_ubsan_instrument_vptr_p): Likewise.
* decl.c (compute_array_index_type): Likewise.
* init.c (finish_length_check): Likewise.
* typeck.c (cp_build_binary_op): Likewise.
2017-07-31  Martin Liska  

PR sanitize/81530
* c-convert.c (convert): Guard condition with flag_sanitize_p
also with current_function_decl non-null equality.
* c-decl.c (grokdeclarator): Likewise.
* c-typeck.c (build_binary_op): Likewise.
2017-07-31  Martin Liska  

PR sanitize/81530
* convert.c (convert_to_integer_1): Guard condition with
flag_sanitize_p
also with current_function_decl non-null equality.
2017-07-31  Martin Liska  

PR sanitize/81530
* c-ubsan.c (ubsan_maybe_instrument_array_ref):
Guard condition with flag_sanitize_p also with current_function_decl
non-null equality.
(ubsan_maybe_instrument_reference_or_call): Likewise.
2017-07-31  Martin Liska  

PR sanitize/81530
* g++.dg/ubsan/pr81530.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/pr81530.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-ubsan.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-convert.c
trunk/gcc/c/c-decl.c
trunk/gcc/c/c-typeck.c
trunk/gcc/convert.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-ubsan.c
trunk/gcc/cp/decl.c
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/81581] runtime checks for DIM argument of intrinsic SUM missing

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Jul 31 09:34:36 2017
New Revision: 250735

URL: https://gcc.gnu.org/viewcvs?rev=250735=gcc=rev
Log:
2017-07-31  Thomas Koenig  

PR fortran/81581
* m4/ifuntion.m4 (name`'rtype_qual`_'atype_code): Perform check
for dim.
(`m'name`'rtype_qual`_'atype_code): Likewise. Change type of rank
and tim to index_type.
(`s'name`'rtype_qual`_'atype_code): Perform check for dim.
* generated/iall_i16.c: Regenerated.
* generated/iall_i1.c: Regenerated.
* generated/iall_i2.c: Regenerated.
* generated/iall_i4.c: Regenerated.
* generated/iall_i8.c: Regenerated.
* generated/iany_i16.c: Regenerated.
* generated/iany_i1.c: Regenerated.
* generated/iany_i2.c: Regenerated.
* generated/iany_i4.c: Regenerated.
* generated/iany_i8.c: Regenerated.
* generated/iparity_i16.c: Regenerated.
* generated/iparity_i1.c: Regenerated.
* generated/iparity_i2.c: Regenerated.
* generated/iparity_i4.c: Regenerated.
* generated/iparity_i8.c: Regenerated.
* generated/maxloc1_16_i16.c: Regenerated.
* generated/maxloc1_16_i1.c: Regenerated.
* generated/maxloc1_16_i2.c: Regenerated.
* generated/maxloc1_16_i4.c: Regenerated.
* generated/maxloc1_16_i8.c: Regenerated.
* generated/maxloc1_16_r10.c: Regenerated.
* generated/maxloc1_16_r16.c: Regenerated.
* generated/maxloc1_16_r4.c: Regenerated.
* generated/maxloc1_16_r8.c: Regenerated.
* generated/maxloc1_4_i16.c: Regenerated.
* generated/maxloc1_4_i1.c: Regenerated.
* generated/maxloc1_4_i2.c: Regenerated.
* generated/maxloc1_4_i4.c: Regenerated.
* generated/maxloc1_4_i8.c: Regenerated.
* generated/maxloc1_4_r10.c: Regenerated.
* generated/maxloc1_4_r16.c: Regenerated.
* generated/maxloc1_4_r4.c: Regenerated.
* generated/maxloc1_4_r8.c: Regenerated.
* generated/maxloc1_8_i16.c: Regenerated.
* generated/maxloc1_8_i1.c: Regenerated.
* generated/maxloc1_8_i2.c: Regenerated.
* generated/maxloc1_8_i4.c: Regenerated.
* generated/maxloc1_8_i8.c: Regenerated.
* generated/maxloc1_8_r10.c: Regenerated.
* generated/maxloc1_8_r16.c: Regenerated.
* generated/maxloc1_8_r4.c: Regenerated.
* generated/maxloc1_8_r8.c: Regenerated.
* generated/maxval_i16.c: Regenerated.
* generated/maxval_i1.c: Regenerated.
* generated/maxval_i2.c: Regenerated.
* generated/maxval_i4.c: Regenerated.
* generated/maxval_i8.c: Regenerated.
* generated/maxval_r10.c: Regenerated.
* generated/maxval_r16.c: Regenerated.
* generated/maxval_r4.c: Regenerated.
* generated/maxval_r8.c: Regenerated.
* generated/minloc1_16_i16.c: Regenerated.
* generated/minloc1_16_i1.c: Regenerated.
* generated/minloc1_16_i2.c: Regenerated.
* generated/minloc1_16_i4.c: Regenerated.
* generated/minloc1_16_i8.c: Regenerated.
* generated/minloc1_16_r10.c: Regenerated.
* generated/minloc1_16_r16.c: Regenerated.
* generated/minloc1_16_r4.c: Regenerated.
* generated/minloc1_16_r8.c: Regenerated.
* generated/minloc1_4_i16.c: Regenerated.
* generated/minloc1_4_i1.c: Regenerated.
* generated/minloc1_4_i2.c: Regenerated.
* generated/minloc1_4_i4.c: Regenerated.
* generated/minloc1_4_i8.c: Regenerated.
* generated/minloc1_4_r10.c: Regenerated.
* generated/minloc1_4_r16.c: Regenerated.
* generated/minloc1_4_r4.c: Regenerated.
* generated/minloc1_4_r8.c: Regenerated.
* generated/minloc1_8_i16.c: Regenerated.
* generated/minloc1_8_i1.c: Regenerated.
* generated/minloc1_8_i2.c: Regenerated.
* generated/minloc1_8_i4.c: Regenerated.
* generated/minloc1_8_i8.c: Regenerated.
* generated/minloc1_8_r10.c: Regenerated.
* generated/minloc1_8_r16.c: Regenerated.
* generated/minloc1_8_r4.c: Regenerated.
* generated/minloc1_8_r8.c: Regenerated.
* generated/minval_i16.c: Regenerated.
* generated/minval_i1.c: Regenerated.
* generated/minval_i2.c: Regenerated.
* generated/minval_i4.c: Regenerated.
* generated/minval_i8.c: Regenerated.
* generated/minval_r10.c: Regenerated.
* generated/minval_r16.c: Regenerated.
* generated/minval_r4.c: Regenerated.
* generated/minval_r8.c: Regenerated.
* generated/norm2_r10.c: Regenerated.
* generated/norm2_r16.c: Regenerated.
* generated/norm2_r4.c: Regenerated.
* generated/norm2_r8.c: Regenerated.
* generated/parity_l16.c: Regenerated.
* 

[Bug target/25967] Add attribute naked for x86

[uros at gcc dot gnu.org]

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

--- Comment #17 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jul 31 10:22:41 2017
New Revision: 250736

URL: https://gcc.gnu.org/viewcvs?rev=250736=gcc=rev
Log:
PR target/25967
* config/i386/i386.c (ix86_function_naked): New function.
(ix86_can_use_return_insn_p): Return false for naked functions.
(ix86_expand_prologue): Skip prologue for naked functions.
(ix86_expand_epilogue): Skip epilogue for naked functions
and emit trap instruction.
(ix86_warn_func_return): New function.
(ix86_attribute_table): Add "naked" attribute specification.
(TARGET_WARN_FUNC_RETURN): Define.
* doc/extend.texi (x86 Function Attributes) : Document it.

testsuite/ChangeLog:

PR target/25967
* gcc.target/i386/naked-1.c: New test.
* gcc.target/i386/naked-2.c: Ditto.
* gcc.target/i386/naked-3.c: Ditto.
* gcc.target/x86_64/abi/ms-sysv/ms-sysv.c: Remove
do_test_body0 stub function, use attribute "naked" instead.
* gcc.dg/pr44290-1.c: Use naked_functions effective target.
* gcc.dg/pr44290-2.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/naked-1.c
trunk/gcc/testsuite/gcc.target/i386/naked-2.c
trunk/gcc/testsuite/gcc.target/i386/naked-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr44290-1.c
trunk/gcc/testsuite/gcc.dg/pr44290-2.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c

[Bug c++/81607] 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|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug target/25967] Add attribute naked for x86

[daniel.santos at pobox dot com]

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

--- Comment #19 from Daniel Santos  ---
(In reply to Uroš Bizjak from comment #18)
> Implemented for gcc 8.

Awesome!  There are actually a number of times over the years that I've wished
this were implemented, thanks! :)

[Bug testsuite/81626] Need effective target omp_target

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Created attachment 41871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41871=edit
Tentative patch

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

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

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

Andreas Schwab  changed:

   What|Removed |Added

Version|8.0 |7.0
   Target Milestone|--- |7.2

[Bug target/25967] Add attribute naked for x86

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #18 from Uroš Bizjak  ---
Implemented for gcc 8.

[Bug hsa/81477] HSA offloading regressions: "function cannot be cloned"

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Jambor  ---
Fixed.

[Bug libstdc++/81599] Error in documentation of std::stack

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.  I'll send a patch.

[Bug c++/81632] New: spurious -Wterminate warning about throw in destructor

[akim.demaille at gmail dot com]

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

Bug ID: 81632
   Summary: spurious -Wterminate warning about throw in destructor
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akim.demaille at gmail dot com
  Target Milestone: ---

In the following piece of code GCC issues a spurious warning about an exception
that escapes a dtor, although it is actually caught.

Observed with GCC 6 and 7.  GCC 5 does not feature -Wterminate.

$ cat /tmp/foo.cc
struct foo
{
  ~foo()
  {
try
  {
throw 42;
  }
catch (int)
  {
throw;
  }
catch (...)
  {
  }
  }
};

int main()
{

}
$ g++-mp-6 --version
g++-mp-6 (MacPorts gcc6 6.3.0_2) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-mp-6 -Wterminate /tmp/foo.cc -std=c++14
/tmp/foo.cc: In destructor 'foo::~foo()':
/tmp/foo.cc:11:9: warning: throw will always call terminate() [-Wterminate]
 throw;
 ^
/tmp/foo.cc:11:9: note: in C++11 destructors default to noexcept
$ g++-mp-7 --version
g++-mp-7 (MacPorts gcc7 7-20170622_0) 7.1.
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-mp-7 -Wterminate /tmp/foo.cc -std=c++14
/tmp/foo.cc: In destructor 'foo::~foo()':
/tmp/foo.cc:11:9: warning: throw will always call terminate() [-Wterminate]
 throw;
 ^
/tmp/foo.cc:11:9: note: in C++11 destructors default to noexcept

There is no such warning if this try/catch is wrapped in another one, so that's
really just the logic of bouncing to another catch clause that is missing.

Cheers!

[Bug libstdc++/81599] Error in documentation of std::stack

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Mon Jul 31 13:44:16 2017
New Revision: 250743

URL: https://gcc.gnu.org/viewcvs?rev=250743=gcc=rev
Log:
PR libstdc++/81599
* include/bits/stl_stack.h: Fix typo.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_stack.h

[Bug c++/81618] Warn for unused functions declared in local scope

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-31
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
This request makes sense to me as an enhancement to -Wunused-function.   With
all the different forms of initialization in C++, it's not rare to accidentally
declare a function when a variable is intended, e.g., like so:

  template 
  void f ()
  {
T x ();   // declares an external function
T y (T ());   // ditto
  }

These mistakes are usually exposed when the symbol is used in a context where
an object is expected but extending -Wunused-function to diagnose locally
declared functions would help detect those that are not.

[Bug tree-optimization/81633] [7/8 Regression] Incorrect floating point result with tree vectoriser

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
In -fdump-tree-vect-details, the difference with this commit is:
--- pr81633.c.149t.vect.239539 2017-07-31 12:00:11.0 -0400
+++ pr81633.c.149t.vect.239542 2017-07-31 12:00:33.0 -0400
@@ -1721,8 +1721,8 @@ pr81633.c:10:5: note: vect_is_simple_use
 pr81633.c:10:5: note: def_stmt: _69 = identity[j_31][0];
 pr81633.c:10:5: note: type of def: internal
 pr81633.c:10:5: note: transform binary/unary operation.
-pr81633.c:10:5: note: add new stmt: vect__71.20_33 = vect__69.14_23 *
vect__69.18_14;
-pr81633.c:10:5: note: add new stmt: vect__71.20_19 = vect__69.15_22 *
vect__69.19_18;
+pr81633.c:10:5: note: add new stmt: vect__71.20_33 = vect__69.14_23 *
vect__69.14_23;
+pr81633.c:10:5: note: add new stmt: vect__71.20_19 = vect__69.15_22 *
vect__69.15_22;
 pr81633.c:10:5: note: -->vectorizing SLP node starting from: tmp[j_31][0]
= _71;
 pr81633.c:10:5: note: vect_is_simple_use: operand _71
 pr81633.c:10:5: note: def_stmt: _71 = _69 * _69;
@@ -1753,8 +1753,8 @@ pr81633.c:10:5: note: -->vectorizing
 pr81633.c:10:5: note: -->vectorizing statement: vectp_identity.16_5 =
vectp_identity.16_17 + 16;
 pr81633.c:10:5: note: -->vectorizing statement: vect__69.19_18 =
MEM[(double *)vectp_identity.16_5];
 pr81633.c:10:5: note: -->vectorizing statement: _91 = identity[j_31][3];
-pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_33 =
vect__69.14_23 * vect__69.18_14;
-pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_19 =
vect__69.15_22 * vect__69.19_18;
+pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_33 =
vect__69.14_23 * vect__69.14_23;
+pr81633.c:10:5: note: -->vectorizing statement: vect__71.20_19 =
vect__69.15_22 * vect__69.15_22;
 pr81633.c:10:5: note: -->vectorizing statement: _92 = _69 * _91;
 pr81633.c:10:5: note: -->vectorizing statement: MEM[(double
*)vectp_tmp.21_16] = vect__71.20_33;
 pr81633.c:10:5: note: -->vectorizing statement: vectp_tmp.21_87 =
vectp_tmp.21_16 + 16;
@@ -1864,8 +1864,8 @@ main ()
   vectp_identity.16_5 = vectp_identity.16_17 + 16;
   vect__69.19_18 = MEM[(double *)vectp_identity.16_5];
   _91 = identity[j_31][3];
-  vect__71.20_33 = vect__69.14_23 * vect__69.18_14;
-  vect__71.20_19 = vect__69.15_22 * vect__69.19_18;
+  vect__71.20_33 = vect__69.14_23 * vect__69.14_23;
+  vect__71.20_19 = vect__69.15_22 * vect__69.15_22;
   _92 = _69 * _91;
   MEM[(double *)vectp_tmp.21_16] = vect__71.20_33;
   vectp_tmp.21_87 = vectp_tmp.21_16 + 16;

The multiplication has different operands, so the newer output looks clearly
wrong.

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

[raskolnikov at gnu dot org]

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

Bug ID: 81634
   Summary: Some types are incorrectly detected as not standard
layout
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raskolnikov at gnu dot org
  Target Milestone: ---

The following code fails to compile with GCC 7.1.0 when passing -std=c++17:

```
#include 

struct a {};
struct b { int x; };
struct ca : a {};
struct cb : ca { b x; };
static_assert(std::is_standard_layout::value, "");
```

https://wandbox.org/permlink/DjuHERFFvgJg84ub

Instead of using `is_standard_layout`, we can detect the bug by using
`offsetof(cb, b)`, which incorrectly rises a warning about `cb` not being
standard layout.

It does work as expected, with -std=c++14 or with other versions of GCC.

[Bug tree-optimization/81633] [7/8 Regression] Incorrect floating point result with tree vectoriser

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-31
 CC||alahay01 at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |7.2
Summary|Incorrect floating point|[7/8 Regression] Incorrect
   |result with tree vectoriser |floating point result with
   ||tree vectoriser
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r239542.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
The aligned computation also looks like invalid IL, BIT_AND_EXPR should not
have pointer arguments I believe (though please double check with Richard), so
it should be first cast to corresponding integral type with the same precision,
then masked and then cast back to the pointer type.

[Bug testsuite/81626] Need effective target omp_target

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #3)
> Yeah, I suppose you just need to remove a "--disable-multilib" from your
> nvptx offloading GCC build configuration, so that the "mgomp" multilib gets
> built in addition to the "default" one?

It would be great if it is that simple. Have you ever tried that?

I see you're the one who's added the "--disable-multilib" in our nvptx
offloading GCC build configuration (which is what I'm using). What was the
reason for that?

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

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak  ---
I'm testing the following patch:

--cut here--
Index: i386.c
===
--- i386.c  (revision 250745)
+++ i386.c  (working copy)
@@ -19421,8 +19421,10 @@ ix86_print_operand_address_as (FILE *file, rtx add
   fputs (string, file);
 }

-  /* Use one byte shorter RIP relative addressing for 64bit mode.  */
-  if (TARGET_64BIT && !base && !index && !no_rip)
+  /* Use one byte shorter RIP relative addressing for
+ symbols in the generic address space.  */
+  if (TARGET_64BIT && !base && !index
+  && ADDR_SPACE_GENERIC_P (as) && !no_rip)
 {
   rtx symbol = disp;

@@ -19442,7 +19444,7 @@ ix86_print_operand_address_as (FILE *file, rtx add
   /* Displacement only requires special attention.  */
   if (CONST_INT_P (disp))
{
- if (ASSEMBLER_DIALECT == ASM_INTEL && parts.seg ==
ADDR_SPACE_GENERIC)
+ if (ASSEMBLER_DIALECT == ASM_INTEL && ADDR_SPACE_GENERIC_P (as))
fputs ("ds:", file);
  fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (disp));
}
--cut here--

The patched compiler compiles following testcase:

--cut here--
int __seg_gs a;

void test_as (void)
{
  a += 1;
}

__thread int b;

void test_thr (void)
{
  b += 2;
}
--cut here--

to:

test_as:
addl$1, %gs:a
ret

test_thr:
addl$2, %fs:b@tpoff
ret

[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Thomas Koenig  ---
I agree that the current handling of *.f90 and *.f with
-cpp and -save-temps is undocumented and partially broken.

Consider creating a *.f90 file from a *.f file:

$ cat foo.f
  programme main
  end
$ gfortran -cpp -save-temps foo.f
$ cat foo.f90
# 1 "foo.f"
# 1 ""
# 1 ""
# 1 "foo.f"
  programme main
  end
$ gfortran foo.f90 
foo.f90:1:13:

 # 1 "foo.f"
 1
Fehler: Ungültige Form der PROGRAM-Anweisung bei (1)

Here, we generate a fixed-form program source with an
extension that is usually an indicator of fixed form.

One possibility would be to disable -save-temps together
with -cpp when the source file is *.f or *.f90 (or *.f03).

Creating *.f90 from *.F90 is also dangerous on Windows systems.

I think creating *.i and *.i90 files, respectively, would be
a better option. ifort does so, so there is at least some
precedent.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Created attachment 41875
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41875=edit
gcc8-pr81622.patch

There are many other issues in that function.

As for ARRAY_TYPE, do you have a testcase that would show how you could end up
with ARRAY_TYPE there?  I mean, C/C++ array-to-pointer conversion should happen
already before this function is called.  Or can say passing reference-to-array
result in that?

There is another issue I haven't fixed, because it means adjusting hundreds of
tests:
error ("Builtin function %s not supported in this compiler configuration",
should not use capital letter in Builtin, that is against GCC diagnostic
conventions.

[Bug libstdc++/81599] Error in documentation of std::stack

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/81633] New: Incorrect floating point result with tree vectoriser

[wence at gmx dot li]

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

Bug ID: 81633
   Summary: Incorrect floating point result with tree vectoriser
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wence at gmx dot li
  Target Milestone: ---

Created attachment 41873
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41873=edit
Preprocessed source.

The attached source (reduced from a real kernel) multiplies a 4x4 identity
matrix by its first column,  It should produce the output:

1 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0

With GCC 7.1.0, (and a recent 8.0.0 snapshot) it produces instead:

1 1 1 1
0 0 0 0
0 0 0 0
0 0 0 0

The bug disappears if I say either -fno-tree-vectorize or
-fno-tree-loop-vectorize

$ gcc -o prog.exe -Wall -Wextra -std=c99 -pedantic -O3 -v prog.c
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-7.1.0/bin/gcc
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-7.1.0/configure --prefix=/opt/wandbox/gcc-7.1.0
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-7.1.0/lib,-rpath,/opt/wandbox/gcc-7.1.0/lib64,-rpath,/opt/wandbox/gcc-7.1.0/lib32
--enable-lto
Thread model: posix
gcc version 7.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-Wpedantic' '-std=c99' '-Wall' '-Wextra'
'-O3' '-v' '-mtune=generic' '-march=x86-64'
 /opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/cc1 -quiet -v
-imultiarch x86_64-linux-gnu prog.c -quiet -dumpbase prog.c -mtune=generic
-march=x86-64 -auxbase prog -O3 -Wpedantic -Wall -Wextra -std=c99 -version -o
/tmp/ccorXUPc.s
GNU C99 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include
 /opt/wandbox/gcc-7.1.0/include
 /opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C99 (GCC) version 7.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5122689c716743eb07fee255d0dfe7c4
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-Wpedantic' '-std=c99' '-Wall' '-Wextra'
'-O3' '-v' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/cc0c1aeA.o /tmp/ccorXUPc.s
GNU assembler version 2.26.1 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.26.1
COMPILER_PATH=/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-Wpedantic' '-std=c99' '-Wall' '-Wextra'
'-O3' '-v' '-mtune=generic' '-march=x86-64'
 /opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/collect2 -plugin
/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/liblto_plugin.so
-plugin-opt=/opt/wandbox/gcc-7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccfS7LEX.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
prog.exe /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/crtbegin.o
-L/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0
-L/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/opt/wandbox/gcc-7.1.0/lib/gcc/x86_64-pc-linux-gnu/7.1.0/../../.. -rpath
/opt/wandbox/gcc-7.1.0/lib64 /tmp/cc0c1aeA.o -lgcc --as-needed -lgcc_s

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #2 from Bill Schmidt  ---
Never mind, it fails that way as well.  Confirmed.  I had thought we had seen
and fixed this scenario some time ago...

[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
TLS canary is initialized by the libc; in Glibc sources you can grep for
THREAD_STACK_SET_GUARD.

In this example the leftmost byte of the SSP canary is overwritten by a zero.
This does not change the canary because Glibc deliberately zeroes that leftmost
byte (presumably, to harden against information-leak attacks when a string
function like strcpy can be used to copy the canary value in an
attacker-controlled manner):

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/dl-osinfo.h;h=823cd8224df939134018fbd8f0227e9f501393ab;hb=HEAD#l63

So what is the GCC bug here? What do we want to change?

[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
> I was under the impression that I would get a test0.i file since the only
> documentation of using -save-temps I can find comes from the gcc docs:
> https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-save-temps

Which says

 Store the usual “temporary” intermediate files permanently.

> which mentions *.i files in their example.

because the compiled file is a C file. The *.i (*.ii) files are C (C++ files),
thus cannot (shall not) be produced by gfortran.

As noticed in comment 0, -save-temps generates a preprocessed *.f90 if it does
not already exists. Note that INCLUDE statements are ignored.

IMO this PR should be closed as INVALID or WONTFIX.

[Bug testsuite/81626] Need effective target omp_target

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords|openacc |
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-31
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
Yeah, I suppose you just need to remove a "--disable-multilib" from your nvptx
offloading GCC build configuration, so that the "mgomp" multilib gets built in
addition to the "default" one?

[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jan.kratochvil at redhat dot 
com,
   ||palves at redhat dot com

--- Comment #3 from Jakub Jelinek  ---
For the N_SLINE stuff, I guess something like:
--- dbxout.c.jj 22017-07-29 09:50:38.0 +0200
+++ dbxout.c 2017-07-31 14:30:00.474385901 +0200
@@ -1273,7 +1273,8 @@ dbxout_source_line (unsigned int lineno,
 #ifdef DBX_OUTPUT_SOURCE_LINE
   DBX_OUTPUT_SOURCE_LINE (asm_out_file, lineno, dbxout_source_line_counter);
 #else
-  if (DBX_LINES_FUNCTION_RELATIVE)
+  if (DBX_LINES_FUNCTION_RELATIVE
+  && in_cold_section_p == first_function_block_is_cold)
 {
   char begin_label[20];
   dbxout_begin_stabn_sline (lineno);

could cure that part.  No idea how the debugger finds out if it is absolute or
relative though.
Then there is DBX_BLOCKS_FUNCTION_RELATIVE macro which decides if N_LBRAC or
N_RBRAC should be relative to start of function or not.  Again, no idea how the
debugger finds out if it is relative or absolute.
So I guess we need help from the debugger folks here...

[Bug target/25967] Add attribute naked for x86

[uros at gcc dot gnu.org]

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

--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jul 31 13:11:59 2017
New Revision: 250742

URL: https://gcc.gnu.org/viewcvs?rev=250742=gcc=rev
Log:
PR target/25967
* config/i386/i386.c (ix86_allocate_stack_slots_for_args):
New function.
(TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS): Define.

testsuite/ChangeLog:

PR target/25967
* gcc.target/i386/naked-3.c (dg-options): Use -O0.
(naked): Add attribute regparm(1) for x86_32 targets.
Add integer argument.  Remove global "data" variable.
(main): Pass integer argument to naked function.
* gcc.target/i386/naked-4.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/naked-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/naked-3.c

[Bug libgomp/81591] segmentation fault when using priorities of nested tasks

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I think we need a reproducer for this.  Can you provide something?

[Bug libgomp/81591] segmentation fault when using priorities of nested tasks

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Before that is available, perhaps backtrace from the gomp_fatal call in the
_LIBGOMP_CHECKING_ enabled build might be also useful.

[Bug testsuite/81624] [8 Regression] FAIL: gcc.target/i386/pr59501-3a.c scan-assembler-not and[^\n\r]*sp

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC|hjl at gcc dot gnu.org |jakub at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

--- Comment #1 from H.J. Lu  ---
A patch was posted at

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00400.html

and waiting from review from Jakub:

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01568.html

H.J.

[Bug target/25967] Add attribute naked for x86

[ubizjak at gmail dot com]

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

--- Comment #21 from Uroš Bizjak  ---
The above patch is needed to pass arguments to a naked function.

Please note that arguments can be reliably passed only in registers, so regparm
convention is necessary for x86_32.

gcc.target/i386/naked-3.c and gcc.target/i386/naked-4.c testcases show function
arguments and function result passing in action.

[Bug libstdc++/81599] Error in documentation of std::stack

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/51515] Unable to forward declare nested functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Because it's not valid C.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
Do you see the same behavior with "vec_ld (1, 2);" ?

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #3 from Bill Schmidt  ---
Mine, need to avoid an optimization when we don't have a pointer/array type.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Created attachment 41874
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41874=edit
Patch under test

[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files

[barrowes at alum dot mit.edu]

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

--- Comment #2 from Ben Barrowes  ---
Then how does one get a preprocessed/savetemp file from an existing *.f90 file?

In the case of C, preprocessed and temp files have different extensions and are
thus easily identified after compiling. For gfortran,
preprocessing/saveingtemps of *.f files produces *.f90 files which is
confusing, and preprocessing/savetemps of *.f90 files produces no output.

Gfortran needs to produce preprocessed/savetemps that have unique and easily
identifiable extensions. If not *.i and *.i90, then something else like *.t and
*.t90 or similar.

[Bug debug/81307] [8 regression] g++.dg/debug/debug9.C -gstabs FAILs

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Looking at gdb I see though that the block_address_function_relative variable
is computed from the object format, so I'm afraid it has to be relative.
Another option is to pretend there isn't just one function, but two with the
same origin.
As -g* options shouldn't affect code generation, we can hardly disable hot/cold
partitioning if -gstabs is used.

[Bug testsuite/81626] Need effective target omp_target

[tschwinge at gcc dot gnu.org]

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

--- Comment #5 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #4)
> (In reply to Thomas Schwinge from comment #3)
> > Yeah, I suppose you just need to remove a "--disable-multilib" from your
> > nvptx offloading GCC build configuration, so that the "mgomp" multilib gets
> > built in addition to the "default" one?
> 
> It would be great if it is that simple.

It is (at least in my build scripts).

> Have you ever tried that?

Have been using that ever since the OpenMP nvptx offloading got committed to
GCC trunk, which added the "mgomp" multilib, r242503 "nvptx backend
prerequisites for OpenMP offloading".

> I see you're the one who's added the "--disable-multilib" in our nvptx
> offloading GCC build configuration (which is what I'm using).

Which exactly?

> What was the
> reason for that?

Off-hand I can only remember using "--disable-multilib" for the target GCC
build configuration, for we're not supporting offloading in 32-bit
configurations, and are thus interested only in 64-bit x86_64 but not 32-bit
i686, which also gets built by default for x86_64-pc-linux-gnu.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
I went spelunking and found that the ARRAY_TYPE change was added here: 
https://gcc.gnu.org/viewcvs/gcc?view=revision=237077.  Looks like a
C++ implementation detail.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
(In reply to Jakub Jelinek from comment #9)
> I take back the ARRAY_TYPE thing, apparently it is different for C vs. C++,
> in C one always sees there POINTER_TYPE, while in C++ always ARRAY_TYPE.
> Anyway, your patch seems to be wrong, POINTER_TYPE_P's argument should be a
> type, while you are passing it an argument instead ((*arglist)[1] is arg1,
> not
> arg1_type = TREE_TYPE (arg1)).

Yes, I agree.  I'll let you lead on this from here as you are well into it. 
Thanks!

[Bug c/80130] Wrong diagnostic: dereferencing type-punned pointer

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
I only get 1 warning on (1) and only with -Wstrict-aliasing=1.
-Wstrict-aliasing=2 and -Wstrict-aliasing=3 are both silent.

(In reply to Richard Biener from comment #1)
> The warning implementation is incredibly stupid, don't use it.  It doesn't
> have any context (so the two stmt variant is different from the single stmt
> one).

It'd still be nice if it could be improved though. Although, maybe it already
has been?

[Bug tree-optimization/81633] [7/8 Regression] Incorrect floating point result with tree vectoriser

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
I'm afraid the tree-vect-slp.c change is completely wrong, the original change
in
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01090.html if the oprnd == NULL
has child_index++; looks reasonable to me.  It changed a fragile code into much
more fragile code which will be always wrong if there are stmts with duplicated
(or more) operands.
Trying to recompute child_index from just oprnd is wrong, there can be multiple
arguments equal to the same SSA_NAME and which exact one it is should really be
derived from the index (dunno why we need child_index var, wouldn't it be
sufficient to use i for that)?
Are there (after the tree-vect-loop.c caller has been fixed in the same
revision) any vect_get_slp_defs callers which pass arguments with gaps or where
the oprnd i to child_index mapping shouldn't be identity?
I wonder about COND_EXPR with non-COMPARISON_CLASS_P first argument, but am not
sure.
E.g. vect_create_new_slp_node counts it as 2 regardless of what the first
argument is:
  else if (is_gimple_assign (stmt))
{
  nops = gimple_num_ops (stmt) - 1;
  if (gimple_assign_rhs_code (stmt) == COND_EXPR)
nops++;
}
while vect_get_and_check_slp_defs has:
  if (gimple_assign_rhs_code (stmt) == COND_EXPR
  && COMPARISON_CLASS_P (gimple_assign_rhs1 (stmt)))
{
  first_op_cond = true;
  number_of_oprnds++;
}
which then matches e.g. masked handling in tree-vect-stmts.c
(vectorizable_condition).

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

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed that gcc ICEs, although is 'c' really the right component?

[Bug c/29970] mixing ({...}) with VLA leads to massive breakage

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=30552

--- Comment #5 from Eric Gallager  ---
Related due to also mixing ({...}) with VLA: bug 30552. (Can stay separate
since they're different testcases though)

[Bug c/79667] spurious -Wunused-variable on a local array of struct declared unused

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug c++/81636] New: Confusing warning message containing "#‘obj_type_ref’ not supported by expression#"

[abbeyj+gcc at gmail dot com]

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

Bug ID: 81636
   Summary: Confusing warning message containing "#‘obj_type_ref’
not supported by expression#"
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abbeyj+gcc at gmail dot com
  Target Milestone: ---

This occurs with any version of GCC that I've tried that recognizes -std=c++11.
 It seems to affect all versions v4.7.1 through v7.1 according to
https://gcc.godbolt.org/

Test case:
class C {
  virtual int MyVirtual();
  void Foo();
};

void C::Foo() {
  int x{ MyVirtual() / 2.0 };
}


$ g++-4.9.4 -std=c++11 -c test.cpp
test.cpp: In member function ‘void C::Foo()’:
test.cpp:7:22: warning: narrowing conversion of ‘((double)(#‘obj_type_ref’ not
supported by expression#)(this) / 2.0e+0)’ from ‘double’ to ‘int’ inside { }
[-Wnarrowing]
   int x{ MyVirtual() / 2.0 };
  ^


I believe that GCC is correct to issue a warning here.  But the text of the
warning message is not friendly, especially the "#‘obj_type_ref’ not supported
by expression#" part.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
I take back the ARRAY_TYPE thing, apparently it is different for C vs. C++, in
C one always sees there POINTER_TYPE, while in C++ always ARRAY_TYPE.
Anyway, your patch seems to be wrong, POINTER_TYPE_P's argument should be a
type, while you are passing it an argument instead ((*arglist)[1] is arg1, not
arg1_type = TREE_TYPE (arg1)).