[Bug target/94065] New: AIX rs6000 NO_SUM_IN_TOC and NO_FP_IN_TOC disable logic reversed in aix config files

[dje at gcc dot gnu.org]

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

Bug ID: 94065
   Summary: AIX rs6000 NO_SUM_IN_TOC and NO_FP_IN_TOC disable
logic reversed in aix config files
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

The logic to disable NO_SUM_IN_TOC and NO_FP_IN_TOC in aix61.h, aix71.h and
aix72.h is reversed.  The intent of the code is to disable those features for
cmodel=large, but it enables those features.

This bug is intended to track the patch.

[Bug target/94065] AIX rs6000 NO_SUM_IN_TOC and NO_FP_IN_TOC disable logic reversed in aix config files

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-06
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug middle-end/94133] GCC loses track of SHIFT optimization

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Last reconfirmed||2020-03-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug middle-end/94133] New: GCC loses track of SHIFT optimization

[dje at gcc dot gnu.org]

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

Bug ID: 94133
   Summary: GCC loses track of SHIFT optimization
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

https://godbolt.org/z/pkXsfc

void foo1(unsigned sh, const uint64_t src[3], uint64_t dst[])
{
  uint64_t w0 = src[0];
  uint64_t w1 = src[1];
  dst[0] = (uint64_t)(unsigned __int128)w1 << 64) | w0) << sh % 64) >> 64);
}

foo1:
  mov rax, QWORD PTR [rsi+8]
  mov r8, rdx
  mov rdx, QWORD PTR [rsi]
  mov ecx, edi
  shld rax, rdx, cl
  mov QWORD PTR [r8], rax
  ret

void foo2(unsigned sh, const uint64_t src[3], uint64_t dst[])
{
  uint64_t w0 = src[0];
  uint64_t w1 = src[1];
  uint64_t w2 = src[2];
  dst[1] = (uint64_t)(unsigned __int128)w2 << 64) | w1) << sh % 64) >> 64);
  dst[0] = (uint64_t)(unsigned __int128)w1 << 64) | w0) << sh % 64) >> 64);
}

foo2:
  mov r9, QWORD PTR [rsi+8]
  mov r8, rdx
  mov ecx, edi
  mov rdx, QWORD PTR [rsi+16]
  and ecx, 63
  mov r10, QWORD PTR [rsi]
  mov rax, r9
  shld rdx, r9, cl
  sal rax, cl
  test cl, 64
  cmovne rdx, rax
  mov rax, r10
  sal rax, cl
  mov QWORD PTR [r8+8], rdx
  mov rdx, r9
  shld rdx, r10, cl
  test cl, 64
  cmovne rdx, rax
  mov QWORD PTR [r8], rdx
  ret

[Bug target/94177] New: TLS global-dynamic model clobbers function parameter on AIX

[dje at gcc dot gnu.org]

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

Bug ID: 94177
   Summary: TLS global-dynamic model clobbers function parameter
on AIX
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

In global-dynamic model, if a TLS variable first is referenced in the argument
list to a function call, GCC can load the parameters to the call before
invoking the function to legitimize the TLS variable, and the legitimize
function clobbers some of the same function argument registers.

extern int foo (char *, int *, int);

int main()
{
   static __thread int result;

   foo ("%p %u\n", &result, 169);
   return 0;
}

$ gcc -fPIC -S bug_tls.c
li 5,169
lwz 10,LCM..1(2)
lwz 9,LC..1(2)
mr 3,10
mr 4,9
bla __tls_get_addr <*** clobbers r4, r5 already loaded with arguments
to foo
mr 9,3
mr 4,9
lwz 3,LC..2(2)
bl .foo


The pattern that generates __tls_get_addr shows that it clobbers r4 and r5

(define_insn "tls_get_addr_internal"
  [(set (reg:P 3)
(unspec:P [(reg:P 3) (reg:P 4)] UNSPEC_TLSTLS))
   (clobber (reg:P 0))
   (clobber (reg:P 4))
   (clobber (reg:P 5))
   (clobber (reg:P 11))
   (clobber (reg:CC CR0_REGNO))
   (clobber (reg:P LR_REGNO))]
  "TARGET_XCOFF && HAVE_AS_TLS"
  "bla __tls_get_addr")

but GCC overwrites the parameters in calls.c during initial RTL generation.

[Bug c/94225] New: C18 conformance for structure implicit initialization

[dje at gcc dot gnu.org]

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

Bug ID: 94225
   Summary: C18 conformance for structure implicit initialization
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

Example 12 in section 6.7.9 of the C18 standard demonstrates that implicit
initialization does not override prior explicit initialization.  The following
is the example code with error checking added.

$ cat example12.c
#include 

struct T {
  int k;
  int l;
};
struct S {
  int i;
  struct T t;
};

struct T x = {.l = 43, .k = 42, };
int main(void)
{
  struct S l = { 1, .t = x, .t.l = 41, };
  if (l.t.k != 42)
fprintf(stderr, "l.t.k is %d instead of 42\n", l.t.k);
}

$ ./xgcc -B./ -std=gnu1x example12.c
$ ./a.out
l.t.k is 0 instead of 42
$

[Bug c/94225] C18 conformance for structure implicit initialization

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org
   Last reconfirmed||2020-03-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug target/89096] [8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default

[dje at gcc dot gnu.org]

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

--- Comment #28 from David Edelsohn  ---
GCC 7 is no longer supported.  The patch was backported and released in GCC 8.4
and GCC 9.1.

[Bug target/89096] [8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default

[dje at gcc dot gnu.org]

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

--- Comment #30 from David Edelsohn  ---
Yes, I can reproduce the error, but it only occurs when -bsvr4 is used.  Have
you looked at what -bsvr4 enables in the ld man page?  Not just the -R comment.

-brtl -brtllib -bexpfull

-R, instead of being ignored, takes one suboption that defines the runtime
library search path

It seems that you're utilizing the -bsvr4 option to change the behavior of -R
without regard for the other effects of the option.  And the other changes to
the default behavior of the AIX are breaking the build.

-bsvr4 tries to provide a lot of SVR4 behavior, but is too course and big a
club.


[ ] Instead of using -bsvr4, I strongly suggest that you adjust / adapt the
Makefile of your project and use the AIX linker -blibpath command line option
to set the runtime library search path.


I realize that there is no other AIX linker option to change the behavior of
just -R, but you incorrectly are blaming the compiler for an error elicited by
other, documented effects of the -bsvr4 linker option.  AIX is not Solaris or
Linux.  There is no magic command line option to make AIX pretend to be Linux.

The failure is not caused by a GCC bug and it's not caused by an AIX linker
bug.  GCC is behaving as designed.  AIX linker is behaving as designed and
documented.  The -bsvr4 option has too many other effects to be used solely to
work around the -R option.

[Bug target/89096] [8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default

[dje at gcc dot gnu.org]

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

--- Comment #31 from David Edelsohn  ---
Just to be clear, the -brtl allows runtime overriding symbols. GCC is correctly
placing some symbols that should not be overridden in the text section. To
allow the runtime overriding, which is not needed for this application/library,
one needs to instruct the AIX linker to make the text section read-write.  All
of these other changes in behavior are triggered by the need to use -R to
specify runtime library search path.

[Bug gcov-profile/95480] New: GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

Bug ID: 95480
   Summary: GCOV change breaks AIX build
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

The June 2 change to gcov breaks AIX because it now requires atomic 64 bit
operations in 32 bit mode.

g++-6.2.0 -std=c++11 -no-pie   -g   -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-bbigtoc 
gcov-tool.o libgcov-util.o libgcov-driver-tool.o libgcov-merge-tool.o
libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a
/gsa/yktgsa/home/e/d/edelsohn/install/lib/libiconv.a 
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -o gcov-tool
ld: 0711-317 ERROR: Undefined symbol: .__atomic_fetch_add_8
ld: 0711-317 ERROR: Undefined symbol: .__sync_val_compare_and_swap_8
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
make: *** [Makefile:3044: gcov-tool] Error 1

[Bug gcov-profile/95480] GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-02
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Edelsohn  ---
Likely caused by

commit 871e5ada6d53d5eb495cc9f323983f347487c1b2
Author: Martin Liska 
Date:   Fri Jan 31 13:10:14 2020 +0100

Make TOPN counter dynamically allocated.

[Bug gcov-profile/95480] GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
$ nm -BCpg libgcov-merge-tool.o | grep _8
 - U .__atomic_fetch_add_8
 - U .__sync_val_compare_and_swap_8

[Bug gcov-profile/95480] GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
Demangling the function names in the assembly output

gcov_counter_add(long long*, long long, int)
...
bl .__atomic_fetch_add_8


gcov_counter_set_if_null(long long*, gcov_kvp*, int)
...
bl .__sync_val_compare_and_swap_8

[Bug gcov-profile/95480] GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  ---
The references only occur when compiling without optimization during stage1.

[Bug gcov-profile/95480] GCOV change breaks AIX build

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
AIX build is happier with the patch

[Bug target/68837] PowerPC switch statement performance

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
The PR was from 2015, before Martin's improvements.

Also, sign-extend load instructions were less efficient at the time.  We need
to re-examine the sequence on more recent microarchitectures.

[Bug libstdc++/95545] thread:: conflicts with std::thread

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-04

--- Comment #1 from David Edelsohn  ---
Confirmed for AIX and MSVC.

[Bug libstdc++/95545] New: thread:: conflicts with std::thread

[dje at gcc dot gnu.org]

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

Bug ID: 95545
   Summary: thread:: conflicts with std::thread
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

AIX, MSVC, and possibly other systems, implemented their own definition of
thread different from Posix threads.

libstdc++  header eventually includes , which includes
the system  header, which, on AIX, eventually includes


The AIX header nicely does

#ifdef __cplusplus
extern "C" {
#endif

struct  thread {
...
}

which creates an ambiguity when a user references thread:: without std::thread.

LLVM C++ has a pattern that helps to avoid the conflict because of a similar
problem for MSVC:

namespace llvm {
typedef std::thread thread;
}

llvm/include/llvm/Support/thread.h

Would libstdc++ consider a similar solution?

[Bug libstdc++/95545] thread:: conflicts with std::thread

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
#include 
#include 
using namespace std;

int main(void)
{
int maxThreads = thread::hardware_concurrency();
printf("maxThreads: %d\n", maxThreads);
return(0);
}

$ g++ -pthread /tmp/nameclash.cpp -o /tmp/nc
/tmp/nameclash.cpp: In function 'int main()':
/tmp/nameclash.cpp:7:19: error: reference to 'thread' is ambiguous
  int maxThreads = thread::hardware_concurrency();
   ^~
In file included from /tmp/nameclash.cpp:2:
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/8/include/c++/thread:62:9: note:
candidates are: 'class std::thread'
   class thread
 ^~
In file included from /usr/include/sys/ptrace.h:28,
 from /usr/include/sys/proc.h:44,
 from /usr/include/sys/pri.h:43,
 from /usr/include/sys/sched.h:38,
 from /usr/include/sched.h:51,
 from /usr/include/pthread.h:63,
 from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/8/include/c++/powerpc-ibm-aix7.2.0.0/pthread/bits/gthr-posix.h:35,
 from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/8/include/c++/powerpc-ibm-aix7.2.0.0/pthread/bits/gthr-default.h:30,
 from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/8/include/c++/powerpc-ibm-aix7.2.0.0/pthread/bits/gthr.h:148,
 from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/8/include/c++/ext/atomicity.h:35,
 from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/8/include/c++/memory:73,
 from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/8/include/c++/thread:39,
 from /tmp/nameclash.cpp:2:
/usr/include/sys/thread.h:106:8: note: 'struct thread'
 struct thread {
^~

[Bug libstdc++/95545] thread:: conflicts with std::thread

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #4 from David Edelsohn  ---
Impossible.

[Bug middle-end/95552] New: VLA ICE

[dje at gcc dot gnu.org]

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

Bug ID: 95552
   Summary: VLA ICE
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

g++.dg/ext/vla3.C
and
g++.dg/cpp1y/vla8.C

both now elicit

during RTL pass: expand
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/cpp1y/vla8.C:24:12: internal
compiler error: in expand_expr_real_1, at expr.c:10160
ranges offset out of range

[Bug middle-end/95552] VLA ICE

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-05
 Ever confirmed|0   |1

--- Comment #2 from David Edelsohn  ---
Confirmed.

[Bug middle-end/95552] VLA ICE

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug middle-end/95552] [11 Regression] VLA ICE

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
Started between r11-878 and r11-896

[Bug middle-end/95552] [11 Regression] VLA ICE

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from David Edelsohn  ---
Jason, this seems to be a regression introduced by your patch for C++ VLA PR
95232.

[Bug bootstrap/95628] [11 regression] ICE in gcc build after r11-1181

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target|powerpc64*-linux-gnu|powerpc*-*-*
 Ever confirmed|0   |1
  Build|powerpc64*-linux-gnu|powerpc*-*-*
   Host|powerpc64*-linux-gnu|powerpc*-*-*
 CC||dje at gcc dot gnu.org
   Last reconfirmed||2020-06-10
 Status|UNCONFIRMED |NEW

--- Comment #2 from David Edelsohn  ---
Confirmed.

[Bug target/95734] [11 regression] lots of ICEs after r11-1445

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org
   Host|powerpc64*-linux-gnu|powerpc*-*-8
 Target|powerpc64*-linux-gnu|powerpc*-*-*
  Build|powerpc64*-linux-gnu|powerpc*-*-*

--- Comment #2 from David Edelsohn  ---
Same on AIX.

[Bug fortran/95918] New: gfortran.dg/char4-subscript.f90 fails for BE architectures

[dje at gcc dot gnu.org]

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

Bug ID: 95918
   Summary: gfortran.dg/char4-subscript.f90 fails for BE
architectures
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, krebbel at gcc dot gnu.org,
segher at gcc dot gnu.org
Depends on: 95837
  Target Milestone: ---
Target: powerpc64-linux, powerpc-ibm-aix, s390x-linux

The new gfortran.dg/char4-subscript.f90 testcase fails on all big endian
targets.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95837
[Bug 95837] derived-type components of character kind=4 – wrong code with
component access (kind=4 ignored)

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-26

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
{ target { le } }

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

[dje at gcc dot gnu.org]

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

--- Comment #8 from David Edelsohn  ---
It uses . where it wants to consume a quotation mark (").

Because the BE/LE difference is flipping characters, would it negate the
purpose of the test to check for one or zero characters?

! { dg-final { scan-tree-dump {  \(\*var\.str2\)\[1\]{lb: 1 sz: 4} =
.d?\\x00\\x00d?.\[1\]{lb: 1 sz: 4};} "original" } }

In other words, test for the "d" or not at one end, and "d" or not at the other
end.

And the next test would become

! { dg-final { scan-tree-dump "  __builtin_memmove \(\(void \*\) &\(\*var.
str2\)\[2\]{lb: 1 sz: 4}, \(void \*\\) &.e?\\x00\\x00\\x00[ef]\\x00
\\x00f?.\[1\]{lb: 1 sz: 4}, 8\);" "original" } }

Or is a possible failure that the endian was flipped?

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

[dje at gcc dot gnu.org]

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

--- Comment #9 from David Edelsohn  ---
This set of regexps works for me:

! { dg-final { scan-tree-dump {  \(\*var\.str2\)\[1\]{lb: 1 sz: 4} =
"(d\\x00\\x
00|\\x00\\x00\\x00d)"\[1\]{lb: 1 sz: 4};} "original" } }
! { dg-final { scan-tree-dump {  __builtin_memmove \(\(void \*\)
&\(\*var.str2\)
\[2\]{lb: 1 sz: 4}, \(void \*\)
&"(e\\x00\\x00\\x00f\\x00\\x00|\\x00\\x00\\x00e\
\x00\\x00\\x00f)"\[1\]{lb: 1 sz: 4}, 8\);} "original" } }
! { dg-final { scan-tree-dump {  \(\*var.str2\)\[4\]{lb: 1 sz: 4} =
"(\\x00\\xf6
\\x01|\\x00\\x01\\xf6)"\[1\]{lb: 1 sz: 4};} "original" } }
! { dg-final { scan-tree-dump {  \(\*var.str2\)\[5\]{lb: 1 sz: 4} =
"(\\b\\xf6\\
x01|\\x00\\x01\\xf6\\b)"\[1\]{lb: 1 sz: 4};} "original" } }

Okay?

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

[dje at gcc dot gnu.org]

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

--- Comment #10 from David Edelsohn  ---
Created attachment 48809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48809&action=edit
Updated regex for either endianness

The new patch updates the regexps to accept the result for either endianness. 
And removes the extra quoting from the regexps.

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

[dje at gcc dot gnu.org]

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

--- Comment #11 from David Edelsohn  ---
With the patch the testcase succeeds on both powerpc-ibm-aix7.2.0.0 (big
endian) and powerpc64-linux (little endian)

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

[dje at gcc dot gnu.org]

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

--- Comment #13 from David Edelsohn  ---
Committed, but why gcc-10? I don't see the testcase on that branch.

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #15 from David Edelsohn  ---
Fixed

[Bug c++/96008] cpp1y/lambda-generic-69078-1.C nonnull warning and ICE

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug c++/96008] New: cpp1y/lambda-generic-69078-1.C nonnull warning and ICE

[dje at gcc dot gnu.org]

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

Bug ID: 96008
   Summary: cpp1y/lambda-generic-69078-1.C nonnull warning and ICE
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

With the recent -Wnonnull changes, cpp1y/lambda-generic-69078-1.C now elicits a
warning and the compiler ICEs.

FAIL: g++.dg/cpp1y/lambda-generic-69078-1.C  -std=gnu++14 (test for excess
errors)
Excess errors:
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/cpp1y/lambda-generic-69078-1.C:23:13:
warning: 'this' pointer null [-Wnonnull]
'
Internal compiler error: Error reporting routines re-entered.
ranges offset out of range


In discussion on IRC, Jonathan Wakely suggested that this is a C++FE bug
because a lambda expression can't have a null this pointer.

[Bug c++/95984] [11 Regression] Internal compiler error: Error reporting routines re-entered. since r11-1697-g75ff24e1920ea6b1

[dje at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

[Bug c++/96008] cpp1y/lambda-generic-69078-1.C nonnull warning and ICE

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
msebor:
the warning is working correctly but the IL the C++ front end
emits doesn't look right: AFAICS, it creates a function object
for the lambda and calls its operator() with a null this pointer:

; Function static decltype (((const main()::*)0)->operator()(static_cast(main::._anon_0::_FUN::) ...))
main()_FUN(auto:1 ...) [with auto:1 = {int};
decltype (((const main()::*)0)->operator()(static_cast(main::._anon_0::_FUN::) ...)) =
void] (null)
;; enabled by -tree-original


<::operator() (0B, D.2440) >;
return;


The ICE is PR95984

[Bug fortran/96023] New: Line number for error message differs for x86-64 vs all other architectures

[dje at gcc dot gnu.org]

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

Bug ID: 96023
   Summary: Line number for error message differs for x86-64 vs
all other architectures
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

I don't know how this is possible, but the line number associated with the
error message for gfortran.dg/pr95690.f90 is different for x86-64 than for all
other architectures.

As seen by the lack of failures in x86-64 testsuite reports, the test succeeds
on that target.  Manually running the testcase on x86-64 (gcc67) elicits:

pr95690.f90:5:0:

5 |   print *, (erfc) ! { dg-error "not a floating constant" }
  | 
Error: initializer for floating value is not a floating constant

Running the testcase on powerpc64le-linux, powerpc-ibm-aix, s390x-linux,
aarch64-linux, etc. elicits:

pr95690.f90:6:0:

6 |end
  | 
Error: initializer for floating value is not a floating constant

Same error message associated with a different line.

[Bug fortran/96023] Line number for error message differs for x86-64 vs all other architectures

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-07-01
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails

[dje at gcc dot gnu.org]

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

--- Comment #11 from David Edelsohn  ---
I added Solaris to the list of targets that see the error on line 5.  Add it
wherever your target sees it.

[Bug c++/96105] GCC not consistent on whether no_unique_address array is an empty data member

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||dje at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
   Last reconfirmed||2020-07-07

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug middle-end/77373] __attribute__((vector_size(N))) fails on AIX in symtab_node::get

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #5 from David Edelsohn  ---
Fixed

[Bug target/94065] AIX rs6000 NO_SUM_IN_TOC and NO_FP_IN_TOC disable logic reversed in aix config files

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Target Milestone|10.3|10.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from David Edelsohn  ---
Fixed in 10.1

[Bug bootstrap/96404] New: [10 Regression] AIX Bootstrap failure with DWARF debug changes

[dje at gcc dot gnu.org]

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

Bug ID: 96404
   Summary: [10 Regression] AIX Bootstrap failure with DWARF debug
changes
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

After the patch for debug/96383, bootstrap fails on AIX due to stage2/stage3
comparison failure.  The DWARF debugging information differs.

[Bug bootstrap/96404] [10 Regression] AIX Bootstrap failure with DWARF debug changes

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Blocks||96383
 Target||powerpc-ibm-aix*
   Severity|normal  |blocker
 CC||rguenth at gcc dot gnu.org


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
[Bug 96383] [8/9/10 Regression] Full ABI information missing from GCC compiled
C

[Bug bootstrap/96404] [10 Regression] AIX Bootstrap failure with DWARF debug changes

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
This apparently occurs on x86_64-*-linux, so this is a more general problem.

It does not appear to be due to the debug patch.

[Bug bootstrap/96404] [10 Regression] AIX Bootstrap failure with DWARF debug changes

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Target|powerpc-ibm-aix*|*-*-*
   Last reconfirmed||2020-07-31

--- Comment #4 from David Edelsohn  ---
This seems to be present for x86_64-*-linux also.

I reverted the debug change, but the failure still is present.  Continuing to
search for the offending patch.

[Bug bootstrap/96404] [10 Regression] Bootstrap failure

[dje at gcc dot gnu.org]

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

--- Comment #6 from David Edelsohn  ---
Created attachment 48969
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48969&action=edit
stage2 dbgcnt.s

[Bug bootstrap/96404] [10 Regression] Bootstrap failure

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
Created attachment 48970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48970&action=edit
stage3 dbgcnt.s

[Bug bootstrap/96404] [10 Regression] Bootstrap failure

[dje at gcc dot gnu.org]

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

--- Comment #10 from David Edelsohn  ---
r11-2445 succeeds.  I am testing r11-2447 and then r11-2451.

[Bug bootstrap/96404] [10 Regression] Bootstrap failure

[dje at gcc dot gnu.org]

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

--- Comment #11 from David Edelsohn  ---
r11-2447 fails.  Testing r11-2446.

[Bug bootstrap/96404] [10 Regression] Bootstrap failure

[dje at gcc dot gnu.org]

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

--- Comment #12 from David Edelsohn  ---
r11-2446 succeeds and r11-2447 fails, so the failure (at least on AIX) is the
var-tracking dataflow patch.

[Bug bootstrap/96404] [10 Regression] Bootstrap failure

[dje at gcc dot gnu.org]

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

--- Comment #13 from David Edelsohn  ---
The symptom I see on AIX is that the labels for DWARF variable locations differ
between stage2 and stage3 for some files.  The difference started with the
recent change to the var-tracking pass.  Once the labels diverge, the addresses
no longer match and the object file differ.

The var-tracking dump files are over 1GB with lots of address differences, but
it doesn't contain any differences in the BB dump output for vt_find_locations,
which is the function that was changed.

The assembly file differences give the appearance of an unstable sort.  The
beginning of the difference for an assembly file looks like:

--- tree-vrp.S  2020-08-01 19:42:00.0 -0400
+++ ../gcc/tree-vrp.S   2020-08-01 19:43:33.0 -0400
@@ -38428,8 +38428,8 @@
 LM..7111:
addi 19,1,792
li 20,1
-L..2070:
 LVL..2903:
+L..2070:
 LBE..22006:
 LBE..22005:
 LBE..22004:
@@ -38466,6 +38466,7 @@
 LM..7114:
cmpwi 0,31,0
beq 0,L..2043
+LVL..2904:
 LBB..22481:
 LM..7115:
 LM..7116:
@@ -38475,12 +38476,12 @@
mr 30,31
bl .memcpy
nop
-LVL..2904:
+LVL..2905:
 LM..7117:
 LM..7118:
 LM..7119:
lwz 27,8(31)
-LVL..2905:
+LVL..2906:
 LM..7120:
 LM..7121:
lwz 9,4(27)
@@ -38489,7 +38490,7 @@
beq 0,L..2348
 L..2044:
 LM..7123:
-LVL..2906:
+LVL..2907:
 LBE..22481:
 LBE..22508:
 LBE..22535:

[Bug bootstrap/96404] [10 Regression] Bootstrap failure

[dje at gcc dot gnu.org]

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

--- Comment #17 from David Edelsohn  ---
The patch fixes bootstrap for AIX.

[Bug target/96772] New: Power VSX libmvec implementation for OpenMP SIMD

[dje at gcc dot gnu.org]

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

Bug ID: 96772
   Summary: Power VSX libmvec implementation for OpenMP SIMD
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-*-linux

[Bug target/96772] Power VSX libmvec implementation for OpenMP SIMD

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-08-24

--- Comment #1 from David Edelsohn  ---
Feature request for Power VSX libmvec "ABI" implementation in GCC.

[Bug target/96787] rs6000 mcpu=power10 miscompiles libiberty htab_delete() causing bootstrap failure

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-26
   Target Milestone|--- |10.2
 CC||bergner at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from David Edelsohn  ---
Confirmed.

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-08-27
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug target/96941] New: Initial PPC64LE transcendental auto-vectorization functionality

[dje at gcc dot gnu.org]

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

Bug ID: 96941
   Summary: Initial PPC64LE transcendental auto-vectorization
functionality
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-*-linux

Demonstrate basic auto-vectorization of single- and double-precision
transcendental functions using libmvec.

[Bug target/96941] Initial PPC64LE transcendental auto-vectorization functionality

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-09-05

--- Comment #1 from David Edelsohn  ---
confirmed

[Bug target/96941] Initial PPC64LE transcendental auto-vectorization functionality

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #2 from David Edelsohn  ---
Demonstrated.

[Bug libstdc++/97044] Undefined format macros because of include order on AIX

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-09-21

--- Comment #4 from David Edelsohn  ---
This needs to be fixed with fixincludes.

[Bug target/92168] New: Poor code generation for addcarry / subborrow

[dje at gcc dot gnu.org]

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

Bug ID: 92168
   Summary: Poor code generation for addcarry / subborrow
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

Real World Technology reader reports poor GCC code generation relative to Clang
and MSVC for source code involving carry / borrow.

https://www.realworldtech.com/forum/?threadid=188061&curpostid=188061

with example at Compiler Explorer

https://godbolt.org/z/YYq6ou

[Bug target/92168] Poor code generation for addcarry / subborrow

[dje at gcc dot gnu.org]

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

--- Comment #1 from David Edelsohn  ---
Created attachment 47074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47074&action=edit
Source code example from Compiler Explorer

[Bug target/92168] Poor code generation for addcarry / subborrow

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-21
 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Edelsohn  ---
Confirmed.

[Bug target/92269] Profiling (-p) does not work on H8

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #2 from David Edelsohn  ---
That is the other "dje", Doug Evans, who originally worked at Cygnus.  Jeff is
the current maintainer of the H8 port.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[dje at gcc dot gnu.org]

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

--- Comment #35 from David Edelsohn  ---
The ELFv2 ABI does not require Power8+ because the subroutine linkage
convention requires Power8 instructions.  It requires Power8+ because the ABI
provide a minimum guarantee to the programmer / developer / toolchain /
distribution of the minimum ISA that will be encountered. The ABI can function
on earlier hardware, but the ABI asserts to the programmer that one can utilize
the instructions available in Power8 without special accommodation or feature
tests. The authors of the ABI (IBM) didn't want to provide a guarantee of
backward compatibility to the beginning of time, which creates challenges for
the minimum ISA level supported by, for example, a GNU/Linux distribution.

[Bug bootstrap/92661] New: [10 Regression] AIX bootstrap failure with builtin-types.def change

[dje at gcc dot gnu.org]

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

Bug ID: 92661
   Summary: [10 Regression] AIX bootstrap failure with
builtin-types.def change
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

: fatal error: internal error: builtin function '__builtin_ddedpd'
had an unexpected return type 'DD'

AIX does not enable OPTION_MASK_DFP in the CPU masks.

Either rs6000-builtin.def should not define the builtin or rs6000-call.c
rs6000_common_init_builtins should not define the builtin.

started with r278684.

[Bug bootstrap/92661] [10 Regression] AIX bootstrap failure with builtin-types.def change

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-25
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug bootstrap/92661] [10 Regression] AIX bootstrap failure with builtin-types.def change

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
A crude work-around to allow GCC to bootstrap and show the extent of the
problem, I need the following patches to comment out all decimal builtins.

Index: rs6000-call.c
===
--- rs6000-call.c   (revision 278691)
+++ rs6000-call.c   (working copy)
@@ -7653,7 +7653,7 @@
 /* signed args, unsigned return.  */
 case VSX_BUILTIN_XVCVDPUXDS_UNS:
 case ALTIVEC_BUILTIN_FIXUNS_V4SF_V4SI:
-case MISC_BUILTIN_UNPACK_TD:
+/* case MISC_BUILTIN_UNPACK_TD: */
 case MISC_BUILTIN_UNPACK_V1TI:
   h.uns_p[0] = 1;
   break;
@@ -7676,7 +7676,7 @@
   break;

 /* unsigned arguments for 128-bit pack instructions.  */
-case MISC_BUILTIN_PACK_TD:
+/* case MISC_BUILTIN_PACK_TD: */
 case MISC_BUILTIN_PACK_V1TI:
   h.uns_p[1] = 1;
   h.uns_p[2] = 1;
Index: rs6000-c.c
===
--- rs6000-c.c  (revision 278691)
+++ rs6000-c.c  (working copy)
@@ -4884,6 +4884,7 @@
   { P8V_BUILTIN_VEC_VCLZD, P8V_BUILTIN_VCLZD,
 RS6000_BTI_unsigned_V2DI, RS6000_BTI_unsigned_V2DI, 0, 0 },

+#if 0
   { P9_BUILTIN_DFP_TSTSFI_LT, MISC_BUILTIN_TSTSFI_LT_TD,
 RS6000_BTI_INTSI, RS6000_BTI_UINTSI, RS6000_BTI_dfloat128, 0 },
   { P9_BUILTIN_DFP_TSTSFI_LT, MISC_BUILTIN_TSTSFI_LT_DD,
@@ -4923,6 +4924,7 @@
 RS6000_BTI_INTSI, RS6000_BTI_UINTSI, RS6000_BTI_dfloat128, 0 },
   { P9_BUILTIN_DFP_TSTSFI_OV_DD, MISC_BUILTIN_TSTSFI_OV_DD,
 RS6000_BTI_INTSI, RS6000_BTI_UINTSI, RS6000_BTI_dfloat64, 0 },
+#endif

   { P9V_BUILTIN_VEC_VCTZ, P9V_BUILTIN_VCTZB,
 RS6000_BTI_V16QI, RS6000_BTI_V16QI, 0, 0 },
Index: rs6000-builtin.def
===
--- rs6000-builtin.def  (revision 278691)
+++ rs6000-builtin.def  (working copy)
@@ -2298,6 +2298,7 @@
 BU_P7_POWERPC64_MISC_2 (DIVDE, "divde",CONST,  dive_di)
 BU_P7_POWERPC64_MISC_2 (DIVDEU,"divdeu",   CONST,  diveu_di)

+#if 0
 /* 1 argument DFP (decimal floating point) functions added in ISA 2.05.  */
 BU_DFP_MISC_1 (DXEX,   "dxex", CONST,  dfp_dxex_dd)
 BU_DFP_MISC_1 (DXEXQ,  "dxexq",CONST,  dfp_dxex_td)
@@ -2313,6 +2314,7 @@
 BU_DFP_MISC_2 (DSCLIQ, "dscliq",   CONST,  dfp_dscli_td)
 BU_DFP_MISC_2 (DSCRI,  "dscri",CONST,  dfp_dscri_dd)
 BU_DFP_MISC_2 (DSCRIQ, "dscriq",   CONST,  dfp_dscri_td)
+#endif

 /* 0 argument void function that we pretend was added in ISA 2.06.
It's a special nop recognized by 2018+ firmware for P7 and up,
@@ -2338,9 +2340,11 @@
 BU_P8V_MISC_3 (BCDSUB_GT,  "bcdsub_gt",CONST,  bcdsub_gt)
 BU_P8V_MISC_3 (BCDSUB_OV,  "bcdsub_ov",CONST,  bcdsub_unordered)

+#if 0
 /* 2 argument pack/unpack 128-bit floating point types.  */
 BU_DFP_MISC_2 (PACK_TD,"pack_dec128",  CONST,  packtd)
 BU_DFP_MISC_2 (UNPACK_TD,  "unpack_dec128",CONST,  unpacktd)
+#endif 

 /* 0 argument general-purpose register functions added in ISA 3.0 (power9). 
*/
 BU_P9_MISC_0 (DARN_32, "darn_32",  MISC, darn_32)
@@ -2356,6 +2360,7 @@
 BU_P7_MISC_2 (PACK_V1TI,   "pack_vector_int128",   CONST,  packv1ti)
 BU_P7_MISC_2 (UNPACK_V1TI, "unpack_vector_int128", CONST,  unpackv1ti)

+#if 0
 /* 2 argument DFP (Decimal Floating Point) functions added in ISA 3.0.  */
 BU_P9_DFP_MISC_2 (TSTSFI_LT_DD, "dtstsfi_lt_dd", CONST, dfptstsfi_lt_dd)
 BU_P9_DFP_MISC_2 (TSTSFI_LT_TD, "dtstsfi_lt_td", CONST, dfptstsfi_lt_td)
@@ -2385,6 +2390,7 @@
 BU_P9_DFP_OVERLOAD_2 (TSTSFI_OV,   "dtstsfi_ov")
 BU_P9_DFP_OVERLOAD_2 (TSTSFI_OV_DD,"dtstsfi_ov_dd")
 BU_P9_DFP_OVERLOAD_2 (TSTSFI_OV_TD,"dtstsfi_ov_td")
+#endif

 /* 1 argument vector functions added in ISA 3.0 (power9).  */
 BU_P9V_AV_1 (VCTZB,"vctzb",CONST,  ctzv16qi2)

[Bug bootstrap/92661] [10 Regression] AIX bootstrap failure with builtin-types.def change

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
An alternate work-around is

Index: tree.c
===
--- tree.c  (revision 278691)
+++ tree.c  (working copy)
@@ -10334,7 +10334,7 @@
   uint64_type_node = make_or_reuse_type (64, 1);

   /* Decimal float types. */
-  if (targetm.decimal_float_supported_p ())
+  if (1)
 {
   dfloat32_type_node = make_node (REAL_TYPE);
   TYPE_PRECISION (dfloat32_type_node) = DECIMAL32_TYPE_SIZE;

[Bug target/93146] New: TLS init function not generated on AIX

[dje at gcc dot gnu.org]

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

Bug ID: 93146
   Summary: TLS init function not generated on AIX
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

SYMPTOM:
On AIX, TLS init elicits linker errors such as

TLS init fuction for thread_local_seg_handler

or

__tls_init


An example C++ program is

$ cat a.cc
#include 
struct Test {std::atomic x; };

thread_local Test t;

$ cat main.cc
#include 
struct Test {std::atomic x; };

extern thread_local Test t;
int main () {
  return t.x.load();
}

$ g++ -std=c++14 -pthread a.cc main.cc
ld: 0711-317 ERROR: Undefined symbol: __tls_init


BACKGROUND:

AIX XCOFF symbol aliases do not function the same as ELF symbols aliases: XCOFF
generates "hard aliases" (like hard links) with only one definition and the
attributes are shared / overwritten, instead of a "symbolic" reference to the
other definition with its own attributes.  Because of this
gcc/config/rs6000/xcoff.h defines:

/* This is how we tell the assembler to equate two values. 
   The semantic of AIX assembler's .set do not correspond to middle-end
expectat
ions.
   We output aliases as alternative symbols in the front of the definition
   via DECLARE_FUNCTION_NAME and DECLARE_OBJECT_NAME.
   We still need to define this macro to let middle-end know that aliases are
   supported.
 */
#define ASM_OUTPUT_DEF(FILE,LABEL1,LABEL2) do { } while (0)

Honza generously provided other AIX-specific code for function aliases that
generate alternative labels in front of the definition.

Because of this, GCC internals consider AIX as TARGET_SUPPORTS_ALIASES.  Note
that the above macro will not output anything for an alias.

AIX also support TLS.

These two features / behaviors collide for TLS init functions.  gcc/cp/decl2.c
get_tls_init_fn() and handle_tls_init() depend upon TARGET_SUPPORTS_ALIASES,
e.g.,

  if (TARGET_SUPPORTS_ALIASES && TREE_PUBLIC (var))
{
  tree single_init_fn = get_tls_init_fn (var);
  if (single_init_fn == NULL_TREE)
continue;
  cgraph_node *alias
= cgraph_node::get_create (fn)->create_same_body_alias
(single_init_fn, fn);
  gcc_assert (alias != NULL);
}

Disabling TARGET_SUPPORTS_ALIASES within cp/decl2.c does not generate correct
code (it switches from a mangled TLS init function to __tls_init).

How can G++ be coerced to generate TLS init functions for AIX?

[Bug target/93146] C++ TLS init function not generated on AIX

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-03
 CC||hubicka at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug target/89096] [8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-08
 Ever confirmed|0   |1

--- Comment #24 from David Edelsohn  ---
Confirmed.

The patch already was applied to the GCC 8 branch.

It's not clear what exact user code is continuing to triggering GCC to emit
this unusual mapping.

[Bug target/93146] C++ TLS init function not generated on AIX

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
One option is to force

flag_extern_tls_init=0

as default for AIX, e.g., -fno-extern-tls-init.

That works around the linking issue, but it assumes the limited semantics /
assertion of that option always are correct.

[Bug c++/93279] New: [9 Regression] Template substitution ICE

[dje at gcc dot gnu.org]

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

Bug ID: 93279
   Summary: [9 Regression] Template substitution ICE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47659&action=edit
C++ source code example that produces error

From Twitter (https://twitter.com/aozhanmuh/status/1217249292395720705)
and Compiler Explorer (https://godbolt.org/z/5HjwcN)

: In substitution of 'template
template
> > array_depth_v), std::nullptr_t>::type  > constexpr
math::array math::array::operator*(const Other&) const [with Other
= ; typename std::enable_if<(array_depth_v > >
array_depth_v), std::nullptr_t>::type  = ; T =
float; long unsigned int N = ]':

:56:36:   required from 'constexpr math::array math::array::operator*(const Other&) const [with Other = float; typename
std::enable_if<(array_depth_v > > array_depth_v),
std::nullptr_t>::type  = nullptr; T = math::array; long
unsigned int N = 1]'

:79:20:   required from here

:48:5: internal compiler error: unexpected expression 'N' of kind
template_parm_index

   48 |(array_depth_v > array_depth_v),

  | ^~~~

Please submit a full bug report,

with preprocessed source if appropriate.

See <https://gcc.gnu.org/bugs/> for instructions.

Compiler returned: 1

[Bug c++/93279] [9 Regression] C++ Template substitution ICE

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-15
 CC||jason at gcc dot gnu.org
Summary|[9 Regression] Template |[9 Regression] C++ Template
   |substitution ICE|substitution ICE
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
New

[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL

[dje at gcc dot gnu.org]

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

--- Comment #11 from David Edelsohn  ---
I continue to see setjmp failures on AIX.

FAIL: gcc.dg/analyzer/setjmp-7a.c expected multiline pattern lines 41-110 not
found:
FAIL: gcc.dg/analyzer/setjmp-7a.c (test for excess errors)
Excess errors:
   NN |   longjmp (env, 1); /* { dg-warning "leak of 'ptr'" } */

FAIL: gcc.dg/analyzer/setjmp-8.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-8.c  (test for warnings, line 29)
FAIL: gcc.dg/analyzer/setjmp-8.c expected multiline pattern lines 40-108 not
found:
FAIL: gcc.dg/analyzer/setjmp-8.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-8.c:15:3:
interna
l compiler error: in as_a, at is-a.h:197
   NN |   longjmp (env, 0);
  |   ^~~~
ranges offset out of range

FAIL: gcc.dg/analyzer/setjmp-9.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-9.c  (test for warnings, line 31)
FAIL: gcc.dg/analyzer/setjmp-9.c expected multiline pattern lines 42-110 not
found:
FAIL: gcc.dg/analyzer/setjmp-9.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-9.c:17:3:
interna
l compiler error: in as_a, at is-a.h:197
   NN |   longjmp (env, unknown_val);
  |   ^~
ranges offset out of range

FAIL: gcc.dg/analyzer/setjmp-3.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-3.c  (test for warnings, line 28)
FAIL: gcc.dg/analyzer/setjmp-3.c expected multiline pattern lines 39-107 not
found:
FAIL: gcc.dg/analyzer/setjmp-3.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-3.c:14:3:
interna
l compiler error: in as_a, at is-a.h:197
   NN |   longjmp (env, 1);
  |   ^~~~
ranges offset out of range

FAIL: gcc.dg/analyzer/setjmp-4.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-4.c  (test for warnings, line 29)
FAIL: gcc.dg/analyzer/setjmp-4.c expected multiline pattern lines 34-107 not
found:
FAIL: gcc.dg/analyzer/setjmp-4.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-4.c:12:3:
interna
l compiler error: in as_a, at is-a.h:197
   NN |   foo (x);
  |   ^~~
ranges offset out of range

[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL

[dje at gcc dot gnu.org]

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

--- Comment #14 from David Edelsohn  ---
Compiler version: 10.0.1 20200124 (experimental) [src revision
96f7f2867f2:1b708f12f4b:5026cbde65e724347cc2d2797026bb7bb12578f1] (GCC) 

You can see https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01180.html

[Bug middle-end/93512] New: Introduce rotate_truncation_mask

[dje at gcc dot gnu.org]

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

Bug ID: 93512
   Summary: Introduce rotate_truncation_mask
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, segher at gcc dot gnu.org
Depends on: 93505
  Target Milestone: ---

 i386.md has ;; Avoid useless masking of count operand.
 (define_insn_and_split "*3_mask"
 and (define_insn_and_split "*3_mask_1"
 for this purpose
 yeah...  but that catches not all cases at all.  but the common ones,
sure
 the other option is to say that in RTL all rotate counts are well
defined and so effectively have implicit ROTATE_COUNT_TRUNCATED
 or introduce rotate_truncation_mask with a default that will truncate
and let weirdo targets opt out
 yes, i think that would help all targets
 in any case, that looks like GCC 11 material to me
 because one would need to check all code that works with rotates, do
the masking, ensure simplify-rtx.c simplifies it etc.
 would need to be a property of ROTATE/ROTATERT, because e.g. for
library implementation if it is done using shifts we don't want to introduce UB
there
 so with the combine.c change you've acked perhaps we could defer the
rest for GCC11 (and at that point change even that hunk to do % prec


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505
[Bug 93505] [8/9/10 Regression] wrong code or ICE with __builtin_bswap64() and
rotation at -Og

[Bug target/56228] [4.8 Regression] Indirect call fails to assemble

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56228



--- Comment #2 from David Edelsohn  2013-02-06 18:15:17 
UTC ---

The proposed patch LGTM.

[Bug target/53040] nested functions may trash floating point registers

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53040



David Edelsohn  changed:



   What|Removed |Added



 CC||dje at gcc dot gnu.org



--- Comment #8 from David Edelsohn  2013-02-06 22:25:21 
UTC ---

Go ahead and backport it to 4.7 branch.

[Bug target/55431] Invalid auxv search in ppc linux-unwind code.

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431



David Edelsohn  changed:



   What|Removed |Added



 Target||powerpc*-*-linux

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-02-11

 CC||amodra at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #4 from David Edelsohn  2013-02-11 18:17:03 
UTC ---

Confirmed.



__libc_stack_end is not part of the ABI.  The problem is Glibc makes it

difficult to access auxv, otherwise one could obtain the pointer passed to

_start by the kernel. One could read /proc/self/auxv .

[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889



--- Comment #31 from David Edelsohn  2013-02-15 
16:15:19 UTC ---

With the patch, the testcase no longer ICEs when compiled on powerpc-aix.

[Bug libgcj/54100] Problems building libjava on AIX 5.2

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54100



David Edelsohn  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-25

 CC||dje at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #2 from David Edelsohn  2013-03-25 20:40:56 
UTC ---

libjava does not build on AIX in general for other reasons.  But GCC 4.8 should

invoke the AIX assembler with -many to accept more, valid mnemonics.

[Bug bootstrap/38607] AIX error messages about TOC during build

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38607



David Edelsohn  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #21 from David Edelsohn  2013-03-25 
20:53:17 UTC ---

The change to libtool to invoke GCC with -fPIC fixes most of the issues.  The

remaining issue (tail recursion in libstdc++) is a incorrect warning from the

AIX linker because it does not recognize that the target of the call -- a

function declared weak because it could be overridden -- is itself.

[Bug middle-end/56729] New: [4.9 Regression] ICE in df_insn_delete

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56729



 Bug #: 56729

   Summary: [4.9 Regression] ICE in df_insn_delete

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: d...@gcc.gnu.org





/tmp/20130325/gcc/xgcc -B/tmp/20130325/gcc/

/nasfarm/dje/src/src/gcc/testsuite/c-c++-common/torture/vshuf-v2di.c 

-fno-diagnostics-show-caret -O1 -S  -o vshuf-v2di.s

In file included from

/nasfarm/dje/src/src/gcc/testsuite/c-c++-common/torture/vshuf-v2di.c:15:0:

/nasfarm/dje/src/src/gcc/testsuite/c-c++-common/torture/vshuf-main.inc: In

function 'main':

/nasfarm/dje/src/src/gcc/testsuite/c-c++-common/torture/vshuf-main.inc:26:1:

internal compiler error: in df_insn_delete, at df-scan.c:1162

[Bug middle-end/56729] [4.9 Regression] ICE in df_insn_delete

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56729



David Edelsohn  changed:



   What|Removed |Added



 Target||powerpc*-*-*

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-25

 CC||steven at gcc dot gnu.org

   Host||powerpc*-*-*

 Ever Confirmed|0   |1

  Build||powerpc*-*-*



--- Comment #1 from David Edelsohn  2013-03-25 21:16:08 
UTC ---

Also g++ compilation and

g++.dg/torture/vshuf-v2di.C



These failures appeared after the recent df cleanups.

[Bug middle-end/56729] [4.9 Regression] ICE in df_insn_delete

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56729

--- Comment #3 from David Edelsohn  2013-03-26 18:29:16 
UTC ---
The failure only occurs in 32 bit mode and would not have been seen by a
default bootstrap on powerpc64-linux that did not run the testsuite in 32 bit
mode.

$ ./xgcc -B./ -O1 -m32
/home/dje/src/gcc/gcc/testsuite/c-c++-common/torture/vshuf-v2di.c 
In file included from
/home/dje/src/gcc/gcc/testsuite/c-c++-common/torture/vshuf-v2di.c:15:0:
/home/dje/src/gcc/gcc/testsuite/c-c++-common/torture/vshuf-main.inc: In
function ‘main’:
/home/dje/src/gcc/gcc/testsuite/c-c++-common/torture/vshuf-main.inc:26:1:
internal compiler error: in df_insn_delete, at df-scan.c:1162
 }
 ^
0x1029cabb df_insn_delete(rtx_def*)
/home/dje/src/gcc/gcc/df-scan.c:1162
0x1030d4b7 remove_insn(rtx_def*)
/home/dje/src/gcc/gcc/emit-rtl.c:3972
0x102490b3 delete_insn(rtx_def*)
/home/dje/src/gcc/gcc/cfgrtl.c:167
0x10af3c33 resolve_simple_move
/home/dje/src/gcc/gcc/lower-subreg.c:1072
0x10af3a83 resolve_simple_move
/home/dje/src/gcc/gcc/lower-subreg.c:923
0x10af4ca7 decompose_multiword_subregs
/home/dje/src/gcc/gcc/lower-subreg.c:1563
0x10af57a3 rest_of_handle_lower_subreg2
/home/dje/src/gcc/gcc/lower-subreg.c:1682
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/56770] New: Partial sums loop optimization

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770



 Bug #: 56770

   Summary: Partial sums loop optimization

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: d...@gcc.gnu.org





GCC loop optimization should unroll and transform loops using partial sums

where beneficial for expensive, independent computations where the target has

additional function units available.



Before



double fValue = 0;

int j;

for (j = 0; j < NZ; j++)

fValue += Q[j] / r[j];



After



double fValue = 0;

double fValue1 = 0;

int j;

for (j = 0; j < NZ; j=j+2){

fValue += Q[j] / r[j];

fValue1 += Q[j+1] / r[j+1];

}



for (j = (NZ/2)*2; j < NZ; j++){

fValue += Q[j] / r[j];

}



fValue = fValue + fValue1;

[Bug tree-optimization/56770] Partial sums loop optimization

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770



David Edelsohn  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-29

 Ever Confirmed|0   |1



--- Comment #1 from David Edelsohn  2013-03-29 15:29:38 
UTC ---

Currently not implemented in GCC.

[Bug tree-optimization/56770] Partial sums loop optimization

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770



--- Comment #3 from David Edelsohn  2013-03-29 18:11:54 
UTC ---

I tried -funroll-loops -fvariable-expansion-in-unroller.  I did not see any

additional benefit from -fvariable-expansion-in-unroller.



Unrolling helped somewhat, the intermediate sum was computed in each loop

iteration instead of sunk after the loop.

[Bug middle-end/56770] Partial sums loop optimization

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770



--- Comment #5 from David Edelsohn  2013-03-29 19:53:44 
UTC ---

Segher pointed out that the transformed code example is has a bug.  The first

revised loop should test j+1 < NZ.



for (j = 0; j+1 < NZ; j += 2){

fValue += Q[j] / r[j];

fValue1 += Q[j+1] / r[j+1];

}

[Bug target/56843] PowerPC Newton-Raphson reciprocal estimates can be improved

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56843



David Edelsohn  changed:



   What|Removed |Added



 Target|powerpc64-unknown-linux-gnu |powerpc*-*-*

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-04

 CC||dje at gcc dot gnu.org

   Host|powerpc64-unknown-linux-gnu |powerpc*-*-*

   Target Milestone|--- |4.9.0

 Ever Confirmed|0   |1

  Build|powerpc64-unknown-linux-gnu |powerpc*-*-*



--- Comment #1 from David Edelsohn  2013-04-04 15:09:17 
UTC ---

Confirmed.

[Bug rtl-optimization/56921] New: [4.8 Regression] ICE in rtx_cost

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921



 Bug #: 56921

   Summary: [4.8 Regression] ICE in rtx_cost

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: d...@gcc.gnu.org





libgomp.c++/for-3.C produces a segfault in GCC.



Program received signal SIGSEGV, Segmentation fault.

_Z8rtx_costP7rtx_def8rtx_codeib (x=0x70824514, outer_code=270238820, opno=0, 

speed=true) at /nasfarm/dje/src/src/gcc/rtlanal.c:3802



(gdb) where

#0  _Z8rtx_costP7rtx_def8rtx_codeib (x=0x70824514, outer_code=270238820, 

opno=0, speed=true) at /nasfarm/dje/src/src/gcc/rtlanal.c:3802

#1  0x109f4e98 in _Z21doloop_optimize_loopsv ()

at /nasfarm/dje/src/src/gcc/loop-doloop.c:2125

#2  0x109d0db8 in _ZL10rtl_doloopv ()

at /nasfarm/dje/src/src/gcc/loop-init.c:543

#3  0x106370f8 in _Z16execute_one_passP8opt_pass (pass=0x3019aa00)

at /nasfarm/dje/src/src/gcc/passes.c:2329

#4  0x10637590 in _Z17execute_pass_listP8opt_pass (pass=0x3019aa00)

at /nasfarm/dje/src/src/gcc/passes.c:2380

#5  0x106375a8 in _Z17execute_pass_listP8opt_pass (pass=0x3019ab50)

at /nasfarm/dje/src/src/gcc/passes.c:2381

#6  0x106375a8 in _Z17execute_pass_listP8opt_pass (pass=0x301b59c8)

at /nasfarm/dje/src/src/gcc/passes.c:2381

#7  0x10545f54 in _ZL15expand_functionP11cgraph_node (node=0x70419dc0)

at /nasfarm/dje/src/src/gcc/cgraphunit.c:1640

#8  0x1054821c in _Z7compilev () at /nasfarm/dje/src/src/gcc/cgraphunit.c:3710

#9  0x10548da4 in _Z25finalize_compilation_unitv ()

at /nasfarm/dje/src/src/gcc/cgraphunit.c:2119

#10 0x107517b8 in _Z28cp_write_global_declarationsv ()

at /nasfarm/dje/src/src/gcc/cp/decl2.c:4324

#11 0x1b14 in _ZL12compile_filev ()



3797  /* Sum the costs of the sub-rtx's, plus cost of this operation,

3798 which is already in total.  */

3799

3800  fmt = GET_RTX_FORMAT (code);

3801  for (i = GET_RTX_LENGTH (code) - 1; i >= 0; i--)

3802if (fmt[i] == 'e')

3803  total += rtx_cost (XEXP (x, i), code, i, speed);

3804else if (fmt[i] == 'E')

3805  for (j = 0; j < XVECLEN (x, i); j++)

3806total += rtx_cost (XVECEXP (x, i, j), code, i, speed);

[Bug rtl-optimization/56921] [4.8 Regression] ICE in rtx_cost called by doloop_optimize_loops for PPC

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921



David Edelsohn  changed:



   What|Removed |Added



 Target||powerpc*-*-*

 Status|UNCONFIRMED |NEW

   Keywords||ice-on-valid-code

   Last reconfirmed||2013-04-11

   Host||powerpc*-*-*

 Ever Confirmed|0   |1

Summary|[4.8 Regression] ICE in |[4.8 Regression] ICE in

   |rtx_cost|rtx_cost called by

   ||doloop_optimize_loops for

   ||PPC

  Build||powerpc*-*-*



--- Comment #1 from David Edelsohn  2013-04-11 15:43:24 
UTC ---

Confirmed in both AIX and PowerLinux.