[Bug preprocessor/98021] #warning issues redundant diagnostic lines

2020-11-29 Thread schwab--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98021

--- Comment #16 from Andreas Schwab  ---
There is no difference between these cases.  GCC will always show the source
lines that are available.  Of course, it will never pull anything out of thin
air, but that is obvious.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

2020-11-29 Thread pipcet at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #18 from pipcet at gmail dot com ---
Sorry for only getting back to this now.

I release all code on this branch into the public domain, if it helps at all.
I'm happy to add whatever legal attribution is needed for that.

I'm willing to help where I can, but please understand I've had to abandon this
due to an unfortunate combination of family and health issues. I'm sorry about
that.

[Bug c/98049] New: False positive when compiling with -Os -Wmaybe-uninitialized

2020-11-29 Thread ahmad at a3f dot at via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98049

Bug ID: 98049
   Summary: False positive when compiling with -Os
-Wmaybe-uninitialized
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ahmad at a3f dot at
  Target Milestone: ---

Created attachment 49642
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49642&action=edit
C Source reproducing the erroneous warning

gcc -Os warns that "'start' may be used uninitialized in this function
[-Wmaybe-uninitialized]" in this snippet:

unsigned start;

if (timeout)
start = get_time();
while (!active()) {
if (timeout && is_timeout(start, timeout))
   ~~^~~~
return 1;
}

This is wrong, because `start' is only evaluated when `timeout' != 0
at which time it's always initialized. `timeout' is automatic storage and can't
change in-between.

The warning vanishes if -Os is removed or code around is moved.

Steps to reproduce (or check https://godbolt.org/z/3qf58T):

$ cc minim.c -c -Os -Wmaybe-uninitialized

: In function 'void f(int, unsigned int)':
:12:42: warning: 'start' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   12 | if (timeout && is_timeout(start, timeout))
  |~~^~~~
:7:18: note: 'start' was declared here
7 | unsigned start;
  |  ^

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

2020-11-29 Thread abebeos at lazaridis dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #19 from abebeos at lazaridis dot com ---
pipcet, thank you for your quick response (both here and within email).

I think all here will agree that there's no need to apologize, as family/health
should always come first.

As for your work, if all goes fine, then I'll have validated your patch
tomorrow, so "The Last 2%" of the work can start. One or two more days and I
can make my local dev-system reproducible, so anyone can jump in to run the
tests and try to spot things.

I believe that it should be you (pipcet) that sends the final patch in (even if
I do modifications), but if you cannot do it, then "placing you initial patch
under public domain" should enable me to send a modified version in.

Now, going on, trying to keep the self-declared deadline (5th Dec. 2020).

[Bug target/98045] [11 Regression] ICE in compute_fn_summary, at ipa-fnsummary.c:3138 on powerpc64le-linux-gnu

2020-11-29 Thread doko at debian dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98045

Matthias Klose  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu   |powerpc64le-linux-gnu
   ||aarch64-linux-gnu

--- Comment #1 from Matthias Klose  ---
also seen on aarch64-linux-gnu

[Bug target/98045] [11 Regression] ICE in compute_fn_summary, at ipa-fnsummary.c:3138 on powerpc64le-linux-gnu

2020-11-29 Thread doko at debian dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98045

--- Comment #2 from Matthias Klose  ---
Created attachment 49643
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49643&action=edit
preprocessed source

[Bug c/98050] New: in logical_combine, at gimple-range-gori.cc:754

2020-11-29 Thread haoxintu at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98050

Bug ID: 98050
   Summary: in logical_combine, at gimple-range-gori.cc:754
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

[Bug target/98045] [11 Regression] ICE in compute_fn_summary, at ipa-fnsummary.c:3138 on powerpc64le-linux-gnu

2020-11-29 Thread doko at debian dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98045

--- Comment #3 from Matthias Klose  ---
Created attachment 49644
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49644&action=edit
range-op.gcda

[Bug d/87788] Support D on x86_64-apple-darwin*

2020-11-29 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r11-5516-gf59be8dfbd85a7f8face7340950503750a8bfddb
Author: Iain Buclaw 
Date:   Sun Nov 29 12:49:52 2020 +0100

d: Remove d_size_t from front-end sources (PR 87788)

The typedef for d_size_t assumes that the implementation of the
front-end is written in D itself, where size_t can map only to uint32_t
or uint64_t.  As that is not the case for the current D front-end, the
typedef should be removed. This would fix the bootstrap on targets where
in C++ size_t is a long, such as darwin i386.

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

gcc/d/ChangeLog:

PR d/87788
* dmd/MERGE: Merge upsream dmd 45fa6cfd2.

[Bug c/98051] New: ICE in logical_combine, at gimple-range-gori.cc:754 in O2-Os

2020-11-29 Thread haoxintu at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98051

Bug ID: 98051
   Summary: ICE in logical_combine, at gimple-range-gori.cc:754 in
O2-Os
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi all. The small.cc makes GCC-trunk crash under O2~Os, while O0-O1 is fine.

$cat small.c
#include 
void a(int b) {
  uint8_t c;
  int32_t d;
  for (;;)
if (c >= ((b == (d == d)) > !b)) {
  int32_t e[] = {};
}
}

$gcc-trunk -O2 -c small.c
during GIMPLE pass: evrp
small.c: In function ‘a’:
small.c:9:1: internal compiler error: in logical_combine, at
gimple-range-gori.cc:754
9 | }
  | ^
0x6667df gori_compute::logical_combine(irange&, tree_code, irange const&,
tf_range const&, tf_range const&)
../../gcc/gimple-range-gori.cc:754
0x14d37cc gori_compute_cache::cache_stmt(gimple*)
../../gcc/gimple-range-gori.cc:1314
0x14d3bd1 gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
../../gcc/gimple-range-gori.cc:1279
0x14d15a1 gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*)
../../gcc/gimple-range-gori.cc:903
0x14d3b7c gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*)
../../gcc/gimple-range-gori.cc:575
0x14d3b7c gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
../../gcc/gimple-range-gori.cc:1276
0x14d16ba gori_compute::compute_operand2_range(irange&, gimple*, irange const&,
tree_node*)
../../gcc/gimple-range-gori.cc:936
0x14d3b7c gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*)
../../gcc/gimple-range-gori.cc:575
0x14d3b7c gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
../../gcc/gimple-range-gori.cc:1276
0x14d25a7 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*)
../../gcc/gimple-range-gori.cc:1001
0x14cf26c ranger_cache::iterative_cache_update(tree_node*)
../../gcc/gimple-range-cache.cc:636
0x14cfc0c ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
../../gcc/gimple-range-cache.cc:808
0x14d01bf ranger_cache::block_range(irange&, basic_block_def*, tree_node*,
bool)
../../gcc/gimple-range-cache.cc:589
0x14c935a gimple_ranger::range_on_entry(irange&, basic_block_def*, tree_node*)
../../gcc/gimple-range.cc:875
0x14c98a8 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../gcc/gimple-range.cc:846
0x14caad9 gimple_ranger::range_of_range_op(irange&, gimple*)
../../gcc/gimple-range.cc:418
0x14cce97 gimple_ranger::calc_stmt(irange&, gimple*, tree_node*)
../../gcc/gimple-range.cc:369
0x14cd355 gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
../../gcc/gimple-range.cc:952
0x14c9918 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../gcc/gimple-range.cc:843
0xdc69c5 range_query::value_of_expr(tree_node*, gimple*)
../../gcc/value-query.cc:85
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/tuhaoxin/compilers/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/tuhaoxin/compilers/gcc/build/
--enable-bootstrap --enable-checking=release --enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201007 (experimental) (GCC)

[Bug c/98050] in logical_combine, at gimple-range-gori.cc:754

2020-11-29 Thread haoxintu at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98050

Haoxin Tu  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Haoxin Tu  ---
Sorry for the mistake

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

[Bug c/98051] ICE in logical_combine, at gimple-range-gori.cc:754 in O2-Os

2020-11-29 Thread haoxintu at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98051

--- Comment #1 from Haoxin Tu  ---
*** Bug 98050 has been marked as a duplicate of this bug. ***

[Bug fortran/98046] lock in libpthread occurs with gcc-fortran and atlas-lapack

2020-11-29 Thread anthony.debeus at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98046

--- Comment #3 from Anthony M de Beus  ---
Very interesting discussion in bug 30617. Particularly the view that

"If you compile code with undefined behavior in it, run it and that code
crashes, hangs or formats your disk, that is a bug in the code you are running,
not in the compiler.  Anything can happen when you invoke undefined behavior.
And anything includes hanging, segfault, formatting your disk etc."

or 

"It appears that the code is invalid Fortran, so gfortran can do anything"

Yes, but should it?

If you take the view that the compiler is working perfectly if it compiles
correct code correctly, then that make sense.  However, if the compiler's job
is also understood to check code for problems, hence compiler flags to check
bounds, or issue warnings, eg -Wall, then the current situation vis a vis
nested calls to io seems inadequate.  Surely we don't want a compiler that
rewards relatively subtle and hard to isolate bugs by formatting the hard disk!

On the other hand, if the correct compiler behavior is to hang the program with
the nested io calls, then shouldn't it do it consistently?  

Ignoring the invalid io call most of the time but only hanging when a
particular version of a library (which isn't even invoked) is linked is
unpredictable behavior by the compiler, IMO.  

Comment 41 in the duplicate thread seems quite apropos and prescient.
Thank you both for very informative anf helpful comments.

[Bug c++/98052] New: Allocation with new and deallocation with std::allocator should result in an error

2020-11-29 Thread src at andyf dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98052

Bug ID: 98052
   Summary: Allocation with new and deallocation with
std::allocator should result in an error
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: src at andyf dot de
  Target Milestone: ---

Hello,

the following code compiles without an error (https://godbolt.org/z/oPG8Ea) in
GCC:


#include 

constexpr auto fun()
{
int* i = new int{4};

std::allocator a{};
a.deallocate(i, 1);

return 0;
}

int main()
{
constexpr auto f = fun();
}


In the constexpr function fun, an int is allocated with new and free'd with
std::allocator's deallocate. According to N4868 [allocator.members] p6, a
precondition for deallocate is that the memory was previously allocated with
allocate. Clang does reject the code with:

note: 'std::allocator<...>::deallocate' used to delete pointer to object
allocated with 'new'

The behavior of Clang seems to be consistent with the wording. GCC incorrectly
allows this code to compile.


Best,

   Andreas

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

2020-11-29 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504

--- Comment #38 from CVS Commits  ---
The master branch has been updated by John David Anglin :

https://gcc.gnu.org/g:4612c4d09d7d18a6c6345b57a9bb5e249b182fa4

commit r11-5519-g4612c4d09d7d18a6c6345b57a9bb5e249b182fa4
Author: John David Anglin 
Date:   Sun Nov 29 15:57:40 2020 +

Fix PR ada/97504 on hppa*-*-hpux*.

2020-11-29  John David Anglin  

gcc/ada/
PR ada/97504
* Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Use wraplf
version of Aux_Long_Long_Float.

[Bug fortran/98016] Host association problem

2020-11-29 Thread pault at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Status|WAITING |NEW

--- Comment #6 from Paul Thomas  ---
Created attachment 49645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49645&action=edit
Fix for the PR

This fix is rather different to Steve's. It exploits the existing mechanism for
formal arguments. In this context, the function result is equivalent to formal
arguments.

It even regtests OK :-)

Unless there are objections, I will commit as 'obvious' after I fix the last of
the nits with PR83118 or, at least, towards the end of the week.

Cheers

Paul

[Bug c/98051] ICE in logical_combine, at gimple-range-gori.cc:754 in O2-Os

2020-11-29 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98051

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-29
 Ever confirmed|0   |1
 CC||hjl.tools at gmail dot com
 Status|UNCONFIRMED |WAITING

--- Comment #2 from H.J. Lu  ---
(In reply to Haoxin Tu from comment #0)
> Hi all. The small.cc makes GCC-trunk crash under O2~Os, while O0-O1 is fine.
> 
> gcc version 11.0.0 20201007 (experimental) (GCC)

I can't produce with 

gcc version 11.0.0 20201128 (experimental) [master revision
b1adbc27c4a:406d9d6a006:8e59ff5541889817a160afda130bcbcdb70c4b90] (GCC) 

Please try the current master branch.

[Bug tree-optimization/98048] [11 Regression] ICE in build_vector_from_val, at tree.c:1985 by r11-5429

2020-11-29 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98048

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |tree-optimization

--- Comment #2 from Uroš Bizjak  ---
The patch exposed a bug in generic vector handling code.

We have:

  if (op >= FIRST_NORM_OPTAB && op <= LAST_NORM_OPTAB
  && optab_handler (op, TYPE_MODE (TREE_TYPE (type))) !=
CODE_FOR_nothing)

where abs_optab in E_HImode enables this condition.

There is nothing wrong with the patch itself.

[Bug testsuite/26183] setting environment variables in test cases

2020-11-29 Thread tkoenig at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26183

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
This is now possible using dg-set-target-env-var .

[Bug fortran/98053] New: Add Fortran tests for behavior from environment variables

2020-11-29 Thread tkoenig at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98053

Bug ID: 98053
   Summary: Add Fortran tests for behavior from environment
variables
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

There is dg-set-target-env-var , which we could use to check that
the runtime behavior which depends on environment variables is
indeed OK.

[Bug c++/98054] New: ICE: in pp_cxx_trait_expression, at cp/cxx-pretty-print.c:2671

2020-11-29 Thread foss at grueninger dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98054

Bug ID: 98054
   Summary: ICE: in pp_cxx_trait_expression, at
cp/cxx-pretty-print.c:2671
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foss at grueninger dot de
  Target Milestone: ---

Created attachment 49646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49646&action=edit
Dumped file with -save-temps

When compiling a C++ project with G++11, that works fine with G++ 10 and
Clang++, I get the following output:

In file included from
/home/kiko/dune/complete/dune-functions/dune/functions/common/test/polymorphicsmallobjecttest.cc:7:
/home/kiko/dune/complete/dune-functions/dune/functions/common/polymorphicsmallobject.hh:
In instantiation of ‘class Dune::Functions::PolymorphicSmallObject’:
/usr/include/c++/11/type_traits:971:25:   in pp_cxx_trait_expression, at
cp/cxx-pretty-print.c:2671
   44 | class PolymorphicSmallObject
  |   ^~
0x7f4b1a4c4349 __libc_start_main
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

More details regarding my G++ 11:
>g++-11 -v
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d
--enable-offload-targets=nvptx-none=/usr/nvptx-none,amdgcn-amdhsa=/usr/amdgcn-amdhsa,
--without-cuda-driver --enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201127 (experimental) [revision
67138ea1b041fe1637da6b3568f064f172d9358c] (SUSE Linux)

== How to reproduce ==
With -save-temps I dumped the file and attached it. With the following command
line, I can reproduce the problem:
> /usr/bin/g++-11 -DENABLE_MPI=1 -DENABLE_SUITESPARSE=1 -DENABLE_SUPERLU=1 
> -DENABLE_TBB=1 -DENABLE_UG=1 -DHAVE_CONFIG_H -DMETIS_API_VERSION=5 
> -DMPICH_SKIP_MPICXX -DMPIPP_H -DMPI_NO_CPPBIND -DModelP -DOMPI_SKIP_MPICXX 
> -DUG_USE_NEW_DIMENSION_DEFINES -D_TBB_CPP0X 
> -I/home/kiko/dune/complete/dune-functions/build-cmake 
> -I/home/kiko/dune/complete/dune-functions -I/usr/include/python3.6m 
> -I/home/kiko/dune/complete/dune-common -I/home/kiko/dune/complete/dune-uggrid 
> -I/home/kiko/dune/complete/dune-geometry -I/home/kiko/dune/complete/dune-grid 
> -I/home/kiko/dune/complete/dune-typetree -I/home/kiko/dune/complete/dune-istl 
> -I/home/kiko/dune/complete/dune-localfunctions -isystem 
> /usr/lib64/mpi/gcc/openmpi/include -isystem /usr/include/suitesparse -isystem 
> /home/kiko/dune/zusatz/parmetis-4.0.3/include -isystem 
> /home/kiko/dune/zusatz/metis-5.1.0/include -std=c++17  -Wall -Wunused 
> -Wmissing-include-dirs -Wcast-align -Wno-sign-compare -Wno-cast-align -Wall 
> -pedantic -Wno-inconsistent-missing-override -O2 -Wno-unused-parameter 
> -fno-strict-aliasing -fstrict-overflow -g -fPIE -pthread -o 
> CMakeFiles/polymorphicsmallobjecttest.dir/polymorphicsmallobjecttest.cc.o -c 
> polymorphicsmallobjecttest.cc.ii

[Bug c/98055] New: __builtin_alloca should not have warn_unused_result attribute

2020-11-29 Thread psmith at gnu dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055

Bug ID: 98055
   Summary: __builtin_alloca should not have warn_unused_result
attribute
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: psmith at gnu dot org
  Target Milestone: ---

Code that wants to use alloca() and still be portable will often include
replacements where memory is allocated on the heap, and the user is expected to
invoke alloca(0) periodically to free up this memory.  See for example the GNU
gnulib replacement alloca().

(Please no comments about the usefulness or not of alloca()--I'm not interested
in that discussion.  alloca() has problems but it's strictly more powerful than
VLAs, while providing the possibility of portability to compilers that don't
support them).

In this situation (invoking alloca(0)) there's no point in assigning the return
value, and older versions of GCC this works fine but when I try to compile the
same code with GCC 10.2.0 compilation fails because apparently
__builtin_alloca() now has the warn_unused_result attribute applied to it (this
isn't documented anywhere that I can find, but appears to be the case):

In file included from src/makeint.h:31,
 from src/read.c:17:
src/read.c: In function 'eval_makefile':
lib/alloca.h:46:18: error: ignoring return value of '__builtin_alloca' declared
with attribute 'warn_unused_result' [-Werror=unused-result]
   46 | #  define alloca __builtin_alloca
src/read.c:435:3: note: in expansion of macro 'alloca'
  435 |   alloca (0);
  |   ^~

Because (void) doesn't work around this attribute there's no easy way to
resolve this; I don't think it's appropriate to add this attribute to alloca()
and it should be removed.

[Bug c++/98056] New: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862

2020-11-29 Thread lemourin at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056

Bug ID: 98056
   Summary: internal compiler error: tree check: expected
record_type or union_type or qual_union_type, have
array_type in build_special_member_call, at
cp/call.c:9862
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lemourin at gmail dot com
  Target Milestone: ---

Created attachment 49647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49647&action=edit
preprocessor output; compressed

The attached .ii file causes:

internal compiler error: tree check: expected record_type or union_type or
qual_union_type, have array_type in build_special_member_call, at
cp/call.c:9862

The compiler used is built at head (commit f59be8dfbd85..) with default
configure flags on Ubuntu 20.04 running in WSL 1. Same issue occurs with
g++-10, g++-9 shipped with the distro.

The compiler flags used:

-fcoroutines -std=gnu++2a

Same code works well on latest clang and msvc.

The issue can be worked around by modifying calls to util::FetchJson in
GoogleDrive class in a way:

util::FetchJson(Request<>{ ... }, ...)

change to

auto request = ...;
util::FetchJson(std::move(request), ...)

[Bug c++/98056] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862

2020-11-29 Thread lemourin at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056

--- Comment #1 from Paweł Wegner  ---
Created attachment 49648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49648&action=edit
error log

[Bug c/98055] __builtin_alloca should not have warn_unused_result attribute

2020-11-29 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055

--- Comment #1 from Andrew Pinski  ---
See the thread starting at:
https://gcc.gnu.org/pipermail/gcc-patches/2019-June/523700.html

[Bug d/87788] Support D on x86_64-apple-darwin*

2020-11-29 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:2fdf75cb70d6bedd855205d6b05bbf6afac46730

commit r11-5521-g2fdf75cb70d6bedd855205d6b05bbf6afac46730
Author: Iain Buclaw 
Date:   Sat Nov 28 19:38:52 2020 +0100

configure: Support building D front-end on *-*-darwin*

The bootstrap has been confirmed to be succeeding, there's no need to
set it as an unsupported language.

ChangeLog:

PR d/87788
* configure.ac: Don't disable D for *-*-darwin*.
* configure: Regenerate.

[Bug d/87788] Support D on x86_64-apple-darwin*

2020-11-29 Thread egallager at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788

--- Comment #20 from Eric Gallager  ---
(In reply to CVS Commits from comment #19)
> The master branch has been updated by Iain Buclaw :
> 
> https://gcc.gnu.org/g:2fdf75cb70d6bedd855205d6b05bbf6afac46730
> 
> commit r11-5521-g2fdf75cb70d6bedd855205d6b05bbf6afac46730
> Author: Iain Buclaw 
> Date:   Sat Nov 28 19:38:52 2020 +0100
> 
> configure: Support building D front-end on *-*-darwin*
> 
> The bootstrap has been confirmed to be succeeding, there's no need to
> set it as an unsupported language.
> 
> ChangeLog:
> 
> PR d/87788
> * configure.ac: Don't disable D for *-*-darwin*.
> * configure: Regenerate.

This should get a note in the changes.html file for GCC 11

[Bug c++/98057] New: ICE when build clang

2020-11-29 Thread euloanty at live dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98057

Bug ID: 98057
   Summary: ICE when build clang
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

|   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
[1031/4271] Building CXX object
lib/DebugInfo/PDB/CMakeFiles/LLVMDebugInfoPDB.dir/Native/PDBFileBuilder.cpp.o
In file included from ../include/llvm/DebugInfo/PDB/Native/HashTable.h:12,
 from ../include/llvm/DebugInfo/PDB/Native/NamedStreamMap.h:16,
 from ../include/llvm/DebugInfo/PDB/Native/PDBFileBuilder.h:15,
 from ../lib/DebugInfo/PDB/Native/PDBFileBuilder.cpp:9:
../include/llvm/ADT/SparseBitVector.h: In member function 'void
llvm::pdb::PDBFileBuilder::commitSrcHeaderBlock(llvm::WritableBinaryStream&,
const llvm::msf::MSFLayout&)':
../include/llvm/ADT/SparseBitVector.h:129:15: warning: array subscript 2 is
above array bounds of 'const BitWord [2]' {aka 'const long unsigned int [2]'}
[-Warray-bounds]
  129 |   if (Bits[i] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
../include/llvm/ADT/SparseBitVector.h: In member function 'void
llvm::pdb::HashTable::grow(TraitsT&) [with TraitsT =
llvm::pdb::StringTableHashTraits; ValueT = llvm::pdb::SrcHeaderBlockEntry]':
../include/llvm/ADT/SparseBitVector.h:129:15: warning: array subscript 2 is
above array bounds of 'const BitWord [2]' {aka 'const long unsigned int [2]'}
[-Warray-bounds]
  129 |   if (Bits[i] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
../include/llvm/ADT/SparseBitVector.h: In member function 'llvm::Error
llvm::pdb::PDBFileBuilder::finalizeMsfLayout()':
../include/llvm/ADT/SparseBitVector.h:138:15: warning: array subscript
4294967295 is above array bounds of 'const BitWord [2]' {aka 'const long
unsigned int [2]'} [-Warray-bounds]
  138 |   if (Bits[Idx] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
../include/llvm/ADT/SparseBitVector.h:138:15: warning: array subscript
4294967295 is above array bounds of 'const BitWord [2]' {aka 'const long
unsigned int [2]'} [-Warray-bounds]
  138 |   if (Bits[Idx] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
[1035/4271] Building CXX object
lib/DebugInfo/PDB/CMakeFiles/LLVMDebugInfoPDB.dir/Native/TpiStream.cpp.o
In file included from ../include/llvm/DebugInfo/PDB/Native/HashTable.h:12,
 from ../include/llvm/DebugInfo/PDB/Native/TpiStream.h:13,
 from ../lib/DebugInfo/PDB/Native/TpiStream.cpp:9:
../include/llvm/ADT/SparseBitVector.h: In member function 'llvm::Error
llvm::pdb::HashTable::load(llvm::BinaryStreamReader&) [with ValueT =
llvm::support::detail::packed_endian_specific_integral]':
../include/llvm/ADT/SparseBitVector.h:129:15: warning: array subscript 2 is
above array bounds of 'const BitWord [2]' {aka 'const long unsigned int [2]'}
[-Warray-bounds]
  129 |   if (Bits[i] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
../include/llvm/ADT/SparseBitVector.h:129:15: warning: array subscript 2 is
above array bounds of 'const BitWord [2]' {aka 'const long unsigned int [2]'}
[-Warray-bounds]
  129 |   if (Bits[i] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
[1084/4271] Building CXX object
lib/ExecutionEngine/RuntimeDyld/CMakeFiles/LLVMRuntimeDyld.dir/RTDyldMemoryManager.cpp.
FAILED:
lib/ExecutionEngine/RuntimeDyld/CMakeFiles/LLVMRuntimeDyld.dir/RTDyldMemoryManager.cpp.o
/usr/local/bin/g++  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/ExecutionEngine/RuntimeDyld
-I../lib/ExecutionEngine/RuntimeDyld -Iinclude -I../include -fPIC
-fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra
-Wno-unused-paramete

[Bug middle-end/98055] __builtin_alloca should not have warn_unused_result attribute

2020-11-29 Thread psmith at gnu dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055

--- Comment #2 from Paul Smith  ---
I see no resolution to that thread, but the current behavior of GCC in this
respect is not right and Martin Sebor's arguments are missing the point: the
thinking there is too GCC-centric.  Whether or not builtin-alloca is used is
irrelevant: the issue is _portability_ to _other compilers_.

[Bug d/87788] Support D on x86_64-apple-darwin*

2020-11-29 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788

--- Comment #21 from Iain Buclaw  ---
(In reply to Eric Gallager from comment #20)
> (In reply to CVS Commits from comment #19)
> > ChangeLog:
> > 
> > PR d/87788
> > * configure.ac: Don't disable D for *-*-darwin*.
> > * configure: Regenerate.
> 
> This should get a note in the changes.html file for GCC 11

I'll do this once have confirmed that libphobos is fit for purpose.

[Bug d/98058] New: libphobos: Support building on *-*-darwin*

2020-11-29 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98058

Bug ID: 98058
   Summary: libphobos: Support building on *-*-darwin*
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

This is in continuation of pr87788, but this focuses on issues building the
standard library.

[Bug d/87788] Support D on x86_64-apple-darwin*

2020-11-29 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #22 from Iain Buclaw  ---
Compiler side is fine, so I'll close this as resolved.  Moving work on getting
the compiler/runtime integration of libphobos ported to a new ticket in
pr98058.

[Bug d/98058] libphobos: Support building on *-*-darwin*

2020-11-29 Thread iains at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98058

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-11-29
 CC||iains at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug c++/98052] Allocation with new and deallocation with std::allocator should result in an error

2020-11-29 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98052

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-29

[Bug middle-end/92936] missing warning on a past-the-end store to a PHI

2020-11-29 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92936

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r11-5523-geafe8ee7af13c39805ea09bbf5b4f9ab2a48304a
Author: Martin Sebor 
Date:   Sun Nov 29 15:09:30 2020 -0700

Handle PHIs in compute_objsize.

PR middle-end/92936 - missing warning on a past-the-end store to a PHI
PR middle-end/92940 - incorrect offset and size in -Wstringop-overflow for
out-of-bounds store into VLA and two offset ranges
PR middle-end/89428 - missing -Wstringop-overflow on a PHI with variable
offset

gcc/ChangeLog:

PR middle-end/92936
PR middle-end/92940
PR middle-end/89428
* builtins.c (access_ref::access_ref): Initialize member.
(access_ref::phi): New function.
(access_ref::get_ref): New function.
(access_ref::add_offset): Remove duplicate assignment.
(maybe_warn_for_bound): Add "maybe" kind of warning messages.
(warn_for_access): Same.
(inform_access): Rename...
(access_ref::inform_access): ...to this.  Print PHI arguments. 
Format
offset the same as size and simplify.  Improve printing of
allocation
functions and VLAs.
(check_access): Adjust to the above.
(gimple_parm_array_size): Change argument.
(handle_min_max_size): New function.
* builtins.h (class ssa_name_limit_t): Move class here from
tree-ssa-strlen.c.
(struct access_ref): Declare new members.
(gimple_parm_array_size): Change argument.
* tree-ssa-strlen.c (maybe_warn_overflow): Use access_ref and
simplify.
(handle_builtin_memcpy): Correct argument passed to
maybe_warn_overflow.
(handle_builtin_memset): Same.
(class ssa_name_limit_t): Move class to builtins.{h,c}.

gcc/testsuite/ChangeLog:

PR middle-end/92936
PR middle-end/92940
PR middle-end/89428
* c-c++-common/Wstringop-overflow-2.c: Adjust text of expected
informational notes.
* g++.dg/warn/Wstringop-overflow-3.C: Same.
* g++.dg/warn/Wplacement-new-size.C: Remove a test for a no longer
issued warning.
* gcc.dg/Warray-bounds-43.c: Removed unused declarations.
* gcc.dg/Wstringop-overflow-11.c: Remove xfails.
* gcc.dg/Wstringop-overflow-12.c: Same.
* gcc.dg/Wstringop-overflow-17.c: Adjust text of expected messages.
* gcc.dg/Wstringop-overflow-27.c: Same.  Remove xfails.
* gcc.dg/Wstringop-overflow-28.c: Adjust text of expected messages.
* gcc.dg/Wstringop-overflow-29.c: Same.
* gcc.dg/Wstringop-overflow-37.c: Same.
* gcc.dg/Wstringop-overflow-46.c: Same.
* gcc.dg/Wstringop-overflow-47.c: Same.
* gcc.dg/Wstringop-overflow-54.c: Same.
* gcc.dg/warn-strnlen-no-nul.c: Add expected warning.
* gcc.dg/Wstringop-overflow-7.c: New test.
* gcc.dg/Wstringop-overflow-58.c: New test.
* gcc.dg/Wstringop-overflow-59.c: New test.
* gcc.dg/Wstringop-overflow-60.c: New test.
* gcc.dg/Wstringop-overflow-61.c: New test.
* gcc.dg/Wstringop-overflow-62.c: New test.
* gcc.dg/Wstringop-overflow-63.c: New test.
* gcc.dg/Wstringop-overflow-64.c: New test.

[Bug middle-end/92940] incorrect offset and size in -Wstringop-overflow for out-of-bounds store into VLA and two offset ranges

2020-11-29 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92940

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r11-5523-geafe8ee7af13c39805ea09bbf5b4f9ab2a48304a
Author: Martin Sebor 
Date:   Sun Nov 29 15:09:30 2020 -0700

Handle PHIs in compute_objsize.

PR middle-end/92936 - missing warning on a past-the-end store to a PHI
PR middle-end/92940 - incorrect offset and size in -Wstringop-overflow for
out-of-bounds store into VLA and two offset ranges
PR middle-end/89428 - missing -Wstringop-overflow on a PHI with variable
offset

gcc/ChangeLog:

PR middle-end/92936
PR middle-end/92940
PR middle-end/89428
* builtins.c (access_ref::access_ref): Initialize member.
(access_ref::phi): New function.
(access_ref::get_ref): New function.
(access_ref::add_offset): Remove duplicate assignment.
(maybe_warn_for_bound): Add "maybe" kind of warning messages.
(warn_for_access): Same.
(inform_access): Rename...
(access_ref::inform_access): ...to this.  Print PHI arguments. 
Format
offset the same as size and simplify.  Improve printing of
allocation
functions and VLAs.
(check_access): Adjust to the above.
(gimple_parm_array_size): Change argument.
(handle_min_max_size): New function.
* builtins.h (class ssa_name_limit_t): Move class here from
tree-ssa-strlen.c.
(struct access_ref): Declare new members.
(gimple_parm_array_size): Change argument.
* tree-ssa-strlen.c (maybe_warn_overflow): Use access_ref and
simplify.
(handle_builtin_memcpy): Correct argument passed to
maybe_warn_overflow.
(handle_builtin_memset): Same.
(class ssa_name_limit_t): Move class to builtins.{h,c}.

gcc/testsuite/ChangeLog:

PR middle-end/92936
PR middle-end/92940
PR middle-end/89428
* c-c++-common/Wstringop-overflow-2.c: Adjust text of expected
informational notes.
* g++.dg/warn/Wstringop-overflow-3.C: Same.
* g++.dg/warn/Wplacement-new-size.C: Remove a test for a no longer
issued warning.
* gcc.dg/Warray-bounds-43.c: Removed unused declarations.
* gcc.dg/Wstringop-overflow-11.c: Remove xfails.
* gcc.dg/Wstringop-overflow-12.c: Same.
* gcc.dg/Wstringop-overflow-17.c: Adjust text of expected messages.
* gcc.dg/Wstringop-overflow-27.c: Same.  Remove xfails.
* gcc.dg/Wstringop-overflow-28.c: Adjust text of expected messages.
* gcc.dg/Wstringop-overflow-29.c: Same.
* gcc.dg/Wstringop-overflow-37.c: Same.
* gcc.dg/Wstringop-overflow-46.c: Same.
* gcc.dg/Wstringop-overflow-47.c: Same.
* gcc.dg/Wstringop-overflow-54.c: Same.
* gcc.dg/warn-strnlen-no-nul.c: Add expected warning.
* gcc.dg/Wstringop-overflow-7.c: New test.
* gcc.dg/Wstringop-overflow-58.c: New test.
* gcc.dg/Wstringop-overflow-59.c: New test.
* gcc.dg/Wstringop-overflow-60.c: New test.
* gcc.dg/Wstringop-overflow-61.c: New test.
* gcc.dg/Wstringop-overflow-62.c: New test.
* gcc.dg/Wstringop-overflow-63.c: New test.
* gcc.dg/Wstringop-overflow-64.c: New test.

[Bug middle-end/89428] missing -Wstringop-overflow on a PHI with variable offset

2020-11-29 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89428

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r11-5523-geafe8ee7af13c39805ea09bbf5b4f9ab2a48304a
Author: Martin Sebor 
Date:   Sun Nov 29 15:09:30 2020 -0700

Handle PHIs in compute_objsize.

PR middle-end/92936 - missing warning on a past-the-end store to a PHI
PR middle-end/92940 - incorrect offset and size in -Wstringop-overflow for
out-of-bounds store into VLA and two offset ranges
PR middle-end/89428 - missing -Wstringop-overflow on a PHI with variable
offset

gcc/ChangeLog:

PR middle-end/92936
PR middle-end/92940
PR middle-end/89428
* builtins.c (access_ref::access_ref): Initialize member.
(access_ref::phi): New function.
(access_ref::get_ref): New function.
(access_ref::add_offset): Remove duplicate assignment.
(maybe_warn_for_bound): Add "maybe" kind of warning messages.
(warn_for_access): Same.
(inform_access): Rename...
(access_ref::inform_access): ...to this.  Print PHI arguments. 
Format
offset the same as size and simplify.  Improve printing of
allocation
functions and VLAs.
(check_access): Adjust to the above.
(gimple_parm_array_size): Change argument.
(handle_min_max_size): New function.
* builtins.h (class ssa_name_limit_t): Move class here from
tree-ssa-strlen.c.
(struct access_ref): Declare new members.
(gimple_parm_array_size): Change argument.
* tree-ssa-strlen.c (maybe_warn_overflow): Use access_ref and
simplify.
(handle_builtin_memcpy): Correct argument passed to
maybe_warn_overflow.
(handle_builtin_memset): Same.
(class ssa_name_limit_t): Move class to builtins.{h,c}.

gcc/testsuite/ChangeLog:

PR middle-end/92936
PR middle-end/92940
PR middle-end/89428
* c-c++-common/Wstringop-overflow-2.c: Adjust text of expected
informational notes.
* g++.dg/warn/Wstringop-overflow-3.C: Same.
* g++.dg/warn/Wplacement-new-size.C: Remove a test for a no longer
issued warning.
* gcc.dg/Warray-bounds-43.c: Removed unused declarations.
* gcc.dg/Wstringop-overflow-11.c: Remove xfails.
* gcc.dg/Wstringop-overflow-12.c: Same.
* gcc.dg/Wstringop-overflow-17.c: Adjust text of expected messages.
* gcc.dg/Wstringop-overflow-27.c: Same.  Remove xfails.
* gcc.dg/Wstringop-overflow-28.c: Adjust text of expected messages.
* gcc.dg/Wstringop-overflow-29.c: Same.
* gcc.dg/Wstringop-overflow-37.c: Same.
* gcc.dg/Wstringop-overflow-46.c: Same.
* gcc.dg/Wstringop-overflow-47.c: Same.
* gcc.dg/Wstringop-overflow-54.c: Same.
* gcc.dg/warn-strnlen-no-nul.c: Add expected warning.
* gcc.dg/Wstringop-overflow-7.c: New test.
* gcc.dg/Wstringop-overflow-58.c: New test.
* gcc.dg/Wstringop-overflow-59.c: New test.
* gcc.dg/Wstringop-overflow-60.c: New test.
* gcc.dg/Wstringop-overflow-61.c: New test.
* gcc.dg/Wstringop-overflow-62.c: New test.
* gcc.dg/Wstringop-overflow-63.c: New test.
* gcc.dg/Wstringop-overflow-64.c: New test.

[Bug jit/97867] [11 Regression] thunk_info::release breaks function calls in libgccjit

2020-11-29 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r11-5524-gcaea077c17fdf6fe1aa4c350260f25439dfd5066
Author: Jan Hubicka 
Date:   Sun Nov 29 23:22:24 2020 +0100

Fix freeing of thunk-info

PR jit/97867
* symtab-thunks.h (thunk_info::release): Use ggc_delete.

[Bug fortran/98017] [8/9/10/11 Regression] Suspected regression (relative to 7.5) using PACK in iolist since r8-4151-g6c6bde30706c29ff

2020-11-29 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r11-5526-gbb67ad5cff58a707aaae645d4f45a913d8511c86
Author: Harald Anlauf 
Date:   Sun Nov 29 23:23:16 2020 +0100

PR fortran/98017 - Suspected regression using PACK

When substituting a parameter variable of type character, the character
length was reset to 1.  Fix this by copying the length.

gcc/fortran/ChangeLog:

* expr.c (simplify_parameter_variable): Fix up character length
after copying an array-valued expression.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr98017.f90: New test.

[Bug jit/97867] [11 Regression] thunk_info::release breaks function calls in libgccjit

2020-11-29 Thread hubicka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #6 from Jan Hubicka  ---
Fixed sorry for taking so long

[Bug middle-end/92936] missing warning on a past-the-end store to a PHI

2020-11-29 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92936

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Implemented for GCC 11.  GCC 11 issues the following warnings.   Only accesses
that exceed the size of the largest object are diagnosed for now.  Doing
otherwise would lead to false positives for some common idioms (accessing
either a small buffer or a dynamically allocated larger buffer).  Those cases
will require a predicate analysis to handle in a more robust way.

$ gcc -O2 -S -Wall pr92936.c  
pr92936.c: In function ‘f’:
pr92936.c:17:8: warning: array subscript 5 is outside array bounds of ‘char[5]’
[-Warray-bounds]
   17 |   p[n] = 0;   // -Warray-bounds
  |   ~^~~
pr92936.c:5:15: note: while referencing ‘a5’
5 |   char a3[3], a5[5], *p;
  |   ^~
pr92936.c:11:8: warning: array subscript 3 is outside array bounds of ‘char[3]’
[-Warray-bounds]
   11 |   p[n] = 0;   // -Warray-bounds
  |   ~^~~
pr92936.c:5:8: note: while referencing ‘a3’
5 |   char a3[3], a5[5], *p;
  |^~
pr92936.c: In function ‘g’:
pr92936.c:40:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   40 |   p[n + 9] = 2;   // missing warning
  |   ~^~~
pr92936.c:25:8: note: at offset [12, 14] into destination object ‘a3’ of size 3
   25 |   char a3[3], a5[5], *p;
  |^~
pr92936.c:25:15: note: at offset [12, 14] into destination object ‘a5’ of size
5
   25 |   char a3[3], a5[5], *p;
  |   ^~
pr92936.c:41:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   41 |   p[12345] = 3;   // missing warning
  |   ~^~~
pr92936.c:25:8: note: at offset 12345 into destination object ‘a3’ of size 3
   25 |   char a3[3], a5[5], *p;
  |^~
pr92936.c:25:15: note: at offset 12345 into destination object ‘a5’ of size 5
   25 |   char a3[3], a5[5], *p;
  |   ^~

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

2020-11-29 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 92936, which changed state.

Bug 92936 Summary: missing warning on a past-the-end store to a PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92936

   What|Removed |Added

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

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

2020-11-29 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 92936, which changed state.

Bug 92936 Summary: missing warning on a past-the-end store to a PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92936

   What|Removed |Added

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

[Bug middle-end/89428] missing -Wstringop-overflow on a PHI with variable offset

2020-11-29 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89428

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Resolved by  r11-5523 for GCC 11 which now issues the following warnings for
the test case in comment #0 (the duplicate note needs to be fixed):

$ gcc -O2 -S pr89428.c
pr89428.c: In function ‘f’:
pr89428.c:7:3: warning: ‘__builtin_memset’ writing 7 bytes into a region of
size 6 overflows the destination [-Wstringop-overflow=]
7 |   __builtin_memset (a + i, 0, 7);   // warning (good)
  |   ^~
pr89428.c:1:6: note: at offset [1, 2] into destination object ‘a’ of size 7
1 | char a[7];
  |  ^
pr89428.c: In function ‘g’:
pr89428.c:14:3: warning: ‘__builtin_memset’ writing 99 bytes into a region of
size 7 overflows the destination [-Wstringop-overflow=]
   14 |   __builtin_memset (a + i, 0, 99);   // missing warning (bug)
  |   ^~~
pr89428.c:1:6: note: destination object ‘a’ of size 7
1 | char a[7];
  |  ^
pr89428.c:1:6: note: destination object ‘a’ of size 7

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

2020-11-29 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 89428, which changed state.

Bug 89428 Summary: missing -Wstringop-overflow on a PHI with variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89428

   What|Removed |Added

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

[Bug middle-end/92940] incorrect offset and size in -Wstringop-overflow for out-of-bounds store into VLA and two offset ranges

2020-11-29 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92940

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
  Known to fail||10.2.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to work||11.0

--- Comment #4 from Martin Sebor  ---
Resolved by r11-5523 for GCC 11 which prints the following warning and note:

$ gcc -O2 -S pr92940.c
pr92940.c: In function ‘g’:
pr92940.c:13:8: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   13 |   p[j] = 0;
  |   ~^~~
pr92940.c:9:8: note: at offset 4 into destination object ‘a’ of size [3, 4]
9 |   char a[n];
  |^

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

2020-11-29 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 92940, which changed state.

Bug 92940 Summary: incorrect offset and size in -Wstringop-overflow for 
out-of-bounds store into VLA and two offset ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92940

   What|Removed |Added

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

[Bug plugins/98059] New: [11 regression] Plugins don't compile with c++20

2020-11-29 Thread sss--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98059

Bug ID: 98059
   Summary: [11 regression] Plugins don't compile with c++20
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s...@li-snyder.org
  Target Milestone: ---

The following example fails with gcc 11 (20201128):

$ echo '#include "gcc-plugin.h"' | g++  -x c++ -std=c++20 -c -o x.o - -I`g++
-print-file-name=plugin`/include
In file included from
/usr/local/gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.0/plugin/include/config.h:8,
 from
/usr/local/gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.0/plugin/include/gcc-plugin.h:27,
 from :1:
/usr/local/gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.0/plugin/include/ansidecl.h:424:9:
error: expected unqualified-id before ‘const’
  424 |   TYPE (const TYPE&) = delete;  \
  | ^
/usr/local/gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.0/plugin/include/vec.h:1605:3:
note: in expansion of macro ‘DISABLE_COPY_AND_ASSIGN’
 1605 |   DISABLE_COPY_AND_ASSIGN(auto_delete_vec);
  |   ^~~
/usr/local/gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.0/plugin/include/ansidecl.h:424:9:
error: expected ‘)’ before ‘const’
  424 |   TYPE (const TYPE&) = delete;  \
  |~^
/usr/local/gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.0/plugin/include/vec.h:1605:3:
note: in expansion of macro ‘DISABLE_COPY_AND_ASSIGN’
 1605 |   DISABLE_COPY_AND_ASSIGN(auto_delete_vec);
  |   ^~~


Can be fixed with this patch:

diff --git a/gcc/vec.h b/gcc/vec.h
index 14d77e87342..90904515ea0 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1602,7 +1602,7 @@ class auto_delete_vec : public auto_vec 
   ~auto_delete_vec ();

 private:
-  DISABLE_COPY_AND_ASSIGN(auto_delete_vec);
+  DISABLE_COPY_AND_ASSIGN(auto_delete_vec);
 };

 /* Conditionally allocate heap memory for VEC and its internal vector.  */

[Bug target/98060] New: Failure to optimize cmp+setnb+add to cmp+sbb

2020-11-29 Thread gabravier at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98060

Bug ID: 98060
   Summary: Failure to optimize cmp+setnb+add to cmp+sbb
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int r(unsigned v0, unsigned v1, int v2)
{
return (v0 >= v1) + v2;
}

This code, on x86, can be implemented with `cmp` followed by `sbb`. This
optimization is done by LLVM, but not by GCC.

-O3 x86 output on LLVM :

r:
  mov eax, edx
  cmp edi, esi
  sbb eax, -1
  ret

On GCC :

r:
  xor eax, eax
  cmp edi, esi
  setnb al
  add eax, edx
  ret

[Bug middle-end/98055] __builtin_alloca should not have warn_unused_result attribute

2020-11-29 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
The -Wunused-result warning applies to calls to the GCC alloca built-in
function that allocate space on the stack.  To use replacement implementations
of the function the built-in must be disabled by -fno-builtin-alloca.  That
also suppresses the warning.  This behavior applies in general to other
built-in functions as well, including malloc (and including calls to malloc(0)
which need not allocate any memory and returns null on some implementations).

Diagnosing unportable code, either to other implementations or even to
different configurations of GCC, could be a useful feature, but it's not the
purpose of existing warnings.  Their goal is to detect potential problems given
the current target, under the options in effect.  As an example, take
-Wpointer-to-int-cast which only diagnoses slicing conversion under the
selected data model (e.g., pointer to int in LP64 but not in ILP32).

Broadening the scope of existing warnings to portability would need to be done
under the control of some sort of a -Wportability option that, to be useful and
not overly noisy, would also need to specify the target(s) to which the code is
intended to be portable.  Otherwise, to continue with the example of
-Wpointer-to-int-cast, the warning would have to diagnose every conversion of a
pointer to an integer except intptr_t (which might be useful to some but not
others).

I don't think it would be appropriate to make these implementation choices on a
case-by-case basis and have GCC behave differently for one set of constructs or
functions than another.  Doing so would only result in inconsistencies and make
the warnings less useful, not more.

[Bug middle-end/98055] __builtin_alloca should not have warn_unused_result attribute

2020-11-29 Thread egallager at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78014
 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #3)
> 
> Broadening the scope of existing warnings to portability would need to be
> done under the control of some sort of a -Wportability option that, to be
> useful and not overly noisy, would also need to specify the target(s) to
> which the code is intended to be portable.

Hm, I thought there was a separate bug for this, but it turns out it was just a
tangent to bug 78014...

[Bug c++/98061] New: CV qualifiers are incorrectly stripped from the type of void prvalues

2020-11-29 Thread jason.e.cobb at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98061

Bug ID: 98061
   Summary: CV qualifiers are incorrectly stripped from the type
of void prvalues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.e.cobb at gmail dot com
  Target Milestone: ---

When creating a prvalue of a cv void type, cv qualifiers are incorrectly
stripped.

Consider:
BEGIN EXAMPLE

#include 

template
using id_t = T;

static_assert(std::is_same_v()), void>);

END EXAMPLE

On Compiler Explorer: https://godbolt.org/z/z3PebY

GCC, Clang, and MSVC accept. ICC rejects, believing the type to instead be
const void (https://godbolt.org/z/Tqvjoo). The results are similar for
volatile.

ICC is correct. The correct type is const void per [expr.type.conv]/2:
> Otherwise, if the type is cv void and the initializer is () or {} (after pack 
> expansion, if any), the expression is a prvalue of the specified type that 
> performs no initialization.

[Bug tree-optimization/98051] ICE in logical_combine, at gimple-range-gori.cc:754 in O2-Os

2020-11-29 Thread haoxintu at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98051

--- Comment #3 from Haoxin Tu  ---
(In reply to H.J. Lu from comment #2)

> Please try the current master branch.

Ok, I can't reproduce it in the current trunk, either. Will check more next
time before I submit a report.

BTW, could you please close this as fixed? Thanks.

[Bug c++/98061] CV qualifiers are incorrectly stripped from the type of void prvalues

2020-11-29 Thread jason.e.cobb at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98061

Jason Cobb  changed:

   What|Removed |Added

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

--- Comment #1 from Jason Cobb  ---
I was wrong. GCC is correct.

>From https://bugs.llvm.org/show_bug.cgi?id=48331#c1
> This is an ICC bug. See [expr.type]p2:
>
> "If a prvalue initially has the type “cv T”, where T is a cv-unqualified 
> non-class, non-array type, the type of the expression is adjusted to T prior 
> to any further analysis."

[Bug tree-optimization/98051] ICE in logical_combine, at gimple-range-gori.cc:754 in O2-Os

2020-11-29 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98051

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|WAITING |RESOLVED

--- Comment #4 from H.J. Lu  ---
Dup.

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

[Bug tree-optimization/97359] [11 Regression] ice in logical_combine, at gimple-range-gori.cc:754

2020-11-29 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97359

H.J. Lu  changed:

   What|Removed |Added

 CC||haoxintu at gmail dot com

--- Comment #8 from H.J. Lu  ---
*** Bug 98051 has been marked as a duplicate of this bug. ***

[Bug plugins/98062] New: [11 regression] Crash in type_as_string from plugin

2020-11-29 Thread sss--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98062

Bug ID: 98062
   Summary: [11 regression] Crash in type_as_string from plugin
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s...@li-snyder.org
  Target Milestone: ---

hi -

A plugin i'm working on crashes with gcc 11 because
pp_cxx_trait_expression doesn't handle the CPTK_IS_NOTHROW_CONSTRUCTIBLE enum.

Here's a simple reproducer.  First, here's the plugin:

-- p.cc ---
#include "gcc-plugin.h"
#include "cp/cp-tree.h"

int plugin_is_GPL_compatible;

void type_callback (void* gcc_data, void*)
{
  tree t = (tree)gcc_data;
  tree binfo = TYPE_BINFO (t);
  if (binfo && BINFO_N_BASE_BINFOS (binfo) > 0) {
tree base_binfo = BINFO_BASE_BINFO (binfo, 0);
tree bt = BINFO_TYPE (base_binfo);
if (bt) {
  type_as_string (bt, 0);
}
  }
}


extern "C" {

int
plugin_init(struct plugin_name_args   *, struct plugin_gcc_version *)
{
  register_callback ("a", PLUGIN_FINISH_TYPE, type_callback, nullptr);
  return 0;
}


} // extern "C"
---

Compile with

$ g++ -fPIC -shared -o libp.so  p.cc  -I`g++ -print-file-name=plugin`/include

Run it with this input:

-- x.cc --
template  class B {};

template
struct is_nothrow_default_constructible
  : public B<__is_nothrow_constructible(_Tp)>
{
};
--

$ g++  -fplugin=libp.so   -c x.cc
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_TYPE   | a
x.cc:7:1: internal compiler error: in pp_cxx_trait_expression, at
cp/cxx-pretty-print.c:2671
7 | };
  | ^
0x61483f pp_cxx_trait_expression(cxx_pretty_printer*, tree_node*)
/home/sss/gcc/gcc/gcc/cp/cxx-pretty-print.c:2671
0x6e82ef dump_template_parms
/home/sss/gcc/gcc/gcc/cp/error.c:1945
0x6ec3dc type_as_string(tree_node*, int)
/home/sss/gcc/gcc/gcc/cp/error.c:3024
0xbd60c9 invoke_plugin_callbacks_full(int, void*)
/home/sss/gcc/gcc/gcc/plugin.c:588
0x73ed8f invoke_plugin_callbacks
/home/sss/gcc/gcc/gcc/plugin.h:191
0x73ed8f cp_parser_type_specifier
/home/sss/gcc/gcc/gcc/cp/parser.c:17964
0x73f7fb cp_parser_decl_specifier_seq
/home/sss/gcc/gcc/gcc/cp/parser.c:14585
0x766536 cp_parser_single_declaration
/home/sss/gcc/gcc/gcc/cp/parser.c:29908
0x766897 cp_parser_template_declaration_after_parameters
/home/sss/gcc/gcc/gcc/cp/parser.c:29571
0x766e9a cp_parser_explicit_template_declaration
/home/sss/gcc/gcc/gcc/cp/parser.c:29837
0x7697d9 cp_parser_declaration
/home/sss/gcc/gcc/gcc/cp/parser.c:13609
0x76a04d cp_parser_translation_unit
/home/sss/gcc/gcc/gcc/cp/parser.c:4806
0x76a04d c_parse_file()
/home/sss/gcc/gcc/gcc/cp/parser.c:44630
0x837bed c_common_parse_file()
/home/sss/gcc/gcc/gcc/c-family/c-opts.c:1198
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


This patch fixes the crash:

diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c
index 058b9c2f4fc..b1e10f9e2a8 100644
--- a/gcc/cp/cxx-pretty-print.c
+++ b/gcc/cp/cxx-pretty-print.c
@@ -2666,6 +2666,9 @@ pp_cxx_trait_expression (cxx_pretty_printer *pp, tree t)
 case CPTK_IS_CONSTRUCTIBLE:
   pp_cxx_ws_string (pp, "__is_constructible");
   break;
+case CPTK_IS_NOTHROW_CONSTRUCTIBLE:
+  pp_cxx_ws_string (pp, "__is_nothrow_constructible");
+  break;

 default:
   gcc_unreachable ();


However, there are still a few other CPTK_ enums that aren't handled
in pp_cxx_trait_expression --- probably PTK_IS_NOTHROW_ASSIGNABLE
should be there, at least.

[Bug target/98063] New: Emit R_X86_64_GOTOFF64 instead of R_X86_64_GOTPCRELX for -mcmodel=large -fno-plt

2020-11-29 Thread i at maskray dot me via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98063

Bug ID: 98063
   Summary: Emit R_X86_64_GOTOFF64 instead of R_X86_64_GOTPCRELX
for -mcmodel=large -fno-plt
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

% cat a.c
#include 

int main() {
  puts("meow");
}

% gcc -mcmodel=large -fno-plt -O1 -S a.c -fpic -o - -O2
-fno-asynchronous-unwind-tables
...
main:
.L2:
movabsq $_GLOBAL_OFFSET_TABLE_-.L2, %r11
subq$8, %rsp
leaq.L2(%rip), %rax
movabsq $.LC0@GOTOFF, %rdx
addq%r11, %rax
leaq(%rax,%rdx), %rdi
call*puts@GOTPCREL(%rip)
xorl%eax, %eax
addq$8, %rsp
ret

The distance between the GOT entry and the next instruction of call may be
larger than 32-bit. An R_X86_64_GOTPCRELX relocation cannot be used.

[Bug tree-optimization/98064] New: ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:726 with -O3

2020-11-29 Thread vsevolod.livinskij at frtk dot ru via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98064

Bug ID: 98064
   Summary: ICE in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:726 with -O3
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Error:
>$ g++ -c -O3 func.cpp
during GIMPLE pass: slp
func.cpp: In function ‘void test()’:
func.cpp:8:6: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:726
8 | void test() {
  |  ^~~~
0x84b706 check_loop_closed_ssa_def
/home/vlivinsk/workspace/gcc/gcc_src/gcc/tree-ssa-loop-manip.c:726
0x12ae78d check_loop_closed_ssa_bb
/home/vlivinsk/workspace/gcc/gcc_src/gcc/tree-ssa-loop-manip.c:752
0x12b05d6 verify_loop_closed_ssa(bool, loop*)
/home/vlivinsk/workspace/gcc/gcc_src/gcc/tree-ssa-loop-manip.c:777
0x12b05d6 verify_loop_closed_ssa(bool, loop*)
/home/vlivinsk/workspace/gcc/gcc_src/gcc/tree-ssa-loop-manip.c:761
0x1062c24 execute_function_todo
/home/vlivinsk/workspace/gcc/gcc_src/gcc/passes.c:2057
0x10638ae execute_todo
/home/vlivinsk/workspace/gcc/gcc_src/gcc/passes.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Reproducer:
#include 
extern long var_2;
extern int var_3, var_8;
extern long long var_5;
extern unsigned short arr_353[];
extern short arr_362[];
extern int arr_518[];
void test() {
for (char d = 0; d < 013; d += 4) {
for (char e = 0; e < 11; e++)
arr_353[e] = var_2 | std::min((long long)7, var_5);
for (int f = var_5; f; f += 4)
for (short g = var_8; g; g++)
arr_362[g] = 0;
}
for (short h = 5; (short)var_2; h += 5)
arr_518[h] = 0;
}


gcc version 11.0.0 20201126 (beb9afcaf1466996a301c778596c5df209e7913c)

[Bug target/98065] New: [11 Regression] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7024

2020-11-29 Thread asolokha at gmx dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98065

Bug ID: 98065
   Summary: [11 Regression] ICE in rs6000_expand_vector_set, at
config/rs6000/rs6000.c:7024
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gcc-11.0.0-alpha20201129 snapshot (g:bb67ad5cff58a707aaae645d4f45a913d8511c86)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/i386/avx2-vec-set-1.c, w/ -mvsx -O1:

typedef int v4si __attribute__ ((vector_size (16)));

v4si
gt (v4si tr, int ci, int wd)
{
  tr[wd] = ci;

  return tr;
}

% powerpc-e300c3-linux-gnu-gcc-11.0.0 -mvsx -O1 -c mat0imfx.c
during RTL pass: expand
mat0imfx.c: In function 'gt':
mat0imfx.c:6:10: internal compiler error: in rs6000_expand_vector_set, at
config/rs6000/rs6000.c:7024
6 |   tr[wd] = ci;
  |   ~~~^~~~
0x7259c7 rs6000_expand_vector_set(rtx_def*, rtx_def*, rtx_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/config/rs6000/rs6000.c:7024
0x153b880 ???
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/config/rs6000/vector.md:1251
0xcd0378 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/optabs.c:7435
0xb6a67d expand_vec_set_optab_fn
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/internal-fn.c:2879
0xb6a67d expand_VEC_SET
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/internal-fn.def:148
0x93e0c7 expand_call_stmt
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cfgexpand.c:2740
0x93e0c7 expand_gimple_stmt_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cfgexpand.c:3835
0x93e0c7 expand_gimple_stmt
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cfgexpand.c:3999
0x943c5a expand_gimple_basic_block
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cfgexpand.c:6040
0x9457bf execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/cfgexpand.c:6724

[Bug tree-optimization/97239] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201

2020-11-29 Thread asolokha at gmx dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97239

--- Comment #2 from Arseny Solokha  ---
I cannot reproduce it anymore w/ gcc-11.0.0-alpha20201129 snapshot
(g:bb67ad5cff58a707aaae645d4f45a913d8511c86).

[Bug tree-optimization/97239] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201

2020-11-29 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97239

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Yeah, it's a dup.

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

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

2020-11-29 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579

Richard Biener  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #12 from Richard Biener  ---
*** Bug 97239 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/98066] New: [11 Regression] ICE: Segmentation fault (in gsi_next)

2020-11-29 Thread asolokha at gmx dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98066

Bug ID: 98066
   Summary: [11 Regression] ICE: Segmentation fault (in gsi_next)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gcc-11.0.0-alpha20201129 snapshot (g:bb67ad5cff58a707aaae645d4f45a913d8511c86)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-2.c, w/ -mvsx -O1:

typedef int v4si __attribute__ ((vector_size (16)));

void
qs (v4si i1, v4si t7, int a0)
{
  if (a0 != 0)
t7[a0] = a0;

  if (__builtin_vec_vcmpeq_p (a0, i1, t7))
__builtin_abort ();
}

% powerpc-e300c3-linux-gnu-gcc-11.0.0 -mvsx -O1 -c zeu112my.c
during GIMPLE pass: isel
zeu112my.c: In function 'qs':
zeu112my.c:4:1: internal compiler error: Segmentation fault
4 | qs (v4si i1, v4si t7, int a0)
  | ^~
0xdf2a16 crash_signal
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/toplev.c:330
0x104ba30 gsi_next
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/gimple-iterator.h:193
0x104ba30 gimple_expand_vec_exprs
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/gimple-isel.cc:264
0x104ba30 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201129/work/gcc-11-20201129/gcc/gimple-isel.cc:318