[Bug target/86753] [9/10 Regression] gcc.target/aarch64/sve/vcond_[45].c fail after recent combine patch

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #10 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Fri Oct 18 05:13:26 2019
New Revision: 277141

URL: https://gcc.gnu.org/viewcvs?rev=277141=gcc=rev
Log:
2019-10-18  Prathamesh Kulkarni  
Richard Sandiford  

PR target/86753
* tree-vectorizer.h (scalar_cond_masked_key): New struct,
and define hashmap traits for it.
(loop_vec_info::scalar_cond_masked_set): New member.
(vect_record_loop_mask): Adjust prototype.
* tree-vectorizer.c (scalar_cond_masked_key::get_cond_ops_from_tree):
Implement method.
* tree-vect-loop.c (vectorizable_reduction): Pass NULL as last arg to
vect_record_loop_mask.
(vectorizable_live_operation): Likewise.
(vect_record_loop_mask): New param scalar_mask. Add entry
cond, loop_mask to scalar_cond_masked_set if scalar_mask is non NULL.
* tree-vect-stmts.c (check_load_store_masking): New param scalar_mask.
Pass it as last arg to vect_record_loop_mask.
(vectorizable_call): Pass scalar_mask as last arg to
vect_record_loop_mask.
(vectorizable_store): Likewise.
(vectorizable_load): Likewise.
(vectorizable_condition): Check if another part of vectorized code
applies loop_mask to condition or to it's inverse, and if yes,
apply loop_mask to result of vector comparison.

testsuite/
* gcc.target/aarch64/sve/cond_cnot_2.c: Remove XFAIL
from { scan-assembler-not {\tsel\t}.
* gcc.target/aarch64/sve/cond_convert_1.c: Adjust to make
only one load conditional.
* gcc.target/aarch64/sve/cond_convert_4.c: Likewise.
* gcc.target/aarch64/sve/cond_unary_2.c: Likewise.
* gcc.target/aarch64/sve/vcond_4.c: Remove XFAIL's.
* gcc.target/aarch64/sve/vcond_5.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/sve/cond_cnot_2.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/cond_convert_1.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/cond_convert_4.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/cond_unary_2.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_4.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/vcond_5.c
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.c
trunk/gcc/tree-vectorizer.h

[Bug c++/87628] Redundant check of pointer when operator delete is called

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  IIRC there are duplicates of this bug.

Well related bugs for the plain-C equivalent with free() at least

[Bug target/92137] [ia32] Missing documentation for ia32 builtins

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #3)
> Those are intrinsics and most of them are documented in the Intel
> architecture manuals, or various web sites.  Not sure it is a good idea to
> duplicate that documentation.

Might be worthwhile to at least provide a link to the manuals or websites then,
if we're not going to duplicate the info contained in them...

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

[gcc-bugzilla at daryl dot haresign.com]

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

--- Comment #4 from Daryl Haresign  ---
As for conformance, the latest C draft says:

The aligned_alloc function allocates space for an object whose alignment is
specified by alignment, whose size is specified by size, and whose value is
indeterminate. If the value of alignment is not a valid alignment supported by
the implementation the function shall fail by returning a null pointer.

C11 said:

The aligned_alloc function allocates space for an object whose alignment is
specified by alignment, whose size is specified by size, and whose value is
indeterminate. The value of alignment shall be a valid alignment supported by
the implementation and the value of size shall be an integral multiple of
alignment.

So it seems macOS and AIX's implementations are technically conformant. 
Perhaps GCC should determine whether the platform supports alignments less than
sizeof(void*) when GCC is built, and put a new macro in c++config.h (assuming
that's how that file is constructed)?

[Bug rtl-optimization/92107] GCC's insn attribute arithmetic does not follow C rules

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED
  Known to fail||7.4.0, 8.3.0, 9.2.0

--- Comment #3 from Segher Boessenkool  ---
Fixed on trunk.  This doesn't need a backport unless something that uses
such arithmetic shows up (there is nothing currently); not doing it now.

[Bug c++/92145] New: -Wdeprecated-copy false-positive when inheriting base assignment operators

[nok.raven at gmail dot com]

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

Bug ID: 92145
   Summary: -Wdeprecated-copy false-positive when inheriting base
assignment operators
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nok.raven at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/UAc5tq

struct base
{
base() { }
base(const base&) { }
base(base&&) { }
base& operator=(const base&) { return *this; }
base& operator=(base&&) { return *this; }
};

struct foo : base
{
//using base::base;
using base::operator=;
};

struct bar
{
bar& operator=(foo v)
{
value = v;
return *this;
}

foo value;
};

int main()
{
foo a;
foo{a};
}


source>: In member function 'bar& bar::operator=(foo)':
:20:17: warning: implicitly-declared 'foo& foo::operator=(const foo&)'
is deprecated [-Wdeprecated-copy]
   20 | value = v;
  | ^
:6:11: note: because 'foo' has user-provided 'base&
base::operator=(const base&)'
6 | base& operator=(const base&) { return *this; }
  |   ^~~~
: In function 'int main()':
:30:10: warning: implicitly-declared 'foo::foo(const foo&)' is
deprecated [-Wdeprecated-copy]
   30 | foo{a};
  |  ^
:6:11: note: because 'foo' has user-provided 'base&
base::operator=(const base&)'
6 | base& operator=(const base&) { return *this; }
  |   ^~~~

[Bug tree-optimization/92056] [10 Regression] ice in expr_object_size, at tree-object-si ze.c:675 with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Oct 17 22:21:12 2019
New Revision: 277134

URL: https://gcc.gnu.org/viewcvs?rev=277134=gcc=rev
Log:
PR tree-optimization/92056
* tree-ssa-strlen.c (determine_min_objsize): Call init_object_sizes
before calling compute_builtin_object_size.

* gcc.dg/tree-ssa/pr92056.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr92056.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug fortran/69455] [7/8/9/10 Regression] [F08] Assembler error(s) when using intrinsic modules in two BLOCK

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #15 from kargl at gcc dot gnu.org ---
see https://gcc.gnu.org/ml/fortran/2019-10/msg00157.html

[Bug fortran/89047] ICE in mark_scope_block_unused, at tree-ssa-live.c:391

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
The code in the original comment now compiles.  Likely fixed by one of Tobias's
recent patches.

[Bug testsuite/92144] New: [10 regression] c-c++-common/Warray-bounds-4.c still fails after r277080

[seurer at gcc dot gnu.org]

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

Bug ID: 92144
   Summary: [10 regression] c-c++-common/Warray-bounds-4.c still
fails after r277080
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This test is still failing at least sometimes on powerpc64 (re: remove XFAIL):

make -k check-gcc RUNTESTFLAGS=dg.exp=c-c++-common/Warray-bounds-4.c
...
FAIL: c-c++-common/Warray-bounds-4.c  -Wc++-compat  strcpy (test for warnings,
line 66)
FAIL: c-c++-common/Warray-bounds-4.c  -std=gnu++98 strcpy (test for warnings,
line 66)
FAIL: c-c++-common/Warray-bounds-4.c  -std=gnu++14 strcpy (test for warnings,
line 66)
FAIL: c-c++-common/Warray-bounds-4.c  -std=gnu++17 strcpy (test for warnings,
line 66)
FAIL: c-c++-common/Warray-bounds-4.c  -std=gnu++2a strcpy (test for warnings,
line 66)
...
# of expected passes3
# of expected passes12
# of unexpected failures1
# of expected failures  1
# of unexpected failures4
# of expected failures  4


One example:


Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/Warray-bounds-4.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -Wc++-compat  -O2
-Warray-bounds=2 -Wno-stringop-overflow -ftrack-macro-expansion=0 -S -o
Warray-bounds-4.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/Warray-bounds-4.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -Wc++-compat -O2
-Warray-bounds=2 -Wno-stringop-overflow -ftrack-macro-expansion=0 -S -o
Warray-bounds-4.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/Warray-bounds-4.c: In
function 'test_memcpy_bounds_memarray_range':
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/Warray-bounds-4.c:47:3:
warning: 'memcpy' offset [5, 7] from the object at 'ma' is out of the bounds of
referenced subobject 'a5' with type 'char[5]' at offset 0 [-Warray-bounds]
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/Warray-bounds-4.c:27:18:
note: subobject 'a5' declared here
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/Warray-bounds-4.c:48:3:
warning: 'memcpy' offset [5, 9] from the object at 'ma' is out of the bounds of
referenced subobject 'a5' with type 'char[5]' at offset 0 [-Warray-bounds]
/home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/Warray-bounds-4.c:27:18:
note: subobject 'a5' declared here
PASS: c-c++-common/Warray-bounds-4.c  -Wc++-compat   (test for warnings, line
47)
PASS: c-c++-common/Warray-bounds-4.c  -Wc++-compat   (test for warnings, line
48)
FAIL: c-c++-common/Warray-bounds-4.c  -Wc++-compat  strcpy (test for warnings,
line 66)
XFAIL: c-c++-common/Warray-bounds-4.c  -Wc++-compat  strcpy (test for warnings,
line 70)
PASS: c-c++-common/Warray-bounds-4.c  -Wc++-compat  (test for excess errors)




r277080 | msebor | 2019-10-16 14:24:36 -0500 (Wed, 16 Oct 2019) | 24 lines

PR tree-optimization/83821 - local aggregate initialization defeats strlen
optimization

gcc/ChangeLog:

PR tree-optimization/83821
* tree-ssa-strlen.c (maybe_invalidate): Add argument.  Consider
the length of a string when available.
(handle_builtin_memset) Add argument.
(handle_store, strlen_check_and_optimize_call): Same.
(check_and_optimize_stmt): Same.  Pass it to callees.

gcc/testsuite/ChangeLog:

PR tree-optimization/83821
* c-c++-common/Warray-bounds-4.c: Remove XFAIL.
* gcc.dg/strlenopt-82.c: New test.
* gcc.dg/strlenopt-83.c: Same.
* gcc.dg/strlenopt-84.c: Same.
* gcc.dg/strlenopt-85.c: Same.
* gcc.dg/strlenopt-86.c: Same.
* gcc.dg/tree-ssa/calloc-4.c: Same.
* gcc.dg/tree-ssa/calloc-5.c: Same.

[Bug testsuite/92126] gcc.dg/vect/pr62171.c fails on power7

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Should we close this?  I found it on an internal list of old failures on P7
that need looking at.  Not sure having this issue open provides value.

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

[gcc-bugzilla at daryl dot haresign.com]

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

--- Comment #3 from Daryl Haresign  ---
$ g++-9 -E -dM test.cc | grep ALIGNED
#define _GLIBCXX_HAVE_ALIGNED_ALLOC 1

[Bug testsuite/92126] gcc.dg/vect/pr62171.c fails on power7

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[10 regression] |gcc.dg/vect/pr62171.c fails
   |gcc.dg/vect/pr62171.c fails |on power7
   |after r276876 on power7 |

--- Comment #3 from seurer at gcc dot gnu.org ---
Looking back through logs this goes back a looong way.  Not sure why it popped
up as a newly found regression.

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-10-17
  Component|c++ |libstdc++
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
More likely is that OS X has a non-conforming aligned_alloc, similar to AIX:

#if _GLIBCXX_HAVE_ALIGNED_ALLOC
# ifdef _AIX
  /* AIX 7.2.0.0 aligned_alloc incorrectly has posix_memalign's requirement
   * that alignment is a multiple of sizeof(void*).  */
  if (align < sizeof(void*))
align = sizeof(void*);
# endif
  /* C11: the value of size shall be an integral multiple of alignment.  */
  sz = (sz + align - 1) & ~(align - 1);
#endif


Please attach the output of compiling your example with -E -dM so I can see
which macros are defined.

[Bug c++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
We increase the alignment when calling posix_memalign, so that shouldn't be the
problem:

static inline void*
aligned_alloc (std::size_t al, std::size_t sz)
{
  void *ptr;
  // posix_memalign has additional requirement, not present on aligned_alloc:
  // The value of alignment shall be a power of two multiple of sizeof(void *).
  if (al < sizeof(void*))
al = sizeof(void*);
  int ret = posix_memalign (, al, sz);
  if (ret == 0)
return ptr;
  return nullptr;
}

[Bug rtl-optimization/89721] __builtin_mffs sometimes optimized away

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #8 from Segher Boessenkool  ---
Fixed on all open release branches.

[Bug target/92140] clang vs gcc optimizing with adc/sbb

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-17
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Uroš Bizjak  ---
This optimization builds on the equivalence of:

cmpl$0, %edi
sete%al

where zero flag is used to set %al and

cmpl$1, %edi
setc%al

where carry flag is set to the "borrow" from the unsigned subtract of the $1
from %edi. The carry flag (aka "borrow") is set only for (0 - 1), when %edi ==
0.


The above conversion is beneficial when the following insn consumes carry flag
(e.g. adc/sbb, but also rcr and rcl).

IMO, the combine pass should be the most appropriate place for the above
transformation.

[Bug rtl-optimization/89721] __builtin_mffs sometimes optimized away

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Author: segher
Date: Thu Oct 17 19:52:55 2019
New Revision: 277132

URL: https://gcc.gnu.org/viewcvs?rev=277132=gcc=rev
Log:
Backport from trunk
2019-03-15  Segher Boessenkool  

PR rtl-optimization/89721
* lra-constraints (invariant_p): Return false if side_effects_p holds.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/lra-constraints.c

[Bug rtl-optimization/89721] __builtin_mffs sometimes optimized away

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Author: segher
Date: Thu Oct 17 19:51:01 2019
New Revision: 277131

URL: https://gcc.gnu.org/viewcvs?rev=277131=gcc=rev
Log:
Backport from trunk
2019-03-15  Segher Boessenkool  

PR rtl-optimization/89721
* lra-constraints (invariant_p): Return false if side_effects_p holds.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/lra-constraints.c

[Bug target/65342] [7/8/9/10 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9/10 after r210201

[iains at gcc dot gnu.org]

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

--- Comment #29 from Iain Sandoe  ---
Author: iains
Date: Thu Oct 17 19:46:52 2019
New Revision: 277130

URL: https://gcc.gnu.org/viewcvs?rev=277130=gcc=rev
Log:
[Darwin, PPC] Fix PR 65342.

The current Darwin load/store lo_sum patterns have neither predicate nor
constraint.  This means that most parts of the backend, which rely on
recog() to validate the rtx, can produce invalid combinations/selections.

For 32bit cases this isn't a problem since we can load/store to unaligned
addresses using D-mode insns.

Conversely, for 64bit instructions that use DS mode, this can manifest as
assemble errors (for an assembler that checks the LO14 relocations), or as
crashes caused by wrong offsets (or worse, wrong content for the two LSBs).

What we want to check for "Y" on Darwin is:
  - that the alignment of the Symbols' target is sufficient for DS mode
  - that the offset is suitable for DS mode.
(while looking through the Mach-O PIC unspecs).

So, the patch removes the Darwin-specific lo_sum patterns (we begin using
the movdi_internal64 patterns).  We also we need to extend the handling of the
mem_operand_gpr constraint to allow looking through Mach-O PIC UNSPECs in
the lo_sum cases.

gcc/ChangeLog:

2019-10-17  Iain Sandoe  

PR target/65342
* config/rs6000/darwin.md (movdi_low, movsi_low_st): Delete.
(movdi_low_st): Delete.
* config/rs6000/rs6000.c
(darwin_rs6000_legitimate_lo_sum_const_p): New.
(mem_operand_gpr): Validate Mach-O LO_SUM cases separately.
* config/rs6000/rs6000.md (movsi_low): Delete.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/darwin.md
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md

[Bug target/92137] [ia32] Missing documentation for ia32 builtins

[danielgutson at gmail dot com]

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

Daniel Gutson  changed:

   What|Removed |Added

 CC||danielgutson at gmail dot com

--- Comment #4 from Daniel Gutson  ---
(In reply to Jakub Jelinek from comment #3)
> Those are intrinsics and most of them are documented in the Intel
> architecture manuals, or various web sites.  Not sure it is a good idea to
> duplicate that documentation.

What about
https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html#x86-Built-in-Functions
?

[Bug c++/92143] New: std::pmr::polymorphic_allocator throws bad_alloc on macOS

[gcc-bugzilla at daryl dot haresign.com]

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

Bug ID: 92143
   Summary: std::pmr::polymorphic_allocator throws bad_alloc
on macOS
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at daryl dot haresign.com
  Target Milestone: ---

The following code throws a std::bad_alloc on macOS (seen via GCC 9.2 installed
with Homebrew, on macOS Catalina 10.15):

  #include 
  #include 
  int main()
  {
std::pmr::string s { "0123456789abcdef" };
  }

16 characters is required to get it to overflow SSO.

The same issue can be seen with the following code:

  #include 
  int main()
  {
std::pmr::polymorphic_allocator alloc {
  std::pmr::new_delete_resource()
};
alloc.allocate(1);
  }

Changing the type from char to short, and char to int, yields the same error. 
Once you get to long, it starts working.

Presumably power-of-two alignments less than sizeof(void *) are not supported
(that's certainly what posix_memalign says).

Looking through the wording, it's all down to a question of whether
[mem.res.private] p2 allows for your memory resources to force the alignment to
be at least alignof(void *).  I would say the answer is probably yes.

http://eel.is/c++draft/mem.res#private-2

[Bug target/92137] [ia32] Missing documentation for ia32 builtins

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Those are intrinsics and most of them are documented in the Intel architecture
manuals, or various web sites.  Not sure it is a good idea to duplicate that
documentation.

[Bug target/92137] [ia32] Missing documentation for ia32 builtins

[arieltorti14 at gmail dot com]

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

--- Comment #2 from Ariel Torti  ---
(In reply to Richard Biener from comment #1)
> You shouldn't use those, they are for internal use only.  That's the reason
> they are not documented.

Yes, my mistake. I just read
https://www.mail-archive.com/gcc@gcc.gnu.org/msg03310.html, where it says
built-ins should not be documented.

But if builtins are not documented their interfaces should, right ?
As in, the functions below should be documented:

__bsfd / _bit_scan_forward
__bsrd / _bit_scan_reverse
__bswapd / _bswap
__crc32b / 
__crc32w
__crc32d
__popcntd / _popcnt32
__rdpmc / _rdpmc
__rdtsc / _rdtsc 
__rdtscp / _rdtscp
__rolb
__rolw
__rold
__rorb
__rorw
__rord
__pause
__bsfq
__bsrq
__bswapq / _bswap64
__crc32q
__popcntq / _popcnt64
__rolq
__rorq
__writeeflags
__readeflags

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #9 from Witold Baryluk  ---
Indeed, passing -fno-tree-pre in the first example does make it be vectorized.

In the mesh_simple.c this corresponds to ONTHEFLY_CONSTANTS being defined, but
USE_LOOP_CONSTANTS being not. The SIMPLIFIED can be defined or not, it
vectorizes now in both cases.

Targeting -march=knm.

This is with #define OCTAVES 12, a compile time constant, so compiler fully
unrolls the most inner loop.

Without -fno-tree-pre:

1230 :
1230:   41 57   push   %r15
1232:   62 a1 7d 40 ef c0   vpxord %zmm16,%zmm16,%zmm16
1238:   49 ba 53 ec 85 1a femovabs $0xc4ceb9fe1a85ec53,%r10
123f:   b9 ce c4 
1242:   41 56   push   %r14
1244:   c5 7a 10 0d f8 0d 00vmovss 0xdf8(%rip),%xmm9# 2044
<_IO_stdin_used+0x44>
124b:   00 
124c:   62 31 7c 48 28 d0   vmovaps %zmm16,%zmm10
1252:   41 55   push   %r13
1254:   c5 7a 10 3d ec 0d 00vmovss 0xdec(%rip),%xmm15# 2048
<_IO_stdin_used+0x48>
125b:   00 
125c:   62 a1 7c 48 28 d0   vmovaps %zmm16,%zmm18
1262:   41 54   push   %r12
1264:   c5 7a 10 35 e0 0d 00vmovss 0xde0(%rip),%xmm14# 204c
<_IO_stdin_used+0x4c>
126b:   00 
126c:   49 b9 cd 8c 55 ed d7movabs $0xff51afd7ed558ccd,%r9
1273:   af 51 ff 
1276:   55  push   %rbp
1277:   c5 7a 10 2d d1 0d 00vmovss 0xdd1(%rip),%xmm13# 2050
<_IO_stdin_used+0x50>
127e:   00 
127f:   49 be 68 66 ac 6a bfmovabs $0xfa8d7ebf6aac6668,%r14
1286:   7e 8d fa 
1289:   53  push   %rbx
128a:   c5 7a 10 25 c2 0d 00vmovss 0xdc2(%rip),%xmm12# 2054
<_IO_stdin_used+0x54>
1291:   00 
1292:   48 89 7c 24 f8  mov%rdi,-0x8(%rsp)
1297:   c7 44 24 f0 00 00 00movl   $0x0,-0x10(%rsp)
129e:   00 
129f:   c7 44 24 f4 00 00 00movl   $0x0,-0xc(%rsp)
12a6:   00 
12a7:   c5 7a 10 1d a9 0d 00vmovss 0xda9(%rip),%xmm11# 2058
<_IO_stdin_used+0x58>
12ae:   00 
12af:   62 e1 7e 08 10 0d a3vmovss 0xda3(%rip),%xmm17# 205c
<_IO_stdin_used+0x5c>
12b6:   0d 00 00 
12b9:   0f 1f 80 00 00 00 00nopl   0x0(%rax)
12c0:   48 8b 6c 24 f8  mov-0x8(%rsp),%rbp
12c5:   31 f6   xor%esi,%esi
12c7:   31 db   xor%ebx,%ebx
12c9:   62 31 7c 48 28 c2   vmovaps %zmm18,%zmm8
12cf:   90  nop
12d0:   8b 54 24 f0 mov-0x10(%rsp),%edx
12d4:   45 31 e4xor%r12d,%r12d
12d7:   62 b1 7c 48 28 f8   vmovaps %zmm16,%zmm7
12dd:   62 c1 7c 48 28 d9   vmovaps %zmm9,%zmm19
12e3:   c5 32 11 cc vmovss %xmm9,%xmm9,%xmm4
12e7:   eb 26   jmp130f

12e9:   0f 1f 80 00 00 00 00nopl   0x0(%rax)
12f0:   c5 ba 59 c4 vmulss %xmm4,%xmm8,%xmm0
12f4:   62 f3 7d 08 0a c0 09vrndscaless $0x9,%xmm0,%xmm0,%xmm0
12fb:   c5 fa 2c f0 vcvttss2si %xmm0,%esi
12ff:   c4 c1 5a 59 c2  vmulss %xmm10,%xmm4,%xmm0
1304:   62 f3 7d 08 0a c0 09vrndscaless $0x9,%xmm0,%xmm0,%xmm0
130b:   c5 fa 2c d0 vcvttss2si %xmm0,%edx
130f:   4c 89 e1mov%r12,%rcx
1312:   62 c1 7c 48 28 e8   vmovaps %zmm8,%zmm21
1318:   48 c1 e9 21 shr$0x21,%rcx
131c:   62 e1 7c 48 28 e4   vmovaps %zmm4,%zmm20
1322:   c5 d2 2a ea vcvtsi2ss %edx,%xmm5,%xmm5
1326:   4c 31 e1xor%r12,%rcx
1329:   49 0f af ca imul   %r10,%rcx
132d:   48 63 d2movslq %edx,%rdx
1330:   c5 e2 2a de vcvtsi2ss %esi,%xmm3,%xmm3
1334:   4f 8d 24 0c lea(%r12,%r9,1),%r12
1338:   48 69 d2 53 42 41 4eimul   $0x4e414253,%rdx,%rdx
133f:   62 c2 55 08 9b e2   vfmsub132ss %xmm10,%xmm5,%xmm20
1345:   c4 c1 52 58 e9  vaddss %xmm9,%xmm5,%xmm5
134a:   48 8d 01lea(%rcx),%rax
134d:   48 c1 e8 21 shr$0x21,%rax
1351:   62 e2 65 08 9b ec   vfmsub132ss %xmm4,%xmm3,%xmm21
1357:   48 31 c1xor%rax,%rcx
135a:   4c 8d ba 53 42 41 4elea0x4e414253(%rdx),%r15
1361:   48 89 cfmov%rcx,%rdi
1364:   48 89 c8mov%rcx,%rax
1367:   48 81 f7 70 46 ab 58xor$0x58ab4670,%rdi
136e:   c4 c1 62 58 d9  vaddss %xmm9,%xmm3,%xmm3
1373:   48 c1 e8 21 shr

[Bug tree-optimization/92141] Bogus -Wstringop-truncation warning for strncpy in a loop

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-17
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The warning sees the '_1 = (char[8] *) ivtmp.6_10;' DEF_STMT but
ignores the cast to (char[8] *) and considers the size of ivtmp.6_9(3) as the
size of the array that could store the longest string.

e ()
{
  unsigned long ivtmp.6;
  int f;
  char[8] * _1;

   [local count: 107374]:
  ivtmp.6_14 = (unsigned long) 

   [local count: 1073741824]:
  # ivtmp.6_10 = PHI 
  _1 = (char[8] *) ivtmp.6_10;
  strncpy (, _1, 8);
  ivtmp.6_9 = ivtmp.6_10 + 8;
  goto ; [100.00%]

}


The warning could be changed to consider the type of the cast instead, trading
the false positive for a false negative in code like:

  char a[23];

  void g (char *b)
  {
typedef char A[8];
A *p = (A *)a;
for (int i = 0; i != 3; ++i)
  strncpy (b, p + i, 8);
  }


My guess is the former is more common than the latter so the trade-off might
make sense.  Alternatively, the warning could try to take both the cast and the
type of the object into consideration and use some heuristic to decide between
the two.

[Bug target/89400] [7/8/9 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Earnshaw  ---
Fixed on all active branches

[Bug target/89400] [7/8/9 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access

[rearnsha at gcc dot gnu.org]

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

--- Comment #10 from Richard Earnshaw  ---
Author: rearnsha
Date: Thu Oct 17 16:48:39 2019
New Revision: 277125

URL: https://gcc.gnu.org/viewcvs?rev=277125=gcc=rev
Log:
[arm]  PR target/89400 fix thumb1 unaligned access expansion

Armv6 has support for unaligned accesses to memory.  However, the
thumb1 code patterns were trying to use the 32-bit code constraints.
One failure mode from this was that the patterns are designed to be
compatible with conditional execution and this was then causing an
assert in the compiler.

The unaligned_loadhis pattern is only used for expanding extv, which
in turn is only enabled for systems supporting thumb2.  Given that
there is no simple expansion for a thumb1 sign-extending load (the
instruction has no immediate offset form and requires two registers in
the address) it seems simpler to just disable this for thumb1.

Fixed thusly:

Backport from trunk:
2019-05-03  Richard Earnshaw  

PR target/89400
* config/arm/arm.md (unaligned_loadsi): Add variant for thumb1.
Restrict 'all' variant to 32-bit configurations.
(unaligned_loadhiu): Likewise.
(unaligned_storehi): Likewise.
(unaligned_storesi): Likewise.
(unaligned_loadhis): Disable when compiling for thumb1.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/arm/arm.md

[Bug target/89400] [7/8/9 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access

[rearnsha at gcc dot gnu.org]

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

--- Comment #9 from Richard Earnshaw  ---
Author: rearnsha
Date: Thu Oct 17 16:47:42 2019
New Revision: 277124

URL: https://gcc.gnu.org/viewcvs?rev=277124=gcc=rev
Log:
[arm]  PR target/89400 fix thumb1 unaligned access expansion

Armv6 has support for unaligned accesses to memory.  However, the
thumb1 code patterns were trying to use the 32-bit code constraints.
One failure mode from this was that the patterns are designed to be
compatible with conditional execution and this was then causing an
assert in the compiler.

The unaligned_loadhis pattern is only used for expanding extv, which
in turn is only enabled for systems supporting thumb2.  Given that
there is no simple expansion for a thumb1 sign-extending load (the
instruction has no immediate offset form and requires two registers in
the address) it seems simpler to just disable this for thumb1.

Fixed thusly:

Backport from trunk:
2019-05-03  Richard Earnshaw  

PR target/89400
* config/arm/arm.md (unaligned_loadsi): Add variant for thumb1.
Restrict 'all' variant to 32-bit configurations.
(unaligned_loadhiu): Likewise.
(unaligned_storehi): Likewise.
(unaligned_storesi): Likewise.
(unaligned_loadhis): Disable when compiling for thumb1.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/arm/arm.md

[Bug target/89400] [7/8/9 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access

[rearnsha at gcc dot gnu.org]

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

--- Comment #8 from Richard Earnshaw  ---
Author: rearnsha
Date: Thu Oct 17 16:45:46 2019
New Revision: 277123

URL: https://gcc.gnu.org/viewcvs?rev=277123=gcc=rev
Log:
[arm]  PR target/89400 fix thumb1 unaligned access expansion

Armv6 has support for unaligned accesses to memory.  However, the
thumb1 code patterns were trying to use the 32-bit code constraints.
One failure mode from this was that the patterns are designed to be
compatible with conditional execution and this was then causing an
assert in the compiler.

The unaligned_loadhis pattern is only used for expanding extv, which
in turn is only enabled for systems supporting thumb2.  Given that
there is no simple expansion for a thumb1 sign-extending load (the
instruction has no immediate offset form and requires two registers in
the address) it seems simpler to just disable this for thumb1.

Fixed thusly:

Backport from trunk:
2019-05-03  Richard Earnshaw  

PR target/89400
* config/arm/arm.md (unaligned_loadsi): Add variant for thumb1.
Restrict 'all' variant to 32-bit configurations.
(unaligned_loadhiu): Likewise.
(unaligned_storehi): Likewise.
(unaligned_storesi): Likewise.
(unaligned_loadhis): Disable when compiling for thumb1.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/arm/arm.md

[Bug fortran/92142] New: CFI_setpointer corrupts descriptor

[jrfsousa at gmail dot com]

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

Bug ID: 92142
   Summary: CFI_setpointer corrupts descriptor
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 47060
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47060=edit
Code demonstrating problems.

Hi all!

CFI_setpointer does not check if it is setting a pointer and will set any type
of object to the target.

CFI_setpointer will also change the pointer attribute of the pointer to
whatever is the target's attribute corrupting the descriptor.

Thank you very much.

Best regards,
José Rui

[Bug fortran/89943] Submodule functions are not allowed to have C binding

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk and 9-branch. Closing. Thanks for bug reports.

[Bug fortran/83113] Bogus "duplicate allocatable attribute" error for submodule character function

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct 17 16:30:25 2019
New Revision: 277122

URL: https://gcc.gnu.org/viewcvs?rev=277122=gcc=rev
Log:
2019-10-17  Steven G. Kargl  

PR fortran/83113
PR fortran/89943
decl.c (gfc_match_function_decl): Ignore duplicate BIND(C) for function
declaration in submodule.  Implement at check for F2018 C1550.
(gfc_match_entry): Use temporary for locus, which allows removal of
one gfc_error_now().
(gfc_match_subroutine): Ignore duplicate BIND(C) for subroutine
declaration in submodule.  Implement at check for F2018 C1550.

2019-10-17  Steven G. Kargl  

PR fortran/83113
PR fortran/89943
* gfortran.dg/pr89943_1.f90: New test.
* gfortran.dg/pr89943_2.f90: Ditto.
* gfortran.dg/pr89943_3.f90: Ditto.
* gfortran.dg/pr89943_4.f90: Ditto.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr89943_1.f90
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr89943_2.f90
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr89943_3.f90
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr89943_4.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/decl.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/89943] Submodule functions are not allowed to have C binding

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Oct 17 16:30:25 2019
New Revision: 277122

URL: https://gcc.gnu.org/viewcvs?rev=277122=gcc=rev
Log:
2019-10-17  Steven G. Kargl  

PR fortran/83113
PR fortran/89943
decl.c (gfc_match_function_decl): Ignore duplicate BIND(C) for function
declaration in submodule.  Implement at check for F2018 C1550.
(gfc_match_entry): Use temporary for locus, which allows removal of
one gfc_error_now().
(gfc_match_subroutine): Ignore duplicate BIND(C) for subroutine
declaration in submodule.  Implement at check for F2018 C1550.

2019-10-17  Steven G. Kargl  

PR fortran/83113
PR fortran/89943
* gfortran.dg/pr89943_1.f90: New test.
* gfortran.dg/pr89943_2.f90: Ditto.
* gfortran.dg/pr89943_3.f90: Ditto.
* gfortran.dg/pr89943_4.f90: Ditto.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr89943_1.f90
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr89943_2.f90
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr89943_3.f90
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr89943_4.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/decl.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug debug/90231] ivopts causes iterator in the loop

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Note, for the ignoring of not useful candidates we could during the cand_pref
computation not just check for step being equal, but also if one step is
multiple of the other one or vice versa, of course prefer same step first, then
perhaps the * case where info->iv->step is a constant multiple of
cand->iv->step and finally the division case, perhaps that one with the
requirement that the type of cand->iv->base has then at least ceil_log2
(cand->iv->step) bits larger TYPE_PRECISION.

[Bug debug/90231] ivopts causes iterator in the loop

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
So, one possibility is for remove_unused_ivs to get_computation_at for all
candidates it is considering rather than just the best, or try best and if that
fails, try the others too and pick the best from among those that have some
computation.
Another problem is that get_computation_at fails even for the ivtmp.11_20
candidate.  Now, perhaps we could have some argument to get_computation_at,
for_debug or similar, propagate it through the calls.
The reason it fails is:
  else if (!constant_multiple_of (ustep, cstep, ))
return false;
ustep is 1, cstep is 4.  Indeed, we can't express i_18 as use using
use = ubase - ratio * cbase + ratio * var
because we need division instead, so
use = ubase + (var - cbase) / ratio.
Now, for non-debug uses I'm quite sure this is never a good answer, division in
the loop is expensive, but for debug uses it is fine.
The question is if it is safe, what we've discussed earlier.
For the case of ivtmp.11_20 on x86_64 I think it is safe no matter what,
int is 32-bit, cstep / ustep is constant 4 and thus as long as the unsigned
long ctype is at least 34-bit, if there wasn't overflow on i_18, there won't be
on the other IV either (after the base is subtracted, if say the base was -16,
there would be a wrap of course, but we care about var - cbase).
On 32-bit arches we'd need to argue from the pointer arithmetics I guess,
something that isn't clear in the candidate.

[Bug debug/90231] ivopts causes iterator in the loop

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
That has been added for PR54693 BTW.

[Bug testsuite/92126] [10 regression] gcc.dg/vect/pr62171.c fails after r276876 on power7

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Sorry, I may have gotten the suspect revision wrong for this.  There are some
build compilation failures just a bit before this revision that are goofing up
my bisect script.

[Bug debug/90231] ivopts causes iterator in the loop

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Note, there already is a function that is meant to handle this,
remove_unused_ivs, just either it doesn't find the right IV candidate, or
get_computation_at fails.
On this particular testcase, I see 2 IVs in the code originally, with the PHI
results base_17 and i_18, and two IVs in the code afterwards, base_17 and
ivtmp.11_20.  remove_unused_ivs for i_18 decides the best candidate is base_17,
which is unsigned int IV with step 15, so I'd guess the problem we've discussed
happens for that one.  That base_17 cand has cand_pref of 2, while the
ivtmp.11_20 one has cand_pref of 0 and so base_17 wins.  Anyway, just trying to
pass the other cand to get_computation_at fails too.  Why?

[Bug testsuite/92093] New test case gcc.target/powerpc/pr91275.c from r276410 fails on BE

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #8 from Bill Schmidt  ---
Closing.

[Bug testsuite/92093] New test case gcc.target/powerpc/pr91275.c from r276410 fails on BE

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.4.0, 8.3.0, 9.1.0
 Resolution|--- |FIXED
  Known to fail|7.4.0, 8.3.0, 9.1.0 |

--- Comment #7 from Bill Schmidt  ---
Fixed everywhere.

[Bug testsuite/92093] New test case gcc.target/powerpc/pr91275.c from r276410 fails on BE

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Oct 17 15:35:28 2019
New Revision: 277119

URL: https://gcc.gnu.org/viewcvs?rev=277119=gcc=rev
Log:
2019-10-17  Bill Schmidt  

Backport from mainline
2019-10-15  Bill Schmidt  

PR target/92093
* gcc.target/powerpc/pr91275.c: Fix type and endian issues.


Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr91275.c

[Bug tree-optimization/92141] New: Bogus -Wstringop-truncation warning for strncpy in a loop

[krebbel at gcc dot gnu.org]

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

Bug ID: 92141
   Summary: Bogus -Wstringop-truncation warning for strncpy in a
loop
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Compiling the following testcase with: gcc -O2 -Wall t.c

char *strncpy(char *, const char *, long unsigned); 
struct {
  char b[8];
} c[6]; 
char b[8];  
void e() {  
  for (int f = 0;; f++) 
strncpy(b, c[f].b, 8);  
}

gives me:

t.c: In function 'e':
t.c:8:5: warning: 'strncpy' output may be truncated copying 8 bytes from a
string of length 47 [-Wstringop-truncation]
8 | strncpy(b, c[f].b, 8);
  | ^

[Bug testsuite/92093] New test case gcc.target/powerpc/pr91275.c from r276410 fails on BE

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Oct 17 15:33:58 2019
New Revision: 277118

URL: https://gcc.gnu.org/viewcvs?rev=277118=gcc=rev
Log:
2019-10-17  Bill Schmidt  

Backport from mainline
2019-10-15  Bill Schmidt  

PR target/92093
* gcc.target/powerpc/pr91275.c: Fix type and endian issues.


Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr91275.c

[Bug testsuite/92093] New test case gcc.target/powerpc/pr91275.c from r276410 fails on BE

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Oct 17 15:32:40 2019
New Revision: 277117

URL: https://gcc.gnu.org/viewcvs?rev=277117=gcc=rev
Log:
2019-10-17  Bill Schmidt  

Backport from mainline
2019-10-15  Bill Schmidt  

PR target/92093
* gcc.target/powerpc/pr91275.c: Fix type and endian issues.


Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/pr91275.c

[Bug c/92140] New: clang vs gcc optimizing with adc/sbb

[hermantenbrugge at home dot nl]

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

Bug ID: 92140
   Summary: clang vs gcc optimizing with adc/sbb
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hermantenbrugge at home dot nl
  Target Milestone: ---

The following code:

extern char table[];
extern int c, v;

void tst1 (void) { v += table[c] != 0; }
void tst2 (void) { v -= table[c] != 0; }
unsigned int tst3 (unsigned int n) { return n ? 2 : 1; }

compiled with gcc and clang see some optimizing opportunities for gcc.
Table with instruction generated:
gccclang
tst1: 53
tst2: 53
tst3: 43

This is with:
gcc (GCC) 10.0.0 20191017 (experimental)
clang version 10.0.0 (trunk 373843)

[Bug tree-optimization/92111] [10 Regression] ICE during GIMPLE pass: dom

[jan at jki dot io]

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

--- Comment #6 from Jan  ---
-fno-semantic-interposition with -flto  seems to be the culprit if I drop
either compile works fine.


minimum cflags for error: -march=native -O2 -flto -fno-semantic-interposition

[Bug c++/92136] cc1plus segv with CTAD and -fchecking

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
We call comp_template_parms with
2 D.2223, 1 d, <<< Unknown tree: template_decl >>>
2 D.2254, 1 d, <<< Unknown tree: template_decl >>>

it compares D.2223 to D.2254, then d to d, then the template_decls.  When
comparing the template decls, we will compare their types:

 3289   else if (!same_type_p (TREE_TYPE (parm1), TREE_TYPE (parm2)))
 3290 return 0;
their types are template_template_parms.  So in structural_comptypes we do:

 1324   if (!comp_template_parms
 1325   (DECL_TEMPLATE_PARMS (TEMPLATE_TEMPLATE_PARM_TEMPLATE_DECL
(t1)),
 1326DECL_TEMPLATE_PARMS (TEMPLATE_TEMPLATE_PARM_TEMPLATE_DECL
(t2
 1327 return false;

but DECL_TEMPLATE_PARMS (TEMPLATE_TEMPLATE_PARM_TEMPLATE_DECL (t1)) is
2 D.2223, 1 d, <<< Unknown tree: template_decl >>>
and DECL_TEMPLATE_PARMS (TEMPLATE_TEMPLATE_PARM_TEMPLATE_DECL (t2)) is
2 D.2254, 1 d, <<< Unknown tree: template_decl >>>
so we loop.

[Bug c++/92139] New: Segmentation fault on constraints verification

[mateusz.pusz at gmail dot com]

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

Bug ID: 92139
   Summary: Segmentation fault on constraints verification
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mateusz.pusz at gmail dot com
  Target Milestone: ---

While trying to compile preprocessed file from the attachment the compiler
crashes with the following stack trace:

[build] /usr/local/gcc-10/bin/g++-10   -I../../src/include -isystem
/home/mpusz/.conan/data/range-v3/0.9.1/ericniebler/stable/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include
-isystem
/home/mpusz/.conan/data/fmt/6.0.0/_/_/package/1291f461f6832a5b3098e2156f727f267fd98612/include
-Wall -Wextra -Wformat=2 -pedantic -Wshadow -Wunused -Wnon-virtual-dtor
-Woverloaded-virtual -Wold-style-cast -Wcast-qual -Wcast-align -Wlogical-op
-Wuseless-cast -Wduplicated-cond -Wduplicated-branches -Wnull-dereference
-Werror -g   -fconcepts -Wno-literal-suffix -Wno-non-template-friend
-Wno-pedantic -std=gnu++2a -MD -MT
test/unit_test/static/CMakeFiles/unit_tests_static.dir/quantity_test.cpp.o -MF
test/unit_test/static/CMakeFiles/unit_tests_static.dir/quantity_test.cpp.o.d -o
test/unit_test/static/CMakeFiles/unit_tests_static.dir/quantity_test.cpp.o -c
../../test/unit_test/static/quantity_test.cpp
[build] In file included from ../../src/include/units/dimensions/length.h:26,
[build]  from ../../src/include/units/dimensions/velocity.h:25,
[build]  from ../../test/unit_test/static/quantity_test.cpp:23:
[build] ../../src/include/units/quantity.h: In constructor ‘constexpr
units::quantity::quantity(const Q2&) [with Q2 =
units::quantity; U = units::metre; Rep = int]’:
[build] ../../src/include/units/quantity.h:206:18: internal compiler error:
Segmentation fault
[build]   206 | requires same_dim &&
[build]   |  ^~~
[build] 0xba89ff crash_signal
[build] ../../gcc_trunk/gcc/toplev.c:326
[build] 0x70a11d tsubst(tree_node*, tree_node*, int, tree_node*)
[build] ../../gcc_trunk/gcc/cp/pt.c:14896
[build] 0x714626 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
[build] ../../gcc_trunk/gcc/cp/pt.c:12917
[build] 0x70b157 tsubst(tree_node*, tree_node*, int, tree_node*)
[build] ../../gcc_trunk/gcc/cp/pt.c:14772
[build] 0x714626 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
[build] ../../gcc_trunk/gcc/cp/pt.c:12917
[build] 0x707592 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
[build] ../../gcc_trunk/gcc/cp/pt.c:18697
[build] 0x70e5f6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
[build] ../../gcc_trunk/gcc/cp/pt.c:18630
[build] 0x70e5f6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../gcc_trunk/gcc/cp/pt.c:18288
[build] 0x644a19 satisfy_atom
[build] ../../gcc_trunk/gcc/cp/constraint.cc:2343
[build] 0x6450d2 satisfy_conjunction
[build] ../../gcc_trunk/gcc/cp/constraint.cc:2403
[build] 0x6450f4 satisfy_conjunction
[build] ../../gcc_trunk/gcc/cp/constraint.cc:2399
[build] 0x64521d satisfy_constraint
[build] ../../gcc_trunk/gcc/cp/constraint.cc:2427
[build] 0x645533 satisfy_associated_constraints
[build] ../../gcc_trunk/gcc/cp/constraint.cc:2445
[build] 0x645533 constraints_satisfied_p
[build] ../../gcc_trunk/gcc/cp/constraint.cc:2529
[build] 0x61646a add_function_candidate
[build] ../../gcc_trunk/gcc/cp/call.c:2262
[build] 0x6187ed add_template_candidate_real
[build] ../../gcc_trunk/gcc/cp/call.c:3399
[build] 0x618d14 add_template_candidate
[build] ../../gcc_trunk/gcc/cp/call.c:3440
[build] 0x618d14 add_candidates
[build] ../../gcc_trunk/gcc/cp/call.c:5748
[build] 0x61bbca add_candidates
[build] ../../gcc_trunk/gcc/cp/call.c:5672
[build] 0x61bbca build_new_method_call_1
[build] ../../gcc_trunk/gcc/cp/call.c:9812
[build] Please submit a full bug report,
[build] with preprocessed source if appropriate.
[build] Please include the complete backtrace with any bug report.
[build] See  for instructions.

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[segher at gcc dot gnu.org]

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

--- Comment #16 from Segher Boessenkool  ---
Oh doh, I am blind, apparently :-)

[Bug debug/90231] ivopts causes iterator in the loop

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Sure, the debug stmts should not have any effect on code generation.  I admit I
don't know much about ivopts implementation, but either when you are rewriting
stmts containing uses of the IV being replaced by some other IV, don't you know
an IV from the same class already and similarly to how the replacement is done
for those, you'd tweak debug stmts too?  And, if there aren't any normal uses
(I think the only spot i_18 is used is in the increment of the iterator), can't
you try to determine an IV from the same class (if it exist) and again, emit
the needed expressions in debug stmts?
While the debug stmts don't have a rigid shape like other GIMPLE stmts, we
certainly try to avoid arbitrarily complex expressions in there, though one can
use the DEBUG_EXPR_DECL temporaries.  So when you for the IV i_18 being removed
notice some debug uses, add something like:
  # DEBUG D#6 => ivtmp.11_20 - ivtmp.11_5
  # DEBUG D#7 => D#6 / 4
  # DEBUG D#8 => (int) D#7
and replace all debug stmt uses of i_18 with D#8.

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[iii at linux dot ibm.com]

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

--- Comment #15 from Ilya Leoshkevich  ---
Created attachment 47059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47059=edit
proposed fix (without renaming the pass so far)

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[iii at linux dot ibm.com]

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

--- Comment #14 from Ilya Leoshkevich  ---
Created attachment 47058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47058=edit
temporary patch for finding out the number of threaded edges

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool  ---
I don't see a patch there?  If you have one, please attach it?

[Bug c++/63287] __STDCPP_THREADS__ is not defined

[alisdairm at me dot com]

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

Alisdair Meredith  changed:

   What|Removed |Added

 CC||alisdairm at me dot com

--- Comment #2 from Alisdair Meredith  ---
*** Bug 92138 has been marked as a duplicate of this bug. ***

[Bug c++/92138] Compiler does not define __CPP_THREADS__ when multiple threads are supported

[alisdairm at me dot com]

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

Alisdair Meredith  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Alisdair Meredith  ---
Sorry - not enough caffeine early morning: the bug is correct but the macro
name is not, that should be __STDCPP_THREADS__ and is a duplicate of 63287.

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

[Bug c++/92138] Compiler does not define __CPP_THREADS__ when multiple threads are supported

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-17
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I agree it has nothing to do with  but I think it depends on the OS,
not the memory model.

[Bug libstdc++/92124] std::vector copy-assigning when it should move-assign.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 17 14:21:27 2019
New Revision: 277113

URL: https://gcc.gnu.org/viewcvs?rev=277113=gcc=rev
Log:
PR libstdc++/92124 fix incorrect container move assignment

The container requirements say that for move assignment "All existing
elements of [the target] are either move assigned or destroyed". Some of
our containers currently use __make_move_if_noexcept which makes the
move depend on whether the element type is nothrow move constructible.
This is incorrect, because the standard says we must move assign, not
move or copy depending on the move constructor.

Use make_move_iterator instead so that we move unconditionally. This
ensures existing elements won't be copy assigned.

PR libstdc++/92124
* include/bits/forward_list.h
(_M_move_assign(forward_list&&, false_type)): Do not use
__make_move_if_noexcept, instead move unconditionally.
* include/bits/stl_deque.h (_M_move_assign2(deque&&, false_type)):
Likewise.
* include/bits/stl_list.h (_M_move_assign(list&&, false_type)):
Likewise.
* include/bits/stl_vector.h (_M_move_assign(vector&&, false_type)):
Likewise.
* testsuite/23_containers/vector/92124.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/23_containers/deque/92124.cc
trunk/libstdc++-v3/testsuite/23_containers/forward_list/92124.cc
trunk/libstdc++-v3/testsuite/23_containers/list/92124.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/92124.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/forward_list.h
trunk/libstdc++-v3/include/bits/stl_deque.h
trunk/libstdc++-v3/include/bits/stl_list.h
trunk/libstdc++-v3/include/bits/stl_vector.h

[Bug debug/90231] ivopts causes iterator in the loop

[amker at gcc dot gnu.org]

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

--- Comment #12 from bin cheng  ---
(In reply to Jakub Jelinek from comment #10)
> Actually (int) ((ivtmp.11 - (unsigned long) dst_10) / 4), sorry.
> On 64-bit targets this will never be a problem, are you worried about 32-bit
> targets where int and pointers are the same width and for a loop with say up
> to INT_MAX iterations ivtmp.11 would wrap around?  Then dst[i] would be
> invalid too.
> So as long as the IVs aren't added there out of the blue sky, with larger
> steps than what is really used, it shouldn't be an issue.
> Or can say a loop that does:
> unsigned int j = x;
> for (int i = 0; i < n; i++)
>   {
> j += 32;
> use (i, j);
>   }
> use j as unsigned int IV with step 32 replace the i int IV with step 1?  If
> yes, then I'd understand that (int) ((j - x) / 32) might not be correct
> expression all the time, e.g. if j == x, then i might be 0, or 0x800
> etc., but (int) ((j - x) / 32) will be 0.

Yes, as mentioned in #11, we need to choose the same class IV in rewriting. 
And reuse of existing code makes it harder, after all, I don't want to disturb
existing code because of debug-stmt rewriting.

[Bug libstdc++/92124] std::vector copy-assigning when it should move-assign.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk.

[Bug debug/90231] ivopts causes iterator in the loop

[amker at gcc dot gnu.org]

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

--- Comment #11 from bin cheng  ---
(In reply to Richard Biener from comment #9)
> (In reply to bin cheng from comment #7)
> > The orignal iv needs to be represented in debug bind stmt is:
> >  64 IV struct:
> >  65   SSA_NAME: i_18
> >  66   Type: int
> >  67   Base: 0
> >  68   Step: 1
> >  69   Biv:  Y
> >  70   Overflowness wrto loop niter: No-overflow
> > 
> > While the possible candidate is:
> > 185 Candidate 8:
> > 186   Var befor: ivtmp.11
> > 187   Var after: ivtmp.11
> > 188   Incr POS: before exit test
> > 189   IV struct:
> > 190 Type:   unsigned long
> > 191 Base:   (unsigned long) dst_10(D)
> > 192 Step:   4
> > 193 Object: (void *) dst_10(D)
> > 194 Biv:N
> > 195 Overflowness wrto loop niter:   Overflow
> > 
> > Strictly speaking, with above information, we can't compute i_18 using
> > ivtmp.11 correctly in all cases, because ivtmp.11 could overflow.  Of
> > course, the overflow-ness in this case could be improved, thus solve the
> > problem.  Or there is another method: we can do the computation anyway, it
> > may give wrong value in some cases, but we are in debug stmt, value which is
> > correct in most cases is better than optimized away, sensible?
> 
> Actually we do know that ivtmp.11 doesn't overflow.
> 
> Since we can express the use of i in dst[i] by the new IV we can express
> i in terms of the new IV at the point of its original use as well, I see
> no way the transform isn't bijective.  The complication here is just
It's bijective if we can choose candidate derived from the same class of
induction variables as "i", however, code rewriting debug-stmt currently
selects cand using simple heuristic, it's not guaranteed cand from right class
would be chosen. 
Also we reuse existing iv_use -> iv_cand computation code in rewriting
debug-stmt.
> that we have to undo the 'use in dst[i]' effect somehow, but for simple
> cases or rewrite_use_* this should be doable.

[Bug c++/92138] New: Compiler does not define __CPP_THREADS__ when multiple threads are supported

[alisdairm at me dot com]

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

Bug ID: 92138
   Summary: Compiler does not define __CPP_THREADS__ when multiple
threads are supported
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alisdairm at me dot com
  Target Milestone: ---

According to [cpp.predefined], the __CPP_THREADS__ macro should be (implicitly)
predefined "if and only if a program can have more than one thread of
execution".

I believe this is entirely dependent on the memory model, and the necessary
ordering guarantees that are likely to impact optimizers etc. (whether data
races are a thing to worry about or not) and totally unrelated to library
support for the  header, etc.

This requirement was added for C++11, but from my attempts at searching
Bugzilla, I have not found any other reports featuring the token
"__CPP_THREADS__", which means either my search skills are sadly wanting, or
this is not a highly requested feature.  My research of other C++11 compilers
suggests that the Intel compiler (EDG front end) and Microsoft compilers
correctly define this macro, and the Clang folks already have bug reports
tracking this.

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[iii at linux dot ibm.com]

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

--- Comment #12 from Ilya Leoshkevich  ---
> Well, it apparently has found new jump threading opportunities after
> partition_blocks.  Are such changes useful?  Does it happen often?

It's still combine that was responsible for this particular opportunity.
I've added a simple counter of threaded edges and built two compiler
versions: with and without the patch from comment 3. The value of the
counter is the same in both cases for the code from this bugreport.

Furthermore, I've built SPEC 2006 and SPEC 2017 with vanilla and patched
compilers and aggregated the counter values.

When doing jump threading right after reload, 3889 edges are threaded.
When doing jump threading right after combine, 3918 edges are threaded.

Both figures are more or less the same, we even end up losing some
opportunities if we delay jump threading.

[Bug target/92137] [ia32] Missing documentation for ia32 builtins

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
  Component|driver  |target

--- Comment #1 from Richard Biener  ---
You shouldn't use those, they are for internal use only.  That's the reason
they are not documented.

[Bug driver/92137] New: [ia32] Missing documentation for ia32 builtins

[arieltorti14 at gmail dot com]

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

Bug ID: 92137
   Summary: [ia32] Missing documentation for ia32 builtins
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arieltorti14 at gmail dot com
  Target Milestone: ---

There are many implemented x86 builtins that are not documented, namely:

__builtin_ia32_bsrsi
__builtin_ia32_bsrdi
__builtin_ia32_rolqi
__builtin_ia32_rolhi
__builtin_ia32_rorqi
__builtin_ia32_rorhi
__builtin_ia32_readeflags_u64
__builtin_ia32_writeeflags_u64
__builtin_ia32_readeflags_u32
__builtin_ia32_writeeflags_u32

I believe all of them should be documented but I may be wrong. 
I can document readeflags and writeeflags builtins if no one else will.

[Bug c++/92136] cc1plus segv with CTAD and -fchecking

[mpolacek at gcc dot gnu.org]

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

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

commit 42decc18f5e1795228b8259de7880d7f676e36c7
Author: jason 
Date:   Tue Feb 28 23:57:09 2017 +

Class template argument deduction refinements

* call.c (joust): Move deduction guide tiebreaker down.
* decl.c (start_decl_1, cp_finish_decl, grokdeclarator): Allow
class
deduction with no initializer.
* pt.c (build_deduction_guide): Handle implicit default/copy ctor.
(do_class_deduction): Use that rather than special case.
(do_auto_deduction): Handle null initializer.

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

before that the testcase compiled fine.

[Bug c++/92136] New: cc1plus segv with CTAD and -fchecking

[mpolacek at gcc dot gnu.org]

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

Bug ID: 92136
   Summary: cc1plus segv with CTAD and -fchecking
   Product: gcc
   Version: 10.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: ---

This testcase, provided by Pilar Latiesa:

template 
class Base {};

template 
class Test : public Base>
{
public:
  Test() = default;

  template  typename T>
  Test(Base> const &) {}
};

int main()
{
  Test<2> const eps;
  Test const omega = eps;
  Test const gamma = omega;

  return 0;
}

causes a segv.  We seem to loop infinitely:

#0  0x00b953ee in structural_comptypes (
t1=, 
t2=, 
strict=)
at /home/marek/src/gcc/gcc/cp/typeck.c:1236
#1  0x00b96f7e in comptypes (t1=, 
t2=, strict=0)
at /home/marek/src/gcc/gcc/cp/typeck.c:1497
#2  0x00aa2181 in comp_template_parms (parms1=, 
parms2=) at /home/marek/src/gcc/gcc/cp/pt.c:3289
#3  0x00b95b71 in structural_comptypes (t1=, 
t2=, strict=0)
at /home/marek/src/gcc/gcc/cp/typeck.c:1325
#4  0x00b96f7e in comptypes (t1=, 
t2=, strict=0)
at /home/marek/src/gcc/gcc/cp/typeck.c:1497
#5  0x00aa2181 in comp_template_parms (parms1=, 
parms2=) at /home/marek/src/gcc/gcc/cp/pt.c:3289
#6  0x00b95b71 in structural_comptypes (t1=, 
t2=, strict=0)
at /home/marek/src/gcc/gcc/cp/typeck.c:1325
#7  0x00b96f7e in comptypes (t1=, 
t2=, strict=0)
at /home/marek/src/gcc/gcc/cp/typeck.c:1497
#8  0x00aa2181 in comp_template_parms (parms1=, 
parms2=) at /home/marek/src/gcc/gcc/cp/pt.c:3289
#9  0x00b95b71 in structural_comptypes (t1=, 
t2=, strict=0)
at /home/marek/src/gcc/gcc/cp/typeck.c:1325
#10 0x00b96f7e in comptypes (t1=, 
t2=, strict=0)
at /home/marek/src/gcc/gcc/cp/typeck.c:1497
#11 0x00aa2181 in comp_template_parms (parms1=, 
parms2=) at /home/marek/src/gcc/gcc/cp/pt.c:3289
#12 0x00b95b71 in structural_comptypes (t1=, 
t2=, strict=0)
at /home/marek/src/gcc/gcc/cp/typeck.c:1325
#13 0x00b96f7e in comptypes (t1=, 
t2=, strict=0)
at /home/marek/src/gcc/gcc/cp/typeck.c:1497
#14 0x00aa2181 in comp_template_parms (parms1=, 
parms2=) at /home/marek/src/gcc/gcc/cp/pt.c:3289
#15 0x00b95b71 in structural_comptypes (t1=, 
t2=, strict=0)
at /home/marek/src/gcc/gcc/cp/typeck.c:1325
[...]

[Bug libfortran/92027] [10 regression] gfortran.dg/ISO_Fortran_binding_10.f90 FAILs – conditional jump based on uninitialized memory in runtime/ISO_Fortran_binding.c

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-17
 CC||burnus at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
Summary|[10 regression] |[10 regression]
   |gfortran.dg/ISO_Fortran_bin |gfortran.dg/ISO_Fortran_bin
   |ding_10.f90 FAILs   |ding_10.f90 FAILs –
   ||conditional jump based on
   ||uninitialized memory in
   ||runtime/ISO_Fortran_binding
   ||.c
 Ever confirmed|0   |1

--- Comment #1 from Tobias Burnus  ---
The only libgfortran change in this range is r276624.

Namely:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00422.html

2019-10-05  Paul Thomas  

PR fortran/91926
* runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Do not
modify the bounds and offset for CFI_other.

The code changed:
-  d->dtype.attribute = (signed short)s->attribute;
+  if (d->dtype.attribute == CFI_attribute_other)
+return;


If I run it with valgrind, it shows:

==24369== Conditional jump or move depends on uninitialised value(s)
==24369==at 0x4A7D63C: _gfortran_cfi_desc_to_gfc_desc
(ISO_Fortran_binding.c:66)

That's the "d->dtype.attribute". Seemingly, it is not guaranteed that "d" is
initialized.


At a glance, I do not see the reason for this change. It looks clearly
unrelated to the test cases and the issue reported in PR fortran/91926.

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Another case

unsigned bar (unsigned int *x)
{
  int sum = 0;
  for (int i = 0; i < 16; ++i)
sum += x[i];
  return sum;
}

where an intermeditate result of the reduction chain is live.

[Bug tree-optimization/92115] [10 Regression] ICE in gimple_cond_get_ops_from_tree, at gimple-expr.c:577

[asolokha at gmx dot com]

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

--- Comment #7 from Arseny Solokha  ---
(In reply to Ilya Leoshkevich from comment #6)
> Did you per chance open-source it?

I didn't, but if you are interested I believe it would be appropriate to
continue the discussion in private for now.

[Bug tree-optimization/92111] [10 Regression] ICE during GIMPLE pass: dom

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez  ---
Please include any flags that were used in building things.  For example, it
looks like it needs at least -std=c++17 to work.

I can't reproduce with a ./cc1plus -O2.  I also can't reproduce with -flto:

./xgcc -B./ a.ii -w -O2 -std=c++17 -flto
/usr/bin/ld: /lib/../lib64/crt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
/usr/bin/ld: /tmp/cczITmdb.ltrans0.ltrans.o:(.qtversion[qt_version_tag]+0x0):
undefined reference to `qt_version_tag'
collect2: error: ld returned 1 exit status

Have you tried with a more recent trunk?

Can you reproduce at all without -flto, as LTO is a bit trickier to debug, and
may require you sending more files.

Can you narrow down the source to the smallest subset that can still reproduce
the bug?

[Bug c++/92134] static constinit members incorrectly compile

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug other/92121] Error using GCC 4.9.4 -- arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y,

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
There is no GCC bug here. Please find a more appropriate place to ask for help
solving your problem (and try to accurately describe that problem -- so far all
you've done is show things that don't work, which is to be expected with GCC
4.9.4).

Try the gcc-help mailing list, or a CentOS forum. Describe the problem you're
trying to solve. Ask for help solving it.

Don't report a bug in GCC just because old versions of GCC don't support new
features from 2018.

[Bug fortran/92122] [coarrays, polymophism] Error 'must be a scalar of type LOCK_TYPE'

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Regarding the discussion of comment 0, see:
https://mailman.j3-fortran.org/pipermail/j3/2019-October/011691.html
https://mailman.j3-fortran.org/pipermail/j3/2019-October/011692.html

"So, the whole argument here seems to hinge on the fact that x%q is not a
“named variable”. Since if it were, it would have to be a coarray.  Also, the
LOCK statement in the example is only locking a local lock.  Which is very
peculiar, but apparently allowed."

and:
"Yes. I don’t think that local-locking is particularly peculiar; the lock is,
after all, accessible to other images because the pointer is associated with a
coarray.
I understand, and agree, that we want to make sure that any lock-variable is
going to be accessible to other images, since that’s the whole point of the
feature. The existing constraints do achieve that, so philosophically they are
fine as is I think.
If on the other hand, we didn’t want to allow this, either we would have to
make some rule for lock_type and pointer components, or in this case we could
make it “useless” by requiring the lock-variable to be a coarray or coindexed."
+
"Oh, and I think similar analysis applies to events,"

→ Hence, unless something changes ("if … we didn't want this"), it is valid.

[Bug tree-optimization/92131] [8/9/10 Regression] incorrect assumption that (ao >= 0) is always false

[aldyh at gcc dot gnu.org]

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

--- Comment #17 from Aldy Hernandez  ---
Author: aldyh
Date: Thu Oct 17 12:38:38 2019
New Revision: 277107

URL: https://gcc.gnu.org/viewcvs?rev=277107=gcc=rev
Log:
PR tree-optimization/92131
* tree-vrp.c (value_range_base::dump): Display +INF for both
pointers and integers when appropriate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/evrp4.c
trunk/gcc/tree-vrp.c

[Bug target/92132] new test case gcc.dg/vect/vect-cond-reduc-4.c fails with its introduction in r277067

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Yes, odd that the comparison is flagged as not vectorizable.

[Bug other/92121] Error using GCC 4.9.4 -- arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y,

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Jonathan Wakely  ---
GCC 4.9 is several years old, it doesn't support those new options.

[Bug debug/90231] ivopts causes iterator in the loop

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Actually (int) ((ivtmp.11 - (unsigned long) dst_10) / 4), sorry.
On 64-bit targets this will never be a problem, are you worried about 32-bit
targets where int and pointers are the same width and for a loop with say up to
INT_MAX iterations ivtmp.11 would wrap around?  Then dst[i] would be invalid
too.
So as long as the IVs aren't added there out of the blue sky, with larger steps
than what is really used, it shouldn't be an issue.
Or can say a loop that does:
unsigned int j = x;
for (int i = 0; i < n; i++)
  {
j += 32;
use (i, j);
  }
use j as unsigned int IV with step 32 replace the i int IV with step 1?  If
yes, then I'd understand that (int) ((j - x) / 32) might not be correct
expression all the time, e.g. if j == x, then i might be 0, or 0x800 etc.,
but (int) ((j - x) / 32) will be 0.

[Bug debug/90231] ivopts causes iterator in the loop

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
(In reply to bin cheng from comment #7)
> The orignal iv needs to be represented in debug bind stmt is:
>  64 IV struct:
>  65   SSA_NAME: i_18
>  66   Type: int
>  67   Base: 0
>  68   Step: 1
>  69   Biv:  Y
>  70   Overflowness wrto loop niter: No-overflow
> 
> While the possible candidate is:
> 185 Candidate 8:
> 186   Var befor: ivtmp.11
> 187   Var after: ivtmp.11
> 188   Incr POS: before exit test
> 189   IV struct:
> 190 Type:   unsigned long
> 191 Base:   (unsigned long) dst_10(D)
> 192 Step:   4
> 193 Object: (void *) dst_10(D)
> 194 Biv:N
> 195 Overflowness wrto loop niter:   Overflow
> 
> Strictly speaking, with above information, we can't compute i_18 using
> ivtmp.11 correctly in all cases, because ivtmp.11 could overflow.  Of
> course, the overflow-ness in this case could be improved, thus solve the
> problem.  Or there is another method: we can do the computation anyway, it
> may give wrong value in some cases, but we are in debug stmt, value which is
> correct in most cases is better than optimized away, sensible?

Actually we do know that ivtmp.11 doesn't overflow.

Since we can express the use of i in dst[i] by the new IV we can express
i in terms of the new IV at the point of its original use as well, I see
no way the transform isn't bijective.  The complication here is just
that we have to undo the 'use in dst[i]' effect somehow, but for simple
cases or rewrite_use_* this should be doable.

And no, debug info that is sometimes incorrect isn't preferable to
.

> Thanks,
> bin

[Bug debug/90231] ivopts causes iterator in the loop

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to bin cheng from comment #7)
> The orignal iv needs to be represented in debug bind stmt is:
>  64 IV struct:
>  65   SSA_NAME: i_18
>  66   Type: int
>  67   Base: 0
>  68   Step: 1
>  69   Biv:  Y
>  70   Overflowness wrto loop niter: No-overflow
> 
> While the possible candidate is:
> 185 Candidate 8:
> 186   Var befor: ivtmp.11
> 187   Var after: ivtmp.11
> 188   Incr POS: before exit test
> 189   IV struct:
> 190 Type:   unsigned long
> 191 Base:   (unsigned long) dst_10(D)
> 192 Step:   4
> 193 Object: (void *) dst_10(D)
> 194 Biv:N
> 195 Overflowness wrto loop niter:   Overflow
> 
> Strictly speaking, with above information, we can't compute i_18 using
> ivtmp.11 correctly in all cases, because ivtmp.11 could overflow.  Of
> course, the overflow-ness in this case could be improved, thus solve the
> problem.  Or there is another method: we can do the computation anyway, it
> may give wrong value in some cases, but we are in debug stmt, value which is
> correct in most cases is better than optimized away, sensible?

I don't understand what kind of overflow you are worried about.
If the original IV didn't overflow, why would (int) ((unsigned long) ivtmp.11 -
(unsigned long) dst_10) ever not be a valid replacement for whatever was in
i_18?  Do you have an example where it would result in wrong-debug?
And yes, wrong-debug is worse than , but we could do things
like use a COND_EXPR in the debug_bind expression, if some condition is true,
use some expression how to compute the value, otherwise signal .
But I don't understand why it would be needed in this case.

[Bug debug/90231] ivopts causes iterator in the loop

[amker at gcc dot gnu.org]

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

--- Comment #7 from bin cheng  ---
The orignal iv needs to be represented in debug bind stmt is:
 64 IV struct:
 65   SSA_NAME: i_18
 66   Type: int
 67   Base: 0
 68   Step: 1
 69   Biv:  Y
 70   Overflowness wrto loop niter: No-overflow

While the possible candidate is:
185 Candidate 8:
186   Var befor: ivtmp.11
187   Var after: ivtmp.11
188   Incr POS: before exit test
189   IV struct:
190 Type:   unsigned long
191 Base:   (unsigned long) dst_10(D)
192 Step:   4
193 Object: (void *) dst_10(D)
194 Biv:N
195 Overflowness wrto loop niter:   Overflow

Strictly speaking, with above information, we can't compute i_18 using ivtmp.11
correctly in all cases, because ivtmp.11 could overflow.  Of course, the
overflow-ness in this case could be improved, thus solve the problem.  Or there
is another method: we can do the computation anyway, it may give wrong value in
some cases, but we are in debug stmt, value which is correct in most cases is
better than optimized away, sensible?

Thanks,
bin

[Bug other/92121] Error using GCC 4.9.4 -- arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y,

[dhgopal at gmail dot com]

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

Dhanagopal Kannaiyan  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #4 from Dhanagopal Kannaiyan  ---

we have tried with a sample program and it compiling & when we try with the
below options during compilation we are getting the below error 



gcc  -mindirect-branch=thunk-extern -mindirect-branch-register  -o Test test.c
gcc: error: unrecognized command line option ‘-mindirect-branch=thunk-extern’
gcc: error: unrecognized command line option ‘-mindirect-branch-register’

can you please help -if we need to configure any to compile with the above
arguments which gcc compilation

[Bug testsuite/92125] New test gcc.dg/ipa/pr91088.c introduced in r277054 fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/92134] static constinit members incorrectly compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-17
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/91369] Implement P0784R7: constexpr new

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Ok, so do I need to somehow mark the CALL_EXPR created from new/delete lowering
and only treat calls to global replaceable allocator/deallocator functions
specially if they either have this flag or are in allocate//deallocate method
of std::allocator template?  And similarly perhaps do something for the
placement new in std::construct_at etc.?

[Bug testsuite/92125] New test gcc.dg/ipa/pr91088.c introduced in r277054 fails

[fxue at gcc dot gnu.org]

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

--- Comment #2 from fxue at gcc dot gnu.org ---
Author: fxue
Date: Thu Oct 17 09:55:37 2019
New Revision: 277095

URL: https://gcc.gnu.org/viewcvs?rev=277095=gcc=rev
Log:
PR testsuite/92125

2019-10-17  Feng Xue  

PR testsuite/92125
* gcc.dg/ipa/pr91088.c: Change char conversion to bitand.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/pr91088.c

[Bug target/92135] New: Implement popcountsi expansion for arm

[ktkachov at gcc dot gnu.org]

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

Bug ID: 92135
   Summary: Implement popcountsi expansion for arm
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: arm*

On aarch64 we can do SImode and DImode popcount operations using the AdvSIMD
CNT instruction. As the comment in aarch64.md says:
;; Pop count be done via the "CNT" instruction in AdvSIMD.
;;
;; MOV  v.1d, x0
;; CNT  v1.8b, v.8b
;; ADDV b2, v1.8b
;; MOV  w0, v2.b[0]

We should be able to do a similar thing on arm, using the VCNT instruction.
This just needs implementing as an expansion in arm.md.
int
foocnt (int a)
{
  return __builtin_popcount (a);
}

is the trivial testcase.
Haven't thought too much about the DImode case, but perhaps that can also be
accelerated in similar ways

[Bug tree-optimization/92111] [10 Regression] ICE during GIMPLE pass: dom

[jan at jki dot io]

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

Jan  changed:

   What|Removed |Added

  Attachment #47043|0   |1
is obsolete||

--- Comment #4 from Jan  ---
Created attachment 47057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47057=edit
preprocessed source

wrong initial tarball

[Bug tree-optimization/92115] [10 Regression] ICE in gimple_cond_get_ops_from_tree, at gimple-expr.c:577

[iii at linux dot ibm.com]

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

--- Comment #6 from Ilya Leoshkevich  ---
> Am 16.10.2019 um 16:32 schrieb asolokha at gmx dot com 
> :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92115
> 
> --- Comment #4 from Arseny Solokha  ---
> (In reply to Ilya Leoshkevich from comment #3)
>> Arseny, how did you find this? Did you just run the regtest? I wonder why
>> didn't I see it during my test runs.
> 
> My test harness continuously compiles a corpus of C, C++, and Fortran code 
> with
> the latest weekly trunk snapshot, picking a random set of compiler options and
> parameters for each file. gcc and libstdc++ test suites constitute an 
> important
> part of that corpus. When compiling files from these test suites, my test
> harness ignores compiler options specified there for DejaGNU and uses its own
> randomly chosen ones instead. Of course, this approach is not suitable for
> testing run-time correctness.
> 
> So, if there are no testcases in the test suite yet which could trigger that
> specific code path in gcc internals, probably due to an unusual set of 
> compiler
> options, your testing won't reveal a problem reported here. That is probably
> OK, as regression testing have to be deterministic, after all.

Hi Arseny,

Did you per chance open-source it?

Best regards,
Ilya

[Bug tree-optimization/92131] [8/9/10 Regression] incorrect assumption that (ao >= 0) is always false

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |8.4
Summary|incorrect assumption that   |[8/9/10 Regression]
   |(ao >= 0) is always false   |incorrect assumption that
   ||(ao >= 0) is always false

--- Comment #16 from Jakub Jelinek  ---
At least on the #c0 testcase with -O2 this started with r254954, but has been
latent before (as in, I believe intersection with a non-VARYING range and these
, sym - 1 upper bound would run into the same issue).
I'm afraid I'm not familiar with symbolic handling in VRP enough, so will not
work on this PR further and will defer to those that are familiar with it.

[Bug tree-optimization/92131] incorrect assumption that (ao >= 0) is always false

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  ---
> We cannot really add range bounds to symbolics because those bounds
> are not added in the IL and thus those adds are prone to overflowing.

Yes, the issue is very likely in the way we use combine_bound.

[Bug tree-optimization/92131] incorrect assumption that (ao >= 0) is always false

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou  ---
> Perhaps, but it would still be called for
> long int [-9223372036854775805, +INF] + long int [-INF, e.7_8 + -1], for
> which it would still end up with long int [-INF, e.7_8 +
> 9223372036854775806].

Why is the lower bound not caught in extract_range_from_plus_minus_expr?

  /* Build the bounds.  */
  combine_bound (code, wmin, min_ovf, expr_type, min_op0, min_op1);
  combine_bound (code, wmax, max_ovf, expr_type, max_op0, max_op1);

  /* If we have overflow for the constant part and the resulting
 range will be symbolic, drop to VR_VARYING.  */
  if (((bool)min_ovf && sym_min_op0 != sym_min_op1)
  || ((bool)max_ovf && sym_max_op0 != sym_max_op1))
{
  vr->set_varying (expr_type);
  return;
}

[Bug c++/92134] New: static constinit members incorrectly compile

[vincent.hamp at higaski dot at]

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

Bug ID: 92134
   Summary: static constinit members incorrectly compile
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent.hamp at higaski dot at
  Target Milestone: ---

The new C++20 constinit specifier currently doesn't seem to work with static
data members.

The following snippet compiles although the constructor of Value calls new.

struct Value {
  Value() : v{new int{42}} {}
  int* v;
};

struct S {
  static constinit inline Value v{};
};

int main() { return *S::v.v; }

[Bug tree-optimization/92131] incorrect assumption that (ao >= 0) is always false

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Thu, 17 Oct 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
> 
> --- Comment #12 from Jakub Jelinek  ---
> (In reply to Eric Botcazou from comment #11)
> > > From what I can see, the weird + 0x7ffe is created when
> > > extract_range_from_plus_minus_expr is called with PLUS_EXPR and VARYING 
> > > and
> > > long int [-INF, e.7_8 + -1] ranges.
> > >   /* Build the symbolic bounds if needed.  */
> > >   adjust_symbolic_bound (min, code, expr_type,
> > >  sym_min_op0, sym_min_op1,
> > >  neg_min_op0, neg_min_op1);
> > >   adjust_symbolic_bound (max, code, expr_type,
> > >  sym_max_op0, sym_max_op1,
> > >  neg_max_op0, neg_max_op1);
> > > in there.  max_op0 is 9223372036854775807 (maximum of VARYING), and 
> > > max_op1
> > > is -1 (which is not the upper bound, just an offset against the symbolic).
> > > combine_bound adds this into wmax, so 9223372036854775807 + -1 gives
> > > 0x7ffe and that is what is used.
> > 
> > This looks like the bug, i.e. combine_bound shouldn't be called on VARYING.
> 
> Perhaps, but it would still be called for
> long int [-9223372036854775805, +INF] + long int [-INF, e.7_8 + -1], for which
> it would still end up with long int [-INF, e.7_8 + 9223372036854775806].

We cannot really add range bounds to symbolics because those bounds
are not added in the IL and thus those adds are prone to overflowing.

We can only do

 _1 = _2 + 1;


with _2 = [ -1, _3 + 4]

derive _1 = [ 0, _3 + 5]

but not for

 _1 = _2 + _4;

with _4 = [ 0, 1 ]

derive _1 = [ -1, _3 + 5]

Richard.

[Bug ipa/92133] New: Support multi versioning on self recursive function

[fxue at os dot amperecomputing.com]

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

Bug ID: 92133
   Summary: Support multi versioning on self recursive function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

For recursive function, IPA does not allow constant propagation on parameter
that is used to control recursion. It is common that the parameter is inc/dec
(arithmetic op) a constant before entering next recursion. The following
example gives a general source code pattern.

int recur_fn (int i)
{
  if (i == 6)
{
  do_work ();
  return 0;
}

  do_prepare ();

  recur_fn (i + 1);

  do_post ();

  return 0;
}

int foo()
{
  ...
  recur_fn (1);
  ...
}

A straight forward optimization is to duplicate recur_fn () 6 times, which
constitute a calling chain on the specialized copies as:

  recur_fn() -> recur_fn() -> ... -> recur_fn()

[Bug tree-optimization/92131] incorrect assumption that (ao >= 0) is always false

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Eric Botcazou from comment #11)
> > From what I can see, the weird + 0x7ffe is created when
> > extract_range_from_plus_minus_expr is called with PLUS_EXPR and VARYING and
> > long int [-INF, e.7_8 + -1] ranges.
> >   /* Build the symbolic bounds if needed.  */
> >   adjust_symbolic_bound (min, code, expr_type,
> >  sym_min_op0, sym_min_op1,
> >  neg_min_op0, neg_min_op1);
> >   adjust_symbolic_bound (max, code, expr_type,
> >  sym_max_op0, sym_max_op1,
> >  neg_max_op0, neg_max_op1);
> > in there.  max_op0 is 9223372036854775807 (maximum of VARYING), and max_op1
> > is -1 (which is not the upper bound, just an offset against the symbolic).
> > combine_bound adds this into wmax, so 9223372036854775807 + -1 gives
> > 0x7ffe and that is what is used.
> 
> This looks like the bug, i.e. combine_bound shouldn't be called on VARYING.

Perhaps, but it would still be called for
long int [-9223372036854775805, +INF] + long int [-INF, e.7_8 + -1], for which
it would still end up with long int [-INF, e.7_8 + 9223372036854775806].

[Bug tree-optimization/92131] incorrect assumption that (ao >= 0) is always false

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> From what I can see, the weird + 0x7ffe is created when
> extract_range_from_plus_minus_expr is called with PLUS_EXPR and VARYING and
> long int [-INF, e.7_8 + -1] ranges.
>   /* Build the symbolic bounds if needed.  */
>   adjust_symbolic_bound (min, code, expr_type,
>  sym_min_op0, sym_min_op1,
>  neg_min_op0, neg_min_op1);
>   adjust_symbolic_bound (max, code, expr_type,
>  sym_max_op0, sym_max_op1,
>  neg_max_op0, neg_max_op1);
> in there.  max_op0 is 9223372036854775807 (maximum of VARYING), and max_op1
> is -1 (which is not the upper bound, just an offset against the symbolic).
> combine_bound adds this into wmax, so 9223372036854775807 + -1 gives
> 0x7ffe and that is what is used.

This looks like the bug, i.e. combine_bound shouldn't be called on VARYING.

[Bug tree-optimization/92129] [10 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:5869

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 17 07:39:37 2019
New Revision: 277094

URL: https://gcc.gnu.org/viewcvs?rev=277094=gcc=rev
Log:
2019-10-17  Richard Biener  

PR tree-optimization/92129
* tree-vect-loop.c (vectorizable_reduction): Also fail
on GIMPLE_SINGLE_RHS.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/92129] [10 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:5869

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/92111] [10 Regression] ICE during GIMPLE pass: dom

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez  ---
There is no pre-processed file in the tar file:

$ tar tvf ~/Download/preprocessed.tar.bz2 
-rw-r--r-- root/root   1067433 2019-10-15 20:36
libKF5JsEmbed.so.5.63.0.ltrans6.o
-rw-r--r-- root/root38 2019-10-15 20:43
libKF5JsEmbed.so.5.63.0.ltrans6.s

Could you attach one please?