[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Jul 17 07:47:19 2014
New Revision: 212738

URL: https://gcc.gnu.org/viewcvs?rev=212738&root=gcc&view=rev
Log:
2014-07-17  Richard Biener  

PR rtl-optimization/61801
* sched-deps.c (sched_analyze_2): For ASM_OPERANDS and
ASM_INPUT don't set reg_pending_barrier if it appears in a
debug-insn.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-deps.c

[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Thu Jul 17 07:48:49 2014
New Revision: 212739

URL: https://gcc.gnu.org/viewcvs?rev=212739&root=gcc&view=rev
Log:
2014-07-17  Richard Biener  

PR rtl-optimization/61801
* sched-deps.c (sched_analyze_2): For ASM_OPERANDS and
ASM_INPUT don't set reg_pending_barrier if it appears in a
debug-insn.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/sched-deps.c

[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.10.0, 4.8.4, 4.9.2
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.4
  Known to fail|4.10.0  |

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

[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Thu Jul 17 07:49:44 2014
New Revision: 212740

URL: https://gcc.gnu.org/viewcvs?rev=212740&root=gcc&view=rev
Log:
2014-07-17  Richard Biener  

PR rtl-optimization/61801
* sched-deps.c (sched_analyze_2): For ASM_OPERANDS and
ASM_INPUT don't set reg_pending_barrier if it appears in a
debug-insn.

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/sched-deps.c

[Bug c/61779] gcc -Og fails with impossible constraint on legal C code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.9.2
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.2

--- Comment #8 from Richard Biener  ---
Fixed for 4.9.2.

[Bug c/61779] gcc -Og fails with impossible constraint on legal C code

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Jul 17 07:53:16 2014
New Revision: 212741

URL: https://gcc.gnu.org/viewcvs?rev=212741&root=gcc&view=rev
Log:
2014-07-17  Richard Biener  

Backport from mainline
2014-07-14  Richard Biener  

PR tree-optimization/61779
* tree-ssa-copy.c (copy_prop_visit_cond_stmt): Always try
simplifying a condition.

* gcc.dg/tree-ssa/ssa-copyprop-2.c: New testcase.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/tree-ssa/ssa-copyprop-2.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-copy.c

[Bug c/61741] wrong code with -fno-strict-overflow

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Jul 17 07:57:30 2014
New Revision: 212742

URL: https://gcc.gnu.org/viewcvs?rev=212742&root=gcc&view=rev
Log:
2014-07-17  Richard Biener  

Backport from mainline
2014-07-10  Richard Biener  

PR c-family/61741
* c-c++-common/torture/pr61741.c: Use signed char.

2014-07-09  Richard Biener  

PR c-family/61741
* c-gimplify.c (c_gimplify_expr): Gimplify self-modify expressions
using unsigned arithmetic if overflow does not wrap instead of
if overflow is undefined.

* c-c++-common/torture/pr61741.c: New testcase.

Added:
branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/pr61741.c
Modified:
branches/gcc-4_9-branch/gcc/c-family/ChangeLog
branches/gcc-4_9-branch/gcc/c-family/c-gimplify.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/61741] wrong code with -fno-strict-overflow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.9.2
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.2

--- Comment #9 from Richard Biener  ---
Fixed on trunk and 4.9 branch.

[Bug ipa/61085] [4.9/4.10 Regression] wrong code with -O2 -fno-early-inlining (maybe wrong devirtualization)

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Can you open a new bug for that?

[Bug c++/61804] rejects-valid if parenthesized temporary is incremented

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jul 17 08:32:18 2014
New Revision: 212743

URL: https://gcc.gnu.org/viewcvs?rev=212743&root=gcc&view=rev
Log:
/cp
2014-07-17  Paolo Carlini  

PR c++/61804
* parser.c (cp_parser_tokens_start_cast_expression): Return -1
for '++' and '--'.

/testsuite
2014-07-17  Paolo Carlini  

PR c++/61804
* g++.dg/parse/pr61804.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr61804.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/61804] rejects-valid if parenthesized temporary is incremented

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Fixed for 4.10.

[Bug ipa/61823] [4.10 Regression] gcc.dg/torture/pr43879_[12].c FAILs with -fno-inline

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-07-17
 CC||hubicka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.10.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
We fail to process the tbl initializer in IPA PTA (I guess Honza broke this
again with on-demand DECL_INITIAL loading...)

But then when a function pointer is computed as pointing to "anything" we
fail to have sth like "anything-called" to make _all_ functions possibly
called receive the proper arguments.  That's a pre-existing bug.

Honza, how do I update

  /* If this is a global variable with an initializer and we are in
 IPA mode generate constraints for it.  */
  if (DECL_INITIAL (decl)
  && vnode->definition)
{

which now fails?

[Bug tree-optimization/61822] gcc.dg/vect/vect-cond-reduc-1.c FAILs

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
It looks like 
/* { dg-require-effective-target vect_condition } */
directive was missed in vect-cond-reduc-1.c test.
I will fix it asap.

[Bug ipa/61823] [4.10 Regression] gcc.dg/torture/pr43879_[12].c FAILs with -fno-inline

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  ---
>   /* If this is a global variable with an initializer and we are in
>  IPA mode generate constraints for it.  */
>   if (DECL_INITIAL (decl)
>   && vnode->definition)
> {
> 
> which now fails?

You need to call varpool_get_constructor

Honza

[Bug libstdc++/60936] [4.9 Regression] Binary code bloat with std::string

[d.v.a at ngs dot ru]

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

__vic  changed:

   What|Removed |Added

Summary|Binary code bloat with  |[4.9 Regression] Binary
   |std::string |code bloat with std::string
  Known to fail||4.9.0, 4.9.1

--- Comment #3 from __vic  ---
4.9.1 - same results

[Bug c++/61807] genautomata.c fails to compile

[y.rajesh.4683 at gmail dot com]

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

--- Comment #2 from Rajesh  ---
Hi,
  The default genautomata.c in the gcc-4.9.0 package doesn't have the explicit
conversions at two places. I have made this change and have been able to get
past this error. But I am just curious, if this change is valid and should be
added to the src.

[Bug fortran/61819] ICE in gfc_conv_descriptor_data_get

[sfilippone at uniroma2 dot it]

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

Salvatore Filippone  changed:

   What|Removed |Added

  Attachment #33127|0   |1
is obsolete||

--- Comment #3 from Salvatore Filippone  ---
Created attachment 33129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33129&action=edit
test case

Reduced test case, giving:
[sfilippo@jacobi leak-demo]$ gfortran -c foo-test-ice.f90
foo-test-ice.f90: In function ‘__final_foo_vector_field_mod_Vector_field’:
foo-test-ice.f90:62:0: internal compiler error: in
gfc_conv_descriptor_data_get, at fortran/trans-array.c:146
 end module foo_vector_field_mod
 ^
0x602fc5 gfc_conv_descriptor_data_get(tree_node*)
../../gcc/gcc/fortran/trans-array.c:146
0x60a24e gfc_array_deallocate(tree_node*, tree_node*, tree_node*, tree_node*,
tree_node*, gfc_expr*)
../../gcc/gcc/fortran/trans-array.c:5350
0x674bea gfc_trans_deallocate(gfc_code*)
../../gcc/gcc/fortran/trans-stmt.c:5484
0x5ff2b7 trans_code
../../gcc/gcc/fortran/trans.c:1798
0x66a583 gfc_trans_if_1
../../gcc/gcc/fortran/trans-stmt.c:989
0x670dea gfc_trans_if(gfc_code*)
../../gcc/gcc/fortran/trans-stmt.c:1020
0x5ff3a7 trans_code
../../gcc/gcc/fortran/trans.c:1736
0x672114 gfc_trans_simple_do
../../gcc/gcc/fortran/trans-stmt.c:1446
0x672114 gfc_trans_do(gfc_code*, tree_node*)
../../gcc/gcc/fortran/trans-stmt.c:1609
0x5ff37a trans_code
../../gcc/gcc/fortran/trans.c:1748
0x62966b gfc_generate_function_code(gfc_namespace*)
../../gcc/gcc/fortran/trans-decl.c:5765
0x600d61 gfc_generate_module_code(gfc_namespace*)
../../gcc/gcc/fortran/trans.c:1995
0x5bc031 translate_all_program_units
../../gcc/gcc/fortran/parse.c:4934
0x5bc031 gfc_parse_file()
../../gcc/gcc/fortran/parse.c:5144
0x5fa935 gfc_be_parse_file
../../gcc/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[sfilippo@jacobi leak-demo]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu/4.10/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu/4.10
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp
--with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc
--with-cloog=/home/travel/GNUBUILD/cloog
Thread model: posix
gcc version 4.10.0 20140716 (experimental) (GCC) 
[sfilippo@jacobi leak-demo]$

[Bug fortran/61819] ICE in gfc_conv_descriptor_data_get

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-07-17
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Confirmed on 4.9 and trunk (4.10).

[Bug fortran/61819] ICE in gfc_conv_descriptor_data_get

[sfilippone at uniroma2 dot it]

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

--- Comment #5 from Salvatore Filippone  ---
Code works with 4.8.3, so this is a regression.

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
Summary|ICE in  |[4.9/4.10 Regression] ICE
   |gfc_conv_descriptor_data_ge |in
   |t   |gfc_conv_descriptor_data_ge
   ||t

--- Comment #6 from Dominique d'Humieres  ---
> Code works with 4.8.3, so this is a regression.

Confirmed: revision r206362 (2014-01-06) is OK, r206567 (2014-01-12) gives the
ICE. Likely r206379 (pr59589).

[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.

[varvara.s.rainchik at gmail dot com]

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

Varvara Rainchik  changed:

   What|Removed |Added

 CC||varvara.s.rainchik at gmail 
dot co
   ||m

--- Comment #13 from Varvara Rainchik  ---
I experience the same problem with Android NDK. TLS is not supported into
Android, so I observe the similar test crash:

[New LWP 18636]

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 18636]
(gdb) bt
#0  gomp_icv (write=) at
/s/ndk-toolchain/src/build/../gcc/gcc-4.8/libgomp/libgomp.h:393
#1  0x0804a3d7 in omp_set_num_threads (n=4) at
/s/ndk-toolchain/src/build/../gcc/gcc-4.8/libgomp/env.c:657
#2  0x08049e70 in _thread (Id=0x1) at omp_test.c:19
#3  0x0804d119 in __pthread_start (arg=0x8087270) at
bionic/libc/bionic/pthread_create.cpp:153
#4  0x08055e1a in __start_thread (fn=0x804d0e0 <__pthread_start(void*)>,
arg=0x8087270) at bionic/libc/bionic/clone.cpp:39
#5  0x0806b9b7 in __bionic_clone () at
bionic/libc/arch-x86/bionic/__bionic_clone.S:42

I use android-ndk-r9d for x86 arch, gcc 4.8. Modified patch solves this issue.

[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.

[varvara.s.rainchik at gmail dot com]

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

--- Comment #14 from Varvara Rainchik  ---
Created attachment 33130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33130&action=edit
Modified patch

I will send this patch to gcc patches.

[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.

[varvara.s.rainchik at gmail dot com]

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

--- Comment #15 from Varvara Rainchik  ---
Created attachment 33131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33131&action=edit
Correct patch

[Bug middle-end/61268] [4.10 regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8262

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  ---
Richard,

from my POV, the patch is good to go.

Thanks.
  Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at gcc dot gnu.org]

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

--- Comment #47 from Rainer Orth  ---
Thomas,

any progress on this one?  SPARC bootstrap has been broken for almost two
months
now (yes, there's an out-of-tree workaround, but still).

Thanks.
  Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

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

--- Comment #48 from Richard Biener  ---
Please provide preprocessed source for jcf-parse.c and instructions on how
to configure a cross compiler from x86_64-linux.  Please also provide
disassembly around the failing place with enough context to spot it
in a cc1 generated output - best with an explanation what's wrong.

>From what Thomas says in comment #46 it looks like for some unknown
reason a HI load from a 1-byte aligned address is emitted:

(insn 688 687 689 (set (reg:HI 482)
(mem:HI (reg/v/f:SI 189 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2
A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1
 (nil))

but as the bswap pass emits a plain MEM_REF with an aligned type we should
go through the following path in expand:

if (modifier != EXPAND_WRITE
&& modifier != EXPAND_MEMORY
&& !inner_reference_p
&& mode != BLKmode
&& align < GET_MODE_ALIGNMENT (mode))
  {
if ((icode = optab_handler (movmisalign_optab, mode))
!= CODE_FOR_nothing)
  {
struct expand_operand ops[2];

/* We've already validated the memory, and we're creating a
   new pseudo destination.  The predicates really can't fail,
   nor can the generator.  */
create_output_operand (&ops[0], NULL_RTX, mode);
create_fixed_operand (&ops[1], temp);
expand_insn (icode, 2, ops);
temp = ops[0].value;
  }
else if (SLOW_UNALIGNED_ACCESS (mode, align))
  temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode),
0, TYPE_UNSIGNED (TREE_TYPE (exp)),
(modifier == EXPAND_STACK_PARM
 ? NULL_RTX : target),
mode, mode);

that is, go through extract_bit_field (supposed sparc doesn't have
movmisalign and is SLOW_UNALIGNED_ACCESS for HImode and 8-bit align).

So we need to figure out why we don't go the above path or why
extract_bit_field gets things wrong.

[Bug c++/61825] New: [4.10 regression] g++.dg/cpp0x/static_assert9.C FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 61825
   Summary: [4.10 regression] g++.dg/cpp0x/static_assert9.C FAILs
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Host: i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-unknown-linux-gnu
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-unknown-linux-gnu
 Build: i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-unknown-linux-gnu

Between 20140711 and 20140716, the ++.dg/cpp0x/static_assert9.C testcase start
to FAIL on at least Solaris/x86, Solaris/SPARC, and Linux/x86:

FAIL: g++.dg/cpp0x/static_assert9.C  -std=c++11 (test for excess errors)
FAIL: g++.dg/cpp0x/static_assert9.C  -std=c++1y (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1:
error: non-constant condition for static assertion
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/cpp0x/static_assert9.C:5:1:
error: '(f != 0u)' is not a constant expression

This is a regression from 4.9.

  Rainer

[Bug c++/61825] [4.10 regression] g++.dg/cpp0x/static_assert9.C FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[sfilippone at uniroma2 dot it]

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

--- Comment #7 from Salvatore Filippone  ---
The original code leaks memory like a sieve, and looks suspiciously similar to
PR55603. It is just possible that the whole area of function results needs to
be reviewed (I guess that would be no small task)

Salvatore

[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[sfilippone at uniroma2 dot it]

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

--- Comment #4 from Salvatore Filippone  ---
Looking at the original code of PR 61819, it is quite possible that the real
culprit are CLASS() ALLOCATABLE components, not necessarily the result itself
(being allocatable).
Salvatore

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thopre01 at gcc dot gnu.org]

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

--- Comment #49 from thopre01 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #48)
> 
> From what Thomas says in comment #46 it looks like for some unknown
> reason a HI load from a 1-byte aligned address is emitted:

Yep that's it. Just look at log for expand in the archive Rainer posted the
link to on this bug report and search for :1622. In the last step of gimple
(optimized) we can just see a single load. The log doesn't show the alignment
of a given load but from the code it should be correct.

Best regards.

[Bug middle-end/61826] [4.10 regression] gcc.dg/pr44024.c UNRESOLVED

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug middle-end/61826] New: [4.10 regression] gcc.dg/pr44024.c UNRESOLVED

[ro at gcc dot gnu.org]

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

Bug ID: 61826
   Summary: [4.10 regression] gcc.dg/pr44024.c UNRESOLVED
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Host: i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-unknown-linux-gnu
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-unknown-linux-gnu
 Build: i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-unknown-linux-gnu

Between 20140711 and 20140716, the gcc.dg/pr44024.c testcase became UNRESOLVED.
gcc.log shows

PASS: gcc.dg/pr44024.c (test for excess errors)
gcc.dg/pr44024.c: dump file does not exist
UNRESOLVED: gcc.dg/pr44024.c scan-tree-dump-not ccp1 "foo"

and indeed -fdump-tree-ccp1 dumps nothing here, unlike -fdump-tree-original
before this change:

2014-07-13  Jan Hubicka  

* gcc.dg/pr36901.h: Simplify because non-zero symbol folding no
longer happens during parsing.
* gcc.dg/pr44024.c: Update template.

This is a regression from 4.9.

  Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|thopre01 at gcc dot gnu.org|rguenth at gcc dot 
gnu.org

--- Comment #50 from Richard Biener  ---
Ah, we also expand one from a TARGET_MEM_REF:

;;   basic block 76, loop depth 2
;;pred:   79
  load_dst_215 = MEM[base: ptr_110, offset: 0B];

and TARGET_MEM_REF only handles the movmisalign case.  So it's either IVOPTs
not punting properly here (it does for unaligned accesses - grep for
STRICT_ALIGNMENT) or we need to put a bitfield extraction case into
TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too much
pessimized by not considering this).

I'll fix it somewhen after the cauldron unless somebody beats me to it.

[Bug target/61827] New: gcc.target/i386/fuse-caller-save-xmm.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 61827
   Summary: gcc.target/i386/fuse-caller-save-xmm.c FAILs
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Host: i386-pc-solaris2.11, x86_64-unknown-linux-gnu
Target: i386-pc-solaris2.11, x86_64-unknown-linux-gnu
 Build: i386-pc-solaris2.11, x86_64-unknown-linux-gnu

The new gcc.target/i386/fuse-caller-save-xmm.c testcase FAILs in various
different ways on different targets:

* On Solaris 11/x86 with Sun as, there can be no cfi directives since that
  assembler doesn't fully support them yet:

FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times
.cfi_def_cfa_offset 16 1
FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times
.cfi_def_cfa_offset 32 1

  for both 32 and 64-bit.

* On Solaris 11/x86 with gas, I see the same failures although cfi directives
  are used.

* On Linux/x86_64, I see
FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times
.cfi_def_cfa_offset 32 1

  for 32-bit only.  In the 32-bit .s file, I find

.cfi_def_cfa_offset 16
.cfi_def_cfa_offset 4

  compared to 64-bit

.cfi_def_cfa_offset 16
.cfi_def_cfa_offset 8
.cfi_def_cfa_offset 32
.cfi_def_cfa_offset 8


  Rainer

[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug middle-end/61828] New: gcc.dg/strlenopt-8.c XPASSes

[ro at gcc dot gnu.org]

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

Bug ID: 61828
   Summary: gcc.dg/strlenopt-8.c XPASSes
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
 Build: sparc-sun-solaris2.11

Between 20140711 and 20140716, gcc.dg/strlenopt-8.c started to XPASS on
Solaris/SPARC
due to this patch:

2014-07-11  Richard Biener  

PR middle-end/61473
* gcc.dg/memmove-4.c: New testcase.
* gcc.dg/strlenopt-8.c: XFAIL.

  Rainer

[Bug middle-end/61828] gcc.dg/strlenopt-8.c XPASSes

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug target/61827] gcc.target/i386/fuse-caller-save-xmm.c FAILs

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.11,|i386-pc-solaris2.11,
   |x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu,
   ||*-*-darwin*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-07-17
 CC||iains at gcc dot gnu.org
   Host|i386-pc-solaris2.11,|i386-pc-solaris2.11,
   |x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu,
   ||*-*-darwin*
 Ever confirmed|0   |1
  Build|i386-pc-solaris2.11,|i386-pc-solaris2.11,
   |x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu,
   ||*-*-darwin*

--- Comment #1 from Dominique d'Humieres  ---
Also fails on *-*-darwin* for the same reason as Solaris 11/x86 with Sun as:
cfi directives not supported.

[Bug tree-optimization/61829] New: SEGV in fold_binary_loc for gcc.dg/graphite/isl-codegen-loop-dumping.c

[ro at gcc dot gnu.org]

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

Bug ID: 61829
   Summary: SEGV in fold_binary_loc for
gcc.dg/graphite/isl-codegen-loop-dumping.c
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: romangareev at gcc dot gnu.org
  Host: i386-pc-solaris2.11, sparc-sun-solaris2.11
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11
 Build: i386-pc-solaris2.11, sparc-sun-solaris2.11

Between 20140711 (r212451) and 20140716 (r212663), the
gcc.dg/graphite/isl-codegen-loop-dumping.c testcase started to FAIL (32-bit
only) on Solaris/x86 and SPARC:

FAIL: gcc.dg/graphite/isl-codegen-loop-dumping.c (internal compiler error)
FAIL: gcc.dg/graphite/isl-codegen-loop-dumping.c (test for excess errors)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x084af7eb in fold_binary_loc (loc=0, code=MINUS_EXPR, type=0x0, 
op0=0xfac63528, op1=0xfac0458c)
at /vol/gcc/src/hg/trunk/local/gcc/fold-const.c:10814
10814 && !TYPE_OVERFLOW_TRAPS (type))
(gdb) where
#0  0x084af7eb in fold_binary_loc (loc=0, code=MINUS_EXPR, type=0x0, 
op0=0xfac63528, op1=0xfac0458c)
at /vol/gcc/src/hg/trunk/local/gcc/fold-const.c:10814
#1  0x084d3450 in fold_build2_stat_loc (loc=0, code=MINUS_EXPR, type=0x0, 
op0=0xfac63528, op1=0xfac0458c)
at /vol/gcc/src/hg/trunk/local/gcc/fold-const.c:14988
#2  0x08bea952 in binary_op_to_tree (ip=..., expr=0x953a328, type=0x0)
at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:175
#3  gcc_expression_from_isl_expr_op (ip=..., expr=0x953a328, type=0x0)
at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:317
#4  gcc_expression_from_isl_expression (type=0x0, expr=0x953a328, ip=...)
at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:348
#5  0x08bea766 in binary_op_to_tree (ip=..., expr=0x9517968, type=0x0)
at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:164
#6  gcc_expression_from_isl_expr_op (ip=..., expr=0x9517968, type=0x0)
at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:317
#7  gcc_expression_from_isl_expression (type=0x0, expr=0x9517968, ip=...)
at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:348
#8  0x08beac55 in graphite_create_new_loop_guard (ip=..., 
ub=, lb=, type=, 
node_for=0x949e178, entry_edge=0xfac63f00)
at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:501
#9  translate_isl_ast_node_for (ip=..., next_e=0xfac63f00, node=0x949e178, 
context_loop=0xfac0e6b4)
at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:536
#10 translate_isl_ast (context_loop=0xfac0e6b4, node=0x949e178, 
next_e=0xfac63f00, ip=...)
at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:558
#11 0x08beb246 in graphite_regenerate_ast_isl (scop=0x9513840)
at /vol/gcc/src/hg/trunk/local/gcc/graphite-isl-ast-to-gimple.c:699
#12 0x08be65aa in graphite_transform_loops ()
at /vol/gcc/src/hg/trunk/local/gcc/graphite.c:304
#13 0x08be6632 in graphite_transforms (fun=0xfacb2000)
at /vol/gcc/src/hg/trunk/local/gcc/graphite.c:333
#14 (anonymous namespace)::pass_graphite_transforms::execute (this=0x94a24b0, 
fun=0xfacb2000) at /vol/gcc/src/hg/trunk/local/gcc/graphite.c:413
#15 0x0864c2e0 in execute_one_pass (pass=0x94a24b0)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2149
#16 0x0864c85f in execute_pass_list_1 (pass=0x94a24b0)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2201
#17 0x0864c872 in execute_pass_list_1 (pass=0x94a2468)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2202
#18 0x0864c872 in execute_pass_list_1 (pass=0x94a2150)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2202
#19 0x0864c872 in execute_pass_list_1 (pass=0x94a14f0, pass@entry=0x94a1460)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2202
#20 0x0864c8bb in execute_pass_list (fn=0xfacb2000, pass=0x94a1460)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2212
#21 0x083c8c97 in expand_function (node=node@entry=0xfac071a8)
at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1786
#22 0x083cae98 in expand_all_functions ()
at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1920
#23 compile () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2264
#24 0x083cb56b in finalize_compilation_unit ()
at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2341
#25 0x0828f24b in c_write_global_declarations ()
at /vol/gcc/src/hg/trunk/local/gcc/c/c-decl.c:10463
#26 0x087028e5 in compile_file ()
at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:562
#27 0x08704bec in do_compile ()
at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1946
#28 toplev_main (argc=19, argv=0xfeffe398)
at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2022
#29 0x0

[Bug tree-optimization/61829] SEGV in fold_binary_loc for gcc.dg/graphite/isl-codegen-loop-dumping.c

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug fortran/61830] New: Memory leak with assignment to array of derived types with allocatable components

[sfilippone at uniroma2 dot it]

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

Bug ID: 61830
   Summary: Memory leak with assignment to array of derived types
with allocatable components
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sfilippone at uniroma2 dot it

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

Hi,
The attached code shows the problem. 
When I started investigating I was using 4.10 but I ran into PR61819 while
reducing the test case. 

With 4.8.3 I get the following:

[sfilippo@jacobi runs]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu/4.8.3/libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.3/configure --prefix=/usr/local/gnu/4.8.3
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp
--with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc
Thread model: posix
gcc version 4.8.3 (GCC) 
[sfilippo@jacobi runs]$ valgrind --leak-check=full ./foo-test-leak 
==20638== Memcheck, a memory error detector
==20638== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==20638== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==20638== Command: ./foo-test-leak
==20638== 
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
==20638== 
==20638== HEAP SUMMARY:
==20638== in use at exit: 6,164 bytes in 23 blocks
==20638==   total heap usage: 89 allocs, 66 frees, 35,518 bytes allocated
==20638== 
==20638== 560 (48 direct, 512 indirect) bytes in 1 blocks are definitely lost
in loss record 3 of 5
==20638==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==20638==by 0x400B70: __foo_base_mod_MOD_foo_geall (foo-test-leak.f90:96)
==20638==by 0x401F8B: __foo_scalar_field_mod_MOD_new_scalar_field
(foo-test-leak.f90:141)
==20638==by 0x40271F: __foo_vector_field_mod_MOD_new_vector_field
(foo-test-leak.f90:163)
==20638==by 0x402AC8: MAIN__ (foo-test-leak.f90:188)
==20638==by 0x4031D3: main (foo-test-leak.f90:179)
==20638== 
==20638== 5,600 (480 direct, 5,120 indirect) bytes in 10 blocks are definitely
lost in loss record 5 of 5
==20638==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==20638==by 0x400B70: __foo_base_mod_MOD_foo_geall (foo-test-leak.f90:96)
==20638==by 0x401F8B: __foo_scalar_field_mod_MOD_new_scalar_field
(foo-test-leak.f90:141)
==20638==by 0x40271F: __foo_vector_field_mod_MOD_new_vector_field
(foo-test-leak.f90:163)
==20638==by 0x402C9E: MAIN__ (foo-test-leak.f90:192)
==20638==by 0x4031D3: main (foo-test-leak.f90:179)
==20638== 
==20638== LEAK SUMMARY:
==20638==definitely lost: 528 bytes in 11 blocks
==20638==indirectly lost: 5,632 bytes in 11 blocks
==20638==  possibly lost: 0 bytes in 0 blocks
==20638==still reachable: 4 bytes in 1 blocks
==20638== suppressed: 0 bytes in 0 blocks
==20638== Reachable blocks (those to which a pointer was found) are not shown.
==20638== To see them, rerun with: --leak-check=full --show-reachable=yes
==20638== 
==20638== For counts of detected and suppressed errors, rerun with: -v
==20638== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)
---

If I change line 163 
this%u = [new_scalar_field()]

into
do i=1, size(this%u)
  associate(sf=>this%u(i))
sf = new_scalar_field()
  end associate
end do

then I get no leak

[sfilippo@jacobi runs]$ valgrind --leak-check=full ./foo-test-leak-fixed
==20852== Memcheck, a memory error detector
==20852== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==20852== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==20852== Command: ./foo-test-leak-fixed
==20852== 
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() component
 Scalar deallocation
 Deallocate class() comp

[Bug fortran/61830] Memory leak with assignment to array of derived types with allocatable components

[sfilippone at uniroma2 dot it]

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

--- Comment #1 from Salvatore Filippone  ---
Created attachment 33133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33133&action=edit
workaround

[Bug tree-optimization/61829] SEGV in fold_binary_loc for gcc.dg/graphite/isl-codegen-loop-dumping.c

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-07-17
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00902.html.

[Bug fortran/61830] Memory leak with assignment to array of derived types with allocatable components

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-07-17
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
The following PRs give an ICE at the same place: pr54784, pr59765, pr60529, and
pr61766.

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
Note that the original test of pr54784 now gives the same ICE and the change of
behavior is in the range given in comment 6.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ebotcazou at gcc dot gnu.org]

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

--- Comment #51 from Eric Botcazou  ---
> Ah, we also expand one from a TARGET_MEM_REF:
> 
> ;;   basic block 76, loop depth 2
> ;;pred:   79
>   load_dst_215 = MEM[base: ptr_110, offset: 0B];
> 
> and TARGET_MEM_REF only handles the movmisalign case.  So it's either IVOPTs
> not punting properly here (it does for unaligned accesses - grep for
> STRICT_ALIGNMENT) or we need to put a bitfield extraction case into
> TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too much
> pessimized by not considering this).

TARGET_MEM_REF is supposed to be a valid memory access for the target though
and, by definition, an unaligned access is not valid for a strict alignment
target (unless you have a movmisalign pattern), so the problem is the
TARGET_MEM_REF.

If you want to make IVOPTS generate unaligned TARGET_MEM_REFs, you'll need to
make sure that the costs are properly adjusted and benchmark the result.

[Bug fortran/61831] New: [4.9.1 regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

Bug ID: 61831
   Summary: [4.9.1 regression] runtime error: pointer being freed
was not allocated
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de

Our code, WHIZARD 2.2.2, crashes in its self test smtest_5 with the following
runtime error:
whizard(46878) malloc: *** error for object 0x7faf83d7e270: pointer being freed
was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x1102fb0b2
#1  0x1102fb86e
#2  0x7fff8a300cf9
Abort trap: 6

Our code can be found here: 
http://www.hepforge.org/archive/whizard/whizard-2.2.2.tar.gz
It can be configured with
./configure --disable-ocaml --prefix=
then just do make, make install and run the code as
./whizard smtest_5.sin from the share/tests folder.

We try to isolate the problem, but are not confident to manage to do that in a
certain amount of time.

[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de
   Severity|normal  |critical

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thopre01 at gcc dot gnu.org]

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

--- Comment #52 from thopre01 at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #51)
> 
> TARGET_MEM_REF is supposed to be a valid memory access for the target though
> and, by definition, an unaligned access is not valid for a strict alignment
> target (unless you have a movmisalign pattern), so the problem is the
> TARGET_MEM_REF.

So we just need to identify what changes the MEM_REF that bswap introduce into
a TARGET_MEM_REF without taking alignment into account.

After bswap it's only a MEM_REF:

load_dst_215 = MEM[(unsigned char *)load_src_277];

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thopre01 at gcc dot gnu.org]

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

--- Comment #53 from thopre01 at gcc dot gnu.org ---
(In reply to thopre01 from comment #52)
> (In reply to Eric Botcazou from comment #51)
> > 
> > TARGET_MEM_REF is supposed to be a valid memory access for the target though
> > and, by definition, an unaligned access is not valid for a strict alignment
> > target (unless you have a movmisalign pattern), so the problem is the
> > TARGET_MEM_REF.
> 
> So we just need to identify what changes the MEM_REF that bswap introduce
> into a TARGET_MEM_REF without taking alignment into account.
> 
> After bswap it's only a MEM_REF:
> 
> load_dst_215 = MEM[(unsigned char *)load_src_277];

So it changes from a MEM_REF to a TARGET_MEM_REF in ivopts from a quick grep. I
don't know how much this system but I can take a look after Cauldron where does
this happen and bring the right person into this discussion.

[Bug c++/50961] Fails to decay template function properly(?)

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jul 17 16:22:19 2014
New Revision: 212760

URL: https://gcc.gnu.org/viewcvs?rev=212760&root=gcc&view=rev
Log:
/cp
2014-07-17  Paolo Carlini  

PR c++/50961
* call.c (standard_conversion): Use resolve_nondeduced_context
for type_unknown_p (EXPR) && TREE_CODE (TO) == BOOLEAN_TYPE.

/testsuite
2014-07-17  Paolo Carlini  

PR c++/50961
* g++.dg/template/operator13.C: New.

Added:
trunk/gcc/testsuite/g++.dg/template/operator13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/50961] Fails to decay template function properly(?)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |4.10.0

--- Comment #4 from Paolo Carlini  ---
Fixed for 4.10.

[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Severity|critical|normal

--- Comment #1 from kargl at gcc dot gnu.org ---
Can you rebuild your code with compile with the -fcheck=all option?

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||damian at sourceryinstitute 
dot or
   ||g

--- Comment #10 from Dominique d'Humieres  ---
> Likely r206379 (pr59589).

If I partially revert r206379, the ICEs for pr54784, pr59765, pr60529, pr61766,
pr61819, and pr61822 are gone. Indeed the memory leak for pr59589 reappears and
I get an ICE at trans-array.c:146 for the test in comment 1 of pr56385
(gfortran.dg/proc_ptr_comp_37.f90), but not in the original test.

--- ../_clean/gcc/fortran/class.c2014-05-07 12:46:43.0 +0200
+++ gcc/fortran/class.c2014-07-17 18:01:17.0 +0200
@@ -833,7 +833,20 @@ finalize_component (gfc_expr *expr, gfc_
   gfc_expr *e;
   gfc_ref *ref;

-  if (!comp_is_finalizable (comp))
+/*  if (!comp_is_finalizable (comp)) */
+  if (comp->ts.type != BT_DERIVED && comp->ts.type != BT_CLASS
+  && !comp->attr.allocatable)
+return;
+
+  if ((comp->ts.type == BT_DERIVED && comp->attr.pointer)
+  || (comp->ts.type == BT_CLASS && CLASS_DATA (comp)
+  && CLASS_DATA (comp)->attr.pointer))
+return;
+
+  if (comp->ts.type == BT_DERIVED && !comp->attr.allocatable
+  && (comp->ts.u.derived->f2k_derived == NULL
+  || comp->ts.u.derived->f2k_derived->finalizers == NULL)
+  && !has_finalizer_component (comp->ts.u.derived))
 return;

   e = gfc_copy_expr (expr);

Note the ICEs reappear if I apply on top of the above the patch in comment 13
of pr59589.

Could people familiar with finalization compare the tests in the above PRs and
try to infer why comp->ts.u.derived->attr.alloc_comp changes the compiler
behavior.

[Bug fortran/60529] [4.9/4.10 Regression] [OOP] ICE with allocatable sub-component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #5 from Dominique d'Humieres  ---
Per pr61819, duplicate of pr 59765.

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

[Bug fortran/59765] [4.9/4.10 Regression] [OOP] ICE on valid with finalizable array components

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||carlos.a.cruz at nasa dot gov

--- Comment #8 from Dominique d'Humieres  ---
*** Bug 60529 has been marked as a duplicate of this bug. ***

[Bug fortran/61766] [4.9/4.10 regression] ICE on trans-array.c

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
Per pr61819, duplicate of pr 59765.

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

[Bug fortran/59765] [4.9/4.10 Regression] [OOP] ICE on valid with finalizable array components

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #9 from Dominique d'Humieres  ---
*** Bug 61766 has been marked as a duplicate of this bug. ***

[Bug preprocessor/61832] New: r212638 breaks building ncurses

[ktkachov at gcc dot gnu.org]

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

Bug ID: 61832
   Summary: r212638 breaks building ncurses
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org

As of 212638:

gcc/c-family/ChangeLog:
* c-ppoutput.c (struct print::prev_was_system_token): New data
member.
(init_pp_output): Initialize it.
(maybe_print_line_1, maybe_print_line, print_line_1, print_line)
(do_line_change): Return a flag saying if a line marker was
emitted or not.
(scan_translation_unit): Detect if the system-ness of the token we
are about to emit is different from the one of the previously
emitted token.  If so, emit a line marker.  Avoid emitting useless
adjacent line markers.  Avoid emitting line markers for tokens
originating from the expansion of built-in macros.
(scan_translation_unit_directives_only): Adjust.

by dodji

gcc fails to build ncurses. Basically the preprocessor ends up generating
invalid C-code.

I'll try to reduce a testcase soon, but in the meantime this appears on x86,
arm and aarch64 so should be easily reproducible

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #11 from Dominique d'Humieres  ---
See comment 4 of pr59765 for the origin of the problem.

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

[Bug fortran/59765] [4.9/4.10 Regression] [OOP] ICE on valid with finalizable array components

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||sfilippone at uniroma2 dot it

--- Comment #10 from Dominique d'Humieres  ---
*** Bug 61819 has been marked as a duplicate of this bug. ***

[Bug c++/61833] New: [4.9] ICE in fold_comparison

[ppluzhnikov at google dot com]

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

Bug ID: 61833
   Summary: [4.9] ICE in fold_comparison
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

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

Google ref: b/16030670

Originally reported against gcc-4.8.

Attached test case causes gcc-4_9-branch (r212536) to ICE like this (but only
with -O2):

gcc-svn-4_9-r212536/bin/g++ -c -std=c++11 t.ii -O2
t.ii: In function ‘void ToSpec()’:
t.ii:158:1: internal compiler error: Segmentation fault
 ToSpec ()
 ^
0xb947ff crash_signal
../../gcc/toplev.c:337
0x952096 fold_comparison
../../gcc/fold-const.c:9074
0x95b8a7 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12953
0xbca30d cleanup_control_expr_graph
../../gcc/tree-cfgcleanup.c:112
0xbca30d cleanup_control_flow_bb
../../gcc/tree-cfgcleanup.c:187
0xbca30d cleanup_tree_cfg_bb
../../gcc/tree-cfgcleanup.c:630
0xbcbd48 cleanup_tree_cfg_1
../../gcc/tree-cfgcleanup.c:675
0xbcbd48 cleanup_tree_cfg_noloop
../../gcc/tree-cfgcleanup.c:731
0xbcbd48 cleanup_tree_cfg()
../../gcc/tree-cfgcleanup.c:786
0xaea194 execute_function_todo
../../gcc/passes.c:1811
0xaeaa83 execute_todo
../../gcc/passes.c:1887
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

Trunk rejects the reduced test case with "definition of std::initializer_list
does not match #include " due to fixes for PR61723.

Trunk @r212277 does not ICE.

[Bug c++/61723] [C++11] ICE in contains_struct_check

[ppluzhnikov at google dot com]

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

--- Comment #8 from Paul Pluzhnikov  ---
Filed PR61833

[Bug c++/61834] New: __attribute__((may_alias)) causes compilation error with forward-declared constructor

[lopresti at gmail dot com]

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

Bug ID: 61834
   Summary: __attribute__((may_alias)) causes compilation error
with forward-declared constructor
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lopresti at gmail dot com

Created attachment 33135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33135&action=edit
Source file demonstrating bug with may_alias

If you compile the attached stand-alone test case with:

  g++ -S may_alias_bug.cc

...it compiles fine.

If you compile with:

  g++ -DBUG -S may_alias_bug.cc

...it produces a compilation error:

  may_alias_bug2.cc:16:8: error: prototype for ‘Thing1::Thing1(Thing2)’ does
not match any in class ‘Thing1’



This bug appears to exist at least as far back as GCC 4.4.7. The code compiles
fine with Clang and with the Intel C++ compiler, as you can see by
experimenting here: http://goo.gl/dDyljx

[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

--- Comment #2 from Jürgen Reuter  ---
(In reply to kargl from comment #1)
> Can you rebuild your code with compile with the -fcheck=all option?

I did. This does not change anything. And it does not give any further
information.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenther at suse dot de]

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

--- Comment #54 from rguenther at suse dot de  ---
On July 17, 2014 5:50:44 PM CEST, "ebotcazou at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
>
>--- Comment #51 from Eric Botcazou  ---
>> Ah, we also expand one from a TARGET_MEM_REF:
>> 
>> ;;   basic block 76, loop depth 2
>> ;;pred:   79
>>   load_dst_215 = MEM[base: ptr_110, offset: 0B];
>> 
>> and TARGET_MEM_REF only handles the movmisalign case.  So it's either
>IVOPTs
>> not punting properly here (it does for unaligned accesses - grep for
>> STRICT_ALIGNMENT) or we need to put a bitfield extraction case into
>> TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too
>much
>> pessimized by not considering this).
>
>TARGET_MEM_REF is supposed to be a valid memory access for the target
>though
>and, by definition, an unaligned access is not valid for a strict
>alignment
>target (unless you have a movmisalign pattern), so the problem is the
>TARGET_MEM_REF.

Ivopts does not change the memory addresses, so even when not using a
target_men_ref the access will be unaligned. It's only that we had no way of
specifying whether an access is unaligned or not.  The addressing mode costs
may not reflect reality though.

Richard.
>
>If you want to make IVOPTS generate unaligned TARGET_MEM_REFs, you'll
>need to
>make sure that the costs are properly adjusted and benchmark the
>result.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenther at suse dot de]

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

--- Comment #55 from rguenther at suse dot de  ---
On July 17, 2014 6:13:14 PM CEST, "thopre01 at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
>
>--- Comment #53 from thopre01 at gcc dot gnu.org ---
>(In reply to thopre01 from comment #52)
>> (In reply to Eric Botcazou from comment #51)
>> > 
>> > TARGET_MEM_REF is supposed to be a valid memory access for the
>target though
>> > and, by definition, an unaligned access is not valid for a strict
>alignment
>> > target (unless you have a movmisalign pattern), so the problem is
>the
>> > TARGET_MEM_REF.
>> 
>> So we just need to identify what changes the MEM_REF that bswap
>introduce
>> into a TARGET_MEM_REF without taking alignment into account.
>> 
>> After bswap it's only a MEM_REF:
>> 
>> load_dst_215 = MEM[(unsigned char *)load_src_277];
>
>So it changes from a MEM_REF to a TARGET_MEM_REF in ivopts from a quick
>grep. I
>don't know how much this system but I can take a look after Cauldron
>where does
>this happen and bring the right person into this discussion.

You need to fix may_be_unaligned (or similar) in ivopts.

[Bug libstdc++/61835] New: Invalid comment on pretty printers breaks gdb

[mariano.bessone at tallertechnologies dot com]

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

Bug ID: 61835
   Summary: Invalid comment on pretty printers breaks gdb
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mariano.bessone at tallertechnologies dot com

Created attachment 33136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33136&action=edit
Workaround

Running gdb with latest pretty printers causes:

Traceback (most recent call last):
  File "", line 3, in 
  File "/data/utils/prettyprinters/libstdcxx/v6/printers.py", line 1056
"""
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in
position 194-195: malformed \N character escape
/home/marjobe/.gdbinit:6: Error in sourced command file:
Error while executing Python code.

The problem is that a comment contains an escape sequence. See workaround in
the attached patch.

[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-07-17
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed with 4.9.1 revision r212339. AFAICT revision r210749 is OK. I suspect
r211405 for 4.10 and r212329 for 4.9. Can you revert r212329 and see if the
error disappear?

In any case a reduced test will help a lot.

[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Thu, Jul 17, 2014 at 07:14:19PM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
> 
> --- Comment #2 from J??rgen Reuter  ---
> > Can you rebuild your code with compile with the -fcheck=all option?
> 
> I did. This does not change anything. And it does not give any further
> information.
> 

Thanks.  Unfortunately, I cannot get the code to build.  Without a 
reduced testcase, this is going to be difficult for someone to
debug.

[Bug c++/61836] New: Incorrect template argument deduction/substitution failure?

[ilja.j.honkonen at nasa dot gov]

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

Bug ID: 61836
   Summary: Incorrect template argument deduction/substitution
failure?
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ilja.j.honkonen at nasa dot gov

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

Trying to enable_if a particular implementation of a class member function
based on its template argument:

template<
class Out_T
> typename std::enable_if<
std::is_same::value,
Out_T
>::type get_parsed_value(...)

template<
class Out_T
> typename std::enable_if<
std::is_same::value,
Out_T
>::type get_parsed_value(...)


including std::array and Eigen::Matrix:

template struct is_std_array_double : std::false_type {};
template struct is_std_array_double<
std::array
> : std::true_type {};


template struct is_eigen_vector_double : std::false_type {};
template struct is_eigen_vector_double<
Eigen::Matrix
> : std::true_type {};


template<
class Out_T
> typename std::enable_if<
detail::is_std_array_double::value,
Out_T
>::type get_parsed_value(...)

template<
class Out_T
> typename std::enable_if<
detail::is_eigen_vector_double::value,
Out_T
>::type get_parsed_value(...)


fails because apparently is_eigen_vector_double returns false for
Eigen::Matrix even though it shouldn't. The same code compiles
with clangs 3.3-5.


Compile command:
/opt/local/gcc-4.9.1/bin/g++ -I source -std=c++11 -W -Wall -Wextra -pedantic
-O3  -I /opt/local/include/eigen3 -I /opt/local/include -L /opt/local/lib
-lboost_coroutine-mt -lboost_system-mt -lboost_random-mt
-lboost_program_options-mt -I /Users/iljah/include -L /Users/iljah/lib
-lmuparserx -I /Users/iljah/include
tests/program_options/variable_to_option.cpp -o
tests/program_options/variable_to_option.exe -Wno-unused-local-typedefs
-save-temps -v


Output:
Using built-in specs.
COLLECT_GCC=/opt/local/gcc-4.9.1/bin/g++
COLLECT_LTO_WRAPPER=/opt/local/gcc-4.9.1/libexec/gcc/x86_64-apple-darwin13.3.0/4.9.1/lto-wrapper
Target: x86_64-apple-darwin13.3.0
Configured with: ../gcc-4.9.1/configure --prefix=/opt/local/gcc-4.9.1
--enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-multilib
--with-system-zlib --enable-languages=c,c++ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --disable-bootstrap
Thread model: posix
gcc version 4.9.1 (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.3' '-I' 'source' '-std=c++11'
'-Wall' '-Wextra' '-Wpedantic' '-O3' '-I' '/opt/local/include/eigen3' '-I'
'/opt/local/include' '-L/opt/local/lib' '-I' '/Users/iljah/include'
'-L/Users/iljah/lib' '-I' '/Users/iljah/include' '-o'
'tests/program_options/variable_to_option.exe' '-Wno-unused-local-typedefs'
'-save-temps' '-v' '-shared-libgcc' '-mtune=core2'
 /opt/local/gcc-4.9.1/libexec/gcc/x86_64-apple-darwin13.3.0/4.9.1/cc1plus -E
-quiet -v -I source -I /opt/local/include/eigen3 -I /opt/local/include -I
/Users/iljah/include -I /Users/iljah/include -D__DYNAMIC__
tests/program_options/variable_to_option.cpp -fPIC -mmacosx-version-min=10.9.3
-mtune=core2 -std=c++11 -Wall -Wextra -Wpedantic -Wno-unused-local-typedefs -O3
-fpch-preprocess -o variable_to_option.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/../../../../x86_64-apple-darwin13.3.0/include"
ignoring duplicate directory "/Users/iljah/include"
#include "..." search starts here:
#include <...> search starts here:
 source
 /opt/local/include/eigen3
 /opt/local/include
 /Users/iljah/include

/opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/../../../../include/c++/4.9.1

/opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/../../../../include/c++/4.9.1/x86_64-apple-darwin13.3.0

/opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/../../../../include/c++/4.9.1/backward
 /opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/include
 /opt/local/gcc-4.9.1/include
 /opt/local/gcc-4.9.1/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.3' '-I' 'source' '-std=c++11'
'-Wall' '-Wextra' '-Wpedantic' '-O3' '-I' '/opt/local/include/eigen3' '-I'
'/opt/local/include' '-L/opt/local/lib' '-I' '/Users/iljah/include'
'-L/Users/iljah/lib' '-I' '/Users/iljah/include' '-o'
'tests/program_options/variable_to_option.exe' '-Wno-unused-local-typedefs'
'-save-temps' '-v' '-shared-libgcc' '-mtune=core2'
 /opt/local/gcc-4.9.1/libexec/gcc/x86_64-apple-darwin13.3.0/4.9.1/cc1plus
-fpreprocessed variable_to_option.ii -fPIC -quiet -dumpbase
variable_to_option.cpp -mmacosx-version-min=10.9.3 

[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> Confirmed with 4.9.1 revision r212339. AFAICT revision r210749 is OK.
> I suspect r211405 for 4.10 and r212329 for 4.9. Can you revert r212329
> and see if the error disappear?

I am afraid that I am the culprit, i.e., r212329: I get the error with r209838
+ the patch in r212329. However the failures are not exactly the same:
with 4.9.1 revision r212339, it is

| Creating decay process library for particle W+
| Process library 'default_lib_dp24': initialized
| decay_p24_1: W+ => dbar u
| Process library 'default_lib_dp24': recorded process 'decay_p24_1'
| decay_p24_2: ?O => sbar c
| Process library 'default_lib_dp24': recorded process 'decay_p24_2'
| decay_p24_3:  => e+ nue
whizard(32872,0x7fff7738d310) malloc: *** error for object 0x7f805874ea60:
pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

while with r209838 + patch, it is

| Creating decay process library for particle W+
| Process library 'default_lib_dp24': initialized
| decay_p24_1: W+ => dbar u
| Process library 'default_lib_dp24': recorded process 'decay_p24_1'
| decay_p24_2:  => sbar c
| Process library 'default_lib_dp24': recorded process 'decay_p24_2'
whizard(36947,0x7fff7738d310) malloc: *** error for object 0x7fb8c3755810:
pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

For 4.9.0, I get

| Creating decay process library for particle W+
| Process library 'default_lib_dp24': initialized
| decay_p24_1: W+ => dbar u
| Process library 'default_lib_dp24': recorded process 'decay_p24_1'
| decay_p24_2: W+ => sbar c
| Process library 'default_lib_dp24': recorded process 'decay_p24_2'
| decay_p24_3: W+ => e+ nue
| Process library 'default_lib_dp24': recorded process 'decay_p24_3'
| decay_p24_4: W+ => mu+ numu
| Process library 'default_lib_dp24': recorded process 'decay_p24_4'
| decay_p24_5: W+ => tau+ nutau
| Process library 'default_lib_dp24': recorded process 'decay_p24_5'
| Integrate: current process library needs compilation
| Process library 'default_lib_dp24': compiling ...
| Process library 'default_lib_dp24': writing makefile
| Process library 'default_lib_dp24': writing driver
| Process library 'default_lib_dp24': creating source code
rm -f decay_p24_1_i1.f90
rm -f opr_decay_p24_1_i1.mod
rm -f decay_p24_1_i1.lo
rm -f decay_p24_2_i1.f90
rm -f opr_decay_p24_2_i1.mod
rm -f decay_p24_2_i1.lo
rm -f decay_p24_3_i1.f90
rm -f opr_decay_p24_3_i1.mod
rm -f decay_p24_3_i1.lo
rm -f decay_p24_4_i1.f90
rm -f opr_decay_p24_4_i1.mod
rm -f decay_p24_4_i1.lo
rm -f decay_p24_5_i1.f90
rm -f opr_decay_p24_5_i1.mod
rm -f decay_p24_5_i1.lo
/usr/local/bin/omega_SM.opt -o decay_p24_1_i1.f90 -target:whizard
-target:parameter_module parameters_SM -target:module opr_decay_p24_1_i1
-target:md5sum 'B42EAF21C73773800B93C9AE1495DD00' -fusion:progress -decay 'W+
-> dbar u' 
make: /usr/local/bin/omega_SM.opt: Command not found
make: *** [decay_p24_1_i1.f90] Error 127
| command: make source -j1 -f default_lib_dp24.makefile
| Return code = 512
**
**
*** FATAL ERROR: System command returned with nonzero status code
**
**
WHIZARD run aborted.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||4.9.0
Version|unknown |4.9.1
Summary|[4.9.1 regression] runtime  |[4.9/ 4.10 Regression]
   |error: pointer being freed  |runtime error: pointer
   |was not allocated   |being freed was not
   ||allocated
  Known to fail||4.10.0, 4.9.1

--- Comment #6 from Dominique d'Humieres  ---
Marked as 4.9/4.10 regression.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

--- Comment #7 from Jürgen Reuter  ---
(In reply to Dominique d'Humieres from comment #5)
> > Confirmed with 4.9.1 revision r212339. AFAICT revision r210749 is OK.
> > I suspect r211405 for 4.10 and r212329 for 4.9. Can you revert r212329
> > and see if the error disappear?
> 
> I am afraid that I am the culprit, i.e., r212329: I get the error with
> r209838 + the patch in r212329. However the failures are not exactly the
> same:
> with 4.9.1 revision r212339, it is
> 
> | Creating decay process library for particle W+
> | Process library 'default_lib_dp24': initialized
> | decay_p24_1: W+ => dbar u
> | Process library 'default_lib_dp24': recorded process 'decay_p24_1'
> | decay_p24_2: ?O => sbar c
> | Process library 'default_lib_dp24': recorded process 'decay_p24_2'
> | decay_p24_3:  => e+ nue
> whizard(32872,0x7fff7738d310) malloc: *** error for object 0x7f805874ea60:
> pointer being freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> 
> while with r209838 + patch, it is
> 
> | Creating decay process library for particle W+
> | Process library 'default_lib_dp24': initialized
> | decay_p24_1: W+ => dbar u
> | Process library 'default_lib_dp24': recorded process 'decay_p24_1'
> | decay_p24_2:  => sbar c
> | Process library 'default_lib_dp24': recorded process 'decay_p24_2'
> whizard(36947,0x7fff7738d310) malloc: *** error for object 0x7fb8c3755810:
> pointer being freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> 
> For 4.9.0, I get
> 
> | Creating decay process library for particle W+
> | Process library 'default_lib_dp24': initialized
> | decay_p24_1: W+ => dbar u
> | Process library 'default_lib_dp24': recorded process 'decay_p24_1'
> | decay_p24_2: W+ => sbar c
> | Process library 'default_lib_dp24': recorded process 'decay_p24_2'
> | decay_p24_3: W+ => e+ nue
> | Process library 'default_lib_dp24': recorded process 'decay_p24_3'
> | decay_p24_4: W+ => mu+ numu
> | Process library 'default_lib_dp24': recorded process 'decay_p24_4'
> | decay_p24_5: W+ => tau+ nutau
> | Process library 'default_lib_dp24': recorded process 'decay_p24_5'
> | Integrate: current process library needs compilation
> | Process library 'default_lib_dp24': compiling ...
> | Process library 'default_lib_dp24': writing makefile
> | Process library 'default_lib_dp24': writing driver
> | Process library 'default_lib_dp24': creating source code
> rm -f decay_p24_1_i1.f90
> rm -f opr_decay_p24_1_i1.mod
> rm -f decay_p24_1_i1.lo
> rm -f decay_p24_2_i1.f90
> rm -f opr_decay_p24_2_i1.mod
> rm -f decay_p24_2_i1.lo
> rm -f decay_p24_3_i1.f90
> rm -f opr_decay_p24_3_i1.mod
> rm -f decay_p24_3_i1.lo
> rm -f decay_p24_4_i1.f90
> rm -f opr_decay_p24_4_i1.mod
> rm -f decay_p24_4_i1.lo
> rm -f decay_p24_5_i1.f90
> rm -f opr_decay_p24_5_i1.mod
> rm -f decay_p24_5_i1.lo
> /usr/local/bin/omega_SM.opt -o decay_p24_1_i1.f90 -target:whizard
> -target:parameter_module parameters_SM -target:module opr_decay_p24_1_i1
> -target:md5sum 'B42EAF21C73773800B93C9AE1495DD00' -fusion:progress -decay
> 'W+ -> dbar u' 
> make: /usr/local/bin/omega_SM.opt: Command not found
> make: *** [decay_p24_1_i1.f90] Error 127
> | command: make source -j1 -f default_lib_dp24.makefile
> | Return code = 512
> *
> *
> *
> *
> *** FATAL ERROR: System command returned with nonzero status code
> *
> *
> *
> *
> WHIZARD run aborted.

Great, thanks. The error you get for 4.9.0 is because the executable
omega_SM.opt is absent (this is OCaml code).

[Bug go/59432] [4.9/4.10 regression] sync/atomic FAILs on Solaris/x86

[ian at airs dot com]

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

--- Comment #6 from Ian Lance Taylor  ---
Re: comment #5.  This bug report is about Solaris/x86 and is specific to
Solaris.  If you want to report a bug on any other target, please open a
different bug.  Thanks.

In your case I suspect you need to use the configure option
--with-arch-32=i686.

[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate

[xinliangli at gmail dot com]

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

davidxl  changed:

   What|Removed |Added

 CC||xinliangli at gmail dot com

--- Comment #3 from davidxl  ---
In tree-profiling (), in the intrumentation loop (for each def function) -- a
pending list of functions calling pure functions should be recorded.

After the loop that reset the const/pure flags, a loop should iterate though
the pending list, and perform cfg fixup on them.

David


(In reply to Richard Biener from comment #1)
> There are several possibilities:
> 
>  - don't instrument pure/const functions
>  - do not reset the pure/const flag (I see no reason to - the compiler might
>not insert side-effects and we can consider the counter updates as
>non-side-effect)
> 
> That is, I wonder why we do
> 
>   /* Drop pure/const flags from instrumented functions.  */
>   FOR_EACH_DEFINED_FUNCTION (node)
> {
>   if (!gimple_has_body_p (node->decl)
>   || !(!node->clone_of
>   || node->decl != node->clone_of->decl))
> continue;
> 
>   /* Don't profile functions produced for builtin stuff.  */
>   if (DECL_SOURCE_LOCATION (node->decl) == BUILTINS_LOCATION)
> continue;
> 
>   cgraph_set_const_flag (node, false, false);
>   cgraph_set_pure_flag (node, false, false);
> }
> 
> but don't then call execute_fixup_cfg () again (but it doesn't yet deal
> with a const/pure function becoming non-pure/const and thus a bb-ending
> stmt).
> 
> Btw, this is yet another case where transitioning to call flags instead
> of decl flags would save us - definitely even the instrumented call cannot
> return abnormally.
> 
> Dropping the clearing of const/pure fixes the bug.  Honza?  I only can think
> of the case where we have
> 
>   for (..)
>{
>  const ();
>  const ();
>}
> 
> and inline only one of the calls where after that loop store-motion might
> apply store-motion to the counter updates of the inline clone, overwriting
> the updates from the non-inline call.  But do we really care?
> 
> Anyway, confirmed.  Btw, goo() should be leaf but it seems we don't
> auto-compute 'leaf' yet?

[Bug c++/61825] [4.10 regression] g++.dg/cpp0x/static_assert9.C FAILs

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.11,|i386-pc-solaris2.11,
   |sparc-sun-solaris2.11,  |sparc-sun-solaris2.11,
   |x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu,
   ||cris-elf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-07-17
 CC||hp at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Hans-Peter Nilsson  ---
cris-elf too, appearing in the svn revision interval (212498:212499].
I think I noticed some traffic and perhaps a patch go by but maybe that
stalled; it's still there at r212759.

[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate

[wmi at google dot com]

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

--- Comment #4 from wmi at google dot com ---
Can we move the pure/const resetting loop to an earlier place: inside
branch_prob , after instrument_edges and before gsi_commit_edge_inserts (where
stmt_ends_bb_p  is checked), so that gsi_commit_edge_inserts() which changes
cfg could take reset const/pure flags into consideration?

[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate

[xinliangli at gmail dot com]

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

--- Comment #5 from davidxl  ---
(In reply to wmi from comment #4)
> Can we move the pure/const resetting loop to an earlier place: inside
> branch_prob , after instrument_edges and before gsi_commit_edge_inserts
> (where stmt_ends_bb_p  is checked), so that gsi_commit_edge_inserts() which
> changes cfg could take reset const/pure flags into consideration?

Sounds plausible. Have you tried it?

David

[Bug middle-end/61268] [4.10 regression] ICE in vt_expand_var_loc_chain, at var-tracking.c:8262

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #9 from Pat Haugen  ---
Following tests started failing on powerpc64-unknown-linux-gnu with r210543.

FAIL: gcc.dg/vmx/gcc-bug-5.c   -O3 -g  (internal compiler error)
FAIL: gcc.dg/vmx/gcc-bug-6.c   -O3 -g  (internal compiler error)
FAIL: gcc.dg/vmx/varargs-7.c   -O3 -g  (internal compiler error)

I tried the patch from comment 5 and all 3 now pass. Bootstrap on
powerpc64-unknown-linux-gnu also passed with it.

[Bug c++/61833] [4.9] ICE in fold_comparison

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
Hmm, I'm not seeing this with r212742.

[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate

[wmi at google dot com]

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

--- Comment #6 from wmi at google dot com ---
(In reply to davidxl from comment #5)
> (In reply to wmi from comment #4)
> > Can we move the pure/const resetting loop to an earlier place: inside
> > branch_prob , after instrument_edges and before gsi_commit_edge_inserts
> > (where stmt_ends_bb_p  is checked), so that gsi_commit_edge_inserts() which
> > changes cfg could take reset const/pure flags into consideration?
> 
> Sounds plausible. Have you tried it?
> 
> David

I just tried but found it was not very easy.

FOR_EACH_DEFINED_FUNCTION (node) {
  execute_fixup_cfg() and cleanup_tree_cfg()
  branch_prob()
}

For the above loop, branch_prob is called one by one for each defined func.
Because a func could possibly call any other funcs on the cgraph, we need to
reset the const/pure flags for every defined func before any branch_prob() is
called, so we cannot put the const/pure reset code inside branch_prob().

We also cannot move the const/pure reset loop before the branch_prob() loop,
because execute_fixup_cfg will use const/pure flags to generate different cfg.
If we put the const/pure reset code before the branch_prob() loop, the
const/pure reset code should only be executed in intrumentation phase, not in
annotation phase, so that we may get different cfg between intrumentation and
annotation.

Wei.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

--- Comment #8 from Jürgen Reuter  ---
Created attachment 33138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33138&action=edit
Test case

[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate

[xinliangli at gmail dot com]

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

--- Comment #7 from davidxl  ---
(In reply to wmi from comment #6)
> (In reply to davidxl from comment #5)
> > (In reply to wmi from comment #4)
> > > Can we move the pure/const resetting loop to an earlier place: inside
> > > branch_prob , after instrument_edges and before gsi_commit_edge_inserts
> > > (where stmt_ends_bb_p  is checked), so that gsi_commit_edge_inserts() 
> > > which
> > > changes cfg could take reset const/pure flags into consideration?
> > 
> > Sounds plausible. Have you tried it?
> > 
> > David
> 
> I just tried but found it was not very easy.
> 
> FOR_EACH_DEFINED_FUNCTION (node) {
>   execute_fixup_cfg() and cleanup_tree_cfg()
>   branch_prob()
> }
> 
> For the above loop, branch_prob is called one by one for each defined func.
> Because a func could possibly call any other funcs on the cgraph, we need to
> reset the const/pure flags for every defined func before any branch_prob()
> is called, so we cannot put the const/pure reset code inside branch_prob().
> 

As you noted below, resetting the flag before branch_prob will lead to cfg
mismatch between instr and profile-use build.

David

> We also cannot move the const/pure reset loop before the branch_prob() loop,
> because execute_fixup_cfg will use const/pure flags to generate different
> cfg. If we put the const/pure reset code before the branch_prob() loop, the
> const/pure reset code should only be executed in intrumentation phase, not
> in annotation phase, so that we may get different cfg between intrumentation
> and annotation.
> 
> Wei.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

--- Comment #9 from Jürgen Reuter  ---
I added the test case which is at least freed from a lot of docu and the heavy
autotools/libtool setup. The makefile compiles the code and creates a binary
seg_prod. Run this as ./seg_prod input.txt to produce the problem. I try to
reduce this further.

[Bug target/61837] New: missed loop invariant expression optimization

[carrot at google dot com]

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

Bug ID: 61837
   Summary: missed loop invariant expression optimization
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carrot at google dot com
  Host: x86_64-unknown-linux-gnu
Target: powerpc64le

Compile following code with trunk compiler and options -O2 -m64 -mcpu=power8

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

  v = 0;
  for (n = 0; n <= 100; n++) {
 for (i = 0; i < s; i++)
if (p2[i] == n)
   p1[i] = v;
 v += 88;
  }
}

I got

foo:
addi 9,5,-1
cmpwi 5,5,0
rldicl 9,9,0,32
li 6,0
li 7,0
add 5,4,9
.p2align 4,,15
.L2:
ble 5,.L6
addi 8,4,-1
mr 10,3
subf 9,8,5 // A
mtctr 9
b .L4
.p2align 4,,15
.L3:
addi 10,10,4
bdz .L6
.L4:
lbzu 9,1(8)
cmpw 7,9,7
bne 7,.L3
stw 6,0(10)
addi 10,10,4
bdnz .L4
.L6:
addi 6,6,88
addi 7,7,1
cmpwi 7,6,
extsw 7,7
extsw 6,6
bne 7,.L2
blr

Instruction A computes the inner loop counter, it is loop invariant for the
outer loop, so it can be hoisted out of the outer loop.

[Bug c++/61838] New: ICE on Windows with ctors defined outside class definitions

[lh_mouse at 126 dot com]

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

Bug ID: 61838
   Summary: ICE on Windows with ctors defined outside class
definitions
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com

Created attachment 33139
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33139&action=edit
crashme.cpp

A ctor, which takes a parameter of a template class with a template parameter
of another variadic template class, and defined outside its class definition,
results in an ICE. This ICE seems to happen on Windows only.

E:\Desktop>g++ crashme.cpp -std=c++1y
cc1plus.exe: internal compiler error: Segmentation fault

E:\Desktop>g++ -v
...
Target: x86_64-w64-mingw32
...
Thread model: win32
gcc version 4.9.1 (x86_64-win32-seh-rev0, Built by MinGW-W64 project)

[Bug c/51840] asm goto enhancement request

[adam at consulting dot net.nz]

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

--- Comment #11 from Adam Warner  ---
Thank you for the fixed example! Just for the record only toy VM examples can
be implemented using this technique.

GCC documentation used to say that that the extended asm 30 operand limit might
be lifted in a future version of GCC. This sentence seems to have been deleted.
The full statement now reads: "The total number of input + output + goto
operands has a limit of 30."

The Java Virtual Machine, for example, contains almost 200 bytecode
instructions. To use this technique to jump to each instruction the list of asm
goto labels would number around 200. But the GCC limit is less than 30 (since
one must also subtract input operands from the limit). It's a blemish on GCC's
compiler architecture and a gross violation of the zero-one-infinity rule.

BTW if the example is modified by adding 25+ additional dummy goto labels there
is an Internal Compiler Error in extract_insn, at recog.c:2175 [gcc (Debian
4.9.0-7) 4.9.0]

[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"

[damien.buhl at lecbna dot org]

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

Damien Buhl (daminetreg)  changed:

   What|Removed |Added

 CC||damien.buhl at lecbna dot org

--- Comment #40 from Damien Buhl (daminetreg)  
---
I can also confirm the crash with gcc-4.8.1 for an arm platform. 

Everything compiles fine, but on the platform the support for atomics looks
like missing, because it dies with pure virtual method called.

Using boost::thread which uses boost::atomic and in this case implements atomic
self (not via the gcc compiler) is the only workaround I found without
recompiling the compiler with atomic support.

[Bug c++/61833] [4.9] ICE in fold_comparison

[ppluzhnikov at google dot com]

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

Paul Pluzhnikov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Paul Pluzhnikov  ---
I confirmed that both the reduced case and the original no longer ICE on
gcc-4_9-branch @r212773.