Re: optimization/5959: __attribute__((pure)) ignored on PowerPC AIX
Synopsis: __attribute__((pure)) ignored on PowerPC AIX Responsible-Changed-From-To: unassigned->dje Responsible-Changed-By: dje Responsible-Changed-When: Fri Apr 26 12:18:34 2002 Responsible-Changed-Why: AIX State-Changed-From-To: open->suspended State-Changed-By: dje State-Changed-When: Fri Apr 26 12:18:34 2002 State-Changed-Why: This seems to be another case where GCC creates the TOC reference to the function early and no longer recognizes that the two functions are the same. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5959
Re: ada/10019: Can't bootstrap gcc on AIX with Ada enabled
Synopsis: Can't bootstrap gcc on AIX with Ada enabled Responsible-Changed-From-To: unassigned->bosch Responsible-Changed-By: dje Responsible-Changed-When: Mon Mar 31 17:48:48 2003 Responsible-Changed-Why: Ada http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10019
[Bug rtl-optimization/20639] New: store motion deletion of redundant stores doesn't consider asm volatiles
I'm getting the following error.
claire:~/claire/gnu/b-sparc/gcc$ ./cc1 -da -O2 -quiet foo.c
foo.c: In function `foo':
foo.c:9: error: inconsistent operand constraints in an `asm'
The problem is store motion is "deleting" one of the asm volatile stores by
changing it to a store to a pseudo. grep for "Removing redundant" in
foo.c.08.gcse.
I realize asm volatiles are optimized more these days than in the 2.x days.
I guess one can debate how far one wants to take things as far as making
asm volatile's optimizable, but this case doesn't feel like it should be
optimizable.
p.s. yes, the asm is wrong for sparc. I just picked something simple for
illustration.
void
foo (int t, int* mp)
{
int x = 42;
int* mp2 = mp;
if (t == 2)
{
asm volatile ("store %1,%0" : "=m" (*(int*) mp) : "r" (x));
asm volatile ("store %1,%0" : "=m" (*(int*) mp2) : "r" (x));
}
if (t == 3)
{
*mp = 43;
*mp = 43;
}
}
--
Summary: store motion deletion of redundant stores doesn't
consider asm volatiles
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dje at transmeta dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sparc-sun-solaris2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20639
[Bug target/94065] New: AIX rs6000 NO_SUM_IN_TOC and NO_FP_IN_TOC disable logic reversed in aix config files
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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 <http://gcc.gnu.org/bugs.html> for instructions.
[Bug tree-optimization/56770] New: Partial sums loop optimization
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
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
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
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];
}
