[Bug debug/47597] ICE: call frame debugging information is not handled when case is post_dec

[anitha.boyapati at atmel dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47597

--- Comment #2 from Anitha Boyapati  
2011-06-03 07:20:44 UTC ---
Patch in trunk revision 171296

http://gcc.gnu.org/viewcvs/trunk/gcc/dwarf2out.c?r1=171150&r2=171296&diff_format=h

[Bug c++/49264] [4.6/4.7 Regression] Internal compiler error: segmentation fault

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49264

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #10 from Jakub Jelinek  2011-06-03 
07:47:11 UTC ---
Created attachment 24421
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24421
gcc46-pr49264.patch

Untested fix.

[Bug libstdc++/49274] Regression: unique_ptr needs full definition of map type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

Jonathan Wakely  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com
   Severity|major   |normal

--- Comment #2 from Jonathan Wakely  2011-06-03 
08:33:42 UTC ---
the problem is that std::map requires the CMP class to be defined

it's undefined behaviour to instantiate std::map with an incomplete type,
apparently what's changed is that unique_ptr instantiates it.

Paolo, any idea if is this caused by a noexcept change somewhere?

[Bug libstdc++/49274] Regression: unique_ptr needs full definition of map type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

--- Comment #3 from Jonathan Wakely  2011-06-03 
08:50:23 UTC ---
I'm not sure why default_delete needs to instantiate T, it doesn't need a
complete type except in operator()

[Bug libstdc++/49274] Regression: unique_ptr needs full definition of map type

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

--- Comment #4 from Paolo Carlini  2011-06-03 
09:32:34 UTC ---
Jon, I'm traveling, I cannot investigate this in detail, but I'm wondering if
this isn't a duplicate of the recent issue failed by Marc Glisse, about pair,
noexcept and incompleteness, which turned out to be definitely a c++ front-end
issue. I also markes it as regression. Can you check it?

[Bug other/2222] option enable-target-optspace disables _GNU_SOURCE

[oliver.metz at gmx dot de]

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

Oliver Metz  changed:

   What|Removed |Added

 CC||oliver.metz at gmx dot de

--- Comment #6 from Oliver Metz  2011-06-03 09:32:44 
UTC ---
Thanks Ian for your help.

This bug is still valid for gcc-4.6.0.

When --enable-target-optspace is set config/mt-ospace is included and
overwrites the configured CFLAGS_FOR_TARGET variable. 

config/mt-ospace:
# Build libraries optimizing for space, not speed.
 CFLAGS_FOR_TARGET = -g -Os
 CXXFLAGS_FOR_TARGET = -g -Os

So it's not possible to optimize the target libs for the target (e.g.
-march=4kc -msoft-float).

[Bug libstdc++/49274] Regression: unique_ptr needs full definition of map type

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

--- Comment #5 from Paolo Carlini  2011-06-03 
09:37:00 UTC ---
PR49107

[Bug tree-optimization/48377] [4.6/4.7 regression] miscompilation at -O3

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #39 from Eric Botcazou  2011-06-03 
10:01:01 UTC ---
> Fixed (the testcase with aligned(1)).  The original is INVALID.

The testcase with aligned(1) cannot pass on strict-alignment targets, either
with or without vectorization.  On the SPARC:

(botcazou@nile) /nile.build/botcazou/gcc-head/sparc-sun-solaris2.8 $ ./pr48377
Bus Error (core dumped)

On IA-64:

(botcazou@merced) /nile.build/botcazou/gcc-head/ia64-linux-gnu $ ./pr48377
pr48377(1543): unaligned access to 0x60001041, ip=0x4650
pr48377(1543): unaligned access to 0x60001045, ip=0x4650
pr48377(1543): unaligned access to 0x60001049, ip=0x4650
pr48377(1543): unaligned access to 0x6000104d, ip=0x4650

Please move it to gcc.target/i386 or something equivalent.

[Bug tree-optimization/48377] [4.6/4.7 regression] miscompilation at -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377

--- Comment #40 from Jakub Jelinek  2011-06-03 
10:06:26 UTC ---
(In reply to comment #39)
> > Fixed (the testcase with aligned(1)).  The original is INVALID.
> 
> The testcase with aligned(1) cannot pass on strict-alignment targets, either
> with or without vectorization.  On the SPARC:
> 
> (botcazou@nile) /nile.build/botcazou/gcc-head/sparc-sun-solaris2.8 $ ./pr48377
> Bus Error (core dumped)
> 
> On IA-64:
> 
> (botcazou@merced) /nile.build/botcazou/gcc-head/ia64-linux-gnu $ ./pr48377
> pr48377(1543): unaligned access to 0x60001041, ip=0x4650
> pr48377(1543): unaligned access to 0x60001045, ip=0x4650
> pr48377(1543): unaligned access to 0x60001049, ip=0x4650
> pr48377(1543): unaligned access to 0x6000104d, ip=0x4650
> 
> Please move it to gcc.target/i386 or something equivalent.

Can you explain why it cannot pass on strict-alignment targets?  The read is
done through a type with explicit low alignment, so strict alignment targets
just shouldn't use an aligned load but unaligned load in that case.  If that
doesn't work, it is a target bug.

[Bug libstdc++/49274] Regression: unique_ptr needs full definition of map type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.03 10:18:52
 Ever Confirmed|0   |1

--- Comment #6 from Jonathan Wakely  2011-06-03 
10:18:52 UTC ---
Thanks for the pointer, Paolo, I'll take a look later today.

Confirming anyway, as unique_ptr should work with incomplete T

[Bug tree-optimization/48377] [4.6/4.7 regression] miscompilation at -O3

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377

--- Comment #41 from Eric Botcazou  2011-06-03 
10:41:55 UTC ---
> Can you explain why it cannot pass on strict-alignment targets?  The read is
> done through a type with explicit low alignment, so strict alignment targets
> just shouldn't use an aligned load but unaligned load in that case.

What do you mean by an unaligned load?  Most targets don't have that.  If you
want to support

typedef unsigned int U __attribute__((__aligned__ (1)));

U id (U *u)
{
  return *u;
}

on strict-alignment targets, you'll have to implement it in the middle-end.  In
the meantime (and for 4.6.x), the test cannot pass.

[Bug debug/47858] [4.5/4.6/4.7 Regression] IPA-SRA decreases quality of debug info

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47858

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #24416|0   |1
is obsolete||

--- Comment #5 from Jakub Jelinek  2011-06-03 
10:46:40 UTC ---
Created attachment 24422
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24422
gcc47-pr47858.patch

Updated patch, just added tree-sra.c bits for ipa-sra to add DEBUG x s=> y
and DEBUG z => D#N stmts as needed, and create VAR_DECL for the omitted
arguments.  With this DW_OP_GNU_parameter_ref is generated both for all places
in #c0 and #c4 testcases where it should.

Thinking more about DW_OP_GNU_parameter_ref vs. typed DWARF stack, I think it
will need as optional parameter the base type die, because unlike
DW_OP_GNU_entry_value where the type is derived from the type of the inner
expression (e.g. regval_type vs. breg/reg and deref_type vs. deref{,_size}) the
DWARF consumer needs to know which type should be used for the parameter.
So, it could be DW_OP_GNU_parameter_ref  where the first
argument is either 0 (untyped) or base type DIE offset, and second argument is
DIE offset of the DW_TAG_formal_parameter.
Or, it could have no explicit type and the type would be taken from the caller
DW_TAG_GNU_call_site_parameter's DW_AT_GNU_call_site_value.
Preferences from debug consumer folks?

For the (still unimplemented) caller side representation in GIMPLE and RTL,
I forgot we don't need just list of DEBUG_EXPR_DECLs/DEBUG_EXPRs, we actually
need a list of pairs  and propagate that
list up to var-tracking.

[Bug c++/46003] cond5.C fails for ARM EABI tests.

[yufeng at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46003

Yufeng Zhang  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||yufeng at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |yufeng at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Yufeng Zhang  2011-06-03 
10:48:29 UTC ---
(In reply to comment #4)
> Test g++.dg/template/cond5.C started failing for arm-none-linux-gnueabi with
> this patch:
> 
> r132158 | aoliva | 2008-02-06 20:31:43 + (Wed, 06 Feb 2008) | 10 lines
> 
> gcc/cp/ChangeLog:
> PR c++/35056
> * tree.c: Include tree-flow.h.
> (build_target_expr): Check type compatibility.

The type checking introduced by this commit to build_target_expr is indeed
where the ICE occurs, i.e. the assertion failure. The added type-checking
exposes the problem.

Jason Merrill has suggested updating build_conditional_expr to "have a template
case that just determines the appropriate type and then builds up a COND_EXPR
with that type from the unconverted operands, like we do for calls in
finish_call_expr" (http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00164.html)

I've been distracted by other work, but will come back to this very soon.

[Bug tree-optimization/48377] [4.6/4.7 regression] miscompilation at -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377

--- Comment #42 from Jakub Jelinek  2011-06-03 
10:54:54 UTC ---
It surprises me it doesn't handle it, that is clearly a bug.
Conceptually it is no different from
struct A { char c; unsigned int d; } __attribute__((packed));

unsigned int
id (struct A *p)
{
  return p->d;
}

which is handled.

[Bug tree-optimization/48377] [4.6/4.7 regression] miscompilation at -O3

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377

--- Comment #43 from Eric Botcazou  2011-06-03 
11:10:35 UTC ---
> Conceptually it is no different from
> struct A { char c; unsigned int d; } __attribute__((packed));
> 
> unsigned int
> id (struct A *p)
> {
>   return p->d;
> }
> 
> which is handled.

Guess what?  We implement under-aligned scalar types in Ada, i.e. the
equivalent of typedef unsigned int U __attribute__((__aligned__ (1))) by
wrapping them up in a record type. ;-)  As soon as you give SImode to the type,
the game is over.

[Bug c++/49274] [4.6/4.7 Regression] unique_ptr needs full definition of map type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
  Component|libstdc++   |c++
  Known to work||4.4.5, 4.5.0
Summary|Regression: unique_ptr  |[4.6/4.7 Regression]
   |needs full definition of|unique_ptr needs full
   |map type|definition of map type

--- Comment #7 from Jonathan Wakely  2011-06-03 
11:19:59 UTC ---
reduced, with no library or c++0x dependencies:

struct incomplete;

template
struct cont
{
  T t;
};

template struct complete { };


int main()
{
  complete> c;
  c = c;
}

which works prior to 4.6, and with EDG and clang

with 4.6 and later the assignment requires cont to be complete,
even though it is unused in complete.

In the original testcase that causes is_assignable to instantiate
map

Jason, could you take a look?
Possibly the same issue as PR 49107

[Bug tree-optimization/48377] [4.6/4.7 regression] miscompilation at -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377

--- Comment #44 from Jakub Jelinek  2011-06-03 
11:24:27 UTC ---
Created attachment 24423
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24423
gcc46-pr48377.patch

I don't see why mode should be relevant, the MEM_REF should have from the type
clear indication that it is unaligned load (or store) and just should lead to
the bit-fieldish expansion.

Anyway, here is a testsuite patch for now, works on x86_64, not tested other
targets.

[Bug c++/49274] [4.6/4.7 Regression] unique_ptr needs full definition of map type

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

--- Comment #8 from Paolo Carlini  2011-06-03 
11:40:20 UTC ---
Thanks Jon.

[Bug c++/49274] [4.6/4.7 Regression] unique_ptr needs full definition of map type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work|4.5.0   |4.1.2
  Known to fail||4.5.2, 4.6.0, 4.7.0

--- Comment #9 from Jonathan Wakely  2011-06-03 
12:02:55 UTC ---
actually it fails with 4.5 too, I tried with an old pre-4.5.0 snapshot at
first, but 4.5.0 and later reject it

[Bug c++/49274] [4.6/4.7 Regression] unique_ptr needs full definition of map type

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  2011-06-03 
12:37:10 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153958

[Bug libfortran/48906] Wrong rounding results with -m32

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906

--- Comment #23 from Jerry DeLisle  2011-06-03 
12:55:21 UTC ---
Patch submitted to list for approval.

[Bug tree-optimization/48377] [4.6/4.7 regression] miscompilation at -O3

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377

--- Comment #45 from Richard Guenther  2011-06-03 
12:55:18 UTC ---
(In reply to comment #44)
> Created attachment 24423 [details]
> gcc46-pr48377.patch
> 
> I don't see why mode should be relevant, the MEM_REF should have from the type
> clear indication that it is unaligned load (or store) and just should lead to
> the bit-fieldish expansion.
> 
> Anyway, here is a testsuite patch for now, works on x86_64, not tested other
> targets.

The issue is (or at least was) that the mem-attrs get the alignment from
the alignment of the mode (for indirect-refs) unconditionally on strict-align
targets until

2010-12-30  Ulrich Weigand  

* emit-rtl.c (set_mem_attributes_minus_bitpos): Explicitly derive
default values from MEM mode if no memory attributes are present.
Do not use mode alignment, even on STRICT_ALIGNMENT targets, when
called with an expression (not a type).

and the indirect-ref path never went down the misaligned path as the
get_inner_reference path did.  This is a very old issue.  The only thing
MEM_REF improves here is that if the target has a movmisalign_optab it
is uses for such accesses, otherwise there will be simply a MEM RTX
with alingment less than the modes alignment which has no effect.

It is a genuine middle-end / target issue that we do not properly implement
this GCC extension for strict-align targets.

[Bug middle-end/49261] [4.7 Regression] FAIL: gcc.dg/tree-ssa/forwprop-9.c

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49261

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  2011-06-03 
13:04:36 UTC ---
Seems to be fixed now.

[Bug bootstrap/49270] make BOOT_CFLAGS="-g -O3" CFLAGS_FOR_TARGET="-g -O3" CXXFLAGS_FOR_TARGET="-g -O3" failure

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49270

--- Comment #8 from Dmitry Gorbachev  
2011-06-03 13:19:39 UTC ---
See also PR49116.

[Bug c++/49276] New: Segmentation fault with default lambda parameter in member function

[lepesme.jb at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49276

   Summary: Segmentation fault with default lambda parameter in
member function
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lepesme...@gmail.com


Created attachment 24424
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24424
The segfault source + 2 different sources that pass + temps + compile logs

Hi, I don't know if what I'm doing is correct, but GCC crashs on it.

Segfault: Member function with a default lambda parameter.
Pass-1: Global function with a default lambda parameter.
Pass-2: Member function without default lambda parameter.

[jiboo@localhost gccbag]$ uname -a
Linux localhost.localdomain 2.6.38.6-27.fc15.x86_64 #1 SMP Sun May 15 17:23:28
UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

[jiboo@localhost gccbag]$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.0 20110509 (Red Hat 4.6.0-7) (GCC) 

[jiboo@localhost gccbag]$ g++ -v -save-temps -Wall -Wextra -fno-strict-aliasing
-fwrapv -std=c++0x boog-pass-1.cpp 2>boog-pass-1.log
[jiboo@localhost gccbag]$ g++ -v -save-temps -Wall -Wextra -fno-strict-aliasing
-fwrapv -std=c++0x boog-pass-2.cpp 2>boog-pass-2.log
[jiboo@localhost gccbag]$ g++ -v -save-temps -Wall -Wextra -fno-strict-aliasing
-fwrapv -std=c++0x boog-segfault.cpp 2>boog-segfault.log

[Bug c++/49276] [C++0x] Segmentation fault with default lambda parameter in member function

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49276

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.03 13:36:58
Summary|Segmentation fault with |[C++0x] Segmentation fault
   |default lambda parameter in |with default lambda
   |member function |parameter in member
   ||function
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-06-03 
13:36:58 UTC ---
confirmed

[Bug middle-end/49277] New: [4.7 Regression] 456.hmmer in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49277

   Summary: [4.7 Regression] 456.hmmer in SPEC CPU 2006 failed to
build
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/ia32, revision 174523 gave

gcc -m32  -O2 -msse2 -mfpmath=sse -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin   -lm   alphabet.o core_algorithms.o debug.o display.o
emit.o emulation.o fast_algorithms.o histogram.o hmmio.o hmmcalibrate.o
hmmsearch.o mathsupport.o masks.o misc.o modelmakers.o plan7.o plan9.o
postprob.o prior.o tophits.o trace.o ucbqsort.o a2m.o aligneval.o alignio.o
clustal.o cluster.o dayhoff.o eps.o file.o getopt.o gki.o gsi.o hsregex.o
iupac.o msa.o msf.o phylip.o revcomp.o rk.o selex.o seqencode.o shuffle.o
sqerror.o sqio.o squidcore.o sre_ctype.o sre_math.o sre_random.o sre_string.o
ssi.o stack.o stockholm.o translate.o types.o vectorops.o weight.o
-lm-o hmmer
...
In file included from :28:0:
hmmsearch.c: In function 'main_loop_serial':
hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4124_585 == 6)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4124_597 == 6)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4118_602 == 7)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4124_645 == 7)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4163_684 == 1)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4163_684 == 3)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4288_847 == 1)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4288_875 == 1)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4510_1347 == 59)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4510_1353 != 59)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4523_1394 == 0)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4550_1404 != 62)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4560_1447 == 45)

hmmsearch.c:598:1: error: type mismatch in comparison expression
bool
char
unsigned char
if (D.4560_1447 != 0)

hmmsearch.c:598:1: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [/tmp/ccGI9oyK.ltrans0.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake[3]: *** [hmmer] Error 1

[Bug c++/49276] [C++0x] Segmentation fault with default lambda parameter in member function

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49276

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-06-03 
13:48:55 UTC ---
@@ -943,7 +943,7 @@ write_nested_name (const tree decl)
   else
 {
   /* No, just use   */
-  write_prefix (DECL_CONTEXT (decl));
+  write_prefix (CP_DECL_CONTEXT (decl));
   write_unqualified_name (decl);
 }
   write_char ('E');

fixes this, will try to reduce and submit patch.

[Bug c++/49274] [4.6/4.7 Regression] unique_ptr needs full definition of map type

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

--- Comment #11 from Jason Merrill  2011-06-03 
14:03:59 UTC ---
Yes, cont is an associated type for argument-dependent lookup, so
we instantiate it to get any friend declarations.  I think G++ is correct.

Clang fails to compile the testcase for 34870.  Interestingly, EDG accepts both
this testcase and the testcase for 34870.  I wonder why that would be.

[Bug c++/49274] [4.6/4.7 Regression] unique_ptr needs full definition of map type

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #12 from Jason Merrill  2011-06-03 
14:08:32 UTC ---
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#557

[Bug c++/49274] [4.6/4.7 Regression] unique_ptr needs full definition of map type

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

--- Comment #13 from Paolo Carlini  2011-06-03 
14:14:14 UTC ---
Ah, thus exactly like the issue we discussed a few days ago. I suspected that
and indeed Intel was accepting the code.

By the way, PR49107 is different then?

[Bug c++/49274] [4.6/4.7 Regression] unique_ptr needs full definition of map type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49274

--- Comment #14 from Jonathan Wakely  2011-06-03 
14:37:17 UTC ---
Thanks, Jason.

So to respond to the OP, although unique_ptr allows T to be incomplete it
might instantiate T, and unlike unique_ptr most templates in the standard
library cannot be instantiated with incomplete types, so if T is e.g.
std::map then the results are undefined.

[Bug lto/49277] [4.7 Regression] 456.hmmer in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49277

H.J. Lu  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Component|middle-end  |lto

--- Comment #1 from H.J. Lu  2011-06-03 14:40:05 
UTC ---
It is caused by revision 174519:

http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg5.html

[Bug c++/49276] [C++0x] Segmentation fault with default lambda parameter in member function

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49276

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Jakub Jelinek  2011-06-03 
15:06:30 UTC ---
Created attachment 24425
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24425
gcc46-pr49276.patch

Untested fix.

[Bug fortran/49278] New: internal compiler error: Segmentation fault

[petrielmjr at ornl dot gov]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278

   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: petriel...@ornl.gov


Created attachment 24426
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24426
The attachment has the gfortran version, system, command line, command output,
and source file

The source in the attachment causes an ICC.

[Bug java/49036] gcj-mp-4.5: Internal error: Abort trap (program ecj1) on Mac OS X 10.5.8

[Martin.vGagern at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49036

Martin von Gagern  changed:

   What|Removed |Added

 CC||Martin.vGagern at gmx dot
   ||net

--- Comment #2 from Martin von Gagern  
2011-06-03 15:21:49 UTC ---
Hit the same using Fink Project and pdftk 1.44-1.

(In reply to comment #1)
> Bug 41991 is possibly related to this bug.

As on my system, even a simple hello world java application fails to compile,
and that bug describes pretty much that situation, I'd say this is probably a
duplicate of that.

[Bug fortran/49278] internal compiler error: Segmentation fault

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
  Known to fail||4.3.6, 4.4.7, 4.5.3, 4.6.1,
   ||4.7.0

--- Comment #1 from kargl at gcc dot gnu.org 2011-06-03 16:07:45 UTC ---
Reduced testcase.

module oad_active
   implicit none
   type active
  sequence
  real :: v 
  real :: d =0.
   end type
end module

module tots_c
   use oad_active
   implicit none
   type(active), save :: trlkold
   data trlkold%v /0./
end module

[Bug fortran/49271] Compiler crashed and asked me to submit a report

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49271

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-06-03 16:29:12 UTC ---
What operating system?  

I get 

troutmask:sgk[272] gfc43 -c testcfopen.f90
testcfopen.f90:17.33:

PRINT '(I10)', file_struct%handle  ! I do not know what is in the structure or 
 1
Error: 'handle' at (1) is not a member of the 'c_ptr' structure

with 4.3.6, 4.4.7, 4.5.3, 4.6.1, and 4.7.0 on FreeBSD.  If I change
handle to a component within FreeBSD's FILE such as _blksize, I get

 testcfopen.f90:19.27:

PRINT '(I10)', file_struct%_blksize
   1
Error: Expected structure component name at (1)

[Bug fortran/49271] Compiler crashed and asked me to submit a report

[langton at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49271

Asher Langton  changed:

   What|Removed |Added

 CC||langton at gcc dot gnu.org

--- Comment #2 from Asher Langton  2011-06-03 
17:07:08 UTC ---
I can't reproduce this on x86_64-unknown-linux-gnu (4.3.3, 4.5.1, 4.6.0, 4.7)
or x86_64-apple-darwin10 (4.4.6).

[Bug fortran/49271] Compiler crashed and asked me to submit a report

[coml4 at san dot rr.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49271

--- Comment #3 from Hugh  2011-06-03 17:33:03 UTC ---
I apologize for omitting the OS.

27" iMac with i7 processor running OS X 10.6.7.  I know the code is bad.  It is
just that the compiler crashed and requested a bug report.

Hugh





On Jun 3, 2011, at 9:29 AM, kargl at gcc dot gnu.org wrote:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49271

kargl at gcc dot gnu.org changed:

  What|Removed |Added

CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-06-03 16:29:12 UTC ---
What operating system?  

I get 

troutmask:sgk[272] gfc43 -c testcfopen.f90
testcfopen.f90:17.33:

PRINT '(I10)', file_struct%handle  ! I do not know what is in the structure or 
1
Error: 'handle' at (1) is not a member of the 'c_ptr' structure

with 4.3.6, 4.4.7, 4.5.3, 4.6.1, and 4.7.0 on FreeBSD.  If I change
handle to a component within FreeBSD's FILE such as _blksize, I get

testcfopen.f90:19.27:

PRINT '(I10)', file_struct%_blksize
  1
Error: Expected structure component name at (1)

[Bug fortran/49271] Compiler crashed and asked me to submit a report

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49271

--- Comment #4 from Dominique d'Humieres  2011-06-03 
17:38:13 UTC ---
Compiling the code gives the error without crash for me too on
x86_64-apple-darwin10.7.0 (trunk and 4.4.4).

[Bug fortran/49278] internal compiler error: Segmentation fault

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278

--- Comment #2 from Steve Kargl  
2011-06-03 18:10:40 UTC ---
On Fri, Jun 03, 2011 at 04:08:05PM +, kargl at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
> 
> Reduced testcase.
> 
> module oad_active
>implicit none
>type active
>   sequence
>   real :: v 
>   real :: d =0.
>end type
> end module
> 
> module tots_c
>use oad_active
>implicit none
>type(active), save :: trlkold
>data trlkold%v /0./
> end module
> 

This simply patch fixes the segfault with the compiler.

Index: trans-expr.c
===
--- trans-expr.c(revision 174566)
+++ trans-expr.c(working copy)
@@ -4638,7 +4638,7 @@ gfc_conv_structure (gfc_se * se, gfc_exp
   cm = expr->ts.u.derived->components;

   for (c = gfc_constructor_first (expr->value.constructor);
-   c; c = gfc_constructor_next (c), cm = cm->next)
+   c && cm; c = gfc_constructor_next (c), cm = cm->next)
 {
   /* Skip absent members in default initializers and allocatable
 components.  Although the latter have a default initializer


It's not clear if it achieves the desired result.  The following
aborts.  Note sure if it is conforming.

module oad_active
   implicit none
   type active
  integer :: v 
  integer :: d = 42
   end type
end module

module tots_c
   use oad_active
   implicit none
   type(active), save :: trlkold
   data trlkold%v /100/
end module

program foo
   use tots_c
   implicit none
   if (trlkold%d /= 42) call abort
   if (trlkold%v /= 100) call abort
end program foo

[Bug debug/49167] dwarf marker for function return instruction

[jistone at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49167

Josh Stone  changed:

   What|Removed |Added

 CC||jistone at redhat dot com

--- Comment #1 from Josh Stone  2011-06-03 18:56:06 
UTC ---
(In reply to comment #0)
> Ideally, tail call sites would also have this marker, and so would
> inlined functions.  One can dream...

Besides nearby variables, we'd also like to know what is the imminent return
value.  I imagine that's fine for a typical function, and perhaps for inlines
too if optimization didn't morph it away.  But it's not clear to me how DWARF
could help us with the return value from a tail call.  If the callee is
statically known, then perhaps some indirection to that site, but in general I
don't know...

[Bug debug/49167] dwarf marker for function return instruction

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49167

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-06-03 
19:09:04 UTC ---
For tail calls, you have in GCC 4.7 (and 4.6-RH in Fedora 16) the
DW_TAG_GNU_call_site* stuff from which you can (sometimes) reconstruct the
actual backtrace.  The return value from the function that tail called another
one is by definition the same as from the tail callee.

[Bug target/48250] ICE in reload_cse_simplify_operands, at postreload.c:403

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48250

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
  Known to fail||4.6.0

--- Comment #3 from Ramana Radhakrishnan  2011-06-03 
19:34:06 UTC ---
Fixed on trunk . 

Needs backporting to 4.6 branch.

Ramana

[Bug c++/49276] [C++0x] Segmentation fault with default lambda parameter in member function

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49276

--- Comment #4 from Jakub Jelinek  2011-06-03 
20:19:46 UTC ---
Author: jakub
Date: Fri Jun  3 20:19:42 2011
New Revision: 174619

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174619
Log:
PR c++/49276
* mangle.c (write_nested_name): Use CP_DECL_CONTEXT instead of
DECL_CONTEXT.

* g++.dg/cpp0x/lambda/lambda-mangle2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49276] [C++0x] Segmentation fault with default lambda parameter in member function

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49276

--- Comment #5 from Jakub Jelinek  2011-06-03 
20:21:41 UTC ---
Author: jakub
Date: Fri Jun  3 20:21:38 2011
New Revision: 174620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174620
Log:
PR c++/49276
* mangle.c (write_nested_name): Use CP_DECL_CONTEXT instead of
DECL_CONTEXT.

* g++.dg/cpp0x/lambda/lambda-mangle2.C: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle2.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/mangle.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/49276] [C++0x] Segmentation fault with default lambda parameter in member function

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49276

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  2011-06-03 
20:37:39 UTC ---
Fixed.

[Bug target/48250] ICE in reload_cse_simplify_operands, at postreload.c:403

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48250

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/48792] ICE in failed_reload, at reload1.c:6000

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48792

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #4 from Ramana Radhakrishnan  2011-06-03 
21:02:57 UTC ---
This is now fixed. 

Ramana

[Bug rtl-optimization/48808] ICE in spill_failure, at reload1.c:2113

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48808

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
  Component|target  |rtl-optimization

--- Comment #4 from Ramana Radhakrishnan  2011-06-03 
21:13:59 UTC ---
This appears to be fixed on trunk . It appears to work with the command line
options that are specified on 4.6 branch. 


Reclassified. 


Ramana

[Bug rtl-optimization/48792] ICE in failed_reload, at reload1.c:6000

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48792

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
  Component|target  |rtl-optimization

--- Comment #5 from Ramana Radhakrishnan  2011-06-03 
21:14:31 UTC ---
And properly reclassified.

[Bug fortran/49271] Compiler crashed and asked me to submit a report

[langton at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49271

--- Comment #5 from Asher Langton  2011-06-03 
21:18:20 UTC ---
(In reply to comment #3)
> I apologize for omitting the OS.
> 
> 27" iMac with i7 processor running OS X 10.6.7.  I know the code is bad.  It 
> is
> just that the compiler crashed and requested a bug report.

I can't reproduce the crash with the current development version built on OS X
10.6.7. Could you post the output you get from running 'gfortran -v'?

[Bug c++/49279] New: Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets

[tcmartins at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279

   Summary: Optimization incorrectly presuming constant variable
inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for
x86_64 targets
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tcmart...@gmail.com


Created attachment 24427
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24427
Testcase (reduced automatically using multidelta)

GCC is apparently producing the wrong code with Eigen2 (a template-based linear
algebra library) with optimization levels -O3 and -O2 for
x86_64-unknown-linux-gnu targets. A reduced test case is provided that
reproduces the error.

As I understand, the core of the problem is this loop (line 1132 of
the submitted test case):

for (; (ProcessFirstHalf ? i && i.index () < j : i); ++i)  {
   if (LhsIsSelfAdjoint) {
  int a = LhsIsRowMajor ? j : i.index ();
  int b = LhsIsRowMajor ? i.index () : j;
  Scalar v = i.value ();
  derived ().row (b) += ei_conj (v) * product.rhs ().row (a);
  }
}

which is being translated into:

movq-8(%rsp), %rsi
movq(%rsi), %rbp
addq%rdx, %rbp
movsd0(%rbp), %xmm1   # <- %xmm1 is initialized here and 
.L5: #no longer touched!
leaq0(,%rcx,8), %rsi
leaq4(%r8,%rcx,4), %r8
movl%r9d, %ecx
jmp.L8
.L13:  # <-Loop here!!!
movl(%r8), %r10d
addq$4, %r8
.L8:
movsd0(%r13,%rsi), %xmm0
movslq%r10d, %r10
addl$1, %ecx
mulsd(%r12,%r10,8), %xmm0
cmpl%r11d, %ecx
addsd%xmm1, %xmm0
movsd%xmm0, 0(%rbp)   # <- % shouldn't %xmm1 be updated here?
je.L3  
addq$8, %rsi
cmpl%ecx, %r9d
jle.L13  # <- Loop ends 

the sum operation on line

 derived ().row (b) += ei_conj (v) * product.rhs ().row (a);

is apparently being performed by the instruction

 addsd%xmm1, %xmm0

but the value of %xmm1 isn't being updated inside the loop!! Apparently the
compiler is presuming derived ().row (b) is constant inside the loop, which is
evidently *not* true. Since the value of %xmm1 is never updated, the 
value of derived ().row (b) at the end of the loop is equal to the last 
ei_conj (v) * product.rhs ().row (a) result.

The bug was verified on gcc versions 4.5.2 and 4.6.0 with -O2 and -O3 switches.
The compiler produces the correct code with -O0 and -O switches.

It is *NOT* present on the 4.4 branch (that is, 4.4 compiles the code
correctly) for -O0, -0, -02 and -O3 switches. 

I suppose it is a regression of the 4.5 branch.

Command line (for gcc 4.6.0):
/opt/gnu/gcc-4.6/bin/g++ -v -save-temps -nostdinc -O3  testcase.a.cpp

Compiler output:
Using built-in specs.
COLLECT_GCC=/opt/gnu/gcc-4.6/bin/g++
COLLECT_LTO_WRAPPER=/opt/gnu/gcc-4.6/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure : (reconfigured) ../configure : (reconfigured)
../configure
Thread model: posix
gcc version 4.6.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-nostdinc' '-O3' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /opt/gnu/gcc-4.6/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -E
-quiet -nostdinc -v -iprefix
/opt/gnu/gcc-4.6/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/ -D_GNU_SOURCE
testcase.a.cpp -mtune=generic -march=x86-64 -O3 -fpch-preprocess -o
testcase.a.ii
#include "..." search starts here:
#include <...> search starts here:
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-nostdinc' '-O3' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /opt/gnu/gcc-4.6/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus
-fpreprocessed testcase.a.ii -quiet -dumpbase testcase.a.cpp -mtune=generic
-march=x86-64 -auxbase testcase.a -O3 -version -o testcase.a.s
GNU C++ (GCC) version 4.6.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0, GMP version 4.3.2, MPFR version
3.0.0-p8, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.6.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0, GMP version 4.3.2, MPFR version
3.0.0-p8, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3f3899c46d47b31a2bc0cb7f3d1408a6
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-nostdinc' '-O3' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as --64 -o testcase.a.o testcase.a.s
COMPILER_PATH=/opt/gnu/gcc-4.6/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/:/opt/gnu/gcc-4.6/bin/../libexec/gcc/
LIBRARY_PATH=/opt/gnu/gcc-4.6/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/:/opt/gnu/gcc-4.6/bin/../lib/gcc/:/opt/gnu/gcc-4.6/bin/../lib/gcc/x86_64-unknown-l

[Bug target/46329] ICE on ARM for __attribute__ ((vector_size (8 * sizeof(int)))) operations

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46329

Ramana Radhakrishnan  changed:

   What|Removed |Added

  Known to work||4.7.0
  Known to fail||4.6.0

--- Comment #5 from Ramana Radhakrishnan  2011-06-03 
21:48:42 UTC ---
Fixed on trunk - fails on 4.6 branch still . 


Ramana

[Bug fortran/49271] Compiler crashed and asked me to submit a report

[coml4 at san dot rr.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49271

--- Comment #6 from Hugh  2011-06-03 21:50:43 UTC ---
oz-2:gert_library hugh$ gfortran -v
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: /tmp/gfortran-20090604/ibin/../gcc/configure
--prefix=/usr/local/gfortran --enable-languages=c,fortran
--with-gmp=/tmp/gfortran-20090604/gfortran_libs --enable-bootstrap
Thread model: posix
gcc version 4.5.0 20090604 (experimental) [trunk revision 148180] (GCC) 



On Jun 3, 2011, at 2:18 PM, langton at gcc dot gnu.org wrote:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49271

--- Comment #5 from Asher Langton  2011-06-03
21:18:20 UTC ---
(In reply to comment #3)
> I apologize for omitting the OS.
> 
> 27" iMac with i7 processor running OS X 10.6.7.  I know the code is bad.  It 
> is
> just that the compiler crashed and requested a bug report.

I can't reproduce the crash with the current development version built on OS X
10.6.7. Could you post the output you get from running 'gfortran -v'?

[Bug fortran/49271] Compiler crashed and asked me to submit a report

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49271

--- Comment #7 from Steve Kargl  
2011-06-03 21:59:43 UTC ---
On Fri, Jun 03, 2011 at 09:50:46PM +, coml4 at san dot rr.com wrote:
>
> gcc version 4.5.0 20090604 (experimental) [trunk revision 148180] (GCC) 
>

You may be hitting an old bug.  20090604 occurred almost
2 years ago.  Can you update your compiler to something
a litte more recent?

[Bug tree-optimization/49135] ICE in gcc.c-torture/execute/920302-1.c on arm

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49135

--- Comment #6 from Ramana Radhakrishnan  2011-06-03 
22:18:04 UTC ---
combine puts 2 and 2 together . 

(insn 11 10 12 (set (reg/f:SI 154)
(mem/u/c/i:SI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [4 S4 A32]))
/home/ramana/cos/git/gcc/gcc/testsuite/gcc.c-torture/execute/920302-1.c:14 -1
 (expr_list:REG_EQUAL (label_ref:SI 0)  
(nil)))

(insn 12 11 13 (set (reg:HI 153)
(subreg:HI (reg/f:SI 154) 0))
/home/ramana/cos/git/gcc/gcc/testsuite/gcc.c-torture/execute/920302-1.c:14 -1
 (nil))

(insn 13 12 0 (set (reg:SI 142 [ D.2035 ])  
(zero_extend:SI (reg:HI 153)))
/home/ramana/cos/git/gcc/gcc/testsuite/gcc.c-torture/execute/920302-1.c:14 -1
 (nil))



Trying 11 -> 12:
Successfully matched this instruction:
(set (reg/f:HI 153)
(mem/u/c/i:HI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [4 S2 A32]))
deferring deletion of insn with uid = 11.
modifying insn i312 r153:HI=[`*.LC0']
deferring rescan insn with uid = 12.

Trying 12 -> 13:
Successfully matched this instruction:
(set (reg:SI 142 [ D.2035 ])
(zero_extend:SI (mem/u/c/i:HI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [4 S2
A32])))
deferring deletion of insn with uid = 12.
modifying insn i313 r142:SI=zero_extend([`*.LC0'])
deferring rescan insn with uid = 13.

---


(insn 13 12 15 3 (set (reg:SI 142 [ D.2035 ])
(zero_extend:SI (mem/u/c/i:HI (symbol_ref/u:SI ("*.LC0") [flags 0x2])
[4 S2 A32])))
/home/ramana/cos/git/gcc/gcc/testsuite/gcc.c-torture/execute/920302-1.c:14 150
{*arm_zero_extendhisi2_v6}
 (nil))

[Bug target/44290] [4.5 regression] __naked attribute is broken

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #34 from Ramana Radhakrishnan  
2011-06-03 22:19:40 UTC ---
Jie , 

Are you still planning on backporting this ?

Ramana

[Bug fortran/49280] New: Misinterpretation of -static-libgfortran switch

[hroch at physics dot muni.cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49280

   Summary: Misinterpretation of -static-libgfortran switch
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hr...@physics.muni.cz


Dear collegues,

I'm just informing, that linking of a trivial source 
with switch -static-libgfortran returns results which 
looks to be misinterpreted:

$ gfortran -static-libgfortran zk.f95
/usr/bin/ld: cannot find -lgfortran
collect2: ld returned 1 exit status

(The same for g++ and -static-libstdc++.)

Note, the switch works cleanly under the 
older gfortran 4.4.5 (Debian Squeeze).

FH

[Bug fortran/49280] Misinterpretation of -static-libgfortran switch

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49280

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-06-03 22:45:46 UTC ---
There is insufficient information here.  Do you
have libgfortran.a for the version of gfortran 
that you are trying to use?  Is libgfortran.a
installed in the location where gfortran was
configured to look for it?  I just tried the
option with 4.3, 4.4, 4.5, 4.6, and trunk 
versions of the compiler.

[Bug fortran/49280] Misinterpretation of -static-libgfortran switch

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49280

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot
   ||gnu.org

--- Comment #2 from Jerry DeLisle  2011-06-03 
23:48:52 UTC ---
Steve makes a good point.  I have found that some distributions do not install
the static libraries unless one specifically installs them.  An example is
Fedora 15.  They are provided, but not installed by default

[Bug target/49281] New: lea_general_4 doesn't work for x32

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49281

   Summary: lea_general_4 doesn't work for x32
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ja...@redhat.com, ubiz...@gmail.com


We added:

(define_insn_and_split "*lea_general_4"
  [(set (match_operand:SWI 0 "register_operand" "=r")
(any_or:SWI (ashift:SWI (match_operand:SWI 1 "index_register_operand"
"l")
(match_operand:SWI 2 "const_int_operand" "n"))
(match_operand 3 "const_int_operand" "n")))]
  "(mode == DImode
|| mode == SImode
|| !TARGET_PARTIAL_REG_STALL
|| optimize_function_for_size_p (cfun))
   && ((unsigned HOST_WIDE_INT) INTVAL (operands[2])) - 1 < 3
   && ((unsigned HOST_WIDE_INT) INTVAL (operands[3])
   <= ((unsigned HOST_WIDE_INT) 1 << INTVAL (operands[2])))"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  rtx pat;
  if (mode != DImode)
operands[0] = gen_lowpart (SImode, operands[0]);
  operands[1] = gen_lowpart (Pmode, operands[1]);
  operands[2] = GEN_INT (1 << INTVAL (operands[2]));
  pat = plus_constant (gen_rtx_MULT (Pmode, operands[1], operands[2]),
   INTVAL (operands[3]));
  if (Pmode != SImode && mode != DImode)
pat = gen_rtx_SUBREG (SImode, pat, 0);
  emit_insn (gen_rtx_SET (VOIDmode, operands[0], pat));
  DONE;
}
  [(set_attr "type" "lea")
   (set (attr "mode")
  (if_then_else (eq (symbol_ref "mode == DImode") (const_int 0))
(const_string "SI")
(const_string "DI")))])

It miscompiled 458.sjeng and 464.h264ref in SPEC CPU 2006 on x32.
I am trying to figure out what went wrong.

[Bug fortran/49271] Compiler crashed and asked me to submit a report

[coml4 at san dot rr.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49271

--- Comment #8 from Hugh  2011-06-04 01:08:47 UTC ---
I will be happy to update the compiler.  I very recently downloaded the latest
one that was labeled "Stable Release" for Mac OS X.  Which version do you
recommend?

Thanks,

Hugh McCutchen, Jr.



On Jun 3, 2011, at 2:59 PM, sgk at troutmask dot apl.washington.edu wrote:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49271

--- Comment #7 from Steve Kargl 
2011-06-03 21:59:43 UTC ---
On Fri, Jun 03, 2011 at 09:50:46PM +, coml4 at san dot rr.com wrote:
> 
> gcc version 4.5.0 20090604 (experimental) [trunk revision 148180] (GCC) 
> 

You may be hitting an old bug.  20090604 occurred almost
2 years ago.  Can you update your compiler to something
a litte more recent?

[Bug middle-end/49282] New: malloc corruption in large lto1-wpa run during inline edge heap resize

[andi-gcc at firstfloor dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282

   Summary: malloc corruption in large lto1-wpa run during inline
edge heap resize
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org


A large lto1-wpa run with 20110603 results now in

malloc.c:3551: munmap_chunk: Assertion `ret == 0' failed.

on x86-64-linux.

When I run with MALLOC_CHECK_=2 it seems to get a bit further, but eventually
aborts (and deadlocks because the abort->internal_error handler calls
malloc again)

Here's the original trace for the malloc that aborts (with MALLOC_CHECK_=2)

Any suggestions for patches to try to revert? Note full bisect
is difficult because this run depends on some earlier fixes.

Not uploading a test case currently because it's quite large.

#10 0x2b236701d4e5 in raise () from /lib64/libc.so.6
#11 0x2b236701e9b0 in abort () from /lib64/libc.so.6
#12 0x2b236705df1a in ?? () from /lib64/libc.so.6
#13 0x2b23670640d7 in ?? () from /lib64/libc.so.6
#14 0x00b2684d in xrealloc (oldmem=Unhandled dwarf expression opcode
0xf3
) at ../../gcc/libiberty/xmalloc.c:179
#15 0x0083e528 in vec_heap_o_reserve_1 (vec=0x2b23ea786010,
reserve=Unhandled dwarf ex
pression opcode 0xf3
)
at ../../gcc/gcc/vec.c:313
#16 0x005ea27f in VEC_inline_edge_summary_t_heap_reserve_exact (
alloc_=, vec_=)
at ../../gcc/gcc/ipa-inline.h:128
#17 VEC_inline_edge_summary_t_heap_safe_grow (alloc_=,
vec_=) at ../../gcc/gcc/ipa-inline.h:128
#18 VEC_inline_edge_summary_t_heap_safe_grow_cleared (alloc_=,
vec_=) at ../../gcc/gcc/ipa-inline.h:128
#19 inline_summary_alloc (alloc_=, vec_=)
at ../../gcc/gcc/ipa-inline-analysis.c:646
#20 0x005ea3c1 in inline_edge_duplication_hook (src=0x2b2499f41680,
dst=0x2b243e2d7680, data=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/ipa-inline-analysis.c:853
#21 0x004e995c in cgraph_call_edge_duplication_hooks
(cs2=0x2b243e2d7680,
cs1=0x2b2499f41680) at ../../gcc/gcc/cgraph.c:376
#22 cgraph_clone_edge (cs2=0x2b243e2d7680, cs1=0x2b2499f41680) at
../../gcc/gcc/cgraph.c:2127
#23 0x004e9c1d in cgraph_clone_node (n=0x2b2499f286f0,
decl=0x2b2395b15500, count=Unha
ndled dwarf expression opcode 0xf3
)
at ../../gcc/gcc/cgraph.c:2196
#24 0x005eeb9f in clone_inlined_nodes (e=0x2b2499f4a6e8, duplicate=1
'\001',
update_original=1 '\001', overall_size=0x102e488)

[Bug target/49281] lea_general_4 doesn't work for x32

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49281

--- Comment #1 from H.J. Lu  2011-06-04 03:18:48 
UTC ---
When the SImode pattern is enabled, SPEC CPU 2006 is miscompiled.

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49107

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #8 from Jason Merrill  2011-06-04 
05:55:15 UTC ---
This is not an arg-dependent lookup issue.  Here, instantiating
std::pair> involves evaluating
noexcept(ploum>::value), which means evaluating decltype(::new
VectorH3(declval>())), so invoking a VectorH3
constructor, so considering all the possible constructors, in particular
VectorH3(const Line_3&).  To evaluate how good that match is, we need to
instantiate Line_3, which fails as you see.

The resolution of core 1092 might make this work, though.  It isn't reflected
in the issues list, but the discussion in Madrid suggested that we should
always ignore constructors taking non-related types when trying to copy an
object of the same type.

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49107

Jason Merrill  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |

--- Comment #9 from Jason Merrill  2011-06-04 
06:17:27 UTC ---
(In reply to comment #8)
> The resolution of core 1092 might make this work, though.  It isn't reflected
> in the issues list, but the discussion in Madrid suggested that we should
> always ignore constructors taking non-related types when trying to copy an
> object of the same type.

But doing this breaks auto_ptr.  And v3 future as well, for some reason.

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49107

--- Comment #10 from Paolo Carlini  2011-06-04 
06:57:59 UTC ---
Thanks Jason, seems a nasty issue. I'm trying to understand how the specific
testcase in Comment #4 fits in the picture, ie why it compiles only because I
commented out that VectorH3 constructor which seems unrelated?!?