https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115167
--- Comment #6 from David Edelsohn ---
The libgcc failure is due to something not being built or rebuilt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115167
--- Comment #3 from David Edelsohn ---
On PPC64 Linux, gcc-rich-location.o now has undefined references to
range_label_for_type_mismatch:
$ nm -BCpg gcc-rich-location.o | grep range_label_for_type_mismatch
U vtable for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115167
David Edelsohn changed:
What|Removed |Added
Last reconfirmed||2024-05-20
Ever confirmed|0
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
Unfortunately r15-636-g770657d02c986c causes a bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #9 from David Edelsohn ---
The patch in comment 6 succeeds for me, but it seems more of a heavy-handed
band-aid that confirms the symptom, but covers up the problem.
Something in GCC apparently has generated invalid IR that was not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113507
--- Comment #4 from David Edelsohn ---
rs6000-ibm-aix doesn't exist anymore. This should have been configured as
powerpc-ibm-aix7.2 . Maybe there is some magic about the "powerpc" name?
Those variables are provided by generated files and
reconfirmed||2023-12-05
CC||aoliva at gcc dot gnu.org,
||dje at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868
--- Comment #2 from David Edelsohn ---
Narrowing the ISA dialect range accepted by the assembler is good in theory to
catch problems. We need to ensure that this doesn't break a lot of existing
code and make POWER more tedious.
Most people
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #11 from David Edelsohn ---
GIMPLE supports must_tail, but it is not exposed at the sources level /
attributes in GCC.
CPython is not adding the LLVM JIT at runtime. The proposal is to utilize LLVM
at build time to generate code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #9 from David Edelsohn ---
Brandt Bucher: A JIT compiler for CPython
https://www.youtube.com/watch?v=HxSHIpEQRjs
https://github.com/brandtbucher/cpython/tree/justin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
David Edelsohn changed:
What|Removed |Added
Priority|P3 |P2
Ever confirmed|0
-improvement
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
https://reviews.llvm.org/D99517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111246
--- Comment #17 from David Edelsohn ---
I'm glad that we have confirmed that the GCC and LLVM code generation for
PowerPC are correct for the memory model. And now your translation tool is more
accurate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111246
--- Comment #14 from David Edelsohn ---
The conditional branch always will proceed to the next instruction, so the code
that you showed in the PR is a correct "optimization" of the original code, but
the processor does execute the conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111246
--- Comment #10 from David Edelsohn ---
If I compile your testcase with either GCC 11.3 or GCC trunk, GCC produces
P1:
.LFB1:
.cfi_startproc
.localentry P1,1
pld 9,.LANCHOR0+8@pcrel
sync
lwz 9,0(9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111246
--- Comment #7 from David Edelsohn ---
Have you reached out to Paul McKenney (now at Meta) who suggested the
instruction sequences to implement the C/C++ memory for PowerPC?
https://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111246
David Edelsohn changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
David Edelsohn changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #36 from David Edelsohn ---
I don't know enough FORTRAN90 to instruct the compiler to use an external
function as if it were native.
EXTERNAL :: MYFUNC
changes the calling convention.
But if I manually change the assembly code so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #34 from David Edelsohn ---
AIX POWER BE output:
$ ./a.out
val(fortran): 65 A
val(fortran):0
val(fortran):0
val_c: char(65)='A'
val_c: char(65)='A'
val_c: char(804399656)='('
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #32 from David Edelsohn ---
i think that I see part of the difference. The 005t.original dump shows
(intermingled with sources)
! call val ("B","B")
val (&"B"[1]{lb: 1 sz: 1}, "B", 1, 1);
! call val ("A",char(65))
val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #31 from David Edelsohn ---
Yes, &"B"[1], is not shifted because it is a reference. The important
different is "B" is passed left-shifted, but 65 is passed right-shifted.
call val ("B","B") OK
call val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #29 from David Edelsohn ---
I don't know if this is a BE issue or a struct issue. AIX doesn't pass
characters in structs normally.
Is there any other debugging output from the GFORTRAN other than parse?
-fdump-lang-all doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #27 from David Edelsohn ---
GFORTRAN parse output describes the characters as follow
symtree: 'char'|| symbol: 'char'
type spec : (UNKNOWN 0)
attributes: (PROCEDURE INTRINSIC-PROC FUNCTION
||dje at gcc dot gnu.org
Last reconfirmed||2023-07-18
Ever confirmed|0 |1
--- Comment #16 from David Edelsohn ---
As I wrote in issue 110360, the bug appears to be the memory layout and padding
assumed by GFortran that does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110614
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc*-*-*
Beginning with
commit dd86a5a69cbda40cf76388a65d3317c91cb2b501
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #10 from David Edelsohn ---
Please be careful about the effect on AIX. AIX defaults to long-double-64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
--- Comment #11 from David Edelsohn ---
One can pass command line arguments to the AIX linker through a file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #11 from David Edelsohn ---
Have you looked on the GCC mailing list for zero-extend elimination (zee) and
sign-extend elimination (see)? The many, previous proposals for such passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #12 from David Edelsohn ---
We're working to add a Power10 system to the Compile Farm. The systems are at
OSUOSL, but Power10 doesn't have official KVM support so the interface to the
OpenStack management system is complicated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108734
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107916
David Edelsohn changed:
What|Removed |Added
Last reconfirmed||2022-11-29
Ever confirmed|0
: target
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
Target Milestone: ---
Target: powerpc64le-*-linux
https://github.com/openzfs/zfs/pull/14234
GCC codegen https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107781
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107239
--- Comment #1 from David Edelsohn ---
https://twitter.com/novacisko/status/1580056176040980481
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
object duplicated without constructor
problem is at line 592 - lambda in co_await
https://godbolt.org/z/nz1coM5YP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107221
David Edelsohn changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Keywords: build
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
CC: redi at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
in_shutdown is declared within #ifdef ATOMIC_FDE_FAST_PATH but used outside the
scope of that macro. This causes an undeclared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106855
--- Comment #2 from David Edelsohn ---
dwarf2out.cc uses XCOFF_DEBUGGING_INFO to emit DWARF information with XCOFF
syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106855
David Edelsohn changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
New.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106637
David Edelsohn changed:
What|Removed |Added
Last reconfirmed||2022-08-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
--- Comment #20 from David Edelsohn ---
Double-double has advantages and disadvantages. You're welcome to debate
William Kahan about the choice instead of making snarky comments here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
David Edelsohn changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/29_atomics/headers/stdatomic.h/
c_compat.cc:95: error
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
Excess errors:
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/shared_ptr_atomic.h:39
5: error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955
--- Comment #26 from David Edelsohn ---
As Bill mentioned, one can increase the alignment of a large constant, but
there is no way for the hooks that set alignment to recognize that the constant
will be assigned to variable with stricter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103759
David Edelsohn changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103759
David Edelsohn changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-*-* i386-*-*
memcpy-chk, memmove-chk, mempcpy-chk, memset-chk, stpcpy-chk test cases now all
fail in 32 bit mode.
https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103004
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910
--- Comment #7 from David Edelsohn ---
Sandra checked in a large number of testcases for interoperability that were
broken from the outset on all platforms -- I saw them failing on multiple Linux
architectures, not just AIX. The testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102882
David Edelsohn changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
The 96088 testcases are failing on AIX.
Does this testcase require overriding operator new[] in the library itself, not
only the testcase? The default build options
||dje at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from David Edelsohn ---
Gaius reports fixed.
|RESOLVED
CC||dje at gcc dot gnu.org
--- Comment #2 from David Edelsohn ---
Gaius reports fixed.
|RESOLVED
CC||dje at gcc dot gnu.org
--- Comment #3 from David Edelsohn ---
Gaius reports fixed.
||dje at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #5 from David Edelsohn ---
Gaius reports fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #18 from David Edelsohn ---
Yea! That fixes the *worst* of the memory growth problem for me.
It still is growing, but much more slowly. RSS now grows from 569788 to 642076
for the final function, instead of 783896 before it died
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #15 from David Edelsohn ---
I annotated execute_vrp_threader() to call getrusage() and print the size of
RSS around each call to threader.thread_jumps(). It consistently is growing,
but not in the threader itself. Was the former
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #14 from David Edelsohn ---
I tried the patch, but, unfortunately, it exceeds the memory limit in the same
manner.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #12 from David Edelsohn ---
GCC non-quiet mode shows:
...
g_31_31_16 f_31_31_17 g_31_31_17 f_31_31_23 g_31_31_23 f_31_31_24 g_31_31_24
f_31_31_25 g_31_31_25 f_31_31_29 g_31_31_29 f_31_31_30 g_31_31_30 f_31_31_31
g_31_31_31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #11 from David Edelsohn ---
tree VRP threader : 0.25 ( 2%) 0.03 ( 1%) 0.76 ( 1%)
7804k ( 2%)
Despite that report output, prior to the two patches ending with
ef1e524fd87a679f5da06116029c66a84daac80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #7 from David Edelsohn ---
Have you tried a native PPC64LE Linux build?
AIX defaults to 32 bit, and it's big endian. I wouldn't expect that to affect
the memory usage, but I'm mentioning it.
Did you try to compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
David Edelsohn changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org, law at gcc dot gnu.org
Target Milestone: ---
After the VRP jump threader replacement on Monday, September 27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102349
--- Comment #8 from David Edelsohn ---
This needs an additional adjustment. The encoding decoration needs to be
applied if the decl isn't an alias. That means both a null summary *OR* the
decl is not explicitly an alias.
I'm proposing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102349
--- Comment #7 from David Edelsohn ---
As we discussed on IRC
symtab_node::exists (decl) && symtab_node::get (decl)->alias
seems better because that function does not need to create the summary for its
internal use. The function should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102349
--- Comment #1 from David Edelsohn ---
I can't duplicate this failure in a native build. And rs6000.c:21750 doesn't
correspond to any statement. Can you provide some additional information or
source code context?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102148
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147
--- Comment #5 from David Edelsohn ---
Vlad privately commented: "I suspect order of processing conflicts might depend
on their representation."
The two representations may produce different results and the heuristics to
choose the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147
--- Comment #2 from David Edelsohn ---
Created attachment 51389
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51389=edit
Pre-processed subset of tree-vect-slp.c
$ gcc -O2 -fno-exceptions
produces different conflicts and register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147
David Edelsohn changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
IRA heuristics chooses different data structure encodings based on the register
size, and this produces different register allocation results.
This was discovered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99557
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102068
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
--- Comment #13 from David Edelsohn ---
I don't object to backporting Hao Chen's patch. It has baked sufficiently on
trunk that it seems relatively stable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
--- Comment #11 from David Edelsohn ---
We could backport Haochen's patch to AT.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102068
David Edelsohn changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
struct __attribute__((packed, aligned(2))) S {
double a;
char b;
};
extern "C" int printf(const char*, ...);
int main()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102029
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101984
David Edelsohn changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
As part of the warning code refactoring, alloc_max_size() was moved from
calls.c to gimple-ssa-warn-access.cc. The alloc_object_size_limit variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101959
--- Comment #2 from David Edelsohn ---
This may be related to 32 bit builds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101959
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
/tmp/GCC/./gcc/xgcc -B/tmp/GCC/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null
-f
self-test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3985
David Edelsohn changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Add appropriate SPDX license identifiers to GCC source code files.
https://spdx.org/licenses/
||dje at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from David Edelsohn ---
I already have a patch for the first part of this. This should test dg-require
target int128 and float128
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
The __int128 extended type should not be enabled in strict standard mode, e.g.,
not gnu extended standard.
auto typechk = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98171
--- Comment #1 from David Edelsohn ---
gcc119 should be functioning again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95549
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096
David Edelsohn changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
1 - 100 of 1155 matches
Mail list logo
