[Bug c/68454] internal compiler error: Segmentation fault

[luser.droog at gmail dot com]

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

--- Comment #1 from M Joshua Ryan  ---
This is on a fresh install of cygwin64 on a new Windows 10 laptop.

[Bug c/68454] New: internal compiler error: Segmentation fault

[luser.droog at gmail dot com]

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

Bug ID: 68454
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luser.droog at gmail dot com
  Target Milestone: ---

Created attachment 36778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36778&action=edit
gcc -E -o main.cpp src/lib/xpost_main.c

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/5.2.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-5.2.0-1.x86_64/src/gcc-5.2.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.2.0-1.x86_64/src/gcc-5.2.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
Thread model: posix
gcc version 5.2.0 (GCC) 

FWIW I got the same error from the 4.9.2-3 release.


Here's my complete session, from a fresh clone of the git to the error.

josh@LAPTOP-ILO10OOF ~
$ git clone https://github.com/luser-dr00g/xpost.git
Cloning into 'xpost'...
remote: Counting objects: 7988, done.
remote: Total 7988 (delta 0), reused 0 (delta 0), pack-reused 7988
Receiving objects: 100% (7988/7988), 1.38 MiB | 58.00 KiB/s, done.
Resolving deltas: 100% (5880/5880), done.
Checking connectivity... done.

josh@LAPTOP-ILO10OOF ~
$ cd xpost

josh@LAPTOP-ILO10OOF ~/xpost
$ ./autogen.sh
autoreconf-2.69: Entering directory `.'
autoreconf-2.69: configure.ac: not using Gettext
autoreconf-2.69: running: aclocal --force -I m4
autoreconf-2.69: configure.ac: tracing
autoreconf-2.69: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf-2.69: running: /usr/bin/autoconf-2.69 --force
autoreconf-2.69: running: /usr/bin/autoheader-2.69 --force
autoreconf-2.69: running: automake --add-missing --copy --force-missing
Unescaped left brace in regex is deprecated, passed through in regex; marked by
<-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /usr/bin/automake-1.14 line
3930.
configure.ac:16: installing './compile'
configure.ac:21: installing './config.guess'
configure.ac:21: installing './config.sub'
configure.ac:18: installing './install-sh'
configure.ac:18: installing './missing'
Makefile.am: installing './depcomp'
autoreconf-2.69: Leaving directory `.'
configure: creating cache config.cache
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/bin/sh: /home/josh/missing: No such file or directory
configure: WARNING: 'missing' script is too old or missing
checkin

[Bug middle-end/68453] [6 Regression] graphite ICE: segfault

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch, spop at gcc dot gnu.org
Summary|graphite ICE: segfault  |[6 Regression] graphite
   ||ICE: segfault

--- Comment #1 from Joost VandeVondele  
---
new graphite ice

[Bug middle-end/68453] New: graphite ICE: segfault

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 68453
   Summary: graphite ICE: segfault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

current trunk (r230637) crashes with

> cat bug.f90
MODULE dbcsr_geev
  INTEGER, PARAMETER :: real_8=8
CONTAINS
  SUBROUTINE dbcsr_dgeev(jobvl,jobvr,matrix,ndim,evals,revec,levec)
CHARACTER(1) :: jobvl, jobvr
REAL(real_8), DIMENSION(:, :):: matrix
INTEGER  :: ndim
COMPLEX(real_8), DIMENSION(:):: evals
COMPLEX(real_8), DIMENSION(:, :) :: revec, levec
INTEGER  :: i, info, lwork
REAL(real_8) :: norm, tmp_array(ndim,ndim), &
work(20*ndim)
REAL(real_8), DIMENSION(ndim):: eval1, eval2
REAL(real_8), DIMENSION(ndim, ndim)  :: evec_l, evec_r
DO WHILE (i.le.ndim)
  IF(ABS(eval2(i)).LT.EPSILON(REAL(0.0,real_8)))THEN
norm=SQRT(SUM(evec_r(:,i)**2.0_real_8)+SUM(evec_r(:,i+1)**2.0_real_8))
revec(:,i)=CMPLX(evec_r(:,i),evec_r(:,i+1),real_8)/norm
  END IF
END DO
  END SUBROUTINE  dbcsr_dgeev 
END MODULE dbcsr_geev 

> gfortran -c  -O2  -floop-nest-optimize bug.f90
bug.f90:4:0:

   SUBROUTINE dbcsr_dgeev(jobvl,jobvr,matrix,ndim,evals,revec,levec)


internal compiler error: Segmentation fault
0xb5c56f crash_signal
../../gcc/gcc/toplev.c:334
0xbaf347 ssa_default_def(function*, tree_node*)
../../gcc/gcc/tree-dfa.c:305
0xbb1d88 get_or_create_ssa_default_def(function*, tree_node*)
../../gcc/gcc/tree-dfa.c:357
0xbe8ce3 get_reaching_def
../../gcc/gcc/tree-into-ssa.c:1168
0xbe8ce3 get_reaching_def
../../gcc/gcc/tree-into-ssa.c:1155
0xbea968 rewrite_update_phi_arguments
../../gcc/gcc/tree-into-ssa.c:2015
0xbea968 rewrite_update_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-into-ssa.c:2135
0xbea968 rewrite_update_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-into-ssa.c:2068
0x124aeda dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:176
0xbe7715 rewrite_blocks
../../gcc/gcc/tree-into-ssa.c:2190
0xbee94e update_ssa(unsigned int)
../../gcc/gcc/tree-into-ssa.c:3351
0x1274bb1
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:1026
0x1275505 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:1051
0x1275505 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:1051
0x1275505 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:1051
0x1274f7a graphite_regenerate_ast_isl(scop*)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:2999
0x126d690 graphite_transform_loops()
../../gcc/gcc/graphite.c:343
0x126db60 graphite_transforms
../../gcc/gcc/graphite.c:371
0x126db60 execute
../../gcc/gcc/graphite.c:448
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/68279] ICE: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:836

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

   Last reconfirmed||2015-11-20

--- Comment #4 from Joost VandeVondele  
---
still happens at r230637

I notice the Fortran testcase misses its last line, for completeness:

> cat PR68279.f90

MODULE dbcsr_mm_accdrv
  INTEGER, SAVE :: accdrv_binning_nbins = 4096
  INTEGER, SAVE :: accdrv_binning_binsize = 16
  INTEGER, PARAMETER, PUBLIC :: dbcsr_ps_width = 7
  CONTAINS
  SUBROUTINE stack_binning(params_in, params_out, stack_size)
INTEGER, INTENT(IN)  :: stack_size
INTEGER, DIMENSION(dbcsr_ps_width, &
  stack_size), INTENT(OUT)   :: params_out
INTEGER, DIMENSION(dbcsr_ps_width, &
  stack_size), INTENT(IN):: params_in
INTEGER, DIMENSION(accdrv_binning_nbins) :: bin_top
INTEGER, DIMENSION(dbcsr_ps_width)   :: val
INTEGER, DIMENSION(dbcsr_ps_width, &
  accdrv_binning_binsize, &
  accdrv_binning_nbins)  :: bin_arr
 DO i=1,stack_size
val(:) = params_in(:,i)
IF(bin_top(bin_id) > accdrv_binning_binsize) THEN
   params_out(:, top:top+bin_top(bin_id)-2) = bin_arr(:,
1:bin_top(bin_id)-1, bin_id)
ENDIF
bin_arr(:, bin_top(bin_id), bin_id) =  val(:)
bin_top(bin_id) = bin_top(bin_id) + 1
 END DO
  END SUBROUTINE  stack_binning
END MODULE

[Bug plugins/68452] New: C front end doesn't call PLUGIN_FINISH_DECL on CONST_DECLs

[tromey at gcc dot gnu.org]

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

Bug ID: 68452
   Summary: C front end doesn't call PLUGIN_FINISH_DECL on
CONST_DECLs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

While working on a plugin I noticed that PLUGIN_FINISH_DECL doesn't
seem to be called for a CONST_DECL.

I think this could be fixed by adding the appropriate plugin call
near the end of c-decl.c:build_enumerator.

[Bug c++/68451] New: internal compiler error: Segmentation fault when using decltype with friend inside a class template

[tim.pavlic at minelab dot com.au]

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

Bug ID: 68451
   Summary: internal compiler error: Segmentation fault when using
decltype with friend inside a class template
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.pavlic at minelab dot com.au
  Target Milestone: ---

Source to reproduce:



struct A {};

struct B
{
A a;
friend decltype(a); // This works, B is not a class template
};

template 
struct C
{
A a;
// This friend declaration gives an ICE.
// Seemingly because C is a class template
friend decltype(a); 
};

int main()
{
B b;
C c;   // This causes the ICE
}



I have the above source in a single file, ice.cpp, and compile with: g++
-std=c++14 ice.cpp

Looks like using decltype in conjunction with friend has problems when you are
in a class template.

It also crashes on GCC 5 (not sure of minor number).
-std=c++11 has the same issue.

[Bug tree-optimization/66573] Unexpected change in static, branch-prediction cost from O1 to O2 in if-then-else.

[jvg1981 at aim dot com]

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

jvg1981 at aim dot com changed:

   What|Removed |Added

 CC||jvg1981 at aim dot com

--- Comment #5 from jvg1981 at aim dot com ---
I recently came across this surprising behavior.  Has anyone taken a serious
look at it?  Is it likely to be corrected/changed?

[Bug libstdc++/68448] Python Pretty Printers get disabled on libstdc++ reload by GDB

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-20
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Thanks for figuring out the problem, this has been annoying me recently but I
didn't know what caused it.

Please CC the patch to the libstdc++ list (I'm not subscribed to gcc-patches).

N.B. this reverts https://gcc.gnu.org/r215726 so we should look back at why
that change was made.

[Bug c++/68450] New: regex matching different from ECMAScript?

[lcoquelle at gmail dot com]

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

Bug ID: 68450
   Summary: regex matching different from ECMAScript?
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lcoquelle at gmail dot com
  Target Milestone: ---

Created attachment 36777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36777&action=edit
Code sample

Using a complex regex to remove comment in JSON file (...), the behaviour seems
to differ from ECMAScript.
FYI: boost::regex 1.59 seems to have the correct behaviour.

Regex: ((['"])(?:(?!\2|\\).|\\.)*\2)|\/\/[^\n]*|\/\*(?:[^*]|\*(?!\/))*\*\/
(can be try here: https://regex101.com/r/vI2iW5/2#javascript)

Input string: "Entry": "Value", // Skip "me"
Expected output: "Entry": "Value", 
Real output: "Entry": "Value", // Skip "me"



Attached a code sample.
Compiling output as below:


> /usr/local/gcc49/bin/g++ -v -save-temps -Wall -std=gnu++14 re.cc 
Using built-in specs.
COLLECT_GCC=/usr/local/gcc49/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /usr/local/src/gcc-4.9.2/configure --disable-multilib
--enable-cloog-backend=isl --enable-gold=default --enable-languages=c,c++
--enable-lto --enable-libssp --enable-plugins --enable-plugin
--with-build-config=bootstrap-lto --enable-stage1-checking=release
--prefix=/usr/local/gcc49
Thread model: posix
gcc version 4.9.2 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=gnu++1y' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -E -quiet
-v -D_GNU_SOURCE re.cc -mtune=generic -march=x86-64 -std=gnu++1y -Wall
-fpch-preprocess -o re.ii
ignoring nonexistent directory
"/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2

/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/x86_64-unknown-linux-gnu

/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/backward
 /usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include
 /usr/local/include
 /usr/local/gcc49/include
 /usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=gnu++1y' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus
-fpreprocessed re.ii -quiet -dumpbase re.cc -mtune=generic -march=x86-64
-auxbase re -Wall -std=gnu++1y -version -o re.s
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4c9e457b752b2d9171dda4de0a18535a
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=gnu++1y' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'

/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/bin/as
-v --64 -o re.o re.s
GNU assembler version 2.24 (x86_64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.24
COMPILER_PATH=/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/bin/
LIBRARY_PATH=/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/lib/:/usr/local/gcc49/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=gnu++1y' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/collect2 -plugin
/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/liblto_plugin.so
-plugin-opt=/usr/local/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
-plugin-opt=-fresolution=re.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plu

[Bug sanitizer/68065] Size calculations for VLAs can overflow

[joseph at codesourcery dot com]

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

--- Comment #34 from joseph at codesourcery dot com  ---
On Thu, 19 Nov 2015, ch3root at openwall dot com wrote:

> What does the following mean then?
> 
> C11, 4p5:
> "A strictly conforming program[...] It [...] shall not exceed any 
> minimum implementation limit."

It's well-known that, if you read the standard literally, strictly 
conforming programs may not exist; too much is unspecified or 
implementation-defined (including, in general, limits on supported 
programs; cf 1#2 "This International Standard does not specify ... the 
size or complexity of a program and its data that will exceed the capacity 
of any specific data-processing system or the capacity of a particular 
processor").

In general, you can only reason about C programs conditional on the 
program not exceeding any implementation limit.

[Bug sanitizer/68065] Size calculations for VLAs can overflow

[ch3root at openwall dot com]

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

--- Comment #33 from Alexander Cherepanov  ---
On 2015-11-12 06:25, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
>
> --- Comment #31 from Martin Sebor  ---
> (In reply to Alexander Cherepanov from comment #23)
>
>> 2. The practical problem is size calculation in general, it's not
>> limited to sizeof operation. You don't need to use sizeof to create
>> oversized automatic VLA (an example in the description).
>
> Agreed.  Creating an automatic VLA object that exhausts the stack is bad.  In
> all likelihood it will crash the program.  I'm not sure to what extent it 
> might
> be exploitable.

 From http://www.openwall.com/lists/oss-security/2014/11/03/2 :
"It can be exploitable in multithreaded programs though if there is
an unused stack allocation of at least one page further down in the
stack."

Sorry, don't have more info off-hand.

> Allowing a sizeof expression to overflow given a VLA type is
> benign in an of itself, but can lead to more subtle bugs depending on how the
> result is used (e.g., to allocate an array on the heap whose elements are then
> written to).  Some of those bugs have known exploits.

Sure.

>> 3. IMHO overflow in sizeof operation is UB due to C11, 6.5p5, and
>> wrapping according to C11, 6.2.5p9, is not applicable (see the comment #7).
>
> No, that's not a correct interpretation.  It's exactly the other way around.
> Sizeof is computed in an unsigned type.

IMHO, how sizeof is computed is an implementation detail. C11 doesn't 
describe it at all. E.g., for arrays it doesn't mention multiplication 
and just says that "the result is the total number of bytes in the 
array". From another side: an operand of sizeof is usually not unsigned. 
Even when the operand is unsigned, sizeof doesn't compute anything with 
it, sizeof work with its type.

>> 4. From the POV of the standard I don't see much difference between VLA
>> and ordinary arrays in this question. AFAICT the standard doesn't place
>> limits on constructed types of any kind and hence oversized types are
>> permitted by the standard. See comment #3 (or pr68107) for a practical
>> example of sizeof overflow with an array of a known constant size which
>> works with the current gcc.
>
> It is the intent of the standard to allow implementations to impose such a
> limit.  It may not be specified with sufficient clarity in the text, but the
> intent is reflected in the C99 Rationale.

Yeah, it seems to be a known problem without know solution:-) But IMHO:

* if C11, 4p6, (about acceptig any strictly conforming
program) is really mean what I think it means it should be fixed;

* the scope of the problem should be somehow acknowledged and preferably 
limited in the standard. Something like saying that an implementation 
can impose any other restrictions but those restrictions must be 
documented. It's a sad situation when arbitrary limits could be imposed 
but there is no way for a user to find out which. The ideal illustration 
here is pr67999. It's a limit which can lead to security problems, which 
is not documented and which is not detected at compile- or run-time.

[Bug tree-optimization/68428] [6 Regression] [graphite] ICE in outermost_loop_in_sese w/ -O2 -floop-strip-mine or -O2 -floop-nest-optimize

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||spop at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Sebastian Pop  ---
Fixed in r230632

[Bug sanitizer/68065] Size calculations for VLAs can overflow

[ch3root at openwall dot com]

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

--- Comment #32 from Alexander Cherepanov  ---
Sorry for the late reply. Decided to read DR 260 and got distracted. It 
so fundamentally undermines the base of classical C that it took me some 
time to grasp the scale:-)

On 2015-11-12 01:51, joseph at codesourcery dot com wrote:
>> 4. From the POV of the standard I don't see much difference between VLA
>> and ordinary arrays in this question. AFAICT the standard doesn't place
>> limits on constructed types of any kind and hence oversized types are
>> permitted by the standard. See comment #3 (or pr68107) for a practical
>
> "permitted by" only in the sense of "the standard does not require
> implementations to reject them".  It is not intended that the listed
> implementation limits are the only limits that there may be, at compile
> time or run time.

What does the following mean then?

C11, 4p5:
"A strictly conforming program[...] It [...] shall not exceed any 
minimum implementation limit."

C11, 4p6:
"A conforming hosted implementation shall accept any strictly conforming 
program."

>> 3. The same for sizes of objects. There is an environmental limit for
>> "bytes in an object" but it's marked as "(in a hosted environment
>> only)". So there is no such limit in the standard for a freestanding
>> implementation, right? But I doubt that you are supposed to be able to
>
> No, what's "in a hosted environment only" is the requirement that the
> implementation translate and execute some program with a 65535-byte object
> (and an instance of the other given limits, simultaneously); freestanding
> implementations may have an object size limit smaller than 65535 bytes.
> That is, effectively, C99 and above do not support hosted environments
> with a 16-bit address space; systems with a 16-bit address space are only
> supported for freestanding implementations.

I see, thanks for the info.

[Bug tree-optimization/68335] [6 Regression][GRAPHITE] ICE: tree check: expected ssa_name, have real_cst in add_phi_arg_for_new_expr, at sese.c:1373

[spop at gcc dot gnu.org]

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

--- Comment #4 from Sebastian Pop  ---
testcase added in r230630

[Bug fortran/68439] ICE in alloc_scalar_allocatable_for_subcomponent_assignment, at fortran/trans-expr.c:6711

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed for 5.2 and trunk (6.0). Version 4.9 gives the error

pr68439.f90:7.7:

   x = t(a=1)
   1
Error: No initializer for component 'c' given in the structure constructor at
(1)!

and version 4.8

pr68439.f90:4.36:

  character(:), allocatable :: c
1
Error: Deferred-length character component 'c' at (1) is not yet supported

[Bug tree-optimization/68341] [6 Regression] FAIL: gcc.dg/graphite/interchange-{1,11,13}.c (internal compiler error)

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #4 from Sebastian Pop  ---
Fixed in r230631

[Bug fortran/68440] ICE on declaring class variable with wrong attribute

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-19
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Compiling the first two tests with 4.8 up to trunk gives an ICE. Compiling the
third and fourth tests with 4.8 up to 5.2 gives and ICE, but with trunk (6.0)
the third test compiles without error and the fourth test gives the following
error

pr68440_3.f90:4:16:

class(t) :: x = t()
1

Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer

The last two tests give the reported errors with 4.8 up to trunk, except the
last one when compiled with 4.8:

   x = t()
   1
Error: Variable must not be polymorphic in intrinsic assignment at (1) - check
that there is a matching specific subroutine for '=' operator

[Bug fortran/68441] ICE on using transfer with character parameter

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

[Bug tree-optimization/68335] [6 Regression][GRAPHITE] ICE: tree check: expected ssa_name, have real_cst in add_phi_arg_for_new_expr, at sese.c:1373

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #3 from Sebastian Pop  ---
This is fixed in trunk as of today.  I will add the testcase.

[Bug fortran/68442] ICE on kind specification, depending on ordering of functions

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-19
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk.

[Bug c++/68422] compile-time cost of sizeof... is quadratic

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Nov 19 22:29:08 2015
New Revision: 230629

URL: https://gcc.gnu.org/viewcvs?rev=230629&root=gcc&view=rev
Log:
PR c++/68422

* cp-tree.h (PACK_EXPANSION_SIZEOF_P): New.
* parser.c (cp_parser_sizeof_pack): Set it.
* pt.c  (tsubst_copy) [SIZEOF_EXPR]: Likewise.
(tsubst_pack_expansion): Improve T... shortcut for expression packs.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c

[Bug c/68412] [6 Regression] ICE with -Wall -Wextra in fold_binary_loc()

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c/68412] [6 Regression] ICE with -Wall -Wextra in fold_binary_loc()

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Thu Nov 19 22:04:00 2015
New Revision: 230627

URL: https://gcc.gnu.org/viewcvs?rev=230627&root=gcc&view=rev
Log:
PR c/68412
* c-typeck.c (parser_build_binary_op): Properly handle
C_MAYBE_CONST_EXPR before calling warn_tautological_cmp.

* gcc.dg/pr68412-2.c: New test.
* gcc.dg/pr68412.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr68412-2.c
trunk/gcc/testsuite/gcc.dg/pr68412.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68427] GCC (G++) flunks legal ANSI-C code

[wam at hiwaay dot net]

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

--- Comment #5 from wam at hiwaay dot net ---
Created attachment 36776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36776&action=edit
response to comment 4 

Here is the stuff in reply to comment 4 

[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
Bug 68449 is likely a duplicate of this one, though with a test case not
involving C++ 11 constexpr.

[Bug c++/68449] New: ICE in cxx_eval_constant_expression on atomic_load in C++

[msebor at gcc dot gnu.org]

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

Bug ID: 68449
   Summary: ICE in cxx_eval_constant_expression on atomic_load in
C++
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Compiling the following program with the latest trunk triggers a number of
errors due to the _Atomic qualifier that's not recognized in C++ followed by an
ICE:

$ cat z.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -o/dev/null  -xc++ z.cpp
#include 

int foo (int *p)
{
return atomic_load (p) < 0;
}

After reducing that to a small test case I ended up with the following valid
code.

Searching for cxx_eval_constant_expression suggests this might be a duplicate
of bug 68348.

$ cat z.ii && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -o/dev/null -xc++ z.ii
int foo (int a)
{
return __extension__ ({
__typeof__ (a) b;
b; }) < 0;
}
z.ii: In function ‘int foo(int)’:
z.ii:5:17: internal compiler error: Segmentation fault
 b; }) < 0;
 ^

0xffa298 crash_signal
/home/msebor/scm/fsf/gcc-svn/gcc/toplev.c:334
0x9f417f cxx_eval_constant_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3198
0x9f377d cxx_eval_statement_list
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3029
0x9f59ce cxx_eval_constant_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3614
0x9f5a4d cxx_eval_constant_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3620
0x9f628a cxx_eval_outermost_constant_expr
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3774
0x9f6c9c maybe_constant_value_1
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3960
0x9f6d99 maybe_constant_value(tree_node*, tree_node*)
/home/msebor/scm/fsf/gcc-svn/gcc/cp/constexpr.c:3981
0x8f5e3c cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
/home/msebor/scm/fsf/gcc-svn/gcc/cp/typeck.c:5045
0x73e1d4 build_new_op_1
/home/msebor/scm/fsf/gcc-svn/gcc/cp/call.c:5758
0x73e2c8 build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
/home/msebor/scm/fsf/gcc-svn/gcc/cp/call.c:5803
0x8f1d8f build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
/home/msebor/scm/fsf/gcc-svn/gcc/cp/typeck.c:3828
0x892faa cp_parser_binary_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:8591
0x8932a1 cp_parser_assignment_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:8712
0x893511 cp_parser_expression
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:8871
0x8981bc cp_parser_jump_statement
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:11408
0x895904 cp_parser_statement
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:10035
0x896408 cp_parser_statement_seq_opt
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:10426
0x896303 cp_parser_compound_statement
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:10380
0x8a70f3 cp_parser_function_body
/home/msebor/scm/fsf/gcc-svn/gcc/cp/parser.c:20192
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
tmp$

[Bug libstdc++/68448] Python Pretty Printers get disabled on libstdc++ reload by GDB

[jan.kratochvil at redhat dot com]

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

--- Comment #2 from Jan Kratochvil  ---
[patch] Python Pretty Printers get disabled on libstdc++ reload by GDB (PR
libstdc++/68448)
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02418.html

[Bug libstdc++/68448] Python Pretty Printers get disabled on libstdc++ reload by GDB

[jan.kratochvil at redhat dot com]

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

--- Comment #1 from Jan Kratochvil  ---
https://bugzilla.redhat.com/show_bug.cgi?id=1279406

[Bug libstdc++/68448] New: Python Pretty Printers get disabled on libstdc++ reload by GDB

[jan.kratochvil at redhat dot com]

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

Bug ID: 68448
   Summary: Python Pretty Printers get disabled on libstdc++
reload by GDB
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
  Target Milestone: ---

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

echo -e '#include \nint main(){std::vector l;\nreturn 0;}'|g++ -g
-Wall -x c++ -;gdb -q ./a.out -batch -ex 'b 3' -ex r -ex 'p l' -ex r -ex 'p l'

Actual:
[...]
$1 = std::vector of length 0, capacity 0
[...]
$2 = { >> = {_M_impl =
{> = {<__gnu_cxx::new_allocator> = {},
}, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}},
}

Expected:
[...]
$1 = std::vector of length 0, capacity 0
[...]
$2 = std::vector of length 0, capacity 0

[Bug c/68412] [6 Regression] ICE with -Wall -Wextra in fold_binary_loc()

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #3 from Marek Polacek  ---
*** Bug 68447 has been marked as a duplicate of this bug. ***

[Bug c/68447] ICE with -Wall on valid code on x86_64-linux-gnu in fold_binary_loc, at fold-const.c:9085

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Dup.  Patch: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02408.html

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

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Np.  It's certainly something I'd love to see fixed :/.  Hopefully the next
stage1.

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Marek Polacek from comment #9)
> So that's why this PR is still open.

Sure, sorry, I should have been clearer. It was mostly a note to myself so I do
not need to re-check next time I look at this PR.

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
So that's why this PR is still open.

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
The last patch did not fix the original testcase nor
gcc/testsuite/gcc.dg/pr40172-3.c

[Bug c/68447] New: ICE with -Wall on valid code on x86_64-linux-gnu in fold_binary_loc, at fold-const.c:9085

[su at cs dot ucdavis.edu]

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

Bug ID: 68447
   Summary: ICE with -Wall on valid code on x86_64-linux-gnu in
fold_binary_loc, at fold-const.c:9085
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk with
-Wall enabled on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151118 (experimental) [trunk revision 230547] (GCC) 
$ 
$ gcc-trunk -c small.c
$ gcc-5.2 -Wall -c small.c
small.c: In function ‘fn1’:
small.c:6:10: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
   a != (0, 0); 
  ^
small.c:6:3: warning: statement with no effect [-Wunused-value]
   a != (0, 0); 
   ^
$ 
$ gcc-trunk -Wall -c small.c
small.c: In function ‘fn1’:
small.c:6:10: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
   a != (0, 0);
  ^

small.c:6:3: internal compiler error: in fold_binary_loc, at fold-const.c:9085
   a != (0, 0);
   ^

0x83befd fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc-trunk/gcc/fold-const.c:9082
0x858f94 fold(tree_node*)
../../gcc-trunk/gcc/fold-const.c:11974
0x649880 warn_tautological_cmp(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc-trunk/gcc/c-family/c-common.c:1927
0x601e5f parser_build_binary_op(unsigned int, tree_code, c_expr, c_expr)
../../gcc-trunk/gcc/c/c-typeck.c:3515
0x613678 c_parser_binary_expression
../../gcc-trunk/gcc/c/c-parser.c:6544
0x613b35 c_parser_conditional_expression
../../gcc-trunk/gcc/c/c-parser.c:6187
0x6141d0 c_parser_expr_no_commas
../../gcc-trunk/gcc/c/c-parser.c:6104
0x6148f2 c_parser_expression
../../gcc-trunk/gcc/c/c-parser.c:8250
0x615339 c_parser_expression_conv
../../gcc-trunk/gcc/c/c-parser.c:8283
0x62e4d1 c_parser_statement_after_labels
../../gcc-trunk/gcc/c/c-parser.c:5177
0x630594 c_parser_compound_statement_nostart
../../gcc-trunk/gcc/c/c-parser.c:4762
0x63098e c_parser_compound_statement
../../gcc-trunk/gcc/c/c-parser.c:4599
0x62c54b c_parser_declaration_or_fndef
../../gcc-trunk/gcc/c/c-parser.c:2017
0x637e6d c_parser_external_declaration
../../gcc-trunk/gcc/c/c-parser.c:1461
0x638869 c_parser_translation_unit
../../gcc-trunk/gcc/c/c-parser.c:1348
0x638869 c_parse_file()
../../gcc-trunk/gcc/c/c-parser.c:17658
0x6988d2 c_common_parse_file()
../../gcc-trunk/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


---


int a;

void
fn1 ()
{
  a != (0, 0); 
}

[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250

[adam at os dot inf.tu-dresden.de]

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

Adam Lackorzynski  changed:

   What|Removed |Added

 CC||adam at os dot 
inf.tu-dresden.de

--- Comment #25 from Adam Lackorzynski  ---
I've also came across this ICE, with this reduced testcase:

template< typename C > class Dl
{
  class __ii { };
  typedef __ii It;
  It ii(typename C::I *e) { return It(e); }
};

template class X1 { typename E::L foo; };

struct M
{
  struct CO { typedef M I; };
  enum Type { };
  typedef Dl L;
  Type t;
  struct R { X1 f; };
};

With: gcc version 6.0.0 20151119 (experimental) (GCC) 

t.i: In instantiation of ‘class Dl’:
t.i:8:47:   required from ‘class X1’
t.i:16:20:   required from here
t.i:1:30: error: TYPE_CANONICAL is not compatible
 template< typename C > class Dl
  ^~

 
asm_written unsigned SI
size 
unit size 
align 32 symtab -862572224 alias set -1 canonical type
0x7f1ccca8c348 precision 32 min  max  context 
chain >
decl_3 VOID file t.i line 15 col 8
align 1 offset_align 1 context 
chain 
used nonlocal decl_4 VOID file t.i line 11 col 1
align 1 context  result 
chain >> context

full-name "struct M"
n_parents=0 use_template=0 interface-unknown
pointer_to_this  chain >
 
full-name "struct M"
n_parents=0 use_template=0 interface-unknown
chain >
used nonlocal decl_4 VOID file t.i line 11 col 1
align 1 context 
result  context

full-name "struct M"
n_parents=0 use_template=0 interface-unknown
pointer_to_this  chain >

chain 
public decl_2 VOID file t.i line 12 col 10
align 8 context  chain >> context 
full-name "M::CO::I"
n_parents=0 use_template=0 interface-unknown
pointer_to_this  chain >
t.i:1:30: internal compiler error: verify_type failed
0xf75d1c verify_type(tree_node const*)
../../gcc/gcc/tree.c:13818
0x991de4 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20739
0x992428 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20836
0x9932e6 gen_type_die
../../gcc/gcc/dwarf2out.c:20932
0x99efb7 gen_formal_types_die
../../gcc/gcc/dwarf2out.c:18283
0x9978b5 gen_subprogram_die
../../gcc/gcc/dwarf2out.c:19141
0x9996ac gen_decl_die
../../gcc/gcc/dwarf2out.c:21496
0x994563 gen_member_die
../../gcc/gcc/dwarf2out.c:20432
0x994563 gen_struct_or_union_type_die
../../gcc/gcc/dwarf2out.c:20516
0x994563 gen_tagged_type_die
../../gcc/gcc/dwarf2out.c:20717
0x99278d gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20877
0x9932e6 gen_type_die
../../gcc/gcc/dwarf2out.c:20932
0x999c71 gen_decl_die
../../gcc/gcc/dwarf2out.c:21519
0x99a6bc dwarf2out_decl
../../gcc/gcc/dwarf2out.c:21974
0x99a9fb dwarf2out_type_decl
../../gcc/gcc/dwarf2out.c:21684
0xc0175f rest_of_type_compilation(tree_node*, int)
../../gcc/gcc/passes.c:335
0x6b0956 finish_struct_1(tree_node*)
../../gcc/gcc/cp/class.c:6776
0x67ff9b instantiate_class_template_1
../../gcc/gcc/cp/pt.c:10198
0x67ff9b instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:10238
0x723f4b complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:131
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug ada/68443] [ada] FAIL: c39006b

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||charlet at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #2 from Arnaud Charlet  ---
was fixed on revision 230617

[Bug jit/68446] jit testsuite failures seen inside dwarf2out.c:gen_producer_string

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
(In reply to David Malcolm from comment #0)
[...]
> I ran a git bisect, it indicated that the failure of test-volatile.c was
> introduced by:
> 
> commit 25faed340686df8d7bb2242dc8d04285976922b6
> Author: marxin 
> Date:   Thu Nov 12 15:50:05 2015 +
> 
> Fix big memory leak in ix86_valid_target_attribute_p
> 
> * config/i386/i386.c (ix86_valid_target_attribute_p):
> Finalize options at the of the function.
> * gcc.c (driver_get_configure_time_options): Call newly
> introduced init_opts_obstack.
> * lto-wrapper.c (main): Likewise.
> * opts.c (init_opts_obstack): New function.
> (init_options_struct): Call newly
> introduced init_opts_obstack.
> * opts.h (init_options_struct): Declare.

i.e. r230264 (hopefully bugzilla will URL-ify this)

[Bug jit/68446] New: jit testsuite failures seen inside dwarf2out.c:gen_producer_string

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 68446
   Summary: jit testsuite failures seen inside
dwarf2out.c:gen_producer_string
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

At r230562 (aka 21a6b87b86defda10ac903a9cd49e34b1f8ce6fb) jit.sum has:
  # of expected passes1711
  # of unexpected failures60
  # of unresolved testcases   2
as compared to e.g. trunk from July (r226339;
1ae7fdc96dfbbd74f29a0d563fa7641c1563d615) which has jit.sum:
  # of expected passes6372
  # of unexpected failures1
(where: FAIL: jit.dg/test-threads.c, initial compilation, due to:
/home/david/coding-3/gcc-git-jit-clean/src/gcc/testsuite/jit.dg/harness.h:25:14:
error: static declaration of 'dejagnu_pass' follows non-static declaration
/home/david/coding-3/gcc-git-jit-clean/src/gcc/testsuite/jit.dg/test-threads.c:23:6:
note: previous declaration of 'dejagnu_pass' was here
(I think I've fixed this other failure).

i.e. lots of major failures.

They seem to mostly be an ICE in:
0x7f9d586ee332 gen_producer_string
../../src/gcc/dwarf2out.c:20139
0x7f9d586ee332 dwarf2out_finish
../../src/gcc/dwarf2out.c:25250

due to this assertion failing:
20139 gcc_checking_assert (save_decoded_options[j].canonical_option[0][0]
20140  == '-');

A minimal reproducer is e.g. test-volatile.c

As far as I can tell, save_decoded_options[3] and [4] canonical_option
fieldhave become the empty string (or corrupt?); the loop is accessing 0..9,
and dies with j == 3:
(gdb) p save_decoded_options[0]
$6 = {opt_index = 1432, warn_message = 0x0, 
  arg = 0x606120
"/home/david/coding-3/gcc-git-clean/build-with-jit/gcc/test-volatile.c.exe", 
  orig_option_with_args_text = 0x606120
"/home/david/coding-3/gcc-git-clean/build-with-jit/gcc/test-volatile.c.exe", 
  canonical_option = {0x606120
"/home/david/coding-3/gcc-git-clean/build-with-jit/gcc/test-volatile.c.exe",
0x0, 0x0, 0x0}, 
  canonical_option_num_elements = 1, value = 1, errors = 0}
(gdb) p save_decoded_options[1]
$7 = {opt_index = 1433, warn_message = 0x0, arg = 0x606b50
"/tmp/libgccjit-8Mwbrw/fake.c", 
  orig_option_with_args_text = 0x606b50 "/tmp/libgccjit-8Mwbrw/fake.c",
canonical_option = {
0x606b50 "/tmp/libgccjit-8Mwbrw/fake.c", 0x0, 0x0, 0x0},
canonical_option_num_elements = 1, value = 1, errors = 0}
(gdb) p save_decoded_options[2]
$8 = {opt_index = 486, warn_message = 0x0, arg = 0x0,
orig_option_with_args_text = 0x608340 "", canonical_option = {
0x775b9759 "-fPIC", 0x0, 0x0, 0x0}, canonical_option_num_elements = 1,
value = 1, errors = 0}
(gdb) p save_decoded_options[3]
$9 = {opt_index = 139, warn_message = 0x0, arg = 0x606e42 "3",
orig_option_with_args_text = 0x608360 "\377\377\001", 
  canonical_option = {0x608350 "", 0x0, 0x0, 0x0},
canonical_option_num_elements = 1, value = 1, errors = 0}
(gdb) p save_decoded_options[4]
$10 = {opt_index = 1126, warn_message = 0x0, arg = 0x606e62 "",
orig_option_with_args_text = 0x608380 "\200", canonical_option = {
0x608370 "", 0x0, 0x0, 0x0}, canonical_option_num_elements = 1, value = 1,
errors = 0}

I ran a git bisect, it indicated that the failure of test-volatile.c was
introduced by:

commit 25faed340686df8d7bb2242dc8d04285976922b6
Author: marxin 
Date:   Thu Nov 12 15:50:05 2015 +

Fix big memory leak in ix86_valid_target_attribute_p

* config/i386/i386.c (ix86_valid_target_attribute_p):
Finalize options at the of the function.
* gcc.c (driver_get_configure_time_options): Call newly
introduced init_opts_obstack.
* lto-wrapper.c (main): Likewise.
* opts.c (init_opts_obstack): New function.
(init_options_struct): Call newly
introduced init_opts_obstack.
* opts.h (init_options_struct): Declare.


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

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[ch3root at openwall dot com]

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

--- Comment #18 from Alexander Cherepanov  ---
A bit simplified variant:

#include 

int main()
{
   int x, y = 1;
   int *volatile v;
   int *p;

   v = &y;
   p = v;
   if (p == &x + 1) {
 *p = 2;
 printf("y = %d\n", y);
   }
}

077t.alias dump shows such "Points-to sets" (among others):

v = { y }
p_5 = { y } same as v

and then the code:

   :
   *p_5 = 2;
   y.0_7 = y;
   printf ("y = %d\n", y.0_7);

Seems right.

081t.vrp1 dump shows such "Value ranges after VRP":

p_11: [&MEM[(void *)&x + 4B], &MEM[(void *)&x + 4B]]  EQUIVALENCES: { 
p_5 } (1 elements)

and the code:

   :
   MEM[(int *)&x + 4B] = 2;
   y.0_7 = y;
   printf ("y = %d\n", y.0_7);

Seems wrong.

gcc 5.2.0

On 2015-11-16 01:30, ch3root at openwall dot com wrote:
> I guess it depends on the transitivity of the == operator. After this bug is
> fixed it will be possible to constuct a third pointer r from two pointer p and
> q such that r == p and r == q but p != q. For p and q take &x + 1 and &y as
> above, obtain r by stripping provenance info from p or q (e.g. by printf/scanf
> with %p).

This bug turned out to be not that tricky after all. The program:

#include 

int main()
{
   int x, y;
   void *p = &x + 1, *q = &y, *r;

   /* Strip p of provenance info */
   /* To simplify testing: */
   char s[100]; sprintf(s, "%p", p); sscanf(s, "%p", &r);
   /* Instead, imagine this:
   printf("%p or %p? ", p, q); scanf("%p", &r);
   */

   char *eq[] = {"!=", "=="};
   printf("r %s p, r %s q, p %s q\n", eq[r == p], eq[r == q], eq[p == q]);
}

prints "r == p, r == q, p != q" and the first two equalities are 
essentially mandated by C11 (unless you patch it by making one of them UB).

[Bug fortran/66762] ICE when compiling gfortran.dg/submodule_[16].f90 with -flto

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> The attached patch fixes the problem but is, as yet, not regtested.

Confirmed and regtested without regression. Thanks.

[Bug tree-optimization/68445] New: ICE: internal compiler error: in operator[], at vec.h

[pthaugen at gcc dot gnu.org]

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

Bug ID: 68445
   Summary: ICE: internal compiler error: in operator[], at vec.h
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

See the following using current trunk (r230619).

[pthaugen@igoo delta]$ cat junk.c
void IMB_double_fast_x (float *destf, int *dest, int y, float *p1f)
{
  int i;
  for (i = y; i > 0; i--)
{
  *dest++ = 0;
  destf[0] = destf[4] = p1f[0];
  destf[1] = destf[5] = p1f[1];
  destf[2] = destf[6] = p1f[2];
  destf[3] = destf[7] = p1f[3];
  destf += 8;
  p1f += 4;
}
}


[pthaugen@igoo delta]$ ~/install/gcc/trunk/bin/gcc -c -O3 -mcpu=power8 junk.c
junk.c: In function ‘IMB_double_fast_x’:
junk.c:1:6: internal compiler error: in operator[], at vec.h:714
 void IMB_double_fast_x (float *destf, int *dest, int y, float *p1f)
  ^

0x10aedf43 vec::operator[](unsigned int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/vec.h:714
0x10aedf43 vec::operator[](unsigned int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/vec.h:1180
0x10aedf43 vect_create_mask_and_perm
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-slp.c:3195
0x10aedf43 vect_transform_slp_perm_load(_slp_tree*, vec, gimple_stmt_iterator*, int, _slp_instance*, bool)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-slp.c:3458
0x10abf86b vectorizable_load
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-stmts.c:7196
0x10aca8cf vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
_slp_tree*, _slp_instance*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-stmts.c:8046
0x10af2737 vect_schedule_slp_instance
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-slp.c:3608
0x10af27b7 vect_schedule_slp_instance
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-slp.c:3489
0x10af3057 vect_schedule_slp(vec_info*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-slp.c:3673
0x10ad4a03 vect_transform_loop(_loop_vec_info*)
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vect-loop.c:6747
0x10afcdbb vectorize_loops()
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-vectorizer.c:548
0x109d2103 execute
/home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-loop.c:276

[Bug other/68444] New: [libvtv] All libvtv tests fail for powerpc*-*-linux* (undefined references)

[wschmidt at gcc dot gnu.org]

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

Bug ID: 68444
   Summary: [libvtv] All libvtv tests fail for powerpc*-*-linux*
(undefined references)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
CC: dje.gcc at gmail dot com
  Target Milestone: ---
  Host: powerpc*-*-linux*
Target: powerpc*-*-linux*
 Build: powerpc*-*-linux*

I attempted enabling libvtv for power*-*-linux* today by setting
VTV_SUPPORTED=yes in libvtv/configure.tgt.  The build and installation of
libvtv all succeeded.  However, all of the tests in the test suite fail.

Looking at the libvtv.log file, the failures all involve linkage errors like
these:

bb_tests.cc:(.text+0x174): undefined reference to
`__VLTVerifyVtablePointer(void
**, void const*)'

bb_tests.cc:(.text+0x29c): undefined reference to `__VLTRegisterSet(void**,
void
 const*, unsigned long, unsigned long, void**)'

nested_vcall_test.cc:(.text+0x3f8): undefined reference to
`__VLTRegisterPair(vo
id**, void const*, unsigned long, void const*)'

register_set_pair.cc:(.text+0x380): undefined reference to
`__VLTChangePermission'

[Bug ada/68443] [ada] FAIL: c39006b

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed between revisions r230509 (PASS) and r230581 (FAIL).

[Bug other/67868] ICE in handling VTV sections for targets with section anchors.

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
However, I should note that although libvtv builds and installs for Power, it
fails the testsuite completely, so we are going to leave this disabled for now.
 I'll open a bug report on the test failures.

[Bug c++/68396] function auto-deduced return types get incorrectly classified as parameter packs

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Nov 19 18:25:38 2015
New Revision: 230620

URL: https://gcc.gnu.org/viewcvs?rev=230620&root=gcc&view=rev
Log:
PR c++/68396

2015-11-19  Ryan Burn  

* pt.c (find_parameter_packs_r) [DECLTYPE_TYPE]: When traversing
the DECLTYPE_TYPE_EXPR, set type_pack_expansion_p to false.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr68396.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug ada/68443] New: [ada] FAIL: c39006b

[vries at gcc dot gnu.org]

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

Bug ID: 68443
   Summary: [ada] FAIL: c39006b
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With r230596:
...
RUN c39006b

,.,. C39006B ACATS 2.5 15-11-19 04:41:57
 C39006B CHECK THAT PROGRAM_ERROR IS RAISED IF AN ATTEMPT IS MADE TO
CALL A SUBPROGRAM WHOSE BODY HAS NOT YET BEEN
ELABORATED.
   * C39006B PROGRAM_ERROR NOT RAISED - 2.
 C39006B FAILED .
FAIL:   c39006b
...

[Bug c++/68427] GCC (G++) flunks legal ANSI-C code

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to wam from comment #3)
> comment 1: How do I go about doing that (posting preprocessed source file) ?

It's explained at the link you should have read before creating a bug:
https://gcc.gnu.org/bugs/

> The tarball I uploaded just has 2 text files showing the output of my effort
> to compile the code, & the code in its own tarball.

Yes I know, I used the same commands as you showed in your file, and it
compiled successfully.

> comment 2: The code was ANSI-C for about 15 years (from ~1995 on), then
> converted to C++ by simply renaming it to gauss.cpp & overloading the names
> of the various gauss functions. It is otherwise legal ANSI C code.

But that's irrelevant. It's *not* ANSI C code if you've used overloaded
functions, and you're compiling it as C++ anyway so it's besides the point. C
and C++ are different languages, just because something used to be valid C
doesn't mean failing to compile as C++ indicates a compiler bug.

> As to the
> makefile, I used GCC 4.8.5, pkg-installed, i.e. compiled up by the FreeBSD
> folks & retreived by me from their repo. I compiled the GCC5.2.1 up myself,
> adding Graphite support (recently accomodated by the GCC maintainer(s)). I
> did nothing to the makefile myself. I originally posted this to the
> FreeBSD-toolchain list & was advised to repost it here. When you compile it,
> are you using FreeBSD 9.3R to do so, or another implementation ?

I only tried on GNU/Linux. The errors shown in your file are not
platform-specific, they suggest a header file was missing or something like
that.

[Bug fortran/68442] ICE on kind specification, depending on ordering of functions

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Detected with reversed order :


$ cat z2.f90
module m
   interface gkind
  procedure g
   end interface
contains
   integer function g()
  g = 1
   end
   subroutine f(x)
  character(kind=gkind()) :: x
   end
end


$ gfortran-5 -g -O0 -Wall -fcheck=all z2.f90
z2.f90:10:21:

   character(kind=gkind()) :: x
 1
Error: Function 'gkind' in initialization expression at (1) must be an
intrinsic function

[Bug fortran/68442] New: ICE on kind specification, depending on ordering of functions

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 68442
   Summary: ICE on kind specification, depending on ordering of
functions
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Using this order (f before g) :


$ cat z1.f90
module m
   interface gkind
  procedure g
   end interface
contains
   subroutine f(x)
  character(kind=gkind()) :: x
   end
   integer function g()
  g = 1
   end
end


$ gfortran-5 -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: in gfc_arglist_matches_symbol, at
fortran/interface.c:3468

[Bug fortran/68441] New: ICE on using transfer with character parameter

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 68441
   Summary: ICE on using transfer with character parameter
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

For some tests of "TRANSFER (TRANSFER (E, D), E)" :

$ cat z1.f90
program p
   character(huge(1_1)), parameter :: x = 'abc'
   print *, transfer(transfer(0, x), 0)
end

$ gfortran-5 -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: in gfc_interpret_character, at
fortran/target-memory.c:458

---

Whereas :

$ cat z2.f90
program p
   character(huge(1_1)) :: x = 'abc'
   print *, transfer(transfer(0, x), 0)
end

$ gfortran-5 -g -O0 -Wall -fcheck=all z2.f90
z2.f90:3:30:

print *, transfer(transfer(0, x), 0)
  1
Warning: Intrinsic TRANSFER at (1) has partly undefined result: source size 4 <
result size 127

$ a.out
   0

[Bug fortran/68440] ICE on declaring class variable with wrong attribute

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
Detected :

$ cat z7.f90
subroutine s
   type t
   end type
   class(t), allocatable :: x = t()
end

$ gfortran -g -O0 -Wall -fcheck=all z7.f90
z7.f90:4:29:

class(t), allocatable :: x = t()
 1
Error: Allocatable 'x' at (1) cannot have an initializer

---

$ cat z8.f90
subroutine s
   type t
   end type
   class(t), allocatable :: x
   x = t()
end

$ gfortran -g -O0 -Wall -fcheck=all z8.f90
z8.f90:5:3:

x = t()
   1
Error: Assignment to an allocatable polymorphic variable at (1) is not yet
supported

[Bug fortran/68440] ICE on declaring class variable with wrong attribute

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Some variants :

$ cat z4.f90
subroutine s
   type t
   end type
   class(t), parameter :: x = t()
end

$ gfortran -g -O0 -Wall -fcheck=all z4.f90
f951: internal compiler error: Segmentation fault

---

$ cat z5.f90
subroutine s
   type t
   end type
   class(t) :: x = t()
end

$ gfortran -g -O0 -Wall -fcheck=all z5.f90
z5.f90:4:16:

class(t) :: x = t()
1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer
(null):0: confused by earlier errors, bailing out

[Bug fortran/68440] New: ICE on declaring class variable with wrong attribute

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 68440
   Summary: ICE on declaring class variable with wrong attribute
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This wrong code (class not allocatable nor pointer) :

$ cat z1.f90
subroutine s
   type t
   end type
   class(t), parameter :: x = t()
   class(t), parameter :: y = x
end

$ gfortran -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: in check_alloc_comp_init, at fortran/expr.c:2209

---

$ cat z2.f90
subroutine s
   type t
   end type
   class(t), parameter :: x = t()
   class(t) :: y = x
end

$ gfortran -g -O0 -Wall -fcheck=all z2.f90
f951: internal compiler error: in check_alloc_comp_init, at fortran/expr.c:2209

[Bug fortran/68439] New: ICE in alloc_scalar_allocatable_for_subcomponent_assignment, at fortran/trans-expr.c:6711

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 68439
   Summary: ICE in
alloc_scalar_allocatable_for_subcomponent_assignment,
at fortran/trans-expr.c:6711
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

One dedicated case and error message. Issue related with pr68225.

$ cat z1.f90
program p
   type t
  integer :: a
  character(:), allocatable :: c
   end type
   type(t) :: x
   x = t(a=1)
end


$ gfortran -g -O0 -Wall -fcheck=all -c z1.f90
z1.f90:7:0:

x = t(a=1)
 1
internal compiler error: in
alloc_scalar_allocatable_for_subcomponent_assignment, at
fortran/trans-expr.c:6711

[Bug testsuite/66621] [4.9/5 Regression] Mistakenly unsupported tests in g++.dg/torture/

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
I guess not severe enough to backport.  Thus fixed for 6.1+.

[Bug target/67089] [4.9/5/6 Regression] Integer overflow checks not optimized on x86/x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Note this affects even code generated with __builtin_sub_overflow.

[Bug target/68421] unused copy of global register variable into another gpr

[acsawdey at gcc dot gnu.org]

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
So, looking at the dump files, at the end of tree form we have copies from the
register globals and uses of the copies only:

  :
  execute_data.0_4 = execute_data;
  opline.1_5 = opline;
  _6 = opline.1_5->op1.var;

Then after reload, those temps get allocated to 8 and 10 and only 8/10 are used
after the initial copy:

(insn 8 2 7 2 (set (reg/f:DI 8 8 [orig:157 opline.1_5 ] [157])
(reg/v:DI 29 29 [ opline ])) min_unused_regs10.c:51 538
{*movdi_internal64}
 (nil))
(insn 7 8 9 2 (set (reg/f:DI 10 10 [orig:156 execute_data.0_4 ] [156])
(reg/v:DI 28 28 [ execute_data ])) min_unused_regs10.c:51 538
{*movdi_internal64}
 (nil))
(insn 9 7 10 2 (set (reg:DI 6 6 [orig:172 opline.1_5->op1.var ] [172])
(sign_extend:DI (mem:SI (reg/f:DI 8 8 [orig:157 opline.1_5 ] [157]) [0
opline.1_5->op1.var+0 S4 A32]))) min_unused_regs10.c:41 46 {extendsidi2}
 (nil))
(insn 10 9 11 2 (set (reg/f:DI 9 9 [orig:169 _29 ] [169])
(plus:DI (reg/f:DI 10 10 [orig:156 execute_data.0_4 ] [156])
(reg:DI 6 6 [orig:172 opline.1_5->op1.var ] [172])))
min_unused_regs10.c:41 81 {*adddi3}
 (nil))

Then after cprop_hardreg, the uses of 8/10 are replaced with 29/28 except for
that initial copy which is what remains:

(insn 8 2 7 2 (set (reg/f:DI 8 8 [orig:157 opline.1_5 ] [157])
(reg/v:DI 29 29 [ opline ])) min_unused_regs10.c:51 538
{*movdi_internal64}
 (nil))
(insn 7 8 9 2 (set (reg/f:DI 10 10 [orig:156 execute_data.0_4 ] [156])
(reg/v:DI 28 28 [ execute_data ])) min_unused_regs10.c:51 538
{*movdi_internal64}
 (nil))
(insn 9 7 10 2 (set (reg:DI 6 6 [orig:172 opline.1_5->op1.var ] [172])
(sign_extend:DI (mem:SI (reg/f:DI 29 29 [orig:157 opline.1_5 ] [157])
[0 opline.1_5->op1.var+0 S4 A32]))) min_unused_regs10.c:41 46 {extendsidi2}
 (nil))
(insn 10 9 11 2 (set (reg/f:DI 9 9 [orig:169 _29 ] [169])
(plus:DI (reg/f:DI 28 28 [orig:156 execute_data.0_4 ] [156])
(reg:DI 6 6 [orig:172 opline.1_5->op1.var ] [172])))
min_unused_regs10.c:41 81 {*adddi3}
 (nil))

[Bug objc/68438] New: [6 Regression] Conditional jump or move depends on uninitialised value in location_adhoc_data_eq (line-map.c:89)

[marxin at gcc dot gnu.org]

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

Bug ID: 68438
   Summary: [6 Regression] Conditional jump or move depends on
uninitialised value in location_adhoc_data_eq
(line-map.c:89)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi.

Looks objc test-suite contains many valgrind errors:

Command:
valgrind --leak-check=yes --trace-children=yes --num-callers=100 gcc
/home/marxin/Programming/gcc/gcc/testsuite/objc.dg/call-super-2.m -c

==8665== Conditional jump or move depends on uninitialised value(s)
==8665==at 0x169A8D6: location_adhoc_data_eq(void const*, void const*)
(line-map.c:89)
==8665==by 0x16CDB3C: htab_find_slot_with_hash (hashtab.c:679)
==8665==by 0x169B5DC: get_combined_adhoc_loc(line_maps*, unsigned int,
source_range, void*) (line-map.c:214)
==8665==by 0xFFEAE9: COMBINE_LOCATION_DATA(line_maps*, unsigned int,
source_range, void*) (line-map.h:1004)
==8665==by 0xFFCE0B: set_source_range(tree_node*, source_range)
(tree.c:13936)
==8665==by 0xFFCD5A: set_source_range(tree_node*, unsigned int, unsigned
int) (tree.c:13923)
==8665==by 0x804E73: c_fully_fold_internal(tree_node*, bool, bool*, bool*,
bool) (c-common.c:1639)
==8665==by 0x803C7A: c_fully_fold_internal(tree_node*, bool, bool*, bool*,
bool) (c-common.c:1372)
==8665==by 0x803497: c_fully_fold(tree_node*, bool, bool*)
(c-common.c:1162)
==8665==by 0x7CA952: build_modify_expr(unsigned int, tree_node*,
tree_node*, tree_code, unsigned int, tree_node*, tree_node*) (c-typeck.c:5545)
==8665==by 0x7DA5F8: c_parser_expr_no_commas(c_parser*, c_expr*,
tree_node*) (c-parser.c:6149)
==8665==by 0x7E0CFF: c_parser_expression(c_parser*) (c-parser.c:8250)
==8665==by 0x7E0F38: c_parser_expression_conv(c_parser*) (c-parser.c:8283)
==8665==by 0x7D82FF: c_parser_statement_after_labels(c_parser*,
vec*) (c-parser.c:5177)
==8665==by 0x7D781D: c_parser_compound_statement_nostart(c_parser*)
(c-parser.c:4762)
==8665==by 0x7D724D: c_parser_compound_statement(c_parser*)
(c-parser.c:4599)
==8665==by 0x7E1FFC: c_parser_objc_method_definition(c_parser*)
(c-parser.c:8821)
==8665==by 0x7D0FA9: c_parser_external_declaration(c_parser*)
(c-parser.c:1449)
==8665==by 0x7D0BF1: c_parser_translation_unit(c_parser*) (c-parser.c:1348)
==8665==by 0x7FB922: c_parse_file() (c-parser.c:17658)
==8665==by 0x850A92: c_common_parse_file() (c-opts.c:1064)
==8665==by 0xD41AF8: compile_file() (toplev.c:464)
==8665==by 0xD43F4F: do_compile() (toplev.c:1951)
==8665==by 0xD441CE: toplev::main(int, char**) (toplev.c:2058)
==8665==by 0x166391D: main (main.c:39)
==8665== 
/home/marxin/Programming/gcc/gcc/testsuite/objc.dg/call-super-2.m:134:4:
warning: ‘-categ_instance_func2’ not found in protocol(s)
i += (size_t)[(id )self categ_instance_func2];  /* { dg-warning
".\\-categ_instance_func2. not found in protocol" } */
^

/home/marxin/Programming/gcc/gcc/testsuite/objc.dg/call-super-2.m:136:4:
warning: ‘TestsuiteObject’ may not respond to ‘-instance_func0’
return i + (size_t)[super instance_func0];   /* { dg-warning
".TestsuiteObject. may not respond to .\\-instance_func0." } */
^~

==8665== Use of uninitialised value of size 8
==8665==at 0x16CDA83: htab_find_slot_with_hash (hashtab.c:655)
==8665==by 0x169B5DC: get_combined_adhoc_loc(line_maps*, unsigned int,
source_range, void*) (line-map.c:214)
==8665==by 0xFFEAE9: COMBINE_LOCATION_DATA(line_maps*, unsigned int,
source_range, void*) (line-map.h:1004)
==8665==by 0xFFCD27: set_block(unsigned int, tree_node*) (tree.c:13914)
==8665==by 0x156A9C4: gimple_set_block(gimple*, tree_node*) (gimple.h:1744)
==8665==by 0x156B4A6: lower_stmt(gimple_stmt_iterator*, lower_data*)
(gimple-low.c:236)
==8665==by 0x156B3D8: lower_sequence(gimple**, lower_data*)
(gimple-low.c:203)
==8665==by 0x156B586: lower_stmt(gimple_stmt_iterator*, lower_data*)
(gimple-low.c:272)
==8665==by 0x156B3D8: lower_sequence(gimple**, lower_data*)
(gimple-low.c:203)
==8665==by 0x156B94E: lower_gimple_bind(gimple_stmt_iterator*, lower_data*)
(gimple-low.c:418)
==8665==by 0x156B0EB: lower_function_body() (gimple-low.c:107)
==8665==by 0x156B33C: (anonymous
namespace)::pass_lower_cf::execute(function*) (gimple-low.c:181)
==8665==by 0xC39BF9: execute_one_pass(opt_pass*) (passes.c:2335)
==8665==by 0xC39EFC: execute_pass_list_1(opt_pass*) (passes.c:2408)
==8665==by 0xC39F85: execute_pass_list(function*, opt_pass*)
(passes.c:2419)
==8665==by 0x904119: cgraph_node::analyze() (cgraphunit.c:634)
==8665==by 0x9051B9: analyze_functions(bool) (cgraphunit.c:1078)
==8665==by 0x908B48: symbol_table::finalize_compilation_unit()
(cgrap

[Bug tree-optimization/46032] openmp inhibits loop vectorization

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
(In reply to vries from comment #20)
> This patch seems to have the desired effect on the original testcase: 
> ...
> diff --git a/gcc/omp-low.c b/gcc/omp-low.c
> index 830db75..996756b 100644
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -9361,6 +9361,7 @@ expand_omp_for_static_nochunk (struct omp_region
> *region,
>if (collapse_bb == NULL)
> loop->latch = cont_bb;
>add_loop (loop, body_bb->loop_father);
> +  loop->safelen = INT_MAX;
>  }
>  }
> ...
> 
> AFAIU, adding the omp for to the loop is an assertion that the loop is
> independent. It seems reasonable to assume that if the original loop was
> independent, the loop operating on a slice of the original iteration space
> will be independent as well.

That is very much wrong.  Static scheduling, both nochunk and chunk, doesn't
imply in any way that the iterations are independent, the OpenMP standard says
how the work is split among the threads, with nochunk that threads get
consecutive sets of iterations as one chunk that are approximately the same
size, but eventhough it is not exactly specified how exactly the iteration
space is deviced (for nochunk), if you make the loop iterations independent,
you would break many observable properties (say through threadprivate vars,
omp_get_thread_num etc.).
Note loop->safelen == INT_MAX is actually weaker than independent iterations,
when loop->safelen == INT_MAX, there can be dependencies, but only of certain
kinds, it says that it is equivalent if you run the loop normally and if you
run simultaneously (or emulated) the first statements of all the iterations,
then second statements and so on (so vectorize with any vectorization factor
the compiler wants).

[Bug rtl-optimization/68392] ICE: SIGSEGV in update_uses (fwprop.c:896) with -fno-checking

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-19
 Ever confirmed|0   |1

--- Comment #7 from Mikhail Maltsev  ---
Yes, it helps. Also consider adding this testcase to g++.dg (used to ICE on
x86_64):

// PR rtl-optimization/68392
// { dg-do compile }
// { dg-options "-O -fno-checking" }

void tool_cleanup(bool from_signal)
{
  tool_cleanup(from_signal);
}

[Bug tree-optimization/46032] openmp inhibits loop vectorization

[vries at gcc dot gnu.org]

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

--- Comment #20 from vries at gcc dot gnu.org ---
This patch seems to have the desired effect on the original testcase: 
...
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 830db75..996756b 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -9361,6 +9361,7 @@ expand_omp_for_static_nochunk (struct omp_region *region,
   if (collapse_bb == NULL)
loop->latch = cont_bb;
   add_loop (loop, body_bb->loop_father);
+  loop->safelen = INT_MAX;
 }
 }
...

AFAIU, adding the omp for to the loop is an assertion that the loop is
independent. It seems reasonable to assume that if the original loop was
independent, the loop operating on a slice of the original iteration space will
be independent as well.

[Bug preprocessor/60736] [4.9 Regression] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] Crash  |[4.9 Regression] Crash in
   |in preprocessor including   |preprocessor including
   |stdc-predef.h when it does  |stdc-predef.h when it does
   |not exist on glibc-based|not exist on glibc-based
   |systems |systems

--- Comment #17 from Jakub Jelinek  ---
Fixed for 5.3+ so far.

[Bug target/67770] [4.9 Regression] i386: -fshrink-wrap can interact badly with trampolines

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] i386:  |[4.9 Regression] i386:
   |-fshrink-wrap can interact  |-fshrink-wrap can interact
   |badly with trampolines  |badly with trampolines

--- Comment #7 from Jakub Jelinek  ---
Fixed for 5.3+ so far.

[Bug c++/67409] [5/6 Regression] tree-cfg.c dereferences a NULL pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed for 5.3+.

[Bug rtl-optimization/68376] [4.9 Regression] wrong code at -O1 and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] wrong  |[4.9 Regression] wrong code
   |code at -O1 and above on|at -O1 and above on
   |x86_64-linux-gnu|x86_64-linux-gnu

--- Comment #7 from Jakub Jelinek  ---
Fixed for 5.3+ so far.

[Bug c++/68409] Garbage added to a map instead of object

[f3rn4nd0.c354r+gcc at gmail dot com]

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

--- Comment #1 from f3rn4nd0.c354r  ---
I forget to specify the compilation options used:

-std=c++11 -Wall -Wextra -save-temps

[Bug c++/67409] [5/6 Regression] tree-cfg.c dereferences a NULL pointer

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 19 16:34:32 2015
New Revision: 230616

URL: https://gcc.gnu.org/viewcvs?rev=230616&root=gcc&view=rev
Log:
PR c++/67409
* decl.c (identify_goto): Add LOC and DIAG_KIND arguments, call
emit_diagnostic instead of permerror.
(check_previous_goto_1): Adjust identify_goto callers, treat all
cases but crossing initialization and entering scope of decl with
non-trivial dtor as unconditional hard errors.
(check_goto): Use identify_goto.  Treat all cases but crossing
initialization and entering scope of decl with non-trivial dtor
as unconditional hard errors.

* g++.dg/eh/goto3.C: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/eh/goto3.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/decl.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt

[alahay01 at gcc dot gnu.org]

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

alahay01 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |alahay01 at gcc dot 
gnu.org

--- Comment #8 from alahay01 at gcc dot gnu.org ---
>Probably compute reduction type at analysis phase only?

I had come to the same conclusion myself :)

Initially I was going to ignore base in is_nonwrapping_integer_induction (),
but that is not a good idea.

I'm writing a patch now. There's a few places more places than I expected to
add checks for the analysis phase.

[Bug other/67868] ICE in handling VTV sections for targets with section anchors.

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
Thanks, Ramana!  I've verified that this is working ok for Power as well.

[Bug rtl-optimization/68392] ICE: SIGSEGV in update_uses (fwprop.c:896) with -fno-checking

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #6 from Michael Matz  ---
Should be fixed with r230612.  Can you confirm?

[Bug c++/67409] [5/6 Regression] tree-cfg.c dereferences a NULL pointer

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 19 16:18:39 2015
New Revision: 230613

URL: https://gcc.gnu.org/viewcvs?rev=230613&root=gcc&view=rev
Log:
PR c++/67409
* decl.c (identify_goto): Add LOC and DIAG_KIND arguments, call
emit_diagnostic instead of permerror.
(check_previous_goto_1): Adjust identify_goto callers, treat all
cases but crossing initialization and entering scope of decl with
non-trivial dtor as unconditional hard errors.
(check_goto): Use identify_goto.  Treat all cases but crossing
initialization and entering scope of decl with non-trivial dtor
as unconditional hard errors.

* g++.dg/eh/goto3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/eh/goto3.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68437] New: [concepts] fold expression, pack expansion, and deduced constraint requirement

[lucdanton at free dot fr]

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

Bug ID: 68437
   Summary: [concepts] fold expression, pack expansion, and
deduced constraint requirement
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

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

This is using g++-trunk (GCC) 6.0.0 20151103 (experimental). Attached testcase
is as minimal as I could manage. If I change the fold expression in the
requirement to a 'manual', compile-time fold (not included in the testcase for
brevity) then the program compiles as expected--this is the workaround that I'm
using in the meantime.

[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization

[ysrumyan at gmail dot com]

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

--- Comment #4 from Yuri Rumyantsev  ---
Created attachment 36774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36774&action=edit
tar file

tar file contains good and bad ce1-rtl dumps showing the problem

[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-19
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Thanks to both of you for the info.
I've reproduced this.

[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization

[afomin.mailbox at gmail dot com]

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

--- Comment #3 from Alexander Fomin  ---
This can be reproduced both for i686-*-* and x86_64-*-* hosts.

[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
I will post 2 rtl dumps for ce1 phase produced with -O2 -m32 options on ix86.
You can see that file t21.c.203r.ce1 produced by 20110927 compiler contains
3 possible IF blocks searched.
1 IF blocks converted.
2 true changes made.
but file t21.c.209r.ce1 produced by 20151119 compiler does not
1 possible IF blocks searched.
0 IF blocks converted.
0 true changes made.

[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt

[ienkovich at gcc dot gnu.org]

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

--- Comment #7 from Ilya Enkovich  ---
Looking deeper the difference is caused by different result of
is_nonwrapping_integer_induction called for reduction related phi statement.  

For the first call it is:

i_12 = PHI 

For the second call it is:

i_12 = PHI 

It changed due to generated prologue. It cases is_nonwrapping_integer_induction
to return false due to non-constant base and as a result we compute different
reduction type.

Probably compute reduction type at analysis phase only?

[Bug middle-end/68436] New: [5 Regression] wrong code on x86_64-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 68436
   Summary: [5 Regression] wrong code on x86_64-linux-gnu
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36773&action=edit
preprocessed source

[forwarded from https://bugs.debian.org/800543]

last rechecked with 20151028 from the branch.

On line 15054 of the attached preprocessed output of 'file.c', the
following code:

 x->sm.sm_buffer = 0;
 x->sm.sm_object0 = (unzipped ? make_cons(sSAallow_gzipped_fileA,unzipped) :
sLcharacter);
 x->sm.sm_object1 = fn;
 x->sm.sm_int0 = x->sm.sm_int1 = 0;
 (*vs_top++ = (x));
 setup_stream_buffer(x);


referring to the function setup_stream_buffer on line 14810 in the same file:

void
setup_stream_buffer(object x) {



  if (!(!setvbuf(x->sm.sm_fp,x->sm.sm_buffer=({void * v;bool
w=writable_malloc;writable_malloc=1;v=malloc(
# 314 "file.d" 3 4
 8192
# 314 "file.d"
 );writable_malloc=w;v;}),
# 314 "file.d" 3 4
 0
# 314 "file.d"
 ,
# 314 "file.d" 3 4
 8192
# 314 "file.d"
 )))
assert_error("!setvbuf(x->sm.sm_fp,x->sm.sm_buffer=writable_malloc_wrap(malloc,void
*,BUFSIZ),_IOFBF,BUFSIZ)",314,"file.d",__FUNCTION__);

}


is miscompiled at -O3, with the line

 x->sm.sm_buffer = 0;

omitted and optimized away.  Apparently there is some sort of escape
analysis in which the write to x->sm.sm_buffer in setup_stream_buffer is
detected and determined to be side effect free, maybe because 'malloc'
is assumed to have certain properties.  This is GCL, however, which
supplies its own malloc on top of a native garbage collector, which then
fails when examining 'x' with an uninitialized sm.sm_buffer field.

-O2 works fine.

[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt

[ienkovich at gcc dot gnu.org]

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

--- Comment #6 from Ilya Enkovich  ---
I checked what is happening and seems the reason is in different
STMT_VINFO_VEC_REDUCTION_TYPE (stmt_info) on analysis and transform phases. 
During analysis it is INTEGER_INDUC_COND_REDUCTION, for transformation it is
COND_REDUCTION.

Thus we have different flow for if-statement at tree-vect-loop.c:5653 whose
branches have two major differences.

1. Different types are used to get optab.  For analysis we get
reduc_smax_scal_optab, for transformation we get reduc_umax_scal_optab.

2. Only 'true path' checks old optabs (with no _scal_)

This bug was 'fixed' by r230423 which switched i386 target to new optabs, but
problem still exist.  Currently I see on trunk:

Analysis:
#0  optab_handler (op=reduc_smax_scal_optab, mode=V8SImode) at
gcc/optabs-query.h:31
#1  0x01023d5d in vectorizable_reduction (stmt=0x77f20660, gsi=0x0,
vec_stmt=0x0, slp_node=0x0) at gcc/tree-vect-loop.c:5643

Transformation:
#0  optab_handler (op=reduc_umax_scal_optab, mode=V8SImode) at
gcc/optabs-query.h:31
#1  0x01023fb1 in vectorizable_reduction (stmt=0x77f20660,
gsi=0x7fffb600, vec_stmt=0x7fffb558, slp_node=0x0) at
gcc/tree-vect-loop.c:5691

Note the same statements but different optabs used.

Also we my still have ICE on targets not using new reduction optabs.

[Bug target/68408] broken support for attribute init_priority

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> Eric, thank you very much for the quick fix! 

You're welcome.

> I confirm it is fixed on sparc-elf-g++ (GCC) 5.2.1 20151119.

Thanks, independent verification is always helpful.

[Bug tree-optimization/68431] [6 Regression] Regression in GCC-6.0.0's optimizer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug tree-optimization/68431] [6 Regression] Regression in GCC-6.0.0's optimizer

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Thu Nov 19 15:12:35 2015
New Revision: 230608

URL: https://gcc.gnu.org/viewcvs?rev=230608&root=gcc&view=rev
Log:
PR tree-optimization/68431
* tree-vrp.c (extract_range_from_binary_expr_1): Fix condition.

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

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

[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I'll have a look, thanks.
Is this on x86_64?
Could you please post the if-converted code before that revision?

[Bug target/57845] ICE with -freg-struct-return on SPARC

[sorganov at gmail dot com]

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

--- Comment #16 from Sergey Organov  ---
I confirm it is fixed on sparc-elf-gcc (GCC) 5.2.1 20151119.

Thanks one more time!

[Bug rtl-optimization/68435] New: [6 Regression] Missed if-conversion optimization

[afomin.mailbox at gmail dot com]

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

Bug ID: 68435
   Summary: [6 Regression] Missed if-conversion optimization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: afomin.mailbox at gmail dot com
CC: izamyatin at gmail dot com, kyrylo.tkachov at arm dot com,
ysrumyan at gmail dot com
  Target Milestone: ---
 Build: x86_64-linux-gnu

Created attachment 36772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36772&action=edit
A reproducer

Given the following code compiled with -fif-conversion, we miss if-conversion
opportunity since r228194.

int
foo(char *p1, char *p2, int n)
{
  int s = 0;
  int v;
  int i;

  for (i = 0; i < n; i++) {
v = p1[i] - p2[i];
if (v >= 0)
  s += v;
else
  s -= v;
p1 = p2++;
  }

  return s;
}

[Bug target/68408] broken support for attribute init_priority

[sorganov at gmail dot com]

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

--- Comment #7 from Sergey Organov  ---
Eric, thank you very much for the quick fix! 

I confirm it is fixed on sparc-elf-g++ (GCC) 5.2.1 20151119.

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #8 from Joost VandeVondele  
---
(In reply to Mikael Morin from comment #7)
> (In reply to Joost VandeVondele from comment #6)
> > (In reply to Mikael Morin from comment #5)
> > > (In reply to Joost VandeVondele from comment #4)
> > > > In the original post I suggested that I already looked at the code,
> > > 
> > > What changes did you try?
> > 
> > Baby steps :-) see below. Basically stuck when I realized that somehow the
> > 'tree size' needs to get in.
> > 
> I guess the easiest is to use a variadic call.
> The calls can be updated by incrementing the argument count of
> build_call_expr_loc, and adding the size argument.
> Then you can't use os_error, which is non-variadic.
> You can either use one of the existing (variadic) routines, such as
> runtime_error, or create some os_error_varargs (basically create the
> gfor_fndecl_XXX in trans-decl.c and use it as argument of
> build_call_expr_loc).
> If you create a new declaration, you'll have to write the corresponding code
> in libgfortran.
> 
> Does it sound like it's worth it?

well, at least I have an idea of a way forward.. I did spent a few hours on
this already. I guess it is easier once one knows the code.

I do believe this is useful indeed, within our project we discussed if we could
clean up the error checking of (de)allocates (14000 calls) and we already
removed all checking for all but 400, cleaning away roughly 3 lines of
(useless in my opinion, and with various bugs) code. See for example
https://sourceforge.net/p/cp2k/code/15938/ with many similar commits. The
remaining 400 calls report the size of the failed allocate. To clean those the
consensus was that the compiler should report the size of the failed
allocation.

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

[mikael at gcc dot gnu.org]

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

--- Comment #7 from Mikael Morin  ---
(In reply to Joost VandeVondele from comment #6)
> (In reply to Mikael Morin from comment #5)
> > (In reply to Joost VandeVondele from comment #4)
> > > In the original post I suggested that I already looked at the code,
> > 
> > What changes did you try?
> 
> Baby steps :-) see below. Basically stuck when I realized that somehow the
> 'tree size' needs to get in.
> 
I guess the easiest is to use a variadic call.
The calls can be updated by incrementing the argument count of
build_call_expr_loc, and adding the size argument.
Then you can't use os_error, which is non-variadic.
You can either use one of the existing (variadic) routines, such as
runtime_error, or create some os_error_varargs (basically create the
gfor_fndecl_XXX in trans-decl.c and use it as argument of build_call_expr_loc).
If you create a new declaration, you'll have to write the corresponding code in
libgfortran.

Does it sound like it's worth it?

[Bug middle-end/68393] internal compiler error: in convert_move, at expr.c:286

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
Thanks, Richard!

[Bug c++/68427] GCC (G++) flunks legal ANSI-C code

[wam at hiwaay dot net]

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

--- Comment #3 from wam at hiwaay dot net ---
comment 1: How do I go about doing that (posting preprocessed source file) ?
The tarball I uploaded just has 2 text files showing the output of my effort to
compile the code, & the code in its own tarball.

comment 2: The code was ANSI-C for about 15 years (from ~1995 on), then
converted to C++ by simply renaming it to gauss.cpp & overloading the names of
the various gauss functions. It is otherwise legal ANSI C code. As to the
makefile, I used GCC 4.8.5, pkg-installed, i.e. compiled up by the FreeBSD
folks & retreived by me from their repo. I compiled the GCC5.2.1 up myself,
adding Graphite support (recently accomodated by the GCC maintainer(s)). I did
nothing to the makefile myself. I originally posted this to the
FreeBSD-toolchain list & was advised to repost it here. When you compile it,
are you using FreeBSD 9.3R to do so, or another implementation ?

[Bug c++/68434] New: [concepts] ICE same canonical type node for different types

[ryan.burn at gmail dot com]

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

Bug ID: 68434
   Summary: [concepts] ICE same canonical type node for different
types
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The code below generates this ICE when compiled with 

g++ (GCC) 6.0.0 20151118 (experimental)

 constexpr bool C1() constexpr bool C2() constexpr bool C3()
reduce2.cpp: At global scope:
reduce2.cpp:19:10: internal compiler error: same canonical type node for
different types C2 and C1
 auto f(C3) {
  ^

0x8fb760 comptypes(tree_node*, tree_node*, int)
../../src-orig/gcc/cp/typeck.c:1435
0x9857e8 cp_tree_equal(tree_node*, tree_node*)
../../src-orig/gcc/cp/tree.c:3128
0x9857a1 cp_tree_equal(tree_node*, tree_node*)
../../src-orig/gcc/cp/tree.c:3121
0x9857a1 cp_tree_equal(tree_node*, tree_node*)
../../src-orig/gcc/cp/tree.c:3121
0xa17928 insert
../../src-orig/gcc/cp/logic.cc:131
0xa17c8d left_conjunction
../../src-orig/gcc/cp/logic.cc:237
0xa17e6d decompose_left_term
../../src-orig/gcc/cp/logic.cc:292
0xa17f07 decompose_left_goal
../../src-orig/gcc/cp/logic.cc:315
0xa17f5d decompose_left
../../src-orig/gcc/cp/logic.cc:327
0xa18179 decompose_assumptions(tree_node*)
../../src-orig/gcc/cp/logic.cc:373
0xa12af0 build_constraints(tree_node*, tree_node*)
../../src-orig/gcc/cp/constraint.cc:1035
0x780e0f grokfndecl
../../src-orig/gcc/cp/decl.c:7819
0x78c25d grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../src-orig/gcc/cp/decl.c:11292
0x79f2c9 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../src-orig/gcc/cp/decl.c:14069
0x8bd2c1 cp_parser_function_definition_from_specifiers_and_declarator
../../src-orig/gcc/cp/parser.c:24703
0x8b09bd cp_parser_init_declarator
../../src-orig/gcc/cp/parser.c:17972
0x8a6d64 cp_parser_simple_declaration
../../src-orig/gcc/cp/parser.c:11971
0x8a6b22 cp_parser_block_declaration
../../src-orig/gcc/cp/parser.c:11843
0x8a689c cp_parser_declaration
../../src-orig/gcc/cp/parser.c:11740
0x8a63a7 cp_parser_declaration_seq_opt
../../src-orig/gcc/cp/parser.c:11619
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions

//
template 
concept bool C1() { 
  return true;  
}   

template 
concept bool C2() { 
  return true;  
}   

template
concept bool C3() { 
  return requires(Expr expr) {  
  {expr}->C1;   
  {expr}->C2;   
  };
}   

auto f(C3) {
} 
//

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #6 from Joost VandeVondele  
---
(In reply to Mikael Morin from comment #5)
> (In reply to Joost VandeVondele from comment #4)
> > In the original post I suggested that I already looked at the code,
> 
> What changes did you try?

Baby steps :-) see below. Basically stuck when I realized that somehow the
'tree size' needs to get in.

Index: fortran/trans.c
===
--- fortran/trans.c (revision 227094)
+++ fortran/trans.c (working copy)
@@ -567,6 +567,8 @@ gfc_call_malloc (stmtblock_t * block, tr
   tree tmp, msg, malloc_result, null_result, res, malloc_tree;
   stmtblock_t block2;

+  char* msgstr;
+
   size = gfc_evaluate_now (size, block);

   if (TREE_TYPE (size) != TREE_TYPE (size_type_node))
@@ -593,8 +595,9 @@ gfc_call_malloc (stmtblock_t * block, tr
   null_result = fold_build2_loc (input_location, EQ_EXPR,
 boolean_type_node, res,
 build_int_cst (pvoid_type_node, 0));
+  msgstr = xasprintf("Memory allocation of %ld bytes failed",0L);
   msg = gfc_build_addr_expr (pchar_type_node,
- gfc_build_localized_cstring_const ("Memory allocation failed"));
+ gfc_build_localized_cstring_const (msgstr));
   tmp = fold_build3_loc (input_location, COND_EXPR, void_type_node,
 null_result,
  build_call_expr_loc (input_location,
@@ -641,6 +644,7 @@ gfc_allocate_using_malloc (stmtblock_t *
 {
   tree tmp, error_cond;
   stmtblock_t on_error;
+  char* msgstr;
   tree status_type = status ? TREE_TYPE (status) : NULL_TREE;

   /* Evaluate size only once, and make sure it has the right type.  */
@@ -677,10 +681,12 @@ gfc_allocate_using_malloc (stmtblock_t *
   else
 {
   /* Here, os_error already implies PRED_NORETURN.  */
+  /* TODO figure out how to get 'size' in this string */
+  msgstr=xasprintf("Allocation of %ld bytes would exceed memory
limit",-1L);
   tmp = build_call_expr_loc (input_location, gfor_fndecl_os_error, 1,
-   gfc_build_addr_expr (pchar_type_node,
-gfc_build_localized_cstring_const
-   ("Allocation would exceed memory limit")));
+   gfc_build_addr_expr (pchar_type_node,
gfc_build_cstring_const(msgstr)));
+   /*   gfc_build_localized_cstring_const
+   ("Allocation would exceed memory limit")));
*/
   gfc_add_expr_to_block (&on_error, tmp);
 }

[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou  ---
Fixed everywhere.

[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 19 13:32:54 2015
New Revision: 230605

URL: https://gcc.gnu.org/viewcvs?rev=230605&root=gcc&view=rev
Log:
PR lto/61313
* configure.ac (PLUGIN_LD_SUFFIX): Do not touch the value specified
by the user.
* configure: Regenerate.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/configure
branches/gcc-4_9-branch/gcc/configure.ac

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #5 from Mikael Morin  ---
(In reply to Joost VandeVondele from comment #4)
> In the original post I suggested that I already looked at the code,

What changes did you try?

[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 19 13:32:10 2015
New Revision: 230604

URL: https://gcc.gnu.org/viewcvs?rev=230604&root=gcc&view=rev
Log:
PR lto/61313
* configure.ac (PLUGIN_LD_SUFFIX): Do not touch the value specified
by the user.
* configure: Regenerate.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/configure
branches/gcc-5-branch/gcc/configure.ac

[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 19 13:31:33 2015
New Revision: 230603

URL: https://gcc.gnu.org/viewcvs?rev=230603&root=gcc&view=rev
Log:
PR lto/61313
* configure.ac (PLUGIN_LD_SUFFIX): Do not touch the value specified
by the user.
* configure: Regenerate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac