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

[bacon at cs dot nyu.edu]

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

Bug ID: 68589
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bacon at cs dot nyu.edu
  Target Milestone: ---

Created attachment 36859
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36859=edit
Preprocessor output

Here is the command line and output:

$ gcc -v -save-temps -std=gnu99 -DHAVE_CONFIG_H -I.
-I../../../../../setl-2.3.5/src/run/gmp-setl/mpn -I.. -D__GMP_WITHIN_GMP
-I../../../../../setl-2.3.5/src/run/gmp-setl
-I../../../../../setl-2.3.5/src/run/gmp-setl/..
-I../../../../../setl-2.3.5/src/run/gmp-setl/../.. -I../.. -I../../..
-DOPERATION_mp_bases -g -O2 -Wall -Wextra -Wcast-qual -Wc++-compat
-Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wmissing-format-attribute -Wmissing-noreturn -c
../../../../../setl-2.3.5/src/run/gmp-setl/mpn/mp_bases.c -o mp_bases.o
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.x86_64/src/gcc-4.9.3/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.x86_64/src/gcc-4.9.3
--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 4.9.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu99' '-D' 'HAVE_CONFIG_H' '-I'
'.' '-I' '../../../../../setl-2.3.5/src/run/gmp-setl/mpn' '-I' '..' '-D'
'__GMP_WITHIN_GMP' '-I' '../../../../../setl-2.3.5/src/run/gmp-setl' '-I'
'../../../../../setl-2.3.5/src/run/gmp-setl/..' '-I'
'../../../../../setl-2.3.5/src/run/gmp-setl/../..' '-I' '../..' '-I' '../../..'
'-D' 'OPERATION_mp_bases' '-g' '-O2' '-Wall' '-Wextra' '-Wcast-qual'
'-Wc++-compat' '-Wpointer-arith' '-Wbad-function-cast' '-Wcast-align'
'-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes'
'-Wmissing-declarations' '-Wsuggest-attribute=format'
'-Wsuggest-attribute=noreturn' '-c' '-o' 'mp_bases.o' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/cc1.exe -E -quiet -v -I . -I
../../../../../setl-2.3.5/src/run/gmp-setl/mpn -I .. -I
../../../../../setl-2.3.5/src/run/gmp-setl -I
../../../../../setl-2.3.5/src/run/gmp-setl/.. -I
../../../../../setl-2.3.5/src/run/gmp-setl/../.. -I ../.. -I ../../.. -Dunix
-idirafter
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/../../../../lib/../include/w32api
-idirafter
/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api
-D HAVE_CONFIG_H -D __GMP_WITHIN_GMP -D OPERATION_mp_bases
../../../../../setl-2.3.5/src/run/gmp-setl/mpn/mp_bases.c -mtune=generic
-march=x86-64 -std=gnu99 -Wall -Wextra -Wcast-qual -Wc++-compat -Wpointer-arith
-Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -Wsuggest-attribute=format
-Wsuggest-attribute=noreturn -g -fworking-directory -O2 -fpch-preprocess -o
mp_bases.i
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/../../../../x86_64-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../../../../setl-2.3.5/src/run/gmp-setl/mpn
 ..
 ../../../../../setl-2.3.5/src/run/gmp-setl
 ../../../../../setl-2.3.5/src/run/gmp-setl/..
 ../../../../../setl-2.3.5/src/run/gmp-setl/../..
 ../..
 ../../..
 /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/include
 /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/include-fixed
 /usr/include
 /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/../../../../lib/../include/w32api
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu99' '-D' 'HAVE_CONFIG_H' '-I'
'.' '-I' '../../../../../setl-2.3.5/src/run/gmp-setl/mpn' '-I' '..' '-D'
'__GMP_WITHIN_GMP' '-I' '../../../../../setl-2.3.5/src/run/gmp-setl' '-I'

[Bug tree-optimization/68501] [6 Regression] sqrt builtin is not used anymore

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 36858
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36858=edit
gcc6-pr68501.patch

Untested fix.  The problem is that the vector SQRT is now an internal call, and
in that case targetm.builtin_reciprocal is not called at all.

[Bug rtl-optimization/68349] [6 regression] ice in decompose_normal_address with -O2 at rtlanal.c:6086

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Seems this is LRA on
(insn 84 145 162 3 (set (reg:SI 183 [180])
(plus:SI (plus:SI (subreg:SI (plus:DI (reg/f:DI 20 frame)
(const_int 16 [0x10])) 0)
(subreg:SI (reg:DI 168) 0))
(const_int 303 [0x12f]))) 212 {*leasi}
 (expr_list:REG_DEAD (reg:DI 20 frame)
(expr_list:REG_DEAD (reg:DI 168)
(nil
where supposedly the lea is not used for address computation, but just as a
fancy arithmetics computation.

[Bug rtl-optimization/68536] LRA ICEs with new arm pattern

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
The problem of the segmentation fault is in base == NULL in lra_emit_add but
the real root of the problem is in processing insn operators for subreg
reloading.

I'll have a patch today and commit it in trunk if everything is ok.

[Bug c++/68586] [6 Regression] Enum template parameter wrongly rejected

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
Looks like a regression compared to gcc 5.2.0 to me.

[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 #7 from Jonathan Wakely  ---
OK, the problem is a bug in your code, not GCC.

Your StdIO.h file has this header guard:

#ifndef _STDIO_H_
#define _STDIO_H_

That clashes with the name of the header guard in /usr/include/stdio.h so the
contents of your StdIO.h are ignored if  has already been included

You should not be using a name like _STDIO_H_ in your code, all names starting
with _[A-Z_] are reserved for the implementation, for any purpose. Defining a
macro with that name results in undefined behaviour, meaning your code is not
valid ANSI C and is not valid ISO C++.

So you need to fix your header.

[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 #8 from Jonathan Wakely  ---
Similarly, _STD_C_H_ is not a valid header guard in StdC.h, and _ASSERT0_H_ is
not valid in Assert.h, and _GAUSS_H_ is not valid in gauss.h

Same goes for 

#  define __ASSERT_FUNCTION ((__const char *) 0)


I don't know what the point of this is:

#ifdef  __linux__   // Linux :-) 
#include 
#elif defined   __FreeBSD__ // FreeBSD & SGI :-) 
#include  // typedef uint :-) 
#endif

But the  header is deprecated and you should include 

The code has a number of problems, but GCC is not the cause.

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

[dje at gcc dot gnu.org]

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

--- Comment #5 from David Edelsohn  ---
One needs to upgrade to ISL 0.14 or 0.15.

The earlier inclusion ordering of ISL header files in graphite source files
were wrong and did not follow GCC requirements.  It worked on Mint and OpenSUSE
because GCC header file requirements were violated.

[Bug ada/68564] Ada fails to bootstrap on sparc64-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|ada fails to bootstrap on   |Ada fails to bootstrap on
   |sparc64-linux-gnu   |sparc64-linux-gnu

--- Comment #3 from Eric Botcazou  ---
The patch is OK for mainline and 5 branch, thanks.

[Bug rtl-optimization/68536] LRA ICEs with new arm pattern

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Nov 27 18:26:12 2015
New Revision: 231021

URL: https://gcc.gnu.org/viewcvs?rev=231021=gcc=rev
Log:
2015-11-27  Vladimir Makarov  

PR rtl-optimization/68536
* lra.c (lra_emit_add): Add code for null base.
* lra-constraints.c (curr_insn_transform): Skip operators for
subreg reloads.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/lra.c

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||spop at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
See also
.
 Unfortunately, one has to revert a number of patches before being able to
revert r230759.

[Bug tree-optimization/68552] [5/6 Regression]: ICE in in expand_expr_real_2 with -O2 -ftree-vectorize

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Created attachment 36847 [details]
> > gcc6-pr68552.patch
> 
> I have started a bootstrap + regtest with the above patch on alpha-linux-gnu
> native, please expect results in ~10 hours.

The regression test didn't yet finish, but all regressed test were OK with the
patched compiler.

[Bug tree-optimization/68552] [5/6 Regression]: ICE in in expand_expr_real_2 with -O2 -ftree-vectorize

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 27 19:42:47 2015
New Revision: 231024

URL: https://gcc.gnu.org/viewcvs?rev=231024=gcc=rev
Log:
PR tree-optimization/68552
* optabs.c (expand_vec_perm_1): Move vec_shr handling from here...
(expand_vec_perm): ... here.  Do it regardless of vec_perm_const_optab
or whether v0 == v1.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/optabs.c

[Bug c++/61039] Using a constexpr's address as a template variable produces an unnecessary warning

[Torsten at Robitzki dot de]

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

Torsten Robitzki  changed:

   What|Removed |Added

 CC||Torsten at Robitzki dot de

--- Comment #1 from Torsten Robitzki  ---
I see the same issue already with 4.8.4.

[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0

[mrs at gcc dot gnu.org]

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

--- Comment #34 from mrs at gcc dot gnu.org  ---
So, for bugs that aren't fixed, sometimes we work around them.  We can use this
bug to track things like the vendor bug status (fixed or not), and potential
workarounds.  Plus, we can list this bug in the documentation for _why_ the
compiler doesn't work.

[Bug bootstrap/68361] [6 regression] Bootstrap failure with --enable-checking=release

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So fixed?

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[burnus at gcc dot gnu.org]

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

--- Comment #13 from Tobias Burnus  ---
(In reply to rsand...@gcc.gnu.org from comment #10)
> Series finally posted here:
>   https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03020.html

Part 05's gcc/genattrtab.c changes do not apply. (All other parts and the
chunks for other files in Part 05 do with some line-offset fuzzy.)

That's a bit surprising as git lists r229184 of 2015-10-22 as latest change for
that file while the patch set was posted on 2015-11-25. - Six of the
gcc/genattrtab.c chunks do not apply and none of them looks trivial.


For instance, the patch changes:
@@ -4770,6 +4804,7 @@ gen_insn_reserv (md_rtx_info *info)
   memset (, 0, sizeof (attr));
   attr.name = DEF_ATTR_STRING (XSTR (def, 0));
   attr.loc = info->loc;
+  attr.type = AT_INSN;

   decl->name= DEF_ATTR_STRING (XSTR (def, 0));
   decl->default_latency = XINT (def, 1);


But in the trunk, I only see:
  4753  gen_insn_reserv (md_rtx_info *info)
  4754  {
  4755struct insn_reserv *decl = oballoc (struct insn_reserv);
  4756rtx def = info->def;
  4757
  4758decl->name= DEF_ATTR_STRING (XSTR (def, 0));
  4759decl->default_latency = XINT (def, 1);

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #6 from Joost VandeVondele  
---
graphite without recent ISL is not a good idea, graphite before 0.15 (certainly
not 0.12) could lead to exponential memory and cpu time requirements, see

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852#c19

[Bug fortran/68218] ALLOCATE with size given by a module function

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.4

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on trunk, 5-branch, and 4-branch.  Thanks for patch.  Closing PR.

[Bug c++/68383] Demangler stack overflow

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
markus@x4 libiberty % ./a.out
_ZSt7forwardIRKZN5Write14DataMapGrammarISt20back_insert_iteratorISsEEC4EvEUlRT_E_EOS5_RNSt16remove_referenceIS5_E4typeE
typed name
  template
qualified name
  name 'std'
  name 'forward'
template argument list
  reference
const
  local name
typed name
  qualified name
template
  qualified name
name 'Write'
name 'DataMapGrammar'
  template argument list
template
  qualified name
name 'std'
name 'back_insert_iterator'
  template argument list
standard substitution std::string
constructor 4
  name 'DataMapGrammar'
  function type
argument list
lambda 0
  argument list
reference
  template parameter 0
  function type
rvalue reference
  template parameter 0
argument list
  reference
qualified name
  template
qualified name
  standard substitution std
  name 'remove_reference'
template argument list
  template parameter 0
  name 'type'
ASAN:SIGSEGV
=
==12223==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe4e88 (pc
0x004046fd bp 0x0fffca20 sp 0x7ffe4e80 T0)

[Bug libgomp/68579] FAIL: libgomp.c/target-32.c execution test

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 27 19:33:33 2015
New Revision: 231023

URL: https://gcc.gnu.org/viewcvs?rev=231023=gcc=rev
Log:
PR libgomp/68579
* task.c (gomp_task_run_post_handle_depend_hash): New forward decl.
(gomp_create_target_task): Call it before freeing
GOMP_TARGET_TASK_DATA tasks.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/task.c

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[dvyukov at google dot com]

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

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #2 from Dmitry Vyukov  ---
If you change types of:

int v;
int q;
int o;

to 'long long', does it fix the failure?

[Bug rtl-optimization/68250] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 27 12:12:35 2015
New Revision: 231009

URL: https://gcc.gnu.org/viewcvs?rev=231009=gcc=rev
Log:
PR rtl-optimization/68250
* gcc.c-torture/execute/pr68250.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr68250.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/68583] [5/6 Regression] Missed if-conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 CC||venkataramanan.kumar at amd 
dot co
   ||m
  Known to work||4.9.3, 5.1.0
   Target Milestone|--- |5.3
 Ever confirmed|0   |1
  Known to fail||5.2.0, 6.0

[Bug rtl-optimization/68536] LRA ICEs with new arm pattern

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Hmm, I can definitely still reproduce based on today's trunk.
I'm using an arm-none-eabi compiler configured with
 --without-isl --with-float=hard --with-cpu=cortex-a15 --with-fpu=neon-vfpv4
--with-float=hard --enable-checking=yes

[Bug c/68582] New: -Wunused-function doesn't warn about unused static __attribute__((noreturn)) functions

[palves at redhat dot com]

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

Bug ID: 68582
   Summary: -Wunused-function doesn't warn about unused static
__attribute__((noreturn)) functions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palves at redhat dot com
  Target Milestone: ---

With:

 $ gcc6 -v:
 ...
 GNU C11 (GCC) version 6.0.0 20151117 (experimental) (x86_64-pc-linux-gnu)
 ...

This warns, as expected:

 $ cat not-used.c 
 void abort(void);
 static void foo (void) { abort (); }
 int main () {return 0;}
 $ gcc6 not-used.c -o not-used -Wunused-function 
 not-used.c:2:13: warning: ‘foo’ defined but not used [-Wunused-function]
  static void foo (void) { abort (); }
  ^~~

Adding __attribute__((noreturn)) to foo silences the warning:

 $ cat not-used.c 
 void abort(void);
 static __attribute__((noreturn)) void foo (void) { abort (); }
 int main () {return 0;}
 $ gcc6 not-used.c -o not-used -Wunused-function 
 $

Couldn't find this documented in the manual.

[Bug c++/68578] [5 Regression] ICE on invalid template declaration and instantiation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Seems this has regressed with r226657, but couldn't reproduce it after the
corresponding trunk commit on the trunk.

[Bug rtl-optimization/68250] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 27 12:13:48 2015
New Revision: 231010

URL: https://gcc.gnu.org/viewcvs?rev=231010=gcc=rev
Log:
PR rtl-optimization/68250
* gcc.c-torture/execute/pr68250.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr68250.c
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/68583] New: [5/6 Regression] Missed if-conversion

[rguenth at gcc dot gnu.org]

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

Bug ID: 68583
   Summary: [5/6 Regression] Missed if-conversion
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We don't if-convert

void foo (long *a)
{
  int i;
  for (i = 0; i < 100; i+=2)
{
  if (a[i] == 0)
{
  a[i+1] = 2;
  a[i] = 3;
}
  else
{
  a[i+1] = 3;
  a[i] = 4;
}
}
}

even though both a[i] and a[i+1] are written to unconditionally.  We only
keep a base_master to see if sth is writable but if we'd have separate
read-unconditionally and write-unconditionally flags from the master_dr
we could handle the above just fine.  That would require the master_dr
entry to be associated with two different predicates, one for
reads and writes (for read-or-written-unconditionally) and one for writes
only (for written-unconditionally).

PR56624 suggests this missed if-conversion is a regression which it is
as GCC 4.9 and GCC 5.1.0 happily if-convert it.

[Bug c/68582] -Wunused-function doesn't warn about unused static __attribute__((noreturn)) functions

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Probably because noreturn uses the volatile bit, TREE_THIS_VOLATILE:

  /* Warn about static fns or vars defined but not used.  */
  if (((warn_unused_function && TREE_CODE (decl) == FUNCTION_DECL)
   || (((warn_unused_variable && ! TREE_READONLY (decl))
|| (warn_unused_const_variable && TREE_READONLY (decl)))
   && TREE_CODE (decl) == VAR_DECL))
  && ! DECL_IN_SYSTEM_HEADER (decl)
...
  /* A volatile variable might be used in some non-obvious way.  */
  && ! TREE_THIS_VOLATILE (decl)

this flag check should be gated on VAR_DECLs.

[Bug bootstrap/64320] Missing config.h during findcomp.cc compilation

[gk at torproject dot org]

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

Georg Koppen  changed:

   What|Removed |Added

 CC||gk at torproject dot org

--- Comment #3 from Georg Koppen  ---
(In reply to Andreas Schwab from comment #2)
> Please try this patch:

This solves the issue for me.

[Bug target/68577] [6 Regression] ICE: in expand_direct_optab_fn, at internal-fn.c:2171

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Bet this started with r230475 or so.
The problem is that these builtins are in scalar form always returning int, but
take some argument of wider bitsize.
The vectorizer thinks the target can handle narrowing conversion builtin, and
thus emits:
  vect_l.17_53 = [vec_unpack_lo_expr] vect_vec_iv_.15_49;
  vect_l.17_54 = [vec_unpack_hi_expr] vect_vec_iv_.15_49;
  vect__7.18_55 = POPCOUNT (vect_l.17_53, vect_l.17_54);
where vec_l.17 has V2DImode, and vect__7.18 has V4SImode.
But at least the power8 popcountv2di2 pattern takes a single V2DImode argument
(rather than 2 V2DImode arguments) and returns a V2DImode result, while the
caller expects one that takes two V2DImode arguments and produces 4 results in
V4SImode vector for that.

So, first of all, what do we expect from the backends, shall they implement
these popcount2 expanders for vector modes as returning the result in the
same mode as the single argument (then the vectorizer needs to be told about
that and needs to do the narrowing manually, do e.g. in the above case do
POPCOUNT on each V2DImode argument separately, then combine the two V2DImode
results as for long -> int vectorized conversion.  Or they need to do something
different, but then the question is if it should be called popcountv2di2 if it
actually takes 2 arguments rather than 1, etc.

[Bug c/68582] -Wunused-function doesn't warn about unused static __attribute__((noreturn)) functions

[palves at redhat dot com]

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

--- Comment #1 from Pedro Alves  ---
Same thing with gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) [Fedora 20].

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Dmitry Vyukov from comment #2)
> If you change types of:
> 
> int v;
> int q;
> int o;
> 
> to 'long long', does it fix the failure?

As long as I don't have a reliable way to reproduce the failure, I can't answer
that question.

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

[mar...@mpa-garching.mpg.de]

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

--- Comment #1 from Martin Reinecke  ---
I should probably add that building the trunk was possible without any problems
on Linux Mint until about two weeks ago. Unfortunately I do not know yet how to
isolate the problematic commit ... will look into "git bisect" and post updates
if I have more information.

[Bug rtl-optimization/68536] LRA ICEs with new arm pattern

[yroux at gcc dot gnu.org]

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

--- Comment #6 from Yvan Roux  ---
(In reply to ktkachov from comment #5)
> Hmm, I can definitely still reproduce based on today's trunk.
> I'm using an arm-none-eabi compiler configured with
>  --without-isl --with-float=hard --with-cpu=cortex-a15 --with-fpu=neon-vfpv4
> --with-float=hard --enable-checking=yes

Ok, mine is on yesterday's trunk and arm-linux-gnueabihf, but I'll retry from
scratch.

[Bug tree-optimization/68343] FAIL: gcc.dg/graphite/fuse-{1,2}.c scan-tree-dumps

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed|2015-11-13 00:00:00 |2015-11-27
 CC||ktkachov at gcc dot gnu.org

--- Comment #7 from ktkachov at gcc dot gnu.org ---
I'm also seeing these fails on arm with ISL version 0.14

[Bug rtl-optimization/67477] [6 Regression] ICE in cselib_record_set, at cselib.c:2388

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-27
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
Cannot reproduce on trunk any more.

Not sure where it got fixed though.

[Bug c/68582] -Wunused-function doesn't warn about unused static __attribute__((noreturn)) functions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 Ever confirmed|0   |1

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

[Bug bootstrap/68563] LTO bootstrap fails on aarch64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
LTO bootstrap on aarch64-linux with --disable-werror passes.

[Bug target/68214] gcc.dg/cwsc1.c fails on arm-none-eabi

[ktkachov at gcc dot gnu.org]

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

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 ---
How was the compiler configured?
The testcases passes for me with a recent trunk.
Compiling it with a arm-none-eabi compiler with -march=armv4t -mthumb
-mfloat-abi=softfp (for example) gives:
main:
push{r4, lr}
sub sp, sp, #8
mov r3, sp
addsr4, r3, #7
ldr r3, .L5
ldr r3, [r3]
mov ip, r4
bl  .L7
cmp r0, r4
bne .L4
movsr0, #0
add sp, sp, #8
@ sp needed
pop {r4}
pop {r1}
bx  r1
.L4:
bl  abort
.L6:
.align  2
.L5:
.word   .LANCHOR0
.size   main, .-main
.global ptr
.data
.align  2
.set.LANCHOR0,. + 0
.type   ptr, %object
.size   ptr, 4
ptr:
.word   foo
.ident  "GCC: (unknown) 6.0.0 20151127 (experimental)"
.text
.code 16
.align  1
.L7:
bx  r3

[Bug c++/68584] nested generic lambda with trailing return type cases compiler crash

[Gaetano.Checinski at gmail dot com]

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

--- Comment #1 from Gaetano.Checinski at gmail dot com  ---
clang compiles this examples

[Bug c++/68585] New: [5/6 Regression] c++14 code accepted by 4.9 not accepted by 5 and 6

[doko at gcc dot gnu.org]

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

Bug ID: 68585
   Summary: [5/6 Regression] c++14 code accepted by 4.9 not
accepted by 5 and 6
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

is this code which shouldn't be accepted by 4.9?

$ cat tst.cc
#include 
#include 

struct Pos
{
  unsigned l,c,a;

  //fix g++
// constexpr Pos(unsigned l, unsigned c, unsigned a)
// : l(l), c(c), a(a)
// {}
};

template
constexpr std::array make_grid_position(std::integer_sequence)
{
  return std::array{Pos{Ints / 9, Ints % 9, (Ints / 9) / 3 * 3 +
(Ints % 9) / 3}...};
}

constexpr std::array make_grid_positions()
{
  return make_grid_position(std::make_index_sequence<9*9>{});
}

template
void generate_sudoku(T)
{
  constexpr std::array positions = make_grid_positions(); // fail
}

int main()
{
  constexpr std::array positions = make_grid_positions(); // ok
  generate_sudoku(1);
}

$ g++ -std=gnu++14 tst.cc 
tst.cc: In instantiation of 'void generate_sudoku(T) [with T = int]':
tst.cc:34:20:   required from here
tst.cc:28:66: error: 'std::array{std::__array_traits::_Type{Pos{0u, 0u, 0u}, Pos{0u, 1u, 0u}, Pos{0u, 2u, 0u}, Pos{0u, 3u,
1u}, Pos{0u, 4u, 1u}, Pos{0u, 5u, 1u}, Pos{0u, 6u, 2u}, Pos{0u, 7u, 2u},
Pos{0u, 8u, 2u}, Pos{1u, 0u, 0u}, Pos{1u, 1u, 0u}, Pos{1u, 2u, 0u}, Pos{1u, 3u,
1u}, Pos{1u, 4u, 1u}, Pos{1u, 5u, 1u}, Pos{1u, 6u, 2u}, Pos{1u, 7u, 2u},
Pos{1u, 8u, 2u}, Pos{2u, 0u, 0u}, Pos{2u, 1u, 0u}, Pos{2u, 2u, 0u}, Pos{2u, 3u,
1u}, Pos{2u, 4u, 1u}, Pos{2u, 5u, 1u}, Pos{2u, 6u, 2u}, Pos{2u, 7u, 2u},
Pos{2u, 8u, 2u}, Pos{3u, 0u, 3u}, Pos{3u, 1u, 3u}, Pos{3u, 2u, 3u}, Pos{3u, 3u,
4u}, Pos{3u, 4u, 4u}, Pos{3u, 5u, 4u}, Pos{3u, 6u, 5u}, Pos{3u, 7u, 5u},
Pos{3u, 8u, 5u}, Pos{4u, 0u, 3u}, Pos{4u, 1u, 3u}, Pos{4u, 2u, 3u}, Pos{4u, 3u,
4u}, Pos{4u, 4u, 4u}, Pos{4u, 5u, 4u}, Pos{4u, 6u, 5u}, Pos{4u, 7u, 5u},
Pos{4u, 8u, 5u}, Pos{5u, 0u, 3u}, Pos{5u, 1u, 3u}, Pos{5u, 2u, 3u}, Pos{5u, 3u,
4u}, Pos{5u, 4u, 4u}, Pos{5u, 5u, 4u}, Pos{5u, 6u, 5u}, Pos{5u, 7u, 5u},
Pos{5u, 8u, 5u}, Pos{6u, 0u, 6u}, Pos{6u, 1u, 6u}, Pos{6u, 2u, 6u}, Pos{6u, 3u,
7u}, Pos{6u, 4u, 7u}, Pos{6u, 5u, 7u}, Pos{6u, 6u, 8u}, Pos{6u, 7u, 8u},
Pos{6u, 8u, 8u}, Pos{7u, 0u, 6u}, Pos{7u, 1u, 6u}, Pos{7u, 2u, 6u}, Pos{7u, 3u,
7u}, Pos{7u, 4u, 7u}, Pos{7u, 5u, 7u}, Pos{7u, 6u, 8u}, Pos{7u, 7u, 8u},
Pos{7u, 8u, 8u}, Pos{8u, 0u, 6u}, Pos{8u, 1u, 6u}, Pos{8u, 2u, 6u}, Pos{8u, 3u,
7u}, Pos{8u, 4u, 7u}, Pos{8u, 5u, 7u}, Pos{8u, 6u, 8u}, Pos{8u, 7u, 8u},
Pos{8u, 8u, 8u}}}' is not a constant expression
   constexpr std::array positions = make_grid_positions(); // fail
  ^

[Bug fortran/68218] ALLOCATE with size given by a module function

[vehre at gcc dot gnu.org]

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

--- Comment #6 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Fri Nov 27 14:35:46 2015
New Revision: 231017

URL: https://gcc.gnu.org/viewcvs?rev=231017=gcc=rev
Log:
gcc/fortran/ChangeLog:

2015-11-27  Andre Vehreschild  

PR fortran/68218
* trans-array.c (gfc_array_init_size): Add gfc_evaluate_now() when
array spec in allocate is a function call.

gcc/testsuite/ChangeLog:

2015-11-27  Andre Vehreschild  

PR fortran/68218
* gfortran.dg/allocate_with_arrayspec_1.f90: New test.



Added:
   
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/allocate_with_arrayspec_1.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/trans-array.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/68570] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So, we have:
basic block 13, loop depth 1
 pred:   11
_24 = (int) m_23(D);
i_lsm.22_91 = _24;
i_lsm.23_92 = 1;
_43 = _24 <= 0;
_45 = (int) _43;
 succ:   14

basic block 14, loop depth 1
 pred:   19
 13
# prephitmp_42 = PHI 
# i_lsm.22_58 = PHI 
# i_lsm.23_60 = PHI 
if (prephitmp_42 != 0)
  goto ;
else
  goto ;
 succ:   20
 15

and #line 2164 "../../gcc/match.pd is applied, we get:
# prephitmp_42 = PHI 
# i_lsm.22_58 = PHI 
# i_lsm.23_60 = PHI 
if (_24 != 0)
  goto ;
else
  goto ;
 succ:   20
 15

which is wrong IL, as _24 is is used in a bb not dominated by its definition.
Perhaps it is optimized this way because match.pd sees that bb19 is unreachable
or something similar, lots of the conditions are folded into 1 != 0 or 0 != 0.

[Bug other/61233] Demangler crash (GDB PR 16957)

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Author: trippels
Date: Fri Nov 27 14:48:21 2015
New Revision: 231020

URL: https://gcc.gnu.org/viewcvs?rev=231020=gcc=rev
Log:
PR other/61321 - demangler crash on casts in template parameters

The fix for bug 59195:

 [C++ demangler handles conversion operator incorrectly]
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195

unfortunately makes the demangler crash due to infinite recursion, in
case of casts in template parameters.

For example, with:

 template struct A {};
 template  void function_temp(A) {}
 template void function_temp(A);

The 'function_temp' instantiation above mangles to:

  _Z13function_tempIiEv1AIXszcvT_Li999EEE

The demangler parses this as:

typed name
  template
name 'function_temp'
template argument list
  builtin type int
  function type
builtin type void
argument list
  template  (*)
name 'A'
template argument list
  unary operator
operator sizeof
unary operator
  cast
template parameter 0(**)
  literal
builtin type int
name '999'

And after the fix for 59195, due to:

 static void
 d_print_cast (struct d_print_info *dpi, int options,
   const struct demangle_component *dc)
 {
 ...
   /* For a cast operator, we need the template parameters from
  the enclosing template in scope for processing the type.  */
   if (dpi->current_template != NULL)
 {
   dpt.next = dpi->templates;
   dpi->templates = 
   dpt.template_decl = dpi->current_template;
 }

when printing the template argument list of A (what should be ""), the template parameter 0 (that is, "T_", the '**' above) now
refers to the first parameter of the the template argument list of the
'A' template (the '*' above), exactly what we were already trying to
print.  This leads to infinite recursion, and stack exaustion.  The
template parameter 0 should actually refer to the first parameter of
the 'function_temp' template.

Where it reads "for the cast operator" in the comment in d_print_cast
(above), it's really talking about a conversion operator, like:

  struct A { template  explicit operator U(); };

We don't want to inject the template parameters from the enclosing
template in scope when processing a cast _expression_, only when
handling a conversion operator.

The problem is that DEMANGLE_COMPONENT_CAST is currently ambiguous,
and means _both_ 'conversion operator' and 'cast expression'.

Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
which does what DEMANGLE_COMPONENT_CAST does today, and making
DEMANGLE_COMPONENT_CAST just simply print its component subtree.

I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
d_print_comp_inner still do:

 @@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int
options,
d_print_comp (dpi, options, dc->u.s_extended_operator.name);
return;

 case DEMANGLE_COMPONENT_CAST:
   d_append_string (dpi, "operator ");
 - d_print_cast (dpi, options, dc);
 + d_print_conversion (dpi, options, dc);
   return;

leaving the unary cast case below calling d_print_cast, but seems to
me that spliting the component types makes it easier to reason about
the code.

g++'s testsuite actually generates three symbols that crash the
demangler in the same way.  I've added those as tests in the demangler
testsuite as well.

And then this fixes PR other/61233 too, which happens to be a
demangler crash originally reported to GDB, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16957

Bootstrapped and regtested on x86_64 Fedora 20.

Also ran this through GDB's testsuite.  GDB will require a small
update to use DEMANGLE_COMPONENT_CONVERSION in one place it's using
DEMANGLE_COMPONENT_CAST in its sources.

libiberty/
2015-11-27  Pedro Alves  

PR other/61321
PR other/61233
* demangle.h (enum demangle_component_type)
: New value.
* cp-demangle.c (d_demangle_callback, d_make_comp): Handle
DEMANGLE_COMPONENT_CONVERSION.
(is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
instead of DEMANGLE_COMPONENT_CAST.
(d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
component if handling a conversion.
(d_count_templates_scopes, d_print_comp_inner): Handle
DEMANGLE_COMPONENT_CONVERSION.
(d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
of DEMANGLE_COMPONENT_CAST.
(d_print_cast): Rename as ...
(d_print_conversion): ... this.  Adjust comments.
(d_print_cast): Rewrite - simply print the left subcomponent.
* cp-demint.c (cplus_demangle_fill_component): Handle
DEMANGLE_COMPONENT_CONVERSION.

* testsuite/demangle-expected: Add tests.

[Bug other/59195] C++ demangler handles conversion operator incorrectly

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
Author: trippels
Date: Fri Nov 27 14:48:21 2015
New Revision: 231020

URL: https://gcc.gnu.org/viewcvs?rev=231020=gcc=rev
Log:
PR other/61321 - demangler crash on casts in template parameters

The fix for bug 59195:

 [C++ demangler handles conversion operator incorrectly]
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195

unfortunately makes the demangler crash due to infinite recursion, in
case of casts in template parameters.

For example, with:

 template struct A {};
 template  void function_temp(A) {}
 template void function_temp(A);

The 'function_temp' instantiation above mangles to:

  _Z13function_tempIiEv1AIXszcvT_Li999EEE

The demangler parses this as:

typed name
  template
name 'function_temp'
template argument list
  builtin type int
  function type
builtin type void
argument list
  template  (*)
name 'A'
template argument list
  unary operator
operator sizeof
unary operator
  cast
template parameter 0(**)
  literal
builtin type int
name '999'

And after the fix for 59195, due to:

 static void
 d_print_cast (struct d_print_info *dpi, int options,
   const struct demangle_component *dc)
 {
 ...
   /* For a cast operator, we need the template parameters from
  the enclosing template in scope for processing the type.  */
   if (dpi->current_template != NULL)
 {
   dpt.next = dpi->templates;
   dpi->templates = 
   dpt.template_decl = dpi->current_template;
 }

when printing the template argument list of A (what should be ""), the template parameter 0 (that is, "T_", the '**' above) now
refers to the first parameter of the the template argument list of the
'A' template (the '*' above), exactly what we were already trying to
print.  This leads to infinite recursion, and stack exaustion.  The
template parameter 0 should actually refer to the first parameter of
the 'function_temp' template.

Where it reads "for the cast operator" in the comment in d_print_cast
(above), it's really talking about a conversion operator, like:

  struct A { template  explicit operator U(); };

We don't want to inject the template parameters from the enclosing
template in scope when processing a cast _expression_, only when
handling a conversion operator.

The problem is that DEMANGLE_COMPONENT_CAST is currently ambiguous,
and means _both_ 'conversion operator' and 'cast expression'.

Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
which does what DEMANGLE_COMPONENT_CAST does today, and making
DEMANGLE_COMPONENT_CAST just simply print its component subtree.

I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
d_print_comp_inner still do:

 @@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int
options,
d_print_comp (dpi, options, dc->u.s_extended_operator.name);
return;

 case DEMANGLE_COMPONENT_CAST:
   d_append_string (dpi, "operator ");
 - d_print_cast (dpi, options, dc);
 + d_print_conversion (dpi, options, dc);
   return;

leaving the unary cast case below calling d_print_cast, but seems to
me that spliting the component types makes it easier to reason about
the code.

g++'s testsuite actually generates three symbols that crash the
demangler in the same way.  I've added those as tests in the demangler
testsuite as well.

And then this fixes PR other/61233 too, which happens to be a
demangler crash originally reported to GDB, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16957

Bootstrapped and regtested on x86_64 Fedora 20.

Also ran this through GDB's testsuite.  GDB will require a small
update to use DEMANGLE_COMPONENT_CONVERSION in one place it's using
DEMANGLE_COMPONENT_CAST in its sources.

libiberty/
2015-11-27  Pedro Alves  

PR other/61321
PR other/61233
* demangle.h (enum demangle_component_type)
: New value.
* cp-demangle.c (d_demangle_callback, d_make_comp): Handle
DEMANGLE_COMPONENT_CONVERSION.
(is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
instead of DEMANGLE_COMPONENT_CAST.
(d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
component if handling a conversion.
(d_count_templates_scopes, d_print_comp_inner): Handle
DEMANGLE_COMPONENT_CONVERSION.
(d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
of DEMANGLE_COMPONENT_CAST.
(d_print_cast): Rename as ...
(d_print_conversion): ... this.  Adjust comments.
(d_print_cast): Rewrite - simply print the left subcomponent.
* cp-demint.c (cplus_demangle_fill_component): Handle
DEMANGLE_COMPONENT_CONVERSION.

* testsuite/demangle-expected: Add tests.

[Bug other/61321] demangler crash on casts in template parameters

[trippels at gcc dot gnu.org]

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

--- Comment #16 from Markus Trippelsdorf  ---
Author: trippels
Date: Fri Nov 27 14:48:21 2015
New Revision: 231020

URL: https://gcc.gnu.org/viewcvs?rev=231020=gcc=rev
Log:
PR other/61321 - demangler crash on casts in template parameters

The fix for bug 59195:

 [C++ demangler handles conversion operator incorrectly]
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195

unfortunately makes the demangler crash due to infinite recursion, in
case of casts in template parameters.

For example, with:

 template struct A {};
 template  void function_temp(A) {}
 template void function_temp(A);

The 'function_temp' instantiation above mangles to:

  _Z13function_tempIiEv1AIXszcvT_Li999EEE

The demangler parses this as:

typed name
  template
name 'function_temp'
template argument list
  builtin type int
  function type
builtin type void
argument list
  template  (*)
name 'A'
template argument list
  unary operator
operator sizeof
unary operator
  cast
template parameter 0(**)
  literal
builtin type int
name '999'

And after the fix for 59195, due to:

 static void
 d_print_cast (struct d_print_info *dpi, int options,
   const struct demangle_component *dc)
 {
 ...
   /* For a cast operator, we need the template parameters from
  the enclosing template in scope for processing the type.  */
   if (dpi->current_template != NULL)
 {
   dpt.next = dpi->templates;
   dpi->templates = 
   dpt.template_decl = dpi->current_template;
 }

when printing the template argument list of A (what should be ""), the template parameter 0 (that is, "T_", the '**' above) now
refers to the first parameter of the the template argument list of the
'A' template (the '*' above), exactly what we were already trying to
print.  This leads to infinite recursion, and stack exaustion.  The
template parameter 0 should actually refer to the first parameter of
the 'function_temp' template.

Where it reads "for the cast operator" in the comment in d_print_cast
(above), it's really talking about a conversion operator, like:

  struct A { template  explicit operator U(); };

We don't want to inject the template parameters from the enclosing
template in scope when processing a cast _expression_, only when
handling a conversion operator.

The problem is that DEMANGLE_COMPONENT_CAST is currently ambiguous,
and means _both_ 'conversion operator' and 'cast expression'.

Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
which does what DEMANGLE_COMPONENT_CAST does today, and making
DEMANGLE_COMPONENT_CAST just simply print its component subtree.

I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
d_print_comp_inner still do:

 @@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int
options,
d_print_comp (dpi, options, dc->u.s_extended_operator.name);
return;

 case DEMANGLE_COMPONENT_CAST:
   d_append_string (dpi, "operator ");
 - d_print_cast (dpi, options, dc);
 + d_print_conversion (dpi, options, dc);
   return;

leaving the unary cast case below calling d_print_cast, but seems to
me that spliting the component types makes it easier to reason about
the code.

g++'s testsuite actually generates three symbols that crash the
demangler in the same way.  I've added those as tests in the demangler
testsuite as well.

And then this fixes PR other/61233 too, which happens to be a
demangler crash originally reported to GDB, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16957

Bootstrapped and regtested on x86_64 Fedora 20.

Also ran this through GDB's testsuite.  GDB will require a small
update to use DEMANGLE_COMPONENT_CONVERSION in one place it's using
DEMANGLE_COMPONENT_CAST in its sources.

libiberty/
2015-11-27  Pedro Alves  

PR other/61321
PR other/61233
* demangle.h (enum demangle_component_type)
: New value.
* cp-demangle.c (d_demangle_callback, d_make_comp): Handle
DEMANGLE_COMPONENT_CONVERSION.
(is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
instead of DEMANGLE_COMPONENT_CAST.
(d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
component if handling a conversion.
(d_count_templates_scopes, d_print_comp_inner): Handle
DEMANGLE_COMPONENT_CONVERSION.
(d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
of DEMANGLE_COMPONENT_CAST.
(d_print_cast): Rename as ...
(d_print_conversion): ... this.  Adjust comments.
(d_print_cast): Rewrite - simply print the left subcomponent.
* cp-demint.c (cplus_demangle_fill_component): Handle
DEMANGLE_COMPONENT_CONVERSION.

* testsuite/demangle-expected: Add tests.

[Bug tree-optimization/68553] gcc.dg/vect/pr68445.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug ada/68564] ada fails to bootstrap on sparc64-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
You probably need to tweak gcc-interface/Makefile.in (Sparc Linux):

  ifeq ($(strip $(shell $(GCC_FOR_TARGET) $(GNATLIBCFLAGS)
-print-multi-os-directory)),../lib64)
LIBGNAT_TARGET_PAIRS = \
$(LIBGNAT_TARGET_PAIRS_COMMON) $(LIBGNAT_TARGET_PAIRS_64)
  else
LIBGNAT_TARGET_PAIRS = \
$(LIBGNAT_TARGET_PAIRS_COMMON) $(LIBGNAT_TARGET_PAIRS_32)
  endif

to make it pick the right system.ads file.

[Bug tree-optimization/68553] gcc.dg/vect/pr68445.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 27 11:17:51 2015
New Revision: 231006

URL: https://gcc.gnu.org/viewcvs?rev=231006=gcc=rev
Log:
2015-11-27  Richard Biener  

PR tree-optimization/68553
* tree-vect-slp.c (vect_create_mask_and_perm): Skip VEC_PERM_EXPR
generation for 1:1 permutations.
(vect_transform_slp_perm_load): Detect 1:1 permutations.

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

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
(In reply to Joost VandeVondele from comment #15)
> Created attachment 29738 [details]
> maybe smaller testcase version ?
> 
> Attached is what I think is roughly the smallest kernel of this type that we
> have in the code. I checked this is at least partially vectorized with
> ifort, but not so with gfortran trunk. It is still not such a small
> testcase, I'm afraid.

With BB vectorization enhancement this still doesn't vectorize because the
four remaining stores in the function are not grouped.

The non-reduced testcase has the same issue.

I suppose to much scalarization has happened and we don't consider candidates
that do not end in a vector write to memory.

[Bug rtl-optimization/68194] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
*** Bug 68250 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/68250] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Dup.

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

[Bug target/68214] gcc.dg/cwsc1.c fails on arm-none-eabi

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Oh, it needs -mcpu=arm7tdmi -mthumb -mfloat-abi=soft -marm.
confirmed

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

[mar...@mpa-garching.mpg.de]

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

--- Comment #2 from Martin Reinecke  ---
OK, the problematic commit appears to be:

Revision 230759 - Directory Listing
Added Mon Nov 23 14:23:59 2015 UTC (3 days, 23 hours ago) by dje

Correct graphite*.c ISL header file inclusion order.
* system.h: Don't poison calloc and strdup if USES_ISL is defined.
* graphite-dependences.c: Define USES_ISL.  Include ISL header files
after GCC header files and before graphite header files.
* graphite-dependences.c: Same.
* graphite-isl-ast-to-gimple.c: Same.
* graphite-optimize-isl.c: Same.
* graphite-poly.c: Same.
* graphite-scop-detection.c: Same.
* graphite-sese-to-poly.c: Same.
* graphite.c: Same.

[Bug ada/68564] ada fails to bootstrap on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose  ---
Created attachment 36855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36855=edit
patch

proposed patch; check for the multiarch string before checking for the
directory name.

[Bug fortran/68218] ALLOCATE with size given by a module function

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Fri Nov 27 14:08:23 2015
New Revision: 231014

URL: https://gcc.gnu.org/viewcvs?rev=231014=gcc=rev
Log:
gcc/fortran/ChangeLog:

2015-11-27  Andre Vehreschild  

PR fortran/68218
* trans-array.c (gfc_array_init_size): Add gfc_evaluate_now() when
array spec in allocate is a function call.

gcc/testsuite/ChangeLog:

2015-11-27  Andre Vehreschild  

PR fortran/68218
* gfortran.dg/allocate_with_arrayspec_1.f90: New test.



Added:
   
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_arrayspec_1.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 68559, which changed state.

Bug 68559 Summary: Excessive peeling for gaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68559

   What|Removed |Added

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

[Bug c++/68584] New: nested generic lambda with trailing return type cases compiler crash

[Gaetano.Checinski at gmail dot com]

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

Bug ID: 68584
   Summary: nested generic lambda with trailing return type cases
compiler crash
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Gaetano.Checinski at gmail dot com
  Target Milestone: ---

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

the following code causes a crash:

//auto F = [](auto){return 1; };
auto call = [](auto/*int*/) {
  auto F = [](auto){return 1; };
  return [=](auto /*int*/ x) -> decltype( F(x) ) { return F(x);};
};

int main(){
  call(1);
}


It has been tested with g++-5.2 and g++-6.0(20151122).
Might be related to bugID:66135 and bugID:61814

[Bug tree-optimization/68559] Excessive peeling for gaps

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 27 14:17:28 2015
New Revision: 231015

URL: https://gcc.gnu.org/viewcvs?rev=231015=gcc=rev
Log:
2015-11-27  Richard Biener  

PR tree-optimization/68559
* tree-vect-data-refs.c (vect_analyze_group_access_1): Move
peeling for gap checks ...
* tree-vect-stmts.c (vectorizable_load): ... here and relax
for SLP.
* tree-vect-loop.c (vect_analyze_loop_2): Re-set
LOOP_VINFO_PEELING_FOR_GAPS before re-trying without SLP.

* gcc.dg/vect/slp-perm-4.c: Adjust again.
* gcc.dg/vect/pr45752.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr45752.c
trunk/gcc/testsuite/gcc.dg/vect/slp-perm-4.c
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/68559] Excessive peeling for gaps

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

[bacon at cs dot nyu.edu]

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

--- Comment #1 from David Bacon  ---
Version 5.2.0 of gcc for the same Cygwin 64-bit platform fails in the same way
on the same source line.

[Bug ada/68590] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Botcazou  ---
Yes, it comes from:

2015-11-26  Richard Biener  

* genmatch.c (dt_simplify::gen_1): For generic wrap all
multi-result-use captures in a SAVE_EXPR.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[gang.chen.5i5j at gmail dot com]

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

--- Comment #22 from Chen Gang  ---
(In reply to Jakub Jelinek from comment #21)
> Author: jakub
> Date: Fri Nov 27 08:59:55 2015
> New Revision: 230999
> 
> URL: https://gcc.gnu.org/viewcvs?rev=230999=gcc=rev

This way looks OK to me.

But for C++, it has no pr63326 issue, do we still need to modify
gcc/cp/parser.c?

pr42979 is related with this issue, more or less. May this patch also fix
pr42979 by the way? If this patch really fix pr42979, we will still need
gcc/cp/parser.c (both C and C++ have pr42979 issue).


Thanks.

[Bug ada/68564] Ada fails to bootstrap on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #5 from Matthias Klose  ---
Author: doko
Date: Sat Nov 28 02:41:20 2015
New Revision: 231029

URL: https://gcc.gnu.org/viewcvs?rev=231029=gcc=rev
Log:
2015-11-28  Matthias Klose  

PR ada/68564
* gcc-interface/Makefile.in: Fix sparc/sparc64 bitness detection.

Modified:
branches/gcc-5-branch/gcc/ada/ChangeLog
branches/gcc-5-branch/gcc/ada/gcc-interface/Makefile.in

[Bug tree-optimization/68576] scev failed for loop auto parallelize

[majun4950646 at 163 dot com]

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

--- Comment #3 from majun  ---
(In reply to Richard Biener from comment #2)
> I think the issue is that with respect to loop 4 the evolution is
> 
> _76 = { 1 + _373, + , 1 }_4
> 
> but with all the casting we end up with
> 
> (set_scalar_evolution
>   instantiated_below = 5
>   (scalar = _470)
>   (scalar_evolution = {(unsigned long) stride.92_29 + (unsigned long)
> offset.93_35, +, (unsigned long) stride.92_29}_1))
> )
> 
> and instantiate_scev for the SCEV above fails.  Likewise for instantiate
> below 10, only below 15 succeeds in the end.

Yes,it failed in CASE_CONVERT while do instantiate_scev_r.
BTW, another example is interchange-1.f:
---
  subroutine foo(f1,f2,f3,f4,f5,f6,f7,f8,f9,f0,g1,g2,g3)
  implicit none
  integer f4,f3,f2,f1
  integer g4,g5,g6,g7,g8,g9
  integer i1,i2,i3,i4,i5

  real*8 g1(5,f3,f2,f1),g2(5,5,f3,f2,f1),g3(5,f3,f2,f1)
  real*8 f0(5,5,f3,f2,f1),f9(5,5,f3,f2,f1),f8(5,5,f3,f2,f1)
  real*8 f7(5,5,f3,f2,f1),f6(5,5,f3,f2,f1),f5(5,5,f3,f2,f1)

  do i3=1,f1
 g8=mod(i3+f1-2,f1)+1
 g9=mod(i3,f1)+1
 do i4=1,f2
g6=mod(i4+f2-2,f2)+1
g7=mod(i4,f2)+1
do i5=1,f3
   g4=mod(i5+f3-2,f3)+1
   g5=mod(i5,f3)+1
   do i1=1,5
  g3(i1,i5,i4,i3)=0.0d0
  do i2=1,5
 g3(i1,i5,i4,i3)=g3(i1,i5,i4,i3)+
 1g2(i1,i2,i5,i4,i3)*g1(i2,i5,i4,i3)+
 2f0(i1,i2,i5,i4,i3)*g1(i2,g5,i4,i3)+
 3f9(i1,i2,i5,i4,i3)*g1(i2,i5,g7,i3)+
 4f8(i1,i2,i5,i4,i3)*g1(i2,i5,i4,g9)+
 5f7(i1,i2,i5,i4,i3)*g1(i2,g4,i4,i3)+
 6f6(i1,i2,i5,i4,i3)*g1(i2,i5,g6,i3)+
 7f5(i1,i2,i5,i4,i3)*g1(i2,i5,i4,g8)
  enddo
   enddo
enddo
 enddo
  enddo
  return
  end
---
the innermost 2 loops have constant loop bound, and this example can paralle in
the 2nd loop instead of 3rd loop.

so,any plan to improve CASE_CONVERT or type casting in instantiate_scev ?

Thanks!
---Jun

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

[bacon at cs dot nyu.edu]

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

--- Comment #3 from David Bacon  ---
A workaround for this gcc bug is to replace the offending 1e37 (the only one in
the .i file) with 10.1 (1{37 zeroes}.1). 
That works in the 5.2.0 case, anyway.

It is worth noting also that the segfault occurred with every pure positive
power of 10 that I tried (quite a few):  the .1 matters, if not to the
floating-point value realized.

  dB

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

[bacon at cs dot nyu.edu]

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

--- Comment #2 from David Bacon  ---
A workaround for this gcc bug is to replace the offending 1e37 (the only one in
the .i file) with 10.1 (1{37 zeroes}.1). 
That works in the 5.2.0 case, anyway.

It is worth noting also that the segfault occurred with every pure positive
power of 10 that I tried (quite a few):  the .1 matters, if not to the
floating-point value realized.

  dB

[Bug ada/68590] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Investigating.

[Bug ada/68564] Ada fails to bootstrap on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #4 from Matthias Klose  ---
Author: doko
Date: Sat Nov 28 02:39:20 2015
New Revision: 231028

URL: https://gcc.gnu.org/viewcvs?rev=231028=gcc=rev
Log:
2015-11-28  Matthias Klose  

PR ada/68564
* gcc-interface/Makefile.in: Fix sparc/sparc64 bitness detection.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in

[Bug libitm/68591] trans-mem: missing transactional read in transaction when using -O1

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #1 from torvald at gcc dot gnu.org ---
Filed as libitm, but this is really a compiler problem, and not related to
libitm.

[Bug libitm/68591] New: trans-mem: missing transactional read in transaction when using -O1

[torvald at gcc dot gnu.org]

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

Bug ID: 68591
   Summary: trans-mem: missing transactional read in transaction
when using -O1
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libitm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: torvald at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36860
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36860=edit
test case

The attached test case miscompiles in that it does not transform the load from
ptr in the conditional in the transaction into a transactional load.  Instead,
it seems to assume that ptr's value is fixed and not shared with other threads.
 This changes when the synchronization that could potentially make it share
gets inlined into the function with the transaction.  For simplicity, this is a
single-threaded test, but I discovered that in a multi-threaded setting.

[Bug other/61321] demangler crash on casts in template parameters

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||cas43 at cs dot stanford.edu

--- Comment #18 from Mikhail Maltsev  ---
*** Bug 63159 has been marked as a duplicate of this bug. ***

[Bug other/63159] Demangler crash

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

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

--- Comment #1 from Mikhail Maltsev  ---
Fixed with PR61321. Now demangles as:
PhysBAM::HETERO_DIFF::HESSIAN, decltype
(PhysBAM::HETERO_DIFF::MAT_MAP_1,
PhysBAM::HETERO_DIFF::ARG<1> >,
PhysBAM::HETERO_DIFF::VEC_MAP_1,
PhysBAM::HETERO_DIFF::ARG<1> > >
>::Type((PhysBAM::HETERO_DIFF::MAT_HOLDER,
PhysBAM::HETERO_DIFF::VEC_END, PhysBAM::HETERO_DIFF::MAT_END>)(),
(PhysBAM::VECTOR::SCALAR)()))>
PhysBAM::HETERO_DIFF::operator*,
PhysBAM::HETERO_DIFF::MAT_HOLDER,
PhysBAM::HETERO_DIFF::VEC_END, PhysBAM::HETERO_DIFF::MAT_END>
>(PhysBAM::VECTOR::SCALAR,
PhysBAM::HETERO_DIFF::HESSIAN,
PhysBAM::HETERO_DIFF::MAT_HOLDER,
PhysBAM::HETERO_DIFF::VEC_END, PhysBAM::HETERO_DIFF::MAT_END> > const&)

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

[Bug c++/56606] GCC refuses to emit long calls for operator new/delete on PowerPC

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Target||powerpc64
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-28
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.7.2, 4.8.5, 6.0

--- Comment #2 from Martin Sebor  ---
Confirmed with recent trunk (6.0.0 20151125) on powerpc64le-redhat-linux-gnu.

[Bug tree-optimization/68592] New: [6 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1403 with -fprofile-generate

[miyuki at gcc dot gnu.org]

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

Bug ID: 68592
   Summary: [6 Regression] ICE in vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1403 with -fprofile-generate
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miyuki at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

This ICE started to show up during LTO build of 416.gamess with
-fprofile-generate.
r230895 - OK
r230981 - ICE

$ cat gamess_min.f 
  PARAMETER (MXCPGA=320,ZERO=0.0)
  DIMENSION CPNORM(MXCPGA),CDNORM(MXCPGA),
 *  CFNORM(MXCPGA)  
 KTYPIL= KTYPI()
 DO 84 K=1,NOGTF
   LMP=LMP+1
   CFNORM(LMP)=ZERO
   IF (KTYPIL.EQ.1) LMP=CMPILMP
   IF (KTYPIL.EQ.2) CPNORM(LMP)=CMPILMP
   IF (KTYPIL.EQ.3) CDNORM(LMP)=CMPILMP
   IF (KTYPIL.EQ.4) LMP=CMPILMP
   IF (KTYPIL.EQ.6) LMP=CMPILMP
   84CONTINUE
 CALL MMPNOR(CPNORM,CDNORM,CFNORM) 
  END

$ f951 -Ofast -march=haswell -fprofile-generate -quiet gamess_min.f 
gamess_min.f:1:0:

   PARAMETER (MXCPGA=320,ZERO=0.0)


internal compiler error: in vect_get_vec_def_for_operand, at
tree-vect-stmts.c:1403
0xd777c9 vect_get_vec_def_for_operand(tree_node*, gimple*, tree_node*)
/home/miyuki/gcc/src/gcc/tree-vect-stmts.c:1403
0xd83629 vectorizable_conversion
/home/miyuki/gcc/src/gcc/tree-vect-stmts.c:3991
0xd8ed2a vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
/home/miyuki/gcc/src/gcc/tree-vect-stmts.c:8049
0xd94f84 vect_transform_loop(_loop_vec_info*)
/home/miyuki/gcc/src/gcc/tree-vect-loop.c:6858
0xdb0a17 vectorize_loops()
/home/miyuki/gcc/src/gcc/tree-vectorizer.c:548
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[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 #9 from wam at hiwaay dot net ---
On 11/27/15 13:32, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68427
>
> --- Comment #8 from Jonathan Wakely  ---
> Similarly, _STD_C_H_ is not a valid header guard in StdC.h, and _ASSERT0_H_ is
> not valid in Assert.h, and _GAUSS_H_ is not valid in gauss.h
>
> Same goes for
>
> #  define __ASSERT_FUNCTION ((__const char *) 0)
>
>
> I don't know what the point of this is:
>
> #ifdef  __linux__   // Linux :-) 
> #include 
> #elif defined   __FreeBSD__ // FreeBSD & SGI :-) 
> #include  // typedef uint :-) 
> #endif
>
> But the  header is deprecated and you should include 
>
> The code has a number of problems, but GCC is not the cause.
>


Very well, you are correct  for FreeBSD. My linux box defines 
_STDIO_H in /usr/include/stdio.h (w/o trailing '_'), but FreeBSD 9.3R 
has the trailing '_'  Pilot error, but a bit subtle & hard to track 
down since it was/is compiling on my linux box. Sorry for the bother, I 
will address this in my headers. Thanks :-/ 

[Bug c++/68113] VLA+typeof+new -- confusing warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-28
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.2.0, 6.0

--- Comment #1 from Martin Sebor  ---
Confirmed with decltype instead of __typeof__.  The 'new decltype(a)' construct
is valid provided a is not a VLA.  The strange warning message is caused by gcc
not distinguishing 'new (int[n])' (a GCC extension) from 'new decltype(a)' in
the function that issues the warning (build_new_1 in cp/init.c).

$ cat x.cpp && /build/gcc-trunk-svn/gcc/xg++ -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic -std=c++11 x.cpp 
int main ()
{
int n = 1;
int a [n];
new decltype (a);
}
x.cpp: In function ‘int main()’:
x.cpp:4:13: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
 int a [n];
 ^

x.cpp:5:9: warning: non-constant array new length must be specified without
parentheses around the type-id [-Wvla]
 new decltype (a);
 ^~~~

Clang rejects the code because it doesn't allow VLAs in new expressions:

$ /build/llvm-trunk/bin/clang++ -Wall -Wextra -std=c++11 x.cpp
x.cpp:5:9: error: 'new' cannot allocate object of variably modified type
  'decltype(a)' (aka 'int [n]')
new decltype (a);
^
1 error generated.

[Bug ada/68564] Ada fails to bootstrap on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #7 from Matthias Klose  ---
fixed, also checked in on the 4.9 branch.

[Bug ada/68564] Ada fails to bootstrap on sparc64-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #6 from Matthias Klose  ---
Author: doko
Date: Sat Nov 28 02:42:37 2015
New Revision: 231030

URL: https://gcc.gnu.org/viewcvs?rev=231030=gcc=rev
Log:
2015-11-28  Matthias Klose  

PR ada/68564
* gcc-interface/Makefile.in: Fix sparc/sparc64 bitness detection.

Modified:
branches/gcc-4_9-branch/gcc/ada/ChangeLog
branches/gcc-4_9-branch/gcc/ada/gcc-interface/Makefile.in

[Bug c++/68593] New: Problem compiling random.h

[c.spanakis83 at gmail dot com]

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

Bug ID: 68593
   Summary: Problem compiling random.h
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: c.spanakis83 at gmail dot com
  Target Milestone: ---

Hello I tried to compile a c++ file using random.h and i got this message:

In file included from
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/random:42:0,
 from main.cpp:9:
/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/include/c++/limits:1561:7: internal
compiler error: Segmentation fault
   max() _GLIBCXX_USE_NOEXCEPT { return __FLT_MAX__; }

what could be the problem?

[Bug c++/68312] [6 Regression] Memory leaks in cilkplus

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed in trunk.

[Bug c++/68586] New: [6 Regression] Enum template parameter wrongly rejected

[reichelt at gcc dot gnu.org]

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

Bug ID: 68586
   Summary: [6 Regression] Enum template parameter wrongly
rejected
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet is wrongly rejected on trunk (6.0.0 20151122):


enum E { x = 1, y = x << 1 };

template struct A {};

A a;


bug.cc:5:4: error: invalid conversion from 'int' to 'E' [-fpermissive]
 A a;
^

During reduction from a larger testcase I had to tweak the settings
of the garbage collector (--param ggc-min-expand=0) to make it appear reliably.

[Bug other/61233] Demangler crash (GDB PR 16957)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
fixed.

[Bug other/61321] demangler crash on casts in template parameters

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #17 from Markus Trippelsdorf  ---
fixed.

[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 #6 from wam at hiwaay dot net ---
I see this is labelled as resolved. That is *NOT* true for me. All versions of
gcc on FreeBSD 9.3R that I have tried (4.8.5, 4.9.4, 5.2.0, 5.2.1) still
reproduce this bug as of today. I pkg-upgraded all versions last evening &
tried them this A.M. The header files are where they are supposed to be (&
where intel's ICC is able to find them), etc. Intel's ICC is able to compile
this stuff cleanly nightly under FC14 64-bit across my LAN, no problems. I am
stuck under FreeBSD until this gets fixed :-( 

[Bug bootstrap/68540] 6.0 build process broken on Linux Mint, potential include ordering problem

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-27
 CC||reichelt at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Volker Reichelt  ---
I have the same problem on an OpenSUSE 13.1 distribution.

[Bug sanitizer/68587] New: [6 Regression][UBSAN] ICE in expand_insn, at optabs.c:6974

[burnus at gcc dot gnu.org]

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

Bug ID: 68587
   Summary: [6 Regression][UBSAN] ICE in expand_insn, at
optabs.c:6974
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36857=edit
test.ii, compile with: g++ -Ofast -fsanitize=undefined

Very recently, GCC 6 compiled the big program - since today it fails with an
ICE.

Compile the reduced program with:
  g++ -Ofast -fsanitize=undefined -S test.ii


It fails here with:

test27.ii: In member function ‘int MSMeasurement::compareWithGrid(const
MSMeasurement&, const ECoordinate&, const ECoordinate&) const’:
test27.ii:128:28: internal compiler error: in expand_insn, at optabs.c:6974
 double fa=floor(a/g);
^

0xc2c143 expand_insn(insn_code, unsigned int, expand_operand*)
../../gcc/optabs.c:6974
0xb026a4 expand_direct_optab_fn
../../gcc/internal-fn.c:2147
0x91c69a expand_call_stmt
../../gcc/cfgexpand.c:2565
0x91c69a expand_gimple_stmt_1
../../gcc/cfgexpand.c:3525
0x91c69a expand_gimple_stmt
../../gcc/cfgexpand.c:3688
0x91f25a expand_gimple_basic_block
../../gcc/cfgexpand.c:5694
0x924b46 execute
../../gcc/cfgexpand.c:6309

[Bug sanitizer/68587] [6 Regression][UBSAN] ICE in expand_insn, at optabs.c:6974

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu
   Target Milestone|--- |6.0

[Bug c++/68588] New: GCC requires constexpr for template non-type parameter, even though constexpr conversion operator exists

[petr at kalinin dot nnov.ru]

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

Bug ID: 68588
   Summary: GCC requires constexpr for template non-type
parameter, even though constexpr conversion operator
exists
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petr at kalinin dot nnov.ru
  Target Milestone: ---

Consider the following code:

struct A {
constexpr operator int() { return 42; }
};

template 
void foo() {}

void bar(A a) {
foo();
}

int main() {
foo();

const int i = 42;
foo();  // (1)

A a{};

static_assert(i == a, "");
bar(a);
foo();  // error here
}

Clang 3.7 with c++14 accepts this, while gcc 5.2.0 with c++14 (by "g++
--std=c++14 b.cpp -o b") does not, producing the following message:

b.cpp: In function ‘int main()’:
b.cpp:22:9: error: the value of ‘a’ is not usable in a constant expression
 foo();  // error here
 ^
b.cpp:18:7: note: ‘a’ was not declared ‘constexpr’
 A a{};
   ^

This behavior of GCC seems at at least strange, as it allows "a" in
static_assert, as well in bar(), but not directly in foo. Moreover,
A::operator int() is declared constexpr and does not evaluate any class
members, therefore use of "a" should be converted constant expression.


This is from my question
http://stackoverflow.com/questions/33957274/type-conversion-at-template-non-type-argument-without-constexpr/33958291.
The last sentence here is reworded from Serge Ballesta's answer there.

[Bug target/68214] gcc.dg/cwsc1.c fails on arm-none-eabi

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
  Known to fail||6.0

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Mine.

[Bug c++/68588] GCC requires constexpr for template non-type parameter, even though constexpr conversion operator exists

[petr at kalinin dot nnov.ru]

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

--- Comment #1 from pkalinin  ---
[Attribution was incorrect, the last sentence is reworded from Columbo's
answer. Sorry.]

[Bug sanitizer/68587] [6 Regression][UBSAN] ICE in expand_insn, at optabs.c:6974

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
The options can be reduced to:
   g++ -O1 -ffast-math -fsanitize=null

[Bug sanitizer/68587] [6 Regression][UBSAN] ICE in expand_insn, at optabs.c:6974

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
has nothing to do with sanitizer. dup.

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

[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #12 from Markus Trippelsdorf  ---
*** Bug 68587 has been marked as a duplicate of this bug. ***

[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0

[iains at gcc dot gnu.org]

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

--- Comment #33 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #32)
> reduced testcase:

..however this is not "our" bug, so there's no known reason to keep this PR
open, right?

.. if no-one objects by Monday 30th, then let's close it.

[Bug ada/68590] New: FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"

[vries at gcc dot gnu.org]

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

Bug ID: 68590
   Summary: FAIL: gnat.dg/loop_optimization19.adb
scan-tree-dump-not optimized "Index_Check"
   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 r231009

Target: x86_64-pc-linux-gnu
Configured with: configure --enable-checking=yes,rtl
--enable-languages=c,c++,fortran,go,java,objc,obj-c++,ada

[Bug c++/56606] GCC refuses to emit long calls for operator new/delete on PowerPC

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Test case and its output:

$ cat u.cpp && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -Wall
-Wextra -c -mlongcall u.cpp && objdump -r u.o
extern void foo();
void bar() {
foo();
new char;
}

u.o: file format elf64-powerpcle

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE  VALUE 
 R_PPC64_REL16_HA  .TOC.
0004 R_PPC64_REL16_LO  .TOC.+0x0004
000c R_PPC64_TOC16_HA  .toc
0010 R_PPC64_TOC16_LO_DS  .toc
0030 R_PPC64_REL24 _Znwm


RELOCATION RECORDS FOR [.toc]:
OFFSET   TYPE  VALUE 
 R_PPC64_ADDR64_Z3foov


RELOCATION RECORDS FOR [.eh_frame]:
OFFSET   TYPE  VALUE 
001c R_PPC64_REL32 .text

[Bug c++/68312] [6 Regression] Memory leaks in cilkplus

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Fri Nov 27 09:36:20 2015
New Revision: 231001

URL: https://gcc.gnu.org/viewcvs?rev=231001=gcc=rev
Log:
Fix memory leak in cilk

PR c++/68312
* c-array-notation.c (fix_builtin_array_notation_fn):
Use release_vec_vec instead of vec::release.
(build_array_notation_expr): Likewise.
(fix_conditional_array_notations_1): Likewise.
(fix_array_notation_expr): Likewise.
(fix_array_notation_call_expr): Likewise.
PR c++/68312
* cp-array-notation.c (expand_sec_reduce_builtin):
Likewise.
(create_array_refs): Replace argument with const reference.
(expand_an_in_modify_expr): Likewise.
(cp_expand_cond_array_notations): Likewise.
(expand_unary_array_notation_exprs): Likewise.
PR c++/68312
* array-notation-common.c (cilkplus_extract_an_triplets):
Release vector of vectors.
* cilk.c (gimplify_cilk_spawn): Free allocated memory.
PR c++/68312
* vec.h (release_vec_vec): New function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/array-notation-common.c
trunk/gcc/c-family/cilk.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-array-notation.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-array-notation.c
trunk/gcc/vec.h