[Bug tree-optimization/91514] optimization needs ficktive memory allocation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization, openmp
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-08-22
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Blocks||53947
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So what's the variant w/o the fictive allocation?  It would be nice to
see source with the variants controlled by a #define so one can compare
both compiling with -DFICTIVE or -UFICTIVE?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug target/91518] [9/10 Regression] segfault when run CPU2006 465.tonto since r263875

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc64le
 Status|UNCONFIRMED |WAITING
   Keywords||lto, wrong-code
   Last reconfirmed||2019-08-22
  Component|lto |target
 Blocks||26163
 Ever confirmed|0   |1
Summary|segfault when run CPU2006   |[9/10 Regression] segfault
   |465.tonto since r263875 |when run CPU2006 465.tonto
   ||since r263875
   Target Milestone|--- |9.3

--- Comment #2 from Richard Biener  ---
Not seen on x86_64.  Given you bisected to r263875 it should appear with GCC 9
as well - are the actual GCC 9 releases also affected?

I assume this is ppc64le.

Unless we know more I assume this is a target issue.  Please build with debug
info and see where exactly and why it segfaults.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/91510] r253207 fixed a wrong-code bug

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Created attachment 46742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46742&action=edit
original testcase

Original testcase.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[rguenth at gcc dot gnu.org]

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

--- Comment #28 from Richard Biener  ---
(In reply to James Cowgill from comment #0)
> Before the ldxc1 instruction is executed, gdb reports that the values in v0
> and s0 are both large integers (above 0x8000):
> (gdb) print/x $v0
> $1 = 0xfffee7f8
> (gdb) print/x $s0
> $2 = 0x80008b50
> 
> When added together, the lower 32-bits contains the correct pointer (in this
> case on the stack). On a 32-bit processor this is fine.
> 
> On a 64-bit processor, we know that v0 and s0 are sign extended as the last
> instructions to touch them were the addu at 924 and the subu at 8e0. So the
> values in the registers are actually:
> v0 = 0xfffee7f8
> s0 = 0x80008b50
> 
> Adding these together (modulo 64-bit) gives the final pointer of
> 0x7fff7348 which is outside the user address space and thus results
> in a SIGBUS.
> 
> I think GCC is assuming that the address calculated by the ldxc1 instruction
> is modulo 32-bit when compiled for a 32-bit processor. However, this is not
> true if the code is later run on a 64-bit processor.

Given the above GCC has to consider pointers (even integer regs!?) being
64bit even in 32bit mode since obviously semantics between 32bit and 64bit
hardware differs.  Thus as Eric says Pmode needs to be DImode and
ptr_mode SImode for 32bit and DImode for 64bit.  Everything else is going
to lead to issues like the ones observed.

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[crazylht at gmail dot com]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to kargl from comment #4)
> We need the Fortran source not the *.mod file.

You can use samp.f90.

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-08-22
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from kargl at gcc dot gnu.org ---
We need the Fortran source not the *.mod file.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-08-22
 CC||marxin at gcc dot gnu.org
  Component|fortran |middle-end
 Blocks||26163
 Ever confirmed|0   |1

--- Comment #5 from Thomas Koenig  ---
Well I hope somebody with access to the sources can say anything about it.

None of the gfortran maintainers has access to SPEC, so WAITING for more info.
Martin, you helped a lot in debugging PR 90539, maybe you can say if you see
the same effect?

In the meantime, the time is spent in the middle end, so I am resetting the
component.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug c++/80078] Incorrect classification of address of volatile as not constant

[headch at gmail dot com]

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

Christopher Head  changed:

   What|Removed |Added

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

--- Comment #4 from Christopher Head  ---
Appears to be fixed in 9.1.

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[crazylht at gmail dot com]

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

--- Comment #3 from Hongtao.liu  ---
It was ok two weeks ago, new regression from August 10th

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[crazylht at gmail dot com]

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

--- Comment #2 from Hongtao.liu  ---
It needs two *.mod* file which is too large for attachment. So I put them in
github, refer to https://github.com/algebra84/521.wrf_r

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
Created attachment 46741
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46741&action=edit
module_comm_dm_3.mod

[Bug fortran/91519] New: [regression]ICE error in 521.wrf_r

[crazylht at gmail dot com]

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

Bug ID: 91519
   Summary: [regression]ICE error in 521.wrf_r
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

Created attachment 46740
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46740&action=edit
samp.f90

Compile option:
/usr/gcc10_20190821/bin/gfortran -O2 ./samp.f90 -S -mtune=generic

error message:

in gfc_format_decoder, at fortran/error.c:947
0x5e8059 gfc_format_decoder
../../../gnu-toolchain/gcc/gcc/fortran/error.c:947
0x17cb961 pp_format(pretty_printer*, text_info*)
../../../gnu-toolchain/gcc/gcc/pretty-print.c:1390
0x17b5f99 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../../gnu-toolchain/gcc/gcc/diagnostic.c:1025
0x7fca90 gfc_error_opt
../../../gnu-toolchain/gcc/gcc/fortran/error.c:1313
0x7fe15d gfc_error(char const*, ...)
../../../gnu-toolchain/gcc/gcc/fortran/error.c:1342
0x898396 gfc_find_sym_tree(char const*, gfc_namespace*, int, gfc_symtree**)
../../../gnu-toolchain/gcc/gcc/fortran/symbol.c:3239
0x8983cf gfc_find_symbol(char const*, gfc_namespace*, int, gfc_symbol**)
../../../gnu-toolchain/gcc/gcc/fortran/symbol.c:3290
0x93d5c3 check_externals_expr
../../../gnu-toolchain/gcc/gcc/fortran/frontend-passes.c:5397
0x940885 gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*)
../../../gnu-toolchain/gcc/gcc/fortran/frontend-passes.c:4919
0x940ae9 gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*)
../../../gnu-toolchain/gcc/gcc/fortran/frontend-passes.c:4926
0x94358a gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../../gnu-toolchain/gcc/gcc/fortran/frontend-passes.c:5343
0x9435b7 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../../gnu-toolchain/gcc/gcc/fortran/frontend-passes.c:5345
0x944c61 gfc_check_externals(gfc_namespace*)
../../../gnu-toolchain/gcc/gcc/fortran/frontend-passes.c:5453
0x944c86 gfc_check_externals(gfc_namespace*)
../../../gnu-toolchain/gcc/gcc/fortran/frontend-passes.c:5458
0x85a714 gfc_parse_file()
../../../gnu-toolchain/gcc/gcc/fortran/parse.c:6326
0x8a5c5f gfc_be_parse_file
../../../gnu-toolchain/gcc/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug preprocessor/91517] Pragma expansion in variadic macro reorders pragmas and breaks code

[paboyle at ph dot ed.ac.uk]

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

--- Comment #2 from Peter Boyle  ---
GCC preprocessor moves location of _Pragma operator in sequence in a variadic
macro:
Simpler case:

#define thread_for( i, num, ... )  for ( uint64_t i=0;i"
# 1 ""
# 1 "tmp.cc"

#pragma omp critical
# 3 "tmp.cc"
for ( uint64_t i=0;i" 1
# 1 "" 3
# 374 "" 3
# 1 "" 1
# 1 "" 2
# 1 "tmp.cc" 2

for ( uint64_t i=0;i

[Bug lto/91518] segfault when run CPU2006 465.tonto since r263875

[luoxhu at cn dot ibm.com]

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

--- Comment #1 from Xiong Hu XS Luo  ---
51e85e64e125803502fde94b9e22037c0ccaa8b2 is the first bad commit
commit 51e85e64e125803502fde94b9e22037c0ccaa8b2
Author: rguenth rguenth@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Mon Aug 27 10:55:53 2018 +

2018-08-27  Richard Biener  

* cfganal.h (rev_post_order_and_mark_dfs_back_seme): Declare.
* cfganal.c (rev_post_order_and_mark_dfs_back_seme): New function.

* tree-ssa-sccvn.h (struct vn_pval): New structure.
(struct vn_nary_op_s): Add unwind_to member.  Add
predicated_values flag and put result into a union together
with a linked list of vn_pval.
(struct vn_ssa_aux): Add name member to make maintaining
a map of SSA name to vn_ssa_aux possible.  Remove no longer
needed info, dfsnum, low, visited, on_sccstack, use_processed
and range_info_anti_range_p members.
(run_scc_vn, vn_eliminate, free_scc_vn, vn_valueize): Remove.
(do_rpo_vn, run_rpo_vn, eliminate_with_rpo_vn, free_rpo_vn):
New functions.
(vn_valueize): New global.
(vn_context_bb): Likewise.
(VN_INFO_RANGE_INFO, VN_INFO_ANTI_RANGE_P, VN_INFO_RANGE_TYPE,
VN_INFO_PTR_INFO): Remove.
* tree-ssa-sccvn.c: ... (rewrite)
(pass_fre::execute): For -O2+ initialize loops and run
RPO VN in optimistic mode (iterating).  For -O1 and -Og
run RPO VN in non-optimistic mode.
* params.def (PARAM_SCCVN_MAX_SCC_SIZE): Remove.
(PARAM_RPO_VN_MAX_LOOP_DEPTH): Add.
* doc/invoke.texi (sccvn-max-scc-size): Remove.
(rpo-vn-max-loop-depth): Document.
* tree-ssa-alias.c (walk_non_aliased_vuses): Stop walking
when valuezing the VUSE signals we walked out of the region.
* tree-ssa-pre.c (phi_translate_1): Ignore predicated values.
(phi_translate): Set VN context block to use for availability
lookup.
(compute_avail): Likewise.
(pre_valueize): New function.
(pass_pre::execute): Adjust to the RPO VN API.

* tree-ssa-loop-ivcanon.c: Include tree-ssa-sccvn.h.
(propagate_constants_for_unrolling): Remove.
(tree_unroll_loops_completely): Perform value-numbering
on the unrolled bodies loop parent.

[Bug lto/91518] New: segfault when run CPU2006 465.tonto since r263875

[luoxhu at cn dot ibm.com]

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

Bug ID: 91518
   Summary: segfault when run CPU2006 465.tonto since r263875
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luoxhu at cn dot ibm.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

build option:
OPTIMIZE = -Ofast -mcpu=power8 -mrecip=all -funroll-loops -flto

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x1008bc2f in ???
#1  0x1008a3ff in ???
#2  0x10050477 in ???
#3  0x101aabfc in ???
#4  0x101aff3f in ???
#5  0x10133e7b in ???
#6  0x101e7023 in ???
#7  0x101e76ab in ???
#8  0x101e48a7 in ???
#9  0x1021fc5f in ???
#10  0x101e6503 in ???
#11  0x1013c7eb in ???
#12  0x1013583f in ???
#13  0x10154c4f in ???
#14  0x1000210b in ???
#15  0x106750ff in ???


Error: 1x465.tonto

(gdb) bt
#0  0x101a573c in __mol_module_MOD_make_image_of_shell ()
#1  0x101aaac0 in __mol_module_MOD_symmetrise_r ()
#2  0x10130b4c in __mol_module_MOD_symmetrise.constprop.16 ()
#3  0x101e1ba4 in __mol_module_MOD_make_atom_density ()
#4  0x101e222c in __mol_module_MOD_get_atom_density ()
#5  0x101df428 in __mol_module_MOD_get_initial_guess ()
#6  0x1021a7e0 in __mol_module_MOD_constrained_scf ()
#7  0x101e1084 in __mol_module_MOD_scf ()
#8  0x101394bc in __mol_main_module_MOD_process_keyword.constprop.1 ()
#9  0x10132510 in __mol_main_module_MOD_read_keywords.constprop.2 ()
#10 0x10151920 in __mol_main_module_MOD_main.constprop.0 ()
#11 0x100020ec in main ()

[Bug preprocessor/91517] Pragma expansion in variadic macro reorders pragmas and breaks code

[paboyle at ph dot ed.ac.uk]

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

--- Comment #1 from Peter Boyle  ---
Also occurs on 7.4.0, 8.3.0

gcc-7 (Homebrew GCC 7.4.0_2) 7.4.0
gcc-8 (Homebrew GCC 8.3.0) 8.3.0

[Bug tree-optimization/91504] Inlining misses some logical operation folding

[kamleshbhalui at gmail dot com]

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

--- Comment #3 from Kamlesh Kumar  ---
diff --git a/gcc/match.pd b/gcc/match.pd
index 93dcef9..b62ef36 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -137,6 +137,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (pointer_plus integer_zerop @1)
  (non_lvalue (convert @1)))

+/* (~value & C) ^ value -> value | C */
+(simplify
+ (bit_xor:c (bit_and (bit_not @0) INTEGER_CST@1) @0)
+ (bit_ior @0 @1))
+ 
 /* ptr - 0 -> (type)ptr */
 (simplify
  (pointer_diff @0 integer_zerop)
=
After above both function produces same asm.
i.e.
foo:
movl%edi, %eax
orb $4, %ah
ret


bar:

movl%edi, %eax
orb $4, %ah
ret

[Bug tree-optimization/91504] Inlining misses some logical operation folding

[kamleshbhalui at gmail dot com]

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

Kamlesh Kumar  changed:

   What|Removed |Added

 CC||kamleshbhalui at gmail dot com

--- Comment #2 from Kamlesh Kumar  ---
diff --git a/gcc/match.pd b/gcc/match.pd
index 93dcef9..b62ef36 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -137,6 +137,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (pointer_plus integer_zerop @1)
  (non_lvalue (convert @1)))

+/* (~value & C) ^ value -> value | C */
+(simplify
+ (bit_xor:c (bit_and (bit_not @0) INTEGER_CST@1) @0)
+ (bit_ior @0 @1))
+ 
 /* ptr - 0 -> (type)ptr */
 (simplify
  (pointer_diff @0 integer_zerop)
=
After above both function produces same asm.
i.e.
foo:
movl%edi, %eax
orb $4, %ah
ret


bar:

movl%edi, %eax
orb $4, %ah
ret

[Bug lto/91273] [7/8/9/10 Regression] ICE in warn_types_mismatch at ipa-devirt.c:995

[luoxhu at cn dot ibm.com]

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

--- Comment #8 from Xiong Hu XS Luo  ---
SPEC2017 case 507.cactuBSSN_r, also has ICE failure from r273571:

lto1: internal compiler error: in warn_types_mismatch, at ipa-devirt.c:995
0x105dad1f warn_types_mismatch(tree_node*, tree_node*, unsigned int, unsigned
int)
/home/gcc/gcc-10-trunk-2019-08-16/gcc/ipa-devirt.c:995
0x101dd147 lto_symtab_merge_decls_2
/home/gcc/gcc-10-trunk-2019-08-16/gcc/lto/lto-symtab.c:723
0x101dd147 lto_symtab_merge_decls_1
/home/gcc/gcc-10-trunk-2019-08-16/gcc/lto/lto-symtab.c:862
0x101dd147 lto_symtab_merge_decls()
/home/gcc/gcc-10-trunk-2019-08-16/gcc/lto/lto-symtab.c:888
0x101f2e47 read_cgraph_and_symbols(unsigned int, char const**)
/home/gcc/gcc-10-trunk-2019-08-16/gcc/lto/lto-common.c:2839
0x101c7def lto_main()

Compiler options used: "-O3 -mcpu=power9 -flto"

[Bug libstdc++/91516] Please also export the base object constructor for __shared_ptr;

[rafael at espindo dot la]

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

--- Comment #1 from Rafael Avila de Espindola  ---
Corresponding clang bug:

https://bugs.llvm.org/show_bug.cgi?id=43079

[Bug c++/91448] FAIL: g++.dg/opt/flifetime-dse2.C -std=gnu++98 execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Target|hppa2.0w-hp-hpux11.11   |hppa*-*-hpux11.11
   Host|hppa2.0w-hp-hpux11.11   |hppa*-*-hpux11.11
  Build|hppa2.0w-hp-hpux11.11   |hppa*-*-hpux11.11

--- Comment #5 from John David Anglin  ---
The flifetime tests fail on both 32 and 64-bit hpux targets.

[Bug preprocessor/91517] New: Pragma expansion in variadic macro reorders pragmas and breaks code

[paboyle at ph dot ed.ac.uk]

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

Bug ID: 91517
   Summary: Pragma expansion in variadic macro reorders pragmas
and breaks code
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paboyle at ph dot ed.ac.uk
  Target Milestone: ---

Pragma expansion in variadic macro reorders pragmas and breaks code

Simple test code 

#define DO_PRAGMA(x) DO_PRAGMA_(x)
#define DO_PRAGMA_(x) _Pragma (#x)
#define thread_for( i, num, ... )  DO_PRAGMA(omp parallel for schedule(static))
for ( uint64_t i=0;i"
# 1 ""
# 1 "tmp.cc"
#pragma omp critical
# 8 "tmp.cc"
#pragma omp parallel for schedule(static)
# 8 "tmp.cc"
 for ( uint64_t i=0;i" 1
# 1 "" 3
# 374 "" 3
# 1 "" 1
# 1 "" 2
# 1 "tmp.cc" 2
#pragma omp parallel for schedule(static)
# 8 "tmp.cc"
 for ( uint64_t i=0;i

[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used

[gofmanp at gmail dot com]

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

--- Comment #1 from Paul Gofman  ---
Created attachment 46739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46739&action=edit
Pop frame pointer in function label if it is not needed instead of prologue for
"ms_hook_prologue" functions on i386

The attached patch fixes the issue for me. I am not sure if that is the best
way to fix it though.

[Bug libstdc++/91516] New: Please also export the base object constructor for __shared_ptr;

[rafael at espindo dot la]

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

Bug ID: 91516
   Summary: Please also export the base object constructor for
__shared_ptr;
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael at espindo dot la
  Target Milestone: ---

Given 

#include 
void foo() {
for (auto& dev : std::filesystem::directory_iterator("slaves")) {
}
}


gcc calls
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_,
but clang calls
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_.

In the libstdc++.so, only the C1 variant is exported, so a program compiled
with clang and libstdc++ fails to link.

[Bug fortran/91512] [10 Regression] Fortran compile time regression.

[skpgkp2 at gmail dot com]

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

--- Comment #4 from Sunil Pandey  ---
(In reply to Thomas Koenig from comment #3)
> (In reply to Sunil Pandey from comment #2)
> 
> >  phase opt and generate :  47.72 ( 97%)   0.24 ( 77%)  48.04 (
> > 96%)  118205 kB ( 89%)
> 
> So, phase_opt_and_generate appears to be something strange.
> 
> What the patch did was to change the way for subarrays that are
> packed because they are passed to an old-style argument, like this:
> 
> module x
>   implicit none
> contains
>   subroutine bar(a, n)
> integer, intent(in) :: n
> integer, intent(in), dimension(n) :: a
> print *,a
>   end subroutine bar
> end module x
> 
> program main
>   use x
>   implicit none
>   integer, parameter :: n = 10
>   integer, dimension(n) :: a
>   integer :: i
>   a = [(i,i=1,n)]
>   call bar(a(n:1:-1),n)
> end program main
> 
> After the patch, the packing is done in the front end, which
> means that the optimizers can see through it and possibly inline
> the procedures, or do other optimizations.  If these optimizations
> hit some quadratic (or worse) behavior, this could lead to long
> compilation times.
> 
> I would assume that your code has a lot of places where code like
> the above occurs, is that the case?

Actually it is spec cpu 2017 521.wrf benchmark getting this problem while
compiling. Compilation taking forever, you can see while compiling file
module_first_rk_step_part1.fppized.f90 as a representative.

[Bug fortran/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
Summary|Fortran compile time|[10 Regression] Fortran
   |regression. |compile time regression.

--- Comment #3 from Thomas Koenig  ---
(In reply to Sunil Pandey from comment #2)

>  phase opt and generate :  47.72 ( 97%)   0.24 ( 77%)  48.04 (
> 96%)  118205 kB ( 89%)

So, phase_opt_and_generate appears to be something strange.

What the patch did was to change the way for subarrays that are
packed because they are passed to an old-style argument, like this:

module x
  implicit none
contains
  subroutine bar(a, n)
integer, intent(in) :: n
integer, intent(in), dimension(n) :: a
print *,a
  end subroutine bar
end module x

program main
  use x
  implicit none
  integer, parameter :: n = 10
  integer, dimension(n) :: a
  integer :: i
  a = [(i,i=1,n)]
  call bar(a(n:1:-1),n)
end program main

After the patch, the packing is done in the front end, which
means that the optimizers can see through it and possibly inline
the procedures, or do other optimizations.  If these optimizations
hit some quadratic (or worse) behavior, this could lead to long
compilation times.

I would assume that your code has a lot of places where code like
the above occurs, is that the case?

[Bug middle-end/91490] [9/10 Regression] bogus argument missing terminating nul warning on strlen of a flexible array member

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
A subset of the patch referenced in comment #1 that deals with just this issue:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01517.html

[Bug c/91515] New: missed optimization: no tailcall for types of class MEMORY

[no...@turm-lahnstein.de]

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

Bug ID: 91515
   Summary: missed optimization: no tailcall for types of class
MEMORY
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: no...@turm-lahnstein.de
  Target Milestone: ---

Produced assembler (-O2) for

   struct Vec3{
double x, y, z;
   };

   struct Vec3 create(void);

   struct Vec3 use(){
return create();
   }

looks as follows (live: https://godbolt.org/z/v-HjX0):

use:
pushq   %r12
movq%rdi, %r12
callcreate
movq%r12, %rax
popq%r12
ret

Hower, I think that under System V AMD64 - ABI, the tailcall optimization:

use:
jmpcreate

as create will move  %rdi-value to %rax anyway.

[Bug target/88839] [SVE] Poor implementation of blend-like permutes

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Wed Aug 21 20:41:41 2019
New Revision: 274810

URL: https://gcc.gnu.org/viewcvs?rev=274810&root=gcc&view=rev
Log:
2019-08-22  Prathamesh Kulkarni  
Richard Sandiford  

PR target/88839
* config/aarch64/aarch64.c (aarch64_evpc_sel): New function.
(aarch64_expand_vec_perm_const_1): Call aarch64_evpc_sel.

testsuite/
* gcc.target/aarch64/sve/sel_1.c: New test.
* gcc.target/aarch64/sve/sel_2.c: Likewise.
* gcc.target/aarch64/sve/sel_3.c: Likewise.
* gcc.target/aarch64/sve/sel_4.c: Likewise.
* gcc.target/aarch64/sve/sel_5.c: Likewise.
* gcc.target/aarch64/sve/sel_6.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/sve/sel_1.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/sel_2.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/sel_3.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/sel_4.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/sel_5.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/sel_6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[Bug c/91514] New: optimization needs ficktive memory allocation

[akonn7 at mail dot ru]

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

Bug ID: 91514
   Summary: optimization needs ficktive memory allocation
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akonn7 at mail dot ru
  Target Milestone: ---

Created attachment 46738
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46738&action=edit
Example project for optimized gemm, with optimization bug

In attachment(file gemm.h) exist optimization bug: we need to allocate fictive
memory block for kc, without it we won't get vectorization in inner most loop,
but kc is still dynamically traverse across big memory block for subdivided
matrix C, so i'm suppose optimizer is too paranoid for possible data
dependencies.

[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs

[skunk at iskunk dot org]

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

Daniel Richard G.  changed:

   What|Removed |Added

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

--- Comment #11 from Daniel Richard G.  ---
I have attempted a bootstrap of 9.2.0 on this same system again, and am happy
to report that it now completes successfully, modulo bug #55930. Specifically,

* The libgcc-unwind.map error no longer occurs, despite my use of
--disable-shared;

* The object diffs no longer arise, even though I am continuing to use
/usr/ccs/bin/as and /usr/ccs/bin/ld .

These issues appear to have been fixed by-the-by since this bug was originally
filed, so I am closing accordingly.

[Bug fortran/91513] New: Non-standard terminology in error message for pointer component assignment in pure procedure

[damian at sourceryinstitute dot org]

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

Bug ID: 91513
   Summary: Non-standard terminology in error message for pointer
component assignment in pure procedure
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

Based on a quick search, I don't think the Fortran standard uses the term
"impure variable," which makes it difficult to interpret the error message
below.  Above the GCC source code that contains this error message is a
citation to Fortran 2008 C1283. It might be nice to have a more descriptive
error message or at least to a comment to the GCC source that more fully
explains how the constraint is being applied to lead to the error message
below:

$cat impure-variable.f90 
  implicit none
  type ptr
logical, pointer :: bool=>null()
  end type
  type(ptr) :: foo, bar
  bar = f(foo)
contains
  pure function f(x) result(y)
type(ptr), intent(in) :: x
type(ptr) y
y = x
  end function
end
$gfortran-8 impure-variable.f90
impure-variable.f90:11:8:

 y = x
1
Error: The impure variable at (1) is assigned to a derived type variable with a
POINTER component in a PURE procedure (12.6)
$gfortran-8 --version

[Bug fortran/91512] Fortran compile time regression.

[skpgkp2 at gmail dot com]

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

--- Comment #2 from Sunil Pandey  ---
Before commit time report:
==

$
/local/skpandey/gccwork/gcc_trunk/tools-build/gcc-debug/release.a4ba5c3ec624008e899a8bcb687359db25140c23/usr/gcc-10.0.0-x86-64/bin/gfortran
 -m64 -c -o module_first_rk_step_part1.fppized.o  
-fno-unsafe-math-optimizations -mfpmath=sse -Ofast -march=native -funroll-loops
 -fconvert=big-endian foo.f90 -ftime-report

Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
182 kB (  1%)
 phase parsing  :   1.67 ( 54%)   0.07 ( 88%)   1.74 ( 54%)
  10534 kB ( 72%)
 phase opt and generate :   1.45 ( 46%)   0.01 ( 12%)   1.46 ( 45%)
   3928 kB ( 27%)
 garbage collection :   0.02 (  1%)   0.00 (  0%)   0.02 (  1%)
  0 kB (  0%)
 callgraph construction :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
121 kB (  1%)
 callgraph optimization :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
  0 kB (  0%)
 ipa function summary   :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
 11 kB (  0%)
 cfg cleanup:   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
 34 kB (  0%)
 CFG verifier   :   0.05 (  2%)   0.00 (  0%)   0.10 (  3%)
  0 kB (  0%)
 trivially dead code:   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
  0 kB (  0%)
 df scan insns  :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 df reaching defs   :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 df live regs   :   0.01 (  0%)   0.01 ( 12%)   0.00 (  0%)
  0 kB (  0%)
 df live&initialized regs   :   0.03 (  1%)   0.00 (  0%)   0.00 (  0%)
  0 kB (  0%)
 df must-initialized regs   :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
  0 kB (  0%)
 df reg dead/unused notes   :   0.02 (  1%)   0.00 (  0%)   0.01 (  0%)
 72 kB (  0%)
 register information   :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 alias stmt walking :   0.01 (  0%)   0.00 (  0%)   0.02 (  1%)
 13 kB (  0%)
 parser (global):   1.67 ( 54%)   0.07 ( 88%)   1.74 ( 54%)
  10534 kB ( 72%)
 tree gimplify  :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
430 kB (  3%)
 tree CFG cleanup   :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 tree VRP   :   0.03 (  1%)   0.00 (  0%)   0.02 (  1%)
 72 kB (  0%)
 tree Early VRP :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
 17 kB (  0%)
 tree copy propagation  :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 tree PTA   :   0.03 (  1%)   0.00 (  0%)   0.03 (  1%)
113 kB (  1%)
 dominator optimization :   0.04 (  1%)   0.00 (  0%)   0.03 (  1%)
 62 kB (  0%)
 tree CCP   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 17 kB (  0%)
 tree PRE   :   0.03 (  1%)   0.00 (  0%)   0.04 (  1%)
 79 kB (  1%)
 tree FRE   :   0.03 (  1%)   0.00 (  0%)   0.01 (  0%)
 17 kB (  0%)
 tree forward propagate :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  1 kB (  0%)
 tree phiprop   :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
  0 kB (  0%)
 tree aggressive DCE:   0.02 (  1%)   0.00 (  0%)   0.00 (  0%)
 10 kB (  0%)
 tree DSE   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  1 kB (  0%)
 complete unrolling :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 13 kB (  0%)
 tree slp vectorization :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
 53 kB (  0%)
 tree SSA verifier  :   0.22 (  7%)   0.00 (  0%)   0.15 (  5%)
  0 kB (  0%)
 tree STMT verifier :   0.17 (  5%)   0.00 (  0%)   0.23 (  7%)
  0 kB (  0%)
 dominance computation  :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 expand :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
497 kB (  3%)
 CSE:   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
 15 kB (  0%)
 dead store elim1   :   0.02 (  1%)   0.00 (  0%)   0.01 (  0%)
 55 kB (  0%)
 dead store elim2   :   0.10 (  3%)   0.00 (  0%)   0.10 (  3%)
 77 kB (  1%)
 loop init  :   0.02 (  1%)   0.00 (  0%)   0.03 (  1%)
 15 kB (  0%)
 loop unrolling :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 94 kB (  1%)
 CPROP  :   0.01 (  0%)   0.00 (  0%)   0.02 (  1%)
 69 kB (  0%)
 PRE

[Bug target/83531] Build broken on macOS 10.13.2

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe  ---
fixed for 9.3

[Bug target/83531] Build broken on macOS 10.13.2

[iains at gcc dot gnu.org]

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

--- Comment #13 from Iain Sandoe  ---
Author: iains
Date: Wed Aug 21 19:18:14 2019
New Revision: 274807

URL: https://gcc.gnu.org/viewcvs?rev=274807&root=gcc&view=rev
Log:
[Darwin, fixincludes] Backport fix for PR83531

There is no reasonable chance that the SDKs in question will be re-
issued, so the only viable solution is a fixincludes.

2019-08-21  Iain Sandoe  

Backport from mainline.
2019-08-18  C.G. Dogan 
Iain Sandoe  

PR target/83531
* inclhack.def (darwin_api_availability): New; strip leading
underscores from API_ defines.
* fixincl.x: Regenerate.
* tests/base/os/availability.h: New file.


Added:
branches/gcc-9-branch/fixincludes/tests/base/os/availability.h
Modified:
branches/gcc-9-branch/fixincludes/ChangeLog
branches/gcc-9-branch/fixincludes/fixincl.x
branches/gcc-9-branch/fixincludes/inclhack.def

[Bug fortran/91512] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Can you show the output of your compilation when adding -ftime-report
to the options?  This will give us an idea of where the CPU cycles
are burned.

[Bug target/90724] ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Wed Aug 21 18:34:43 2019
New Revision: 274805

URL: https://gcc.gnu.org/viewcvs?rev=274805&root=gcc&view=rev
Log:
2019-08-21  Prathamesh Kulkarni  

PR target/90724
* config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): Force y
in reg if it fails aarch64_plus_operand predicate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c

[Bug middle-end/91490] [9/10 Regression] bogus argument missing terminating nul warning on strlen of a flexible array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-21
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01202.html

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[ma...@linux-mips.org]

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

--- Comment #27 from Maciej W. Rozycki  ---
Yes, it is the same problem, the same address calculation occurs here,
and the lack of 32-bit address space wraparound is a part of the n32
Linux ABI, which implies support for processors that do not support such
a wraparound in hardware (no CP0.Status.PX bit).

You may try experimenting with ISA/ASE selection options, so that LWX is
not considered a valid instruction by GCC.  Otherwise I can't help with
finding a workaround as I don't know one offhand and I'm not involved
with MIPS development anymore, sorry.  And neither is Doug BTW.

This really ought to be fixed properly in GCC.

[Bug fortran/91512] New: Fortran compile time regression.

[skpgkp2 at gmail dot com]

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

Bug ID: 91512
   Summary: Fortran compile time regression.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp2 at gmail dot com
CC: crazylht at gmail dot com, hjl.tools at gmail dot com,
tkoenig at gcc dot gnu.org
  Target Milestone: ---

We have a big fortran file which used to take 30 second to compile now it's
taking more than 30 minute. I'm trying to create a small reproducer.

Compile time regression caused by this change.

commit 396260630b60675a92bee5577333c4794565aee5 (HEAD, refs/bisect/bad)
Author: tkoenig 
Date:   Sun May 19 10:21:06 2019 +

2019-05-19  Thomas Koenig  

PR fortran/88821
* expr.c (gfc_is_simply_contiguous): Return true for
an EXPR_ARRAY.
* trans-array.c (is_pointer): New function.
(gfc_conv_array_parameter): Call gfc_conv_subref_array_arg
when not optimizing and not optimizing for size if the formal
arg is passed by reference.
* trans-expr.c (gfc_conv_subref_array_arg): Add arguments
fsym, proc_name and sym.  Add run-time warning for temporary
array creation.  Wrap argument if passing on an optional
argument to an optional argument.
* trans.h (gfc_conv_subref_array_arg): Add optional arguments
fsym, proc_name and sym to prototype.

2019-05-19  Thomas Koenig  

PR fortran/88821
* gfortran.dg/alloc_comp_auto_array_3.f90: Add -O0 to dg-options
to make sure the test for internal_pack is retained.
* gfortran.dg/assumed_type_2.f90: Split compile and run time
tests into this and
* gfortran.dg/assumed_type_2a.f90: New file.
* gfortran.dg/c_loc_test_22.f90: Likewise.
* gfortran.dg/contiguous_3.f90: Likewise.
* gfortran.dg/internal_pack_11.f90: Likewise.
* gfortran.dg/internal_pack_12.f90: Likewise.
* gfortran.dg/internal_pack_16.f90: Likewise.
* gfortran.dg/internal_pack_17.f90: Likewise.
* gfortran.dg/internal_pack_18.f90: Likewise.
* gfortran.dg/internal_pack_4.f90: Likewise.
* gfortran.dg/internal_pack_5.f90: Add -O0 to dg-options
to make sure the test for internal_pack is retained.
* gfortran.dg/internal_pack_6.f90: Split compile and run time
tests into this and
* gfortran.dg/internal_pack_6a.f90: New file.
* gfortran.dg/internal_pack_8.f90: Likewise.
* gfortran.dg/missing_optional_dummy_6: Split compile and run time
tests into this and
* gfortran.dg/missing_optional_dummy_6a.f90: New file.
* gfortran.dg/no_arg_check_2.f90: Split compile and run time tests
into this and
* gfortran.dg/no_arg_check_2a.f90: New file.
* gfortran.dg/typebound_assignment_5.f90: Split compile and run
time
tests into this and
* gfortran.dg/typebound_assignment_5a.f90: New file.
* gfortran.dg/typebound_assignment_6.f90: Split compile and run
time
tests into this and
* gfortran.dg/typebound_assignment_6a.f90: New file.
* gfortran.dg/internal_pack_19.f90: New file.
* gfortran.dg/internal_pack_20.f90: New file.
* gfortran.dg/internal_pack_21.f90: New file.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@271377
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[patrickdepinguin at gmail dot com]

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

--- Comment #26 from Thomas De Schampheleire  ---
(In reply to Thomas De Schampheleire from comment #25)
> Is it possible that this same problem is applicable on the 'lwx' instruction?
> I am using MIPS64 n32.
> 
> I first saw the original problem as described in this bug with instruction
> 'lwxc1'. I then used the suggested compilation flag -mno-lxc1-sxc1 which
> removed that problem.
> 
> However, in another place in the code I get a SIGBUS on following
> instruction:
> 
> lwx   v1,a5(v1)
> 
> where:
> v1: eb623870
> a5: 8a4ee1c4
> 
> The exception shows:
> badvaddr: 75b11a34
> 
> If you sum the lower 32 bits of v1+a5 you get '175b11a34' (i.e. 33 bits).
> Truncated to 32 bits, this is the value you see in badvaddr.
> Nevertheless, this address is inside a mapped and read/writable memory
> range, from /proc/PID/maps:
> 
> 75b0-75b21000 rw-p  00:00 0 
> 
> This behavior looks very similar to this bug's description.
> 
> If this same problem indeed also applies to 'lwx', is there a workaround for
> it?

This is observed with gcc 7.3.0.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[patrickdepinguin at gmail dot com]

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

--- Comment #25 from Thomas De Schampheleire  ---
Is it possible that this same problem is applicable on the 'lwx' instruction?
I am using MIPS64 n32.

I first saw the original problem as described in this bug with instruction
'lwxc1'. I then used the suggested compilation flag -mno-lxc1-sxc1 which
removed that problem.

However, in another place in the code I get a SIGBUS on following instruction:

lwx v1,a5(v1)

where:
v1: eb623870
a5: 8a4ee1c4

The exception shows:
badvaddr: 75b11a34

If you sum the lower 32 bits of v1+a5 you get '175b11a34' (i.e. 33 bits).
Truncated to 32 bits, this is the value you see in badvaddr.
Nevertheless, this address is inside a mapped and read/writable memory range,
from /proc/PID/maps:

75b0-75b21000 rw-p  00:00 0 

This behavior looks very similar to this bug's description.

If this same problem indeed also applies to 'lwx', is there a workaround for
it?

[Bug c++/91304] maybe_unused attribute ignored on variable declared in if declaration

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01495.html

[Bug c++/91314] Confusing warning refers to nonexistent comma operator

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-21
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Marek Polacek  ---
Confirmed.  Probably comes from genericize_compound_lvalue.

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-21
 CC||segher at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Segher Boessenkool  ---
The various darn patterns use unspec instead of unspec_volatile.

Mine.

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug c/61727] #pragma simd is undocumented

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||fx at gnu dot org

--- Comment #5 from Eric Gallager  ---
*** Bug 91511 has been marked as a duplicate of this bug. ***

[Bug other/91511] documentation of the effect of #pragma omp simd

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Eric Gallager  ---
since "omp simd" is the only kind of #pragma simd left (Cilk+'s was removed),
I'm marking this as a dup of bug 61727

*** This bug has been marked as a duplicate of bug 61727 ***

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Wed Aug 21 13:59:31 2019
New Revision: 274799

URL: https://gcc.gnu.org/viewcvs?rev=274799&root=gcc&view=rev
Log:
[C++] Protect call to copy_attributes_to_builtin (PR91505)

copy_attributes_to_builtin only handles BUILT_IN_NORMAL, but C++ was
calling it immediately after the:

  if (DECL_BUILT_IN_CLASS (newdecl) == BUILT_IN_NORMAL)

block.  The corresponding C code calls it inside the block instead.

2019-08-21  Richard Sandiford  

gcc/cp/
PR c++/91505
* decl.c (duplicate_decls): Call copy_attributes_to_builtin inside
the BUILT_IN_NORMAL block rather than afterward.

gcc/testsuite/
PR c++/91505
* g++.target/i386/crc32-4.C: New test.

Added:
trunk/gcc/testsuite/g++.target/i386/crc32-4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/91510] r253207 fixed a wrong-code bug

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.4.1
 Resolution|--- |FIXED
   Target Milestone|--- |7.5
  Known to fail||7.4.0

--- Comment #3 from Richard Biener  ---
Fixed on the branch.

[Bug tree-optimization/91510] r253207 fixed a wrong-code bug

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Wed Aug 21 13:44:45 2019
New Revision: 274798

URL: https://gcc.gnu.org/viewcvs?rev=274798&root=gcc&view=rev
Log:
2019-08-21  Richard Biener  

PR tree-optimization/91510
Backport from mainline
2017-09-26  Martin Jambor  

* tree-sra.c (compare_access_positions): Put integral types first,
stabilize sorting of integral types, remove conditions putting
non-full-precision integers last.
(sort_and_splice_var_accesses): Disable scalarization if a
non-integert would be represented by a non-full-precision integer.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/tree-sra.c

[Bug c++/91304] maybe_unused attribute ignored on variable declared in if declaration

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #2 from Marek Polacek  ---
All attributes are ignored.  I have a fix.

[Bug ipa/91508] [9 Regression] Segfault due to referencing removed cgraph_node

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0, 8.3.0
   Target Milestone|--- |9.3
Summary|Segfault due to referencing |[9 Regression] Segfault due
   |removed cgraph_node |to referencing removed
   ||cgraph_node
  Known to fail||9.2.0

[Bug ipa/91508] Segfault due to referencing removed cgraph_node

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-21
Version|unknown |9.2.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Ick, indeed.  It might also get reused since it is ggc_free()d...

Note trunk has

  for (i = nnodes - 1; i >= 0; i--)
{
  cgraph_node *node = order[i];

  /* Function could be inlined and removed as unreachable.  */
  if (node == NULL || removed_nodes.contains (node))
continue;

already, but not the GCC 9 branch.

[Bug other/91511] New: documentation of the effect of #pragma omp simd

[fx at gnu dot org]

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

Bug ID: 91511
   Summary: documentation of the effect of #pragma omp simd
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fx at gnu dot org
  Target Milestone: ---

The behaviour of the "omp simd" pragma may be unexpected, and it would be
useful if it could be spelt out somewhere in the docs.

Experimentally, using the pragma with -march=haswell generates avx2, but avoids
fma.  Thus is loses a factor of two on some loops versus auto-vectorization's
avx2+fma.  (I was experimenting with the BLIS library's generic C kernels for
GEMM. The maintainers use the pragma because they claim GCC won't vectorize
such loops, though it does for me with any GCC version which supports the
pragma.)

I'm not saying that's wrong -- it does say "simd" after all! -- but I think
most people would be surprised by the code generation.

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
(In reply to Andrew Pinski from comment #4)
> >This should fix it:
> 
> Except it is wrong.
> builtin_decl_explicit should be only used with BUILT_IN_NORMAL class.

I wish it would say so then; it only checks BUILTIN_VALID_P.

(In reply to rsand...@gcc.gnu.org from comment #6)
> Yeah, the C++ frontend calls copy_attributes_to_builtin outside
> the BUILT_IN_NORMAL block, whereas the C frontend calls it inside.

Good catch.  Thanks for fixing it.

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Look in the gcc sources, under gcc/config/rs6000/rs6000.c .

[Bug tree-optimization/88240] [7/8/9/10 Regression] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||6.4.0
   Target Milestone|--- |7.5
Summary|Potential optimization bug: |[7/8/9/10 Regression]
   |invalid pre-load of |Potential optimization bug:
   |floating-point value could  |invalid pre-load of
   |cause SIGFPE-underflow if   |floating-point value could
   |value is integer|cause SIGFPE-underflow if
   ||value is integer
  Known to fail||7.1.0

--- Comment #13 from Richard Biener  ---
Runtime testcase that aborts with -O2 -m32 -mno-sse (using fldl/fstpl):

int flag;
union { double f; unsigned long long i; } u;
void __attribute__((noinline))
init ()
{
  flag = 1;
  u.i = 18442936822990639076ULL;
}
unsigned long long __attribute__((noinline))
test ()
{
  if (flag)
return u.i;
  else
return u.f;
}
int main()
{
  init ();
  if (test () != 18442936822990639076ULL)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/91510] r253207 fixed a wrong-code bug

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-21
 CC||jamborm at gcc dot gnu.org
  Known to work||8.1.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I am testing a backport of that change.

[Bug tree-optimization/91482] __builtin_assume_aligned should not break write combining

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Aug 21 11:45:34 2019
New Revision: 274796

URL: https://gcc.gnu.org/viewcvs?rev=274796&root=gcc&view=rev
Log:
2019-08-21  Richard Biener  

PR tree-optimization/91482
* tree-ssa-ccp.c (ccp_folder::fold_stmt): Remove useless
BUILT_IN_ASSUME_ALIGNED calls.

* gcc.dg/tree-ssa/pr91482.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr91482.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug tree-optimization/91482] __builtin_assume_aligned should not break write combining

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed on trunk.

[Bug tree-optimization/91510] New: r253207 fixed a wrong-code bug

[rguenth at gcc dot gnu.org]

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

Bug ID: 91510
   Summary: r253207 fixed a wrong-code bug
   Product: gcc
   Version: 7.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

For GCC 8, r253207 fixed a wrong-code bug with SRA where we end up using
the 'double' member in

  union
  {
unsigned long long int uint_val;
long long int int_val;
double double_val;
  };

to copy the aggregate which, when using x87 instructions fldl/fstpl
can alter the bit-pattern.  See also PR88240 for a related issue.
It requires the correct amount of "luck" to hit, the following simplified
testcase doesn't hit it:

struct S
{
  int key;
  union
{
  unsigned long long int uint_val;
  long long int int_val;
  double double_val;
} u;
};

struct S get();

void copy (struct S *dst, struct S *src)
{
  struct S tem = get ();
  switch (tem.key)
{
case 0:
  dst->u.uint_val = tem.u.uint_val;
  break;
case 1:
  dst->u.int_val = tem.u.int_val;
  break;
case 2:
  dst->u.double_val = tem.u.double_val;
  break;
}
  dst->key = tem.key;
}

while from the full testcase the late SRA dump shows

 value_base* test(std::istream&) (struct istream & source)
 {
+  const double num$D37803$double_val;
   double D.44239;
   long long int D.44232;
   long long unsigned int D.44225;
@@ -733,11 +743,12 @@

[100.00%]:
   num = parseNumber (source_5(D)); [return slot optimization]
+  num$D37803$double_val_52 = MEM[(struct number_t *)&num + 4B];
   _1 = num.type;
   switch (_1)  [25.00%], case 0:  [25.00%], case 1: 
[25.00%], case 2:  [25.00%]>

  [25.00%]:
-  _30 = num.D.37803.uint_val;
+  _30 = VIEW_CONVERT_EXPR(num$D37803$double_val_52);
...

  [25.00%]:
-  _50 = num.D.37803.double_val;
+  _50 = num$D37803$double_val_52;

[Bug lto/50483] lto turns visibility from HIDDEN to DEFAULT

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Btw, I consistently do _not_ see HIDDEN here.  BFD issue?

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Yeah, the C++ frontend calls copy_attributes_to_builtin outside
the BUILT_IN_NORMAL block, whereas the C frontend calls it inside.

Testing a patch.

[Bug rtl-optimization/91509] -fprefetch-loop-arrays and LTO causes memory usage compiling wrf to go through the roof

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto, memory-hog
 Target||x86_64-*-*, arm-*-*,
   ||aarch64-*-*, s390*-*-*

--- Comment #1 from Richard Biener  ---
We have loads of

Ahead 19, unroll factor 16, trip count 9223372036854775807

and the code-size growth is BIG.  There's a single function in the
respective ltrans unit, 'integrate'.

You can also see the non-LTO binary size to double:
https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-megrez-head-64-2006/481_wrf-size_big.png

compared to the following increase which has prefetching disabled:
https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/481_wrf-size_big.png

Not sure what to do about this.  IIRC arm/aarch64/s390 also enable prefetching
in some circumstances.

[Bug rtl-optimization/91509] New: -fprefetch-loop-arrays and LTO causes memory usage compiling wrf to go through the roof

[rguenth at gcc dot gnu.org]

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

Bug ID: 91509
   Summary: -fprefetch-loop-arrays and LTO causes memory usage
compiling wrf to go through the roof
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Our daily SPEC 2006 tester on a bdver2 machine (thus, -fprefetch-loop-arrays is
on by default) runs into its 4GB virtual memory usage limit since r271377
when compiling with -Ofast -flto -march=native (where native is bdver2).

Memory use peaks at about 5.5GB where 4GB is reachend when first computing
DF live after RTL loop opts and the peak is during scheduling.  There are
a lot of pseudos around (~26) during DF live compute.

[Bug ipa/91508] New: Segfault due to referencing removed cgraph_node

[fxue at os dot amperecomputing.com]

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

Bug ID: 91508
   Summary: Segfault due to referencing removed cgraph_node
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Caught a segfault when compiling pr63766.C with debug version gcc. 

pr63766.C:48:1: internal compiler error: Segmentation fault
   48 | }
  | ^
0x14ace78 crash_signal
../../gcc/toplev.c:326
0x8fd7c5 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3256
0x1342850 do_per_function_toporder(void (*)(function*, void*), void*)
../../gcc/passes.c:1703
0x1345471 execute_ipa_pass_list(opt_pass*)
../../gcc/passes.c:2919
0xe10dba ipa_passes
../../gcc/cgraphunit.c:2480
0xe1120c symbol_table::compile()
../../gcc/cgraphunit.c:2618
0xe117d2 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2868

Analysis points to do_per_function_order()/passes.c, in which handling an 
cgraph_node in a worklist might remove later unprocessed node. So, it registers
a remove hook to track removed node by hashset, and uses node's uid as hashset
key. But this trick has a problem in that node's uid becomes garbage if the
node has been removed. Alternative way is to use node address as key.

 /* Function could be inlined and removed as unreachable.  */
 if (node == NULL || removed_nodes.contains (node->get_uid ()))
  ^^

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #13 from Uroš Bizjak  ---
> (In reply to rguent...@suse.de from comment #10) 
>> > +FAIL: gcc.target/i386/minmax-7.c scan-assembler pminsd
>> 
>> Not for me.  I've used -march=haswell in all of these testcases to
>> rule out ISA and cost issues.  So I really don't know what's the issue
>> with these FAILs.
>
> IIRC 32bit Solaris doesn't guarantee 16byte stack alignment, so STV is
> disabled.

Indeed: adding -mno-stackrealign (as is done in a couple of other STV
tests already) fixes this failure and the ones reported in PR
rtl-optimization/91154.

Tested with the appropriate runtest invocation on i386-pc-solaris2.11
and x86_64-pc-linux-gnu (both multilibs each).

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[ro at gcc dot gnu.org]

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

--- Comment #15 from Rainer Orth  ---
Created attachment 46737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46737&action=edit
Patch for 32-bit Solaris/x86 failures

[Bug rtl-optimization/91503] ICE ira-build.i:17:1: error: shared rtx

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Aug 21 08:44:59 2019
New Revision: 274792

URL: https://gcc.gnu.org/viewcvs?rev=274792&root=gcc&view=rev
Log:
2019-08-21  Richard Biener  

PR target/91498
PR target/91503
* config/i386/i386-features.c
(general_scalar_chain::make_vector_copies): Copy stack temporary
rtx when using it multiple times.
(general_scalar_chain::convert_reg): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-features.c

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Wed Aug 21 08:44:59 2019
New Revision: 274792

URL: https://gcc.gnu.org/viewcvs?rev=274792&root=gcc&view=rev
Log:
2019-08-21  Richard Biener  

PR target/91498
PR target/91503
* config/i386/i386-features.c
(general_scalar_chain::make_vector_copies): Copy stack temporary
rtx when using it multiple times.
(general_scalar_chain::convert_reg): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-features.c

[Bug rtl-optimization/91503] ICE ira-build.i:17:1: error: shared rtx

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
Yep, the fix is likely in the caller.

[Bug tree-optimization/91504] Inlining misses some logical operation folding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||easyhack,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-21
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The issue is likely that we inline deposit32 if it were

static inline unsigned deposit32(unsigned value, int start, int length,
 unsigned fieldval)
{
  unsigned mask = (~0U >> (32 - length)) << start;
  return (((fieldval << start) ^ value) & mask) ^ value;
}

changing bar() to the above form results in the same assembly for both.
We end up with (~value & 1024) ^ value:

  _5 = ~value_2(D);
  _3 = _5 & 1024;
  _4 = value_2(D) ^ _3;
  return _4;

on GIMPLE here, compared to

  _1 = value_2(D) & 4294966271;
  _3 = _1 | 1024;
  return _3;

in the good case.  The latter looks more canonical to me but on GIMPLE
is also not optimized fully since it should be simply

  _1 = value_2(D) | 1024;
  return _1;

AFAICS.

Confirmed.  It should be straight-forward to add some match.pd rules
to catch both.

[Bug rtl-optimization/91503] ICE ira-build.i:17:1: error: shared rtx

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-21
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I have a patch.

[Bug target/91502] suboptimal atomic_fetch_sub and atomic_fetch_add

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-21
Version|unknown |9.2.1
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.

[Bug debug/91507] wrong debug for completed array with previous incomplete declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
 CC||jsm28 at gcc dot gnu.org
  Known to fail||10.0, 9.2.1

--- Comment #1 from Richard Biener  ---
And the C frontend confuses dwarf2out here by calling
dwarf2out_early_global_decl
twice with the same decl but with different unrelated TREE_TYPE of it.
There's of couse no way it can be expected to recover from that?  I guess
the situation can only arise for decls at global scope?  So we could
in theory try to lookup the DIE for the decls type after looking up a
specification DIE and emit a new DIE for it?  Ideally we'd have marked
the earlier DIE as "incomplete" somehow.

[Bug d/91339] libphobos: ftbfs when the path contains '~'

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Should be fixed as of r274771.

[Bug d/88722] :1: internal compiler error: in register_moduleinfo, at d/modules.cc:40 2

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw  ---
The ICE is no more as of r274769, but phobos still can't be built.  Adding
support for targets without targetm_common.have_named_sections could be tracked
in a separate PR.

[Bug debug/91507] New: wrong debug for completed array with previous incomplete declaration

[rguenth at gcc dot gnu.org]

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

Bug ID: 91507
   Summary: wrong debug for completed array with previous
incomplete declaration
   Product: gcc
   Version: 7.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

extern char *zzz[];
char *zzz[ ] = {
"abc",
"cde"
};

according to the C standard the array type of zzz is completed at the end
of the initializer list but we emit the following dwarf where the definition
inherits the type specification of the declaration:

 <1><1d>: Abbrev Number: 2 (DW_TAG_array_type)
<1e>   DW_AT_type: <0x28>
<22>   DW_AT_sibling : <0x28>
 <2><26>: Abbrev Number: 3 (DW_TAG_subrange_type)
 <2><27>: Abbrev Number: 0
...
 <1><35>: Abbrev Number: 6 (DW_TAG_variable)
<36>   DW_AT_name: zzz
<3a>   DW_AT_decl_file   : 1
<3b>   DW_AT_decl_line   : 1
<3c>   DW_AT_decl_column : 14
<3d>   DW_AT_type: <0x1d>
<41>   DW_AT_external: 1
<41>   DW_AT_declaration : 1
...
 <1><48>: Abbrev Number: 7 (DW_TAG_variable)
<49>   DW_AT_specification: <0x35>
<4d>   DW_AT_decl_line   : 2
<4e>   DW_AT_decl_column : 7
<4f>   DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)

technically this is a regression from before early-debug where we omitted
debug info for the declaration.  Correct debug info is emitted if the
declaration is omitted.

[Bug d/90444] internal compiler error: in d_init_builtins, at d/d-builtins.cc:1121

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in mainline r274765.

[Bug d/90445] internal compiler error: in d_build_c_type_nodes, at d/d-builtins.cc:783

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in mainline r274766.

[Bug d/90446] ICE: Segmentation fault in build_function_type at gcc/tree.c:8539

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Iain Buclaw  ---
Fixed in r274767.

[Bug d/91339] libphobos: ftbfs when the path contains '~'

[ibuclaw at gcc dot gnu.org]

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

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Aug 21 07:54:06 2019
New Revision: 274771

URL: https://gcc.gnu.org/viewcvs?rev=274771&root=gcc&view=rev
Log:
PR d/91339
d/dmd: Merge upstream dmd b37a537d3

Fixes the error: cannot find source code for runtime library file
'object.d' when the path contains '~'.

Reviewed-on: https://github.com/dlang/dmd/pull/10309

Modified:
trunk/gcc/d/dmd/MERGE
trunk/gcc/d/dmd/root/filename.c

[Bug d/88722] :1: internal compiler error: in register_moduleinfo, at d/modules.cc:40 2

[ibuclaw at gcc dot gnu.org]

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

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Aug 21 07:53:44 2019
New Revision: 274769

URL: https://gcc.gnu.org/viewcvs?rev=274769&root=gcc&view=rev
Log:
d: Partially fix ICE: in register_moduleinfo, at d/modules.cc:40

gcc/d/ChangeLog:

PR d/88722
* modules.cc: Include diagnostic.h.
(register_moduleinfo): Use sorry instead of gcc_assert for targets
without named sections.

Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/modules.cc

[Bug d/90446] ICE: Segmentation fault in build_function_type at gcc/tree.c:8539

[ibuclaw at gcc dot gnu.org]

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

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Aug 21 07:53:25 2019
New Revision: 274767

URL: https://gcc.gnu.org/viewcvs?rev=274767&root=gcc&view=rev
Log:
d: Fix ICE: Segmentation fault in build_function_type at gcc/tree.c:8539

gcc/d/ChangeLog:

PR d/90446
* d-lang.cc (d_type_for_mode): Check for all internal __intN types.
(d_type_for_size): Likewise.

Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/d-lang.cc

[Bug d/90444] internal compiler error: in d_init_builtins, at d/d-builtins.cc:1121

[ibuclaw at gcc dot gnu.org]

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

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Aug 21 07:53:05 2019
New Revision: 274765

URL: https://gcc.gnu.org/viewcvs?rev=274765&root=gcc&view=rev
Log:
d: Fix internal compiler error: in d_init_builtins, at d/d-builtins.cc:1121

gcc/d/ChangeLog:

PR d/90444
* d-builtins.cc (build_frontend_type): Build anonymous RECORD_TYPE
nodes as well, push all fields to the struct members.
(d_build_builtins_module): Push anonymous va_list structs to the
builtins module, naming them __builtin_va_list.
(d_init_builtins): Use sorry instead of gcc_unreachable if va_list did
not succeed in being represented as a D type.

Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/d-builtins.cc

[Bug d/90445] internal compiler error: in d_build_c_type_nodes, at d/d-builtins.cc:783

[ibuclaw at gcc dot gnu.org]

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

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Aug 21 07:53:15 2019
New Revision: 274766

URL: https://gcc.gnu.org/viewcvs?rev=274766&root=gcc&view=rev
Log:
d: Fix internal compiler error: in d_build_c_type_nodes, at d/d-builtins.cc:783

gcc/d/ChangeLog:

PR d/90445
* d-builtins.cc (d_build_c_type_nodes): Test UINTMAX_TYPE for setting
uintmax_type_node.  Set signed_size_type_node as the signed_type_for
size_type_node.

Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/d-builtins.cc

[Bug tree-optimization/91491] [9 Regression] glib2.0 build not working when built with -O2 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Richard Biener  ---
(In reply to Simon McVittie from comment #5)
> So I think this can be closed as not your bug. Sorry for the noise.

No problem - always glad to help.

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to rguent...@suse.de from comment #10) 
> > +FAIL: gcc.target/i386/minmax-7.c scan-assembler pminsd
> 
> Not for me.  I've used -march=haswell in all of these testcases to
> rule out ISA and cost issues.  So I really don't know what's the issue
> with these FAILs.

IIRC 32bit Solaris doesn't guarantee 16byte stack alignment, so STV is
disabled.

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[dimhen at gmail dot com]

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

Dmitry G. Dyachenko  changed:

   What|Removed |Added

 CC||dimhen at gmail dot com

--- Comment #12 from Dmitry G. Dyachenko  ---
(In reply to Arseny Solokha from comment #9)
> (In reply to H.J. Lu from comment #7)
> > Our SPEC CPU 2017 failed with
> > 
> >  39 util.c:205:1: error: invalid rtl sharing found in the insn
> >  40   205 | }
> >  41   | ^
> >  42 (insn 29 28 3 2 (set (subreg:V2DI (reg:DI 91) 0)
> >  43 (vec_concat:V2DI (mem/c:DI (plus:DI (reg/f:DI 19 frame)
> >  44 (const_int -8 [0xfff8])) [0  S8 A64])
> >  45 (const_int 0 [0]))) "util.c":134:1 -1
> >  46  (nil))
> >  47 util.c:205:1: error: shared rtx
> >  48 (mem/c:DI (plus:DI (reg/f:DI 19 frame)
> >  49 (const_int -8 [0xfff8])) [0  S8 A64])
> >  50 during RTL pass: stv
> > 
> > We have an invalid shared rtx.
> 
> And the testcase is as simple as:
> 
> int
> ff (int jn)
> {
>   return jn > 0 ? jn : 0;
> }
> 
> % x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190818 -march=nano-3000 -Os -c
> f9272pqv.c
> f9272pqv.c: In function 'ff':
> f9272pqv.c:5:1: error: invalid rtl sharing found in the insn
> 5 | }
>   | ^
> (insn 18 17 3 2 (set (subreg:V4SI (reg:SI 87) 0)
> (vec_merge:V4SI (vec_duplicate:V4SI (mem/c:SI (plus:DI (reg/f:DI 19
> frame)
> (const_int -4 [0xfffc])) [0  S4 A32]))
> (const_vector:V4SI [
> (const_int 0 [0]) repeated x4
> ])
> (const_int 1 [0x1]))) "f9272pqv.c":3:1 -1
>  (nil))
> f9272pqv.c:5:1: error: shared rtx
> (mem/c:SI (plus:DI (reg/f:DI 19 frame)
> (const_int -4 [0xfffc])) [0  S4 A32])
> during RTL pass: stv
> f9272pqv.c:5:1: internal compiler error: internal consistency failure
> 0x9f3eca verify_rtx_sharing
>   
> /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/
> gcc/emit-rtl.c:2927
> 0x9f3dba verify_rtx_sharing
>   
> /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/
> gcc/emit-rtl.c:2942
> 0x9f3dba verify_rtx_sharing
>   
> /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/
> gcc/emit-rtl.c:2942
> 0x9f3dba verify_rtx_sharing
>   
> /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/
> gcc/emit-rtl.c:2942
> 0x9f4178 verify_insn_sharing
>   
> /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/
> gcc/emit-rtl.c:3013
> 0x9f79ed verify_rtl_sharing()
>   
> /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/
> gcc/emit-rtl.c:3036
> 0xc7a8f3 execute_function_todo
>   
> /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/
> gcc/passes.c:2004
> 0xc7b536 execute_todo
>   
> /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/
> gcc/passes.c:2037

sounds like PR91503

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Tue, 20 Aug 2019, asolokha at gmx dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91498
> 
> Arseny Solokha  changed:
> 
>What|Removed |Added
> 
>  CC||asolokha at gmx dot com
> 
> --- Comment #9 from Arseny Solokha  ---
> (In reply to H.J. Lu from comment #7)
> > Our SPEC CPU 2017 failed with
> > 
> >  39 util.c:205:1: error: invalid rtl sharing found in the insn
> >  40   205 | }
> >  41   | ^
> >  42 (insn 29 28 3 2 (set (subreg:V2DI (reg:DI 91) 0)
> >  43 (vec_concat:V2DI (mem/c:DI (plus:DI (reg/f:DI 19 frame)
> >  44 (const_int -8 [0xfff8])) [0  S8 A64])
> >  45 (const_int 0 [0]))) "util.c":134:1 -1
> >  46  (nil))
> >  47 util.c:205:1: error: shared rtx
> >  48 (mem/c:DI (plus:DI (reg/f:DI 19 frame)
> >  49 (const_int -8 [0xfff8])) [0  S8 A64])
> >  50 during RTL pass: stv
> > 
> > We have an invalid shared rtx.
> 
> And the testcase is as simple as:
> 
> int
> ff (int jn)
> {
>   return jn > 0 ? jn : 0;
> }
> 
> % x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190818 -march=nano-3000 -Os -c
> f9272pqv.c
> f9272pqv.c: In function 'ff':
> f9272pqv.c:5:1: error: invalid rtl sharing found in the insn
> 5 | }
>   | ^
> (insn 18 17 3 2 (set (subreg:V4SI (reg:SI 87) 0)
> (vec_merge:V4SI (vec_duplicate:V4SI (mem/c:SI (plus:DI (reg/f:DI 19
> frame)
> (const_int -4 [0xfffc])) [0  S4 A32]))
> (const_vector:V4SI [
> (const_int 0 [0]) repeated x4
> ])
> (const_int 1 [0x1]))) "f9272pqv.c":3:1 -1
>  (nil))

I have a patch.

[Bug rtl-optimization/91503] ICE ira-build.i:17:1: error: shared rtx

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
Untested patch to fix this issue.

1 file changed, 2 insertions(+)
gcc/config/i386/i386-features.c | 2 ++

modified   gcc/config/i386/i386-features.c
@@ -707,6 +707,8 @@ general_scalar_chain::make_vector_copies (unsigned regno)
  }
else
  emit_move_insn (tmp, reg);
+   /* Avoid invalid rtl sharing.  */
+   tmp = copy_rtx (tmp);
emit_insn (gen_rtx_SET (gen_rtx_SUBREG (vmode, vreg, 0),
gen_gpr_to_xmm_move_src (vmode, tmp)));
  }

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Tue, 20 Aug 2019, ro at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91498
> 
> Rainer Orth  changed:
> 
>What|Removed |Added
> 
>  CC||ro at gcc dot gnu.org
> 
> --- Comment #8 from Rainer Orth  ---
> The new testcase FAILs on both i386-pc-solaris2.11 and x86_64-pc-linux-gnu 
> with
> -m32:
> 
> +FAIL: gcc.target/i386/minmax-7.c scan-assembler pminsd

Not for me.  I've used -march=haswell in all of these testcases to
rule out ISA and cost issues.  So I really don't know what's the issue
with these FAILs.