[Bug rtl-optimization/97170] Wrong optimization in fwprop pass

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
target_fcvt is wrong.
try:
(define_insn "target_fcvt"
  [(set (match_operand:SI 0 "register_operand" "=r")
(unspec:SI [(match_operand:SF 1 "register_operand" "f")
(reg:SI FCVTMODE_REGNUM)]
UNSPEC_FCVT))]
  ""
  "fcvt\t%0,%1"
)

instead.  Basically the set is not dependent on the reg (FCVTMODE_REGNUM) only
the instruction itself which is what ever.

[Bug rtl-optimization/97170] New: Wrong optimization in fwprop pass

[rjiejie at me dot com]

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

Bug ID: 97170
   Summary: Wrong optimization in fwprop pass
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjiejie at me dot com
  Target Milestone: ---

insn seqs:

s1:

__builtin_set_float_convert_mode(0);
r1 = __builtin_load(a1, a2);
r2 = __builtin_float_convert(r1);
__builtin_store(a3, r2);
__builtin_set_float_convert_mode(0);

s2:
__builtin_set_float_convert_mode(1);
r1 = __builtin_load(a1, a2);
r2 = __builtin_float_convert(r1);
__builtin_store(a3, r2);
__builtin_set_float_convert_mode(0);


the diference of s1 and s2 only is "__builtin_set_float_convert_mode"

from beginning, the s1 mode is set 0, but s2 mode is set 1.

from optimization 'fwprop', the s2 insns seqs is deleted 

as dead code, is it gcc bug ?



builtin patten of __builtin_set_float_convert_mode:


(define_insn "target_fcvtmode"
  [(set (reg:SI FCVTMODE_REGNUM)
(unspec_volatile:SI [(match_operand:SI 0 "csr_operand" "rK")]
UNSPECV_FCVTMODE))]
  ""
  "fcvtmode\t%1"
)


builtin patten of __builtin_set_float_convert_mode:

(define_insn "target_fcvt"
  [(set (match_operand:SI 0 "register_operand" "=r")
(unspec:SI [(match_operand:SF 1 "register_operand" "f")]
UNSPEC_FCVT))
   (use (reg:SI FCVTMODE_REGNUM))]
  ""
  "fcvt\t%0,%1"
)


As far as i know, __builtin_set_float_convert_mode depend on 'FCVTMODE_REGNUM'
which is from
__builtin_set_float_convert_mode, it's not dead code.

or something wrong in my pattens ?

Anyone could give me some hints ?

Thanks

[Bug c++/80456] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression

[lebed.dmitry at gmail dot com]

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

Dmitry Lebed  changed:

   What|Removed |Added

 CC||lebed.dmitry at gmail dot com

--- Comment #7 from Dmitry Lebed  ---
Just encountered the same issue independently
https://stackoverflow.com/questions/64019728/are-there-any-caveats-in-c-with-constexpr-static-function-usage-in-volatile

It's sad to see that it's already 3 years without fix.
It's still valid for GCC trunk (according to godbolt) and at 10.2 (according to
my local tests).

Any hope in fixing this?

[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake

[crazylht at gmail dot com]

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

--- Comment #7 from Hongtao.liu  ---
(In reply to Michael_S from comment #6)
> Why do you see it as addition of peephole pattern?
> I see it as removal. Like, "do what's written in the source and don't try to
> be tricky".
> Probably, I am too removed from how compilers work :(
> 
> Or, may be, handle it at the level of cost of instructions?

Since the costs inside/outside of a loop are different, it's too rough to use
an unified cost to do estimation.

> I don't know how gcc works internally, but it seems that currently the cost
> of register move [on Haswell and Skylake] is underestimated.
> Although it is true that register move has no cost in terms of execution
> ports and latency, it still has the same cost as, say, integer ALU
> instructions, in terms of the front end and renamer.
> 
> Also, as pointed out above by Alexander, the cost of FMA3 with (base+index)
> or (index*scale) memory operands could also be underestimated.
> 
> Unlike Alexander, I am not sure that the difference between (base+index) and
> (base) is really what matters. IMO, the cost of FMA3 with *any* memory
> operands is underestimated, but I am not going to insist on that.
> 

We can increase FMA3 cost if it has memory operand, but not sure would it
benifit all cases, especially for those not in inner loop.

> 
> In the ideal world compiler should reason as I do it myself when coding in
> asm:
> estimate which resource is critical in the given loop and then try to reduce
> pressure on this particular resource. In this particular loop a critical
> resource appears to be renamer, so the cost of instructions should be seen
> as cost at renamer. In other situations critical resource could be
> throughput of particular issue port. In yet another situation it could be
> latency of instructions that form dependency chain across multiple

AFAIK, resource like issue port is only consided in software scheduler, but
scheduler won't do instruction tranformation like that, even scheduler itself
is subtle when target supports out-of-order execution.

> iterations of the loop.
> The later is especially common in "reduction" algorithms of which dot
> product is the most common example.
> A single value of instruction cost simply can't cover all these different
> cases in satisfactory manner.
> May be, gcc it's already here, I don't know.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Ah.

Is there no better way to detect GCC impostors?  Oh well.

Since we require 4.5 as bootstrap compiler, this makes no difference
at all for compilers that truthfully claim to be GCC, so it has my
blessing if you want that :-)

Thanks!

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
It can be anything > 4.2 (because clang pretends to be GCC 4.2).

4.5 was just because the other altivec section was >= 4.5.
PR45381 contains some details about that.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Yeah, good point.

So either we can convert to the normal intrinsics, or (much easier)
check we are building with GCC at all.  But why 4.5?  Do earlier
versions not work?

[Bug jit/97169] [11 Regression] Most jit.dg tests segfaulting (modref_summaries finalizer?)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Root cause analysis here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554549.html

[Bug c++/96652] Segmentation fault with instantiate_class_template_1

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |11.0

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 11.

[Bug target/97156] Missed optimization [x86-64] tzcnt unnecessarily zeros out destination register

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
https://stackoverflow.com/questions/21390165/why-does-breaking-the-output-dependency-of-lzcnt-matter

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

This was done because it is needed for some (most) Intel processors have an
errata were popcnt and tzcnt cause a false depenency on the destition register.

[Bug c++/96652] Segmentation fault with instantiate_class_template_1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r11-3371-gc4e4e163c79ca3fca265b85f44b869cb54e802b3
Author: Patrick Palka 
Date:   Tue Sep 22 16:26:49 2020 -0400

c++: Add test for PR96652

Fixed by r11-3361.

gcc/testsuite/ChangeLog:

PR c++/96652
* g++.dg/cpp0x/decltype-96652.C: New test.

[Bug libstdc++/97167] [9/10/11 Regression] string_view bounds error in filesystem::path

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 9.4 and 10.3

[Bug libstdc++/97167] [9/10/11 Regression] string_view bounds error in filesystem::path

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

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

commit r9-8932-ge7285587186bac5692171d7493e29e16c729281d
Author: Jonathan Wakely 
Date:   Tue Sep 22 20:02:58 2020 +0100

libstdc++: Fix out-of-bounds string_view access in filesystem::path [PR
97167]

libstdc++-v3/ChangeLog:

PR libstdc++/97167
* src/c++17/fs_path.cc (path::_Parser::root_path()): Check
for empty string before inspecting the first character.
* testsuite/27_io/filesystem/path/append/source.cc: Append
empty string_view to path.

(cherry picked from commit 49ff88bd0d8a36a9e903f01ce05685cfe07dee5d)

Re: [Bug tree-optimization/97159] [11 Regression] segfault in modref_may_conflict

[Jan Hubicka]

Recursion is handled in normal compilation (we analyze the function and
while hitting the recursive call we skip the summary). I suppose here
the problem is missing LTO and offloading. 

With LTO lto summaries (that include types) are streamed out while they
are turned into non-lto summaries at ltrans time.  We need to do similar
thing with offload.

Honza

[Bug tree-optimization/97159] [11 Regression] segfault in modref_may_conflict

[hubicka at ucw dot cz]

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

--- Comment #3 from Jan Hubicka  ---
Recursion is handled in normal compilation (we analyze the function and
while hitting the recursive call we skip the summary). I suppose here
the problem is missing LTO and offloading. 

With LTO lto summaries (that include types) are streamed out while they
are turned into non-lto summaries at ltrans time.  We need to do similar
thing with offload.

Honza

[Bug jit/97169] [11 Regression] FAIL: jit.dg/test-compile-to-assembler.c

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
Segfaults started with g:d119f34c952f8718fdbabc63e2f369a16e92fa07 aka "New
modref/ipa_modref optimization passes"

[Bug jit/97169] [11 Regression] FAIL: jit.dg/test-compile-to-assembler.c

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-09-22
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed; thanks for filing this.  We've been discussing this at
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554445.html

[Bug fortran/97063] [ MATMUL intrinsic] The value of result is wrong when vector (step size is negative) * matrix

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Having looked at the tree-dump, I am not sure if it is a FE or a library issue.

I appears that the negative stride miscalculates the base or offset of
the array probably by one:

program p
  implicit none
  integer   :: i, j
  real, dimension(6):: arr1 = [(i,i=0,5)]
  real, dimension(6,10) :: arr2 = reshape ([(((i+j),i=0,5),j=0,9)],[6,10])
  real, dimension(10)   :: arr3, arr6
  real, dimension(3):: arr4
  arr4 = arr1(5:1:-2)
  write(*,*) "--arr6--:"
  arr6 = matmul (arr4, arr2(5:1:-2, :))
  write(*,'(10F6.1)') arr6
  arr4 = arr1(6:2:-2)
  write(*,*) "--arr6-- (with arr1 off by one):"
  arr6 = matmul (arr4, arr2(5:1:-2, :))
  write(*,'(10F6.1)') arr6
  arr3 = matmul (arr1(5:1:-2), arr2(5:1:-2, :))
  write(*,*) "--arr3--:"
  write(*,'(10F6.1)') arr3
end program

This prints:

 --arr6--:
  20.0  26.0  32.0  38.0  44.0  50.0  56.0  62.0  68.0  74.0
 --arr6-- (with arr1 off by one):
  26.0  35.0  44.0  53.0  62.0  71.0  80.0  89.0  98.0 107.0
 --arr3--:
  26.0  35.0  44.0  53.0  62.0  71.0  80.0  89.0  98.0 107.0

[Bug c++/96745] [concepts] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-09-22
 Ever confirmed|0   |1
  Known to fail||10.2.0, 11.0
 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Confirmed.

[Bug libstdc++/97167] [9/10/11 Regression] string_view bounds error in filesystem::path

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-8789-gebf259b243069e77dc7199072304b455e8fcb865
Author: Jonathan Wakely 
Date:   Tue Sep 22 20:02:58 2020 +0100

libstdc++: Fix out-of-bounds string_view access in filesystem::path [PR
97167]

libstdc++-v3/ChangeLog:

PR libstdc++/97167
* src/c++17/fs_path.cc (path::_Parser::root_path()): Check
for empty string before inspecting the first character.
* testsuite/27_io/filesystem/path/append/source.cc: Append
empty string_view to path.

(cherry picked from commit 49ff88bd0d8a36a9e903f01ce05685cfe07dee5d)

[Bug jit/97169] New: [11 Regression] FAIL: jit.dg/test-compile-to-assembler.c

[msebor at gcc dot gnu.org]

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

Bug ID: 97169
   Summary: [11 Regression] FAIL:
jit.dg/test-compile-to-assembler.c
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Recent builds with GCC 11 show a number of jit test failures including the
following:

FAIL: did not find a generated reproducer:
test-nested-contexts.c.exe.reproducer.c
FAIL: emit-alphabet.bf.exe does not have executable bit set
FAIL: jit.dg/test-compile-to-assembler.c, assemble/link of
output-of-test-compile-to-assembler.c.s
FAIL: jit.dg/test-compile-to-object.c, link of
output-of-test-compile-to-object.c.o
FAIL: output-of-test-compile-to-assembler.c.s does not exist
FAIL: output-of-test-compile-to-dynamic-library.c.so does not exist
FAIL: output-of-test-compile-to-executable.c.exe does not exist
FAIL: output-of-test-compile-to-executable.c.exe does not have executable bit
set
FAIL: output-of-test-compile-to-object.c.o does not exist
FAIL: test-accessing-bitfield.c.exe killed: 25351 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-accessing-struct.c.exe killed: 26167 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-accessing-union.c.exe killed: 27023 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-add-driver-options.c.exe killed: 27854 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-alignment.c.exe killed: 28587 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-alignment.cc.exe killed: 32060 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-arith-overflow.c.exe killed: 1372 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-array-as-pointer.c.exe killed: 2878 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-arrays.c.exe killed: 3705 exp7 0 0 CHILDKILLED SIGSEGV {segmentation
violation}
FAIL: test-autovectorize.c.exe killed: 4679 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-benchmark.c.exe killed: 5594 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-builtin-memcpy.c.exe killed: 6244 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-builtin-unreachable.c.exe killed: 6948 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-calling-external-function.c.exe killed: 7733 exp7 0 0 CHILDKILLED
SIGSEGV {segmentation violation}
FAIL: test-calling-function-ptr.c.exe killed: 8576 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-combination.c.exe killed: 10625 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-compile-to-assembler.c.exe killed: 3814 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-compile-to-dynamic-library.c.exe killed: 4825 exp7 0 0 CHILDKILLED
SIGSEGV {segmentation violation}
FAIL: test-compile-to-executable.c.exe killed: 5780 exp7 0 0 CHILDKILLED
SIGSEGV {segmentation violation}
FAIL: test-compile-to-object.c.exe killed: 6624 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-compound-assignment.c.exe killed: 7590 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-constants.c.exe killed: 8630 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-debug-strings.c.exe killed: 9850 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-dot-product.c.exe killed: 10664 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-empty.c.exe killed: 11479 exp7 0 0 CHILDKILLED SIGSEGV {segmentation
violation}
FAIL: test-error-array-bounds.c.exe killed: 12809 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-error-gcc_jit_context_new_bitfield-invalid-width.c.exe killed: 18929
exp7 0 0 CHILDKILLED SIGSEGV {segmentation violation}
FAIL: test-error-gcc_jit_lvalue_get_address-bitfield.c.exe killed: 22557 exp7 0
0 CHILDKILLED SIGSEGV {segmentation violation}
FAIL: test-error-gcc_jit_timer_pop-mismatch.c.exe killed: 24156 exp7 0 0
CHILDKILLED SIGSEGV {segmentation violation}
FAIL: test-error-gcc_jit_timer_pop-too-many.c.exe killed: 25003 exp7 0 0
CHILDKILLED SIGSEGV {segmentation violation}
FAIL: test-error-impossible-must-tail-call.c.exe killed: 26856 exp7 0 0
CHILDKILLED SIGSEGV {segmentation violation}
FAIL: test-error-pr63969-missing-driver.c.exe killed: 31555 exp7 0 0
CHILDKILLED SIGSEGV {segmentation violation}
FAIL: test-error-unrecognized-dump.c.exe killed: 347 exp7 0 0 CHILDKILLED
SIGSEGV {segmentation violation}
FAIL: test-expressions.c.exe killed: 2443 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-extra-options.c.exe killed: 5388 exp7 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-factorial-must-tail-call.c.exe killed: 6370 exp7 0 0 CHILDKILLED
SIGSEGV {segmentation violation}
FAIL: test-factorial.c.exe killed: 7346 exp7 0 0 

[Bug plugins/97168] New: [11 Regression] FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c, diagnostic-test-paths-2.c, location-overflow-test-1.c

[msebor at gcc dot gnu.org]

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

Bug ID: 97168
   Summary: [11 Regression] FAIL:
gcc.dg/plugin/diagnostic-test-expressions-1.c,
diagnostic-test-paths-2.c, location-overflow-test-1.c
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Recent builds with GCC 11 show a number of plugin test failures including the
following:

FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
-fplugin=./diagnostic_plugin_test_tree_expression_range.so  1 blank line(s) in
output
FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
-fplugin=./diagnostic_plugin_test_tree_expression_range.so  expected multiline
pattern lines 550-551 not found: "   
__builtin_types_compatible_p \\(long, int\\) \\+ f \\(i\\)\\);.*\\n
   ~\\^~~\\n"
FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
-fplugin=./diagnostic_plugin_test_tree_expression_range.so (test for excess
errors)
FAIL: gcc.dg/plugin/diagnostic-test-paths-2.c
-fplugin=./diagnostic_plugin_test_paths.so  expected multiline pattern lines
36-54 not found: "\\s*29 \\| PyList_Append\\(list, item\\);.*\\n  \\|  
  \\^\\n  'make_a_list_of_random_ints_badly': events
1-3.*\\n\\|.*\\n\\|   25 \\|   list = PyList_New\\(0\\);.*\\n\\|   
  \\|  \\^\\n\\|  \\|  \\|.*\\n\\| 
\\|  \\(1\\) when 'PyList_New' fails, returning NULL.*\\n\\|   26
\\| .*\\n\\|   27 \\|   for \\(i = 0; i < count; i\\+\\+\\) \\{.*\\n\\|
 \\|   ~~~ .*\\n\\|  \\|   \\|.*\\n\\|  \\|   \\(2\\)
when 'i < count'.*\\n\\|   28 \\| item =
PyLong_FromLong\\(random\\(\\)\\);.*\\n\\|   29 \\|
PyList_Append\\(list, item\\);.*\\n\\|  \\|
~\\n\\|  \\| \\|.*\\n\\|  \\|
\\(3\\) when calling 'PyList_Append', passing NULL from \\(1\\) as argument
1.*\\n\\|.*\\n"
FAIL: gcc.dg/plugin/diagnostic-test-paths-2.c
-fplugin=./diagnostic_plugin_test_paths.so (test for excess errors)
FAIL: gcc.dg/plugin/location-overflow-test-1.c
-fplugin=./location_overflow_plugin.so adding '-flarge-source-files' (test for
warnings, line 16)

[Bug c++/97145] Sanitizer pointer-subtract breaks constexpr functions subtracting pointers

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-3368-gbc13106e0414b86af8f6878e7681e6a959921b9e
Author: Jakub Jelinek 
Date:   Tue Sep 22 21:06:32 2020 +0200

c++: Ignore __sanitizer_ptr_{sub,cmp} builtin calls during constant
expression evaluation [PR97145]

These two builtin calls are added already during parsing before pointer
subtractions or comparisons, normally they perform runtime verification
of whether the pointers point to the same object or different objects,
but during constant expressione valuation we don't really need those
builtins for anything.

2020-09-22  Jakub Jelinek  

PR c++/97145
* constexpr.c (cxx_eval_builtin_function_call): Return void_node
for
calls to __sanitize_ptr_{sub,cmp} builtins.

* g++.dg/asan/pr97145.C: New test.

[Bug libstdc++/97167] [9/10/11 Regression] string_view bounds error in filesystem::path

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:49ff88bd0d8a36a9e903f01ce05685cfe07dee5d

commit r11-3367-g49ff88bd0d8a36a9e903f01ce05685cfe07dee5d
Author: Jonathan Wakely 
Date:   Tue Sep 22 20:02:58 2020 +0100

libstdc++: Fix out-of-bounds string_view access in filesystem::path [PR
97167]

libstdc++-v3/ChangeLog:

PR libstdc++/97167
* src/c++17/fs_path.cc (path::_Parser::root_path()): Check
for empty string before inspecting the first character.
* testsuite/27_io/filesystem/path/append/source.cc: Append
empty string_view to path.

[Bug libffi/97166] libffi build issue when compiling with -mcpu=power10

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

  Known to fail||10.0

--- Comment #1 from Peter Bergner  ---
The same issue affects the libffi in GCC 10 sources, since GCC 10 has power10
support, so that needs fixing too.

[Bug libstdc++/97167] [9/10/11 Regression] string_view bounds error in filesystem::path

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||8.4.0
   Last reconfirmed||2020-09-22
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||10.2.0, 11.0, 9.3.0
   Target Milestone|--- |9.4

--- Comment #1 from Jonathan Wakely  ---
I have a patch

[Bug libstdc++/97167] New: [9/10/11 Regression] string_view bounds error in filesystem::path

[redi at gcc dot gnu.org]

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

Bug ID: 97167
   Summary: [9/10/11 Regression] string_view bounds error in
filesystem::path
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This segfaults since 9.1.0:

#include 

int main()
{
  std::filesystem::path p;
  std::string_view s;
  p /= s;
}

[Bug libffi/97166] New: libffi build issue when compiling with -mcpu=power10

[bergner at gcc dot gnu.org]

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

Bug ID: 97166
   Summary: libffi build issue when compiling with -mcpu=power10
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

When building libffi with -mcpu=power10, we're seeing the following linker
error.

libtool: link: gcc -shared  -fPIC -DPIC  src/.libs/prep_cif.o src/.libs/types.o
src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o
src/powerpc/.libs/ffi.o src/powerpc/.libs/ffi_sysv.o
src/powerpc/.libs/ffi_linux64.o src/powerpc/.libs/sysv.o
src/powerpc/.libs/ppc_closure.o src/powerpc/.libs/linux64.o
src/powerpc/.libs/linux64_closure.o-O3 -mcpu=power10 -Wl,--version-script
-Wl,libffi.map   -Wl,-soname -Wl,libffi.so.8 -o .libs/libffi.so.8.1.0
src/powerpc/.libs/linux64.o: in function `ffi_call_LINUX64':
(.text+0x40): call to `ffi_prep_args64' lacks nop, can't restore toc; (toc
save/adjust stub)
/home/bergner/gcc/install/gcc-fsf-mainline-power10/bin/ld: final link failed:
bad value
collect2: error: ld returned 1 exit status
Makefile:1028: recipe for target 'libffi.la' failed

This ends up being a bug in some POWER specific libffi asm code that doesn't
know about our new to POWER10 PCREL support.  This bugzilla is to track syncing
the fix to libffi into GCC version of libffi, which is being tracked upstream
here:

  https://github.com/libffi/libffi/pull/584

[Bug target/61551] [NEON] alter costs to allow use of post-indexed addressing modes for VLD{2..4}/VST{2..4}

[cbaylis at gcc dot gnu.org]

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

cbaylis at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from cbaylis at gcc dot gnu.org ---

This was fixed in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=612ea540d2e1fe5eae5213823a3cec0d3d864fb2

 This patch adds support for modelling the varying costs of different
addressing modes.

This patch adds support for modelling the varying costs of
different addressing modes. The generic cost table treats
all addressing modes as having equal cost.

gcc/ChangeLog:

2017-11-23  Charles Baylis  

* config/arm/arm-protos.h (enum arm_addr_mode_op): New.
(struct addr_mode_cost_table): New.
(struct tune_params): Add field addr_mode_costs.
* config/arm/arm.c (generic_addr_mode_costs): New.
(arm_slowmul_tune): Initialise addr_mode_costs field.
(arm_fastmul_tune): Likewise.
(arm_strongarm_tune): Likewise.
(arm_xscale_tune): Likewise.
(arm_9e_tune): Likewise.
(arm_marvell_pj4_tune): Likewise.
(arm_v6t2_tune): Likewise.
(arm_cortex_tune): Likewise.
(arm_cortex_a8_tune): Likewise.
(arm_cortex_a7_tune): Likewise.
(arm_cortex_a15_tune): Likewise.
(arm_cortex_a35_tune): Likewise.
(arm_cortex_a53_tune): Likewise.
(arm_cortex_a57_tune): Likewise.
(arm_exynosm1_tune): Likewise.
(arm_xgene1_tune): Likewise.
(arm_cortex_a5_tune): Likewise.
(arm_cortex_a9_tune): Likewise.
(arm_cortex_a12_tune): Likewise.
(arm_cortex_a73_tune): Likewise.
(arm_v7m_tune): Likewise.
(arm_cortex_m7_tune): Likewise.
(arm_v6m_tune): Likewise.
(arm_fa726te_tune): Likewise.
(arm_mem_costs): Use table lookup to calculate cost of addressing
mode.

From-SVN: r255112

[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r11-3363-gf74c87f85f510248874cb90ad0b0527b015034b9
Author: Tobias Burnus 
Date:   Tue Sep 22 19:15:44 2020 +0200

libgomp.fortran/pr66199-5.f90: Make stop codes unique

libgomp/ChangeLog:

PR fortran/95654
* testsuite/libgomp.fortran/pr66199-5.f90: Make stop codes unique.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Well, libcpp isn't using the standard Altivec intrinsics, but their gcc
underlying implementation.  Looking at clang altivec.h, I see they use vector
keyword everywhere and not sure what exactly they map it to under the hood, but
clearly not to altivec attribute, and they have different __builtin_* calls to
implement e.g. vsx_ld and the like.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #2)
> Guess we need something like:
> -#elif defined(_ARCH_PWR8) && defined(__ALTIVEC__)
> +#elif (GCC_VERSION >= 4005) && defined(_ARCH_PWR8) && defined(__ALTIVEC__)
> in libcpp/lex.c if clang doesn't support the altivec attribute and the
> builtins.

But it should!  What is actually going wrong here?  The compiler should
not declare it supports what is tested for by __ALTIVEC__ if it doesn't.

[Bug c++/94695] Implement -Wrange-loop-analysis

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-09-22
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug c++/97165] [9/10/11 Regression] Infinite error stream on invalid code

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Similar case:

template
class p

[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Indeed, if in the above testcase one uses b[40] instead of b[64], then it is
rejected with that error message.
Note, this isn't a FE diagnostics, but stor-layout.c one.
We won't be able to diagnose this if the element is variable length, but at
least diagnosing it for for the constant sizes might be sufficient, variable
length structures are except for maybe Ada very rarely used.

[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Keywords||accepts-invalid
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

--- Comment #4 from Richard Biener  ---
So the issue is we do

/* But record element size in units of the type alignment.  */
temp.op2 = TREE_OPERAND (ref, 3);
temp.align = eltype->type_common.align;
if (! temp.op2)
  temp.op2 = size_binop (EXACT_DIV_EXPR, TYPE_SIZE_UNIT (eltype),
 size_int (TYPE_ALIGN_UNIT (eltype)));

and compute EXACT_DIV of 72 (unit size) by 64 (alignment).  That computes
without ICEing but it will result in a badly reconstructed element size, 64,
and thus a badly reconstructed effective offset.  We do this "dance" because
op2 is measured in alignment units of the element type and to reconstruct
the offset we do

tree
array_ref_element_size (tree exp)
{
  tree aligned_size = TREE_OPERAND (exp, 3);
  tree elmt_type = TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 0)));
  location_t loc = EXPR_LOCATION (exp);

  /* If a size was specified in the ARRAY_REF, it's the size measured
 in alignment units of the element type.  So multiply by that value.  */
  if (aligned_size)
{
  /* ??? tree_ssa_useless_type_conversion will eliminate casts to
 sizetype from another type of the same width and signedness.  */
  if (TREE_TYPE (aligned_size) != sizetype)
aligned_size = fold_convert_loc (loc, sizetype, aligned_size);
  return size_binop_loc (loc, MULT_EXPR, aligned_size,
 size_int (TYPE_ALIGN_UNIT (elmt_type)));

so there's no TREE_OPERAND (array-ref, 2) that "correctly" represents the
ARRAY_REF and IMHO the fact that we expand it "correctly" is pure luck.

For C arrays the element type has to be aligned so its size is a multiple
of it (thus all elements can be correctly aligned).  And C arrays have no
"padding".

Not sure what to do here, the FE could reject this or the layout would need
to insert padding, but IIRC we reject arrays of overaligned types:

typedef int aligned_int __attribute__((aligned(8)));
aligned_int x[4];
> ./cc1 -quiet t5.c
t5.c:15:1: error: alignment of array elements is greater than element size
   15 | aligned_int x[4];
  | ^~~

IMHO this should be expanded to "size of array element is not a multiple
of its alignment"?

[Bug c++/97165] [9/10/11 Regression] Infinite error stream on invalid code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-22
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r265734:

commit 5d9a0e3b99e31a2167f6b6ab2473feb58f7c77e8
Author: Marek Polacek 
Date:   Thu Nov 1 22:10:31 2018 +

Implement P0846R0, ADL and function templates.

[Bug c++/97165] [9/10/11 Regression] Infinite error stream on invalid code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |9.4
Summary|Infinite error stream on|[9/10/11 Regression]
   |invalid code|Infinite error stream on
   ||invalid code
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Keywords||compile-time-hog

[Bug c++/97165] New: Infinite error stream on invalid code

[mpolacek at gcc dot gnu.org]

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

Bug ID: 97165
   Summary: Infinite error stream on invalid code
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

a

[Bug fortran/97162] [11 Regression] ICE when building SPECCPU 2006 Gamess benchmark

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Richard Biener from comment #5)
> So just in case the following fixes it we've nailed it (somewhere I have a
> verifier written...)
> 
> diff --git a/gcc/tree-predcom.c b/gcc/tree-predcom.c
> index b1d6e63559c..2f41ad222a0 100644
> --- a/gcc/tree-predcom.c
> +++ b/gcc/tree-predcom.c
> @@ -3326,6 +3326,7 @@ tree_predictive_commoning (void)
>class loop *loop;
>unsigned ret = 0, changed = 0;
>  
> +  scev_reset ();
>initialize_original_copy_tables ();
>FOR_EACH_LOOP (loop, LI_ONLY_INNERMOST)
>  if (optimize_loop_for_speed_p (loop))

Unfortunately, it doesn't help.

[Bug fortran/97162] [11 Regression] ICE when building SPECCPU 2006 Gamess benchmark

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So just in case the following fixes it we've nailed it (somewhere I have a
verifier written...)

diff --git a/gcc/tree-predcom.c b/gcc/tree-predcom.c
index b1d6e63559c..2f41ad222a0 100644
--- a/gcc/tree-predcom.c
+++ b/gcc/tree-predcom.c
@@ -3326,6 +3326,7 @@ tree_predictive_commoning (void)
   class loop *loop;
   unsigned ret = 0, changed = 0;

+  scev_reset ();
   initialize_original_copy_tables ();
   FOR_EACH_LOOP (loop, LI_ONLY_INNERMOST)
 if (optimize_loop_for_speed_p (loop))

[Bug fortran/97162] [11 Regression] ICE when building SPECCPU 2006 Gamess benchmark

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |11.0

--- Comment #4 from Richard Biener  ---
So what are base1/base2 when the assert triggers?  Also try a checking build
which should ICE a bit earlier in the assert:

   gcc_checking_assert (DECL_P (base1) && DECL_P (base2));

but the call chain looks sufficiently protected - so maybe it's a GC issue
of SCEV data...

[Bug testsuite/97146] [11 regression] ipa/ipa-sra-*.c fail since r11-3303 (g:6450f07388f9fe575a489c9309c36012b17b88b0)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Component|tree-optimization   |testsuite

--- Comment #2 from Martin Sebor  ---
Fixed in r11-.

[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|incorrect offset on |[8/9/10/11 Regression]
   |structure member where type |incorrect offset on
   |of that member has aligned  |structure member where type
   |attribute   |of that member has aligned
   ||attribute
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
  Known to work||6.5.0
  Known to fail||7.5.0
   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |8.5
   Last reconfirmed||2020-09-22

--- Comment #3 from Richard Biener  ---
I will have a look.

[Bug sanitizer/90337] sanitizer_linux.cc Fails to compile on Illumos-derived Solaris

[msl0000023508 at gmail dot com]

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

--- Comment #11 from WHR  ---
Created attachment 49259
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49259=edit
gcc-10.2.0-sanitizer-madvise-fix.diff

Replace non-standard madvise(2) with posix_madvise(3).

[Bug sanitizer/90337] sanitizer_linux.cc Fails to compile on Illumos-derived Solaris

[msl0000023508 at gmail dot com]

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

--- Comment #10 from WHR  ---
Created attachment 49258
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49258=edit
gcc-10.2.0-sanitizer-solaris-libelf-h-without-file-offset-bits-64.diff

Solaris libelf.h doesn't work with _FILE_OFFSET_BITS=64 for i386 target.

[Bug sanitizer/90337] sanitizer_linux.cc Fails to compile on Illumos-derived Solaris

[msl0000023508 at gmail dot com]

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

--- Comment #9 from WHR  ---
Created attachment 49257
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49257=edit
gcc-10.2.0-sanitizer-linux-procfs-fix.diff

Limit this Linux procfs code to Linux only.

[Bug sanitizer/90337] sanitizer_linux.cc Fails to compile on Illumos-derived Solaris

[msl0000023508 at gmail dot com]

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

WHR  changed:

   What|Removed |Added

 CC||msl023508 at gmail dot com

--- Comment #8 from WHR  ---
I found this sanitizer-related issue when building GCC 10.2 for Solaris; and
after manual source browseing I believe this bug still existing in the master
branch.

To fix the O_DIRECTORY issue, my opinion is to remove its use by using '#if
SANITIZER_LINUX', because the only place it gets used is some Linux-specific
code, that uses Linux procfs path '/proc/%d/task/'.

I also found some other issues.

Solaris libelf.h doesn't work with _FILE_OFFSET_BITS=64 for i386 target, 
/usr/include/libelf.h:42:2: error: #error "large files are not supported by
libelf"

Last issue is the code uses madvise(2), which is non-standard, and therefore
didn't get declared by Solaris system headers without some addition macros; the
standard interface posix_madvise(3) should be used instead.

I will upload my patches shortly.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Guess we need something like:
-#elif defined(_ARCH_PWR8) && defined(__ALTIVEC__)
+#elif (GCC_VERSION >= 4005) && defined(_ARCH_PWR8) && defined(__ALTIVEC__)
in libcpp/lex.c if clang doesn't support the altivec attribute and the
builtins.

[Bug fortran/97162] [11 Regression] ICE when building SPECCPU 2006 Gamess benchmark

[tnfchris at gcc dot gnu.org]

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

--- Comment #3 from Tamar Christina  ---
Hmm it compiles for me with GCC 10.2 built from
e939674db6fda62a98675d20b95175ec4ba81140

[Bug tree-optimization/97164] incorrect offset on structure member where type of that member has aligned attribute

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase for -O2:
typedef struct { int *a; char b[64]; } A __attribute__((aligned (64)));
struct B { A d[4]; } b;
void foo (void);

int *
bar (void)
{
  struct B *h = 
  if (h->d[1].a)
foo ();
  return h->d[1].a;
}
Not really sure about the validity of the testcase (both original and reduced),
it works fine if one uses
typedef struct __attribute__((aligned (64))) A { int *a; char b[64]; } A;
instead.  The problem is that above, the (anonymous) struct has different
alignment from the typedef and we end up using the type without the increased
alignment for one of those accesses.

[Bug tree-optimization/97146] [11 regression] ipa/ipa-sra-*.c fail since r11-3303 (g:6450f07388f9fe575a489c9309c36012b17b88b0)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-09-22

[Bug tree-optimization/96979] [9/10/11 Regression] Switch with case values derived from constexpr function takes unreasonable time to compile

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[9/10/11 Regression] Switch
   |Switch with case values |with case values derived
   |derived from constexpr  |from constexpr function
   |function takes unreasonable |takes unreasonable time to
   |time to compile |compile
  Known to work||11.0

--- Comment #5 from Martin Liška  ---
GCC 8.x should be fine, compilation finished in 2 seconds.

[Bug tree-optimization/96979] [8/9/10/11 Regression] Switch with case values derived from constexpr function takes unreasonable time to compile

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-3357-gc6df6039e9180c580945266302ec14047d358364
Author: Martin Liska 
Date:   Tue Sep 22 12:23:35 2020 +0200

switch lowering: limit number of cluster attemps

gcc/ChangeLog:

PR tree-optimization/96979
* doc/invoke.texi: Document new param
max-switch-clustering-attempts.
* params.opt: Add new parameter.
* tree-switch-conversion.c (jump_table_cluster::find_jump_tables):
Limit number of attempts.
(bit_test_cluster::find_bit_tests): Likewise.

gcc/testsuite/ChangeLog:

PR tree-optimization/96979
* g++.dg/tree-ssa/pr96979.C: New test.

[Bug c/95777] Allow specifying more than one target options at the same time in target and target_clones attribute

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
I don't see it as a high priority, thus leaving for now.

[Bug tree-optimization/97164] incorrect offset on structure member where type of that member has aligned attribute

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Bisection points to r238468 aka PR71901 fix.

[Bug tree-optimization/96245] Failure to optimize arithmetic pattern in switch

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Leaving for now as it's probably not material for switch-coversion (I mean the
putchar test-case).

[Bug tree-optimization/97164] New: incorrect offset on structure member where type of that member has aligned attribute

[jan.smets at nokia dot com]

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

Bug ID: 97164
   Summary: incorrect offset on structure member where type of
that member has aligned attribute
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

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

Following testcase produces invalid code with GCC 10.2, 9.3, 8.4, 7.5
Works with GCC 6.5

GCC 6:
movqFPAPools+143752(%rdi), %rax

GCC 10 : 
movqFPAPools+143744(%rbx), %rax


Testcase compiled with : -fno-builtin -nostdinc -march=core2 -m64 -O2 
-mno-red-zone -fno-omit-frame-pointer -Wall -Wextra

Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go
gcc version 10.2.0 (GCC)

[Bug fortran/97162] [11 Regression] ICE when building SPECCPU 2006 Gamess benchmark

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Hm, is it really a GCC 11 regression? I see another ICE with the oldest
revision I have:
9d55066c88b4c276(09 Oct 2014 07:40)(fxcoud...@gcc.gnu.org)


scflib.fppized.f: In function 'symh.constprop':
scflib.fppized.f:3780:0: internal compiler error: in expand_assignment, at
expr.c:4857
   460 H(KL) = T(K,L)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [/tmp/cceDDRMT.mk:8: /tmp/ccGK5ftT.ltrans2.ltrans.o] Error 1

[Bug fortran/97162] [11 Regression] ICE when building SPECCPU 2006 Gamess benchmark

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-09-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
I can reproduce that and I'm working on a reduction of the issue..

[Bug target/96814] [11 Regression] wrong code with -march=cascadelake since r11-1445-g502d63b6d6141597

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
> 
> diff --git a/gcc/fold-const.c b/gcc/fold-const.c
> index 1f861630225..0cc80adf632 100644
> --- a/gcc/fold-const.c
> +++ b/gcc/fold-const.c
> @@ -12581,7 +12581,9 @@ fold_ternary_loc (location_t loc, enum tree_code
> code, t
> ree type,
>   && tree_fits_uhwi_p (op2))
> {
>   tree eltype = TREE_TYPE (TREE_TYPE (arg0));
> - unsigned HOST_WIDE_INT width = tree_to_uhwi (TYPE_SIZE (eltype));
> + unsigned HOST_WIDE_INT width
> +   = (TREE_CODE (eltype) == BOOLEAN_TYPE
> +  ? TYPE_PRECISION (eltype) : tree_to_uhwi (TYPE_SIZE
> (eltype)));
>   unsigned HOST_WIDE_INT n = tree_to_uhwi (arg1);
>   unsigned HOST_WIDE_INT idx = tree_to_uhwi (op2);
>  
> diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
> index 6d5d65195ae..e9dbe07dccc 100644
> --- a/gcc/tree-vect-generic.c
> +++ b/gcc/tree-vect-generic.c
> @@ -137,7 +137,7 @@ tree_vec_extract (gimple_stmt_iterator *gsi, tree type,
>  }
>if (bitpos)
>  {
> -  if (TREE_CODE (type) == BOOLEAN_TYPE)
> +  if (0 && TREE_CODE (type) == BOOLEAN_TYPE)
> {
>   tree itype
> = build_nonstandard_integer_type (tree_to_uhwi (bitsize), 0);
> 
> 
> makes the generated code a bit easier to follow but I guess still ends up
> miscompiling things?

Ok, so apparently you installed already the patch. And yes, we still miscompile
it :(

> 
> Note if I add -fdisable-tree-veclower ISEL ICEs.
> 
> So I'd see where this VEC_COND_EXPR comes from.

The vector is already build in C FE:

#0  build_opaque_vector_type (innertype=, nunits=...) at /home/marxin/Programming/gcc/gcc/tree.c:10964
#1  0x0082368e in build_binary_op (location=271264, code=GT_EXPR,
orig_op0=, orig_op1=, convert_p=true) at
/home/marxin/Programming/gcc/gcc/c/c-typeck.c:12164
#2  0x008028e3 in parser_build_binary_op (location=271264,
code=GT_EXPR, arg1=..., arg2=...) at
/home/marxin/Programming/gcc/gcc/c/c-typeck.c:3755
#3  0x0084dcfd in c_parser_binary_expression (parser=0x77fc4ab0,
after=, omp_atomic_lhs=) at
/home/marxin/Programming/gcc/gcc/c/c-parser.c:8087
#4  0x0084e9b6 in c_parser_conditional_expression
(parser=0x77fc4ab0, after=, omp_atomic_lhs=)
at /home/marxin/Programming/gcc/gcc/c/c-parser.c:7691
#5  0x0084efe1 in c_parser_expr_no_commas (parser=0x77fc4ab0,
after=, omp_atomic_lhs=) at
/home/marxin/Programming/gcc/gcc/c/c-parser.c:7606

for 

(gdb) p debug_tree(orig_op0)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x775ec348 precision:8 min  max >
unsigned V16QI
size 
unit-size 
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7740ec78 nunits:16>
side-effects
arg:0 >
side-effects
arg:0 
used unsigned ignored read decl_5 V16QI
/home/marxin/Programming/testcases/pr96814.c:8:12 size  unit-size 
align:128 warn_if_not_align:0 context  initial >
/home/marxin/Programming/testcases/pr96814.c:8:12 start:
/home/marxin/Programming/testcases/pr96814.c:8:12 finish:
/home/marxin/Programming/testcases/pr96814.c:8:12>>
$10 = void
(gdb) p debug_tree(orig_op1)
  constant 0>

So the '(V){8} > 0' if I see correctly. I tried to manually change 'intt' in
parser_build_binary_op to boolean_type_node, but
it leads to:

/home/marxin/Programming/testcases/pr96814.c:8:21: error: invalid operands to
binary == (have ‘__vector(16) _Bool’ and ‘int’)
8 |x = ((V){8} > 0) == 0;
  | ^~
  ||
  |__vector(16) _Bool

:/
Any hint how to resolve it?

[Bug libstdc++/97163] Build error with -mcpu=power9 on ppc64

[pkubaj at anongoth dot pl]

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

--- Comment #1 from Piotr Kubaj  ---
This is on FreeBSD head, which uses ELFv2.

[Bug libstdc++/97163] New: Build error with -mcpu=power9 on ppc64

[pkubaj at anongoth dot pl]

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

Bug ID: 97163
   Summary: Build error with -mcpu=power9 on ppc64
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkubaj at anongoth dot pl
  Target Milestone: ---

The same error happens also on GCC 9.3.0.
I'm using Clang 11.0.0 rc2 to build, but it happened before with 10 (I only now
got to report it).

Issue:
gmake[5]: Entering directory
'/tmp/usr/ports/lang/gcc10/work/.build/build-powerpc64-portbld-freebsd13.0/libcpp'
test -f config.h || (rm -f stamp-h1 && gmake stamp-h1)
c++ -std=gnu++98  -I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp -I.
-I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/../include
-I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/include -DLIBICONV_PLUG -O2
-pipe -mcpu=power9   -DLIBICONV_PLUG  -W -Wall -Wno-narrowing -Wwrite-strings
-Wmissing-format-attribute -pedantic -Wno-long-long  -fno-exceptions -fno-rtti
-I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp -I.
-I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/../include
-I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/include -DLIBICONV_PLUG  -c
-o lex.o -MT lex.o -MMD -MP -MF .deps/lex.Tpo
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c
c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated [-Wdeprecated]
In file included from
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:23:
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/system.h:439:9: warning:
keyword is hidden by macro definition [-Wkeyword-macro]
#define true 1
^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/system.h:440:9: warning:
keyword is hidden by macro definition [-Wkeyword-macro]
#define false 0
^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:544:26: warning: unknown
attribute 'altivec' ignored [-Wunknown-attributes]
  typedef __attribute__((altivec(vector))) unsigned char vc;
 ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:546:12: error: excess
elements in scalar initializer
  const vc repl_nl = {
   ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:550:12: error: excess
elements in scalar initializer
  const vc repl_cr = {
   ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:554:12: error: excess
elements in scalar initializer
  const vc repl_bs = {
   ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:558:12: error: excess
elements in scalar initializer
  const vc repl_qm = {
   ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:571:14: error: use of
undeclared identifier '__builtin_vec_vsx_ld'
  data = __builtin_vec_vsx_ld (0, s);
 ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:574:19: error: use of
undeclared identifier '__builtin_vec_cmpeq'
  m_nl = (vc) __builtin_vec_cmpeq(data, repl_nl);
  ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:575:19: error: use of
undeclared identifier '__builtin_vec_cmpeq'
  m_cr = (vc) __builtin_vec_cmpeq(data, repl_cr);
  ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:576:19: error: use of
undeclared identifier '__builtin_vec_cmpeq'
  m_bs = (vc) __builtin_vec_cmpeq(data, repl_bs);
  ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:577:19: error: use of
undeclared identifier '__builtin_vec_cmpeq'
  m_qm = (vc) __builtin_vec_cmpeq(data, repl_qm);
  ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:584:11: error: use of
undeclared identifier '__builtin_vec_vcmpeq_p'
  while (!__builtin_vec_vcmpeq_p(/*__CR6_LT_REV*/3, t, zero));
  ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:595:23: error: array is
too large (18446744073709551615 elements)
  unsigned long l[(N == 2 || N == 4) ? N : -1];
  ^~~
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:602:13: warning: no case
matching constant switch condition '0'
switch (N)
^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:590:12: note: expanded
from macro 'N'
#define N  (sizeof(vc) / sizeof(long))
   ^~~
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1729:8: warning: result
of comparison against a string literal is unspecified (use an explicit string
comparison function instead) [-Wstring-compare]
  BUF_APPEND ("\\", 1);
  ^~~~
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1699:30: note: expanded
from macro 'BUF_APPEND'
&& (const uchar *)(STR) != base \
    ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1738:5: warning: result
of comparison against a string literal is 

[Bug fortran/97162] New: [11 Regression] ICE when building SPECCPU 2006 Gamess benchmark

[tnfchris at gcc dot gnu.org]

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

Bug ID: 97162
   Summary: [11 Regression] ICE when building SPECCPU 2006 Gamess
benchmark
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---

Unforunately I don't have data going back to the start of GCC 11 and I also
don't know any fortran so no idea how to go about minimizing this..

But Gamess in SPECCPU 2006 fails with an ICE:

  0x6ca753 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../.././gcc/tree.c:9905
  0x753033 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../.././gcc/tree.h:3413
  0x753033 compare_base_decls(tree_node*, tree_node*)
../.././gcc/alias.c:2145
  0xdaa9c3 ptr_deref_may_alias_decl_p
../.././gcc/tree-ssa-alias.c:227
  0x17f67bb dr_may_alias_p(data_reference const*, data_reference const*, loop*)
../.././gcc/tree-data-ref.c:2769
  0x17f693f initialize_data_dependence_relation(data_reference*,
data_reference*, vec)
../.././gcc/tree-data-ref.c:2843
  0x17fb13b compute_all_dependences(vec,
vec*, vec,
bool)
../.././gcc/tree-data-ref.c:5391
  0x1800807 compute_data_dependences_for_loop(loop*, bool, vec*, vec*,
vec*)
../.././gcc/tree-data-ref.c:5868
  0xd6b307 tree_predictive_commoning_loop
../.././gcc/tree-predcom.c:3211
  0xd6b307 tree_predictive_commoning()
../.././gcc/tree-predcom.c:

when built with

-Ofast -fomit-frame-pointer -flto --param ipa-cp-eval-threshold=1 --param
ipa-cp-unit-growth=80 -fno-inline-functions-called-once

Removing any of these options seems to make it go away.

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[kangshan0910 at hotmail dot com]

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

--- Comment #25 from 康 珊  ---
(In reply to rguent...@suse.de from comment #24)
> On September 22, 2020 1:14:48 PM GMT+02:00, kangshan0910 at hotmail dot com
>  wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770
> >
> >--- Comment #23 from 康 珊  ---
> >It seems that gcc will use "_ZGVeN8vl8l8_sincos" which doesn't exit in
> >libmvec.
> >/usr/bin/ld: /tmp/ccTYyEZM.o: in function `main':
> >/home/pnp/ks/test_sincos.c:38: undefined reference to
> >`_ZGVeN8vl8l8_sincos'
> >/usr/bin/ld: /home/pnp/ks/test_sincos.c:38: undefined reference to
> >`_ZGVeN8vl8l8_sincos'
> >collect2: error: ld returned 1 exit status
> 
> That's expected and the thing that needs to be fixed. 
> 
> >I'm using clear linux the glibc of which is 2.31 and I also tried
> >Ubuntu 19.10
> >the glibc of which is 2.30.

But it has _ZGVeN8vvv_sincos(__m512d, __m512i, __m512i), why gcc not use this
call?

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[cvs-commit at gcc dot gnu.org]

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

--- Comment #32 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Kyrylo Tkachov
:

https://gcc.gnu.org/g:874bdcd54b53283a82418649ea7457c1d6804562

commit r8-10526-g874bdcd54b53283a82418649ea7457c1d6804562
Author: Vlad Lazar 
Date:   Fri Aug 31 15:00:54 2018 +

[AArch64] Implement new intrinsics vabsd_s64 and vnegd_s64.

gcc/
2018-08-31  Vlad Lazar  

PR target/71233
* config/aarch64/arm_neon.h (vabsd_s64): New.
(vnegd_s64): Likewise.

gcc/testsuite/
2018-08-31  Vlad Lazar  

PR target/71233
* gcc.target/aarch64/scalar_intrinsics.c (test_vnegd_s64): New.
* gcc.target/aarch64/vneg_s.c (RUN_TEST_SCALAR): New.
(test_vnegd_s64): Likewise.
* gcc.target/aarch64/vnegd_s64.c: New.
* gcc.target/aarch64/vabsd_s64.c: New.

(cherry picked from commit 66da5b53107962a1c115a9686f2220de27f276f7)

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[rguenther at suse dot de]

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

--- Comment #24 from rguenther at suse dot de  ---
On September 22, 2020 1:14:48 PM GMT+02:00, kangshan0910 at hotmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770
>
>--- Comment #23 from 康 珊  ---
>It seems that gcc will use "_ZGVeN8vl8l8_sincos" which doesn't exit in
>libmvec.
>/usr/bin/ld: /tmp/ccTYyEZM.o: in function `main':
>/home/pnp/ks/test_sincos.c:38: undefined reference to
>`_ZGVeN8vl8l8_sincos'
>/usr/bin/ld: /home/pnp/ks/test_sincos.c:38: undefined reference to
>`_ZGVeN8vl8l8_sincos'
>collect2: error: ld returned 1 exit status

That's expected and the thing that needs to be fixed. 

>I'm using clear linux the glibc of which is 2.31 and I also tried
>Ubuntu 19.10
>the glibc of which is 2.30.

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[kangshan0910 at hotmail dot com]

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

--- Comment #23 from 康 珊  ---
It seems that gcc will use "_ZGVeN8vl8l8_sincos" which doesn't exit in libmvec.
/usr/bin/ld: /tmp/ccTYyEZM.o: in function `main':
/home/pnp/ks/test_sincos.c:38: undefined reference to `_ZGVeN8vl8l8_sincos'
/usr/bin/ld: /home/pnp/ks/test_sincos.c:38: undefined reference to
`_ZGVeN8vl8l8_sincos'
collect2: error: ld returned 1 exit status

I'm using clear linux the glibc of which is 2.31 and I also tried Ubuntu 19.10
the glibc of which is 2.30.

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[cvs-commit at gcc dot gnu.org]

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

--- Comment #30 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

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

commit r11-3353-gd4703be185b422f637deebd3bb9222a41c8023d6
Author: Kyrylo Tkachov 
Date:   Tue Sep 22 12:00:38 2020 +0100

AArch64: Implement missing vceq*_p* intrinsics

This patch implements some missing vceq* intrinsics on poly types.
The behaviour is to produce the appropriate CMEQ instruction as for the
unsigned types.

Bootstrapped and tested on aarch64-none-linux-gnu.

gcc/
PR target/71233
* config/aarch64/arm_neon.h (vceqq_p64, vceqz_p64, vceqzq_p64):
Define.

gcc/testsuite/

PR target/71233
* gcc.target/aarch64/simd/vceq_poly_1.c: New test.

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[cvs-commit at gcc dot gnu.org]

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

--- Comment #29 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

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

commit r11-3352-gfa9ad35dae03dcb20c4ccb50ba1b351a8ab77970
Author: Kyrylo Tkachov 
Date:   Tue Sep 22 11:58:36 2020 +0100

AArch64: Implement poly-type vadd intrinsics

This implements the vadd[p]_p* intrinsics.
In terms of functionality they are aliases of veor operations on the
relevant unsigned types.

Bootstrapped and tested on aarch64-none-linux-gnu.

gcc/
PR target/71233
* config/aarch64/arm_neon.h (vadd_p8, vadd_p16, vadd_p64, vaddq_p8,
vaddq_p16, vaddq_p64, vaddq_p128): Define.

gcc/testsuite/
PR target/71233
* gcc.target/aarch64/simd/vadd_poly_1.c: New test.

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[cvs-commit at gcc dot gnu.org]

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

--- Comment #31 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

https://gcc.gnu.org/g:30957092db46d8798e632feefb5df634488dbb33

commit r11-3354-g30957092db46d8798e632feefb5df634488dbb33
Author: Kyrylo Tkachov 
Date:   Tue Sep 22 12:03:49 2020 +0100

AArch64: Implement missing vcls intrinsics on unsigned types

This patch implements some missing intrinsics that perform a CLS on
unsigned SIMD types.

Bootstrapped and tested on aarch64-none-linux-gnu.

gcc/
PR target/71233
* config/aarch64/arm_neon.h (vcls_u8, vcls_u16, vcls_u32,
vclsq_u8, vclsq_u16, vclsq_u32): Define.

gcc/testsuite/
PR target/71233
* gcc.target/aarch64/simd/vcls_unsigned_1.c: New test.

[Bug target/97161] [8/9/10/11 Regression] aarch64: Wrong code at -O2/-O3 since r8-4308-g13494fcb3

[acoplan at gcc dot gnu.org]

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

--- Comment #2 from Alex Coplan  ---
Ah, apologies for the noise - thanks for clarifying.

[Bug tree-optimization/97159] [11 Regression] segfault in modref_may_conflict

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Priority|P3  |P1
   Keywords||ice-on-valid-code
Summary|segfault in |[11 Regression] segfault in
   |modref_may_conflict |modref_may_conflict

[Bug target/97160] Regression from GCC 8 optimizing to sincos on ppc64le

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
gcc/fortran/f95-lang.c:  if (targetm.libc_has_function (function_sincos))

not sure how you configure your compiler?  What OS are you on?

[Bug target/97161] [8/9/10/11 Regression] aarch64: Wrong code at -O2/-O3 since r8-4308-g13494fcb3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener  ---
Note type punning through a union only works when the union type is visible but
you are using int * and short * for accesses.  So you indeed do GCCs view on C
strict aliasing rules.

[Bug target/97161] [8/9/10/11 Regression] aarch64: Wrong code at -O2/-O3 since r8-4308-g13494fcb3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||aarch64
   Target Milestone|--- |8.5
   Keywords||wrong-code

[Bug gcov-profile/96913] [10 regression] gcov TOPN streaming is incorrect for shared libraries

[slyfox at gcc dot gnu.org]

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

Sergei Trofimovich  changed:

   What|Removed |Added

Summary|[10/11 regression] gcov |[10 regression] gcov TOPN
   |TOPN streaming is incorrect |streaming is incorrect for
   |for shared libraries|shared libraries

--- Comment #8 from Sergei Trofimovich  ---
Should be fixed for gcc-11. Will send a backport to gcc-10 this evening (the
code changed slightly since gcc-10).

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
(In reply to 康 珊 from comment #21)
> $ gcc -m64 -g -O2 -fopenmp-simd -fPIC -Wall test_sincos.c -o test_sincos -lm
> -march=skylake-avx512 -ffast-math -ftree-loop-vectorize

Try adding -fno-builtin-sincos here

> $ ldd test_sincos
> linux-vdso.so.1 (0x7ffd2393f000)
> libm.so.6 => /lib64/libm.so.6 (0x7f574f49d000)
> libc.so.6 => /lib64/libc.so.6 (0x7f574f2a2000)
> /lib64/ld-linux-x86-64.so.2 (0x7f574f601000)
> My gcc version is "10.1.1 20200507".
> And I have uploaded my test source file.

[Bug gcov-profile/96913] [10/11 regression] gcov TOPN streaming is incorrect for shared libraries

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Sergei Trofimovich :

https://gcc.gnu.org/g:4ecf368f4b4223fb2df4f3887429dfbb48852e38

commit r11-3351-g4ecf368f4b4223fb2df4f3887429dfbb48852e38
Author: Sergei Trofimovich 
Date:   Sun Sep 6 12:13:54 2020 +0100

gcov: fix TOPN streaming from shared libraries

Before the change gcc did not stream correctly TOPN counters
if counters belonged to a non-local shared object.

As a result zero-section optimization generated TOPN sections
in a form not recognizable by '__gcov_merge_topn'.

The problem happens because in a case of multiple shared objects
'__gcov_merge_topn' function is present in address space multiple
times (once per each object).

The fix is to never rely on function address and predicate on TOPN
counter types.

libgcc/ChangeLog:

PR gcov-profile/96913
* libgcov-driver.c (write_one_data): Avoid function pointer
comparison in TOP streaming decision.

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[kangshan0910 at hotmail dot com]

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

--- Comment #21 from 康 珊  ---
(In reply to Jakub Jelinek from comment #15)
> OpenMP has a way to express this,
> #pragma omp declare simd notinbranch linear(y,z)
> double sincos (double x, double *y, double *z);
> As can be seen on -O2 -fopenmp-simd:
> #pragma omp declare simd notinbranch linear(y, z)
> double foo (double x, double *y, double *z);
> 
> double a[1024], b[1024], c[1024];
> 
> void
> bar (void)
> {
>   #pragma omp simd
>   for (int i = 0; i < 1024; i++)
> foo (a[i], [i], [i]);
> }
> it works fine with that.  But if #pragma omp simd is commented out, it is
> not, because the compiler has no assurance on what the function call
> behavior will be e.g. for data reference analysis (it could e.g. modify the
> global vars).
> Now, for sincos proper, the compiler knows what the function does if not
> -fno-builtin-sincos.
> 
> Unfortunately, I think glibc currently defines sincos in math-vector.h the
> unuseful way with just simd ("notinbranch") attribute, which effectively
> means
> that the caller is supposed to pass vectors of pointers (well integers with
> those sizes) and so needs scatter under the hood.
> So the best thing would be to change glibc first.

Thanks for your reply.(In reply to Jakub Jelinek from comment #15)
> OpenMP has a way to express this,
> #pragma omp declare simd notinbranch linear(y,z)
> double sincos (double x, double *y, double *z);
> As can be seen on -O2 -fopenmp-simd:
> #pragma omp declare simd notinbranch linear(y, z)
> double foo (double x, double *y, double *z);
> 
> double a[1024], b[1024], c[1024];
> 
> void
> bar (void)
> {
>   #pragma omp simd
>   for (int i = 0; i < 1024; i++)
> foo (a[i], [i], [i]);
> }
> it works fine with that.  But if #pragma omp simd is commented out, it is
> not, because the compiler has no assurance on what the function call
> behavior will be e.g. for data reference analysis (it could e.g. modify the
> global vars).
> Now, for sincos proper, the compiler knows what the function does if not
> -fno-builtin-sincos.
> 
> Unfortunately, I think glibc currently defines sincos in math-vector.h the
> unuseful way with just simd ("notinbranch") attribute, which effectively
> means
> that the caller is supposed to pass vectors of pointers (well integers with
> those sizes) and so needs scatter under the hood.
> So the best thing would be to change glibc first.

Thanks for your reply. I tried your method. But it still doesn't work for
sincos. 

#pragma omp declare simd notinbranch linear(y, z)
void sincos(double x, double *y, double *z);

for (unsigned int i = 0; i < loopCount; i++)
{
#pragma omp simd
for (unsigned int j = i * dim; j < (i + 1) * dim; j++)
{
sincos(input_array[j], _array[j], _array1[j]);
}
}

$ gcc -m64 -g -O2 -fopenmp-simd -fPIC -Wall test_sincos.c -o test_sincos -lm
-march=skylake-avx512 -ffast-math -ftree-loop-vectorize
$ ldd test_sincos
linux-vdso.so.1 (0x7ffd2393f000)
libm.so.6 => /lib64/libm.so.6 (0x7f574f49d000)
libc.so.6 => /lib64/libc.so.6 (0x7f574f2a2000)
/lib64/ld-linux-x86-64.so.2 (0x7f574f601000)
My gcc version is "10.1.1 20200507".
And I have uploaded my test source file.

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[kangshan0910 at hotmail dot com]

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

--- Comment #20 from 康 珊  ---
Created attachment 49255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49255=edit
test source file

[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake

[already5chosen at yahoo dot com]

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

--- Comment #6 from Michael_S  ---
Why do you see it as addition of peephole pattern?
I see it as removal. Like, "do what's written in the source and don't try to be
tricky".
Probably, I am too removed from how compilers work :(

Or, may be, handle it at the level of cost of instructions?
I don't know how gcc works internally, but it seems that currently the cost of
register move [on Haswell and Skylake] is underestimated.
Although it is true that register move has no cost in terms of execution ports
and latency, it still has the same cost as, say, integer ALU instructions, in
terms of the front end and renamer.

Also, as pointed out above by Alexander, the cost of FMA3 with (base+index) or
(index*scale) memory operands could also be underestimated.

Unlike Alexander, I am not sure that the difference between (base+index) and
(base) is really what matters. IMO, the cost of FMA3 with *any* memory operands
is underestimated, but I am not going to insist on that.


In the ideal world compiler should reason as I do it myself when coding in asm:
estimate which resource is critical in the given loop and then try to reduce
pressure on this particular resource. In this particular loop a critical
resource appears to be renamer, so the cost of instructions should be seen as
cost at renamer. In other situations critical resource could be throughput of
particular issue port. In yet another situation it could be latency of
instructions that form dependency chain across multiple iterations of the loop.
The later is especially common in "reduction" algorithms of which dot product
is the most common example.
A single value of instruction cost simply can't cover all these different cases
in satisfactory manner.
May be, gcc it's already here, I don't know.

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #17)
> Can one actually define multiple OMP SIMD variants for a single function?

Yes.

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
(In reply to Florian Weimer from comment #16)
> (In reply to Jakub Jelinek from comment #15)
> > Unfortunately, I think glibc currently defines sincos in math-vector.h the
> > unuseful way with just simd ("notinbranch") attribute, which effectively
> > means
> > that the caller is supposed to pass vectors of pointers (well integers with
> > those sizes) and so needs scatter under the hood.
> > So the best thing would be to change glibc first.
> 
> What exactly do we need to change? Factor out the declaration of sincos, so
> that we can apply “linear(__p1, __p2)” to it?

It could provide
#pragma omp declare simd linear(__p1, __p2)
double sincos (double __p0, double *__p1, double *__p2);
prototypes and assembly definition for that function.
Note, right now the simd attribute syntax doesn't allow specifying linear
arguments, there have been talks about extending the syntax, but it hasn't been
finished yet.  Looking at sysdeps/x86_64/fpu/*sincos*.S I actually see the
correct symbols there already, just they aren't exported from the library (the
symbols with *l4l4*, *l8l8* etc. in there).
So I guess we first need to extend the simd attribute syntax, then change glibc
to use it and export those, and finally benefit.

> Should glibc provide a cexpi function? The complex result would avoid having
> to go through memory at all.

Not sure if that would help, because vectorization of complex types doesn't
really work well in GCC unless they are lowered to scalar ops before
vectorization.

[Bug c++/97151] GCC fails to optimize away uselessly allocated arrays (C++)

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #7)
> (IIRC there's
> only ever a single argument to operator delete).

That's not always true. See -fsized-deallocation

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
IIRC cepxi has the complication that we have to define the mangling for vector
_Complex double.  But cexpi is what the vectorizer currently sees, of course
(we can of course vectorize it as sincos with arguments in memory again).

So yeah, glibc is lacking here.

Can one actually define multiple OMP SIMD variants for a single function?

[Bug tree-optimization/97159] segfault in modref_may_conflict

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Fib is a recursive function, and the problem occurs while handling a recursion
call.

[Bug target/97161] New: [8/9/10/11 Regression] aarch64: Wrong code at -O2/-O3 since r8-4308-g13494fcb3

[acoplan at gcc dot gnu.org]

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

Bug ID: 97161
   Summary: [8/9/10/11 Regression] aarch64: Wrong code at -O2/-O3
since r8-4308-g13494fcb3
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

For the following C program:

__attribute__ ((noinline))
void f(char *p, char x)
{
  if (x != 1)
__builtin_abort();
}

union {
  char a;
  int b;
  short c;
} d;
short g, *e = 
int i;
int main()
{
  int *h = 
  g = *h = 1;
  *e |= i;
  f(0, d.a);
}

GCC generates wrong code (and abort is called) at -O2 on AArch64 after
r8-4308-g13494fcb363e8a901db7768a851a9eed1dea62e3.

The issue goes away with -fno-strict-aliasing, but I believe this program does
not violate the strict aliasing constraints: we're simply accessing each member
of the union by its given type.

GCC trunk (x86) and clang 10 (x86 and aarch64) at -O{0,1,2,3} all produce a
program that exits cleanly.

To reproduce, on AArch64:

$ gcc test.c
$ ./a.out
$ gcc test.c -O2
$ ./a.out
Aborted (core dumped)

[Bug c++/97151] GCC fails to optimize away uselessly allocated arrays (C++)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #6)
> (In reply to Marat Radchenko from comment #4)
> > (In reply to Martin Liška from comment #3)
> > > It's caused by what was mentioned as 2) which transforms to:
> > > 
> > >   _6 = operator new [] (40);
> > >   __builtin_memset (_6, 0, 40);
> > >   operator delete [] (_6);
> > > 
> > > So there's a use of _6 and we probably can't remove it as memset can
> > > potentially access NULL pointer if operator new [] fails.
> > 
> > 1. If operator new[] fails, there would be an exception instead of NULL, no?
> > 
> > 2. It doesn't matter, you may guard accessing array with NULL check and
> > still observe described behavior.
> > 
> > What puzzles me the most is why removal of delete[] allows it to optimize.
> 
> Very likely delete[] is keeping the memset itself live.  In particular
> early CDDCE can elide the loop without the delete[] but with the delete[]
> we see
> 
> Marking useful stmt: operator delete [] (_7);
> 
> so that's a no-go there.  Using malloc/free we manage to delete the loop
> early
> because its argument is not considered necessary.  It looks like points-to
> analysis fails to fully handle new/delete and causes the allocated storage
> to point to escaped memory:
> 
> _7 = (10)
> 
> new[] handled OK
> 
> ESCAPED = _7
> 
> delete[] not handled.  One "easy" way would be for the C++ FE to annotate
> delete[] with fnspec ".w" to mark the argument as not escaping.  A hackish
> patch in PTA also fixes it:
> 
> diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
> index 44fe52e0f65..f676bf91e95 100644
> --- a/gcc/tree-ssa-structalias.c
> +++ b/gcc/tree-ssa-structalias.c
> @@ -4857,6 +4857,8 @@ find_func_aliases_for_call (struct function *fn, gcall
> *t)
>  point for reachable memory of their arguments.  */
>else if (flags & (ECF_PURE|ECF_LOOPING_CONST_OR_PURE))
> handle_pure_call (t, );
> +  else if (fndecl && DECL_IS_REPLACEABLE_OPERATOR_DELETE_P (fndecl))
> +   ;
>else
> handle_rhs_call (t, );
>if (gimple_call_lhs (t))

passes bootstrap & regtest, also improving g++.dg/cpp1y/new1.C as of

PASS: g++.dg/cpp1y/new1.C  -std=gnu++98 (test for excess errors)
g++.dg/cpp1y/new1.C  -std=gnu++98 : pattern found 6 times
FAIL: g++.dg/cpp1y/new1.C  -std=gnu++98  scan-tree-dump-times cddce1 "Deleting
: operator delete" 5
g++.dg/cpp1y/new1.C  -std=gnu++98 : pattern found 8 times
FAIL: g++.dg/cpp1y/new1.C  -std=gnu++98  scan-tree-dump-times cddce1 "Deleting
: _\\d+ = operator new" 7

note there are 10 functions in new1.C and there's no XFAIL so it's not clear
whether the currently not optimized cases are to be not optimized for
correctness or whether those are just missed optimizations...

The patch might be even OK in case DECL_IS_REPLACEABLE_OPERATOR_DELETE_P
implies that there is no return value and no argument escapes (IIRC there's
only ever a single argument to operator delete).  Note the patch implies
that the storage is not written to, but I suppose its contents become
undefined after 'delete'.

[Bug libstdc++/96803] std::tuple chooses wrong constructor for uses-allocator construction

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |8.5

--- Comment #9 from Jonathan Wakely  ---
Fixed for 8.5, 9.4 and 10.3

[Bug libstdc++/96803] std::tuple chooses wrong constructor for uses-allocator construction

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:132ddcc78c118a6ab52063193462bf2a6dbdae32

commit r9-8931-g132ddcc78c118a6ab52063193462bf2a6dbdae32
Author: Jonathan Wakely 
Date:   Tue Sep 22 08:42:18 2020 +0100

libstdc++: Use correct argument type for __use_alloc, again [PR 96803]

While backporting 5494edae83ad33c769bd1ebc98f0c492453a6417 I noticed
that it's still not correct. I made the allocator-extended constructor
use the right type for the uses-allocator construction detection, but I
used an rvalue when it should be a const lvalue.

This should fix it properly this time.

libstdc++-v3/ChangeLog:

PR libstdc++/96803
* include/std/tuple
(_Tuple_impl(allocator_arg_t, Alloc, const _Tuple_impl&)):
Use correct value category in __use_alloc call.
* testsuite/20_util/tuple/cons/96803.cc: Check with constructors
that require correct value category to be used.

(cherry picked from commit 7825399092d572ce8ea82c4aa8dfeb65076b0e52)

[Bug libstdc++/96803] std::tuple chooses wrong constructor for uses-allocator construction

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:6e86f0926f8de014cb0b0218442812e9f3ea8e95

commit r8-10525-g6e86f0926f8de014cb0b0218442812e9f3ea8e95
Author: Jonathan Wakely 
Date:   Tue Sep 22 09:39:33 2020 +0100

libstdc++: Use correct argument type for __use_alloc [PR 96803]

The _Tuple_impl constructor for allocator-extended construction from a
different tuple type uses the _Tuple_impl's own _Head type in the
__use_alloc test. That is incorrect, because the argument tuple could
have a different type. Using the wrong type might select the
leading-allocator convention when it should use the trailing-allocator
convention, or vice versa.

This backport includes the value category fix from r11-3348.

libstdc++-v3/ChangeLog:

PR libstdc++/96803
* include/std/tuple
(_Tuple_impl(allocator_arg_t, Alloc, const _Tuple_impl&)):
Replace parameter pack with a type parameter and a pack and pass
the first type to __use_alloc.
* testsuite/20_util/tuple/cons/96803.cc: New test.

(cherry picked from commit 5494edae83ad33c769bd1ebc98f0c492453a6417)

[Bug libstdc++/96803] std::tuple chooses wrong constructor for uses-allocator construction

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:5a981195bd80ad64475bbc24b7a4d222a6a6eff5

commit r10-8787-g5a981195bd80ad64475bbc24b7a4d222a6a6eff5
Author: Jonathan Wakely 
Date:   Tue Sep 22 08:42:18 2020 +0100

libstdc++: Use correct argument type for __use_alloc, again [PR 96803]

While backporting 5494edae83ad33c769bd1ebc98f0c492453a6417 I noticed
that it's still not correct. I made the allocator-extended constructor
use the right type for the uses-allocator construction detection, but I
used an rvalue when it should be a const lvalue.

This should fix it properly this time.

libstdc++-v3/ChangeLog:

PR libstdc++/96803
* include/std/tuple
(_Tuple_impl(allocator_arg_t, Alloc, const _Tuple_impl&)):
Use correct value category in __use_alloc call.
* testsuite/20_util/tuple/cons/96803.cc: Check with constructors
that require correct value category to be used.

(cherry picked from commit 7825399092d572ce8ea82c4aa8dfeb65076b0e52)

[Bug target/97160] New: Regression from GCC 8 optimizing to sincos on ppc64le

[fx at gnu dot org]

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

Bug ID: 97160
   Summary: Regression from GCC 8 optimizing to sincos on ppc64le
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fx at gnu dot org
  Target Milestone: ---
Target: ppc64le

Created attachment 49254
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49254=edit
Fortran benchmark

I looked at the other case in a Fortran benchmark set where GCC does badly on
ppc64le with GCC 10.  The problem seems to be in the middle end, though, not
Fortran.

This case is heavy on trig functions, and I found that gfortran 10 and 9 miss
the optimization of converting sin+cos to sincos which is done by 8 on ppc64le
and also by 10 on x86_64.  I tried a simple example rather than the whole
thing, but couldn't quickly reproduce the effect out of context, so it may be
rather specific to this case.  I'll attach the original 1400-line single
routine (!) but I could take quick suggestions to narrow down the issue.

With gfortran 10.2 (and similarly with 9) on RHEL7 POWER9 the top of the perf
profile resulting from "gfortran -Ofast" is

43.60%  mp_prop_design  libm-2.17.so  [.] __cos
28.85%  mp_prop_design  mp_prop_design[.] MAIN__
24.40%  mp_prop_design  libm-2.17.so  [.] __sin
 1.04%  mp_prop_design  libm-2.17.so  [.] __sincos

With gfortran 8 (from "advanced toolkit 12") it's

78.49%  a.outmp_prop_design[.] MAIN__
20.29%  a.outlibm-2.28.so  [.] __sincos
 1.14%  a.outlibm-2.28.so  [.] __tan

(Those look as if they're from different systems because AT 12 picks up its own
glibc when you set up the environment.)

[Bug tree-optimization/97159] segfault in modref_may_conflict

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Segfaults because tt is NULL:
...
Program received signal SIGSEGV, Segmentation fault.
0x012b1a69 in modref_may_conflict (tt=0x0, ref=0x7fffd8d0,
tbaa_p=true)
at /home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-alias.c:2433
2433  if (tt->every_base)
(gdb)
...

tt comes from summary->loads:
...
(gdb) up
#1  0x012b1da1 in ref_maybe_used_by_call_p_1 (call=0x77ff43f0, 
ref=0x7fffd8d0, tbaa_p=true)
at /home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-alias.c:2513
2513  if (!modref_may_conflict (summary->loads, ref, tbaa_p))
...

and summary looks like:
...
(gdb) p *summary
$2 = {loads = 0x0, stores = 0x0, loads_lto = 0x0, stores_lto = 0x0, finished =
true}
...

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #16 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #15)
> Unfortunately, I think glibc currently defines sincos in math-vector.h the
> unuseful way with just simd ("notinbranch") attribute, which effectively
> means
> that the caller is supposed to pass vectors of pointers (well integers with
> those sizes) and so needs scatter under the hood.
> So the best thing would be to change glibc first.

What exactly do we need to change? Factor out the declaration of sincos, so
that we can apply “linear(__p1, __p2)” to it?

Should glibc provide a cexpi function? The complex result would avoid having to
go through memory at all.

[Bug tree-optimization/97159] New: segfault in modref_may_conflict

[vries at gcc dot gnu.org]

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

Bug ID: 97159
   Summary: segfault in modref_may_conflict
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With a build of commit 48b0c1250a5c7d72be6b3fbbb1117d1cce43daee (Date: Mon Sep
21 12:46:00 2020 +0200) for x86_64-linux with nvptx accelerator, we run into:
...
FAIL: libgomp.fortran/examples-4/declare_target-1.f90   -O1  (internal compiler
error)
...

In more detail:
...
during GIMPLE pass: dse^M
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90:
In function 'fib':^M
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90:6:
internal compiler error: Segmentation fault^M
0x1133447 crash_signal^M
/home/vries/oacc/trunk/source-gcc/gcc/toplev.c:327^M
0x12b1a69 modref_may_conflict^M
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-alias.c:2433^M
0x12b1da0 ref_maybe_used_by_call_p_1^M
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-alias.c:2513^M
0x12b2af9 ref_maybe_used_by_call_p^M
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-alias.c:2832^M
0x12b2c2f ref_maybe_used_by_stmt_p(gimple*, ao_ref*, bool)^M
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-alias.c:2864^M
0x12e8b6f dse_classify_store(ao_ref*, gimple*, bool, simple_bitmap_def*, bool*,
tree_node*)^M
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-dse.c:831^M
0x12e9817 dse_dom_walker::dse_optimize_stmt(gimple_stmt_iterator*)^M
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-dse.c:1151^M
0x12e9947 dse_dom_walker::before_dom_children(basic_block_def*)^M
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-dse.c:1183^M
0x1bef976 dom_walker::walk(basic_block_def*)^M
/home/vries/oacc/trunk/source-gcc/gcc/domwalk.c:309^M
0x12e9ac0 execute^M
/home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-dse.c:1237^M
...

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com,
   ||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
OpenMP has a way to express this,
#pragma omp declare simd notinbranch linear(y,z)
double sincos (double x, double *y, double *z);
As can be seen on -O2 -fopenmp-simd:
#pragma omp declare simd notinbranch linear(y, z)
double foo (double x, double *y, double *z);

double a[1024], b[1024], c[1024];

void
bar (void)
{
  #pragma omp simd
  for (int i = 0; i < 1024; i++)
foo (a[i], [i], [i]);
}
it works fine with that.  But if #pragma omp simd is commented out, it is not,
because the compiler has no assurance on what the function call behavior will
be e.g. for data reference analysis (it could e.g. modify the global vars).
Now, for sincos proper, the compiler knows what the function does if not
-fno-builtin-sincos.

Unfortunately, I think glibc currently defines sincos in math-vector.h the
unuseful way with just simd ("notinbranch") attribute, which effectively means
that the caller is supposed to pass vectors of pointers (well integers with
those sizes) and so needs scatter under the hood.
So the best thing would be to change glibc first.

[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On Tue, 22 Sep 2020, kangshan0910 at hotmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770
> 
> --- Comment #13 from ? ?  ---
> (In reply to Richard Biener from comment #12)
> > *** Bug 97149 has been marked as a duplicate of this bug. ***
> 
> Will you look at this?

glibc needs to think of an ABI for OMP SIMD for this, then we can
autovectorize.  Alternatively we could of course use
vector sin and vector cos separately which might be better than
not vectorizing it at all?

[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake

[crazylht at gmail dot com]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to Michael_S from comment #3)
> (In reply to Alexander Monakov from comment #2)
> > Richard, though register moves are resolved by renaming, they still occupy a
> > uop in all stages except execution, and since renaming is one of the
> > narrowest points in the pipeline (only up to 4 uops/cycle on Intel),
> > reducing number of uops generally helps.
> > 
> > In Michael's the actual memory address has two operands:
> > 
> > <   vmovapd %ymm1, %ymm10
> > <   vmovapd %ymm1, %ymm11
> > <   vfnmadd213pd(%rdx,%rax), %ymm9, %ymm10
> > <   vfnmadd213pd(%rcx,%rax), %ymm7, %ymm11
> > ---
> > >   vmovupd (%rdx,%rax), %ymm10
> > >   vmovupd (%rcx,%rax), %ymm11
> > >   vfnmadd231pd%ymm1, %ymm9, %ymm10
> > >   vfnmadd231pd%ymm1, %ymm7, %ymm11
> > 

We can add peephole2 pattern for this particular situation(Assume the
transformation won't hurt the performance when instructions are outside of
inner loops), but not sure if GCC could hanlde it in *global view*(handle them
differently inside/outside of a loop).