[Bug fortran/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:add31061ec23e07fdf749dc335308efc81151a3d

commit r10-6393-gadd31061ec23e07fdf749dc335308efc81151a3d
Author: Jakub Jelinek 
Date:   Sat Feb 1 10:02:20 2020 +0100

fortran: Fix up TYPE_ARG_TYPES of procs with scalar VALUE optional args
[PR92305]

The following patch fixes
-FAIL: libgomp.fortran/use_device_addr-1.f90   -O0  execution test
-FAIL: libgomp.fortran/use_device_addr-2.f90   -O0  execution test
that has been FAILing for several months on powerpc64le-linux.
The problem is in the Fortran FE, which adds the artificial arguments
for scalar VALUE OPTIONAL dummy args only to DECL_ARGUMENTS where the
current function can see them, but not to TYPE_ARG_TYPES; if those
functions
aren't varargs, this confuses calls.c to pass the remaining arguments
(which aren't named (== not covered by TYPE_ARG_TYPES) and aren't varargs
either) in a different spot from what the callee (which has proper
DECL_ARGUMENTS for all args) expects.  For the artificial length arguments
for character dummy args we already put them in both DECL_ARGUMENTS and
TYPE_ARG_TYPES.

2020-02-01  Jakub Jelinek  

PR fortran/92305
* trans-types.c (gfc_get_function_type): Also push boolean_type_node
types for non-character scalar VALUE optional dummy arguments.
* trans-decl.c (create_function_arglist): Skip those in
hidden_typelist.  Formatting fix.

[Bug fortran/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #20 from Jakub Jelinek  ---
Fixed.

[Bug target/93533] New: [10 Regression] ICE due to popcounthi2 expansion with -march=z196 since r10-3720

[jakub at gcc dot gnu.org]

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

Bug ID: 93533
   Summary: [10 Regression] ICE due to popcounthi2 expansion with
-march=z196 since r10-3720
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The following testcase ICEs on s390x with -march=z196 -O2 (or any -O+) since
r10-3720-gac87f0f3459a57f03503e51aeffc54bb6ef36b90 :
unsigned
foo (unsigned short a)
{
  a = a - (a >> 1 & 21845);
  a = (a & 13107) + (a >> 2 & 13107);
  return (unsigned short) ((a + (a >> 4) & 3855) * 257) >> 8;
}

The problem is in the popcounthi2_z196 expander that emits invalid RTL.

[Bug target/93533] [10 Regression] ICE due to popcounthi2 expansion with -march=z196 since r10-3720

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-01
 CC||krebbel at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 2959d8c0f17..e37ba49444a 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -11670,21 +11670,28 @@ (define_expand "popcountsi2"
 })

 (define_expand "popcounthi2_z196"
-  [; popcnt op0, op1
-   (parallel [(set (match_operand:HI 0 "register_operand" "")
+  [; popcnt op2, op1
+   (parallel [(set (match_dup 2)
   (unspec:HI [(match_operand:HI 1 "register_operand")]
  UNSPEC_POPCNT))
  (clobber (reg:CC CC_REGNUM))])
-   ; sllk op2, op0, 8
-   (set (match_dup 2)
-   (ashift:SI (match_dup 0) (const_int 8)))
-   ; ar op0, op2
-   (parallel [(set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))
+   ; lr op3, op2
+   (set (match_dup 3) (subreg:SI (match_dup 2) 0))
+   ; srl op4, op3, 8
+   (set (match_dup 4) (lshiftrt:SI (match_dup 3) (const_int 8)))
+   ; ar op3, op4
+   (parallel [(set (match_dup 3) (plus:SI (match_dup 3) (match_dup 4)))
  (clobber (reg:CC CC_REGNUM))])
-   ; srl op0, op0, 8
-   (set (match_dup 0) (lshiftrt:HI (match_dup 0) (const_int 8)))]
+   ; llgc op0, op3
+   (parallel [(set (match_operand:HI 0 "register_operand" "")
+  (and:HI (subreg:HI (match_dup 3) 2) (const_int 255)))
+ (clobber (reg:CC CC_REGNUM))])]
   "TARGET_Z196"
-  "operands[2] = gen_reg_rtx (SImode);")
+{
+  operands[2] = gen_reg_rtx (HImode);
+  operands[3] = gen_reg_rtx (SImode);
+  operands[4] = gen_reg_rtx (SImode);
+})

 (define_expand "popcounthi2"
   [(set (match_dup 2)

seems to work for me.

[Bug c++/93534] New: Overloading of Variadic function templates are not be ambiguous

[merukun1125 at docomo dot ne.jp]

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

Bug ID: 93534
   Summary: Overloading of Variadic function templates are not be
ambiguous
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: merukun1125 at docomo dot ne.jp
  Target Milestone: ---

The following code overload may be ambiguous and gives an error in clang, but
not in gcc:

#include 

template* = nullptr>
void func(T...) {}

template
void func(T...) {}

int main() {
func(3.14);
}

The following code that does not use variadic templates will error in both gcc
and clang:

#include 

template* = nullptr>
void func(T) {}

template
void func(T) {}

int main() {
func(3.14);
}

I think the first code overload should be ambiguous.

[Bug target/93533] [10 Regression] ICE due to popcounthi2 expansion with -march=z196 since r10-3720

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 47761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47761&action=edit
gcc10-pr93533.patch

Full untested patch.

[Bug target/91824] unnecessary sign-extension after _mm_movemask_epi8 or __builtin_popcount

[vanyacpp at gmail dot com]

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

--- Comment #7 from Ivan Sorokin  ---
(In reply to Jakub Jelinek from comment #6)
> Fixed.

Thank you!

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #47760|0   |1
is obsolete||

--- Comment #8 from H.J. Lu  ---
Created attachment 47762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47762&action=edit
A patch to handle targetm.asm_out.post_cfi_startproc

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Fangrui Song from comment #7)
> > Is -fasynchronous-unwind-tables compatible with -fpatchable-function-entry?
> 
> Apparently the Linux kernel does not care about it. To make it usable in
> userspace, we should place .cfi_startproc in a reasonable place.

My patch should handle it.

> (A more concerning issue is that __patchable_function_entries can be
> stripped by -Wl,--gc-sections , as the bug I linked above describes)

I opened:

https://sourceware.org/bugzilla/show_bug.cgi?id=25490

>  Interaction with -g1 (line table)

My patch doesn't handle this one.  Handle this one requires changing
DWARF prologue generation.

> % clang -g -fpatchable-function-entry=2 a.c -o a  # latest clang
> % addr2line -e a 0x$(nm a | awk '/ main/{print $1}')
> /tmp/c/a.c:1
> 
> % gcc -g -fpatchable-function-entry=2 a.c -o a
> % addr2line -e a 0x$(nm a | awk '/ main/{print $1}')
> ??:?
> 
> For M>0, I think it is fine to leave NOPs before the function entry
> uncovered by line table information. clang -fpatchable-function-entry=2,1
> layout is the same as #c2, except for a NOP above foo:
> 
> % clang -g -fpatchable-function-entry=2,1 a.c -o a
> # or gcc -g -fpatchable-function-entry=2,1 a.c -o a
> % addr2line -e a $(nm a | ruby -ane 'print ($F[0].to_i(16)-1).to_s(16) if /
> main/')
> crtstuff.c:?

[Bug libgomp/92844] [10 regression] libgomp.fortran/use_device_ptr-optional-2.f90 fails after r279004

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #1)
> I think that is or could be a duplicate of PR 92305

PR92305 has been fixed. Can you re-check whether the issue of this PR still
occurs?

At least when trying it manually, I cannot reproduce it (no actual offloading
done, for the host on ppc64le). And, seemingly, Jakub also does not have any
unexpected fails: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00013.html –
but he didn't seem to have any fail before his fix, either.

[Bug target/93535] New: slow float/double simple constant folding with -Ofast

[hehaochen at hotmail dot com]

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

Bug ID: 93535
   Summary: slow float/double simple constant folding with -Ofast
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hehaochen at hotmail dot com
  Target Milestone: ---

Created attachment 47763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47763&action=edit
testcase

slow float/double simple constant folding with -Ofast compared to -O3

Workload:
Adobe benchmark C++
  - simple_types_constant_folding.cpp
- float simple constant folding
- double simple constant folding


(Homebrew GCC 8.3.0_2)

g++-8  -O3  simple_types_constant_folding.cpp && ./a.out

  float simple constant folding: 7.40 sec  (OK)
  double simple constant folding: 7.41 sec (OK)

g++-8  -Ofast  simple_types_constant_folding.cpp && ./a.out

  float simple constant folding: 8.39 sec  SLOW
  double simple constant folding: 8.33 sec SLOW

g++-8  -Ofast -fno-fast-math  simple_types_constant_folding.cpp && ./a.out

  float simple constant folding: 7.43 sec  (OK)
  double simple constant folding: 7.37 sec (OK)


(Homebrew GCC 9.2.0_3)

g++-9  -O3  simple_types_constant_folding.cpp && ./a.out

  float simple constant folding: 7.42 sec  (OK)
  double simple constant folding: 7.43 sec (OK)

g++-9  -Ofast  simple_types_constant_folding.cpp && ./a.out

  float simple constant folding: 1.85 sec  (OK)
  double simple constant folding: 7.43 sec (should be optimized more)

g++-9  -Ofast -fno-fast-math  simple_types_constant_folding.cpp && ./a.out

  float simple constant folding: 7.49 sec  (OK)
  double simple constant folding: 7.51 sec (OK)


while, in Apple clang version 11.0.0 (clang-1100.0.33.17):

clang++ -O3  simple_types_constant_folding.cpp && ./a.out

  float simple constant folding: 7.59 sec  (OK)
  double simple constant folding: 7.81 sec (OK)

clang++ -Ofast simple_types_constant_folding.cpp && ./a.out

  float simple constant folding: 0.91 sec  (OK)
  double simple constant folding: 0.90 sec (OK)

[Bug c++/91218] internal compiler error: Segmentation fault compiling concepts and constraints

[ragobria at msu dot edu]

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

Brian Rago  changed:

   What|Removed |Added

 CC||ragobria at msu dot edu

--- Comment #2 from Brian Rago  ---
Created attachment 47764
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47764&action=edit
A simpler example

[Bug rtl-optimization/91333] [9/10 Regression] suboptimal register allocation for inline asm

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #10 from Christophe Lyon  ---
(In reply to Jeffrey A. Law from comment #9)
> Fixed by Vlad's patch on the trunk.

This patch causes regressions:
aarch64:
gcc.target/aarch64/sve/pcs/args_10.c -march=armv8.2-a+sve  scan-assembler
\\tld4w\\t{z2\\.s - z5\\.s}, p[0-7]/z, \\[x0\\]\\n
gcc.target/aarch64/sve/pcs/args_5_be_bf16.c -march=armv8.2-a+sve 
check-function-bodies callee
gcc.target/aarch64/sve/pcs/args_5_be_bf16.c -march=armv8.2-a+sve 
scan-assembler \\tld4h\\t{z0\\.h - z3\\.h}, p[0-7]/z, \\[x0, #-8, mul vl\\]\\n
gcc.target/aarch64/sve/pcs/args_5_be_f16.c -march=armv8.2-a+sve 
check-function-bodies callee
gcc.target/aarch64/sve/pcs/args_5_be_f16.c -march=armv8.2-a+sve  scan-assembler
\\tld4h\\t{z0\\.h - z3\\.h}, p[0-7]/z, \\[x0, #-8, mul vl\\]\\n
gcc.target/aarch64/sve/pcs/args_5_be_f32.c -march=armv8.2-a+sve 
check-function-bodies callee
gcc.target/aarch64/sve/pcs/args_5_be_f32.c -march=armv8.2-a+sve  scan-assembler
\\tld4w\\t{z0\\.s - z3\\.s}, p[0-7]/z, \\[x0, #-8, mul vl\\]\\n
gcc.target/aarch64/sve/pcs/args_5_be_f64.c -march=armv8.2-a+sve 
check-function-bodies callee
[] and many others


on arm:
gcc.target/arm/armv8_2-fp16-move-2.c scan-assembler bmi

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to H.J. Lu from comment #9)
> 
> > (A more concerning issue is that __patchable_function_entries can be
> > stripped by -Wl,--gc-sections , as the bug I linked above describes)
> 
> I opened:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=25490
> 

A patch is posted at

https://sourceware.org/ml/binutils/2020-02/msg9.html

[Bug middle-end/93197] -fpatchable-function-entries : __patchable_function_entries does not survive under --gc-sections

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=25490
 CC||hjl.tools at gmail dot com
 Resolution|--- |MOVED

--- Comment #1 from H.J. Lu  ---
I opened a linker bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=25490

[Bug middle-end/93536] New: -fpatchable-function-entries doesn't work with --gc-sections

[hjl.tools at gmail dot com]

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

Bug ID: 93536
   Summary: -fpatchable-function-entries doesn't work with
--gc-sections
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
Blocks: 93195
  Target Milestone: ---

[hjl@gnu-cfl-2 pr93492]$ cat foo.i 
void
bar (void)
{
}

void
_start (void)
{
}
[hjl@gnu-cfl-2 pr93492]$ make foo.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/
-fpatchable-function-entry=1 -ffunction-sections -O2 -S foo.i
[hjl@gnu-cfl-2 pr93492]$ cat foo.s
.file   "foo.i"
.text
.section.text.bar,"ax",@progbits
.p2align 4
.globl  bar
.type   bar, @function
bar:
.cfi_startproc
.section__patchable_function_entries,"aw",@progbits
.align 8
.quad   .LPFE1
.section.text.bar
.LPFE1:
nop
.LFB0:
ret
.cfi_endproc
.LFE0:
.size   bar, .-bar
.section.text._start,"ax",@progbits
.p2align 4
.globl  _start
.type   _start, @function
_start:
.cfi_startproc
.section__patchable_function_entries
.align 8
.quad   .LPFE2
.section.text._start
.LPFE2:
nop
.LFB3:
ret
.cfi_endproc
.LFE3:
.size   _start, .-_start
.ident  "GCC: (GNU) 10.0.1 20200201 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 pr93492]$ 

With --gc-sections, linker will discard bar and may leave a bad entry in
__patchable_function_entries.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195
[Bug 93195] -fpatchable-function-entries : __patchable_function_entries should
consider comdat groups

[Bug middle-end/93536] -fpatchable-function-entries doesn't work with --gc-sections

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Linker with the fix:

https://sourceware.org/ml/binutils/2020-02/msg00010.html

will issue an error:

[hjl@gnu-cfl-2 pr25490]$ ./ld --gc-sections -o foo foo.o
foo.o(__patchable_function_entries): reference to garbage collected section
[hjl@gnu-cfl-2 pr25490]$

[Bug middle-end/93195] -fpatchable-function-entries : __patchable_function_entries should consider comdat groups

[i at maskray dot me]

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

--- Comment #1 from Fangrui Song  ---
This is similar to --gc-sections
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93536) but a bit different.

The only reasonable fix I can think of is to place __patchable_function_entries
in the same section group.
The ELF spec says:

> A symbol table entry with STB_LOCAL binding that is defined relative to one 
> of a group's sections, and that is contained in a symbol table section that 
> is not part of the group, must be discarded if the group members are 
> discarded. References to this symbol table entry from outside the group are 
> not allowed.

Both GCC and clang reference a .L local symbol in __patchable_function_entries.
The __patchable_function_entries must be discarded when the associated text
section is discarded.
We don't want __patchable_function_entries.foo __patchable_function_entries.bar
because that can waste lots of bytes in .shstrtab .


clang -fpatchable-function-entry=2 -S a.cc b.cc

# COMDAT and SHF_LINK_ORDER are used at the same time
.section   
__patchable_function_entries,"awo",@progbits,_Z3barv,unique,0
.p2align3
.quad   .Lfunc_begin0

.section   
__patchable_function_entries,"aGwo",@progbits,_Z3foov,comdat,_Z3foov,unique,1
.p2align3
.quad   .Lfunc_begin1

Because GNU as and ld don't have the features yet. So when -no-integrated-as is
specified (the output is expected to be consumable by GNU as)

clang -fpatchable-function-entry=2 -no-integrated-as -S a.cc b.cc

## The assembler will combine sections with the same name
## If either .Lfunc_begin0 or .Lfunc_begin1 is discarded, the linker will
report an error.
.section__patchable_function_entries,"aw",@progbits
.p2align3
.quad   .Lfunc_begin0

.section__patchable_function_entries,"aw",@progbits
.p2align3
.quad   .Lfunc_begin1

[Bug c/93537] New: gcc 9.2 takes a Segmentation Violation when compiled file

[bob.huemmer at sas dot com]

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

Bug ID: 93537
   Summary: gcc 9.2 takes a Segmentation Violation when compiled
file
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bob.huemmer at sas dot com
  Target Milestone: ---

Created attachment 47765
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47765&action=edit
Standalone 'C' program which exhibits problem described above

/*
 * PROBLEM: GCC 9.2 takes a SEGV when compiling this program.
 *
 * System: Red Hat Enterprise Linux Server release 6.7 (Santiago)
 * Linux foo.unx.sas.com 2.6.32-573.el6.x86_64
 * #1 SMP Wed Jul 1 18:23:37 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
 *
 * GCC: Output of gcc -v
 * Using built-in specs.
 * Target: x86_64-pc-linux-gnu
 * Configured with: ../configure --enable-languages=c,c++,fortran
 * Thread model: posix
 * gcc version 9.2.0 (GCC)
 *
 * To reproduce: gcc -g ./t.c -o t.o -c
 *
 * Error produced:
 *  ‘(stmth->conh != 0 ? ((struct FOO_Generic_Handle_S *)stmth->conh)->type ==
 *  In function ‘FOO’:
 *  Segmentation fault
 *  74 |  cbNativeCatalogName = BAR( TSCGetPublicTMILCath(stmth->conh),
 *  |  ^~~
 *  0xa9010f crash_signal
 *  ../../gcc/toplev.c:326
 *  0xccaca0 location_wrapper_p(tree_node const*)
 *  ../../gcc/tree.h:3812
 *  0xccaca0 tree_strip_any_location_wrapper(tree_node*)
 *  ../../gcc/tree.h:3824
 *  0xccaca0 tree_int_cst_equal(tree_node const*, tree_node const*)
 *  ../../gcc/tree.c:7200
 *  0x699dc4 pp_c_enumeration_constant
 *  ../../gcc/c-family/c-pretty-print.c:985
 *  0x699dc4 c_pretty_printer::constant(tree_node*)
 *  ../../gcc/c-family/c-pretty-print.c:1141
 *  0x69a8a8 c_pretty_printer::conditional_expression(tree_node*)
 *  ../../gcc/c-family/c-pretty-print.c:2092
 *  0x69a8a8 c_pretty_printer::conditional_expression(tree_node*)
 *  ../../gcc/c-family/c-pretty-print.c:2088
 *  0x69a8ec c_pretty_printer::conditional_expression(tree_node*)
 *  ../../gcc/c-family/c-pretty-print.c:2096
 *  0x69a8ec c_pretty_printer::conditional_expression(tree_node*)
 *  ../../gcc/c-family/c-pretty-print.c:2088
 *  0x69ae74 c_pretty_printer::primary_expression(tree_node*)
 *  ../../gcc/c-family/c-pretty-print.c:1268
 *  0x699acd c_pretty_printer::postfix_expression(tree_node*)
 *  ../../gcc/c-family/c-pretty-print.c:1580
 *  0x699acd c_pretty_printer::postfix_expression(tree_node*)
 *  ../../gcc/c-family/c-pretty-print.c:1580
 *  0x625796 c_tree_printer
 *  ../../gcc/c/c-objc-common.c:198
 *  0x625796 c_tree_printer
 *  ../../gcc/c/c-objc-common.c:135
 *  0x12c4fbc pp_format(pretty_printer*, text_info*)
 *  ../../gcc/pretty-print.c:1390
 *  0x12bbc52 diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*)
 *  ../../gcc/diagnostic.c:1015
 *  0x12bc0dd diagnostic_impl
 *  ../../gcc/diagnostic.c:1159
 *  0x12bd430 pedwarn(rich_location*, int, char const*, ...)
 *  ../../gcc/diagnostic.c:1386
 *  0x612033 convert_for_assignment
 *  ../../gcc/c/c-typeck.c:7242
 *  Please submit a full bug report,
 *  with preprocessed source if appropriate.
 *  Please include the complete backtrace with any bug report.
 *  See  for instructions.
 *
 * NOTES:
 *   This problem occurs with gcc 9.1 and 9.2, but not with gcc 8.3
 */

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #128 from Peter Bisroev  ---
(In reply to dave.anglin from comment #125)
> On 2020-01-25 7:59 p.m., peter.bisroev at groundlabs dot com wrote:
> > Please let me know what you would like me to try next.
> Let's look at testsuite log in /gcc/testsuite/gcc.  This should show
> problem with weak.
> For example,
> UNRESOLVED: gcc.dg/weak/weak-1.c
> 
> Also look at a hidden failure to see what's wrong with .hidden.
> 
> Dave


At this point I have noticed that the objdump could not be executed while
running tests. Adding binutils-2.32 that I have compiled earlier to the PATH
allowed all the weak tests to pass. I obviously made some mistake running
  $ make check-c check-c++
initially, so I just kicked of another test run to see what the results will be
using this command
  $ gmake -j8 check-c check-c++ RUNTESTFLAGS="-v"

Will update you once I get the results.

In the meantime, I wanted to ask you. Is it OK for me to add to the PATH
directory containing binutils-2.32 compiled with aCC prior to bootstrapping GCC
4.7.4? For bootstrapping I have provided actual utilities to configure script
directly with a flag such as `--with-as`. Currently this directory contains:
addr2line
ar
as
c++filt
elfedit
gprof
nm
objcopy
objdump
ranlib
readelf
size
strings
strip
As expected ld is missing from the above as on HPUX we need to use HP's linker.
But what about the rest of the binaries? Will using them over comparable HP
ones cause any issues? I am asking as I have had issues with using binutils
provided binaries over system based ones when bootstrapping gcc on AIX.

The other question I wanted to ask, is my make check command above acceptable
or is there a better way to run these tests and get more information?

Thank you!
--peter

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #129 from Peter Bisroev  ---
(In reply to dave.anglin from comment #127)
> On 2020-01-25 9:16 p.m., peter.bisroev at groundlabs dot com wrote:
> > As can be seen above, stage1 binaries are just under 9 times the size of 
> > final
> > -O2 compiled binaries. I believe you have mentioned that this is due the 
> > use of
> > -O0 for stage1 compilation. But is such increase as seen above expected?
> The stage1 sizes are much larger than I would have expected.  However, I
> wouldn't worry
> about it since the compiler can rebuild itself.  There must be a long
> pattern in ia64.md that's
> used a lot.
> 
> Let's focus on issues important for c++.

Understood, thank you for the explanation. Will concentrate on getting updated
test results as per my prior comment. Will get back to you as soon as I have
them.

Thanks!

[Bug fortran/93365] KIND inquiry and zero-sized array generates wrong code

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
Summary|ICE in match_data_constant, |KIND inquiry and zero-sized
   |at fortran/decl.c:426   |array generates wrong code

--- Comment #13 from kargl at gcc dot gnu.org ---
The ICE may be gone, but no one has confirmed whether gfortran generates
correct for the examples.  If someone did show correct code generation, then
those examples should have been added to the testsuite.

Update subject to note possible wrong code.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #130 from dave.anglin at bell dot net ---
On 2020-02-01 5:12 p.m., peter.bisroev at groundlabs dot com wrote:
> At this point I have noticed that the objdump could not be executed while
> running tests. Adding binutils-2.32 that I have compiled earlier to the PATH
> allowed all the weak tests to pass. I obviously made some mistake running
>   $ make check-c check-c++
> initially, so I just kicked of another test run to see what the results will 
> be
> using this command
>   $ gmake -j8 check-c check-c++ RUNTESTFLAGS="-v"
I don't usually provide RUNTESTFLAGS.  I only use it when I want to run a
specific set of test.
>
> Will update you once I get the results.
>
> In the meantime, I wanted to ask you. Is it OK for me to add to the PATH
> directory containing binutils-2.32 compiled with aCC prior to bootstrapping 
> GCC
> 4.7.4? For bootstrapping I have provided actual utilities to configure script
> directly with a flag such as `--with-as`. Currently this directory contains:
> addr2line
> ar
> as
> c++filt
> elfedit
> gprof
> nm
> objcopy
> objdump
> ranlib
> readelf
> size
> strings
> strip
> As expected ld is missing from the above as on HPUX we need to use HP's 
> linker.
> But what about the rest of the binaries? Will using them over comparable HP
> ones cause any issues? I am asking as I have had issues with using binutils
> provided binaries over system based ones when bootstrapping gcc on AIX.
Yes.  I do it all the time.  I also configure with "--with-gnu-as
--with-as=/opt/gnu/bin/as".

It is import to use GNU as as it has same options and directives as it does on
linux.  The other
programs aren't used much in the build but they are useful for debugging.
>
> The other question I wanted to ask, is my make check command above acceptable
> or is there a better way to run these tests and get more information?
There is more info in the "testsuite" directory.  For example, for the c tests,
look in
/gcc/testsuite/gcc/gcc.log.  There similar log files for every
language and
library.

Dave

[Bug c/93537] gcc 9.2 takes a Segmentation Violation when attached file is compiled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-01
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
With --enable-checking=yes we get a different failure:
In function ‘FOO’:
tree check: expected tree that contains ‘decl common’ structure, have
‘integer_cst’ in pp_c_enumeration_constant, at c-family/c-pretty-print.c:999
  131 |  cbNativeCatalogName = BAR( TSCGetPublicTMILCath(stmth->conh),
  |  ^~~
0x6fcc7b tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gits/gcc/gcc/tree.c:9859
0x5e5cb8 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gits/gcc/gcc/tree.h:3392
0x5e5cb8 pp_c_enumeration_constant
../../gits/gcc/gcc/c-family/c-pretty-print.c:999

We are ICEing while trying to do a pedwarn of:
7274if (pedwarn (&richloc, OPT_Wincompatible_pointer_types,
7275 "passing argument %d of %qE from
incompatible "
7276 "pointer type", parmnum, rname))
7277  inform_for_arg (fundecl, expr_loc, parmnum, type,
rhstype);

[Bug tree-optimization/93538] New: equality of address of first member to address to enclosing object not folded

[msebor at gcc dot gnu.org]

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

Bug ID: 93538
   Summary: equality of address of first member to address to
enclosing object not folded
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The inequality below is trivially false but since GCC 4.6 the middle-end fails
to fold it into a constant (it is ultimately folded in RTL).  In GCC 4.5 it was
folded by the ealias pass.

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
struct A { int a[1]; };

void f (struct A *p)
{
  void *q = p->a;
  if (p != q)
__builtin_abort ();
}

;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)

f (struct A * p)
{
  void * q;

   [local count: 1073741824]:
  q_2 = &p_1(D)->a;
  if (p_1(D) != q_2)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}

[Bug tree-optimization/93538] equality of address of first member to address to enclosing object not folded

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
(I noticed this while testing my fix for bug 93519.)

Here's a (strictly undefined) test case involving memcpy where the lack of
folding it prevents the call from being eliminated (it is ultimately eliminated
in RTL but it's supposed to be eliminated sooner):

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
struct A { char a[3]; };

void f (struct A *p)
{
  void *q = p->a;

  __builtin_memcpy (p, q, sizeof (struct A));
}
a.c: In function ‘f’:
a.c:7:3: warning: ‘__builtin_memcpy’ accessing 3 bytes at offsets 0 and 0
overlaps 3 bytes at offset 0 [-Wrestrict]
7 |   __builtin_memcpy (p, q, sizeof (struct A));
  |   ^~

;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)

f (struct A * p)
{
  void * q;

   [local count: 1073741824]:
  q_2 = &p_1(D)->a;
  __builtin_memcpy (p_1(D), q_2, 3); [tail call]
  return;

}

Another undefined test case involving strcpy that isn't folded even in RTL
(Clang eliminates the pointless copy):

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout -o/dev/stdout
a.c
struct A { char a[3]; };

void f (struct A *a)
{
  void *p = a;
  void *q = a->a;

  __builtin_strcpy ((char*)p, (char*)q);
}
.file   "a.c"
.text
a.c: In function ‘f’:
a.c:8:3: warning: ‘__builtin_strcpy’ accessing 1 byte at offsets 0 and 0
overlaps 1 byte at offset 0 [-Wrestrict]
8 |   __builtin_strcpy ((char*)p, (char*)q);
  |   ^

;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)

f (struct A * a)
{
  void * q;

   [local count: 1073741824]:
  q_2 = &a_1(D)->a;
  __builtin_strcpy (a_1(D), q_2); [tail call]
  return;

}


.p2align 4
.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
movq%rdi, %rsi
jmp strcpy
.cfi_endproc
.LFE0:
.size   f, .-f
.ident  "GCC: (GNU) 10.0.1 20200131 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug tree-optimization/93538] equality of address of first member to address to enclosing object not folded

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
A better (well-defined) test case involves memmove:

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout -o/dev/stdout
a.c
struct A { char a[3]; };

void f (struct A *a)
{
  void *p = a;
  void *q = a->a;

  __builtin_memmove (p, q, sizeof (struct A));
}
.file   "a.c"
.text

;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)

f (struct A * a)
{
  void * q;

   [local count: 1073741824]:
  q_2 = &a_1(D)->a;
  __builtin_memmove (a_1(D), q_2, 3); [tail call]
  return;

}


.p2align 4
.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
movl$3, %edx
movq%rdi, %rsi
jmp memmove
.cfi_endproc
.LFE0:
.size   f, .-f
.ident  "GCC: (GNU) 10.0.1 20200131 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug tree-optimization/93539] New: memmove over self with result of string function not eliminated

[msebor at gcc dot gnu.org]

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

Bug ID: 93539
   Summary: memmove over self with result of string function not
eliminated
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While experimenting with the test case from pr3538 I noticed that GCC doesn't
take full advantage of the fact that functions like strcpy return their first
argument.  In the test case below only the memmove call in the first function
is eliminated.  The one in the second one is not (and never has been).  Clang
eliminates both as expected (and always has).

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout -o/dev/stdout
a.c
struct A { char a[10]; };

void f (struct A *p)
{
  __builtin_strcpy (p->a, "abcd");
  char *q = p->a;
  __builtin_memmove (q, p->a, sizeof p->a);   // eliminated (good)
}

void g (struct A *p)
{
  char *q = __builtin_strcpy (p->a, "abcd");
  __builtin_memmove (q, p->a, sizeof p->a);   // not eliminated
}

.file   "a.c"
.text

;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)

f (struct A * p)
{
  char[10] * _1;

   [local count: 1073741824]:
  _1 = &p_2(D)->a;
  __builtin_memcpy (_1, "abcd", 5); [tail call]
  return;

}


.p2align 4
.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
movl$1684234849, (%rdi)
movb$0, 4(%rdi)
ret
.cfi_endproc
.LFE0:
.size   f, .-f

;; Function g (g, funcdef_no=1, decl_uid=1936, cgraph_uid=2, symbol_order=1)

g (struct A * p)
{
  char * q;
  char[10] * _1;

   [local count: 1073741824]:
  _1 = &p_2(D)->a;
  q_5 = __builtin_memcpy (_1, "abcd", 5);
  __builtin_memmove (q_5, _1, 10); [tail call]
  return;

}


.p2align 4
.globl  g
.type   g, @function
g:
.LFB1:
.cfi_startproc
movl$1684234849, (%rdi)
movl$10, %edx
movq%rdi, %rsi
movb$0, 4(%rdi)
jmp memmove
.cfi_endproc
.LFE1:
.size   g, .-g
.ident  "GCC: (GNU) 10.0.1 20200131 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug c/93540] New: Attributes pure and const not working with aggregate return types, even trivial ones

[pskocik at gmail dot com]

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

Bug ID: 93540
   Summary: Attributes pure and const not working with aggregate
return types, even trivial ones
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

Example:

#define SIMPLE 0
#include 
#if SIMPLE
typedef int TYPE;
#else
typedef struct TYPE { int a; } TYPE;
#endif

//__attribute((pure))
__attribute((const))
TYPE get(void);

void TEST(void)
{
#if !SIMPLE  // :( generates repeated calls
if(get().a==0) abort();
if(get().a==0) abort();
if(get().a==0) abort();
if(get().a==0) abort();
#else  //OK, 1 call
if(get()==0) abort();
if(get()==0) abort();
if(get()==0) abort();
if(get()==0) abort();
#endif
}
///

https://gcc.godbolt.org/z/N79MCx

[Bug tree-optimization/93540] Attributes pure and const not working with aggregate return types, even trivial ones

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c   |tree-optimization
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Yes this is expected.  GCC only currently handles non-aggregate pure/const
functions (vector and complex types work).

[Bug fortran/46539] libquadmath: Add -static-libquadmath

[andrew at blamsoft dot com]

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

Andrew B  changed:

   What|Removed |Added

 CC||andrew at blamsoft dot com

--- Comment #6 from Andrew B  ---
It would be great to be able to share a binary with just operating system
supplied dynamic libraries. After reading posts about it and looking at otool
-L, it seems like this is what is needed.