[Bug fortran/87707] actual argument to assumed type dummy argument (i.e. type(*)) cannot have type-bound procedures

[m.diehl at mpie dot de]

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

Martin Diehl  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Martin Diehl  ---
Contrary to my previous statement, the behavior of gfortran is in agreement
eith the F2018 draft.
15.5.2.4 (Argument association > Ordinary dummy variables) states:

"If the actual argument is of a derived type that has type parameters,
type-bound procedures, or final subroutines, the dummy argument shall not be
assumed type."

[Bug middle-end/59658] Document -f* flags enabled by -Og

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
(In reply to Richard Biener from comment #1)
> But it might be misleading (similar to -O0 vs -O2) - enabling for example
> -ftree-pre won't enable PRE for -Og as it has a completely different
> pass pipeline which is not based on -O[123].  Those enumerations are only
> relevant for the 'numbered' optimization levels (excluding -O0).
> 
> So we miss to filter options in --help optimizers that can be enabled at all.

It's a place to start at least.

[Bug tree-optimization/87719] New: missing warning on printf %s and unterminated array

[msebor at gcc dot gnu.org]

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

Bug ID: 87719
   Summary: missing warning on printf %s and unterminated array
   Product: gcc
   Version: 9.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: ---

GCC 9 issues an unterminated array warning for calls to sprintf but not for the
equivalent calls to printf (of fprintf):

$ cat t.c && gcc -O2 -S  -Wall t.c
const char a[] = { 'a', 'b' };

void f (char *d)
{
  __builtin_sprintf (d, "%s", a);   // warning, good
}

void g (void)
{
  __builtin_printf ("%s", a);   // missing warning
}
t.c: In function ‘f’:
t.c:5:26: warning: ‘%s’ directive argument is not a nul-terminated string
[-Wformat-overflow=]
5 |   __builtin_sprintf (d, "%s", a);   // warning, good
  |  ^~   ~
t.c:1:12: note: referenced argument declared here
1 | const char a[] = { 'a', 'b' };
  |^

[Bug rtl-optimization/87716] [9 Regression] FAIL: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-24
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
We currently generate:

test1:
movdqa  (%rdi), %xmm2
pavgb   (%rsi), %xmm2
movdqa  %xmm0, %xmm3
movdqa  %xmm2, %xmm0
punpckhbw   %xmm1, %xmm2
punpcklbw   %xmm1, %xmm0
pmulhuw %xmm3, %xmm2
pmulhuw %xmm3, %xmm0
packuswb%xmm2, %xmm0
movaps  %xmm0, (%rdx)
ret

One of

movdqa  %xmm0, %xmm3
movdqa  %xmm2, %xmm0

is redundant. We should generate

movdqa  %xmm2, %xmm3

[Bug rtl-optimization/87716] [9 Regression] FAIL: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
A slightly older compiler gave

test1:
movdqa  (%rdi), %xmm2
pavgb   (%rsi), %xmm2
movdqa  %xmm2, %xmm3
punpckhbw   %xmm1, %xmm2
punpcklbw   %xmm1, %xmm3
pmulhuw %xmm0, %xmm2
pmulhuw %xmm0, %xmm3
packuswb%xmm2, %xmm3
movaps  %xmm3, (%rdx)
ret

What is so super strange about the current generated code?

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[headch at gmail dot com]

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

--- Comment #9 from Christopher Head  ---
I had to use slightly different code because I only have an ARM cross-compiler
version 8.2.0 installed, so I used this:

void g(unsigned char x);

struct MyStruct {
char foo[8];
};

unsigned char buffer[100], buffer2[100];

void f(void) {
buffer2[5] = 'X';
struct MyStruct *p = (void *) buffer;
asm volatile("nop" : "=m" (*p));
g(buffer2[5]);
}

No matter what I changed the size of the foo array in MyStruct to (I tried 8,
15, 13, and 257), this was always the disassembly:

 :
   0:   4a03ldr r2, [pc, #12]   ; (10 )
   2:   2058movsr0, #88 ; 0x58
   4:   4b03ldr r3, [pc, #12]   ; (14 )
   6:   7150strbr0, [r2, #5]
   8:   bf00nop
   a:   f7ff bffe   b.w 0 
a: R_ARM_THM_JUMP24 g
   e:   bf00nop

Notice that r0 is loaded at offset 2, then passed into g at offset a, and is
not reloaded from the array. If I change the asm to have a full memory clobber,
an ldrb is inserted between the nop and the b.w, as expected, since then
buffer2 is also clobbered.

So, doesn’t this mean that it *is* properly clobbering only buffer, not
buffer2, regardless of the size of foo?

[Bug rtl-optimization/87718] New: [9 Regression] FAIL: gcc.target/i386/avx512dq-concatv2si-1.c

[hjl.tools at gmail dot com]

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

Bug ID: 87718
   Summary: [9 Regression] FAIL:
gcc.target/i386/avx512dq-concatv2si-1.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: segher at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

On x86, r265398 caused:

FAIL: gcc.target/i386/avx512dq-concatv2si-1.c scan-assembler-times
vpinsrd[^\n\r]*\\$1[^\n\r]*%xmm16[^\n\r]*%xmm3 2
FAIL: gcc.target/i386/avx512dq-concatv2si-1.c scan-assembler
vpunpckldq[^\n\r]*%xmm17[^\n\r]*%xmm16[^\n\r]*%xmm3

Before:

.file   "avx512dq-concatv2si-1.c"
.text
.p2align 4
.globl  f1
.type   f1, @function
f1:
.LFB0:
.cfi_startproc
movl%edi, -4(%rsp)
vmovd   -4(%rsp), %xmm16
movl%esi, -4(%rsp)
vmovd   -4(%rsp), %xmm17
vpunpckldq  %xmm17, %xmm16, %xmm3
ret
.cfi_endproc
.LFE0:
.size   f1, .-f1

After:

.file   "avx512dq-concatv2si-1.c"
.text
.p2align 4
.globl  f1
.type   f1, @function
f1:
.LFB0:
.cfi_startproc
movl%edi, -4(%rsp)
vmovd   -4(%rsp), %xmm16
movl%esi, -4(%rsp)
vmovd   -4(%rsp), %xmm17
vmovd   %xmm17, %eax
vpinsrd $1, %eax, %xmm16, %xmm3
ret
.cfi_endproc
.LFE0:
.size   f1, .-f1

[Bug rtl-optimization/87717] New: [9 Regression] FAIL: gcc.target/i386/avx512vl-concatv2si-1.c scan-assembler vpunpckldq[^\n\r]*%xmm17[^\n\r]*%xmm16[^\n\r]*%xmm3

[hjl.tools at gmail dot com]

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

Bug ID: 87717
   Summary: [9 Regression] FAIL:
gcc.target/i386/avx512vl-concatv2si-1.c scan-assembler
vpunpckldq[^\n\r]*%xmm17[^\n\r]*%xmm16[^\n\r]*%xmm3
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: segher at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

On x86-64, r265398 caused:

FAIL: gcc.target/i386/avx512vl-concatv2si-1.c scan-assembler
vpunpckldq[^\n\r]*%xmm17[^\n\r]*%xmm16[^\n\r]*%xmm3

Before:

f1:
.LFB0:
.cfi_startproc
movl%edi, -4(%rsp)
vmovd   -4(%rsp), %xmm16
movl%esi, -4(%rsp)
vmovd   -4(%rsp), %xmm17
vpunpckldq  %xmm17, %xmm16, %xmm3
ret
.cfi_endproc
.LFE0:
.size   f1, .-f1

After:

f1:
.LFB0:
.cfi_startproc
movl%edi, -4(%rsp)
vmovd   -4(%rsp), %xmm16
movl%esi, -4(%rsp)
vmovd   -4(%rsp), %xmm17
vmovd   %xmm17, %eax
vmovdqa32   %zmm16, %zmm0
vmovd   %xmm16, -4(%rsp)
vpinsrd $1, %eax, %xmm0, %xmm3
ret
.cfi_endproc
.LFE0:
.size   f1, .-f1

SAP Business One Demo at your offices

[Procons-4it]

Dear Business Partner,



ProCons4IT team in Lebanon is glad to schedule a demo of SAP Business One 
complete ERP software solution at your offices to showcase how it can help you 
cope with digital transformation.



ProCons 4IT is the largest SAP Business One partner in Middle East and TOP 10 
globally with more than 50 consultants across all its offices. SAP Business One 
is the ideal integrated ERP software solution on Premise or Cloud for Small to 
Medium companies around the world with more than 50 clients in Lebanon and 
60,000 worldwide. It manages all your business from Finance, Accounting, Sales, 
Stock, Inventory to Warehouse, production, HR & Payroll all in one screen.



Please reply to this message with your preferred date/time and will be happy to 
contact you asap to confirm accordingly.



We look forward to meeting with you very soon.



Warm Regards,



ProCons 4IT Team.

Run better with SAP. Run simple with SAP Business One.



Procons 4 IT
Al Moudir Bldg, 3^rd Floor, Jal El Dib
Beirut, Lebanon

Phone : +961 4 725601 (tel:+96120420725601) /2/3
www.procons-4it.com 
(https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.procons-4it.com%2F=02%7C01%7Ctarek.hamdan%40procons-4it.com%7Ccdcba7b8ef6b4cebf7ea08d62e778721%7C5cab5bf6d1834be397b42a5ff8c5d330%7C1%7C0%7C636747488251771984=QhHZaB%2BjUNdyzzbdvFQYzNgmVSas8qlaw1VbNSXvPyU%3D=0)

ProCons  sap

SAP Master Value Added Reseller (VAR)
Lebanon, Dubai, KSA, Kuwait, Qatar, Oman

sap

To Stop Receiving our email please reply with REMOVE
You received this email because you are in GFC.media (https://gfc.media/)  
newsletter list

This email was sent to gcc-bugs@gcc.gnu.org (mailto:gcc-bugs@gcc.gnu.org)
why did I get this? 
(https://battleparkae.us19.list-manage.com/about?u=90bac0906b280fc6945d7b273=4a9f8b0547=9a0a13d120=5428d1b656)
 unsubscribe from this list 
(https://battleparkae.us19.list-manage.com/unsubscribe?u=90bac0906b280fc6945d7b273=4a9f8b0547=9a0a13d120=5428d1b656)
 update subscription preferences 
(https://battleparkae.us19.list-manage.com/profile?u=90bac0906b280fc6945d7b273=4a9f8b0547=9a0a13d120)
BP AE . UAE . Dubai  . United Arab Emirates

[Bug rtl-optimization/87716] New: [9 Regression] FAIL: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2

[hjl.tools at gmail dot com]

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

Bug ID: 87716
   Summary: [9 Regression] FAIL: gcc.target/i386/pr57193.c
scan-assembler-times movdqa 2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: segher at gcc dot gnu.org
  Target Milestone: ---

On x86, r265398 caused:

FAIL: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2

movdqa  (%rdi), %xmm2
pavgb   (%rsi), %xmm2
movdqa  %xmm0, %xmm3 <<

[Bug fortran/87689] Memory corruption on Power 8

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
No, doesn't ring bells.  But I have some more input:

I couldn't get it to fail on powerpc64-linux.
It fails on powerpc64le-linux only if the second file is compiled with -O0.

As output I get just

$ ./87689 |xxd -g1
000: 20 20 20 20 20 20 20 20 20 20 20 31 20 20 20 20 1
010: 20 20 20 20 20 20 20 32 20 20 20 20 20 20 20 20 2
020: 20 20 20 33 20 20 20 20 20 20 20 20 20 20 20 34 3   4
030: 20 20 20 20 20 20 20 20 20 20 20 35 20 20 20 20 5
040: 20 20 20 20 20 20 20 30 0a 20 00 0a 20 66 6f 6f 0. .. foo
050: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20  
060: 20 0a

so no weird characters other than a zero byte.

[Bug target/87690] [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI

[asb at lowrisc dot org]

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

--- Comment #6 from Alex Bradbury  ---
(In reply to Jim Wilson from comment #4)
> I think the intent of the second rule is that float values are passed in the
> same regs as an integer value, and that it wasn't the intent that the
> promotion rule also applied to float values.

Maybe. Given the looseness of the phrasing I expect signext vs anyext just
wasn't thought about.

First of all, many thanks for such a detailed response. I'm completely happy
with seeing the psABI doc updated so that floats passed via the integer calling
convention are anyext. On the LLVM side, I think it's actually not too
difficult to enforce sign-extension of floats passed in -mabi=lp64. But there's
definitely effort in thoroughly testing it works in all cases. Plus changing
nothing is even simpler.

I also don't see value in enforcing that floats are sign-extended. Lets fix the
psABI docs. I've made a PR to do so
https://github.com/riscv/riscv-elf-psabi-doc/pull/82

[Bug target/87690] [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI

[andrew at sifive dot com]

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

--- Comment #5 from Andrew Waterman  ---
FWIW, I agree with your last paragraph

On Wed, Oct 24, 2018 at 7:54 AM wilson at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690
>
> Jim Wilson  changed:
>
>What|Removed |Added
>
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2018-10-23
>Assignee|unassigned at gcc dot gnu.org  |wilson at gcc dot
> gnu.org
>  Ever confirmed|0   |1
>
> --- Comment #4 from Jim Wilson  ---
> I think the intent of the second rule is that float values are passed in
> the
> same regs as an integer value, and that it wasn't the intent that the
> promotion
> rule also applied to float values.
>
> The GCC RISC-V port is passing 32-bit floats as SFmode, which means only
> the
> low 32-bits of the value are valid.  A struct with a single float field
> also
> gets treated as SFmode, so that we can directly access the float member.
> riscv_function_arg isn't checking the argument type, it is only checking
> the
> argument mode.  Hence, a float and a struct with a single float member get
> handled exactly the same.  Since they are passed the same, there is no
> conversion code to go from one to the other.
>
> We would have the exact same problem with a struct with a single int field,
> except that PROMOTE_MODE forces SImode to be handled as DImode, and the
> promote_mode function does check types, and only applies PROMOTE_MODE to
> integer types.  Hence, a struct with single int field is SImode and an int
> is
> DImode, and we require conversion code which does the sign extension
> called for
> by the ABI.  But PROMOTE_MODE is only sensible for integral types, so this
> can't solve the float problem.
>
> I don't see any point to trying to sign extend a 32-bit float in a 64-bit
> integer register.  There are only a few useful things one can do to a
> float in
> an integer register, such as absolute value and signbit, and having the
> value
> be sign extended doesn't help there.  For instance given
> #include 
>
> float sub (float a)
> {
>   return fabs (a);
> }
> and compiling with riscv64-unknown-elf-gcc -O2 -S -mabi=lp64 -march=rv64i
> I get
> sub:
> sllia0,a0,33
> srlia0,a0,33
> ret
> The upper 32-bits of a0 are being treated as don't care bits for both the
> argument and the return value.  They are ignored for the input value, and
> set
> to 0 for the return value.  Having the value sign-extended doesn't make
> this
> code any simpler.  I see that we aren't actually optimizing signbit as we
> should be, but again having it sign-extended doesn't give shorter code.
>
> Requiring that float values be sign extended in a 64-bit reg might require
> emitting extra instructions in some cases, which could reduce
> performance.  So
> it also seems unwise from that point of view.  Consider this testcase for
> instance
> struct float_struct { float v; float w;};
>
> struct float_struct callee(float, float);
>
> struct float_struct caller(struct float_struct fs) {
>   return callee(fs.v, fs.w);
> }
> Compiled with riscv64-unknown-elf-gcc -O2 -S -mabi=lp64 I get
> caller:
> addisp,sp,-32
> sd  a0,8(sp)
> srlia1,a0,32
> addisp,sp,32
> tailcallee
> The 2-float struct is passed entirely in a0.  Since the upper 32-bits of a
> float arg are don't care bits, we can pass a0 directly to callee
> unchanged.
> The second arg for callee is extracted from the upper bits of a0 with a
> logical
> shift that zero extends it.  We could change the logical shift to an
> arithmetic
> shift at no cost.  But sign-extending the float a0 would require adding two
> shift instructions.
>
> I am also concerned that there might be implementation problems trying to
> convince gcc to sign-extend floating point values in integer registers, as
> that
> isn't a natural thing to do.
>
> I think the simplest solution here is to update the psABI to indicate that
> float values in integer registers are not sign extended. Or alternatively
> that
> the sign extension rule only applies to integer types.

[Bug target/87690] [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-23
   Assignee|unassigned at gcc dot gnu.org  |wilson at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jim Wilson  ---
I think the intent of the second rule is that float values are passed in the
same regs as an integer value, and that it wasn't the intent that the promotion
rule also applied to float values.

The GCC RISC-V port is passing 32-bit floats as SFmode, which means only the
low 32-bits of the value are valid.  A struct with a single float field also
gets treated as SFmode, so that we can directly access the float member. 
riscv_function_arg isn't checking the argument type, it is only checking the
argument mode.  Hence, a float and a struct with a single float member get
handled exactly the same.  Since they are passed the same, there is no
conversion code to go from one to the other.

We would have the exact same problem with a struct with a single int field,
except that PROMOTE_MODE forces SImode to be handled as DImode, and the
promote_mode function does check types, and only applies PROMOTE_MODE to
integer types.  Hence, a struct with single int field is SImode and an int is
DImode, and we require conversion code which does the sign extension called for
by the ABI.  But PROMOTE_MODE is only sensible for integral types, so this
can't solve the float problem.

I don't see any point to trying to sign extend a 32-bit float in a 64-bit
integer register.  There are only a few useful things one can do to a float in
an integer register, such as absolute value and signbit, and having the value
be sign extended doesn't help there.  For instance given
#include 

float sub (float a)
{
  return fabs (a);
}
and compiling with riscv64-unknown-elf-gcc -O2 -S -mabi=lp64 -march=rv64i I get
sub:
sllia0,a0,33
srlia0,a0,33
ret
The upper 32-bits of a0 are being treated as don't care bits for both the
argument and the return value.  They are ignored for the input value, and set
to 0 for the return value.  Having the value sign-extended doesn't make this
code any simpler.  I see that we aren't actually optimizing signbit as we
should be, but again having it sign-extended doesn't give shorter code.

Requiring that float values be sign extended in a 64-bit reg might require
emitting extra instructions in some cases, which could reduce performance.  So
it also seems unwise from that point of view.  Consider this testcase for
instance
struct float_struct { float v; float w;};

struct float_struct callee(float, float);

struct float_struct caller(struct float_struct fs) {
  return callee(fs.v, fs.w);
}
Compiled with riscv64-unknown-elf-gcc -O2 -S -mabi=lp64 I get
caller:
addisp,sp,-32
sd  a0,8(sp)
srlia1,a0,32
addisp,sp,32
tailcallee
The 2-float struct is passed entirely in a0.  Since the upper 32-bits of a
float arg are don't care bits, we can pass a0 directly to callee unchanged. 
The second arg for callee is extracted from the upper bits of a0 with a logical
shift that zero extends it.  We could change the logical shift to an arithmetic
shift at no cost.  But sign-extending the float a0 would require adding two
shift instructions.

I am also concerned that there might be implementation problems trying to
convince gcc to sign-extend floating point values in integer registers, as that
isn't a natural thing to do.

I think the simplest solution here is to update the psABI to indicate that
float values in integer registers are not sign extended. Or alternatively that
the sign extension rule only applies to integer types.

[Bug fortran/87648] Clobber some variables on entry to DO CONCURRENT

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Some more food for thought - what if there is only a single iteration?

[Bug fortran/87689] Memory corruption on Power 8

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #3)
> This goes away with -flto or if you put both procedures into one file,
> and does not happen on Linux.

I meant on x86_64.

Wild guess: Do we somehow get the declarations wrong (or different) and this
shows up because we trigger some difference in the POWER ABI?

Segher, does this maybe ring a bell?

[Bug fortran/87689] Memory corruption on Power 8

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Thomas Koenig  ---
I checked, and it seems that this is an old bug; it occurs both
with gfortran 4.8.5 and 8.1.0.

This goes away with -flto or if you put both procedures into one file,
and does not happen on Linux.

Tree dump looks reasonable with 8.1:

static integer(kind=4) C.2183 = 1;
static integer(kind=4) C.2184 = 2;
static integer(kind=4) C.2185 = 3;
static integer(kind=4) C.2186 = 4;
static integer(kind=4) C.2187 = 5;
static integer(kind=4) C.2188 = 6;
character(kind=1) str.0[20];

doesntwork_p8 ((character(kind=1)[1:20] *) , 20, , ,
, , , , , 1);
__builtin_memmove ((void *) , (void *) , 20);

vs.

doesntwork_p8 (character(kind=1)[1:20] & __result, integer(kind=8) .__result,
character(kind=1)[1:1] & restrict c, integer(kind=4) & restrict a1,
integer(kind=4) & restrict a2, integer(kind=4) & restrict a3, integer(kind=4) &
restrict a4, integer(kind=4) & restrict a5, integer(kind=4) & restrict a6,
integer(kind=8) _c)
{

What looks less reasonable is the debug output:

breakpoint 1, doesntwork_p8 (__result=@0x3fffed80:
'\224\016\000\020\000\000\000\000\230\016\000\020\000\000\000\000\000\000\000\000',
.__result=20, c='`', a1=1, a2=2, a3=3, a4=4, a5=5, 
a6=, _c=0) at
b.f90:6

This looks like the arguments pushed on the stack somehow have the wrong number
of bytes...

[Bug ada/87715] New: problems with asan and -O3 build of ada

[dcb314 at hotmail dot com]

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

Bug ID: 87715
   Summary: problems with asan and -O3 build of ada
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just tried to build the ada compiler with address sanitizer
and -O3 on recent gcc trunk.

Configure script is 

../trunk/configure --prefix=/home/dcb/gcc/results.265434.asan \
--with-build-config=bootstrap-asan \
--disable-multilib \
--disable-werror \
--enable-checking=release \
--enable-languages=c,c++,fortran,ada

sed 's/-O2/-O3 -Wlogical-op/' < Makefile > Makefile.tmp
mv Makefile.tmp Makefile

I get error messages:

$ egrep "^Config|ERROR:" mk.out 
...
Configuring stage 3 in ./libdecnumber
Configuring stage 3 in ./libcpp
Configuring stage 3 in ./gcc
=
==14774==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address
0x7ffe9efa6587 at pc 0x01cf4660 bp 0x7ffe9efa5e70 sp 0x7ffe9efa5e68
READ of size 1 at 0x7ffe9efa6587 thread T0
=
==14775==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address
0x7ffde98d1027 at pc 0x01cf4660 bp 0x7ffde98d0910 sp 0x7ffde98d0908
READ of size 1 at 0x7ffde98d1027 thread T0
=
==14779==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address
0x7ffcb7f760a7 at pc 0x01cf4660 bp 0x7ffcb7f75980 sp 0x7ffcb7f75978
READ of size 1 at 0x7ffcb7f760a7 thread T0

I suspect the -O3 might be causing a problem. I'll have another
go at building with -O2, not -O3.

[Bug go/87661] [9 Regression] libgo bootstrap failure on arm-linux-gnueabihf (redefinition of constants)

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed now.

[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
Thanks Douglas, no that is fine of course :-)  What I wanted to know is, does
it fail for the newest versions as well.  So it appears it does.  Which Ryan
already said but I have trouble reading apparently :-/

Thanks for the report!

[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT

[jozef.l at mittosystems dot com]

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

--- Comment #9 from Jozef Lawrynowicz  ---
Patch submitted: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01459.html

[Bug c++/87714] [8/9 Regression] ICE on valid C++ code: in type_dependent_expression_p, at cp/pt.c:25178

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r249323.

[Bug c++/87714] [8/9 Regression] ICE on valid C++ code: in type_dependent_expression_p, at cp/pt.c:25178

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-23
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |8.3
Summary|[8 regresion] ICE on valid  |[8/9 Regression] ICE on
   |C++ code: in|valid C++ code: in
   |type_dependent_expression_p |type_dependent_expression_p
   |, at cp/pt.c:25178  |, at cp/pt.c:25178
 Ever confirmed|0   |1

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

[Bug c++/87714] New: [8 regresion] ICE on valid C++ code: in type_dependent_expression_p, at cp/pt.c:25178

[development at jordi dot vilar.cat]

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

Bug ID: 87714
   Summary: [8 regresion] ICE on valid C++ code: in
type_dependent_expression_p, at cp/pt.c:25178
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: development at jordi dot vilar.cat
  Target Milestone: ---

Hi,

The issue appeared in g++ 8. It compiles ok in g++ 7.3, clang 6.0 and
VisualC++.

$> g++-8 -v -std=c++17 -c repro.cpp
Using built-in specs.
COLLECT_GCC=g++-8
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.2.0-1ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04)
COLLECT_GCC_OPTIONS='-v' '-std=c++17' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -quiet -v -imultiarch x86_64-linux-gnu
-D_GNU_SOURCE repro.cpp -quiet -dumpbase repro.cpp -mtune=generic -march=x86-64
-auxbase repro -std=c++17 -version -fstack-protector-strong -Wformat
-Wformat-security -o /tmp/ccmOu14n.s
GNU C++17 (Ubuntu 8.2.0-1ubuntu2~18.04) version 8.2.0 (x86_64-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/8
 /usr/include/x86_64-linux-gnu/c++/8
 /usr/include/c++/8/backward
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++17 (Ubuntu 8.2.0-1ubuntu2~18.04) version 8.2.0 (x86_64-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b531b606e797d462fe15d91f526b9496
repro.cpp: In instantiation of ‘static std::optional<_Tp> enum_helper::to_enum(std::basic_string_view) [with U =
std::char_traits; T = my_enum_type; bool is_bitmask = true]’:
repro.cpp:34:113:   required from here
repro.cpp:31:31: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:25178
 return parse_my_enum_type(syntax, { string.data(), string.size() });
   ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

repro.cpp --

#include 
#include 
#include 

template struct enum_helper
{
template static std::optional  
to_enum(std::basic_string_view s);
};

template struct icase_char_traits : public std::char_traits
{
static bool eq(C c1, C c2);
static bool lt(C c1, C c2);
static int compare(const C* s1, const C* s2, size_t n);
static const C* find(const C* s, size_t n, C a);
};

using ci_string_view = std::basic_string_view>;

enum class my_enum_type : std::uint32_t;

template<> template std::optional
enum_helper::to_enum(std::basic_string_view s);

std::optional parse_my_enum_type(const std::regex ,
std::string_view string);

template<> template std::optional
enum_helper::to_enum(std::basic_string_view string)
{
static const std::regex syntax(
R"(^...$)",
std::is_same_v> ? std::regex::ECMAScript |
std::regex::icase : std::regex::ECMAScript);
return parse_my_enum_type(syntax, { string.data(), string.size() });
}

template std::optional
enum_helper::to_enum>(std::string_view);
template std::optional

[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions

[dougmencken at gmail dot com]

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

--- Comment #9 from Douglas Mencken  ---
(In reply to Segher Boessenkool from comment #8)
> Is this on all (PowerPC) Darwin?  Only one some versions?  Which, then?

I am really not going to check it on OS X 10.0 or OS X Beta, or even OS X 10.2.
It fails on OS X 10.5 and OS X 10.4. It fails when it’s built via GCCs bundled
with Xcode, 4.0.1 and 4.2.1, as well as with self-built GCCs like 7.3.0 patched
and 6.4.0. It fails on stage2, in words: stage TWO, and stage1 ( stage ONE,
that one which depends on stage0, id est system, compiler ) is okay

[Bug go/87661] [9 Regression] libgo bootstrap failure on arm-linux-gnueabihf (redefinition of constants)

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Oct 23 19:02:29 2018
New Revision: 265439

URL: https://gcc.gnu.org/viewcvs?rev=265439=gcc=rev
Log:
PR go/87661
runtime: remove unused armArch, hwcap and hardDiv

After CL 140057 these are only written but never read in gccgo.

Reviewed-on: https://go-review.googlesource.com/c/141077

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/runtime/os_linux_arm.go

[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Is this on all (PowerPC) Darwin?  Only one some versions?  Which, then?

[Bug c++/87713] single character underlined in an error message instead of the whole token

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||error-recovery
 CC||dmalcolm at gcc dot gnu.org
   Severity|normal  |minor

--- Comment #1 from Martin Sebor  ---
David, you might be interested in this.

Action needed

[Citizens Bank]

 - This mail is in HTML. Some elements may be ommited in plain text. -


Dear customer,
Some Important data's on your Citizens profile has been missing.To Protect 
you,We have temporarily locked your account.Please,Kindly take  a moment to 
update and have your account restored

UPDATE YOUR INFORMATIONS
..  We value your membership!

Thanks,
Citizens Bank

[Bug c++/87713] New: single character underlined in an error message instead of the whole token

[msebor at gcc dot gnu.org]

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

Bug ID: 87713
   Summary: single character underlined in an error message
instead of the whole token
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Every now and then I notice a diagnostic where only a single character of a
token (identifier?) is underlined but up until now I haven't had luck
reproducing it (often times it involves macros).  The ill-formed C++ test case
below shows one situation when this happens without macros.  Note the
underlining in the second error.

$ cat t.C && gcc -S  -Wall t.C
int i = sizeof ((int));
t.C:1:18: error: expected primary-expression before ‘int’
1 | int i = sizeof ((int));
  |  ^~~
t.C:1:18: error: expected ‘)’ before ‘int’
1 | int i = sizeof ((int));
  | ~^~~
  |  )
t.C:1:23: error: expected ‘)’ before ‘;’ token
1 | int i = sizeof ((int));
  |~  ^
  |   )

Other C++ compilers as well as GCC's C front end handle this more gracefully. 
They print just a single message along the lines of:

t.C:1:22: error: expected expression before ‘)’ token

[Bug target/87690] [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI

[wilson at gcc dot gnu.org]

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

--- Comment #3 from Jim Wilson  ---
As far as I know, combined tree builds for RISC-V have never worked.  When
using a combined tree build, configure makes assumptions about gas/ld features
instead of doing run-time gas/ld checks.  Because of our reliance on link time
optimization to reduce code size, we can't support some uses of
.uleb128/.sleb128 that expect code label differences to resolve to a constant,
since this is not a constant at assembly time for RISC-V.  The result is that
the combined tree build gas/ld feature assumptions are wrong, and the build
fails.  I haven't tried to fix this as combined tree builds are obsolete and
not recommended practice anymore.

I have been using the github riscv/riscv-gnu-toolchain for cross builds.  I use
git remote add to add in the FSF git trees I want.  You can do something like
this
git remote add upstream git://gcc.gnu.org/git/gcc.git
git fetch upstream
git checkout -b upstream-trunk --track upstream/trunk
You can do the same thing with binutils using
git://sourceware.org/git/binutils-gdb.git and master instead of trunk.

Another option is to use crosstool-NG.

[Bug target/87702] [6/7/8/9 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #4)
> Program received signal SIGSEGV, Segmentation fault.
> _IO_vfscanf_internal (s=0xc068, format=0x80ae357
> "%llu%llu%u%u%u%u%u%u%llu%llu%u%u%u%u%u%u", 
> argptr=0xc140
> "\354\273\v\bܻ\v\b\374\273\v\b\004\274\v\b,
> \274\v\b(\274\v\b\020\274\v\b\f\274\v\b\364\273\v\b\344\273\v\b", errp=0x0)
> at vfscanf.c:2447
> warning: Source file is more recent than executable.
> 2447*ARG (float *) = negative ? -d : d;
> (gdb) list
> 2442  else
> 2443{
> 2444  float d = __strtof_internal
> 2445(char_buffer_start (), , flags & GROUP);
> 2446  if (!(flags & SUPPRESS) && tw != char_buffer_start
> ())
> 2447*ARG (float *) = negative ? -d : d;
> 2448}
> 2449
> 2450  if (__glibc_unlikely (tw == char_buffer_start ()))
> 2451conv_error ();

Also here, please provide preprocessed source of vfscanf.c from the build and
exact compile flags that will generate the failing assembly.

[Bug target/87702] [6/7/8/9 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #4)

> Program received signal SIGSEGV, Segmentation fault.
> 0xf7e24064 in __run_exit_handlers (status=1, listp=0xf7fca3fc
> <__exit_funcs>, run_list_atexit=true, run_dtors=true)
> at exit.c:114
> warning: Source file is more recent than executable.
> 114   if (__glibc_unlikely (new_exitfn_called !=
> __new_exitfn_called))
> 
> (gdb) list
> 109   break;
> 110 }
> 111   /* Re-lock again before looking at global state.  */
> 112   __libc_lock_lock (__exit_funcs_lock);
> 113
> 114   if (__glibc_unlikely (new_exitfn_called !=
> __new_exitfn_called))
> 115 /* The last exit function, or another thread, has
> registered
> 116more exit functions.  Start the loop over.  */
> 117 goto restart;
> 118 }

Here is what happens:

   0xf7e2405c <+188>:   movq   0x3720(%ebp),%xmm0
2> 0xf7e24064 <+196>:   movdqa (%esp),%xmm1
   0xf7e24069 <+201>:   pxor   %xmm0,%xmm1
   0xf7e2406d <+205>:   movdqa %xmm1,%xmm0
   0xf7e24071 <+209>:   movd   %xmm0,%ecx
   0xf7e24075 <+213>:   psrlq  $0x20,%xmm0
   0xf7e2407a <+218>:   movd   %xmm0,%eax
   0xf7e2407e <+222>:   or %ecx,%eax
   0xf7e24080 <+224>:   jne0xf7e23ffe <__run_exit_handlers+94>
   0xf7e24086 <+230>:   mov0x4(%edi),%ecx
   0xf7e24089 <+233>:   test   %ecx,%ecx
   0xf7e2408b <+235>:   je 0xf7e24110 <__run_exit_handlers+368>
   0xf7e24091 <+241>:   lea-0x1(%ecx),%eax
   0xf7e24094 <+244>:   mov0x3724(%ebp),%edx
   0xf7e2409a <+250>:   mov%eax,0x4(%edi)
   0xf7e2409d <+253>:   mov0x3720(%ebp),%eax
1> 0xf7e240a3 <+259>:   mov%edx,0x4(%esp)
   0xf7e240a7 <+263>:   mov%eax,(%esp)

At 1>, new_exitfn_called is copied from __new_exitfn_called to a stack
location. At point 2>, the (unaligned) location is accessed with full 128 bit
movdqa access (which seems wrong, probably movq should be emitted here).

Please provide a preprocessed source of exit.c (the file is called exit.i and
can be generated by adding --save-temps to the compile command that compiled
exit.c) from the build and the exact compile flags that produce the above
assembly.

[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702

[ygribov at gcc dot gnu.org]

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

Yury Gribov  changed:

   What|Removed |Added

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

--- Comment #11 from Yury Gribov  ---
.

[Bug target/87702] [6/7/8/9 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Mihail Zenkov from comment #2)
> > I'm not sure how to reproduce this regressions without rebuilding glibc. But
> > I can provide prebuilded glibc for test.
> > 
> > http://www.knk.uwebweb.com/glibc-segfault.tar.xz
> > 
> > To reproduce just unpack and run ./test.sh. You should see:
> > 
> > ./test.sh
> > Regression 1
> > busybox   ld.so libc_regression_1.so 
> > libc_regression_2.so  test.sh
> > BusyBox v1.29.3 (2018-10-18 20:28:02 BY) multi-call binary.
> > 
> > Usage: rm [-irf] FILE...
> > 
> > Remove (unlink) FILEs
> > 
> > -i  Always prompt before removing
> > -f  Never prompt
> > -R,-r   Recurse
> > Segmentation fault
> 
> This one is unaligned access in function __run_exit_handlers:
> 
>0xf7e2404d <+173>:   je 0xf7e24050 <__run_exit_handlers+176>
>0xf7e2404f <+175>:   lock cmpxchg %ecx,(%esi)
>0xf7e24053 <+179>:   je 0xf7e2405c <__run_exit_handlers+188>
>0xf7e24055 <+181>:   lea(%esi),%ecx
>0xf7e24057 <+183>:   call   0xf7efd6b0 <__lll_lock_wait_private>
>0xf7e2405c <+188>:   movq   0x3720(%ebp),%xmm0
> => 0xf7e24064 <+196>:   movdqa (%esp),%xmm1
>0xf7e24069 <+201>:   pxor   %xmm0,%xmm1
>0xf7e2406d <+205>:   movdqa %xmm1,%xmm0
>0xf7e24071 <+209>:   movd   %xmm0,%ecx
>0xf7e24075 <+213>:   psrlq  $0x20,%xmm0
>0xf7e2407a <+218>:   movd   %xmm0,%eax
>0xf7e2407e <+222>:   or %ecx,%eax
>0xf7e24080 <+224>:   jne0xf7e23ffe <__run_exit_handlers+94>
> 
> (gdb) p $esp
> $1 = (void *) 0xc3c8

Program received signal SIGSEGV, Segmentation fault.
0xf7e24064 in __run_exit_handlers (status=1, listp=0xf7fca3fc <__exit_funcs>,
run_list_atexit=true, run_dtors=true)
at exit.c:114
warning: Source file is more recent than executable.
114   if (__glibc_unlikely (new_exitfn_called !=
__new_exitfn_called))

(gdb) list
109   break;
110 }
111   /* Re-lock again before looking at global state.  */
112   __libc_lock_lock (__exit_funcs_lock);
113
114   if (__glibc_unlikely (new_exitfn_called !=
__new_exitfn_called))
115 /* The last exit function, or another thread, has
registered
116more exit functions.  Start the loop over.  */
117 goto restart;
118 }

> 
> > 
> > Regression 2
> > busybox   ld.so libc_regression_1.so 
> > libc_regression_2.so  test.sh
> > Segmentation fault
> 
> This one is in function _IO_vfscanf_internal:
> 
>0xf7e6fe26 <+326>:   movaps -0x5f210(%ecx),%xmm1
>0xf7e6fe2d <+333>:   movapd -0x5f280(%ecx),%xmm2
>0xf7e6fe35 <+341>:   mov%esi,-0x5b0(%ebp)
>0xf7e6fe3b <+347>:   movl   $0x0,-0x5b4(%ebp)
> => 0xf7e6fe45 <+357>:   movaps %xmm1,-0x5e8(%ebp)
>0xf7e6fe4c <+364>:   movl   $0x0,-0x594(%ebp)
>0xf7e6fe56 <+374>:   movl   $0x0,-0x5bc(%ebp)
>0xf7e6fe60 <+384>:   movl   $0x0,-0x5c8(%ebp)
> 
> (gdb) p $ebp
> $1 = (void *) 0xc040

Program received signal SIGSEGV, Segmentation fault.
_IO_vfscanf_internal (s=0xc068, format=0x80ae357
"%llu%llu%u%u%u%u%u%u%llu%llu%u%u%u%u%u%u", 
argptr=0xc140
"\354\273\v\bܻ\v\b\374\273\v\b\004\274\v\b,\274\v\b(\274\v\b\020\274\v\b\f\274\v\b\364\273\v\b\344\273\v\b",
errp=0x0) at vfscanf.c:2447
warning: Source file is more recent than executable.
2447*ARG (float *) = negative ? -d : d;
(gdb) list
2442  else
2443{
2444  float d = __strtof_internal
2445(char_buffer_start (), , flags & GROUP);
2446  if (!(flags & SUPPRESS) && tw != char_buffer_start
())
2447*ARG (float *) = negative ? -d : d;
2448}
2449
2450  if (__glibc_unlikely (tw == char_buffer_start ()))
2451conv_error ();

[Bug c++/87712] class template argument deduction fails with wrapped parentheses

[barry.revzin at gmail dot com]

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

--- Comment #3 from Barry Revzin  ---
Didn't realize the OP had filed a bug report already.

[Bug target/87702] [6/7/8/9 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Mihail Zenkov from comment #2)
> I'm not sure how to reproduce this regressions without rebuilding glibc. But
> I can provide prebuilded glibc for test.
> 
> http://www.knk.uwebweb.com/glibc-segfault.tar.xz
> 
> To reproduce just unpack and run ./test.sh. You should see:
> 
> ./test.sh
> Regression 1
> busybox   ld.so libc_regression_1.so 
> libc_regression_2.so  test.sh
> BusyBox v1.29.3 (2018-10-18 20:28:02 BY) multi-call binary.
> 
> Usage: rm [-irf] FILE...
> 
> Remove (unlink) FILEs
> 
> -i  Always prompt before removing
> -f  Never prompt
> -R,-r   Recurse
> Segmentation fault

This one is unaligned access in function __run_exit_handlers:

   0xf7e2404d <+173>:   je 0xf7e24050 <__run_exit_handlers+176>
   0xf7e2404f <+175>:   lock cmpxchg %ecx,(%esi)
   0xf7e24053 <+179>:   je 0xf7e2405c <__run_exit_handlers+188>
   0xf7e24055 <+181>:   lea(%esi),%ecx
   0xf7e24057 <+183>:   call   0xf7efd6b0 <__lll_lock_wait_private>
   0xf7e2405c <+188>:   movq   0x3720(%ebp),%xmm0
=> 0xf7e24064 <+196>:   movdqa (%esp),%xmm1
   0xf7e24069 <+201>:   pxor   %xmm0,%xmm1
   0xf7e2406d <+205>:   movdqa %xmm1,%xmm0
   0xf7e24071 <+209>:   movd   %xmm0,%ecx
   0xf7e24075 <+213>:   psrlq  $0x20,%xmm0
   0xf7e2407a <+218>:   movd   %xmm0,%eax
   0xf7e2407e <+222>:   or %ecx,%eax
   0xf7e24080 <+224>:   jne0xf7e23ffe <__run_exit_handlers+94>

(gdb) p $esp
$1 = (void *) 0xc3c8

> 
> Regression 2
> busybox   ld.so libc_regression_1.so 
> libc_regression_2.so  test.sh
> Segmentation fault

This one is in function _IO_vfscanf_internal:

   0xf7e6fe26 <+326>:   movaps -0x5f210(%ecx),%xmm1
   0xf7e6fe2d <+333>:   movapd -0x5f280(%ecx),%xmm2
   0xf7e6fe35 <+341>:   mov%esi,-0x5b0(%ebp)
   0xf7e6fe3b <+347>:   movl   $0x0,-0x5b4(%ebp)
=> 0xf7e6fe45 <+357>:   movaps %xmm1,-0x5e8(%ebp)
   0xf7e6fe4c <+364>:   movl   $0x0,-0x594(%ebp)
   0xf7e6fe56 <+374>:   movl   $0x0,-0x5bc(%ebp)
   0xf7e6fe60 <+384>:   movl   $0x0,-0x5c8(%ebp)

(gdb) p $ebp
$1 = (void *) 0xc040

So, the best way to proceed is to isolate mentioned functions and feed them
with some test data to prepare a failing runtime testcase. Please also post
preprocessed source of failing functions, so we can see where unaligned access
comes from.

[Bug c++/87709] c++17 class template argument deduction not working in a very specific case

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

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

[Bug c++/87712] class template argument deduction fails with wrapped parentheses

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Looks almost identical.

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

[Bug c++/87712] class template argument deduction fails with wrapped parentheses

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This is likely a dup of 87709.

[Bug c++/87712] New: class template argument deduction fails with wrapped parentheses

[barry.revzin at gmail dot com]

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

Bug ID: 87712
   Summary: class template argument deduction fails with wrapped
parentheses
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Reduced from https://stackoverflow.com/q/52950967/2069064:

template 
struct lit {
lit(T );
};

template 
void operator+(lit, int);

int main() {
auto a = lit('b');// ok
auto b = (lit('b'));  // ok
lit('b') + 1; // ok
(lit('b')) + 1;   // error: missing template arguments after 'lit'
(lit('b') + 1);   // ok
}

[Bug c++/87699] Implement CWG 1512

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81453

--- Comment #2 from Martin Sebor  ---
I raised bug 81453 for this against the C front end, but only to move the
warning GCC issues with -Wextra to -Wall.

[Bug debug/86687] Wrong debug information for string types passed as parameters

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #18 from Tom de Vries  ---
patch with test-case committed to trunk, backported to release branches 6,7,8.

Marking resolved-fixed.

[Bug debug/86687] Wrong debug information for string types passed as parameters

[vries at gcc dot gnu.org]

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

--- Comment #17 from Tom de Vries  ---
Author: vries
Date: Tue Oct 23 17:16:55 2018
New Revision: 265431

URL: https://gcc.gnu.org/viewcvs?rev=265431=gcc=rev
Log:
backport "[c++] Fix DECL_BY_REFERENCE of clone parms"

Consider test.C compiled at -O0 -g:
...
class string {
public:
  string (const char *p) { this->p = p ; }
  string (const string ) { this->p = s.p; }

private:
  const char *p;
};

class foo {
public:
  foo (string dir_hint) {}
};

int
main (void)
{
  std::string s = "This is just a string";
  foo bar(s);
  return 0;
}
...

When parsing foo::foo, the dir_hint parameter gets a DECL_ARG_TYPE of
'struct string & restrict'.  Then during finish_struct, we call
clone_constructors_and_destructors and create clones for foo::foo, and
set the DECL_ARG_TYPE in the same way.

Later on, during finish_function, cp_genericize is called for the original
foo::foo, which sets the type of parm dir_hint to DECL_ARG_TYPE, and sets
DECL_BY_REFERENCE of dir_hint to 1.

After that, during maybe_clone_body update_cloned_parm is called with:
...
(gdb) call debug_generic_expr (parm.typed.type)
struct string & restrict
(gdb) call debug_generic_expr (cloned_parm.typed.type)
struct string
...
The type of the cloned_parm is then set to the type of parm, but
DECL_BY_REFERENCE is not set.

When doing cp_genericize for the clone later on,
TREE_ADDRESSABLE (TREE_TYPE ()) is no longer true for the updated type for
the parm, so DECL_BY_REFERENCE is not set there either.

The missing DECL_BY_REFERENCE on cloned_parm causes incorrect debug info to be
generated.

This patch fixes the problem by copying DECL_BY_REFERENCE in
update_cloned_parm.

Bootstrapped and reg-tested on x86_64.

2018-10-23  Tom de Vries  

backport from trunk:
2018-07-31  Tom de Vries  

PR debug/86687
* optimize.c (update_cloned_parm): Copy DECL_BY_REFERENCE.

* g++.dg/guality/pr86687.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/guality/pr86687.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/optimize.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/87702] [6/7/8/9 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)

[mihail.zenkov at gmail dot com]

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

--- Comment #2 from Mihail Zenkov  ---
I'm not sure how to reproduce this regressions without rebuilding glibc. But I
can provide prebuilded glibc for test.

http://www.knk.uwebweb.com/glibc-segfault.tar.xz

To reproduce just unpack and run ./test.sh. You should see:

./test.sh
Regression 1
busybox   ld.so libc_regression_1.so 
libc_regression_2.so  test.sh
BusyBox v1.29.3 (2018-10-18 20:28:02 BY) multi-call binary.

Usage: rm [-irf] FILE...

Remove (unlink) FILEs

-i  Always prompt before removing
-f  Never prompt
-R,-r   Recurse
Segmentation fault


Regression 2
busybox   ld.so libc_regression_1.so 
libc_regression_2.so  test.sh
Segmentation fault

[Bug fortran/87711] New: ICE in gfc_trans_transfer, at fortran/trans-io.c:2676

[gs...@t-online.de]

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

Bug ID: 87711
   Summary: ICE in gfc_trans_transfer, at fortran/trans-io.c:2676
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least 5 :


$ cat z1.f90
program p
   character(3) :: c(2) = ['abc', 'xyz']
   print *, len_trim(c, 4)
end


$ cat z2.f90
program p
   character(3) :: c(2) = ['abc', 'xyz']
   print *, len_trim(c, 8)
end


$ gfortran-9-20181021 -c z1.f90
z1.f90:3:0:

3 |print *, len_trim(c, 4)
  |
internal compiler error: in gfc_trans_transfer, at fortran/trans-io.c:2676
0x718686 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2676
0x6bdbc7 trans_code
../../gcc/fortran/trans.c:2038
0x715dae build_dt
../../gcc/fortran/trans-io.c:2026
0x6bdba7 trans_code
../../gcc/fortran/trans.c:2010
0x6e51c4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6505
0x673426 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x673426 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6ba3ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[gs...@t-online.de]

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

--- Comment #19 from G. Steinmetz  ---

Adding a "parameter" attribute :


$ cat z8.f90
program p
   type t
  real :: a
  real :: b = 2.0
   end type
   type(t), parameter :: z = t(4.0, 5.0)
   data z%a /3.0/
end


$ cat z9.f90
program p
   type t
  real :: a
   end type
   type(t), parameter :: z = t(4.0)
   data z%a /3.0/
end


$ gfortran-9-20181021 -c z9.f90
z9.f90:7:0:

7 | end
  |
internal compiler error: Segmentation fault
0xb1c86f crash_signal
../../gcc/toplev.c:325
0x6d9481 check_constant_initializer
../../gcc/fortran/trans-decl.c:5198
0x6d9ef4 gfc_emit_parameter_debug_info
../../gcc/fortran/trans-decl.c:5262
0x6a80f2 do_traverse_symtree
../../gcc/fortran/symbol.c:4151
0x6e53fa gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6671
0x673426 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x673426 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6ba3ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204


Adding "pointer" instead of "parameter" gives pr50410 comment 0.

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[gs...@t-online.de]

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

--- Comment #18 from G. Steinmetz  ---

Update and simplified a bit, ICEs down to at least version 5 :


$ cat z1.f90
module m
   type t
  sequence
  real :: a
  real :: b = 2.0
   end type
   type(t) :: z
   data z%a /3.0/
end


$ cat z2.f90
program p
   type t
  real :: a
  real :: b = 2.0
   end type
   type(t) :: z
   data z%a /3.0/
end


$ gfortran-9-20181021 -c z2.f90
z2.f90:1:0:

1 | program p
  |
internal compiler error: Segmentation fault
0xb1c86f crash_signal
../../gcc/toplev.c:325
0x6ec0cd gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7865
0x6fca91 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:7027
0x6e1647 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1824
0x6e3ec7 generate_local_decl
../../gcc/fortran/trans-decl.c:5596
0x6a80f2 do_traverse_symtree
../../gcc/fortran/symbol.c:4151
0x6e4fe4 generate_local_vars
../../gcc/fortran/trans-decl.c:5796
0x6e4fe4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6440
0x673426 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x673426 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6ba3ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/40678] Using a function as variable: ICE with 4.3, accepts invalid with 4.4/4.5

[gs...@t-online.de]

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

--- Comment #5 from G. Steinmetz  ---


Following program compiles smoothly and runs ...
Invocations of function h need obligatoric parenthesis, and a dummy.
On the other hand, "implicit none" would force variable h to be
explicitly declared.


$ cat z2.f90
module m
   implicit none
contains
   logical function f()
  f = h
   end function
   logical function g()
  g = .not. h
   end function
   logical function h(x)
  logical, intent(in) :: x
  h = .not. x
   end function
end
program p
   use m
   print *, f()
   print *, g()  ! .not. f()
end


$ gfortran-9-20181021-chk -Wall -Wextra -fcheck=all -static-libgfortran -g
z2.f90
$ a.out
 F
 F

[Bug fortran/40678] Using a function as variable: ICE with 4.3, accepts invalid with 4.4/4.5

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #4 from G. Steinmetz  ---

No ICE with versions configured with --enable-checking=yes or =release.


$ cat z1.f90
module m
   implicit none
contains
   subroutine s
  logical :: f
  f = g !()
   end
   logical function g()
  g = .true.
   end
end


$ gfortran-9-20181021-chk -c z1.f90

[Bug c/87710] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list

[dilyan.palauzov at aegee dot org]

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

--- Comment #4 from Дилян Палаузов  ---
Moved to 

for ld.bfd: https://sourceware.org/bugzilla/show_bug.cgi?id=23811
for ld.gold: https://sourceware.org/bugzilla/show_bug.cgi?id=23812

[Bug c/87710] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Jonathan Wakely  ---
GCC has nothing to do with adding DT_NEEDED tags, the linker is responsible for
it (whether ld.bfd or ld.gold).

[Bug c/87710] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list

[dilyan.palauzov at aegee dot org]

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

--- Comment #2 from Дилян Палаузов  ---
I tried this with -fuse-ld=gold and -fuse-ld=bfd .

If you mean the problem is in both ld.bfd and ld.gold, I will report it there.

[Bug c/87710] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The linker is part of binutils. not gcc.

[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue Oct 23 15:55:05 2018
New Revision: 265429

URL: https://gcc.gnu.org/viewcvs?rev=265429=gcc=rev
Log:
PR libstdc++/87704 fix unique_ptr(nullptr_t) constructors

Using a delegating constructor to implement these constructors means
that they instantiate the destructor, which requires the element_type to
be complete. In C++11 and C++14 they were specified to be delegating,
but that was changed as part of LWG 2801 so in C++17 they don't require
a complete type (as was intended all along).

PR libstdc++/87704
* include/bits/unique_ptr.h (unique_ptr::unique_ptr(nullptr_t)): Do
not delegate to default constructor.
(unique_ptr::unique_ptr(nullptr_t)): Likewise.
* testsuite/20_util/unique_ptr/cons/incomplete.cc: New test.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/unique_ptr/cons/incomplete.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/unique_ptr.h

[Bug c++/87709] c++17 class template argument deduction not working in a very specific case

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Oops, I missed the first line of the diagnostic. The error from trunk is:


ctad.cc:11:12: error: missing template arguments after 'lit'
11 | auto r2 = (lit(0)) + lit(0);
   |^~~
ctad.cc:2:8: note: 'template struct lit' declared here
2 | struct lit {
  |^~~

[Bug c++/86439] CTAD with deleted copy constructor fails due to deduction-guide taking by value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-23
 Ever confirmed|0   |1

[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations

[romain.geissler at amadeus dot com]

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

--- Comment #6 from Romain Geissler  ---
Versions of gcc and ld:

> gcc --version
gcc (GCC) 8.2.1 20181011
Copyright (C) 2018 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.

> ld --version
GNU ld (GNU Binutils) 2.31.1.20181011
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations

[romain.geissler at amadeus dot com]

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

--- Comment #5 from Romain Geissler  ---
Reduced test case:

> cat test.c
void f() {}

> cat test2.c
void f();

void g()
{
f();
}

> cat test.ver
{
local: *;
};

> gcc -g -flto -ffat-lto-objects -fPIC -o test.fat-objects.o -c test.c
> gcc -g -flto -ffat-lto-objects -fPIC -o test2.fat-objects.o -c test2.c
> gcc -g -flto -ffat-lto-objects -fPIC -shared -o test.fat-objects.so 
> test.fat-objects.o test2.fat-objects.o -Wl,-version-script=test.ver
> gcc -g -flto -fno-fat-lto-objects -fPIC -o test.slim-objects.o -c test.c
> gcc -g -flto -fno-fat-lto-objects -fPIC -o test2.slim-objects.o -c test2.c
> gcc -g -flto -fno-fat-lto-objects -fPIC -shared -o test.slim-objects.so 
> test.slim-objects.o test2.slim-objects.o -Wl,-version-script=test.ver


> readelf -a test.fat-objects.so|grep ABS
5:  0 NOTYPE  GLOBAL DEFAULT  ABS f  <--- unexpected
symbol here
29:  0 FILELOCAL  DEFAULT  ABS crtstuff.c
37:  0 FILELOCAL  DEFAULT  ABS
40:  0 FILELOCAL  DEFAULT  ABS crtstuff.c
42:  0 FILELOCAL  DEFAULT  ABS
77:  0 FILELOCAL  DEFAULT  ABS

> readelf -a test.slim-objects.so|grep ABS
29:  0 FILELOCAL  DEFAULT  ABS crtstuff.c
37:  0 FILELOCAL  DEFAULT  ABS
40:  0 FILELOCAL  DEFAULT  ABS crtstuff.c
42:  0 FILELOCAL  DEFAULT  ABS
65:  0 FILELOCAL  DEFAULT  ABS

[Bug c++/87709] c++17 class template argument deduction not working in a very specific case

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-23
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed, reduced:

template 
struct lit {
  lit(T) { }
};

template 
int operator+(lit, lit) {
  return 0;
}

auto r2 = (lit(0)) + lit(0);



11 | auto r2 = (lit(0)) + lit(0);
   |^~~
ctad.cc:2:8: note: 'template struct lit' declared here
2 | struct lit {
  |^~~

[Bug c/87710] New: Explicitly mentioned libraries by -lx are not in the DT_NEEDED list

[dilyan.palauzov at aegee dot org]

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

Bug ID: 87710
   Summary: Explicitly mentioned libraries by -lx are not in the
DT_NEEDED list
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

Calling “make install” without DESTDIR after building libc-2.28 calls
eventually glibc-2.28/srcribts/test-installation.pl . It creates the file
test-prg7044.c with content:

#include 
#include 
int main(void) {
  printf ("Your new glibc installation seems to be ok.\n");
  exit (0);
}

Then calls “gcc /src/glibc228/test-prg7044.c -lc -lBrokenLocale -lpthread
-lcrypt -ldl -lgcc_s -lnsl -lutil -lnss_dns -lnss_compat -lmvec -lresolv
-lnss_db -lm -lnss_files -lrt -lnss_hesiod -lanl -o
/src/glibc228/test-prg7044“, and chechs whether „ldd test-prg7044” contains
BrokenLocale.  On my system the comman above invoked with -v prints:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-threads=posix --enable-nls
--disable-multilib --enable-interpreter --with-system-zlib
--enable-libgcj-multifile --enable-languages=all --enable-targets=all
--with-system-unwind --without-x --with-linker-hash-style=gnu --enable-shared
--with-build-config='bootstrap-lto bootstrap-O3'
Thread model: posix
gcc version 7.3.1 20181013 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-o' '/src/glibc228//test-prg7044' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/cc1 -quiet -v -imultiarch
x86_64-linux-gnu /src/glibc228//test-prg7044.c -quiet -dumpbase test-prg7044.c
-mtune=generic -march=x86-64 -auxbase test-prg7044 -version -o /tmp/ccDutEqy.s
GNU C11 (GCC) version 7.3.1 20181013 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20181013, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.19-GMP

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/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C11 (GCC) version 7.3.1 20181013 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20181013, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8ff192ae53ef780b032a40b890e7c233
COLLECT_GCC_OPTIONS='-v' '-o' '/src/glibc228//test-prg7044' '-mtune=generic'
'-march=x86-64'

/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/as
-v --64 -o /tmp/ccZTddK3.o /tmp/ccDutEqy.s
GNU assembler version 2.31.51 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.31.51.20181019
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/libexec/gcc/x86_64-pc-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../x86_64-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/lib/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' '/src/glibc228//test-prg7044' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/collect2 -plugin
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so
-plugin-opt=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccLuMS4y.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 --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o /src/glibc228//test-prg7044
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/crtbegin.o
-L/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1
-L/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../x86_64-linux-gnu

[Bug libstdc++/87527] uniform_real_distribution can't generate the full range of finite floating point numbers

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Oh sorry, you provided that message yourself. That assertion is there to
enforce the precondition you found.

[Bug libstdc++/87527] uniform_real_distribution can't generate the full range of finite floating point numbers

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
$ g++ -D_GLIBCXX_ASSERTIONS uniform_real.cc 
$ ./a.out
a.out: uniform_real.cc:13: int main(): Assertion `x >= low && x < high' failed.

[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Oct 23 15:29:03 2018
New Revision: 265428

URL: https://gcc.gnu.org/viewcvs?rev=265428=gcc=rev
Log:
PR libstdc++/87704 fix unique_ptr(nullptr_t) constructors

Using a delegating constructor to implement these constructors means
that they instantiate the destructor, which requires the element_type to
be complete. In C++11 and C++14 they were specified to be delegating,
but that was changed as part of LWG 2801 so in C++17 they don't require
a complete type (as was intended all along).

PR libstdc++/87704
* include/bits/unique_ptr.h (unique_ptr::unique_ptr(nullptr_t)): Do
not delegate to default constructor.
(unique_ptr::unique_ptr(nullptr_t)): Likewise.
* testsuite/20_util/unique_ptr/cons/incomplete.cc: New test.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/unique_ptr/cons/incomplete.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/unique_ptr.h

[Bug c++/87697] Casting a base class to derived gives no warning

[jynelson at email dot sc.edu]

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

--- Comment #3 from jynelson at email dot sc.edu ---
Created attachment 44884
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44884=edit
Casting unrelated types gives an error

[Bug c++/87697] Casting a base class to derived gives no warning

[jynelson at email dot sc.edu]

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

--- Comment #2 from jynelson at email dot sc.edu ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to jynelson from comment #0)
> > Casting a base class to a derived class gives no warning, even with -Wall
> > -Werror enabled. I've been told on IRC that this sort of cast is undefined
> > behaviour according to spec if neither class is virtual.
> 
> It has nothing to do with whether anything is virtual or not. The relevant
> standard wording is:
> 
>If the object of type “cv1 B” is actually a base class subobject of an
>object of type D, the result refers to the enclosing object of type D.
>Otherwise, the behavior is undefined.

Found this at http://www.open-std.org/jtc1/sc22/open/n2356/expr.html, good to
know it's undefined for sure.

> 
> > If that is the
> > case, it would be nice to have a warning.
> 
> It's only possible to warn when the compiler can statically prove that the
> pointer really isn't pointing to a derived. That's possible in your example
> because it was created right there by the 'new c1' expression, but that is a
> very silly thing to do and surely nobody does it in real code. Generally a
> function just gets passed a pointer to a base class, and can't see its
> construction, so can't tell if the cast is valid or not.

I would argue the compiler is in the best place to statically prove an invalid
downcast,
since it knows the types of every object. I'm not sure how functions relate to
this,
but if it's easier to go by a function's type signature, I think it would be
better
to warn on *any* downcast, and make the developer specifically override that
warning.
Part of the reason I opened the bug is I didn't know this was illegal at first.

> 
> > If that isn't the case, there are several more questions that arise, like
> > `why does c1 have access to c2` and `why can the const value c2::x be
> > accessed without be initialized`?
> 
> It doesn't, because there's no c2 object constructed. Obviously the code is
> silly and broken.

Of course it's silly and broken, it's an example.
In a larger project, where there's an intermediary object defined many lines
away
from this assignment, it would be much easier for this to slip by even with
code review
on the assumption that the original was the correct class.
something like this:

```
c1 original;
// ... a bunch of code ...
// looks reasonable
derived *obj = static_cast(  );
```

This is exacerbated by static cast never giving a warning.
This is OK for integers and floats where downcasts are well-defined,
but for undefined behaviour there should at least be a warning.

I would actually argue it should be an error, the same way
casting completely different types is an error
(https://stackoverflow.com/questions/14380275).
I'll attach some code that compiles (except for the error) as an example.

> 
> I don't think a compiler warning would be worthwhile, because it would only
> warn about code which is obviously wrong by inspection i.e. which should be
> caught by the most cursory code review.

I disagree that that it would have to be cursory.

> The general case can be diagnosed through runtime instrumentation but
> -fsanitize=undefined only gives a runtime error for an invalid static_cast
> involving polymorphic types (because the type identification is linked to
> the vtable).
> 
> -fsanitize=address does diagnose that accessing members of c2 performs an
> out-of-bounds read:
> 

This is useful, but a little obscure, I doubt it's widely used.

RE: Secure Messaging !!

[Hutson, Victoria]

Secure Messaging Notification


You have been sent a secure message by Keystone Human Services.

It has been classified as sensitive and may only be accessed from within this 
Secure Messaging service.

View the message by clicking here:

https://protect-us.mimecast.com/s/P8GbCyPJmPtkM4XTZrW6j


If this is the first time you have received a secure message from this company, 
a password will be emailed to you separately.

If you did not receive your password or are experiencing trouble logging in, 
click here to request a new password:

https://protect-us.mimecast.com/s/fIihCzpxnpU92rghXgKAl

[Bug fortran/87707] actual argument to assumed type dummy argument (i.e. type(*)) cannot have type-bound procedures

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-23
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. AFAIU the standards this requires f2018 and is not yet implemented
in gfortran. The code compiles if I replace type(*) with class(*).

[Bug debug/86687] Wrong debug information for string types passed as parameters

[vries at gcc dot gnu.org]

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

--- Comment #16 from Tom de Vries  ---
Author: vries
Date: Tue Oct 23 15:06:17 2018
New Revision: 265427

URL: https://gcc.gnu.org/viewcvs?rev=265427=gcc=rev
Log:
backport "[c++] Fix DECL_BY_REFERENCE of clone parms"

Consider test.C compiled at -O0 -g:
...
class string {
public:
  string (const char *p) { this->p = p ; }
  string (const string ) { this->p = s.p; }

private:
  const char *p;
};

class foo {
public:
  foo (string dir_hint) {}
};

int
main (void)
{
  std::string s = "This is just a string";
  foo bar(s);
  return 0;
}
...

When parsing foo::foo, the dir_hint parameter gets a DECL_ARG_TYPE of
'struct string & restrict'.  Then during finish_struct, we call
clone_constructors_and_destructors and create clones for foo::foo, and
set the DECL_ARG_TYPE in the same way.

Later on, during finish_function, cp_genericize is called for the original
foo::foo, which sets the type of parm dir_hint to DECL_ARG_TYPE, and sets
DECL_BY_REFERENCE of dir_hint to 1.

After that, during maybe_clone_body update_cloned_parm is called with:
...
(gdb) call debug_generic_expr (parm.typed.type)
struct string & restrict
(gdb) call debug_generic_expr (cloned_parm.typed.type)
struct string
...
The type of the cloned_parm is then set to the type of parm, but
DECL_BY_REFERENCE is not set.

When doing cp_genericize for the clone later on,
TREE_ADDRESSABLE (TREE_TYPE ()) is no longer true for the updated type for
the parm, so DECL_BY_REFERENCE is not set there either.

The missing DECL_BY_REFERENCE on cloned_parm causes incorrect debug info to be
generated.

This patch fixes the problem by copying DECL_BY_REFERENCE in
update_cloned_parm.

Bootstrapped and reg-tested on x86_64.

2018-10-23  Tom de Vries  

backport from trunk:
2018-07-31  Tom de Vries  

PR debug/86687
* optimize.c (update_cloned_parm): Copy DECL_BY_REFERENCE.

* g++.dg/guality/pr86687.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/guality/pr86687.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/optimize.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

Welcome to Keystone Secure Email

[SecureMailer1]

Secure Messaging Password Notification


This is a password notification message for the Keystone Human Services Secure 
Messaging service.

You received this notification for one of the following reasons:

1. You have been sent a secure message.
2. The system administrator has arranged access to the Secure Messaging service 
for you.
3. The system administrator has reset your password.
4. You requested a password reminder.

Please connect to the Secure Messaging service by clicking 
https://protect-us.mimecast.com/s/jlI6CjROnRUPz1MtW8NRi. You may be required to 
change your password immediately following login.

You may be required to change your password immediately following login.

Secure Messaging:
https://protect-us.mimecast.com/s/jlI6CjROnRUPz1MtW8NRi

Login Information:

Email Address: gcc-bugs@gcc.gnu.org

Password: iTRWBVo8

[Bug debug/86687] Wrong debug information for string types passed as parameters

[vries at gcc dot gnu.org]

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

--- Comment #15 from Tom de Vries  ---
Author: vries
Date: Tue Oct 23 15:01:12 2018
New Revision: 265426

URL: https://gcc.gnu.org/viewcvs?rev=265426=gcc=rev
Log:
backport "[c++] Fix DECL_BY_REFERENCE of clone parms"

Consider test.C compiled at -O0 -g:
...
class string {
public:
  string (const char *p) { this->p = p ; }
  string (const string ) { this->p = s.p; }

private:
  const char *p;
};

class foo {
public:
  foo (string dir_hint) {}
};

int
main (void)
{
  std::string s = "This is just a string";
  foo bar(s);
  return 0;
}
...

When parsing foo::foo, the dir_hint parameter gets a DECL_ARG_TYPE of
'struct string & restrict'.  Then during finish_struct, we call
clone_constructors_and_destructors and create clones for foo::foo, and
set the DECL_ARG_TYPE in the same way.

Later on, during finish_function, cp_genericize is called for the original
foo::foo, which sets the type of parm dir_hint to DECL_ARG_TYPE, and sets
DECL_BY_REFERENCE of dir_hint to 1.

After that, during maybe_clone_body update_cloned_parm is called with:
...
(gdb) call debug_generic_expr (parm.typed.type)
struct string & restrict
(gdb) call debug_generic_expr (cloned_parm.typed.type)
struct string
...
The type of the cloned_parm is then set to the type of parm, but
DECL_BY_REFERENCE is not set.

When doing cp_genericize for the clone later on,
TREE_ADDRESSABLE (TREE_TYPE ()) is no longer true for the updated type for
the parm, so DECL_BY_REFERENCE is not set there either.

The missing DECL_BY_REFERENCE on cloned_parm causes incorrect debug info to be
generated.

This patch fixes the problem by copying DECL_BY_REFERENCE in
update_cloned_parm.

Bootstrapped and reg-tested on x86_64.

2018-10-23  Tom de Vries  

backport from trunk:
2018-07-31  Tom de Vries  

PR debug/86687
* optimize.c (update_cloned_parm): Copy DECL_BY_REFERENCE.

* g++.dg/guality/pr86687.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/guality/pr86687.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/optimize.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/87709] New: c++17 class template argument deduction not working in a very specific case

[bmburstein at gmail dot com]

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

Bug ID: 87709
   Summary: c++17 class template argument deduction not working in
a very specific case
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bmburstein at gmail dot com
  Target Milestone: ---

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

The test case is attached. It has no includes and so I am attaching the *.cpp
file as per https://gcc.gnu.org/bugs/

I am compiling with -std=c++17

Output of g++ -v:

# g++ -v
Using built-in specs.
COLLECT_GCC=C:\MyProgs\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/MyProgs/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-8.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev3, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 8.2.0 (Rev3, Built by MSYS2 project)


I tried with another build and got the same results. This one gave:

# g++ -v
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-8.2.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.2.0/configure --prefix=/opt/wandbox/gcc-8.2.0
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-8.2.0/lib,-rpath,/opt/wandbox/gcc-8.2.0/lib64,-rpath,/opt/wandbox/gcc-8.2.0/lib32
--enable-lto
Thread model: posix
gcc version 8.2.0 (GCC)

[Bug rtl-optimization/87708] New: ira-shrinkwrap-prep-[12].c testcases fail after r265398

[segher at gcc dot gnu.org]

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

Bug ID: 87708
   Summary: ira-shrinkwrap-prep-[12].c testcases fail after
r265398
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

These fail on many targets, and simply because the
split_live_ranges_for_shrink_wrap code can only move direct copies from the
hard argument registers, but they now usually are move to a pseudo first.

Ideally this code will improve, but in the meantime, maybe we should xfail
the test?

[Bug fortran/87707] New: actual argument to assumed type dummy argument (i.e. type(*)) cannot have type-bound procedures

[m.diehl at mpie dot de]

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

Bug ID: 87707
   Summary: actual argument to assumed type dummy argument (i.e.
type(*)) cannot have type-bound procedures
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.diehl at mpie dot de
  Target Milestone: ---

gfortran (confirmed for 6.3.0 and 8.2.1) rejects passing in a derived type to a
subroutine with a type(*) dummy argument with the following message:

Error: Actual argument at (1) to assumed-type dummy is of derived type with
type-bound or FINAL procedures

The documentation on
https://www.ibm.com/support/knowledgecenter/SSAT4T_15.1.4/com.ibm.xlf1514.lelinux.doc/language_ref/assumedtypeobj.html
implies that this is the expected behavior (An assumed-type dummy argument
cannot correspond to an actual argument of a derived type that has type
parameters, type-bound procedures, or final subroutines.). However, I cannot
confirm this from https://j3-fortran.org/doc/year/18/18-007r1.pdf. See also the
discussion in the Intel developer zone:
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/798744
(Intel Fortran accepts the code). Probably this restriction was part of an
earlier draft.
I compile with '-std=f2008ts' or '-std=f2018'.

This is my test code (need to be split into 2 files)
program main
  use context_module
  implicit none
  type(context_type) :: context

  call test(context) 

end program main

module context_module

  implicit none

  type ::  context_type
integer, private :: foo

contains
  procedure, public :: init => context_init
   end type context_type

contains

  subroutine context_init(self, foo)
   implicit none
class(context_type), intent(in out) :: self
integer, intent(in) :: foo
self%foo = foo
  end subroutine context_init


 subroutine test(context)
   implicit none
   type(*) :: context
   write(6,*) 'hello world'   
 end subroutine

end module context_module

[Bug libstdc++/87527] uniform_real_distribution can't generate the full range of finite floating point numbers

[fergus.henderson at gmail dot com]

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

Fergus Henderson  changed:

   What|Removed |Added

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

--- Comment #1 from Fergus Henderson  ---
It turns out that this example program is not conforming, because it violates a
requirement.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

29.6.8.2.2 Class template uniform_real_distribution [rand.dist.uni.real]

explicit uniform_real_distribution(RealType a = 0.0, RealType b = 1.0

Requires: a ≤ b and b − a ≤ numeric_limits::max().

The requirement "b − a ≤ numeric_limits::max()." is violated.

[Bug target/87702] [6/7/8/9 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Please provide the (preferrably small) self contained runtime testcase that
exposes the bug. Some instructions can be found on [1].

[1] https://gcc.gnu.org/bugs/

[Bug tree-optimization/87665] [6/7/8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 4b3711442e6..a24e1853e03 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -210,16 +210,26 @@ vect_preserves_scalar_order_p (dr_vec_info *dr_info_a,
dr_vec_info *dr_info_b)
 return true;

   /* STMT_A and STMT_B belong to overlapping groups.  All loads in a
- group are emitted at the position of the first scalar load and all
+ group are emitted at the position of the last scalar load and all
  stores in a group are emitted at the position of the last scalar store.
- Thus writes will happen no earlier than their current position
- (but could happen later) while reads will happen no later than their
- current position (but could happen earlier).  Reordering is therefore
- only possible if the first access is a write.  */
-  stmtinfo_a = vect_orig_stmt (stmtinfo_a);
-  stmtinfo_b = vect_orig_stmt (stmtinfo_b);
-  stmt_vec_info earlier_stmt_info = get_earlier_stmt (stmtinfo_a, stmtinfo_b);
-  return !DR_IS_WRITE (STMT_VINFO_DATA_REF (earlier_stmt_info));
+ Compute that position and check whether the resulting order matches
+ the current one.  */
+  stmt_vec_info last_a = DR_GROUP_FIRST_ELEMENT (stmtinfo_a);
+  if (last_a)
+for (stmt_vec_info s = DR_GROUP_NEXT_ELEMENT (last_a); s;
+s = DR_GROUP_NEXT_ELEMENT (s))
+  last_a = get_later_stmt (last_a, s);
+  else
+last_a = stmtinfo_a;
+  stmt_vec_info last_b = DR_GROUP_FIRST_ELEMENT (stmtinfo_b);
+  if (last_b)
+for (stmt_vec_info s = DR_GROUP_NEXT_ELEMENT (last_b); s;
+s = DR_GROUP_NEXT_ELEMENT (s))
+  last_b = get_later_stmt (last_b, s);
+  else
+last_b = stmtinfo_b;
+  return ((get_later_stmt (last_a, last_b) == last_a)
+ == (get_later_stmt (stmtinfo_a, stmtinfo_b) == stmtinfo_a));
 }

 /* A subroutine of vect_analyze_data_ref_dependence.  Handle

[Bug tree-optimization/87665] [6/7/8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
r229172.

[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Oct 23 13:10:26 2018
New Revision: 265423

URL: https://gcc.gnu.org/viewcvs?rev=265423=gcc=rev
Log:
PR libstdc++/87704 fix unique_ptr(nullptr_t) constructors

Using a delegating constructor to implement these constructors means
that they instantiate the destructor, which requires the element_type to
be complete. In C++11 and C++14 they were specified to be delegating,
but that was changed as part of LWG 2801 so in C++17 they don't require
a complete type (as was intended all along).

PR libstdc++/87704
* include/bits/unique_ptr.h (unique_ptr::unique_ptr(nullptr_t)): Do
not delegate to default constructor.
(unique_ptr::unique_ptr(nullptr_t)): Likewise.
* testsuite/20_util/unique_ptr/cons/incomplete.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/unique_ptr/cons/incomplete.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/unique_ptr.h

[Bug tree-optimization/87665] [6/7/8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work|7.3.0   |5.4.0
   Target Milestone|8.3 |6.5
Summary|[8/9 Regression] gcc HEAD   |[6/7/8/9 Regression] gcc
   |(svn: 265340) breaks|HEAD (svn: 265340) breaks
   |elements on resize  |elements on resize

--- Comment #12 from Richard Biener  ---
GCC 5 works, the rest not.  Somebody bisect again please.

[Bug tree-optimization/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
C testcase that is miscompiled:

struct X { long x; long y; };

struct X a[1024], b[1024];

void foo ()
{
  for (int i = 0; i < 1024; ++i)
{
  long tem = a[i].x;
  a[i].x = 0;
  b[i].x = tem;
  b[i].y = a[i].y;
}
}

int main()
{
  for (int i = 0; i < 1024; ++i)
a[i].x = i;
  foo ();
  for (int i = 0; i < 1024; ++i)
if (b[i].x != i)
  __builtin_abort();
  return 0;
}

[Bug fortran/87705] Compilation error when dealing with sub derived types

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-23
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (9.0). The test compiles with 4.3.6.

Reduced test:

module test_mod

  implicit none

  type :: temp_val_prop
character(len=9):: qlevel ! gfortran compiler error
integer(4)  :: n
  end type temp_val_prop

  type material_data
type(temp_val_prop) :: emodul
  end type

end module test_mod

program main

  use :: test_mod
  implicit none

  type(material_data) :: mat(100)
  data mat(1)%emodul%n /  15 /

end program main

[Bug tree-optimization/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|c++ |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.3

--- Comment #10 from Richard Biener  ---
--param vect-max-version-for-alias-checks=0 also avoids the issue.  So it's

/usr/include/c++/8/bits/stl_uninitialized.h:82:23: note: loop vectorized
/usr/include/c++/8/bits/stl_uninitialized.h:82:23: note: loop versioned for
vectorization because of possible aliasing

that breaks things.  This is vectorizing of

   [local count: 163894221]:
  # __first$_M_current_62 = PHI <_100(82), _84(86)>
  # __cur_12 = PHI 
  MEM[(struct  &)__cur_12] ={v} {CLOBBER};
  MEM[(struct  &)__cur_12] ={v} {CLOBBER};
  _82 = MEM[(int * const &)__first$_M_current_62];
  MEM[(int * &)__first$_M_current_62] = 0B;
  MEM[(struct  &)__cur_12] ={v} {CLOBBER};
  MEM[(struct _Head_base *)__cur_12]._M_head_impl = _82;
  _83 = __first$_M_current_62->second;
  __cur_12->second = _83;
  _84 = __first$_M_current_62 + 16;
  __cur_85 = __cur_12 + 16;
  if (_67 != _84)
goto ; [89.00%]
  else
goto ; [11.00%]

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

where we end up interchanging the read and write from/to MEM[(int * const
&)__first$_M_current_62].  There are SLP and non-SLP stmts here,
the SLP ones being

stl_uninitialized.h:82:23: note: Final SLP tree for instance:
stl_uninitialized.h:82:23: note: node
stl_uninitialized.h:82:23: note:stmt 0 MEM[(struct _Head_base
*)__cur_12]._M_head_impl = _82;
stl_uninitialized.h:82:23: note:stmt 1 __cur_12->second = _83;
stl_uninitialized.h:82:23: note: node
stl_uninitialized.h:82:23: note:stmt 0 _82 = MEM[(int * const
&)__first$_M_current_62];
stl_uninitialized.h:82:23: note:stmt 1 _83 =
__first$_M_current_62->second;

[Bug ipa/87706] Inlined functions trigger invalid -Wmissing-profile warning

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Note that it causes bazillion of warnings for GCC PGO bootstrap.

[Bug ipa/87706] New: Inlined functions trigger invalid -Wmissing-profile warning

[marxin at gcc dot gnu.org]

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

Bug ID: 87706
   Summary: Inlined functions trigger invalid -Wmissing-profile
warning
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Considering following example:

$ cat sra-6.c
int g;

static
void cow (int a, int b)
{
  if (a)
g = 123;
}

int main(int argc, char **argv)
{
  cow (argc, 0);
  return 0;
}

One can see:

$ gcc sra-6.c  -O2 -fprofile-generate -Wall && ./a.out && gcc sra-6.c  -O2
-fprofile-use
sra-6.c: In function ‘cow’:
sra-6.c:4:6: warning: profile for function ‘cow’ not found in profile data
[-Wmissing-profile]
4 | void cow (int a, int b)
  |  ^~~

Problem is the function 'cow' is removed in IPA passes and as IPA profile
happens before it we see the warning.

One possible solution would be to mark all cgraph_nodes with missing profile
and emit warnings later after we have final symbols.

Honza?

[Bug fortran/87705] New: Compilation error when dealing with sub derived types

[peter.gerkens at siemens dot com]

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

Bug ID: 87705
   Summary: Compilation error when dealing with sub derived types
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.gerkens at siemens dot com
  Target Milestone: ---

Created attachment 44882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44882=edit
File "main.f90" contains the module with the dreived type declarations and the
main program containing some data statements.

When using nested derived types the order of the variables in the "sub" derived
type are important, otherwise a compiler error occurs:

mlhw7ahx: /home/gerke00p/Softwaredevelopment/Fortran/gfortran_error_10_2018 >
gfortran -v -save-temps -Wall -Wextra main.f90 -o main
Driving: gfortran -v -save-temps -Wall -Wextra main.f90 -o main -l gfortran -l
m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/gerke00p/Softwaredevelopment/gcc/gcc-8.2.0_bin/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.2.0/configure
--prefix=/home/gerke00p/Softwaredevelopment/gcc/gcc-8.2.0_bin
Thread model: posix
gcc version 8.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-o' 'main'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'

/home/gerke00p/Softwaredevelopment/gcc/gcc-8.2.0_bin/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/f951
main.f90 -quiet -dumpbase main.f90 -mtune=generic -march=x86-64 -auxbase main
-Wall -Wextra -version -fintrinsic-modules-path
/home/gerke00p/Softwaredevelopment/gcc/gcc-8.2.0_bin/lib/gcc/x86_64-pc-linux-gnu/8.2.0/finclude
-o main.s
GNU Fortran (GCC) version 8.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 8.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
main.f90:36:0:

 program main

internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:148
0x5c5a3f gfc_conv_string_init(tree_node*, gfc_expr*)
../../gcc-8.2.0/gcc/fortran/trans-const.c:148
0x70a60f gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-8.2.0/gcc/fortran/trans-expr.c:6958
0x70abb0 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-8.2.0/gcc/fortran/trans-expr.c:7818
0x70a627 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-8.2.0/gcc/fortran/trans-expr.c:6951
0x70abb0 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-8.2.0/gcc/fortran/trans-expr.c:7818
0x6ddcdd gfc_conv_array_initializer(tree_node*, gfc_expr*)
../../gcc-8.2.0/gcc/fortran/trans-array.c:5970
0x70a65a gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-8.2.0/gcc/fortran/trans-expr.c:6916
0x6f4bf2 gfc_get_symbol_decl(gfc_symbol*)
../../gcc-8.2.0/gcc/fortran/trans-decl.c:1835
0x6f7657 generate_local_decl
../../gcc-8.2.0/gcc/fortran/trans-decl.c:5595
0x6bd4c2 do_traverse_symtree
../../gcc-8.2.0/gcc/fortran/symbol.c:4179
0x6f824a generate_local_vars
../../gcc-8.2.0/gcc/fortran/trans-decl.c:5795
0x6f824a gfc_generate_function_code(gfc_namespace*)
../../gcc-8.2.0/gcc/fortran/trans-decl.c:6442
0x688e46 translate_all_program_units
../../gcc-8.2.0/gcc/fortran/parse.c:6125
0x688e46 gfc_parse_file()
../../gcc-8.2.0/gcc/fortran/parse.c:6328
0x6cf25f gfc_be_parse_file
../../gcc-8.2.0/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Correction, on both x86_64 and ppc64le it requires all of:

-fstrict-aliasing  -ftree-loop-vectorize -ftree-sra -ftree-ch -ftree-forwprop
-ftree-copy-prop

[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #8 from Ville Voutilainen  ---
It seems that either -fno-strict-aliasing or -march=native makes it work. That
bears a *striking* similarity to the symptoms seen in
https://bugreports.qt.io/browse/QTBUG-69388 !

[Bug tree-optimization/87608] Very slow swap operations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/87105] Autovectorization [X86, SSE2, AVX2, DoublePrecision]

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
The code is now better but not vectorized due to mentioned issues.

[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
On x86_64 it fails with -O1 -fstrict-aliasing -ftree-loop-vectorize

It still fails if every -fno-xxx option for -O1 is added except
-fno-tree-copy-prop so it seems to require:

 -fstrict-aliasing -ftree-loop-vectorize -ftree-copy-prop

On ppc64le it also fails with -O1 -fstrict-aliasing -ftree-loop-vectorize but
-ftree-copy-prop isn't the only -O1 pass that matters, several of the -O1
passes are needed to cause the bug (including at least -ftree-copy-prop 
-ftree-ch -ftree-forwprop but also others I haven't isolated).

[Bug tree-optimization/87105] Autovectorization [X86, SSE2, AVX2, DoublePrecision]

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 23 11:34:56 2018
New Revision: 265421

URL: https://gcc.gnu.org/viewcvs?rev=265421=gcc=rev
Log:
2018-10-23  Richard Biener  

PR tree-optimization/87105
PR tree-optimization/87608
* passes.def (pass_all_early_optimizations): Add early phi-opt
after dce.
* tree-ssa-phiopt.c (value_replacement): Ignore NOPs and predicts in
addition to debug stmts.
(tree_ssa_phiopt_worker): Add early_p argument, do only min/max
and abs replacement early.
* tree-cfg.c (gimple_empty_block_p): Likewise.

* g++.dg/tree-ssa/phiopt-1.C: New testcase.
g++.dg/vect/slp-pr87105.cc: Likewise.
* g++.dg/tree-ssa/pr21463.C: Scan phiopt2 because this testcase
relies on phiprop run before.
* g++.dg/tree-ssa/pr30738.C: Likewise.
* g++.dg/tree-ssa/pr57380.C: Likewise.
* gcc.dg/tree-ssa/pr84859.c: Likewise.
* gcc.dg/tree-ssa/pr45397.c: Scan phiopt2 because phiopt1 is
confused by copies in the IL left by EVRP.
* gcc.dg/tree-ssa/phi-opt-5.c: Likewise, this time confused
by predictors.
* gcc.dg/tree-ssa/phi-opt-12.c: Scan phiopt2.
* gcc.dg/pr24574.c: Likewise.
* g++.dg/tree-ssa/pr86544.C: Scan phiopt4.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/phiopt-1.C
trunk/gcc/testsuite/g++.dg/vect/slp-pr87105.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr21463.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr30738.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr57380.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr86544.C
trunk/gcc/testsuite/gcc.dg/pr24574.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20040514-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20040518-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-12.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/popcount3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr45397.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr84859.c
trunk/gcc/testsuite/gcc.dg/uninit-15.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-ssa-phiopt.c

[Bug tree-optimization/87608] Very slow swap operations

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 23 11:34:56 2018
New Revision: 265421

URL: https://gcc.gnu.org/viewcvs?rev=265421=gcc=rev
Log:
2018-10-23  Richard Biener  

PR tree-optimization/87105
PR tree-optimization/87608
* passes.def (pass_all_early_optimizations): Add early phi-opt
after dce.
* tree-ssa-phiopt.c (value_replacement): Ignore NOPs and predicts in
addition to debug stmts.
(tree_ssa_phiopt_worker): Add early_p argument, do only min/max
and abs replacement early.
* tree-cfg.c (gimple_empty_block_p): Likewise.

* g++.dg/tree-ssa/phiopt-1.C: New testcase.
g++.dg/vect/slp-pr87105.cc: Likewise.
* g++.dg/tree-ssa/pr21463.C: Scan phiopt2 because this testcase
relies on phiprop run before.
* g++.dg/tree-ssa/pr30738.C: Likewise.
* g++.dg/tree-ssa/pr57380.C: Likewise.
* gcc.dg/tree-ssa/pr84859.c: Likewise.
* gcc.dg/tree-ssa/pr45397.c: Scan phiopt2 because phiopt1 is
confused by copies in the IL left by EVRP.
* gcc.dg/tree-ssa/phi-opt-5.c: Likewise, this time confused
by predictors.
* gcc.dg/tree-ssa/phi-opt-12.c: Scan phiopt2.
* gcc.dg/pr24574.c: Likewise.
* g++.dg/tree-ssa/pr86544.C: Scan phiopt4.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/phiopt-1.C
trunk/gcc/testsuite/g++.dg/vect/slp-pr87105.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr21463.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr30738.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr57380.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr86544.C
trunk/gcc/testsuite/gcc.dg/pr24574.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20040514-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20040518-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-12.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/popcount3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr45397.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr84859.c
trunk/gcc/testsuite/gcc.dg/uninit-15.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-ssa-phiopt.c

[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
C++17 doesn't have the defect, it appears to have been fixed as an unintended
consequence of https://wg21.link/lwg2801

[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-10-23
  Known to work||4.7.4
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.0, 4.8.5, 4.9.4, 5.5.0,
   ||6.4.0, 7.3.0, 8.2.0, 9.0

[Bug libstdc++/87704] New: [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

Bug ID: 87704
   Summary: [6/7/8/9 Regression] unique_ptr(nullptr_t) requires
T to be complete
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

struct Incomplete;

void f(void* p)
{
  ::new (p) std::unique_ptr();  // OK

  ::new (p) std::unique_ptr(nullptr);   // ERROR
}

This fails because the unique_ptr(nullptr_t) constructor is implemented
precisely as specified in C++11 and C++14:

  constexpr unique_ptr(nullptr_t) noexcept
: unique_ptr() { }

The use of a delegating constructor means that the destructor is odr-used which
invokes default_delete::operator() which is ill-formed if T is incomplete.

The example compiled until r194651 but fails in all versions since 4.8.0

The same problem exists for the unique_ptr specialization, but not for
shared_ptr(nullptr) because that doesn't create a control block so doesn't
instantiate a deleter.

[Bug target/87702] [6/7/8/9 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
  Component|rtl-optimization|target
  Known to work||4.9.4
Version|unknown |8.2.0
   Target Milestone|--- |6.5
Summary|[5/6/7/8 Regression]|[6/7/8/9 Regression]
   |Segfault in glibc if|Segfault in glibc if
   |compiled with   |compiled with
   |-march=amdfam10 -O2 (x86)   |-march=amdfam10 -O2 (x86)

[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Tue, 23 Oct 2018, jozef.l at mittosystems dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691
> 
> --- Comment #7 from Jozef Lawrynowicz  ---
> (In reply to Richard Biener from comment #6)
> > 
> > I think it's better to, at this place, simply allow MODE_INT or
> > MODE_PARTIAL_INT
> > for unions.  Allowing MODE_INT is what we'd fall back to anyways and you
> > want to allow MODE_PARTIAL_INT which is already allowed for RECORD_TYPEs.
> > 
> > What I'm not sure is if the target is happy about, say,
> > 
> > union U { float f; __int20 i; };
> > 
> > float foo()
> > {
> >   union U u;
> >   u.i = 10;
> >   return u.f;
> > }
> > 
> > iff we were to put u into a MODE_PARTIAL_INT register are targets to be
> > expected to be able to extract a MODE_FLOAT from it or are we going
> > to spill here anyways?
> 
> I tweaked the above source a little:
> 
> float foo(union U u)
> {
>   u.i = u.i + 10;
>   return u.f;
> }
> 
> For this, GCC fills u.i then spills after modifying it. I therefore assume in
> general that if u.f is alive then modifications to u.i will always be spilled
> after.
> 
> > How is TYPE_SIZE / GET_MODE_BITSIZE of this union anyways?  The loop
> > in stor-layout checks TYPE_SIZE vs. DECL_SIZE - is DECL_SIZE always
> > matching GET_MODE_BITSIZE?
> 
> It actually depends on the order of the fields in the union, which is not 
> good.
> Since __int20 and float have the same BITSIZE, the mode of the last field in
> the union will be used for the mode of the union. So for the above code with 
> my
> current patch, the union TYPE_MODE is PSImode. This causes wrong code to be
> generated, as the function foo starts by only pushing the __int20 value of the
> union onto the stack, rather than the full 32-bits.
> 
> I had the following additional patch which didn't seem to affect the
> testresults, but fixes this issue so is clearly beneficial:
> 
> diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> index 6449f16..3bb0bbc 100644
> --- a/gcc/stor-layout.c
> +++ b/gcc/stor-layout.c
> @@ -1834,7 +1834,13 @@ compute_record_mode (tree type)
>/* If this field is the whole struct, remember its mode so
>  that, say, we can put a double in a class into a DF
>  register instead of forcing it to live in the stack.  */
> -  if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field)))
> +  if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field))
> + /* Partial int types (e.g. __int20) may have TYPE_SIZE equal to
> +wider types (e.g. int32), despite precision being less.  Ensure
> +that the TYPE_MODE of the struct does not get set to the partial
> +int mode if there is a wider type also in the struct.  */
> + && known_gt (GET_MODE_PRECISION (DECL_MODE (field)),
> +  GET_MODE_PRECISION (mode)))
> mode = DECL_MODE (field);
> 
>/* With some targets, it is sub-optimal to access an aligned
> 
> This fixes the above issue, so the union TYPE_MODE is always SFmode, 
> regardless
> of the ordering of the fields.

That makes sense.

[Bug ada/87688] [9 regression] ACATS cb1010a cb1010d failure

[simon at pushface dot org]

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

--- Comment #4 from simon at pushface dot org ---
Eric is right: r264896 (OK), r264897 (FAIL).

[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT

[jozef.l at mittosystems dot com]

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

--- Comment #7 from Jozef Lawrynowicz  ---
(In reply to Richard Biener from comment #6)
> 
> I think it's better to, at this place, simply allow MODE_INT or
> MODE_PARTIAL_INT
> for unions.  Allowing MODE_INT is what we'd fall back to anyways and you
> want to allow MODE_PARTIAL_INT which is already allowed for RECORD_TYPEs.
> 
> What I'm not sure is if the target is happy about, say,
> 
> union U { float f; __int20 i; };
> 
> float foo()
> {
>   union U u;
>   u.i = 10;
>   return u.f;
> }
> 
> iff we were to put u into a MODE_PARTIAL_INT register are targets to be
> expected to be able to extract a MODE_FLOAT from it or are we going
> to spill here anyways?

I tweaked the above source a little:

float foo(union U u)
{
  u.i = u.i + 10;
  return u.f;
}

For this, GCC fills u.i then spills after modifying it. I therefore assume in
general that if u.f is alive then modifications to u.i will always be spilled
after.

> How is TYPE_SIZE / GET_MODE_BITSIZE of this union anyways?  The loop
> in stor-layout checks TYPE_SIZE vs. DECL_SIZE - is DECL_SIZE always
> matching GET_MODE_BITSIZE?

It actually depends on the order of the fields in the union, which is not good.
Since __int20 and float have the same BITSIZE, the mode of the last field in
the union will be used for the mode of the union. So for the above code with my
current patch, the union TYPE_MODE is PSImode. This causes wrong code to be
generated, as the function foo starts by only pushing the __int20 value of the
union onto the stack, rather than the full 32-bits.

I had the following additional patch which didn't seem to affect the
testresults, but fixes this issue so is clearly beneficial:

diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index 6449f16..3bb0bbc 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -1834,7 +1834,13 @@ compute_record_mode (tree type)
   /* If this field is the whole struct, remember its mode so
 that, say, we can put a double in a class into a DF
 register instead of forcing it to live in the stack.  */
-  if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field)))
+  if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field))
+ /* Partial int types (e.g. __int20) may have TYPE_SIZE equal to
+wider types (e.g. int32), despite precision being less.  Ensure
+that the TYPE_MODE of the struct does not get set to the partial
+int mode if there is a wider type also in the struct.  */
+ && known_gt (GET_MODE_PRECISION (DECL_MODE (field)),
+  GET_MODE_PRECISION (mode)))
mode = DECL_MODE (field);

   /* With some targets, it is sub-optimal to access an aligned

This fixes the above issue, so the union TYPE_MODE is always SFmode, regardless
of the ordering of the fields.