[Bug bootstrap/115167] [15 Regression] CFG edge visualization to path-printing bootstrap failure

[dje at gcc dot gnu.org via Gcc-bugs]

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.

[Bug bootstrap/115167] [15 Regression] CFG edge visualization to path-printing bootstrap failure

[dje at gcc dot gnu.org via Gcc-bugs]

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 range_label_for_type_mismatch
 U range_label_for_type_mismatch::get_text(unsigned int) const

and c-objc-common.o provides definitions:

$ nm -BCpg c-objc-common.o | grep range_label_for_type_mismatch
1140 T range_label_for_type_mismatch::get_text(unsigned int) const
 V vtable for range_label_for_type_mismatch

AIX similarly has the undefined symbols:

$ /usr/bin/nm -BCpgl gcc-rich-location.o | grep range_label_for_type_mismatch 
 - U _ZTV29range_label_for_type_mismatch
 - U ._ZNK29range_label_for_type_mismatch8get_textEj

and the definition in c-objc-common.o:

$ /usr/bin/nm -BCpgl c-objc-common.o | grep range_label_for_type_mismatch 
  4592 T ._ZNK29range_label_for_type_mismatch8get_textEj
 13828 D _ZNK29range_label_for_type_mismatch8get_textEj
 14000 D _ZTV29range_label_for_type_mismatch


Linux seems to accept the undefined symbols in Fortran, but AIX semantics
requires a definition.

My instinct is that this is a "bug" for all systems, but Linux semantics
ignores or garbage collects the undefined symbol.

[Bug bootstrap/115167] [15 Regression] CFG edge visualization to path-printing bootstrap failure

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-20
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from David Edelsohn  ---
The CFARM wiki provides the following recommendation to build on AIX

$ PATH=/opt/freeware/bin:$PATH

$ .../src/configure --disable-werror --enable-languages=c,c++
--with-gmp=/opt/cfarm --with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch
--with-included-gettext

$ make SHELL=/bin/bash CONFIG_SHELL=/bin/bash


Also, gcc119 would be a much better choice than gcc111.

[Bug bootstrap/115167] New: CFG edge visualization to path-printing bootstrap failure

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 115167
   Summary: CFG edge visualization to path-printing bootstrap
failure
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  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 failure on AIX when
building f951 in stage2.  cc1 and cc1plus link successfully. There doesn't seem
to be a similar failure for powerpc64-linux BE or LE.

The failure is

ld: 0711-317 ERROR: Undefined symbol: _ZTV29range_label_for_type_mismatch
ld: 0711-317 ERROR: Undefined symbol:
._ZNK29range_label_for_type_mismatch8get_textEj

which corresponds to

vtable for range_label_for_type_mismatch
range_label_for_type_mismatch::get_text(unsigned int) const

I suspect that something is not being explicitly instantiated, which is running
afoul of the AIX linker.

Somehow your patch is causing the f951 compiler to reference these additional,
undefined symbols.  I suspect that they also are undefined for Linux targets,
but the linker ignores the error and nothing is amiss if the symbols never are
called.

It seems that the patch has created a reference to get_text() that only has
been instantiated for the C languages:
./c/c-objc-common.cc:range_label_for_type_mismatch::get_text (unsigned
/*range_idx*/) const
./cp/error.cc:range_label_for_type_mismatch::get_text (unsigned /*range_idx*/)
const

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[dje at gcc dot gnu.org via Gcc-bugs]

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 caught
earlier.  GCC should not generate

POINTER = POINTER CMP POINTER

But the trunk should not be left in a broken state as per GCC development
policy.  The broken trunk interferes with the work of other developers and may
mask other broken patches being committed.

This patch should be reverted until the source of the problem is discovered and
fixed.

[Bug target/113507] can't build a cross compiler to rs6000-ibm-aix7.2

[dje at gcc dot gnu.org via Gcc-bugs]

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 apparently something is not
generating them when building a cross compiler.

[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Target|nvptx   |nvptx, powerpc-ibm-aix*
   Last reconfirmed||2023-12-05
 CC||aoliva at gcc dot gnu.org,
   ||dje at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds

[dje at gcc dot gnu.org via Gcc-bugs]

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 want to download a pre-built package.  If someone downloads source
code, they want it to configure, build and run without problems.

While this change will ensure that new packages are more strictly conformant
and may not cause problems with new Linux distro releases, it could prevent
older packages from building with newer releases of GCC.

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

[dje at gcc dot gnu.org via Gcc-bugs]

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 templates that can be copied into the CPython
binary and patched with relocations.

CALL_EXPR_MUST_TAIL_CALL and libgccjit are not sufficient for the CPython plan.
 The plan does not propose connecting CPython to an existing JIT in LLVM (or
GCC).

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

[dje at gcc dot gnu.org via Gcc-bugs]

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

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

   Priority|P3  |P2
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-16
 Status|UNCONFIRMED |NEW

--- Comment #4 from David Edelsohn  ---
https://gcc.gnu.org/pipermail/gcc/2021-April/235882.html

https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html

The lack of this feature is motivating CPython to rely on LLVM for its JIT in
future releases.

[Bug middle-end/112558] New: Add musttail tail call feature equivalent to LLVM and Clang

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112558
   Summary: Add musttail tail call feature equivalent to LLVM and
Clang
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: internal-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

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[dje at gcc dot gnu.org via Gcc-bugs]

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.

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[dje at gcc dot gnu.org via Gcc-bugs]

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 branch in the original code.  Is the
simulator performing an optimization?  Something seems to have transformed the
code.

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[dje at gcc dot gnu.org via Gcc-bugs]

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)
cmpw 0,9,9<*** compare
bne- 0,$+4<*** branch conditional
isync <*** isync
pld 10,.LANCHOR0@pcrel
li 8,1
stw 8,0(10)
pld 10,.LANCHOR0+16@pcrel
stw 9,0(10)
blr

which contains the branch conditional that should satisfy the processor memory
model.  I'm not seeing the unconditional branch that you see in your example.

Your link to Compiler Explorer code generated by Clang also shows a branch
conditional

P1: # @P1
.quad   .Lfunc_begin1
.quad   .TOC.@tocbase
.quad   0
.Lfunc_begin1:
addis 3, 2, y@toc@ha
ld 3, y@toc@l(3)
sync
li 5, 1
lwz 3, 0(3)
cmpd 7, 3, 3  <*** compare
bne- 7, .+4   <*** branch conditional
isync <*** isync

What is generating or parsing or interpreting the unconditional branch shown in
your pasted code?

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[dje at gcc dot gnu.org via Gcc-bugs]

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

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-08-31

--- Comment #5 from David Edelsohn  ---
There is no lwfence instruction in PowerPC.  We will need to examine what code
generation change is necessary.  Did you intend to suggest lwsync?

[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types

[dje at gcc dot gnu.org via Gcc-bugs]

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 from David Edelsohn  ---
The new testcases in the testsuite for this PR are failing.  Is anyone working
on these new failures? Is this being tracked in this PR or a new PR for the
failures?

[Bug fortran/110360] ABI issue with character,value dummy argument

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #38 from David Edelsohn  ---
As mentioned by Mikael in PR110419, GFORTRAN calling convention has a hole.

The problem on PowerPC Big Endian is that sometimes GFORTRAN passes a character
as a character and sometimes it passes a character as a STRING of length 1
passed by value.  On Little Endian systems, the single value happens to end up
in the same location in the register.  On Big Endian systems, the values are at
opposite ends of the register.

Or to put it another way, the GFORTRAN internal "type" of CHARACTER as
represented by/to GCC type system is inconsistent.  GFORTRAN is breaking the
GCC type system, which causes the parameter to be represented differently in
the register.

[Bug fortran/110360] ABI issue with character,value dummy argument

[dje at gcc dot gnu.org via Gcc-bugs]

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 that "val" calls a C function a
print the values

#include 

void
val_0 (int x, int y)
{
  printf ("char(0x%x = %d) = %c 0 0 %c (LEN = %d)\n",
x, x, (char) (x>>24), (char) (x), y);
}

it produces the following output (32 bit):

char(0x4100 = 1090519040) = A 0 0  (LEN = 1)
char(0x41 = 65) =  0 0 A (LEN = 1)
char(0x41 = 65) =  0 0 A (LEN = 1)

for 

  call val   ("A")
  call val   (c)
  call val   (char(a))

to demonstrate exactly what I see on big endian POWER.

[Bug fortran/110360] ABI issue with character,value dummy argument

[dje at gcc dot gnu.org via Gcc-bugs]

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)='('

[Bug fortran/110360] ABI issue with character,value dummy argument

[dje at gcc dot gnu.org via Gcc-bugs]

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 (&"A"[1]{lb: 1 sz: 1}, "A", 1, 1);
!   call val  ("A",char(a))
  {
character(kind=1) char.6;

char.6 = (character(kind=1)) a;
val (&"A"[1]{lb: 1 sz: 1}, char.6, 1, 1);
  }
!  call val  ("A",mychar(65))

  {
static integer(kind=4) C.2654 = 65;
character(kind=1) str.7[1];

mychar ((character(kind=1)[1:1] *) , 1, );
val (&"A"[1]{lb: 1 sz: 1}, str.7[0], 1, 1);
  }
!  call val  ("A",mychar(a))
  {
character(kind=1) str.8[1];

mychar ((character(kind=1)[1:1] *) , 1, );
val (&"A"[1]{lb: 1 sz: 1}, str.8[0], 1, 1);
  }

char(65) is folded by the FORTRAN front-end to "A", so it is passed in the same
manner that elicits the shift.  The rest of the calls pass 65.  The string is
left-shifted and the number is right-shifted.  GFORTRAN seems to assume that
passing a STRING by value will be padded the same as a number or character,
which isn't accurate.

I'm leaning back to big-endian vs little-endian, and not a struct issue.  A
little-endian STRING will start at the lowest address and a big-endian STRING
will start at the highest address.

[Bug fortran/110360] ABI issue with character,value dummy argument

[dje at gcc dot gnu.org via Gcc-bugs]

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  ("A",char(65)) OK
  call val  ("A",char(a))  WRONG
  call val  ("A",mychar(65))   WRONG
  call val  ("A",mychar(a))WRONG
  call val  ("1",c)
  call val  ("1",(c))

  subroutine val (x, c)
character(kind=1), intent(in) :: x  ! control: pass by reference
character(kind=1), value  :: c
print *, "by value(kind=1): ", x
print *, "by value(kind=1): ", c
  end

  character function mychar (i)
integer, intent(in) :: i
mychar = char (i)
  end

I'm confused that char(65) produces correct code, while char(a), mychar(65) and
mychar(a) all produce incorrect code, especially char(65) versus char(a), where
a=65.  If I check in mychar, it receives the value 65 and char(65) produces
'A'. I don't understand why GFORTRAN believes that char(65) should produce a
left-shifted value, and "A" passed by reference is shifted in memory to compare
correctly.

[Bug fortran/110360] ABI issue with character,value dummy argument

[dje at gcc dot gnu.org via Gcc-bugs]

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 seem to produce any additional output.

I'm trying to guess / brainstorm about why GCC sometimes would shift the char
value and other times would not.

Maybe something about the way that GFORTRAN is passing the string by value. 
257.optimized shows

  val (&"B"[1]{lb: 1 sz: 1}, "B", 1, 1);
  val (&"A"[1]{lb: 1 sz: 1}, "A", 1, 1);
  val (&"A"[1]{lb: 1 sz: 1}, 65, 1, 1);
  val (&"A"[1]{lb: 1 sz: 1}, 65, 1, 1);
  val (&"A"[1]{lb: 1 sz: 1}, 65, 1, 1);
  _37 = c[1]{lb: 1 sz: 1};
  val (&"1"[1]{lb: 1 sz: 1}, _37, 1, 1);
  _38 = c[1]{lb: 1 sz: 1};
  val (&"1"[1]{lb: 1 sz: 1}, _38, 1, 1);

&"B"[1] is not shifted.  65 is not shifted.  "B" is shifted.

GFORTRAN is passing the value in different ways that trigger different parts of
the target ABI.  It seems to be assuming that those different parts of the ABI
and forms of parameter passing will produce the same results in terms of
padding, but that is not guaranteed.

[Bug fortran/110360] ABI issue with character,value dummy argument

[dje at gcc dot gnu.org via Gcc-bugs]

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 ARRAY-OUTER-DEPENDENCY)
result: char

  symtree: 'mychar'  || symbol: 'mychar'   
type spec : (CHARACTER 1 1)
attributes: (PROCEDURE INTERNAL-PROC  FUNCTION IMPLICIT-PURE CONTAINED)
result: mychar
Formal arglist: i

  CALL val (('B') ('B'))
  CALL val (('A') ('A'))
  CALL val (('A') (__char_1_i4[[((p:a) ((arg not-present)))]]))
  CALL val (('A') (mychar[[((65))]]))
  CALL val (('A') (mychar[[((p:a))]]))

258r.expand shows the shift of the function parameter:

(insn 114 113 115 11 (set (reg:SI 4 4)
(ashift:SI (reg:SI 4 4)
(const_int 24 [0x18]))) "value_9.f90":23:21 -1
 (nil))
(insn 115 114 116 11 (set (reg:SI 3 3)
(reg:SI 185)) "value_9.f90":23:21 -1
 (nil))
(call_insn 116 115 117 11 (parallel [
(call (mem:SI (symbol_ref:SI ("val.4[DS]") [flags 0x3] 
) [0 val S4 A8])
(const_int 32 [0x20]))
(use (const_int 0 [0]))
(clobber (reg:SI 96 lr))
]) "value_9.f90":23:21 -1
 (expr_list:REG_EH_REGION (const_int 0 [0])
(nil))
(expr_list (use (reg:SI 2 2))
(expr_list:SI (use (reg:SI 3 3))
(expr_list:QI (use (reg:SI 4 4))
(expr_list:SI (use (reg:SI 5 5))
(expr_list:SI (use (reg:SI 6 6))
(nil)))

The original tree is

  static void val (character(kind=1)[1:1] & restrict, character(kind=1)[1:1],
integer(kind=4), integer(kind=4));
  static integer(kind=4) a = 65;
  static character(kind=1) c[1:1] = "1";
  static character(kind=4) c4[1:1] = "\x00\x00\x004";

  val (&"B"[1]{lb: 1 sz: 1}, "B", 1, 1);
  val (&"A"[1]{lb: 1 sz: 1}, "A", 1, 1);
  {
character(kind=1) char.6;

char.6 = (character(kind=1)) a;
val (&"A"[1]{lb: 1 sz: 1}, char.6, 1, 1);
  }
  {
static integer(kind=4) C.2654 = 65;
character(kind=1) str.7[1];

mychar ((character(kind=1)[1:1] *) , 1, );
val (&"A"[1]{lb: 1 sz: 1}, str.7[0], 1, 1);
  }
  {
character(kind=1) str.8[1];

mychar ((character(kind=1)[1:1] *) , 1, );
val (&"A"[1]{lb: 1 sz: 1}, str.8[0], 1, 1);
  }
  val (&"1"[1]{lb: 1 sz: 1}, c[1]{lb: 1 sz: 1}, 1, 1);
  val (&"1"[1]{lb: 1 sz: 1}, c[1]{lb: 1 sz: 1}, 1, 1);


The issue may not be endianness but assumptions about struct padding.  I don't
know exactly how GFORTRAN represents CHARACTER.  I can elicit the same behavior
in C if I embed a "char" in a struct like

struct mychar {
   char c1;
};

  struct mychar mc;

  mc.c1 = 'A';

On AIX, structs are left padded.  A char passed in a 32 bit register is

-
|x|x|x|A|
-

but a char passed by value in a struct is

-
|A|x|x|x|
-

If GFORTRAN assumes that a scalar value and a value in a struct are passed in
registers with the same padding, that is not a valid, general assumption.

[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||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 not take into account endianness.

I have changed val() to print both c and x, and not halt.

  subroutine val (x, c)
character(kind=1), intent(in) :: x  ! control: pass by reference
character(kind=1), value  :: c
print *, "by value(kind=1): ", x
print *, "by value(kind=1): ", c
!if (c /= x)   stop 1
c = "*"
if (c /= "*") stop 2
  end


The output is:

 by value(kind=1): B
 by value(kind=1): B
 by value(kind=1): A
 by value(kind=1): A
 by value(kind=1): A
 by value(kind=1):<- c
 by value(kind=1): A
 by value(kind=1):<- c
 by value(kind=1): A
 by value(kind=1):<- c
 by value(kind=1): 1
 by value(kind=1):<- c
 by value(kind=1): 1
 by value(kind=1):<- c


The assembly language for the first few calls is

# call val  ("B","B")
lwz 31,LC..5(2)  LOAD ADDRESS of x
mr 3,31  COPY address to first parameter
li 6,1
li 5,1
lbzu 4,148(3)LOAD BYTE of c as second parameter
slwi 4,4,24  SHIFT c 24 bits
bl .val.4
# call val  ("A",char(65))
mr 30,31 COPY ADDRESS of x
li 6,1
li 5,1
lbzu 4,152(30)   LOAD BYTE of c as second parameter
slwi 4,4,24  SHIFT c 24 bits
mr 3,30  COPY address of first parameter
bl .val.4
# call val  ("A",char(a))
li 6,1
li 5,1
li 4,65  <- c NOT SHIFTED
mr 3,30  <- x
bl .val.4
# call val  ("A",mychar(65))
li 6,1
li 5,1
li 4,65  <- c NOT SHIFTED
mr 3,30  <- x
bl .val.4
# call val  ("A",mychar(a))
li 6,1
li 5,1
li 4,65  <- c NOT SHIFTED
mr 3,30  <- x
bl .val.4

GFortran is not taking account of endianness for the layout of values in memory
compared to constants loaded into registers.  This isn't an ABI issue of the
target, this is a memory layout and register layout issue of GFortran.

On a big endian system, a character / byte is loaded at the LSB, but GFortran
seems to be comparing it to a memory image with the character / byte stored at
the MSB, which would be correct for little endian.  In some cases, GFortran is
shifting the value and in other cases it is not.

GFortran does not seem to have a consistent view of the memory layout for
characters / bytes loaded into a larger object.

[Bug fortran/110360] ABI issue with character,value dummy argument

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #25 from David Edelsohn  ---
The problem on big endian systems is that GFortran is passing the character
with the wrong padding.

I have changed val() to print both c and x, and not halt.

  subroutine val (x, c)
character(kind=1), intent(in) :: x  ! control: pass by reference
character(kind=1), value  :: c
print *, "by value(kind=1): ", x
print *, "by value(kind=1): ", c
!if (c /= x)   stop 1
c = "*"
if (c /= "*") stop 2
  end


The output is:

 by value(kind=1): B
 by value(kind=1): B
 by value(kind=1): A
 by value(kind=1): A
 by value(kind=1): A
 by value(kind=1):<- c
 by value(kind=1): A
 by value(kind=1):<- c
 by value(kind=1): A
 by value(kind=1):<- c
 by value(kind=1): 1
 by value(kind=1):<- c
 by value(kind=1): 1
 by value(kind=1):<- c


The assembly language for the first few calls is

# call val  ("B","B")
lwz 31,LC..5(2)  LOAD ADDRESS of x
mr 3,31  COPY address to first parameter
li 6,1
li 5,1
lbzu 4,148(3)LOAD BYTE of c as second parameter
slwi 4,4,24  SHIFT c 24 bits
bl .val.4
# call val  ("A",char(65))
mr 30,31 COPY ADDRESS of x
li 6,1
li 5,1
lbzu 4,152(30)   LOAD BYTE of c as second parameter
slwi 4,4,24  SHIFT c 24 bits
mr 3,30  COPY address of first parameter
bl .val.4
# call val  ("A",char(a))
li 6,1
li 5,1
li 4,65  <- c NOT SHIFTED
mr 3,30  <- x
bl .val.4
# call val  ("A",mychar(65))
li 6,1
li 5,1
li 4,65  <- c NOT SHIFTED
mr 3,30  <- x
bl .val.4
# call val  ("A",mychar(a))
li 6,1
li 5,1
li 4,65  <- c NOT SHIFTED
mr 3,30  <- x
bl .val.4

GFortran is not taking account of endianness for the layout of values in memory
compared to constants loaded into registers.  This isn't an ABI issue of the
target, this is a memory layout and register layout issue of GFortran.

Let me know if you need more information or tests.

[Bug tree-optimization/110614] [14 Regression] ICE in vect_supportable_dr_alignment

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-07-10
 Ever confirmed|0   |1

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

[Bug tree-optimization/110614] New: [14 Regression] ICE in vect_supportable_dr_alignment

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 110614
   Summary: [14 Regression] ICE in vect_supportable_dr_alignment
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  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 
Date:   Thu Jun 22 11:40:46 2023 +0200

A number of GCC testsuite test cases ICE in vect_supportable_dr_alignment()

gcc/testsuite/gcc.dg/torture/pr68379.c

$ ./xgcc -B./ -S -O2 -mcpu=power7 pr68379.c 
during GIMPLE pass: vect
pr68379.c: In function ‘fn1’:
pr68379.c:6:1: internal compiler error: Segmentation fault
6 | fn1 ()
  | ^~~
0x10c1d833 crash_signal
/home/dje/src/gcc/gcc/toplev.cc:314
0x11b4ebd0 vect_supportable_dr_alignment(vec_info*, dr_vec_info*, tree_node*,
int)
/home/dje/src/gcc/gcc/tree-vect-data-refs.cc:6833
0x11b53717 vect_enhance_data_refs_alignment(_loop_vec_info*)
/home/dje/src/gcc/gcc/tree-vect-data-refs.cc:2044
0x10fc35bb vect_analyze_loop_2
/home/dje/src/gcc/gcc/tree-vect-loop.cc:2783
0x10fc4d8f vect_analyze_loop_1
/home/dje/src/gcc/gcc/tree-vect-loop.cc:3316
0x10fc56bb vect_analyze_loop(loop*, vec_info_shared*)
/home/dje/src/gcc/gcc/tree-vect-loop.cc:3470
0x110174e7 try_vectorize_loop_1
/home/dje/src/gcc/gcc/tree-vectorizer.cc:1064
0x110174e7 try_vectorize_loop
/home/dje/src/gcc/gcc/tree-vectorizer.cc:1180
0x11017fa3 execute
/home/dje/src/gcc/gcc/tree-vectorizer.cc:1296

The test cases succeed with Power8, Power9, or Power10, but ICE with
-mcpu=power7. command line option.

[Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64

[dje at gcc dot gnu.org via Gcc-bugs]

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.

[Bug libgcc/60939] AIX: exceptions not caught when calling function via pointer

[dje at gcc dot gnu.org via Gcc-bugs]

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.

[Bug target/103784] suboptimal code for returning bool value on target ppc

[dje at gcc dot gnu.org via Gcc-bugs]

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.

[Bug target/108315] -mcpu=power10 changes ABI

[dje at gcc dot gnu.org via Gcc-bugs]

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.

[Bug c/108734] powerpc: False Detection of __atomic_*_8 Builtins

[dje at gcc dot gnu.org via Gcc-bugs]

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 from David Edelsohn  ---
Rohan,

I'm sorry that this is confusing, but the issue is cockpit error.

__has_builtin() does not mean that the builtin is inlined.  It only means that
GCC recognizes the builtin.  That is how __has_builtin() is documented.  In 32
bit mode, GCC emits an external reference for the builtin: 8 byte atomic
requires libatomic library, which is not linked by default (and shouldn't be).

[Bug target/107916] PPC VSX code generation for OpenZFS

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug target/107916] New: PPC VSX code generation for OpenZFS

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107916
   Summary: PPC VSX code generation for OpenZFS
   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
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://gcc.godbolt.org/z/bhPo9sWsx

Clang codegen https://gcc.godbolt.org/z/4rTEe3WMG

Clang is relatively compact and efficient
.LBB0_2:# =>This Inner Loop Header: Depth=1
lxvd2x 1, 0, 4
addi 4, 4, 16
xxswapd 1, 1
xxmrghw 40, 0, 1
xxmrglw 41, 0, 1
vaddudm 7, 7, 8
vaddudm 6, 6, 9
vaddudm 1, 7, 1
vaddudm 5, 6, 5
vaddudm 0, 1, 0
vaddudm 4, 5, 4
vaddudm 3, 0, 3
vaddudm 2, 4, 2
bdnz .LBB0_2

GCC is rather less efficient.

[Bug c++/107781] strchrnul' was not declared in this scope; did you mean 'strchr'? For contracts for canadian compilation

[dje at gcc dot gnu.org via Gcc-bugs]

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 from David Edelsohn  ---
AIX as well.

Although, apparently strchrnul() is provided a z/OS extension, so, hey, you can
build it there too! :-P.

[Bug libstdc++/107239] Coroutine code generation bug

[dje at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from David Edelsohn  ---
https://twitter.com/novacisko/status/1580056176040980481

[Bug libstdc++/107239] New: Coroutine code generation bug

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107239
   Summary: Coroutine code generation bug
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: C++-Coroutine, wrong-code
  Severity: normal
  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

[Bug bootstrap/107221] [13 Regression] libstdc++ EH no matching function __gnu_cxx::__scoped_lock::__scoped_lock

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-10-11
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Edelsohn  ---
Where is __GTHREADS defined now?

-#include 

...

+#ifdef __GTHREADS
   // A single mutex controlling emergency allocations.
   __gnu_cxx::__mutex emergency_mutex;
+  using __scoped_lock = __gnu_cxx::__scoped_lock;
+#else
+  int emergency_mutex = 0;
+  struct __scoped_lock { explicit __scoped_lock(int) { } };
+#endif

[Bug bootstrap/107221] New: [13 Regression] libstdc++ EH no matching function __gnu_cxx::__scoped_lock::__scoped_lock

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107221
   Summary: [13 Regression] libstdc++ EH no matching function
__gnu_cxx::__scoped_lock::__scoped_lock
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  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*

The fix for PR68606 introduced references to
__gnu_cxx::__scoped_lock::__scoped_lock that are not always defined, causing a
bootstrap failure on AIX.

libtool: compile:  /tmp/GCC/./gcc/xgcc -B/tmp/GCC/./gcc/
-B/nasfarm/edelsohn/ins
tall/GCC/powerpc-ibm-aix7.2.5.0/bin/
-B/nasfarm/edelsohn/install/GCC/powerpc-ibm
-aix7.2.5.0/lib/ -isystem
/nasfarm/edelsohn/install/GCC/powerpc-ibm-aix7.2.5.0/i
nclude -isystem
/nasfarm/edelsohn/install/GCC/powerpc-ibm-aix7.2.5.0/sys-include
 -fno-checking -DHAVE_CONFIG_H -I..
-I/nasfarm/edelsohn/src/src/libstdc++-v3/../
libiberty -I/nasfarm/edelsohn/src/src/libstdc++-v3/../include -D_GLIBCXX_SHARED 
-I/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/powerpc-ibm-aix7.2.5.0
-I/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include
-I/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++
-I/nasfarm/edelsohn/install/include -I/nasfarm/edelsohn/install/include -g -O2
-DIN_GLIBCPP_V3 -Wno-error -c cp-demangle.c  -fPIC -DPIC -o cp-demangle.o
/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++/eh_alloc.cc: In member
function 'void* {anonymous}::pool::allocate(std::size_t)':
/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++/eh_alloc.cc:239:54: error: no
matching function for call to '__gnu_cxx::__scoped_lock::__scoped_lock(int&)'
  239 |   __gnu_cxx::__scoped_lock sentry(emergency_mutex);
  |  ^
In file included from
/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++/eh_alloc.cc:37:
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/ext/concurrence.h:240:14:
note: candidate: '__gnu_cxx::__scoped_lock::__scoped_lock(__mutex_type&)'
  240 | explicit __scoped_lock(__mutex_type& __name) : _M_device(__name)
  |  ^
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/ext/concurrence.h:240:42:
note:   no known conversion for argument 1 from 'int' to
'__gnu_cxx::__scoped_lock::__mutex_type&'
  240 | explicit __scoped_lock(__mutex_type& __name) : _M_device(__name)
  |~~^~
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/ext/concurrence.h:236:5:
note: candidate: '__gnu_cxx::__scoped_lock::__scoped_lock(const
__gnu_cxx::__scoped_lock&)'
  236 | __scoped_lock(const __scoped_lock&);
  | ^
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/ext/concurrence.h:236:19:
note:   no known conversion for argument 1 from 'int' to 'const
__gnu_cxx::__scoped_lock&'
  236 | __scoped_lock(const __scoped_lock&);
  |   ^~~~
make[5]: *** [Makefile:778: eh_alloc.lo] Error 1

[Bug bootstrap/107018] New: [13 Regression] libgcc unwind-dw2-fde references undeclared variable

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107018
   Summary: [13 Regression] libgcc unwind-dw2-fde references
undeclared variable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: 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 variable that causes libgcc
build to fail and breaks bootstrap.



#ifdef ATOMIC_FDE_FAST_PATH
#include "unwind-dw2-btree.h"

static struct btree registered_frames;
static bool in_shutdown;

static void
release_registered_frames (void) __attribute__ ((destructor (110)));
static void
release_registered_frames (void)
{
  /* Release the b-tree and all frames. Frame releases that happen later are
   * silently ignored */
  btree_destroy (_frames);
  in_shutdown = true;
}

static void
get_pc_range (const struct object *ob, uintptr_type *range);
static void
init_object (struct object *ob);

#else

[Bug bootstrap/106855] [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX

[dje at gcc dot gnu.org via Gcc-bugs]

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.

[Bug bootstrap/106855] [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-09-06
 Status|UNCONFIRMED |NEW

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

[Bug bootstrap/106855] New: [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 106855
   Summary: [13 Regression] Removal of stabs/xcoff debugging broke
bootstrap on AIX
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

New.

[Bug target/106637] docs: link to www.bullfreeware.com is dead

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-16
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from David Edelsohn  ---
ATOS / Groupe Bull has discontinued its Freeware offering.  The link should be
removed from the web page.

[Bug middle-end/26374] Compile failure on long double

[dje at gcc dot gnu.org via Gcc-bugs]

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.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #25 from David Edelsohn  ---
Fixed

[Bug libstdc++/104123] New: 29_atomics/headers/stdatomic.h/c_compat.cc fails on AIX

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 104123
   Summary: 29_atomics/headers/stdatomic.h/c_compat.cc fails on
AIX
   Product: gcc
   Version: 12.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: ---
Target: powerpc-ibm-aix*

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/29_atomics/headers/stdatomic.h/
c_compat.cc:95: error: 'size_t' was not declared in this scope; did you mean
'st
d::size_t'?
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/stdatomic.h:35: error:
temp
late argument 1 is invalid

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/29_atomics/headers/stdatomic.h/
c_compat.cc:95: error: template argument 2 is invalid
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/29_atomics/headers/stdatomic.h/
c_compat.cc:96: error: 'ptrdiff_t' was not declared in this scope; did you mean 
'std::ptrdiff_t'?

/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/stdatomic.h:35: error:
temp
late argument 1 is invalid
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/29_atomics/headers/stdatomic.h/
c_compat.cc:96: error: template argument 2 is invalid


This probably is an issue that AIX 7.2 headers are not C++-safe.  This will be
fixed in AIX 7.3.

Does this testsuite failure need to be addressed in fixincludes or in the
stdatomic.h header?

[Bug libstdc++/104101] New: [12 Regression] libstdc++ shared_ptr_atomic fails on AIX

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 104101
   Summary: [12 Regression] libstdc++ shared_ptr_atomic fails on
AIX
   Product: gcc
   Version: 12.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: ---
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: '__thread_relax' is not a member of 'std::__detail'
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/shared_ptr_atomic.h:40
4: error: '__thread_relax' is not a member of 'std::__detail'

[Bug middle-end/57955] [9/10/11/12 Regression] Uniquization of constants reduces alignment of initializers

[dje at gcc dot gnu.org via Gcc-bugs]

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 alignment.

[Bug tree-optimization/103759] [12 Regression] memcpy-chk failure for 32 bits

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/103759] [12 Regression] memcpy-chk failure for 32 bits

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-12-17
 Status|UNCONFIRMED |NEW

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

[Bug tree-optimization/103759] New: [12 Regression] memcpy-chk failure for 32 bits

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103759
   Summary: [12 Regression] memcpy-chk failure for 32 bits
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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/pipermail/gcc-testresults/2021-December/742567.html
https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/742553.html
https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/742564.html
https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/742535.html

between r12-6029 and r12-6031

[Bug libgcc/103004] [12 regression] r12-4416 breaks backtrace on PPC64 Big-endian

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-03
 Status|UNCONFIRMED |NEW

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

[Bug testsuite/102910] cf-descriptor-5-c.c fails to build

[dje at gcc dot gnu.org via Gcc-bugs]

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 should have been XFAILed when
initially checked in.  If the testcases had been XFAILed, it would have been
apparent that the cf-descriptor-5-c.c testcase was not written portably for
different OSes.

My patch apparently swapped which targets produced UNRESOLVED and which
produced FAIL (now PASS).

Known failing portability testcases should not have been checked in to the GCC
repository.

alloca() is a mess.  If you have better visibility into the portability of
alloca() across platforms, you're welcome to fix it.  I suggest that having
different targets use different definitions of alloca muddles the test.  If the
intention is for the system header to substitute __builtin_alloca() for
alloca(), then it suggest would be better use that from the beginning.  The
testcase seems to intend to test C-Fortran interoperability, not alloca().

[Bug testsuite/102910] cf-descriptor-5-c.c fails to build

[dje at gcc dot gnu.org via Gcc-bugs]

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 from David Edelsohn  ---
Previously the test case was unresolved because it referenced alloca without a
declaration.

char *adata = (char *) alloca (n);

If you want to call __builtin_alloca() because this is a testcase for GCC,
which provides __builtin_alloca(), fine.  You should call it directly and not
alloca().

If you want to call alloca(), then you need logic for the different systems
that declare alloca() in different header files.

#ifdef alloca

is wrong because it makes the testcase system dependent and tests different
behavior.

[Bug libstdc++/102882] [AIX] 23_containers 96088 testsuite failures

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-22

--- Comment #3 from David Edelsohn  ---
The patch for unordered_set fixes that testcase.

[Bug libstdc++/102882] New: [AIX] 23_containers 96088 testsuite failures

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102882
   Summary: [AIX] 23_containers 96088 testsuite failures
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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 for libstdc++ on AIX do not permit
operator overloading. Maybe it requires XFAIL on AIX.

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/23_containers/unordered_set/960
88.cc:42: void test01(): Assertion '__gnu_test::counter::count() == 3' failed.
operator new is called 
operator new is called 
FAIL: 23_containers/unordered_set/96088.cc execution test

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/23_containers/unordered_map/960
88.cc:42: void test01(): Assertion '__gnu_test::counter::count() == 3' failed.
operator new is called 
operator new is called 
FAIL: 23_containers/unordered_map/96088.cc execution test

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/23_containers/unordered_multima
p/96088.cc:43: void test01(): Assertion '__gnu_test::counter::count() == 3'
fail
ed.
operator new is called 
operator new is called 
FAIL: 23_containers/unordered_multimap/96088.cc execution test

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/23_containers/unordered_multise
t/96088.cc:43: void test01(): Assertion '__gnu_test::counter::count() == 3'
fail
ed.
operator new is called 
operator new is called 
FAIL: 23_containers/unordered_multiset/96088.cc execution test

[Bug modula2/102325] gm2 testsuite drivers should be unique

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dje at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from David Edelsohn  ---
Gaius reports fixed.

[Bug modula2/102323] gm2 testsuite needs to be parallelized

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||dje at gcc dot gnu.org

--- Comment #2 from David Edelsohn  ---
Gaius reports fixed.

[Bug modula2/102339] gm2 testsuite leaves many files behind

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||dje at gcc dot gnu.org

--- Comment #3 from David Edelsohn  ---
Gaius reports fixed.

[Bug modula2/102344] gm2/pim/fail/TestLong4.mod FAILs

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||dje at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from David Edelsohn  ---
Gaius reports fixed.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[dje at gcc dot gnu.org via Gcc-bugs]

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 on an intermediate
function.

Definitely an improvement and good catch.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[dje at gcc dot gnu.org via Gcc-bugs]

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 VPR Threader intentionally or
implicitly freeing some other data allocated by the compiler that the new
threader is not cleaning up?

Assembling  functions:
 f_0_0_0
RSS = 569788
RSS = 569788
RSS = 569792
RSS = 569792
 g_0_0_0
RSS = 569876
RSS = 569876
RSS = 569880
RSS = 569880
 f_0_0_1
RSS = 569880
RSS = 569880
RSS = 569884
RSS = 569884
...
g_17_15_17
RSS = 783824
RSS = 783824
RSS = 783836
RSS = 783836
 f_17_15_23
RSS = 783892
RSS = 783892
RSS = 783896
RSS = 783896

cc1: out of memory allocating 65536 bytes after a total of 1071909664 bytes

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[dje at gcc dot gnu.org via Gcc-bugs]

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.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[dje at gcc dot gnu.org via Gcc-bugs]

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
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> {heap 4160k}  {heap 4288k} 
{heap 4288k}  {heap 4416k}  {heap 9985k}
 {heap 9985k}  {heap 9985k}Streaming LTO
  {heap 12M}  {heap 12M}  {heap 15M}
 {heap 15M}  {heap 15M}  {heap 15M}  {heap 15M}
 {heap 15M}  {heap 15M}  {heap 16M} 
{heap 16M}  {heap 16M}  {heap 16M} 
{heap 16M}
Assembling functions:
 f_0_0_0 g_0_0_0 f_0_0_1 g_0_0_1 f_0_0_2 g_0_0_2 f_0_0_7 g_0_0_7 f_0_0_8
g_0_0_8 f_0_0_9 g_0_0_9 f_0_0_15 g_0_0_15 f_0_0_16 g_0_0_16 f_0_0_17 g_0_0_17
f_0_0_23 
...
f_17_15_9 g_17_15_9 f_17_15_15 g_17_15_15 f_17_15_16 g_17_15_16 f_17_15_17
g_17_15_17 f_17_15_23
cc1: out of memory allocating 65536 bytes after a total of 1071778432 bytes

Somehow the VRP threader change provoked this change in memory usage and
failure mode.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[dje at gcc dot gnu.org via Gcc-bugs]

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 "Remove old VRP jump threader code" and
"Replace VRP threader with a hybrid forward threader.", I was able to compile
the testcase with an AIX limit of 1.25GB data size and now I need 2.25GB.

In other words, I don't need the entire patch series or even the cleanup patch,
just the replace VRP and remove old VRP patches.

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-29
 Status|UNCONFIRMED |NEW

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

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[dje at gcc dot gnu.org via Gcc-bugs]

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 gcc/testsuite/gcc.target/powerpc/rlwimi-1.c ?

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-09-28
 Status|UNCONFIRMED |NEW

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

[Bug middle-end/102519] New: [12 Regression] VRP Jump threader memory explosion

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102519
   Summary: [12 Regression] VRP Jump threader memory explosion
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: memory-hog
  Severity: normal
  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, memory usage
for some testcases, such as gcc.target/powerpc/rlwimi-1.c has doubled.  This is
causing new testsuite failures on AIX because of the default lower memory
limits on AIX.  The testcases previously compiled with 1GB data size for the
compiler, and now require 2GB data size.

Similar to the problem exposed by Martin Sebor's patch a few weeks ago, this
likely is a problem with memory allocation in the new pass.  A data structure
not placed in GC or not correctly tracked by GC.

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

[dje at gcc dot gnu.org via Gcc-bugs]

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 following:

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index d0830a95027..ad81dfb316d 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -21728,8 +21728,8 @@ rs6000_xcoff_encode_section_info (tree decl, rtx rtl,
in
t first)
   if (decl
   && DECL_P (decl)
   && VAR_OR_FUNCTION_DECL_P (decl)
-  && symtab_node::get (decl) != NULL
-  && symtab_node::get (decl)->alias == 0
+  && (symtab_node::get (decl) == NULL
+ || symtab_node::get (decl)->alias == 0)
   && symname[strlen (symname) - 1] != ']')
 {
   const char *smclass = NULL;

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

[dje at gcc dot gnu.org via Gcc-bugs]

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 encode the section info on an alias
because that creates conflicting AIX XCOFF encodings.

Thanks!

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

[dje at gcc dot gnu.org via Gcc-bugs]

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?

rs6000_xcoff_encode_section_info() could be missing some decl validation, but I
cannot reproduce it myself.

[Bug target/102148] ppc64le: homogeneous float arguments are not passed correctly

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-01
 Target|powerpc64le |powerpc64le-*-linux
 Ever confirmed|0   |1

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

[Bug rtl-optimization/102147] IRA dependent on 32-bit vs 64-bit pointer size

[dje at gcc dot gnu.org via Gcc-bugs]

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 representation depend on the pointer size.

[Bug rtl-optimization/102147] IRA dependent on 32-bit vs 64-bit register size

[dje at gcc dot gnu.org via Gcc-bugs]

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 allocation choices if GCC (IRA) is
built as 32 bit vs 64 bit compiler.

[Bug rtl-optimization/102147] IRA dependent on 32-bit vs 64-bit register size

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||bergner at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Last reconfirmed||2021-08-31

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

This was discovered when bootstrapping 64 bit GCC on AIX using 32 bit GCC.

It seems that this should be reproduceable on any system and architecture by
overriding the conflicts data structure encoding choice.

[Bug rtl-optimization/102147] New: IRA dependent on 32-bit vs 64-bit register size

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102147
   Summary: IRA dependent on 32-bit vs 64-bit register size
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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 by a GCC bootstrap comparison failure of tree-vect-slp.c
when using a 32 bit compiler to bootstrap a 64 bit compiler.

A difference occurs in ira-conflicts.c: build_object_conflicts(), for
the same object with the same properties (i.e., min, max and px are the same),
the function ira_conflict_vector_profitable_p() will return 1 by
stage1-gcc and 0 by stage2-gcc.

stage1-gcc: build_object_conflict obj140(a140) px=4 min=3 max=139
profitable_p=1
stage2-gcc: build_object_conflict obj140(a140) px=4 min=3 max=139
profitable_p=0

That's because the size of ira_object_t being a pointer is different
in stage1-gcc (which is 32bit) and stage2-gcc (which is 64bit).

My colleagues at ATOS and I aren't completely certain how this difference
causes different conflict / allocation behavior because it seems that it should
be an
optimization.

Should the data structure choice / algorithm choice depend on pointer size? 
Are the two algorithms supposed to generate the same results?

[Bug target/99557] [AIX] Alignment of double for struct and C++ classes

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

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

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

[Bug target/102068] [AIX] field alignment ignores packed

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #3 from David Edelsohn  ---
Fixed partially.

[Bug rtl-optimization/102062] powerpc suboptimal unrolling simple array sum

[dje at gcc dot gnu.org via Gcc-bugs]

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.

[Bug c/102062] powerpc suboptimal unrolling simple array sum

[dje at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from David Edelsohn  ---
We could backport Haochen's patch to AT.

[Bug target/102068] [AIX] field alignment ignores packed

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-08-25
 Status|UNCONFIRMED |NEW

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

[Bug target/102068] New: [AIX] field alignment ignores packed

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 102068
   Summary: [AIX] field alignment ignores packed
   Product: gcc
   Version: unknown
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: powerpc-ibm-aix*

struct __attribute__((packed, aligned(2))) S {
double a;
char b;
};

extern "C" int printf(const char*, ...);
int main() {
  printf("alignof %s is \t\t%lu\n","S\t",__alignof__(S));
}

GCC: S = 8
XLC: S = 2

typedef double Dbl __attribute__((__aligned__(2)));

struct S {
  Dbl d;
};

S s;

extern "C" int printf(const char*, ...);
int main() {
printf("alignof %s is \t\t%lu\n","D\t",__alignof__(D));
printf("alignof %s is \t\t%lu\n","S\t",__alignof__(S));
}

D = 2
GCC: S = 8
XLC: S = 2

[Bug middle-end/102029] [12 Regression] ice: error: type mismatch in ‘lshift_expr’

[dje at gcc dot gnu.org via Gcc-bugs]

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 from David Edelsohn  ---
This also had broken 32 bit powerpc, so I want to track any future updates.

[Bug other/101984] [12 Regression] gimple-ssa-warn-access memory leak

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-08-19
 CC||msebor at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

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

[Bug other/101984] New: [12 Regression] gimple-ssa-warn-access memory leak

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101984
   Summary: [12 Regression] gimple-ssa-warn-access memory leak
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: GC
  Severity: normal
  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 was
removed and the Tree generated by build_int_cst call in the function is not
managed by the GC machinery, leaking memory.

A patch was posted, but gimple-ssa-warn-access.cc is the first file with file
extension ".cc" to use the GC machinery, so the GCC Makefile machinery is not
prepared to automatically generate the GTY header.  (gimple-isel.cc is listed
but does not use GTY.)

https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577723.html

[Bug bootstrap/101959] [12 Regression] hash_map self test bootstrap failure

[dje at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from David Edelsohn  ---
This may be related to 32 bit builds.

[Bug bootstrap/101959] hash_map self test bootstrap failure

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-08-18

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

[Bug bootstrap/101959] New: hash_map self test bootstrap failure

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101959
   Summary: hash_map self test bootstrap failure
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
  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=/nasfarm/edelsohn/src/src/gcc/testsuite/selftests
/tmp/GCC/./gcc/xgcc -B/tmp/GCC/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null 
-fself-test=/nasfarm/edelsohn/src/src/gcc/testsuite/selftests
/nasfarm/edelsohn/src/src/gcc/hash-map-tests.c:389:
test_map_of_type_with_ctor_a
nd_dtor_expand: FAIL: ASSERT_EQ ((val_t::ncopy), (n_expand_moved))
cc1: internal compiler error: in fail, at selftest.c:47
/nasfarm/edelsohn/src/src/gcc/hash-map-tests.c:389:
test_map_of_type_with_ctor_a
nd_dtor_expand: FAIL: ASSERT_EQ ((val_t::ncopy), (n_expand_moved))
cc1plus: internal compiler error: in fail, at selftest.c:47
0x108cdb03 selftest::fail(selftest::location const&, char const*)
/nasfarm/edelsohn/src/src/gcc/selftest.c:47
0x11ec117f test_map_of_type_with_ctor_and_dtor_expand
/nasfarm/edelsohn/src/src/gcc/hash-map-tests.c:389
0x11ec1cff selftest::hash_map_tests_c_tests()
/nasfarm/edelsohn/src/src/gcc/hash-map-tests.c:463
0x139bb1fb selftest::run_tests()
/nasfarm/edelsohn/src/src/gcc/selftest-run-tests.c:65
0x10006ac7 toplev::run_self_tests()
/nasfarm/edelsohn/src/src/gcc/toplev.c:2297
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
0x109b08b3 selftest::fail(selftest::location const&, char const*)
/nasfarm/edelsohn/src/src/gcc/selftest.c:47
0x105aa67b test_map_of_type_with_ctor_and_dtor_expand
/nasfarm/edelsohn/src/src/gcc/hash-map-tests.c:389
0x105ab1fb selftest::hash_map_tests_c_tests()
/nasfarm/edelsohn/src/src/gcc/hash-map-tests.c:463
0x1401d4e3 selftest::run_tests()
/nasfarm/edelsohn/src/src/gcc/selftest-run-tests.c:65
make[3]: *** [/nasfarm/edelsohn/src/src/gcc/c/Make-lang.in:127: s-selftest-c]
Error 1

[Bug target/3985] AIX -mcpu=630 -maix64 does not use ppc64 multilib

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #10 from David Edelsohn  ---
PPC630 and AIX 4.3 is too old. This now functions correctly for newer processor
specs.

[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #19 from David Edelsohn  ---
I disabled on AIX because CTF and BTF were not enumerated as explicit debug
formats that emitted the normal GCC warning checked by DejaGNU.

[Bug other/101166] New: Add SPDX license identifiers

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101166
   Summary: Add SPDX license identifiers
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  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/

[Bug testsuite/101020] [12 regression] Several test case failures after r12-1316

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-11
 CC||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, not lp64.

[Bug c++/100805] New: __int128 should be disabled for non-extended -std= options

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 100805
   Summary: __int128 should be disabled for non-extended -std=
options
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  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 ? 9223372036854775808 : -1;
unsigned long _p = 

64 bit mode:
error: cannot convert `__int128*' to `long unsigned int*' in initialization

32 bit mode:
error: invalid conversion from `long long int*' to `long long unsigned int*'
[-fpermissive]

using a signed type that is too small to preserve the value.

It seems that promoting the value to a type that is an extension is incorrect
in strict standard mode.

[Bug ada/98171] adaint.c doesn't compile on AIX 7.2

[dje at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from David Edelsohn  ---
gcc119 should be functioning again.

[Bug ada/95549] [9/10/11/12 regression] gnat1 doesn't link on AIX

[dje at gcc dot gnu.org via Gcc-bugs]

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 from David Edelsohn  ---
I don't know why the vtable is not emitted.  It seems that it should be in
gcc-rich-location.o. This could be a situation of a conflict between a symbol
label and a symbol qualname.  The AIX backend has special code to try to handle
it.  I'm unsure why it's failing for gnat1 and not other languages.

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

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX