[Bug c/81709] New: __attribute__((interrupt)) should handle SSE registers

[anatol.pomozov at gmail dot com]

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

Bug ID: 81709
   Summary: __attribute__((interrupt)) should handle SSE registers
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anatol.pomozov at gmail dot com
  Target Milestone: ---

GCC documentation for __attribute__((interrupt)) states that interrupts should
not use SSE/MPX/ MMX/x87 as GCC does not preserve the register content in
handlers. https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html

Is there any way to relax this restriction and make GCC aware of SSE/.. usage
and preserve the state correctly? While I think that interrupt handlers should
be as fast as possible there are cases when it is OK to call functions compiled
with SSE support. GCC should handle such situations and preserve SSE/..
registers.

Clang handles this situation. Here is a compiler output for a handler with a
function call that uses SSE:


__attribute__((interrupt)) void handle_breakpoint(struct interrupt_frame
*frame) {
printf("Hello from breakpoint handler\n");
}


GCC 7:


001021b0 :
  1021b0:   41 53   push   %r11
  1021b2:   41 52   push   %r10
  1021b4:   41 51   push   %r9
  1021b6:   41 50   push   %r8
  1021b8:   57  push   %rdi
  1021b9:   56  push   %rsi
  1021ba:   bf 40 33 10 00  mov$0x103340,%edi
  1021bf:   51  push   %rcx
  1021c0:   52  push   %rdx
  1021c1:   50  push   %rax
  1021c2:   31 c0   xor%eax,%eax
  1021c4:   fc  cld
  1021c5:   e8 c6 de ff ff  callq  100090 
  1021ca:   58  pop%rax
  1021cb:   5a  pop%rdx
  1021cc:   59  pop%rcx
  1021cd:   5e  pop%rsi
  1021ce:   5f  pop%rdi
  1021cf:   41 58   pop%r8
  1021d1:   41 59   pop%r9
  1021d3:   41 5a   pop%r10
  1021d5:   41 5b   pop%r11
  1021d7:   48 cf   iretq  
  1021d9:   0f 1f 80 00 00 00 00nopl   0x0(%rax)


Clang 4:

00100260 :
  100260:   50  push   %rax
  100261:   41 53   push   %r11
  100263:   41 52   push   %r10
  100265:   41 51   push   %r9
  100267:   41 50   push   %r8
  100269:   57  push   %rdi
  10026a:   56  push   %rsi
  10026b:   52  push   %rdx
  10026c:   51  push   %rcx
  10026d:   48 81 ec 00 01 00 00sub$0x100,%rsp
  100274:   44 0f 29 bc 24 f0 00movaps %xmm15,0xf0(%rsp)
  10027b:   00 00 
  10027d:   44 0f 29 b4 24 e0 00movaps %xmm14,0xe0(%rsp)
  100284:   00 00 
  100286:   44 0f 29 ac 24 d0 00movaps %xmm13,0xd0(%rsp)
  10028d:   00 00 
  10028f:   44 0f 29 a4 24 c0 00movaps %xmm12,0xc0(%rsp)
  100296:   00 00 
  100298:   44 0f 29 9c 24 b0 00movaps %xmm11,0xb0(%rsp)
  10029f:   00 00 
  1002a1:   44 0f 29 94 24 a0 00movaps %xmm10,0xa0(%rsp)
  1002a8:   00 00 
  1002aa:   44 0f 29 8c 24 90 00movaps %xmm9,0x90(%rsp)
  1002b1:   00 00 
  1002b3:   44 0f 29 84 24 80 00movaps %xmm8,0x80(%rsp)
  1002ba:   00 00 
  1002bc:   0f 29 7c 24 70  movaps %xmm7,0x70(%rsp)
  1002c1:   0f 29 74 24 60  movaps %xmm6,0x60(%rsp)
  1002c6:   0f 29 6c 24 50  movaps %xmm5,0x50(%rsp)
  1002cb:   0f 29 64 24 40  movaps %xmm4,0x40(%rsp)
  1002d0:   0f 29 5c 24 30  movaps %xmm3,0x30(%rsp)
  1002d5:   0f 29 54 24 20  movaps %xmm2,0x20(%rsp)
  1002da:   0f 29 4c 24 10  movaps %xmm1,0x10(%rsp)
  1002df:   0f 29 04 24 movaps %xmm0,(%rsp)
  1002e3:   fc  cld
  1002e4:   bf 4f 3c 10 00  mov$0x103c4f,%edi
  1002e9:   31 c0   xor%eax,%eax
  1002eb:   e8 f0 28 00 00  callq  102be0 
  1002f0:   0f 28 04 24 movaps (%rsp),%xmm0
  1002f4:   0f 28 4c 24 10  movaps 0x10(%rsp),%xmm1
  1002f9:   0f 28 54 24 20  movaps 0x20(%rsp),%xmm2
  1002fe:   0f 28 5c 24 30  movaps 0x30(%rsp),%xmm3
  100303:   0f 28 64 24 40  movaps 0x40(%rsp),%xmm4
  100308:   0f 28 6c 24 50  movaps 0x50(%rsp),%xmm5
  10030d:   0f 28 74 24 60  movaps 0x60(%rsp),%xmm6
  100312:   0f 28 7c 24 70  movaps 

[Bug fortran/81707] Type parameter inquiry errors

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
Not implemented yet. In fact I did not even know about it. This will take some
front end parsing, etc etc

[Bug preprocessor/53404] warning column reported on comment in warning during bootstrap

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #2)
> I don't see this any longer.

I think I might've seen this before, but I'll have to double-check the next
time I bootstrap to make sure

[Bug target/63545] ICE when building GCC for ia64-hp-hpux11.23 in hash_table<cselib_hasher,xcallocator>::find_slot_with_hash

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
  Component|bootstrap   |target
Summary|ICE building GCC|ICE when building GCC for
   |hash_table::find_slot_with_ |hash_table::find_slot_with_
   ||hash

--- Comment #6 from Eric Gallager  ---
(In reply to Bill Klees from comment #4)
> Much simpler test case
> --
> struct DWstruct { int high, low; };
> 
> typedef union
> {
> struct DWstruct s;
> int ll;
> } DWunion;
> 
> int
> __multi3(int u, int v)
> {
> const DWunion uu = { .ll = u };
> return 0;
> }
> 
> 
> Build Line:
> ---
> /u/scratch/users/b/gcc/hp/gcc491_debug/./gcc/xgcc
> -B/u/scratch/users/b/gcc/hp/gcc491_debug/./gcc/
> -B/shares/source/itlinks/opt/hpux_ia64/11.2/32/gcc-4.9.1/ia64-hp-hpux11.23/
> bin/ -mlp64 -g -O2 -o _muldi3.o -c test2.c
> 

This compiles fine for me on i386-apple-darwin9.8.0, so I'm assuming it must
come down to target differences. Changing component from bootstrap to target.

[Bug fortran/44882] Bogus types in references with mismatched commons

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||accepts-invalid, wrong-code
 CC||egallager at gcc dot gnu.org

--- Comment #17 from Eric Gallager  ---
(In reply to rguent...@suse.de from comment #15)
> On Fri, 19 Sep 2014, dominiq at lps dot ens.fr wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882
> > 
> > Dominique d'Humieres  changed:
> > 
> >What|Removed |Added
> > 
> >  Status|NEW |WAITING
> > 
> > --- Comment #14 from Dominique d'Humieres  ---
> > I dont see any ICE for the test in comment 12 on powerpc-apple-darwin9 (from
> > 4.4.7 to r214282). Any reason why this PR is still open?
> 
> See comment #5/6, the Fortran frontend still produces wrong-code or
> silently accepts invalid input.

Adding those as Keywords on this bug then

[Bug c/81665] Please introduce flags attribute for enums which will mimic one from C#

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirming as an enhancement. Pedro Alves also requested this feature on the
gcc-patches mailing list:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00726.html

[Bug libstdc++/57426] Application core dumps at __gnu_cxx::__exchange_and_add

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to RajaGopal from comment #5)
> 
> Do you need any output from the dbx? If yes please let me know.

Yes please, a fuller backtrace at the very least

[Bug c++/35758] vector_size attribute lost in function arguments for templates

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #24 from Eric Gallager  ---
(In reply to Martin Sebor from comment #23)
> The test case compiles successfully with 6.0 (albeit with warnings).  Since
> the originally reported problem was fixed in r134639 and since there are
> other bugs tracking problems with dependent arguments to attributes (bug
> 58109 and bug 69022), should this bug be RESOLVED as FIXED?
> 

I'd say so at least.

> If there is an outstanding problem that isn't tracked anywhere else, can we
> distill it into a small test case and open a separate bug for it?  (I'd be
> happy to do it but I'm not sure what the outstanding problem is that this
> bug still tracks.)
> 
> Setting Status to WAITING until a decision is made.

[Bug debug/68229] .debug_pubnames length field is too large

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

URL||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1278872
 Resolution|FIXED   |MOVED

[Bug demangler/81680] Memory leak in libiberty demangler

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> This bug might better be filed at sourceware.org/bugzilla

Except the demangler main sources are located in gcc rather than binutils.

[Bug debug/68229] .debug_pubnames length field is too large

[todd.allen at ccur dot com]

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

--- Comment #6 from Todd Allen  ---
They released a patch last year:

https://bugzilla.redhat.com/show_bug.cgi?id=1278872

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[urbanjost at comcast dot net]

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

--- Comment #31 from urbanjost at comcast dot net ---
It may be of interest that the original application where this was encountered
was changed to use modules, which I have had no similar problem with on Cygwin;
but that the bug1.sh attachment still fails using gfortran 5.4.0 on Cygwin
2.7.0. 

Over the intervening time we found that the EXTERNAL statement was required on
several other PEs (Programming Environments). So it seems the explicit EXTERNAL
statement was used as a flag to scan and use the libraries listed on the loads
or to insert some type of work-around.

I would suggest any QA of a solution also test using shared libraries where
supported, as another compiler did not have this issue with static libraries
but had what manifested as the same symptoms when using shared libraries (since
fixed). 

AThe Fortran standard gives some contrary indications (as I see it) on what

   external BLOCK_DATA_NAME

means. Section 12.4.3.5 implies to me that if a matching BLOCKDATA name
is not found at load time that an error should occur (which implies it
should be searched for in the files presented to the loader); and that is
what I have seen with other compilers/loaders.

 12.4.3.5 EXTERNAL statement

   1 An EXTERNAL statement specifies the EXTERNAL attribute (5.3.9) for a list
of names.

 R1210 external-stmtis   EXTERNAL [ :: ]
external-name-list

   2 The appearance of the name of a block data program unit in an EXTERNAL
statement confirms that the block
 data program unit is a part of the program.

But then a note in the standard gives the impression a plain BLOCK DATA
does not by itself imply much:

 C.8.1 Main program and block data program unit (11.1, 11.3)
   1 The name of the main program or of a block data program unit has no
explicit use within the Fortran language.
 It is available for documentation and for possible use by a processor.

To me, this explains why some compilers/loaders only work when there is
an explicit EXTERNAL statement (C.8.1 is only talking about the name in
the declaration of the BLOCK DATA; not in an EXTERNAL statement).

Some old CDC and old CRAY Fortran 77 documentation (not current CRAY
documents -- this was from around the time the XMP came out) explicitly
stated that to ensure a BLOCK DATA is loaded when the use and declaration
are not in the same file that the EXTERNAL statement was required;
but I couldn't find anything else that was that clear about the issue.
s regards the Fortran standard and why I think it does say this should work
(aside from the fact it appears to work everywhere else I tried) ...


I think I can summarize that by saying it is as clear as mud, but if it doesn't
mean that what else would "external BLOCK_DATA_NAME" mean?

[Bug target/81708] The x86 stack canary location should be customizable

[luto at kernel dot org]

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

--- Comment #2 from Andy Lutomirski  ---
(In reply to H. Peter Anvin from comment #1)
> Well, you can choose between "__stack_chk_guard(%rip)" and "%gs:40"... :)

Wow, I guess I didn't even consider the former.  That would be option 5:
symbol(%rip).  Let's not use it for the kernel.

For x86_32, we want %fs:symbol.  %fs:constant would be tolarable, too.  For
x86_64, it depends on the end game for percpu access, I suppose.

[Bug target/81708] The x86 stack canary location should be customizable

[hpa at zytor dot com]

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

H. Peter Anvin  changed:

   What|Removed |Added

 CC||hpa at zytor dot com

--- Comment #1 from H. Peter Anvin  ---
Well, you can choose between "__stack_chk_guard(%rip)" and "%gs:40"... :)

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

[hpa at zytor dot com]

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

--- Comment #22 from H. Peter Anvin  ---
There are other issues, too (we'd have to drop the kernel memory model,
probably replace it with the small-pic model) but %gs: addressing is one of
those.

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

[luto at kernel dot org]

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

--- Comment #21 from Andy Lutomirski  ---
Re: the stack canary, I filed bug 81708.  It seems to me that __seg_gs is
analogous and users should be able to directly specify the addressing mode.

[Bug target/81708] New: The x86 stack canary location should be customizable

[luto at kernel dot org]

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

Bug ID: 81708
   Summary: The x86 stack canary location should be customizable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luto at kernel dot org
  Target Milestone: ---

There are four credible ways to find the stack canary:

1. %fs:symbol
2. %fs:symbol(%rip) [with a PCREL relocation]
3. %gs:symbol
4. %gs:symbol(%rip)

(Obviously the %rip variants only work on x86_64.)

The current code is roughly equivalent to (1) or (3) where symbol is an
absolute symbol equal to 0x28 or similar.

Please give a command line option to choose any of the four modes and specify
the symbol name.  (Or just hardcode the symbol name to __gcc_stack_canary or
whatever if the option is set.)

My perferred solution would be -mstack-protector-cookie=gs:symname or
-mstack-protector-cookie=gs:symname(%rip) or -mstack-protector-cookie=gs:0x28
depending on what's desired.

I personally consider it to have been a mistake for Linux to support a stack
canary without insisting that GCC fix this issue first.  The x86_32 case, in
particular, is a collossal mess in the kernel that slows kernel entries down
and seriously overcomplicates the kernel code because the stack canary
addressing mode that GCC chooses is nonsensical.

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

[luto at kernel dot org]

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

--- Comment #20 from Andy Lutomirski  ---
We have issues putting modules more than 2G from the main kernel no matter
what, but I don't see what this has to do with %gs addressing.

I still think that GCC should let us directly control the addressing mode for
__seg accesses.

Can someone elaborate on what the @GPREL suffix actually means?

[Bug debug/68229] .debug_pubnames length field is too large

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Eric Gallager  ---
(In reply to Todd Allen from comment #4)
> It appears to have been fixed in gcc-4.9.0 by Sterling Augustine,
> 2013-07-25, with the new include_pubname_in_output function.  I don't have a
> 4.9.0 compiler, but I did test it with gcc-4.9.2 on Fedora 21, and that
> worked.  I'll take up the issue with RedHat, since it's RHEL 7.0 that
> provides gcc-4.8.x still.

OK, closing as FIXED, but if you have a link to the issue you opened with
RedHat, it could be closed as MOVED instead.

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

[hpa at zytor dot com]

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

--- Comment #19 from H. Peter Anvin  ---
So the Linux kernel, right now, basically does (b); we'd like to do something
more like (a).

Because the stack canary (which is a percpu variable in the Linux kernel) is
hard-coded in gcc to be %gs:0x28, models (c) and (d) are not available to us. 
Even if they were, it would have issues with moving modules further than 2G
from the main kernel.

We don't need the special relocations since we can see which references point
into the appropriate section during our post-link processing, but someone else
may have use for them.

[Bug target/68094] Compiler segmentation fault

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target||avr
 CC||egallager at gcc dot gnu.org
  Component|c++ |target

--- Comment #4 from Eric Gallager  ---
(In reply to Matha Goram from comment #2)
> Created attachment 36600 [details]
> Pre-processed source file
> 
> Per request to attach pre-processed source file

Are you sure that's the file where GCC crashes? The error message in the
screenshot looks more like it'd be this:
http://svn.savannah.gnu.org/viewvc/avr-libc/trunk/avr-libc/libc/stdlib/malloc.c?view=markup

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

[hjl.tools at gmail dot com]

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

--- Comment #18 from H.J. Lu  ---
(In reply to H.J. Lu from comment #17)
> Created attachment 41920 [details]
> A binutils patch
> 

With this patch:

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 587dbe61e8b..953c153a834 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -19429,8 +19429,10 @@ ix86_print_operand_address_as (FILE *file, rtx addr,
   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;

@@ -19465,6 +19467,8 @@ ix86_print_operand_address_as (FILE *file, rtx addr,
output_pic_addr_const (file, disp, 0);
   else
output_addr_const (file, disp);
+  if (!ADDR_SPACE_GENERIC_P (as))
+   fputs ("@GPREL", file);
 }
   else
 {


I got

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

int
xxx (void)
{
  return foo;
}
[hjl@gnu-6 gprel-1]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -B./ -fPIE -O2 xx.c -S
[hjl@gnu-6 gprel-1]$ cat xx.s
.file   "xx.c"
.text
.p2align 4,,15
.globl  xxx
.type   xxx, @function
xxx:
.LFB0:
.cfi_startproc
movl%gs:foo@GPREL, %eax
ret
.cfi_endproc
.LFE0:
.size   xxx, .-xxx
.ident  "GCC: (GNU) 8.0.0 20170801 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 gprel-1]$ ./as -o xx.o xx.s
[hjl@gnu-6 gprel-1]$ ./objdump -dwr xx.o

xx.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   65 8b 04 25 00 00 00 00 mov%gs:0x0,%eax 4:
R_X86_64_GPREL   foo
   8:   c3  retq   
[hjl@gnu-6 gprel-1]$

[Bug fortran/50360] [cleanup] use an ENUM for the return values of gfc_dep_compare_expr

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|WONTFIX |---
   Severity|normal  |enhancement

--- Comment #3 from Thomas Koenig  ---
Still makes sense to do.

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

[hjl.tools at gmail dot com]

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

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

This binutils patch adds R_X86_64_GPREL to assembler and linker.  It
supports:

.text
.globl get_foo
get_foo:
movl%gs:foo@GPREL, %eax // GS + offset of foo relative to __gp.
ret

.data
.globl foo_gprel
foo_gprel:
.long foo@GPREL // offset of foo relative to __gp.

.section .gpdata,"aw",@progbits
.globl foo
foo:
.long 0x12345678

[Bug fortran/81707] New: Type parameter inquiry errors

[mexas at bristol dot ac.uk]

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

Bug ID: 81707
   Summary: Type parameter inquiry errors
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mexas at bristol dot ac.uk
  Target Milestone: ---

$ cat z.f90 
character( len=: ), allocatable :: a
allocate( character(len=128) :: a )
write (*,*) len(a), a%len, a%kind
end

$ gfortran8 -c z.f90
z.f90:3:22:

 write (*,*) len(a), a%len, a%kind
  1
Error: Unexpected '%' for nonderived-type variable 'a' at (1)

Same with versions 7,6 and 5.

Is this simply not supported yet?
It seems there has been no progress on
this related 2009 PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40196

[Bug tree-optimization/81538] Optimization problem compiling op.c (Perl_custom_op_get_field) in perl 5.26

[danglin at gcc dot gnu.org]

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

--- Comment #10 from John David Anglin  ---
Created attachment 41919
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41919=edit
Somewhat reduced preprocessed source

[Bug c++/81706] New: std::sin vectorization bug

[diegoandres91b at hotmail dot com]

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

Bug ID: 81706
   Summary: std::sin vectorization bug
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: diegoandres91b at hotmail dot com
  Target Milestone: ---

The next code (with -O3 -ffast-math):

#include 

float a[4];

void sin1() {
for(unsigned i = 0; i < 4; i++) a[i] = sinf(a[i]);
}

Compiles vectorized version of sinf (_ZGVbN4v_sinf):

sin1():
sub rsp, 8
movaps  xmm0, XMMWORD PTR a[rip]
call_ZGVbN4v_sinf
movaps  XMMWORD PTR a[rip], xmm0
add rsp, 8
ret

But when i use c++ version of sinf (std::sin) no vectorization occurrs:

void sin2() {
for(unsigned i = 0; i < 4; i++) a[i] = std::sin(a[i]);
}

sin2():
sub rsp, 8
movss   xmm0, DWORD PTR a[rip]
callsinf
movss   DWORD PTR a[rip], xmm0
movss   xmm0, DWORD PTR a[rip+4]
callsinf
movss   DWORD PTR a[rip+4], xmm0
movss   xmm0, DWORD PTR a[rip+8]
callsinf
movss   DWORD PTR a[rip+8], xmm0
movss   xmm0, DWORD PTR a[rip+12]
callsinf
movss   DWORD PTR a[rip+12], xmm0
add rsp, 8
ret

Compiler Explorer Code: https://godbolt.org/g/zSrJrK

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

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #16 from Bill Schmidt  ---
Not all revisions exist in all branches.

Check out the code from http://gcc.gnu.org/svn/gcc/branches/gcc-7-branch to see
if the problem exists there.  From what I can see from this discussion it will
not.

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

[dcb314 at hotmail dot com]

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

--- Comment #15 from David Binderman  ---
>This is a 8 only regression. It has nothing to do with 7.2.

Curiouser and curiouser.

Richard Biener has just posted that 7.2-rc1 has been created from
revision 250819.

The small chunk of code I posted AFAIK goes wrong with revisions
250718, 250725, 250757, 250813, 250841.

I am no expert in svn, but if 250813 and 250841 demonstrate the
fault, then AFAIK something derived from 250819 should also
show the fault.

Unless you know different.

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

[babokin at gmail dot com]

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

Bug ID: 81705
   Summary: UBSAN: yet another false positive
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250857, x86_64.

After recent fix for #81148, this case is the last one failing UBSAN false
positive that I see on my radars.

> cat f.cpp
int var_4 = -1716607962;
int var_14 = 943738830;
volatile int a;
int main() {
//  (-(-1716607962) - 516151698) - -(9403738830)
  a = (-var_4 - 516151698) - -var_14;
  return 0;
}

> g++ -fsanitize=undefined f.cpp -o out; ./out
f.cpp:6:28: runtime error: signed integer overflow: -943738830 + -1716607962
cannot be represented in type 'int'
f.cpp:6:28: runtime error: signed integer overflow: -516151698 - 1634620504
cannot be represented in type 'int'

[Bug libfortran/48958] Add runtime diagnostics for SIZE intrinsic function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED
 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #3)
> This PR is related to pr46182. While I agree that it would be nice to have
> run time errors for invalid use of unallocated variables/not associated
> pointers, I doubt it will ever happen.

That sounds more like a case for the SUSPENDED status than WAITING

[Bug fortran/50360] [cleanup] use an ENUM for the return values of gfc_dep_compare_expr

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #1)
> Any opinion about keeping this four-year old PR opened?

My opinion is to close it, given that it's been in WAITING for so long with no
response.

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

[msebor at gcc dot gnu.org]

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

Bug ID: 81704
   Summary: strncpy folding defeats strlen optimization
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similar to bug 81703, when a call to strncpy() copies an initial sequence from
a string of known length without NUL-terminating the result, the
gimple_fold_builtin_strncpy function transforms the call into a direct memory
access.  When the copy is immediately followed by setting the last element of
the destination to NUL the transformation then prevents a subsequent strlen
optimization that could otherwise take place (bug 81433 tracks the strncpy
optimization that's missing from tree-ssa-strlen).  As a result, examples like
the one in the test case below are not optimized into optimal code.

As in bug 81703, I think the way to solve this is to defer the folding until
after the tree-ssa-strlen pass has run, similarly to how bug 77671 has been
handled.

$ cat a.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout a.c
tree-optimized=/dev/stdout a.c
unsigned f (void)
{
  char d[8];
  __builtin_strcpy (d, "0123456");
  return __builtin_strlen (d);
}

unsigned g (void)
{
  char d[8];
  __builtin_strncpy (d, "01234567", sizeof d);
  d[sizeof d - 1] = '\0';
  return __builtin_strlen (d);
}

;; Function f (f, funcdef_no=0, decl_uid=1815, cgraph_uid=0, symbol_order=0)

f ()
{
   [100.00%] [count: INV]:
  return 7;

}



;; Function g (g, funcdef_no=1, decl_uid=1819, cgraph_uid=1, symbol_order=1)

g ()
{
  char d[8];
  long unsigned int _1;
  unsigned int _5;

   [100.00%] [count: INV]:
  MEM[(char * {ref-all})] = MEM[(char * {ref-all})"01234567"];
  d[7] = 0;
  _1 = __builtin_strlen ();
  _5 = (unsigned int) _1;
  d ={v} {CLOBBER};
  return _5;

}

[Bug middle-end/77799] missing -Wformat-overflow warning on a trivial sprintf overflow with no directives

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
This bug was fixed along with the related pr77671 in r248035.  GCC 8.0 now
prints the following:

.c: In function ‘g’:
a.c:14:15: warning: too many arguments for format [-Wformat-extra-args]
   sprintf (d, "123", 0);
   ^
a.c: In function ‘f’:
a.c:9:18: warning: ‘123’ directive writing 3 bytes into a region of size 2
[-Wformat-overflow=]
   sprintf (d, "123");
~~^
a.c:9:3: note: ‘sprintf’ output 4 bytes into a destination of size 2
   sprintf (d, "123");
   ^~

;; Function f (f, funcdef_no=0, decl_uid=1819, cgraph_uid=0, symbol_order=1)

f ()
{
   [100.00%] [count: INV]:
  sprintf (, "123"); [tail call]
  return;

}


a.c: In function ‘g’:
a.c:14:18: warning: ‘123’ directive writing 3 bytes into a region of size 2
[-Wformat-overflow=]
   sprintf (d, "123", 0);
~~^
a.c:14:3: note: ‘sprintf’ output 4 bytes into a destination of size 2
   sprintf (d, "123", 0);
   ^

;; Function g (g, funcdef_no=1, decl_uid=1822, cgraph_uid=1, symbol_order=2)

g ()
{
   [100.00%] [count: INV]:
  sprintf (, "123", 0); [tail call]
  return;

}

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

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Should be fixed on trunk.

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

[msebor at gcc dot gnu.org]

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

Bug ID: 81703
   Summary: memcpy folding defeats strlen optimization
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When a call to memcpy() copies a string of known length the
gimple_fold_builtin_memcpy function transforms the call to a direct memory
access.  This transformation then prevents a subsequent strlen optimization
that would otherwise readily take place.  As a result, even simple examples
like the one in the test case below are not optimized into optimal code.  (In
addition, the folding fails to consider the size of the destination and allows
buffer overflow to go unnoticed -- this is the subject of bug 79220).

I think this could be dealt in one of at least two ways: a) by enhancing the
tree-ssa-strlen pass to recognize direct memory references (this alone won't
help with bug 79220), or b) by deferring the folding until after the
tree-ssa-strlen pass has had a chance to perform its sophisticate analysis and
transformations.  Between the two alternatives, I would expect b) to be the
simpler solution and yield better results (it could also better handle bug
79220).

$ cat a.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout a.c
unsigned f (void)
{
  char d[8];
  const char s[] = "0123";
  __builtin_strcpy (d, s);
  return __builtin_strlen (d);
}

unsigned g (void)   // can be optimized the same as f()
{
  char d[8];
  const char s[] = "0123";
  __builtin_memcpy (d, s, sizeof s);
  return __builtin_strlen (d);
}

;; Function f (f, funcdef_no=0, decl_uid=1815, cgraph_uid=0, symbol_order=0)

f ()
{
   [100.00%] [count: INV]:
  return 4;

}



;; Function g (g, funcdef_no=1, decl_uid=1820, cgraph_uid=1, symbol_order=1)

g ()
{
  const char s[5];
  char d[8];
  long unsigned int _1;
  unsigned int _5;

   [100.00%] [count: INV]:
  s = "0123";
  MEM[(char * {ref-all})] = MEM[(char * {ref-all})];
  _1 = __builtin_strlen ();
  _5 = (unsigned int) _1;
  d ={v} {CLOBBER};
  s ={v} {CLOBBER};
  return _5;

}

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

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Aug  3 18:09:12 2017
New Revision: 250858

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

Fixes golang/go#21147
Fixes GCC PR 81617

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

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/mksigtab.sh

[Bug c++/81702] New: ICE in gimple_get_virt_method_for_vtable

[adam at os dot inf.tu-dresden.de]

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

Bug ID: 81702
   Summary: ICE in gimple_get_virt_method_for_vtable
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam at os dot inf.tu-dresden.de
  Target Milestone: ---

Created attachment 41918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41918=edit
Code triggering the ICE

With the following reduced code I'm getting an ICE in gcc-7 and gcc-8. Only
happens with -O2.

$ g++
g++ (GCC) 7.1.1 20170803

$ g++ -c -O2 -std=gnu++11 t.i
t.i:107:33: internal compiler error: in gimple_get_virt_method_for_vtable, at
gimple-fold.c:6442
 Resource_factory_t<Foo3, Foo> _x;
 ^
0x8c4684 gimple_get_virt_method_for_vtable(long, tree_node*, unsigned long,
bool*)
../../gcc/gcc/gimple-fold.c:6442
0x111c8c4 ipa_get_indirect_edge_target_1
../../gcc/gcc/ipa-cp.c:2411
0x93b054 estimate_edge_devirt_benefit
../../gcc/gcc/ipa-inline-analysis.c:3141
0x93b3cb estimate_edge_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:3182
0x93b3cb estimate_calls_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:3254
0x93b688 estimate_node_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:3352
0x93ce03 do_estimate_edge_size(cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3910
0x93d07f estimate_edge_size
../../gcc/gcc/ipa-inline.h:297
0x93d07f estimate_edge_growth
../../gcc/gcc/ipa-inline.h:308
0x93d07f do_estimate_growth_1
../../gcc/gcc/ipa-inline-analysis.c:4030
0x93d0c5 cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
../../gcc/gcc/cgraph.h:3150
0x93d0c5 estimate_growth(cgraph_node*)
../../gcc/gcc/ipa-inline-analysis.c:4044
0x11359e9 inline_small_functions
../../gcc/gcc/ipa-inline.c:1764
0x11359e9 ipa_inline
../../gcc/gcc/ipa-inline.c:2434
0x11359e9 execute
../../gcc/gcc/ipa-inline.c:2845
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.

Adding code as attachment as reducing it more shows to be tricky.

[Bug rtl-optimization/30065] Could use indexed addressing to reduce const costs

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Oleg Endo from comment #5)
> (In reply to Eric Gallager from comment #4)
> > (In reply to Steven Bosscher from comment #3)
> > > Is there a test case for this PR?
> > 
> > Reporter never provided a test case; closing
> 
> Please do not close any SH related PR's just for the sake of reducing the
> number of PR's.  I keep them open because they are actual issues.

Can I change the status to SUSPENDED or assign them to you instead? I'm not so
much trying to reduce the number of open PRs as I am trying to just move them
out of the WAITING queue. https://gcc.gnu.org/bugs/management.html says bugs
are only ever supposed to stay in the WAITING state for 3 months, after all.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
I hope this is what you had in mind:

--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -14106,14 +14106,17 @@ fold_indirect_ref_1 (location_t loc, tree type, tree
op0)
   && type == TREE_TYPE (op00type))
{
  tree type_domain = TYPE_DOMAIN (op00type);
- tree min_val = size_zero_node;
- if (type_domain && TYPE_MIN_VALUE (type_domain))
-   min_val = TYPE_MIN_VALUE (type_domain);
- op01 = size_binop_loc (loc, EXACT_DIV_EXPR, op01,
-TYPE_SIZE_UNIT (type));
- op01 = size_binop_loc (loc, PLUS_EXPR, op01, min_val);
- return build4_loc (loc, ARRAY_REF, type, op00, op01,
-NULL_TREE, NULL_TREE);
+ tree min = TYPE_MIN_VALUE (type_domain);
+ if (min && TREE_CODE (min) == INTEGER_CST)
+   {
+ offset_int off = wi::to_offset (op01);
+ offset_int el_sz = wi::to_offset (TYPE_SIZE_UNIT (type));
+ off = wi::sdiv_trunc (off, el_sz);
+ off = off + wi::to_offset (min);
+ op01 = wide_int_to_tree (type, off);
+ return build4_loc (loc, ARRAY_REF, type, op00, op01,
+NULL_TREE, NULL_TREE);
+   }
}
}
 }

[Bug libstdc++/29366] atomics config for sh is weird

[olegendo at gcc dot gnu.org]

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

--- Comment #10 from Oleg Endo  ---
(In reply to Eric Gallager from comment #9)
> 
> Did this fix things?

No, not entirely.  The whole config/cpu/sh/atomicity.h header should not be
required, but because of PR 53579, it is.

Please do not close any SH related PR's just for the sake of reducing the
number of PR's.  I keep them open because they are actual issues.

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[olegendo at gcc dot gnu.org]

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

Bug 30065 Summary: Could use indexed addressing to reduce const costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

[Bug rtl-optimization/30065] Could use indexed addressing to reduce const costs

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #5 from Oleg Endo  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Steven Bosscher from comment #3)
> > Is there a test case for this PR?
> 
> Reporter never provided a test case; closing

Please do not close any SH related PR's just for the sake of reducing the
number of PR's.  I keep them open because they are actual issues.

[Bug fortran/52673] implement -fheap-arrays in gfortran

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
On architectures where we have low stack and need recursive
(for example for OpenMP), we should have the possibility
of having -fheap-arrays instead of putting them all
on the stack.

So, moving to NEW.

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

[tkoenig at gcc dot gnu.org]

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

Bug ID: 81701
   Summary: -fstack-arrays hehavior does not match documentation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

The docs say

 Adding this option will make the Fortran compiler put all local
 arrays, even those of unknown size onto stack memory.

This is not what happens at the moment.  Look at

module x
contains
  subroutine a(n,r)
real, dimension(1) :: arr
real :: r
call random_number(arr)
r = sum(arr)
  end subroutine a
end module x

which, when translated, gets us

a (integer(kind=4) & restrict n, real(kind=4) & restrict r)
{
  static real(kind=4) arr[1];

  {
struct array1_real(kind=4) parm.0;

...

We should change the documented or the actual behavior, or both :)

[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Dominique d'Humieres from comment #9)
> (lldb) b main
> Breakpoint 2: where = a.out`main at pr25967-1.c:55, address =
> 0x00010f4f
> (lldb) disass -a 0x00010f4f
> a.out`main:
> 0x10f4f <+0>:  pushq  $0x12345675   ; imm = 0x12345675 
> 0x10f54 <+5>:  pushq  $0x12345674   ; imm = 0x12345674 
> 0x10f59 <+10>: pushq  $0x12345673   ; imm = 0x12345673 
> 0x10f5e <+15>: pushq  $0x12345672   ; imm = 0x12345672 
> 0x10f63 <+20>: pushq  $0x12345671   ; imm = 0x12345671 
> 0x10f68 <+25>: pushq  $0x12345670   ; imm = 0x12345670 
> 0x10f6d <+30>: jmp0x10ee8   ; fn at
> pr25967-1.c:34
> 0x10f72 <+35>: movl   $0x0, %eax
> 0x10f77 <+40>: retq

Where is

and$0xfff0,%rsp

my patch added?

[Bug c++/81700] New: Unresolved function type when taking address of operator() of generic lambda

[gufideg at gmail dot com]

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

Bug ID: 81700
   Summary: Unresolved function type when taking address of
operator() of generic lambda
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gufideg at gmail dot com
  Target Milestone: ---

Hi, have found this corner case when taking the address of operator() of a
generic lambda. This error only happen when using decltype with a function
defined as follow:

// Take a type, return that same type
template
T identity(T);

int main()
{
auto f = [](auto test) {};

using F = decltype(f);

// Error! Unresolved function type?
(void)decltype(identity(::operator())){};
}

However, taking the address of the lambda beforehand make GCC accept the code:

// Take a type, return that same type
template
T identity(T);

int main()
{
auto f = [](auto test) {};

using F = decltype(f);

// We simply add this line
(void)decltype(::operator()){};

// Compiles!
(void)decltype(identity(::operator())){};
}

Here's a live example: http://coliru.stacked-crooked.com/a/b7909605e2f882c9

Note that this bug don't happen with non-generic lambdas.

[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
(lldb) b main
Breakpoint 2: where = a.out`main at pr25967-1.c:55, address =
0x00010f4f
(lldb) disass -a 0x00010f4f
a.out`main:
0x10f4f <+0>:  pushq  $0x12345675   ; imm = 0x12345675 
0x10f54 <+5>:  pushq  $0x12345674   ; imm = 0x12345674 
0x10f59 <+10>: pushq  $0x12345673   ; imm = 0x12345673 
0x10f5e <+15>: pushq  $0x12345672   ; imm = 0x12345672 
0x10f63 <+20>: pushq  $0x12345671   ; imm = 0x12345671 
0x10f68 <+25>: pushq  $0x12345670   ; imm = 0x12345670 
0x10f6d <+30>: jmp0x10ee8   ; fn at pr25967-1.c:34
0x10f72 <+35>: movl   $0x0, %eax
0x10f77 <+40>: retq

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

[rguenther at suse dot de]

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

--- Comment #1 from rguenther at suse dot de  ---
On August 3, 2017 5:05:36 PM GMT+02:00, "seurer at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81699
>
>seurer at gcc dot gnu.org changed:
>
>   What|Removed |Added
>
>   CC||rguenther at suse dot de

See my mail, it's fixed already.

[Bug fortran/47495] .mod files: File modification time - Makefile build issue

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #14 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #13)
> Is this still of interest?

Guess not.

[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #2)
> Is the problem fixed? Without feedback I'll assume yes.

No feedback so we can assume yes.

[Bug tree-optimization/61203] [5/6/7/8 Regression] g++.old-deja/g++.jason/rvalue2.C FAILs with -O2 -fno-inline

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #12 from Eric Gallager  ---
(In reply to Zdenek Sojka from comment #10)
> (In reply to Zdenek Sojka from comment #9)
> > (In reply to Andrew Pinski from comment #8)
> > > This does not fail on the trunk or 5.3 on aarch64-linux-gnu.
> > 
> > It is failing for me on 4.7 and newer for all tested targets, that is:
> > 
> 
> Ah yes, sorry, the original testcase is still failing, but the reduced
> testcase does not fail for 5 and trunk.

Both the original and the reduced testcase run successfully for me with trunk;
assuming this was fixed

[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
(In reply to Dominique d'Humieres from comment #7)
> > Created attachment 41917 [details]
> > A patch
> >
> > Please try this.
> 
> Sorry it does not work:
> 

Please compile gcc.dg/torture/pr25967-1.c with -g and run
it under debugger:

(gdb) r
Starting program: /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/a.out 
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.25-7.0.fc26.x86_64

Breakpoint 3, fn ()
at
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/torture/pr25967-1.c:43
43asm volatile ("lea " WORD_SIZE "(%%" STACK_POINTER "), %0\n\t"
(gdb) p/x $rsp
$1 = 0x7fffd570
 (gdb) disass main
Dump of assembler code for function main:
   0x00400450 <+0>: and$0xfff0,%rsp
   0x00400454 <+4>: pushq  $0x12345675
   0x00400459 <+9>: pushq  $0x12345674
   0x0040045e <+14>:pushq  $0x12345673
   0x00400463 <+19>:pushq  $0x12345672
   0x00400468 <+24>:pushq  $0x12345671
   0x0040046d <+29>:pushq  $0x12345670
   0x00400472 <+34>:jmpq   0x400557 
   0x00400477 <+39>:xor%eax,%eax
   0x00400479 <+41>:retq   
End of assembler dump.
(gdb) c
Continuing.

Breakpoint 1, 0x7ffe9b3ab1e0 in exit () from /lib64/libc.so.6
(gdb) p/x $rsp
$2 = 0x7fffd568
(gdb) 

Please find out why your stack isn't aligned to 16 bytes when exit is
called.

[Bug rtl-optimization/30065] Could use indexed addressing to reduce const costs

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #4 from Eric Gallager  ---
(In reply to Steven Bosscher from comment #3)
> Is there a test case for this PR?

Reporter never provided a test case; closing

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[egallager at gcc dot gnu.org]

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

Bug 30065 Summary: Could use indexed addressing to reduce const costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #30 from Eric Gallager  ---
(In reply to Jerry DeLisle from comment #29)
> I happened to just get Cygwin installed and running on my Windows box.  Let
> me run some tests and see if I can understand this.

Did you ever do this?

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

[seurer at gcc dot gnu.org]

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

Bug ID: 81699
   Summary: [8 regression] gcc.dg/tree-ssa/reassoc-23.c fails
starting with r250853
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I saw this on both powerpc64 LE and BE power8 systems.

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-ssa/reassoc-23.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-tree-reassoc1
-S -o reassoc-23.s
PASS: gcc.dg/tree-ssa/reassoc-23.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/reassoc-23.c scan-tree-dump-times reassoc1 "= 20" 1
testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp
completed in 1 seconds

=== gcc Summary ===

# of expected passes1
# of unexpected failures1


>From comparing the dumps before and after I think everything is OK but the test
case needs to be adjusted:


seurer@makalu-lp1:~/gcc/build/gcc-test2$ diff
reassoc-23.c.123t.reassoc1.r250852 reassoc-23.c.123t.reassoc1.r250853
13,17d12
<   unsigned int j;
<   unsigned int i;
<   unsigned int _2;
<   unsigned int _10;
< 
19,22c14
<   _2 = -c_5(D);
<   _10 = -a_4(D);
<   e_8 = 20;
<   return e_8;
---
>   return 20;

[Bug c++/67209] G++ generates incorrect code for boost::filesystem

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #1)
> There isn't nearly enough information here to know what's happening, please
> see https://gcc.gnu.org/bugs/ and provide the requested information.
> 
> There are ABI changes in GCC 5's standard library, have you rebuilt
> libboost_filesystem.so with GCC 5, or disabled the new ABI in GCC 5?
> 
> Try compiling your code with the -Wabi-tag warning to see if there are any
> potential ABI incompatibilities.

Reporter never provided the requested information; closing.

[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> Created attachment 41917 [details]
> A patch
>
> Please try this.

Sorry it does not work:

=== gcc Summary for unix/-m64 ===

# of unexpected failures14
# of unresolved testcases   14

=== gcc Summary ===

# of unexpected failures28
# of unresolved testcases   28

[Bug libgomp/81698] expand_omp_sections generates unusual switch

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
That seems like expand_case bug to me.  We don't rely on order of edges for say
GIMPLE_COND either, but determine which one is which by EDGE_FALSE_VALUE vs.
EDGE_TRUE_VALUE.  For GIMPLE_SWITCH, I think it should just determine the
label, from that find which bb it is in and find the corresponding edge.

[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
Created attachment 41917
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41917=edit
A patch

Please try this.

[Bug target/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #12 from Eric Gallager  ---
(In reply to Mark H Weaver from comment #11)
> FYI, there's now a suggested fix for bug #66917.  It would be interesting to
> know whether it fixes the problem reported here.

The suggested fix was applied and that bug has now been closed. Assuming that
this one has been fixed, too.

[Bug target/81621] ICE in delete_insn, at cfgrtl.c:167 with s390x cross compiler

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Aug  3 14:41:08 2017
New Revision: 250857

URL: https://gcc.gnu.org/viewcvs?rev=250857=gcc=rev
Log:
PR target/81621
* bb-reorder.c (pass_partition_blocks::execute): Return TODO_df_finish
after setting changeable df flags.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr81621.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/bb-reorder.c
trunk/gcc/testsuite/ChangeLog

[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
Just guessing, but maybe _exit doesn't like misaligned stack on MacOS. We may
need to emit some dummy pushes to keep it aligned.

[Bug lto/81686] LTO hardcodes identity host to target charset mapping

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
The hook is specified to take an input that's in the basic source 
character set ($ is also used with it).  Maybe LTO should store the 
complete mapping for basic source characters in the object file in the 
case where it's not the identity mapping (and give an error if linking 
objects using different mappings).

[Bug libgomp/81698] New: expand_omp_sections generates unusual switch

[vries at gcc dot gnu.org]

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

Bug ID: 81698
   Summary: expand_omp_sections generates unusual switch
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

I.

A switch has the default label as its first label:
...
  switch (cD.2303)  [INV] [count: INV], 
case 1:  [INV] [count: INV], 
case 2:  [INV] [count: INV]>
...

And because build_cfg makes edges iterating over the switch labels, the default
edge will have index '0'.

In expand_case, we seem to be relying on this (it seems fragile to me though):
...
  edge default_edge = EDGE_SUCC (bb, 0);
...


II.

The switch resulting from expand_omp_sections does not have the default edge as
first edge (in fact, it's the last):
...
  switch (.section.0D.1925)  [INV] [count: INV],
case 0:  [INV] [count: INV], 
case 1:  [INV] [count: INV], 
case 2:  [INV] [count: INV], 
case 3:  [INV] [count: INV], 
case 4:  [INV] [count: INV],
case 5:  [INV] [count: INV]>
;;succ:   8
;;7
;;6
;;5
;;4
;;11
;;9

;;   basic block 8, loop depth 1, freq 0, maybe hot
;;prev block 7, next block 9, flags: (NEW, REACHABLE)
;;pred:   3
:
  # USE = anything
  # CLB = anything
  barD.1917 (5);
  goto ; [INV] [count: INV]
;;succ:   10 (FALLTHRU)


;;   basic block 9, loop depth 0, freq 0, maybe hot
;;prev block 8, next block 10, flags: (NEW)
;;pred:   3
:
  # USE = anything
  # CLB = anything
  __builtin_trapD.1087 ();
;;succ:
...


III.

So we need either to:
- fix expand_omp_sections to emit a normal-form switch, or
- stop relying on the first edge being the default edge.

[Bug tree-optimization/81679] use attribute unused on function arguments as an optimization hint

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Wed, 2 Aug 2017, msebor at gcc dot gnu.org wrote:

> If there is a concern that the attribute could be used on declarations in
> existing code that the optimization might break, then the attribute could be
> specified differently (e.g., as a function attribute with an argument number
> indicating which argument is unused; that would also differentiate it from the
> existing function attribute).  Or the same feature could be provided under a
> different attribute.  The main idea here is the ability to express the notion
> that a function doesn't modify an object via its (non-const) pointer 
> argument. 
> The name for the feature is secondary (though "unused" is obviously a nice
> fit).

The "unused" attribute always means "possibly unused, don't warn if 
actually unused".  It would be a mistake to make it mean anything else.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  Of course, referencing a label outside of a target region from a
target region when offloading or referencing a label from the target region
from outside of a target region will still not work (but then it is a clear
don't do that).

[Bug tree-optimization/81696] [5/6/7/8 Regression] ICF ICE on non-local goto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Marek Polacek from comment #3)
> (In reply to Richard Biener from comment #2)
> > Note the folding we do here is not safe (but I hesitated to remove all the
> > copies...).  It can end up confusing data dependence analysis (read:
> > wrong-code).
> 
> I hope you don't mean that removing the folding causes wrong-code ;).

No, on the contrary...

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

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Btw, one mistake in the folding is that

  if (TREE_CODE (sub) == POINTER_PLUS_EXPR
  && TREE_CODE (TREE_OPERAND (sub, 1)) == INTEGER_CST)
{
  tree op00 = TREE_OPERAND (sub, 0);
  tree op01 = TREE_OPERAND (sub, 1);
^^^

this has to be interpreted as signed (but is always sizetype).  I suspect
restricting this to INTEGER_CST min_val and doing the arithmetic with
offset_ints is easiest.  The non-ARRAY_TYPE cases look ok to me.

[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Created attachment 41915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41915=edit
Assemby for pr25967-1

> Please compile it with -g and provide stack backtrace.

This is what I have done. bt is

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)
  * frame #0: 0x7fff9e17d2fa libdyld.dylib`stack_not_16_byte_aligned_error

> Please also provide the assembly codes of fn and main.

Assembly attached.

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

[v.barinov at samsung dot com]

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

Slava Barinov  changed:

   What|Removed |Added

 Target||armv7l-unknown-linux-gnueab
   ||i

--- Comment #1 from Slava Barinov  ---
Don't know if it's possible to write a test case: I can detect if section is
.str in assembly output, but don't know how to make dejagnu check it
automatically.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
(In reply to Richard Biener from comment #2)
> Note the folding we do here is not safe (but I hesitated to remove all the
> copies...).  It can end up confusing data dependence analysis (read:
> wrong-code).

I hope you don't mean that removing the folding causes wrong-code ;).

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-03
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

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

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Note the folding we do here is not safe (but I hesitated to remove all the
copies...).  It can end up confusing data dependence analysis (read:
wrong-code).

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

[v.barinov at samsung dot com]

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

Bug ID: 81697
   Summary: Incorrect ASan global variables alignment on arm
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v.barinov at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 41914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41914=edit
proposed fix

I have the following code:

#include 
#include 

const char kRecoveryInstallString[] = "NEW";
const char kRecoveryUpdateString[] = "UPDATE";
const char kRecoveryUninstallationString[] = "UNINSTALL";

const std::map kStringToRequestMap = {
  {kRecoveryInstallString, 0},
  {kRecoveryUpdateString, 0},
  {kRecoveryUninstallationString, 0},
};

While compilation for armv7l with -O1 -fmerge-all-constants -fsanitize=address
ASan global variables with strings are placed into section '.rodata.str1.4'
which is not aligned by 64 bytes and mixed with ASan own strings. This leads to
strip during link time and false positive ASan reports due to wrong resulting
red zones size.

Original state:

  0x41a0 554e494e 5354414c 4c00  UNINSTALL...
  0x41b0     
  0x41c0 55504441 5445   UPDATE..
  0x41d0     
  0x41e0 4e455700    NEW.
  0x41f0     
  0x4200 6b537472 696e6754 6f526571 75657374 kStringToRequest
  0x4210 4d617000 6b526563 6f766572 794d6f75 Map.kRecoveryMou
  0x4220 6e745570 64617465 53747269 6e67 ntUpdateString..
  0x4230 6b526563 6f766572 794d6f75 6e74496e kRecoveryMountIn

After disabling section-anchors everything works as intended:

  0x47c0 55504441 5445   UPDATE..
  0x47d0     
  0x47e0     
  0x47f0     
  0x4800 4e455700    NEW.
  0x4810     
  0x4820     
  0x4830     
  0x4840 35203332 20312039 203c756e 6b6e6f77 5 32 1 9  96 1 9  160 4 3 __j
  0x4870 32323420 34203920 3c756e6b 6e6f776e 224 4 9  288 4 9 

[Bug tree-optimization/81696] [5/6/7/8 Regression] ICF ICE on non-local goto

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-03
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICF ICE on non-local goto   |[5/6/7/8 Regression] ICF
   ||ICE on non-local goto
 Ever confirmed|0   |1

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

[Bug tree-optimization/81694] VRP optimization may introduce buffer overflow vulnerabilities into applications

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|VERIFIED|RESOLVED
 CC||mpolacek at gcc dot gnu.org

--- Comment #8 from Marek Polacek  ---
No, see Comment 6.

[Bug tree-optimization/81694] VRP optimization may introduce buffer overflow vulnerabilities into applications

[scdengyuan at gmail dot com]

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

--- Comment #7 from Yuan Deng  ---
When compiled with O0 or O1, the program work well,
inspite of val is overflowed, the program is actually very safe, and
can not be exploited.

But when compiled with O2 or O3, the result is different. The program
got a buffer overflow and can be exploited.

Actually, In my security reseach work, I have discovered many
exploitable vulnerabilities with this root cause in some products.
When compiled without VRP optimization, the vulnerability disapeared.
But if compiled with VRP optimization, the vulnerability is back.

So, I think it's definitely GCC's responsibility.
It's GCC's optimization which turn a non-exploitable program into a
exploitable program.

2017-08-03 21:17 GMT+08:00 pinskia at gcc dot gnu.org
:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81694
>
> --- Comment #6 from Andrew Pinski  ---
> Overflow cannot be checked after the fact. It needs to be checked before the
> overflow has happened.  Just like a buffet overflow should not be checked
> after.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Please compile it with -g and provide stack backtrace.
Please also provide the assembly codes of fn and main.

[Bug tree-optimization/81696] New: ICF ICE on non-local goto

[jakub at gcc dot gnu.org]

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

Bug ID: 81696
   Summary: ICF ICE on non-local goto
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

int
main ()
{
  __label__ lab4, lab5, lab6;
  void foo (void) { goto lab4; }
  void bar (void) { goto lab5; }
  void baz (void) { goto lab6; }
  foo ();
 lab4:;
  bar ();
 lab5:;
  baz ();
 lab6:;
  return 0;
}

ICEs at -O2 somewhere in ICF.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Started with r172261.  Will take a look.

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

[mpolacek at gcc dot gnu.org]

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

Bug ID: 81695
   Summary: [5/6/7/8 Regression] internal compiler error: in
size_binop_loc, at fold-const.c:1768
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

int z[] = { };

int
main (int argc, char *argv[])
{
  __builtin_printf ("%d\n", *(z + 1));
}

gives

$ ./cc1 -quiet s.c
s.c: In function ‘main’:
s.c:6:3: internal compiler error: in size_binop_loc, at fold-const.c:1768
   __builtin_printf ("%d\n", *(z + 1));
   ^~~
0xac0fc6 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
/home/marek/src/gcc/gcc/fold-const.c:1767
0xaf576d fold_indirect_ref_1(unsigned int, tree_node*, tree_node*)
/home/marek/src/gcc/gcc/fold-const.c:14114
0xaf5b07 fold_indirect_ref_loc(unsigned int, tree_node*)
/home/marek/src/gcc/gcc/fold-const.c:14163
0xb9831a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marek/src/gcc/gcc/gimplify.c:11433
0xb9b2d2 gimplify_expr
/home/marek/src/gcc/gcc/gimplify.c:12321
0xb73253 gimplify_arg(tree_node**, gimple**, unsigned int, bool)
/home/marek/src/gcc/gcc/gimplify.c:3082
0xb74470 gimplify_call_expr
/home/marek/src/gcc/gcc/gimplify.c:3302
0xb97a2f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marek/src/gcc/gcc/gimplify.c:11292
0xb8073b gimplify_stmt(tree_node**, gimple**)
/home/marek/src/gcc/gcc/gimplify.c:6542
0xb6d8a2 gimplify_bind_expr
/home/marek/src/gcc/gcc/gimplify.c:1290
0xb98823 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marek/src/gcc/gcc/gimplify.c:11520
0xb8073b gimplify_stmt(tree_node**, gimple**)
/home/marek/src/gcc/gcc/gimplify.c:6542
0xb6f188 gimplify_statement_list
/home/marek/src/gcc/gcc/gimplify.c:1732
0xb997ab gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marek/src/gcc/gcc/gimplify.c:11748
0xb8073b gimplify_stmt(tree_node**, gimple**)
/home/marek/src/gcc/gcc/gimplify.c:6542
0xb9bfa2 gimplify_body(tree_node*, bool)
/home/marek/src/gcc/gcc/gimplify.c:12517
0xb9c8cd gimplify_function_tree(tree_node*)
/home/marek/src/gcc/gcc/gimplify.c:12675
0x983fde cgraph_node::analyze()
/home/marek/src/gcc/gcc/cgraphunit.c:668
0x9858cd analyze_functions
/home/marek/src/gcc/gcc/cgraphunit.c:1129
0x98a241 symbol_table::finalize_compilation_unit()
/home/marek/src/gcc/gcc/cgraphunit.c:2607
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> Please show gdb backtrace as well as disassemble fn/main.

The best I can do without further directive

Current executable set to './a.out' (x86_64).
(lldb) run
Process 25263 launched: './a.out' (x86_64)
Process 25263 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)
frame #0: 0x7fff9e17d2fa libdyld.dylib`stack_not_16_byte_aligned_error
libdyld.dylib`stack_not_16_byte_aligned_error:
->  0x7fff9e17d2fa <+0>: movdqa %xmm0, (%rsp)
0x7fff9e17d2ff <+5>: int3   

libdyld.dylib`_dyld_func_lookup:
0x7fff9e17d300 <+0>: pushq  %rbp
0x7fff9e17d301 <+1>: movq   %rsp, %rbp
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)
  * frame #0: 0x7fff9e17d2fa libdyld.dylib`stack_not_16_byte_aligned_error

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

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
In this particular case we are not exactly copying the region, we are only
moving (outlining) it to a separate function.  We could properly remap the
label.

But in general GCC is indeed confused about address-taken labels when cloning
code for loop unswitching or function clones: bug 80053.

[Bug c/79959] -Wimplicit-fallthrough doesn't recognize some more complex exit cases

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Should be possible to fix this.  Mine.

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

[protze at itc dot rwth-aachen.de]

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

--- Comment #2 from Joachim Protze  ---
Why do you classify the testcase to be invalid code? Neither OpenMP nor C
forbid the use of a label there. Is this an undocumented restriction of the
&&-extension?

Also, clang and icc accept the code despite the use of the && GNU extension.
For both compilers the resulting binaries produce reasonable output.

[Bug tree-optimization/81694] VRP optimization may introduce buffer overflow vulnerabilities into applications

[amonakov at gcc dot gnu.org]

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

--- Comment #5 from Alexander Monakov  ---
GCC exploits undefined behavior throughout the compilation pipeline, if you
want a methodical workaround, you need compilation mode that makes overflow
defined (-fwrapv), and likewise for other sources of undefined behavior. A few
links to related discussion are available at https://gcc.gnu.org/wiki/boringcc

[Bug tree-optimization/81694] VRP optimization may introduce buffer overflow vulnerabilities into applications

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
Overflow cannot be checked after the fact. It needs to be checked before the
overflow has happened.  Just like a buffet overflow should not be checked
after.

[Bug tree-optimization/81694] VRP optimization may introduce buffer overflow vulnerabilities into applications

[scdengyuan at gmail dot com]

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

Yuan Deng  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #4 from Yuan Deng  ---
Inspite of val is overflowed or not, the later check should have avoid this:
if( m_var > 0 && m_index > 0 && m_index < (1 << 16))

but did not!
I thin it's a very serious problem.

[Bug tree-optimization/81694] VRP optimization may introduce buffer overflow vulnerabilities into applications

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org
 Resolution|WONTFIX |INVALID

--- Comment #3 from Alexander Monakov  ---
(Andrew, the correct resolution here is INVALID, not WONTFIX)

The value assigned to m_index is computed in a signed type:

static int ReadNumber(BStream& strm)
{
int code;
int val = 0;

do {
code = strm.getByte();
}
while( !isdigit( code ));

do {
val = val*10 + code;
code = strm.getByte();
}
while( isdigit(code));

return val;
}

and therefore overflowing 'val' invokes undefined behavior.

[Bug tree-optimization/81694] VRP optimization may introduce buffer overflow vulnerabilities into applications

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Andrew Pinski  ---
This is by design.

Use -fsantize=undefined to find these kind of undefined behavior in your
program.

[Bug target/81693] FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-03
 CC||hjl.tools at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Please show gdb backtrace as well as disassemble fn/main.

[Bug tree-optimization/81694] VRP optimization may introduce buffer overflow vulnerabilities into applications

[scdengyuan at gmail dot com]

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

--- Comment #1 from Yuan Deng  ---
Created attachment 41913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41913=edit
patch for this vulnerability

[Bug tree-optimization/81694] New: VRP optimization may introduce buffer overflow vulnerabilities into applications

[scdengyuan at gmail dot com]

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

Bug ID: 81694
   Summary: VRP optimization may introduce buffer overflow
vulnerabilities into applications
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scdengyuan at gmail dot com
  Target Milestone: ---

Created attachment 41912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41912=edit
proof of concept

function extract_range_from_multiplicative_op_1 in tree-vrp.c in GNU Compiler
Collection (gcc) from 4.7.0 to 7.1.0 improperly handles integer overflow, which
might introduce buffer overflow vulnerabilities into applications.

When O2 or O3 flag is set, VRP optimization is enabled.
in my poc:
m_index = ReadNumber(m_strm);
if( m_index > 65535 )
return false;

// int m_index can be overflowed to negative but VRP think it's between
[48, +INF(OVF)], and ignored checking in next line 
if( m_var > 0 && m_index > 0 && m_index < (1 << 16)) //this line was
optimized to "if( m_var>0 )"
// so negative m_index can bypass the check and return true



Value ranges after VRP:

_1: ~[0B, 0B]
_2: VARYING
_3: [0, +INF]
.MEM_4: VARYING
this_7(D): ~[0B, 0B]
_9: VARYING
_11: [48, 57]  EQUIVALENCES: { _15 } (1 elements)
this_12: ~[0B, 0B]  EQUIVALENCES: { this_7(D) } (1 elements)
_15: VARYING
code.1_16: [0, +INF]
_17: [0, +INF]
val_18: [0, +INF(OVF)]
_19: [0, +INF(OVF)]
code_20: [48, 57]  EQUIVALENCES: { } (0 elements)
val_21: [48, +INF(OVF)]
_22: VARYING
code.3_23: [0, +INF]
_24: [0, +INF]
_25: [48, 57]  EQUIVALENCES: { _15 } (1 elements)
.MEM_26: VARYING
.MEM_27: VARYING
val_30: [48, +INF(OVF)]
_31: [48, 57]  EQUIVALENCES: { _22 } (1 elements)
val_32: [48, 65535]  EQUIVALENCES: { val_30 } (1 elements)

   [15.00%]:
  # val_30 = PHI 
  # DEBUG strm => NULL
  # DEBUG val => NULL
  # DEBUG code => NULL
  this_7(D)->m_index = val_30;
  if (val_30 > 65535)
goto ; [46.00%]
  else
goto ; [54.00%]

   [8.10%]:
  # DEBUG strm => NULL
  # DEBUG val => NULL
  # DEBUG code => NULL
  _2 = this_7(D)->m_var;
  if (_2 > 0)
goto ; [67.61%]
  else
goto ; [32.39%]

   [3.70%]:
  # DEBUG result => 1

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid, openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-03
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I think we cannot copy such region so we'd have to reject the
testcase.

[Bug target/81693] New: FAIL: gcc.dg/torture/pr25967-*.c -O* execution test on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 81693
   Summary: FAIL: gcc.dg/torture/pr25967-*.c   -O*  execution test
on darwin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, uros at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin16
Target: x86_64-apple-darwin16
 Build: x86_64-apple-darwin16

The new tests gcc.dg/torture/pr25967-(1|2).c fail on darwin

FAIL: gcc.dg/torture/pr25967-1.c   -O1  execution test
FAIL: gcc.dg/torture/pr25967-1.c   -O2  execution test
FAIL: gcc.dg/torture/pr25967-1.c   -O2 -flto  execution test
FAIL: gcc.dg/torture/pr25967-1.c   -O2 -flto -flto-partition=none  execution
test
FAIL: gcc.dg/torture/pr25967-1.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr25967-2.c   -O0  execution test
FAIL: gcc.dg/torture/pr25967-2.c   -O1  execution test
FAIL: gcc.dg/torture/pr25967-2.c   -O2  execution test
FAIL: gcc.dg/torture/pr25967-2.c   -O2 -flto  execution test
FAIL: gcc.dg/torture/pr25967-2.c   -O2 -flto -flto-partition=none  execution
test
FAIL: gcc.dg/torture/pr25967-2.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr25967-2.c   -Os  execution test

with -m32 and

FAIL: gcc.dg/torture/pr25967-1.c   -O1  execution test
FAIL: gcc.dg/torture/pr25967-1.c   -O2  execution test
FAIL: gcc.dg/torture/pr25967-1.c   -O2 -flto  execution test
FAIL: gcc.dg/torture/pr25967-1.c   -O2 -flto -flto-partition=none  execution
test
FAIL: gcc.dg/torture/pr25967-1.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr25967-1.c   -Os  execution test
FAIL: gcc.dg/torture/pr25967-2.c   -O0  execution test

with -m64.

% /opt/gcc/gcc8w/bin/gcc -mgeneral-regs-only
/opt/gcc/_clean/gcc/testsuite/gcc.dg/torture/pr25967-1.c -O1
-fno-reorder-blocks-and-partition
% ./a.out  
  Segmentation fault

[Bug sanitizer/81148] UBSAN: two more false positives

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Author: rguenth
Date: Thu Aug  3 11:52:00 2017
New Revision: 250853

URL: https://gcc.gnu.org/viewcvs?rev=250853=gcc=rev
Log:
2017-08-03 Richard Biener  

PR middle-end/81148
* fold-const.c (split_tree): Add minus_var and minus_con
arguments, remove unused loc arg.  Never generate NEGATE_EXPRs
here but always use minus_*.
(associate_trees): Assert we never associate with MINUS_EXPR
and NULL first operand.  Do not recurse for PLUS_EXPR operands
when associating as MINUS_EXPR either.
(fold_binary_loc): Track minus_var and minus_con.

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

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

[Bug c++/81692] Bogus noreturn warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

It's a little bit weird, we don't warn about this if
current_function_returns_abnormally.