[Bug target/84081] gcc.target/i386/avx512bitalg-vpopcntb-1.c etc. FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/84081] New: gcc.target/i386/avx512bitalg-vpopcntb-1.c etc. FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 84081
   Summary: gcc.target/i386/avx512bitalg-vpopcntb-1.c etc. FAIL
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jkoval at gcc dot gnu.org, kyukhin at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*, x86_64-*-*

When I switched from gas 2.29 to 2.30, three avx512bitalg tests started to
FAIL:

+FAIL: gcc.target/i386/avx512bitalg-vpopcntb-1.c (test for excess errors)
+WARNING: gcc.target/i386/avx512bitalg-vpopcntb-1.c compilation failed to
produce executable
+FAIL: gcc.target/i386/avx512bitalg-vpopcntw-1.c (test for excess errors)
+WARNING: gcc.target/i386/avx512bitalg-vpopcntw-1.c compilation failed to
produce executable
+FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c (test for excess errors)
+WARNING: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c compilation failed to
produce executable

/var/gcc/regression/trunk/11.4-gcc-gas/build/gcc/include/avx512bitalgintrin.h:73:1:
error: inlining failed in call to always_inline '_mm512_maskz_popcnt_epi8':
target specific option mismatch
/var/gcc/regression/trunk/11.4-gcc-gas/build/gcc/include/avx512bitalgintrin.h:64:1:
error: inlining failed in call to always_inline '_mm512_mask_popcnt_epi8':
target specific option mismatch
/var/gcc/regression/trunk/11.4-gcc-gas/build/gcc/include/avx512bitalgintrin.h:73:1:
error: inlining failed in call to always_inline '_mm512_maskz_popcnt_epi8':
target specific option mismatch
/var/gcc/regression/trunk/11.4-gcc-gas/build/gcc/include/avx512bitalgintrin.h:64:1:
error: inlining failed in call to always_inline '_mm512_mask_popcnt_epi8':
target specific option mismatch
/var/gcc/regression/trunk/11.4-gcc-gas/build/gcc/include/avx512bitalgintrin.h:73:1:
error: inlining failed in call to always_inline '_mm512_maskz_popcnt_epi8':
target specific option mismatch
/var/gcc/regression/trunk/11.4-gcc-gas/build/gcc/include/avx512bitalgintrin.h:64:1:
error: inlining failed in call to always_inline '_mm512_mask_popcnt_epi8':
target specific option mismatch

With gas 2.29 they were UNSUPPORTED.  I'm seeing this on i386-pc-solaris2.11,
but there are gcc-testsuite results for i686-pc-linux-gnu and
x86_64-pc-linux-gnu,
too.

  Rainer

[Bug c++/84082] New: [7/8 Regression] ICE with broken template function definition

[reichelt at gcc dot gnu.org]

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

Bug ID: 84082
   Summary: [7/8 Regression] ICE with broken template function
definition
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The follwong invalid code snippet triggers an ICE since GCC 7.1.0:


struct A;

template void foo()
[
  A().operator=(A());
]


bug.cc:5:3: warning: invalid use of incomplete type 'struct A'
   A().operator=(A());
   ^~~
bug.cc:1:8: note: forward declaration of 'struct A'
 struct A;
^
bug.cc:5:20: internal compiler error: Segmentation fault
   A().operator=(A());
^
0xeab52f crash_signal
../../gcc/gcc/toplev.c:325
0x8555b2 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x8555b2 potential_constant_expression_1
../../gcc/gcc/cp/constexpr.c:5672
0x8560c8 potential_constant_expression_1
../../gcc/gcc/cp/constexpr.c:5309
0x90fc07 cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:9736
0x9229e2 cp_parser_direct_declarator
../../gcc/gcc/cp/parser.c:20059
0x9229e2 cp_parser_declarator
../../gcc/gcc/cp/parser.c:19798
0x9312b0 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19323
0x9386da cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:27104
0x93881c cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:26706
0x9390dc cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:26943
0x9390dc cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:26962
0x93e449 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12673
0x93e731 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12600
0x93ea24 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4559
0x93ea24 c_parse_file()
../../gcc/gcc/cp/parser.c:38820
0xa3cd46 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]

[Bug objc/77428] incorrect 'set but not used' warning with @throw

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Tom de Vries from comment #1)
> > Created attachment 39528 [details]
> > tentative patch
> 
> Have you sent this patch to the gcc-patches mailing list yet?

No.

[Bug sanitizer/82829] libsanitizer build failure on darwin10 (Snow Leopard) due to missing getsectiondata

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org,
   ||mikestump at comcast dot net,
   ||ro at gcc dot gnu.org

--- Comment #2 from Rainer Orth  ---
(In reply to Eric Gallager from comment #0)
> Trying to build gcc with MacPorts on OS X 10.6 results in the following
> error in libsanitizer:
[...]
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.
> org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/
> libsanitizer/asan/asan_mac.cc: In function 'void
> __asan::AsanApplyToGlobals(__asan::globals_op_fptr, const void*)':
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.
> org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/
> libsanitizer/asan/asan_mac.cc:84:45: error: 'getsectiondata' was not
> declared in this scope
>__asan_global *globals = (__asan_global *)getsectiondata(
>  ^~
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.
> org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/
> libsanitizer/asan/asan_mac.cc:84:45: note: suggested alternative:
> 'getsectdata'
>__asan_global *globals = (__asan_global *)getsectiondata(
>  ^~
>  getsectdata

I've had a look at Xcode 3.2.6 (the last release that supports Mac OS X 10.6),
and its  *does* include getsectiondata declarations. 
Comparing
the 10.5 and 10.6 SDKs included in that release, the function was added in
10.6.

Which Xcode version do you have installed?  Maybe you upgraded from 10.5 to
10.6
and forgot to install a corresponding Xcode?

I've also checked cctools on opensource.apple.com and found that it was added
between cctools-758 and cctools-773.  However, I've no idea how to determine
which Xcode releases those correspond to.

I have no idea if your workaround patch is the right thing, but given how
difficult it has been to get fixes for older OS X releases upstream, or even
a statement which versions are supposed to be still supported, the way out is
probably to disable darwin10 support in libsanitizer/configure.tgt.

Maybe the Darwin maintainers have some insight?

  Rainer

[Bug rtl-optimization/84083] New: [missed optimization] loop-invariant strlen() not hoisted out of loop

[eyalroz at technion dot ac.il]

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

Bug ID: 84083
   Summary: [missed optimization] loop-invariant strlen() not
hoisted out of loop
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

Consider the following code:

#include 

void bar(char c);

void foo(const char* __restrict__ ss) 
{
for (int i = 0; i < strlen(ss); ++i) 
{
bar(*ss);
}
}

To my understanding, the fact that ss is __restrict__ed (and the fact that it
isn't written through or that it's a const pointer) is sufficient to allow the
compiler to assume the memory accessible via ss remains constant, and thus that
strlen(ss) will return the same value.

But - that's not what happens (with GCC 7.3):

.L6:
movsx   edi, BYTE PTR [rbp+0]
mov rbx, r12
callbar(char)
.L3:
mov rdi, rbp
lea r12, [rbx+1]
callstrlen
cmp rax, rbx
ja  .L6

(obtained with https://godbolt.org/g/vdGSBe )

Now, I'm no compiler expert, so maybe there are considerations I'm ignoring,
but it seems to me the compiler should be able to hoist the heavier code up
above the loop.

Cf. https://stackoverflow.com/q/48482003/1593077

[Bug sanitizer/82829] libsanitizer build failure on darwin10 (Snow Leopard) due to missing getsectiondata

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Rainer Orth from comment #2)
> (In reply to Eric Gallager from comment #0)
> > Trying to build gcc with MacPorts on OS X 10.6 results in the following
> > error in libsanitizer:
> [...]
> > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.
> > org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/
> > libsanitizer/asan/asan_mac.cc: In function 'void
> > __asan::AsanApplyToGlobals(__asan::globals_op_fptr, const void*)':
> > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.
> > org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/
> > libsanitizer/asan/asan_mac.cc:84:45: error: 'getsectiondata' was not
> > declared in this scope
> >__asan_global *globals = (__asan_global *)getsectiondata(
> >  ^~
> > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.
> > org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/
> > libsanitizer/asan/asan_mac.cc:84:45: note: suggested alternative:
> > 'getsectdata'
> >__asan_global *globals = (__asan_global *)getsectiondata(
> >  ^~
> >  getsectdata
> 
> I've had a look at Xcode 3.2.6 (the last release that supports Mac OS X
> 10.6),
> and its  *does* include getsectiondata declarations. 
> Comparing
> the 10.5 and 10.6 SDKs included in that release, the function was added in
> 10.6.
> 
> Which Xcode version do you have installed?  Maybe you upgraded from 10.5 to
> 10.6
> and forgot to install a corresponding Xcode?
> 
> I've also checked cctools on opensource.apple.com and found that it was added
> between cctools-758 and cctools-773.  However, I've no idea how to determine
> which Xcode releases those correspond to.
> 
> I have no idea if your workaround patch is the right thing, but given how
> difficult it has been to get fixes for older OS X releases upstream, or even
> a statement which versions are supposed to be still supported, the way out is
> probably to disable darwin10 support in libsanitizer/configure.tgt.
> 
> Maybe the Darwin maintainers have some insight?
> 
>   Rainer

Turns out the issue is actually the  from the
libmacho-headers MacPorts port is getting picked up before the system one;
guess this is actually a MacPorts issue instead...

[Bug target/84081] gcc.target/i386/avx512bitalg-vpopcntb-1.c etc. FAIL

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Dup.

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

[Bug target/83828] FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #4 from H.J. Lu  ---
*** Bug 84081 has been marked as a duplicate of this bug. ***

[Bug target/83828] FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-28
 Ever confirmed|0   |1

--- Comment #5 from H.J. Lu  ---
Need binutils 2.30 to reproduce.

[Bug tree-optimization/84084] New: -O2 Early VPR pass wrongly removes "ret" exit basic block causing infinite loop/segfaults

[romain.geissler at amadeus dot com]

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

Bug ID: 84084
   Summary: -O2 Early VPR pass wrongly removes "ret" exit basic
block causing infinite loop/segfaults
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

It looks like there is a regression in the Early VRP pass with -O2 that affects
at the very least gcc 7 and 8, but we could find strange behaviour up to gcc
4.8.

cat evrp-bug.c
#include 
//#include 

int main()
{
  int arr[2] = {1, 2};

  for (int i = 0, val; (val = arr[i]), i < 2; ++i)
  {
  printf("%i\n", val); // With this line, works with gcc <= 6, fails with
gcc >= 7
  //std::cout << val << std::endl; //With line line, works with gcc <= 4.7,
fails with gcc >= 4.8.
  }
}

First the C frontend and the C++ frontend disagrees. The C frontend correctly
compiles this, and even correctly find that "val = arr[i]" is UB when "i == 2"
(when -Wall is enabled)

https://godbolt.org/g/SG9SyU

: In function 'main':
:8:34: warning: array subscript 2 is above array bounds of 'int[2]'
[-Warray-bounds]
   for (int i = 0, val; (val = arr[i]), i < 2; ++i)
   ~~~^~~
Compiler returned: 0

Execution correctly prints:
1
2

Now with the C++ frontend, things go wrong. First the UB behaviour is not
printed. The executation fails with an infinite loop and eventually a segfault

https://godbolt.org/g/9xnRX7

The reason for that is that the function epilog:
  xor eax, eax
  add rsp, 8
  ret

is missing when compiled with the C++ frontend. In our case, since "_start" is
placed by the linker just after "main", then each calls to "main" eventually
continue into "_start", which calls main again, each time increasing the stack
usage, and eventually segfaulting because of stack going out of bound.

Please note that depending on whether the inside loop is inlinable or not
(printf vs std::cout) then the regression either starts with gcc 4.8 or with
gcc 6.

This issue seems to be a wrong behavior from the early vrp pass. Note that
compiling with "-fno-tree-vrp" correctly works around the issue:
https://godbolt.org/g/EjvxQd

I am providing tree dumps generated with g++ (GCC) 7.2.1 20171022, gcc trunk
output might be slightly different.

Pass just before evrp:
cat evrp-bug.c.037t.fre1
;; Function int main() (main, funcdef_no=12, decl_uid=2833, cgraph_uid=12,
symbol_order=12)

int main() ()
{
  int val;
  int i;
  int arr[2];

   [0.00%]:
  arr[0] = 1;
  arr[1] = 2;
  # DEBUG i => 0

   [0.00%]:
  # i_1 = PHI <0(2), i_12(5)>
  # DEBUG i => i_1 
  val_7 = arr[i_1];
  # DEBUG val => val_7
  if (i_1 <= 1)
goto ; [0.00%]
  else
goto ; [0.00%]

   [0.00%]:
  printf ("%i\n", val_7);

   [0.00%]:
  i_12 = i_1 + 1;
  # DEBUG i => i_12
  goto ; [0.00%]

   [0.00%]:
  arr ={v} {CLOBBER};
  return 0;

 [0.00%]:
  arr ={v} {CLOBBER};
  resx 1

}

cat evrp-bug.c.038t.evrp
Then the evrp pass, which wrongly removes the exit basic block 6:
;; Function int main() (main, funcdef_no=12, decl_uid=2833, cgraph_uid=12,
symbol_order=12)

;; 2 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5 6 7
;;
;; Loop 1
;;  header 3, latch 5
;;  depth 1, outer 0
;;  nodes: 3 5 4
;; 2 succs { 3 }
;; 3 succs { 4 6 }
;; 4 succs { 7 5 }
;; 5 succs { 3 }
;; 6 succs { 1 }
;; 7 succs { }

Value ranges after Early VRP:

i_1: [0, 1]
val_7: VARYING
i_12: [1, 2]


Removing basic block 6
Merging blocks 3 and 4
int main() ()
{
  int val;
  int i;
  int arr[2];

   [0.00%]:
  arr[0] = 1;
  arr[1] = 2;
  # DEBUG i => 0

   [0.00%]:
  # i_1 = PHI <0(2), i_12(4)>
  # DEBUG i => i_1
  val_7 = arr[i_1];
  # DEBUG val => val_7
  printf ("%i\n", val_7);

   [0.00%]:
  i_12 = i_1 + 1;
  # DEBUG i => i_12
  goto ; [0.00%]

 [0.00%]:
  arr ={v} {CLOBBER};
  resx 1

}

Can you please have a look at this regression ?

Chees,
Romain

[Bug target/83831] [6/7/8 Regression][RX] Unused bclr,bnot,bset insns

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
Created attachment 43266
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43266&action=edit
Patch for GCC 6

This patch is for GCC 6.  Tested with "make -k check" on rx-sim for c and c++
with no new failures.

[Bug target/83831] [RX] Unused bclr,bnot,bset insns

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-28
Summary|[6/7/8 Regression][RX]  |[RX] Unused bclr,bnot,bset
   |Unused bclr,bnot,bset insns |insns
 Ever confirmed|0   |1

--- Comment #2 from Oleg Endo  ---
(In reply to Oleg Endo from comment #0)
> These cases should be emitting the bclr, bnot, bset instructions.  They are
> present in rx.md but I guess the combine pass does not catch them because of
> some reasons.  I assume these patterns used to work at some point in time,
> so this must be some kind of regression.  It's not working on the latest
> supported branch (GCC 6) and trunk (GCC 8).

While working on this issue, I realized that the patterns could have never
worked to the full extent.  There was also a corresponding comment in rx.md. 
So it's not really a regression, but I'll be posting patches for GCC 6 and GCC
7 here in case somebody needs it.

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|WAITING |ASSIGNED
 Blocks||32630

--- Comment #6 from Thomas Koenig  ---
I'm going to fix the accepts-invalid part of this bug - this has gotten
more important with the automatic generation of interfaces.

How to work with Fortran arrays of character(len=1) as strings...
I thought there was an article by Steve Lionel about that, but I
cannot seem to find it.

TRANSFER looks like a good possibility, at least:

program main
  character(len=10) :: a
  character :: b(10)
  b = 'x'
  a = transfer(b,a)
  print *,b
end program main


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630
[Bug 32630] [meta-bug] ISO C binding

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

[3dw4rd at verizon dot net]

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

Ed Smith-Rowland <3dw4rd at verizon dot net> changed:

   What|Removed |Added

 CC||3dw4rd at verizon dot net

--- Comment #7 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Thank you.

I was curious, is there anything/anyone working the opposite problem?
A -ffortran-interfaces converting structs to type and function protos to module
interfaces?

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
(In reply to Ed Smith-Rowland from comment #7)
> Thank you.
> 
> I was curious, is there anything/anyone working the opposite problem?
> A -ffortran-interfaces converting structs to type and function protos to
> module interfaces?

I am not aware of anything like that.

For function prototypes at least, one problem is ambiguity on the C side.

Take

void foo(int *a, int n);

How should the corresponding Fortran subroutine look like?

subroutine foo(a, n)
  real :: a
  integer :: n

would be one option,

subroutine foo(a,n)
  real :: a(*)
  integer :: n

another.

[Bug rtl-optimization/84083] [missed optimization] loop-invariant strlen() not hoisted out of loop

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think bar can still change the value of what ss points to.

[Bug rtl-optimization/84083] [missed optimization] loop-invariant strlen() not hoisted out of loop

[eyalroz at technion dot ac.il]

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

--- Comment #2 from Eyal Rozenberg  ---
(In reply to Andrew Pinski from comment #1)
> I think bar can still change the value of what ss points to.

What, you mean, by walking up the stack? I don't see why the compiler should
accommodate that by avoiding hoisting.

If you mean because ss is also somehow visible to bar(), then - the
__restrict__ guarantees we don't have to worry about that. IIANM.

[Bug c/84085] New: Array element is unnecessary loaded twice

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 84085
   Summary: Array element is unnecessary loaded twice
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

[code]
#define N 9

struct S1
{
int a1[N][N];
};
struct S2
{
int a2[N][N];
int a3[N][N];
};

void test1(S1* s1, S2* s2)
{
s2->a2[N-1][N-1] = s1->a1[N-1][N-1];
s2->a3[N-1][N-1] = 1u << s1->a1[N-1][N-1];
}

void test2(S1* s1, S2* s2)
{
const int n = N*N-1;
*((&s2->a2[0][0] + n)) = *(&s1->a1[0][0] + n);
*((&s2->a3[0][0] + n)) = 1u << *(&s1->a1[0][0] + n);
}

void test3(S1* s1, S2* s2)
{
const int n = N*N-1;
int x = *(&s1->a1[0][0] + n);
*((&s2->a2[0][0] + n)) = x;
*((&s2->a3[0][0] + n)) = 1u << x;
}
[/code]

[out]
test1(S1*, S2*):
  mov ecx, DWORD PTR [rdi+320]
  mov eax, 1
  sal eax, cl
  mov DWORD PTR [rsi+320], ecx
  mov DWORD PTR [rsi+644], eax
  ret
test2(S1*, S2*):
  mov eax, DWORD PTR [rdi+320]
  mov DWORD PTR [rsi+320], eax
  mov ecx, DWORD PTR [rdi+320]
  mov eax, 1
  sal eax, cl
  mov DWORD PTR [rsi+644], eax
  ret
test3(S1*, S2*):
  mov ecx, DWORD PTR [rdi+320]
  mov eax, 1
  sal eax, cl
  mov DWORD PTR [rsi+320], ecx
  mov DWORD PTR [rsi+644], eax
  ret
[/out]

All 3 functions are equivalent. However when 2D array is treated as a 1D one,
gcc for some reason loads array element twice (function test2). Local variable
added in test3 allows to get the same code as for test1. I have found this
during writing code for AARCH64, but x86_64 is also affected.

gcc 8 (trunk) does not have this problem.

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
(In reply to Jerry DeLisle from comment #3)
> I think this bug is invalid and gfortran is correct.
> 
> If you do this:
> 
> &n
>  ta(1:8)%c = 'bogus'
> /
> 
> You get what you expect.  The way you have it, you can not put 8 strings
> called 'bogus' into one strng element of ta.
> 
> Anyine else have any thoughts on this?

Can you please elaborate in more detail?

For the slightly modified testcase & data:

% cat pr82086b.f90
program pr82086
  implicit none
  type t
 character(8) :: c=''
  end type t
  type(t),  dimension(9) :: ta
  type(t),  dimension(9) :: tb
  type(t),  dimension(9) :: tc
  character(8), dimension(9) :: td = ""
  namelist /n/ta, tb, tc, td

  open(1,file='pr82086b.txt')
  read(1,nml=n)
  print *, ta%c
  print *, tb%c
  print *, tc%c
  print *, td
end program pr82086

% cat pr82086b.txt
&n
 ta(1:8)%c =   'bogus'
 tb(1:8)%c = 8*'bogus'
 tc(1:8)%c =   'bogus','bogus','bogus','bogus','bogus','bogus','bogus','bogus'
 td(1:8)   = 8*'bogus'
/

I get with Intel v15, v17, PGI 17.10, Sun 8.4:

 bogus   
 bogus   bogus   bogus   bogus   bogus   bogus   bogus   bogus   
 bogus   bogus   bogus   bogus   bogus   bogus   bogus   bogus   
 bogus   bogus   bogus   bogus   bogus   bogus   bogus   bogus   

Cray 8.4.1 and 8.6.5 reject the second line (tb).

Can you explain the subleties in more detail why the repeat does not
work as naively expected?

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
NAG 6.1 rejects the third case (tc). After commenting this it prints:

 bogus   
 bogus   

 bogus   bogus   bogus   bogus   bogus   bogus   bogus   bogus

[Bug libgomp/84086] New: [nvptx] segfault in instantiate_scev_r for libgomp.fortran/examples-4/simd-2.f90 -O1

[vries at gcc dot gnu.org]

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

Bug ID: 84086
   Summary: [nvptx] segfault in instantiate_scev_r for
libgomp.fortran/examples-4/simd-2.f90 -O1
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

@r257131:
...
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O1  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O1  (test for excess errors)
UNRESOLVED: libgomp.fortran/examples-4/simd-2.f90   -O1  compilation failed to
produce executable
...

In more details:
...
during GIMPLE pass: ivopts
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.fortran/examples-4/simd-2.f90:21:0:
internal compiler \
error: Segmentation fault
0xc4414f crash_signal
/home/vries/oacc/trunk/source-gcc/gcc/toplev.c:325
0xd442ff instantiate_scev_r
/home/vries/oacc/trunk/source-gcc/gcc/tree-scalar-evolution.c:2765
0xd444c2 instantiate_scev_convert
/home/vries/oacc/trunk/source-gcc/gcc/tree-scalar-evolution.c:2611
0xd444c2 instantiate_scev_r
/home/vries/oacc/trunk/source-gcc/gcc/tree-scalar-evolution.c:2747
0xd4539f resolve_mixers(loop*, tree_node*, bool*)
/home/vries/oacc/trunk/source-gcc/gcc/tree-scalar-evolution.c:2841
0xd47998 analyze_scalar_evolution_in_loop
/home/vries/oacc/trunk/source-gcc/gcc/tree-scalar-evolution.c:2208
0xd47abc simple_iv_with_niters(loop*, loop*, tree_node*, affine_iv*,
tree_node**, bool)
/home/vries/oacc/trunk/source-gcc/gcc/tree-scalar-evolution.c:3323
0xdc6720 find_givs_in_stmt_scev
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-loop-ivopts.c:1416
0xdc6720 find_givs_in_stmt
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-loop-ivopts.c:1446
0xdc6720 find_givs_in_bb
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-loop-ivopts.c:1460
0xdc6720 find_givs
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-loop-ivopts.c:1473
0xdc6720 find_induction_variables
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-loop-ivopts.c:1489
0xdc6720 tree_ssa_iv_optimize_loop
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-loop-ivopts.c:7559
0xdc6720 tree_ssa_iv_optimize()
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-loop-ivopts.c:7618
0xde5ed0 execute
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-loop.c:500
...

[Bug libstdc++/84087] New: string::assign problem with two arguments

[bseifert at gmx dot at]

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

Bug ID: 84087
   Summary: string::assign problem with two arguments
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bseifert at gmx dot at
  Target Milestone: ---

Created attachment 43267
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43267&action=edit
does not compile as expected

>From C++14, string::assign can be called with two arguments: the string (1) and
the position (2). The length (3) is optional.

This worked in gcc 7.2.0. In 7.3.0 (with the updated libstdc++), the call with
only 2 arguments does not work.

gcc 7.3.0 was compiled with default settings in Windows 10 bash. The following
line is used to compile main.cpp (attached):

~/gcc-7.3.0/bin/gcc main.cpp --std=c++14

The following error messages are returned:

main.cpp: In function ‘int main()’:
main.cpp:8:17: error: no matching function for call to
‘std::__cxx11::basic_string::assign(std::__cxx11::string&, int)’
s.assign(s, 2);
 ^
In file included from /home/seifert/gcc-7.3.0/include/c++/7.3.0/string:52:0,
 from main.cpp:3:
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1345:7: note:
candidate: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::assign(const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]
   assign(const basic_string& __str)
   ^~
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1345:7: note:  
candidate expects 1 argument, 2 provided
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1361:7: note:
candidate: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::assign(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with
_CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]
   assign(basic_string&& __str)
   ^~
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1361:7: note:  
candidate expects 1 argument, 2 provided
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1384:7: note:
candidate: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::assign(const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned
int]
   assign(const basic_string& __str, size_type __pos, size_type __n)
   ^~
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1384:7: note:  
candidate expects 3 arguments, 2 provided
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1400:7: note:
candidate: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::assign(const _CharT*,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned
int]
   assign(const _CharT* __s, size_type __n)
   ^~
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1400:7: note:  
no known conversion for argument 1 from ‘std::__cxx11::string {aka
std::__cxx11::basic_string}’ to ‘const char*’
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1416:7: note:
candidate: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::assign(const _CharT*)
[with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]
   assign(const _CharT* __s)
   ^~
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1416:7: note:  
candidate expects 1 argument, 2 provided
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1433:7: note:
candidate: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::assign(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type,
_CharT) [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator; std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type = long unsigned int]
   assign(size_type __n, _CharT __c)
   ^~
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1433:7: note:  
no known conversion for argument 1 from ‘std::__cxx11::string {aka
std::__cxx11::basic_string}’ to
‘std::__cxx11::basic_string::size_type {aka long unsigned int}’
/home/seifert/gcc-7.3.0/include/c++/7.3.0/bits/basic_string.h:1451

[Bug middle-end/84071] [7/8 regression] nonzero_bits1 of subreg incorrect

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-28
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
> PR59461 changed nonzero_bits1 incorrectly for subregs:
> 
>   /* On many CISC machines, accessing an object in a wider mode
>  causes the high-order bits to become undefined.  So they are
>  not known to be zero.  */
>   rtx_code extend_op;
>   if ((!WORD_REGISTER_OPERATIONS
>/* If this is a typical RISC machine, we only have to worry
>   about the way loads are extended.  */
>|| ((extend_op = load_extend_op (inner_mode)) == SIGN_EXTEND
>? val_signbit_known_set_p (inner_mode, nonzero)
>: extend_op != ZERO_EXTEND)
>|| (!MEM_P (SUBREG_REG (x)) && !REG_P (SUBREG_REG (x
>   && xmode_width > inner_width)
> nonzero
>   |= (GET_MODE_MASK (GET_MODE (x)) & ~GET_MODE_MASK
> (inner_mode));
> 
> If WORD_REGISTER_OPERATIONS is set and load_extend_op is ZERO_EXTEND, rtl
> like
> 
> (subreg:SI (reg:HI 125) 0)
> 
> is assumed to be always zero-extended.

That's not what the code is supposed to do.  As explained in the comment, the
code is intended to compute the nonzero bits of the subreg from the
nonzero_bits of the inner reg:

  nonzero &= cached_nonzero_bits (SUBREG_REG (x), mode,
  known_x, known_mode, known_ret);

> This is incorrect since modes that are smaller than WORD_MODE may contain
> random top bits. This is equally true for RISC and CISC ISAs and independent 
> of WORD_REGISTER_OPERATIONS, so it's unclear why the !REG_P check was added.

No, that's wrong, WORD_REGISTER_OPERATIONS precisely means that the bits up to
the word are defined when operations operate in mode smaller than a word.

[Bug libgomp/84086] segfault in instantiate_scev_r for libgomp.fortran/examples-4/simd-2.f90 -O1

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Target|nvptx   |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-28
Summary|[nvptx] segfault in |segfault in
   |instantiate_scev_r for  |instantiate_scev_r for
   |libgomp.fortran/examples-4/ |libgomp.fortran/examples-4/
   |simd-2.f90 -O1  |simd-2.f90 -O1
 Ever confirmed|0   |1

--- Comment #1 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-testresults/2018-01/msg01990.html:
...
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O1  (internal compiler error)
FAIL: libgomp.fortran/examples-4/simd-2.f90   -O1  (test for excess errors)
UNRESOLVED: libgomp.fortran/examples-4/simd-2.f90   -O1  compilation failed to
produce executable
...

So, this is not nvptx specific. The ICE happens in the host compiler, not in
the offload compiler.

[Bug libgomp/84088] New: [nvptx] libgomp.oacc-fortran/declare-*.f90 execution fails

[vries at gcc dot gnu.org]

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

Bug ID: 84088
   Summary: [nvptx] libgomp.oacc-fortran/declare-*.f90 execution
fails
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

@r257131, with GOMP_NVPTX_JIT=-O0, driver version 384.111, geforce 710, and
cuda 8.0, kernel version 4.13.0-32-generic:
...
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O0  execution test
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O1  execution test
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O2  execution test
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer -finline-functions  execution test
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O3 -g  execution test
FAIL: libgomp.oacc-fortran/declare-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -Os  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O0  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O1  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O2  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer -finline-functions  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O3 -g  execution test
FAIL: libgomp.oacc-fortran/declare-2.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -Os  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O0  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O1  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O2  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer -finline-functions  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O3 -g  execution test
FAIL: libgomp.oacc-fortran/declare-4.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -Os  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O0  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O1  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O2  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer -finline-functions  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O3 -g  execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -Os  execution test
...

[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
It's the dbr ("reorg") pass that is deleting the insn.

[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool  ---
There are *two* conditional branches leading to that "return 1".  After
dbr one is a delay-slot seq, and the other has lost the assignment of the
return value.

[Bug middle-end/84089] New: [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

[danglin at gcc dot gnu.org]

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

Bug ID: 84089
   Summary: [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C
-std=gnu++14 (internal compiler error)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++14
-Wpedantic -S -o lambda-generic-x.s
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C: In function
'int main()':
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C:9:22: warning:
lambda templates are only available with -std=c++2a or -std=gnu++2a
[-Wpedantic]
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C:11:23: warning:
lambda templates are only available with -std=c++2a or -std=gnu++2a
[-Wpedantic]
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C: In lambda
function:
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C:12:17: warning:
lambda templates are only available with -std=c++2a or -std=gnu++2a
[-Wpedantic]
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C: In function
'int main()':
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C:19:26: warning:
lambda templates are only available with -std=c++2a or -std=gnu++2a
[-Wpedantic]
during RTL pass: expand
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C: In lambda
function:
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C:13:42: internal
compiler error: Arithmetic exception

This is a division by zero.

[Bug c/84052] Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo

[pageexec at gmail dot com]

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

--- Comment #3 from PaX Team  ---
(In reply to Andrew Pinski from comment #1)
> Plugins issues like this should reported to the plugin author and not to gcc.
what makes you think it's a plugin issue? i reported several gcc bugs myself
over the years that i ran across while developing plugins (some have yet to be
addressed fwiw). this case is no different, it's a gcc bug where sometimes gcc
emits debug info for a type that has not even been constructed yet.

[Bug c/84052] Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Cao jin from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Plugins issues like this should reported to the plugin author and not to 
> > gcc.
> 
> I don't know gcc internals, from my very limited understanding about gcc &
> that plugin, the plugin just does one optimization on the intermediate
> language: redefine a structure with randomized order and set it back to its
> context. So the backend would see a structure different from its original
> definition in source file and could generate the proper debuginfo.   So I
> feels this issue may be more close to gcc.
> 
> I was not sure where should I report this problem. I was hoping gcc guys
> could take a look at that plugin, I feel it is not hard for you gcc expert
> to read, even I can tell the basic logic inside.

It is not the job of gcc developers to figure out a bug in a plugin or gcc.  It
is plugin writer's job to do that.


(In reply to PaX Team from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > Plugins issues like this should reported to the plugin author and not to 
> > gcc.
> what makes you think it's a plugin issue? i reported several gcc bugs myself
> over the years that i ran across while developing plugins (some have yet to
> be addressed fwiw). this case is no different, it's a gcc bug where
> sometimes gcc emits debug info for a type that has not even been constructed
> yet.

Because debug information happens early on and has many interactions with the
front end.  Most optimizations don't change types.  In fact changing of the
type after the fact is not the correct approach, you need to duplication the
type and then lay it out and change all of the ir.  This is how struct reorg
would work.  Also you have to check to make sure the types don't escape. Now of
that code exists in gcc right now.  So again this is outside of the scope of
gcc bug.

[Bug tree-optimization/84090] New: [8 Regression] ICE in gimple_redirect_edge_and_branch, at tree-cfg.c:6151

[asolokha at gmx dot com]

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

Bug ID: 84090
   Summary: [8 Regression] ICE in gimple_redirect_edge_and_branch,
at tree-cfg.c:6151
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu, powerpcspe-*-linux-gnu

gcc-8.0.0-alpha20180121 snapshot (r256935) ICEs when compiling the following
snippet w/ -mcpu=power9 (7400, 7450, 970, G4, G5, cell, e6500, power7, power8,
powerpc64le) -O1 -ftrapv -ftree-loop-vectorize:

void
dn (int uk, int gz)
{
  while (uk < 1)
if (gz != 0)
  {
short int pp;

for (pp = 0; pp < 1; ++pp)
  {
 e6:
gz += pp;
  }
  }

  goto e6;
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180121 -mcpu=power9 -O1 -ftrapv
-ftree-loop-vectorize -c de5zx0pd.c
during GIMPLE pass: vect
de5zx0pd.c: In function 'dn':
de5zx0pd.c:2:1: internal compiler error: in gimple_redirect_edge_and_branch, at
tree-cfg.c:6151
 dn (int uk, int gz)
 ^~
0xc9ee71 gimple_redirect_edge_and_branch
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-cfg.c:6151
0x727708 redirect_edge_and_branch(edge_def*, basic_block_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/cfghooks.c:369
0xc92d70 gimple_split_edge
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-cfg.c:2964
0x728043 split_edge(edge_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/cfghooks.c:648
0x90555e gimple_find_edge_insert_loc
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/gimple-iterator.c:811
0x9068bb gsi_insert_seq_on_edge_immediate(edge_def*, gimple*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/gimple-iterator.c:855
0xf1a261 vectorizable_live_operation(gimple*, gimple_stmt_iterator*,
_slp_tree*, int, gimple**)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-vect-loop.c:8311
0xf11f27 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-vect-stmts.c:9561
0xf220ef vect_transform_loop(_loop_vec_info*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-vect-loop.c:8870
0xf442da vectorize_loops()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-vectorizer.c:740

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
(In reply to Harald Anlauf from comment #4)
> (In reply to Jerry DeLisle from comment #3)
> > I think this bug is invalid and gfortran is correct.
> > 
> > If you do this:
> > 
> > &n
> >  ta(1:8)%c = 'bogus'
> > /
> > 
> > You get what you expect.  The way you have it, you can not put 8 strings
> > called 'bogus' into one strng element of ta.
> > 
> > Anyine else have any thoughts on this?
> 
> Can you please elaborate in more detail?
> 

My interpretation, and I am probably wrong, is that the left hand side of the
assignment ta(1:8)%c = 8*'bogus'  is an array section but we are currently
trying to assign all the 8 "bogus" strings into the first element of the array
since we have not given any array qualifiers on the right hand side.

I see from your expanded example that gfortran does the same thing NAG does. If
we let gfortran write the namelist, we get this:

&N
 TA(1)%C="bogus   ",
 TA(2)%C="bogus   ",
 TA(3)%C="bogus   ",
 TA(4)%C="bogus   ",
 TA(5)%C="bogus   ",
 TA(6)%C="bogus   ",
 TA(7)%C="bogus   ",
 TA(8)%C="bogus   ",
 /

which is not ambiguous.  I am not arguing either way now, but how does one
interpret these two cases:

 ta(1:8)%c =   'bogus'
 tb(1:8)%c = 8*'bogus'

The first case without the repeat count seems unambiguous to me which leads me
to question the validity of the case with the repeat count.

[Bug target/84033] powerpc64le -moptimize-swaps bad code with vec_vbpermq

[amodra at gcc dot gnu.org]

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

--- Comment #4 from Alan Modra  ---
Author: amodra
Date: Mon Jan 29 04:23:00 2018
New Revision: 257135

URL: https://gcc.gnu.org/viewcvs?rev=257135&root=gcc&view=rev
Log:
PR84033, powerpc64le -moptimize-swaps bad code with vec_vbpermq

vbpermq produces its output in bits 48..63 of the target vector reg,
so the output cannot be lane swapped.

gcc/
PR target/84033
* config/rs6000/rs6000.c (rtx_is_swappable_p): Exclude
UNSPEC_VBPERMQ.
gcc/testsuite/
PR target/84033
* gcc.target/powerpc/swaps-p8-46.c: New.

Backport svn r257070

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/swaps-p8-46.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/84091] New: ICE on valid C++ code: Segmentation fault

[su at cs dot ucdavis.edu]

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

Bug ID: 84091
   Summary: ICE on valid C++ code: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a recent regression. 

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.1 20180128 (experimental) [trunk revision 257131] (GCC)
$
$ g++-7.2.0 tmp.cpp
$
$ g++tk tmp.cpp
tmp.cpp: In instantiation of ‘void f() [with  = int]’:
tmp.cpp:8:14:   required from here
tmp.cpp:3:15: internal compiler error: Segmentation fault
   [] { struct A {} a; } ();
   ^
0xe9e57f crash_signal
../../gcc-source-trunk/gcc/toplev.c:325
0x77a0a1 tree_check
../../gcc-source-trunk/gcc/tree.h:3131
0x77a0a1 determine_visibility(tree_node*)
../../gcc-source-trunk/gcc/cp/decl2.c:2472
0x7ea06a do_pushtag
../../gcc-source-trunk/gcc/cp/name-lookup.c:6479
0x7ea06a pushtag(tree_node*, tree_node*, tag_scope)
../../gcc-source-trunk/gcc/cp/name-lookup.c:6491
0x87fb7c lookup_template_class_1
../../gcc-source-trunk/gcc/cp/pt.c:8966
0x87fb7c lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc-source-trunk/gcc/cp/pt.c:9168
0x875a4f tsubst_aggr_type
../../gcc-source-trunk/gcc/cp/pt.c:12036
0x8778b0 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:13669
0x86fa34 tsubst_decl
../../gcc-source-trunk/gcc/cp/pt.c:12965
0x877de6 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:13586
0x857b4c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:16080
0x8533eb tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:16007
0x8545c8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:16284
0x8545c8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:16284
0x89c366 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:17019
0x861011 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:18308
0x86416b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:17628
0x853b9f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:16800
0x855965 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:16021
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


--


template < typename > void f ()
{ 
  [] { struct A {} a; } ();
}

int main ()
{ 
  f < int > ();
  return 0;
}

[Bug target/84033] powerpc64le -moptimize-swaps bad code with vec_vbpermq

[amodra at gcc dot gnu.org]

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

--- Comment #5 from Alan Modra  ---
Author: amodra
Date: Mon Jan 29 04:31:18 2018
New Revision: 257137

URL: https://gcc.gnu.org/viewcvs?rev=257137&root=gcc&view=rev
Log:
[PATCH] PR84033, powerpc64le -moptimize-swaps bad code with vec_vbpermq

vbpermq produces its output in bits 48..63 of the target vector reg,
so the output cannot be lane swapped.

gcc/
PR target/84033
* config/rs6000/rs6000.c (rtx_is_swappable_p): Exclude
UNSPEC_VBPERMQ.
gcc/testsuite/
PR target/84033
* gcc.target/powerpc/swaps-p8-46.c: New.

Backport svn r257070

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/swaps-p8-46.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/84033] powerpc64le -moptimize-swaps bad code with vec_vbpermq

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #6 from Alan Modra  ---
Fixed all active branches

[Bug c++/84092] New: ICE on C++14 code with variable template: in build_qualified_name, at cp/tree.c:2043

[su at cs dot ucdavis.edu]

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

Bug ID: 84092
   Summary: ICE on C++14 code with variable template: in
build_qualified_name, at cp/tree.c:2043
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a recent regression. 

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.1 20180129 (experimental) [trunk revision 257134] (GCC) 
$ 
$ g++-7.2.0 -c tmp.cpp
$ 
$ g++tk -c tmp.cpp
tmp.cpp:1:44: internal compiler error: in build_qualified_name, at
cp/tree.c:2043
 template < typename T > int a (T::template b);
^
0x8dffb4 build_qualified_name(tree_node*, tree_node*, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/tree.c:2043
0x8c9631 finish_qualified_id_expr(tree_node*, tree_node*, bool, bool, bool,
bool, int)
../../gcc-source-trunk/gcc/cp/semantics.c:2074
0x8ca073 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
../../gcc-source-trunk/gcc/cp/semantics.c:3704
0x80b102 cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:5615
0x8183a3 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:7029
0x82180c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8281
0x7fb7c9 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:9049
0x7fbec5 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:9151
0x7fc7b0 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9439
0x7fd7a3 cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9721
0x7ffb9a cp_parser_parenthesized_expression_list
../../gcc-source-trunk/gcc/cp/parser.c:7718
0x800c7c cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:21798
0x823744 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19611
0x8240c1 cp_parser_single_declaration
../../gcc-source-trunk/gcc/cp/parser.c:27111
0x8241fc cp_parser_template_declaration_after_parameters
../../gcc-source-trunk/gcc/cp/parser.c:26710
0x824b23 cp_parser_explicit_template_declaration
../../gcc-source-trunk/gcc/cp/parser.c:26944
0x824b23 cp_parser_template_declaration_after_export
../../gcc-source-trunk/gcc/cp/parser.c:26962
0x8318f9 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12673
0x830424 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12600
0x830767 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4559
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


-


template < typename T > int a (T::template b);

[Bug fortran/84093] New: Invalid nested derived type constructor not rejected

[neil.n.carlson at gmail dot com]

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

Bug ID: 84093
   Summary: Invalid nested derived type constructor not rejected
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

Gfortran allows invalid nested derived type constructors. Consider this
example:

type parent
  integer :: a, b
end type

type, extends(parent) :: child
  real :: x
end type

type(child) :: foo
foo = child(parent(1,2),3.0)

end

Note 4.59 and the preceding paragraphs (in F08 or F15 standard) are clear
that in this example parent(1,2) corresponds to the first component of
child, which is a, and gfortran should reject this illegal code.

The correct constructor must use keywords if one wants to use the parent
constructor:

foo = child(parent=parent(1,2), x=3.0)

Note that the extends_2.f03 testsuite program contains this error.

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
Yes, it's still an issue.

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180128 -v   
Using built-in specs.
COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180128
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/8.0.0-alpha20180128/lto-wrapper
Target: powerpc-e300c3-linux-gnu
Configured with:
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/configure
--host=x86_64-pc-linux-gnu --target=powerpc-e300c3-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/powerpc-e300c3-linux-gnu/gcc-bin/8.0.0-alpha20180128
--includedir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/8.0.0-alpha20180128/include
--datadir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/8.0.0-alpha20180128
--mandir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/8.0.0-alpha20180128/man
--infodir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/8.0.0-alpha20180128/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/8.0.0-alpha20180128/include/g++-v8
--with-python-dir=/share/gcc-data/powerpc-e300c3-linux-gnu/8.0.0-alpha20180128/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --enable-checking=yes --disable-esp
--enable-libstdcxx-time --enable-poison-system-directories
--with-sysroot=/usr/powerpc-e300c3-linux-gnu --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec
--disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx
--disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto
--with-isl --disable-isl-version-check --disable-libsanitizer
Thread model: posix
gcc version 8.0.0-alpha20180128 20180128 (experimental) (GCC)

(as of r257131)

[Bug libgomp/84088] [nvptx] libgomp.oacc-fortran/declare-*.f90 execution fails

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> @r257131, with GOMP_NVPTX_JIT=-O0, driver version 384.111, geforce 710, and
> cuda 8.0, kernel version 4.13.0-32-generic:

Same result without GOMP_NVPTX_JIT=-O0.

And same result with GOMP_NVPTX_JIT=-O0 on driver version 384.111, quadro
m1200, cuda 7.5, kernel version 4.13.0-31-generic.

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Jan 29 07:11:16 2018
New Revision: 257138

URL: https://gcc.gnu.org/viewcvs?rev=257138&root=gcc&view=rev
Log:
2017-01-29  Thomas Koenig  

PR fortran/84073
* resolve.c (resolve_component): Ensure BIND(C) character
components have length one.
(resolve_symbol): Likewise for variables.

2017-01-29  Thomas Koenig  

PR fortran/84073
* gfortran.dg/bind_c_usage_31.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_31.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84073] In -fc-prototypes fixed (nonzero) length strings are mapped to plain char in prototype.

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #10 from Thomas Koenig  ---
The accepts-invalid part is fixed.

I am not planning a backport since user code which may have
worked up to now (even erroneously) would then be rejected.

[Bug tree-optimization/83176] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
Should we close this PR now?

[Bug fortran/32630] [meta-bug] ISO C binding

[tkoenig at gcc dot gnu.org]

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

Bug 84073 Summary: In -fc-prototypes fixed (nonzero) length strings are mapped 
to plain char in prototype.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073

   What|Removed |Added

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

[Bug tree-optimization/82819] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[asolokha at gmx dot com]

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

--- Comment #5 from Arseny Solokha  ---
Should we close this PR now?

[Bug middle-end/84071] [7/8 regression] nonzero_bits1 of subreg incorrect

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Investigating.

[Bug testsuite/84094] New: several correctness issues in gfortran.dg

[janus at gcc dot gnu.org]

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

Bug ID: 84094
   Summary: several correctness issues in gfortran.dg
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

see https://github.com/nncarlson/gfortran.dg/issues

[Bug middle-end/84095] New: false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

Bug ID: 84095
   Summary: false-positive -Wrestrict warnings for memcpy within
array
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

I see multiple new warnings for correct code in the Linux kernel for code that
copies one array member into other members of the same array, reduced to:

$ cat > test.c << EOF
struct { int i; } a[8];

void f(void)
{
int i;

for (i=1; i <8; i++)
__builtin_memcpy(&a[i], &a[0], sizeof(a[0]));
}
EOF

$ x86_64-linux-gcc-8.0.1 -c -Wall test.c 
test4.c: In function 'f':
test4.c:8:3: warning: '__builtin_memcpy' accessing 4 bytes at offsets 0 and 0
overlaps 4 bytes at offset 0 [-Wrestrict]
   __builtin_memcpy(&a[i], &a[0], sizeof(a[0]));
   ^~~~