[Bug tree-optimization/42221] [4.5 Regression] ICE from '-Os -fgraphite-identity'

[spop at gcc dot gnu dot org]

--- Comment #10 from spop at gcc dot gnu dot org  2010-01-08 08:04 ---
Subject: Bug 42221

Author: spop
Date: Fri Jan  8 08:04:35 2010
New Revision: 155731

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155731
Log:
Fix PR42221.

2009-12-23  Sebastian Pop  

PR middle-end/42221
* sese.c (expand_scalar_variables_expr): Follow the SSA links into
the array indexing of ADDR_EXPRs.

* testsuite/gcc.dg/graphite/pr42221.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr42221.c
Modified:
trunk/gcc/ChangeLog.graphite
trunk/gcc/sese.c


-- 


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

[Bug tree-optimization/42221] [4.5 Regression] ICE from '-Os -fgraphite-identity'

[spop at gcc dot gnu dot org]

--- Comment #11 from spop at gcc dot gnu dot org  2010-01-08 08:05 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO|42393   |
  nThis||
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/42393] [4.5 Regression] [graphite] internal compiler error: in check_loop_closed_ssa_use

[spop at gcc dot gnu dot org]

--- Comment #10 from spop at gcc dot gnu dot org  2010-01-08 08:22 ---
Mine.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spop at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-08 08:22:09
   date||


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

[Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.

[steven at gcc dot gnu dot org]

--- Comment #14 from steven at gcc dot gnu dot org  2010-01-08 09:06 ---
Honza, you said in comment #13 that you would look at this -- got news?


-- 


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

[Bug target/38091] [Patch] H8SX: Bit instructions enhancement

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2010-01-08 09:06 ---
Ping?


-- 


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

[Bug target/40730] redundant memory load

[steven at gcc dot gnu dot org]

--- Comment #9 from steven at gcc dot gnu dot org  2010-01-08 09:34 ---
With "GCC: (GNU) 4.5.0 20100108 (experimental) [trunk revision 155731]" and my
patch for bug 20070 applied, I get the following code:

iterate:
push{lr}
ldr r3, [r1]
.L6:
str r3, [r0]
sub r2, r3, #0
bne .L5
b   .L3
.L4:
ldr r3, [r3, #8]
b   .L6
.L5:
ldr r1, [r3, #4]
cmp r1, #0
beq .L4
.L3:
str r2, [r0, #12]
@ sp needed for prologue
pop {pc}

Carrot, could you please double-check that this is still correct code?


-- 


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

[Bug fortran/41293] FGSL: Wrong code generated

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-01-08 09:49 ---
I just compiled GSL 1.13, FGSL 0.9.2 and run "make test" without any failure.
Thus: Close as FIXED.

Note: I have a patch for PR 41298 applied,
cf. http://gcc.gnu.org/ml/fortran/2010-01/msg00047.html


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libgcj/36658] Building gcj for arm linux from trunk (gcc 4.4.0): libjava/gcj/array.h:24: internal compiler error: verify_gimple failed

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug libstdc++/42573] [C++0x] shrink_to_fit() missing

[jwakely dot gcc at gmail dot com]

--- Comment #4 from jwakely dot gcc at gmail dot com  2010-01-08 10:05 
---
It would be conforming to add the function with an empty body ;)


-- 


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

[Bug fortran/25829] [F2003] Asynchronous IO support

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2010-01-08 10:11 ---
For completeness: I just committed support for the ASYNCHRONOUS attribute:
  http://gcc.gnu.org/ml/fortran/2010-01/msg00049.html
  http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00192.html
which is treated as no op.

One needs to think carefully whether one needs to take care of ASYNCHRONOUS for
the middle end when real async I/O is implemented. For a simple:
  write(9, ..., asynchronous='yes') foo
  ...
  write(9, ...) ! force WAIT on unit 9
  foo = 8
presumably not using "&foo" in the first write call lets the address escape
thus unless a function is known (to the ME) to not touch "foo" (indirectly), no
problem should occur. But how about:

  ! Note: using "foo" in AIO implies the ASYNCHRONOUS attribute for foo
  write(9, ..., asynchronous='yes', id=waitid) foo
  call finish(foo, waitid)
contains
  subroutine finish(var, wait)
asynchronous :: var
wait(wait)
var = 7
  end subroutine finish

Here, the ME might be tempted to change the order of WAIT and "var = 7"; thus
in this case we probably need to tell the ME about the ASYNCHRONOUS attribute.


-- 


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

[Bug c/42656] New: VLA as function parameter loses sizeof property

[tbullock at comlore dot com]

According to the documentation at
http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html it should be possible to
use a VLA as a function parameter and preserve the array length for use with
sizeof().

The documentation indicates that the C program at end of this description
should produce the following output

s: 
sizeof(s): 17
s: 
sizeof(s): 17

However gcc 4.4.1 produces the following output instead (note that the second
sizeof calculation is incorrect)

s: 
sizeof(s): 17
s: 
sizeof(s): 4

Note that the following C program is compiled with the -std=c99 option.


#include 
#include 

void
vararray(size_t l, const char s[l])
{
printf("s: <%s>\nsizeof(s): %d\n", s, sizeof(s));
}

int
main()
{
char s[] = "This is a string";

printf("s: <%s>\nsizeof(s): %d\n", s, sizeof(s));

vararray(sizeof(s), s);
return 0;
}


-- 
   Summary: VLA as function parameter loses sizeof property
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbullock at comlore dot com


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

[Bug c/42656] VLA as function parameter loses sizeof property

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-01-08 10:20 ---
No, the manual is just a little hard to read really.  The point about sizeof is
not connected with arguments at all but the normal VLA interface.  Also the VLA
decays to a pointer in this case as required by the normal argument C90/C99
decaying rules.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug translation/39521] specs diagnostics translation problems

[pzhao at gcc dot gnu dot org]

-- 

pzhao at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pzhao at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-08 10:29:20
   date||


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

[Bug libstdc++/42573] [C++0x] shrink_to_fit() missing

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2010-01-08 10:29 
---
Good joke and also good point Jon: I still believe that our C++0x user
interfaces, even not considering the semantics, aren't yet such complete and
otherwise perfect to grant that action, but all in all, if somebody wants to
add the empty bodies with a BIG TODO comment in the code, I do not object...


-- 


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

[Bug fortran/25829] [F2003] Asynchronous IO support

[burnus at gcc dot gnu dot org]

--- Comment #17 from burnus at gcc dot gnu dot org  2010-01-08 10:42 ---
(In reply to comment #16)
> Here, the ME might be tempted to change the order of WAIT and "var = 7"; thus
> in this case we probably need to tell the ME about the ASYNCHRONOUS attribute.

Probably by dropping the "restricted" for the pointer argument (as one would to
for TARGET). One should also check that it works for:
  subroutine finish(var, wait)
BLOCK
  asynchronous :: var
  wait(wait)
  var = 7
end BLOCK
  end subroutine finish
assuming that "asynchronous" applies in the block to the dummy argument.
(Should work analogously for volatile.)


-- 


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

[Bug debug/42657] New: Missing debug info for a variable

[jakub at gcc dot gnu dot org]

At -g -O2 var1 has a location attribute, but var2 does not.

extern unsigned int extfn (char *x);

static inline int
foo (const char *x, int y)
{
  int a = 0;
  a = extfn (y ? __builtin_strdup (x) : (char *) x);
  const char *var1 = x;
  int var2 = a;
  __asm__ volatile ("/* %0 %1 */" : : "r" (var1), "r" (var2));
  return a;
}

int
bar (const char *x)
{
  return foo (x, 1);
}

int
baz (const char *x)
{
  return foo (x, 0);
}

although obviously there is a register in which var2 is present (the one passed
to the inline asm.
The debug stmt is reset during inlining:
./cc1 -O2 -g rh552376.i -fdump-ipa-all -quiet; grep var rh552376.i.04[12]*
rh552376.i.041i.cp:  # DEBUG var1 => x_4(D)
rh552376.i.041i.cp:  # DEBUG var2 => a_9
rh552376.i.042i.inline:  # DEBUG var1 => x_4(D)
rh552376.i.042i.inline:  # DEBUG var2 => a_9
rh552376.i.042i.inline:  # DEBUG var1 => x_4(D)
rh552376.i.042i.inline:  # DEBUG var2 => a_9
rh552376.i.042i.inline:  # DEBUG var1 => x_1(D)
rh552376.i.042i.inline:  # DEBUG var2 => NULL
rh552376.i.042i.inline:  # DEBUG var1 => x_1(D)
rh552376.i.042i.inline:  # DEBUG var2 => NULL


-- 
   Summary: Missing debug info for a variable
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug libstdc++/42573] [C++0x] shrink_to_fit() missing

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-01-08 10:46 
---
Ok, Jon, you convinced me: I'll add the interfaces, and a very, very basic
implementation for vector and deque for now, I think just do something for PODs
(reminder to ourselves, change the dispatches in unitialized_* functions, etc,
to use to most strict yet correct traits)


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug debug/42657] Missing debug info for a variable

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-01-08 10:47 ---
Created an attachment (id=19506)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19506&action=view)
gcc45-pr42657.patch

Inliner fix I'm bootstrapping/regtesting ATM.  Unfortunately this isn't enough
to fix the testcase.
While the debug stmts/insns are preserved until var-tracking - in compgotos we
have:
(debug_insn 13 10 14 2 rh552376.i:7 (var_location:SI a (reg:SI 0 ax [orig:58
D.2702 ] [58])) -1 (nil))

(debug_insn 14 13 15 2 rh552376.i:8 (var_location:DI var1 (reg/v/f:DI 3 bx
[orig:61 x ] [61])) -1 (nil))

(debug_insn 15 14 16 2 rh552376.i:9 (var_location:SI var2 (reg:SI 0 ax [orig:58
D.2702 ] [58])) -1 (nil))

(insn:TI 16 15 27 2 rh552376.i:10 (parallel [
(asm_operands/v ("/* %0 %1 */") ("") 0 [
(reg/v/f:DI 3 bx [orig:61 x ] [61])
(reg:SI 0 ax [orig:58 D.2702 ] [58])
]
 [
(asm_input:DI ("r") (null):0)
(asm_input:SI ("r") (null):0)
]
 [] rh552376.i:24)
(clobber (reg:QI 18 fpsr))
(clobber (reg:QI 17 flags))
]) -1 (expr_list:REG_DEAD (reg/v/f:DI 3 bx [orig:61 x ] [61])
(expr_list:REG_UNUSED (reg:QI 18 fpsr)
(expr_list:REG_UNUSED (reg:QI 17 flags)
(nil)
var-tracking only gives location for x and var1 and not a and var2:
(note/c 44 10 43 2 (var_location x (expr_list:REG_DEP_TRUE (reg/v/f:DI 3 bx
[orig:61 x ] [61])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)

(note/c 43 44 45 2 (var_location x (expr_list:REG_DEP_TRUE (reg/v/f:DI 3 bx
[orig:61 x ] [61])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)

(note 45 43 46 2 (var_location a (expr_list:REG_DEP_TRUE (reg:SI 0 ax [orig:58
D.2702 ] [58])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)

(note 46 45 48 2 (var_location var1 (expr_list:REG_DEP_TRUE (reg/v/f:DI 3 bx
[orig:61 x ] [61])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)

(note 48 46 47 2 (var_location var2 (nil)) NOTE_INSN_VAR_LOCATION)

(note 47 48 16 2 (var_location a (nil)) NOTE_INSN_VAR_LOCATION)

(insn:TI 16 47 27 2 rh552376.i:10 (parallel [
(asm_operands/v ("/* %0 %1 */") ("") 0 [
(reg/v/f:DI 3 bx [orig:61 x ] [61])
(reg:SI 0 ax [orig:58 D.2702 ] [58])
]
The patch actually makes things worse in this testcase, but only in the
vartrack phase - that's because compared to without the patch var-tracking now
adds both the note 48 and note 47, before that there was neither of these
notes.
Which means that not only it doesn't know where var2 lives (it didn't know it
before either), but doesn't know where a lives either, eventhough the a in %eax
was correct.
So we need to also fix var-tracking...


-- 


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

[Bug libgcj/42658] New: [4.5 regression] ICE in _Jv_Linker::verify_class ../.././libjava/link.cc:1904

[jojelino at gmail dot com]

hi i'm trying to link libgcj dll for cygwin.
at recent, i get error while creating classmap.db
but it is wonder why this happened. it has been worked well though
when gcj-dbtool is static-linked to libgcj it doesn't give errors. (it doesn't
confine to gcj-dbtool. every program to 
linked libgcj.dll makes this error.)

Program received signal SIGSEGV, Segmentation fault.
0x6bf1da9e in _Jv_Linker::verify_class (klass=,
state=) at ../.././libjava/link.cc:1904
1904  klass->engine->verify(klass);
(gdb) bt
#0  0x6bf1da9e in _Jv_Linker::verify_class (klass=,
state=) at ../.././libjava/link.cc:1904
#1  _Jv_Linker::wait_for_state (klass=,
state=) at ../.././libjava/link.cc:2074
#2  0x6bf496e8 in java::lang::Class::initializeClass (
this=) at ../.././libjava/java/lang/natClass.cc:717
#3  0x6bf103a9 in _Jv_InitClass (vm_args=)
at ../.././libjava/prims.cc:1666
#4  _Jv_CreateJavaVM (vm_args=)
at ../.././libjava/prims.cc:1666
#5  0x6bf103ec in _Jv_RunMain (vm_args=,
klass=, name=,
argc=, argv=,
is_jar=) at ../.././libjava/prims.cc:1719
#6  0x6bf10738 in _Jv_RunMain (klass=,
name=, argc=,
argv=, is_jar=)
at ../.././libjava/prims.cc:1814
#7  0x6bf107af in JvRunMain (klass=,
argc=, argv=)
at ../.././libjava/prims.cc:1820
#8  0x00401152 in _fu0___Jv_Compiler_Properties (argc=,
argv=) at /cygdrive/d/Temp/cache/ccyGFL1n.i:11


-- 
   Summary: [4.5 regression] ICE in _Jv_Linker::verify_class
../.././libjava/link.cc:1904
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jojelino at gmail dot com


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

[Bug tree-optimization/42641] Random code-generation differences with GRAPHITE

[rguenther at suse dot de]

--- Comment #10 from rguenther at suse dot de  2010-01-08 11:09 ---
Subject: Re:  Random code-generation differences
 with GRAPHITE

On Thu, 7 Jan 2010, sebpop at gmail dot com wrote:

> 
> 
> --- Comment #6 from sebpop at gmail dot com  2010-01-07 17:58 ---
> Subject: Re:  Random code-generation differences 
> with GRAPHITE
> 
> After your change, there remains three users of htab_hash_pointer in graphite:
> 
> In if_region_set_false_region, there is a use of htab_hash_pointer,
> but that matches the use of the loops->exits htab as also used in
> get_exit_descriptions.
> 
> The next two, are:
> 
> hashval_t
> ivtype_map_elt_info (const void *elt)
> {
>   return htab_hash_pointer (((const struct ivtype_map_elt_s *) 
> elt)->cloog_iv);
> }
> 
> static inline hashval_t
> clast_name_index_elt_info (const void *elt)
> {
>   return htab_hash_pointer (((const struct clast_name_index *) elt)->name);
> }
> 
> and they are a bit more difficult to change, as it is the interface
> with CLooG that uses a "char *" to identify loop induction variables.
> In both cases, we're hashing on that string identifier.
> 
> Should these two functions be changed as well?

If you ever end up traversing those hash tables then yes, I suggest
to use htab_hash_string instead.  If you are not traversing them you
might want to consider using the somewhat more efficient pointer_map
structure (but that's only an optimization then).

Richard.


-- 


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

[Bug debug/42657] Missing debug info for a variable

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug tree-optimization/42646] Jump threading breaks canonical loop forms

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-08 11:52 ---
It just means that we shouldn't thread to the header but always to the latch
block.  Note that this restriction should probably be restricted to the
threading before loop optimizations.  Or the 1st jump threading should simply
avoid to thread over backedges (equivalent to removing the 1st DOM pass -
though
there is interesting fallout regarding jump-threading / loop header copying
pass ordering).


-- 


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

[Bug lto/42653] ICE with -g and -flto (requires both flags to crash)

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-08 11:54 ---
Yep - -g and -flto are very experimental.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code, lto
   Last reconfirmed|-00-00 00:00:00 |2010-01-08 11:54:31
   date||


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

[Bug tree-optimization/42652] vectorizer created unaligned vector insns

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-08 11:58 ---
There is some hacks with contains_packed_reference but IIRC I was complaining
about these at some point - they are not conservatively correct.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||irar at gcc dot gnu dot org


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

[Bug c++/42608] [4.4/4.5 Regression] Undefined reference not reported in case of explicit template instantiation

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-01-08 12:06 ---
Yeah, there are several reasons why DECL_WEAK may be set, but only when it is
because of weak attribute or #pragma weak we want to add it to weak_decls.
For vague linkage, or weakref attribute we don't want to do that.

I wonder whether we couldn't add weak attribute in apply_pragma_weak and just
add to weak_decls decls that have that attribute.


-- 


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

[Bug tree-optimization/39955] [4.5 Regression] struct-layout-1 test failures passing struct containing _Decimal32

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2010-01-08 12:41 
---
It looks like this bug is fixed.  Please re-open if struct-layout-1 tests still
fail.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/42139] [4.5 regression] Compiling firefox trunk with 4.5 fails with 'out of memory allocating 4072 bytes after a total of xxx bytes'

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-08 12:50 ---
Maybe I'm missing something.

/usr/bin/time g++-4.5 -S jsxml.ii -m32 -O3 -fPIC -fno-rtti -fno-exceptions
-Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros
-Wno-long-long -pedantic -fstrict-aliasing
6.58user 0.14system 0:06.74elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+1256outputs (0major+23549minor)pagefaults 0swaps

tops at 120MB virtual memory usage.


/usr/bin/time g++-4.4 -S jsxml.ii -m32 -O3 -fPIC -fno-rtti -fno-exceptions
-Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros
-Wno-long-long -pedantic -fstrict-aliasing
6.59user 0.18system 0:06.84elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
24inputs+1248outputs (1major+27930minor)pagefaults 0swaps

tops at 130MB virtual memory usage.


Marking as fixed.  Please re-open if you can still reproduce it but give
more details then.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2010-01-08 12:54 
---
I agree.  Modifying existing DECLs doesn't sound like a good thing to do.


-- 


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

[Bug bootstrap/42424] [4.5 Regression] in-tree GMP/MPFR/MPC bootstrap fails

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-01-08 12:57 
---
Thus fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/42573] [C++0x] shrink_to_fit() missing

[paolo at gcc dot gnu dot org]

--- Comment #7 from paolo at gcc dot gnu dot org  2010-01-08 13:01 ---
Subject: Bug 42573

Author: paolo
Date: Fri Jan  8 13:01:24 2010
New Revision: 155733

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155733
Log:
2010-01-08  Paolo Carlini  

PR libstdc++/42573
* include/bits/allocator.h (struct __shrink_to_fit): Add.
* include/bits/stl_deque.h (deque<>::shrink_to_fit): Add.
* include/bits/stl_vector.h (vector<>::shrink_to_fit): Likewise.
* include/bits/stl_bvector.h (vector::shrink_to_fit): Likewise.
* include/bits/basic_string.h (basic_string<>::shrink_to_fit):
Likewise.
* include/ext/vstring.h (__versa_string<>::shrink_to_fit): Likewise.
* include/debug/deque: Add corresponding using declaration.
* include/debug/vector: Likewise.
* include/debug/string: Likewise.
* include/profile/deque: Likewise.
* include/profile/vector: Likewise.
* config/abi/pre/gnu.ver: Export new symbols.
* testsuite/23_containers/deque/capacity/shrink_to_fit.cc: New.
* testsuite/23_containers/vector/capacity/shrink_to_fit.cc: Likewise.
* testsuite/21_strings/basic_string/capacity/char/shrink_to_fit.cc:
Likewise.
* testsuite/21_strings/basic_string/capacity/wchar_t/shrink_to_fit.cc:
Likewise.
* testsuite/ext/vstring/capacity/shrink_to_fit.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/assign_neg.cc:
Adjust dg-error line number.
* testsuite/23_containers/deque/requirements/dr438/insert_neg.cc:
Likewise.
* testsuite/23_containers/deque/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/
constructor_2_neg.cc: Likewise.
* testsuite/23_containers/vector/requirements/dr438/assign_neg.cc:
Adjust dg-error line number.
* testsuite/23_containers/vector/requirements/dr438/insert_neg.cc:
Likewise.
* testsuite/23_containers/vector/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/vector/requirements/dr438/
constructor_2_neg.cc: Likewise.

Added:
   
trunk/libstdc++-v3/testsuite/21_strings/basic_string/capacity/char/shrink_to_fit.cc
   
trunk/libstdc++-v3/testsuite/21_strings/basic_string/capacity/wchar_t/shrink_to_fit.cc
trunk/libstdc++-v3/testsuite/23_containers/deque/capacity/shrink_to_fit.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/capacity/shrink_to_fit.cc
trunk/libstdc++-v3/testsuite/ext/vstring/capacity/shrink_to_fit.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/include/bits/allocator.h
trunk/libstdc++-v3/include/bits/basic_string.h
trunk/libstdc++-v3/include/bits/stl_bvector.h
trunk/libstdc++-v3/include/bits/stl_deque.h
trunk/libstdc++-v3/include/bits/stl_vector.h
trunk/libstdc++-v3/include/debug/deque
trunk/libstdc++-v3/include/debug/string
trunk/libstdc++-v3/include/debug/vector
trunk/libstdc++-v3/include/ext/vstring.h
trunk/libstdc++-v3/include/profile/deque
trunk/libstdc++-v3/include/profile/vector
   
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/assign_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/insert_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc


-- 


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

[Bug middle-end/42482] [4.5 Regression] Many graphite test failures

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-08 13:05 ---
I still see

FAIL: g++.dg/graphite/pr42130.C execution test
FAIL: gcc.dg/graphite/pr40281.c (test for excess errors) -m32
FAIL: gfortran.dg/graphite/pr42393.f90  -O  (internal compiler error)
FAIL: gfortran.dg/graphite/pr42393.f90  -O  (test for excess errors)
FAIL: gfortran.dg/graphite/pr42393.f90  -O -m32 (internal compiler error)
FAIL: gfortran.dg/graphite/pr42393.f90  -O -m32 (test for excess errors)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-08 13:05:21
   date||


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

[Bug libstdc++/42573] [C++0x] shrink_to_fit() missing

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2010-01-08 13:06 
---
Done (within the limits explained in the audit trail).


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function

[jamborm at gcc dot gnu dot org]

--- Comment #14 from jamborm at gcc dot gnu dot org  2010-01-08 13:23 
---
Unfortunately, creating clones within an intraprocedural pass (and IPA-SRA is
an intraprocedural pass from the pass manager point of view) and continuing 
optimizing them as the original procedure would currently does not work.
Allowing that would require some substantial changes to the pass manager. I
originally wanted to clone and did try various hacks but all of them were
exceptionally ugly and eventually I gave up.  It is of course doable but not
particularly easy, if that was the intent. 


-- 


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

[Bug c++/42608] [4.4/4.5 Regression] Undefined reference not reported in case of explicit template instantiation

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-01-08 13:42 ---
Created an attachment (id=19507)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19507&action=view)
gcc45-pr42608.patch

Untested fix.


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-08 14:07 ---
I believe we can only either allow truncations or widenings in following
SSA edges.  Otherwise we miss that in

  int l_2; 
  for (l_2 = -1; l_2 != 0; l_2 = (unsigned char)(l_2 - 1))
g_3 |= l_2;

the evolution is irregular in that the initial value is integer -1.  That is
what happens - we compute the evolution of the result of (unsigned char)(l_2
-1)
as { 255, +, 255 }_1 but we may not use this evolution to derive that of
the value assigned to l_2, (int) { 255, +, 255 }_1 because we cannot represent
this.  The correct evolution is -1, 254, 253 ..., 0 which isn't representable.

Thus I think we need to either kill the conversion code completely or
at least severely restrict it with sth like

Index: gcc/tree-scalar-evolution.c
===
--- gcc/tree-scalar-evolution.c (revision 155732)
+++ gcc/tree-scalar-evolution.c (working copy)
@@ -1161,9 +1161,19 @@ follow_ssa_edge_expr (struct loop *loop,
 {
 CASE_CONVERT:
   /* This assignment is under the form "a_1 = (cast) rhs.  */
-  res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
- halting_phi, evolution_of_loop, limit);
-  *evolution_of_loop = chrec_convert (type, *evolution_of_loop, at_stmt);
+  rhs0 = TREE_OPERAND (expr, 0);
+  if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (rhs0))
+ || TREE_CODE (*evolution_of_loop) != POLYNOMIAL_CHREC)
+   {
+ res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
+ halting_phi, evolution_of_loop, limit);
+ *evolution_of_loop = chrec_convert (type, *evolution_of_loop,
at_stmt);
+   }
+  else
+   {
+ *evolution_of_loop = chrec_dont_know;
+ res = t_false;
+   }
   break;

 case INTEGER_CST:
@@ -1219,14 +1229,25 @@ follow_ssa_edge_in_rhs (struct loop *loo
   enum tree_code code = gimple_assign_rhs_code (stmt);
   tree type = gimple_expr_type (stmt), rhs1, rhs2;
   t_bool res;
+  tree name;

   switch (code)
 {
 CASE_CONVERT:
   /* This assignment is under the form "a_1 = (cast) rhs.  */
-  res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
- halting_phi, evolution_of_loop, limit);
-  *evolution_of_loop = chrec_convert (type, *evolution_of_loop, stmt);
+  name = gimple_assign_rhs1 (stmt);
+  if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (name))
+ || TREE_CODE (*evolution_of_loop) != POLYNOMIAL_CHREC)
+   {
+ res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
+ halting_phi, evolution_of_loop, limit);
+ *evolution_of_loop = chrec_convert (type, *evolution_of_loop, stmt);
+   }
+  else
+   {
+ *evolution_of_loop = chrec_dont_know;
+ res = t_false;
+   }
   break;

 case POINTER_PLUS_EXPR:
@@ -1759,7 +1780,11 @@ interpret_rhs_expr (struct loop *loop, g

 CASE_CONVERT:
   chrec1 = analyze_scalar_evolution (loop, rhs1);
-  res = chrec_convert (type, chrec1, at_stmt);
+  if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (rhs1))
+ || TREE_CODE (chrec1) != POLYNOMIAL_CHREC)
+   res = chrec_convert (type, chrec1, at_stmt);
+  else
+   res = chrec_dont_know;
   break;

 default:


Sebastian - any better idea?  This will at least regress

FAIL: gcc.dg/tree-ssa/scev-cast.c scan-tree-dump-times optimized "= \(unsigned
char\)" 1
FAIL: gcc.dg/tree-ssa/scev-cast.c scan-tree-dump-times optimized "= \(char\)" 1


because we cannot distinguish the really critical cases from ok ones.
The patch in comment #4 just makes the issue latent again.


-- 


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

[Bug ada/39336] libgnat.dylib, libgnarl.dylib don't contain full paths

[simon at pushface dot org]

--- Comment #3 from simon at pushface dot org  2010-01-08 14:45 ---
Fixed in 4.5.0 (only checked on *-apple-darwin10, but no reason to suppose
isn't fixed on other OS releases).


-- 


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

[Bug ada/42659] New: gnatmake thinks libraries aren't supported

[simon at pushface dot org]

Use of a library GPR (which works fine with i386-apple-darwin10) fails with
"libraries are not supported on this platform".
This is because gnattools/configure uses the test
  powerpc-*-darwin* | *86-*-darwin*)
TOOLS_TARGET_PAIRS="mlib-tgt-specific.adbhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=42659

[Bug ada/42659] gnatmake thinks libraries aren't supported

[simon at pushface dot org]

--- Comment #1 from simon at pushface dot org  2010-01-08 15:00 ---
Created an attachment (id=19508)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19508&action=view)
Patch to gnattools/configure*


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-08 15:00 ---
Hm, actually what is wrong is the evolution of l_2_18:

  (scalar = l_2_18)
  (scalar_evolution = {255, +, 0x0}_1))

that of l_2_10 is correct:

  (scalar = l_2_10)
  (scalar_evolution = (unsigned int) {254, +, 255}_1))

:
  # l_2_18 = PHI 
  # prephitmp.10_25 = PHI 
  # ivtmp.19_37 = PHI 
  D.1960_3 = (short unsigned int) l_2_18;
  g_3.1_5 = (short unsigned int) prephitmp.10_25;
  D.1963_6 = D.1960_3 | g_3.1_5;
  g_3.2_7 = (short int) D.1963_6;
  g_3_lsm.18_11 = g_3.2_7;
  D.1965_8 = (unsigned char) l_2_18;
  D.1966_9 = D.1965_8 + 255;
  l_2_10 = (unsigned int) D.1966_9;
  ivtmp.19_29 = ivtmp.19_37 - 1;
  if (ivtmp.19_29 != 0)
goto ;
  else
goto ;

:
  goto ;


Thus we need to verify we maintain the correct initial condition only?
Like for example with

Index: tree-scalar-evolution.c
===
--- tree-scalar-evolution.c (revision 155732)
+++ tree-scalar-evolution.c (working copy)
@@ -1642,6 +1642,15 @@ interpret_loop_phi (struct loop *loop, g
   init_cond = analyze_initial_condition (loop_phi_node);
   res = analyze_evolution_in_loop (loop_phi_node, init_cond);

+  /* Verify we maintained the correct initial condition throughout
+ possible conversions in the SSA chain.  */
+  if (res != chrec_dont_know)
+{
+  tree new_init = initial_condition (res);
+  if (!operand_equal_p (init_cond, new_init, 0))
+   return chrec_dont_know;
+}
+
   return res;
 }


Maybe too strict in case the returned chrec is wrapped in a conversion
operation itself (no idea if that ever happens - at least initial_condition
doesn't seem to deal with that during recursion either).

I'm going to test that patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-26 20:00:19 |2010-01-08 15:00:44
   date||


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

[Bug gcov-profile/42660] New: buggy instrumentation - return statement never executed.

[pluto at agmk dot net]

hi

i've noticed that in some cases, the test-coverage engine
doesn't record obvious source stmts (e.g. 'return s' from testcase).

$ cat t.cpp
#include 
#include 

char foo( int i )
{
return '0';
}

std::string bar( int i )
{
std::string s;
s+= foo( i );
return s;
}

int main()
{
std::puts( bar( 42 ).c_str() );
}

$ cat t.cpp.gcov
-:0:Source:t.cpp
-:0:Graph:t.gcno
-:0:Data:t.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:#include 
-:3:
1:4:char foo( int i )
-:5:{
1:6:return '0';
-:7:}
-:8:
1:9:std::string bar( int i )
-:   10:{
1:   11:std::string s;
1:   12:s+= foo( i );
#:   13:return s;
-:   14:}
-:   15:
1:   16:int main()
-:   17:{
1:   18:std::puts( bar( 42 ).c_str() );
-:   19:}


-- 
   Summary: buggy instrumentation - return statement never executed.
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
 GCC build triplet: x86_64-gnu-linux
  GCC host triplet: x86_64-gnu-linux
GCC target triplet: x86_64-gnu-linux


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

[Bug gcov-profile/42660] buggy instrumentation - return statement never executed.

[pluto at agmk dot net]

--- Comment #1 from pluto at agmk dot net  2010-01-08 15:06 ---
Created an attachment (id=19509)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19509&action=view)
testcase


-- 


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

[Bug libstdc++/32618] std::vector calls uneccessary constructors instead of inplace construction of first object

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2010-01-08 15:42 
---
Note: the same problem with the DefaultConstructible requirement affects for
example the new constructor vector(size_type). Thinking more about these issues
I'm wondering whether in N3000 std::vector & co are still supposed to be
explicitly instantiable for non-DefaultConstructible types - which would
require a quite boring dispatching and base-class dances for the whole class
for the sake of a few members, now that Concepts are gone - or not, or maybe
just as QoI. Does anybody have an idea? Maybe not, maybe is not supposed to,
otherwise, N2983 would not add the has_default_constructor trait as-if it was
not necessary before...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jwakely dot gcc at gmail dot
   ||com


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[spop at gcc dot gnu dot org]

--- Comment #7 from spop at gcc dot gnu dot org  2010-01-08 16:20 ---
Subject: Re:  [4.5 Regression] integer wrong code bug 
with loop

I like the patch that you proposed in Comment #6.
Let's see if it passes bootstrap and test.


-- 


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

[Bug gcov-profile/42660] buggy instrumentation - return statement never executed.

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-08 16:21 ---
Confirmed on trunk.  The return statement in bar() is not instrumented because
it is turned into a goto to the merged return statement by gimple lowering
and we are not good preserving gotos if they turn into fallthru edges later
(which in this case happens during EH lowering).

We go from

  [t.c : 11:15] s.10 = ;
  [t.c : 11:15] std::basic_string::basic_string (s.10);
  [t.c : 13:11] try
{
  [t.c : 12:14] D.12564 = foo (i);
  [t.c : 12:14] D.12565 = (int) D.12564;
  [t.c : 12:14] s.11 = ;
  [t.c : 12:15] std::basic_string::operator+= (s.11, D.12565);
  [t.c : 13:10] goto ;
}
  catch
{
  [t.c : 11:15] s.12 = ;
  [t.c : 11:15] std::basic_string::~basic_string (s.12);
}
  :
  return ;

to

  [t.c : 11:15] s.10 = ;
  [t.c : 11:15] std::basic_string::basic_string (s.10);
  [t.c : 12:14] D.12564 = foo (i);
  [t.c : 12:14] D.12565 = (int) D.12564;
  [t.c : 12:14] s.11 = ;
  [t.c : 12:15] std::basic_string::operator+= (s.11, D.12565);
  [t.c : 13:10] goto ;
  :
  return ;
  :
  [t.c : 11:15] s.12 = ;
  [t.c : 11:15] std::basic_string::~basic_string (s.12);
  resx 1

to

:
  [t.c : 11:15] s.10 = ;
  [t.c : 11:15] std::basic_string::basic_string (s.10);
  [t.c : 12:14] D.12564 = foo (i);
  [t.c : 12:14] D.12565 = (int) D.12564;
  [t.c : 12:14] s.11 = ;
  [t.c : 12:15] std::basic_string::operator+= (s.11, D.12565);

:
  return ;

:
  [t.c : 11:15] s.12 = ;
  [t.c : 11:15] std::basic_string::~basic_string (s.12);
  resx 1

We could special-case this particular case of CFG construction of a fallthru
to the return block with just a single predecessor to copy the location
from the fallthru goto, but ... that looks like a hack.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-08 16:21:48
   date||


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

[Bug gcov-profile/42660] buggy instrumentation - return statement never executed.

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-08 16:27 ---
I don't know if we can simply output empty insn ranges for the edge source
location in the debug information to fix this.


-- 


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

[Bug tree-optimization/42652] vectorizer created unaligned vector insns

[law at redhat dot com]

--- Comment #3 from law at redhat dot com  2010-01-08 16:45 ---
Subject: Re:  vectorizer created unaligned vector
 insns

On 01/08/10 04:58, rguenth at gcc dot gnu dot org wrote:
> --- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-08 11:58 
> ---
> There is some hacks with contains_packed_reference but IIRC I was complaining
> about these at some point - they are not conservatively correct.
>
>
>
I was thinking about this some more and ISTM that if we can't prove 
suitable alignment, then we have to fall back to a runtime test.  So 
improving the code to detect packed structures would be useful, but is 
not sufficient to resolve this class of problems.  ie, it probably 
wouldn't be too hard to transform that testcase into one which passed in 
a pointer to an unaligned palette->elms at which point we're forced to 
use the runtime test.

Thoughts?
jeff


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-08 16:53 ---
It FAILs

FAIL: gcc.dg/vect/pr36630.c scan-tree-dump-times vect "vectorized 1 loops" 1

but otherwise passes testing.  I'll see what effect it has on SPEC 2006 and
investigate the above.


-- 


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

[Bug lto/42528] ICE with -flto and -fsigned-char

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-01-08 16:58 ---
Subject: Bug 42528

Author: rguenth
Date: Fri Jan  8 16:57:59 2010
New Revision: 155740

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155740
Log:
2010-01-08  Richard Guenther  

PR lto/42528
* c.opt (fsigned-char): Also let LTO handle this option.
(funsigned-char): Likewise.

lto/
* lto-lang.c (lto_handle_option): Handle -f[un]signed-char.
(lto_init): Do not init char_type_node in a standard way
but according to flag_signed_char.

* gcc.dg/lto/20100103-1_0.c: New testcase.
* gcc.dg/lto/20100103-2_0.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/lto/20100103-1_0.c
trunk/gcc/testsuite/gcc.dg/lto/20100103-2_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c.opt
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-lang.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug lto/42528] ICE with -flto and -fsigned-char

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-08 16:58 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-01-08 17:07 ---
Ok, exactly the case I thought of (a conversion around the CHREC).  I'll see to
fix that up.


-- 


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

[Bug rtl-optimization/20070] If-conversion can't match equivalent code, and cross-jumping only works for literal matches

[steven at gcc dot gnu dot org]

--- Comment #30 from steven at gcc dot gnu dot org  2010-01-08 17:08 ---
(From update of attachment 17995)
The ifcvt.c part of the patch does not work anymore, because it doesn't handle
DEBUG_INSNs properly. I am working on an update.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #17995|0   |1
is obsolete||


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

[Bug ada/42659] gnatmake thinks libraries aren't supported

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2010-01-08 17:16 
---
Patches should be posted to the gcc-patc...@gcc.gnu.org mailing list.  Also see
http://gcc.gnu.org/contribute.html for guidelines.


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-01-08 17:21 
---
Ok, I have that fixed locally at the place of the patch but I wonder if
initial_condition () shouldn't return for example

  1ul for (unsigned long) { 1, +, 1 }_1

and

  (int) i_2 for (int) { i_2, +, 1 }_1

and further (for short i_2)

  i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1

?  Can the latter two happen all?  Is it even correct to talk about a
general initial condition in this case?  Consider

  { { 1, +, 1 }_2, +, 1 }_1

initial_condition will return 1 for the chrec even though that is not
correct because the initial condition is not constant in loop 1.
I suppose I'd only see that if instantiating the chrec at the point
where I placed the fix?  So I really only see at most a single outer
conversion around the chrec?


-- 


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

[Bug tree-optimization/42652] vectorizer created unaligned vector insns

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-08 17:25 ---
Well, indeed we have a certain weakness in how we represent pointers to
possibly (un-)aligned stuff.  See PR39954 for another case.  Maybe this
bug is really a duplicate of the underlying problems.


-- 


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

[Bug gcov-profile/42660] buggy instrumentation - return statement never executed.

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-01-08 17:46 ---
Actually this is a front-end issue with NVR :). See PR 12076.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/12076] gcov misreports coverage of return statement [NRV]

[pinskia at gcc dot gnu dot org]

--- Comment #17 from pinskia at gcc dot gnu dot org  2010-01-08 17:46 
---
*** Bug 42660 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pluto at agmk dot net


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

[Bug libgcj/42658] [4.5 regression] ICE in _Jv_Linker::verify_class ../.././libjava/link.cc:1904

[jojelino at gmail dot com]

--- Comment #1 from jojelino at gmail dot com  2010-01-08 17:50 ---
here is vtable dump for klass
as you can see , klass->engine of dynamic version is NULL 
whereas static version got proper instance though
so klass->engine->verify(klass); invokes SEGV...
but why does it happened??? some linker problem??
$ diff static dynamic -ud
--- static  2010-01-09 02:43:35.75000 +0900
+++ dynamic 2010-01-09 02:43:36.18750 +0900
@@ -1,23 +1,23 @@
 (gdb) print *klass
-$1 = (java::lang::Class) {
+$2 = (java::lang::Class) {
   <> = {},
   members of java::lang::Class:
   static class$ = {
 <> = {},
 members of java::lang::Class:
 static class$ = ,
-next_or_version = 0x0,
-name = 0xe2e9f4,
+next_or_version = 0x40062e08,
+name = 0x6c7f70b4,
 accflags = 49,
-superclass = 0xb5c900,
+superclass = 0x6c587100,
 constants = {
   size = 37,
-  tags = 0xb5c180 "",
-  data = 0xb5c0e0
+  tags = 0x6c587580 "",
+  data = 0x6c5874e0
 },
 {
-  methods = 0xb5c1c0,
-  element_type = 0xb5c1c0
+  methods = 0x6c5875c0,
+  element_type = 0x6c5875c0
 },
 method_count = 82,
 vtable_method_count = 65,
@@ -26,15 +26,15 @@
 ---Type  to continue, or q  to quit---
 field_count = 0,
 static_field_count = 0,
-vtable = 0xb5bf28,
+vtable = 0x6c587328,
 otable = 0x0,
 otable_syms = 0x0,
 atable = 0x0,
 atable_syms = 0x0,
 itable = 0x0,
 itable_syms = 0x0,
-catch_classes = 0xb5c828,
-interfaces = 0xb5c840,
+catch_classes = 0x6c587c28,
+interfaces = 0x6c587c40,
 loader = 0x0,
 interface_count = 4,
 state = 1 '\001',
@@ -52,37 +52,37 @@
 hack_signers = 0x0,
 chain = 0x0,
 aux_info = 0x0,
-engine = 0x1173040,
-reflection_data = 0xe2ea20 "\001"
+engine = 0x0,
+reflection_data = 0x6c7f70e0 "\001"
   },
-  next_or_version = 0x0,
-  name = 0xdfea20,
+  next_or_version = 0x40062e08,
+  name = 0x6c8cb860,
   accflags = 1057,
-  superclass = 0xb5c900,
+  superclass = 0x6c587100,
   constants = {
 size = 24,
-tags = 0xb1c838 "",
-data = 0xb19d00
+tags = 0x6c6a12d8 "",
+data = 0x6c69e7a0
   },
   {
-methods = 0xb1c860,
-element_type = 0xb1c860
+methods = 0x6c6a1300,
+element_type = 0x6c6a1300
   },
   method_count = 37,
   vtable_method_count = 34,
-  fields = 0xb1cb60,
+  fields = 0x6c6a1600,
   size_in_bytes = 44,
   field_count = 13,
 ---Type  to continue, or q  to quit---
   static_field_count = 4,
-  vtable = 0xb13888,
+  vtable = 0x6c698328,
   otable = 0x0,
   otable_syms = 0x0,
   atable = 0x0,
   atable_syms = 0x0,
   itable = 0x0,
   itable_syms = 0x0,
-  catch_classes = 0xb1cc30,
+  catch_classes = 0x6c6a16d0,
   interfaces = 0x0,
   loader = 0x0,
   interface_count = 0,
@@ -101,6 +101,6 @@
 ---Type  to continue, or q  to quit---
   chain = 0x0,
   aux_info = 0x0,
-  engine = 0x1173040,
-  reflection_data = 0xdfea40 "\002"
+  engine = 0x0,
+  reflection_data = 0x6c8cb880 "\002"

\ No newline at end of file


-- 


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

Re: [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[Sebastian Pop]

> Ok, I have that fixed locally at the place of the patch but I wonder if
> initial_condition () shouldn't return for example
>
>  1ul for (unsigned long) { 1, +, 1 }_1
>

This is correct.

> and
>
>  (int) i_2 for (int) { i_2, +, 1 }_1
>
> and further (for short i_2)
>
>  i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1
>
> ?  Can the latter two happen all?

Yes, these could happen, and you are right, we should see
the initial value of a chrec through the type conversion lenses.

> Is it even correct to talk about a
> general initial condition in this case?  Consider
>
>  { { 1, +, 1 }_2, +, 1 }_1
>
> initial_condition will return 1 for the chrec even though that is not
> correct because the initial condition is not constant in loop 1.

If you want, there is an initial condition for the loop_1 and that would be
{1, +, 1}_2, and there is an initial condition 1 for loop nest loop_2:

loop_2
  i = loop_2_phi (0, i+1) = {1, +, 1}_2
  loop_1
j = loop_1_phi (i, j+1) = {{1, +, 1}_2, +, 1}_1

> I suppose I'd only see that if instantiating the chrec at the point
> where I placed the fix?  So I really only see at most a single outer
> conversion around the chrec?

Yes, I think that at most you can have only one conversion around a chrec.

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[sebpop at gmail dot com]

--- Comment #11 from sebpop at gmail dot com  2010-01-08 17:55 ---
Subject: Re:  [4.5 Regression] integer wrong code bug 
with loop

> Ok, I have that fixed locally at the place of the patch but I wonder if
> initial_condition () shouldn't return for example
>
>  1ul for (unsigned long) { 1, +, 1 }_1
>

This is correct.

> and
>
>  (int) i_2 for (int) { i_2, +, 1 }_1
>
> and further (for short i_2)
>
>  i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1
>
> ?  Can the latter two happen all?

Yes, these could happen, and you are right, we should see
the initial value of a chrec through the type conversion lenses.

> Is it even correct to talk about a
> general initial condition in this case?  Consider
>
>  { { 1, +, 1 }_2, +, 1 }_1
>
> initial_condition will return 1 for the chrec even though that is not
> correct because the initial condition is not constant in loop 1.

If you want, there is an initial condition for the loop_1 and that would be
{1, +, 1}_2, and there is an initial condition 1 for loop nest loop_2:

loop_2
  i = loop_2_phi (0, i+1) = {1, +, 1}_2
  loop_1
j = loop_1_phi (i, j+1) = {{1, +, 1}_2, +, 1}_1

> I suppose I'd only see that if instantiating the chrec at the point
> where I placed the fix?  So I really only see at most a single outer
> conversion around the chrec?

Yes, I think that at most you can have only one conversion around a chrec.


-- 


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

[Bug target/42417] ICE in change_address_1 for 173.applu with -mvsx

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2010-01-08 18:01 ---


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


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/42416] ICE in rs6000_bulitin_vec_perm for 177.mesa with -mvsx

[janis at gcc dot gnu dot org]

--- Comment #3 from janis at gcc dot gnu dot org  2010-01-08 18:01 ---
*** Bug 42417 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/42416] ICE in rs6000_bulitin_vec_perm for 177.mesa with -mvsx

[janis at gcc dot gnu dot org]

-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janis at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-08 18:01:42
   date||


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

[Bug target/42419] ICE in reload_cse_simplify_operands for 254.gap with -mcpu=power7

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2010-01-08 18:02 ---


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


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/42416] ICE in rs6000_bulitin_vec_perm for 177.mesa with -mvsx

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2010-01-08 18:02 ---
*** Bug 42419 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/42661] New: Documented -mmad option not accepted.

[daney at gcc dot gnu dot org]

$ mips64-linux-gcc --version
mips64-linux-gcc (GCC) 4.5.0 20091201 (experimental) [trunk revision 154864]


The fine GCC documentation says:
-mmad
-mno-mad
Enable (disable) use of the mad, madu and mul instructions, as provided by
the R4650 ISA.

I get:

$ mips64-linux-gcc -march=r5000 -mmad -S hello.c
cc1: error: unrecognized command line option "-mmad"
$ mips64-linux-gcc -march=r5000 -mno-mad -S hello.c
cc1: error: unrecognized command line option "-mno-mad"

But these undocumented options are accpeted:
$ mips64-linux-gcc -march=r5000 -mad -S hello.c
$ mips64-linux-gcc -march=r5000 -mno-ad -S hello.c


-- 
   Summary: Documented -mmad option not accepted.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daney at gcc dot gnu dot org
 GCC build triplet: mips64-unknown-linux
  GCC host triplet: mips64-unknown-linux
GCC target triplet: mips64-unknown-linux


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

[Bug c/42662] New: invalid rtl sharing found in the insn

[dcb314 at hotmail dot com]

I just tried to compile the package cross-avr-gcc44 with the GNU
C compiler version 4.5 snapshot 20100107 and the compiler said

../../gcc/real.c:2486:1: error: invalid rtl sharing found in the insn
(debug_insn 287 285 289 22 ../../gcc/real.c:291 (var_location:QI D#65 (ltu:QI
(plus:DI (mult:DI (reg:DI 520 [ ai ])
(const_int 2 [0x2]))
(reg:DI 277 [ D.25377 ]))
(mult:DI (reg:DI 520 [ ai ])
(const_int 2 [0x2] -1 (nil))
../../gcc/real.c:2486:1: error: shared rtx
(mult:DI (reg:DI 520 [ ai ])
(const_int 2 [0x2]))
../../gcc/real.c:2486:1: internal compiler error: internal consistency failure
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flags -g -O3 required.


-- 
   Summary: invalid rtl sharing found in the insn
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c/42662] invalid rtl sharing found in the insn

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2010-01-08 18:10 ---
Created an attachment (id=19510)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19510&action=view)
C source code


-- 


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

[Bug debug/42662] [4.5 Regression] invalid rtl sharing found in the insn

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |debug
   Keywords||ice-on-valid-code
Summary|invalid rtl sharing found in|[4.5 Regression] invalid rtl
   |the insn|sharing found in the insn
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/42663] New: GCC 4.5-20100107 doesn't bootstrap on MinGW/MSYS

[lxndrmxwll at gmail dot com]

According to the GCC 4.5 Release Criteria at
http://gcc.gnu.org/gcc-4.5/criteria.html , MinGW is a secondary platform and
should be able to bootstrap successfully. GCC 4.5-20100107 contains the fix for
42584 and builds on MinGW/MSYS with --disable-bootstrap, but it still doesn't
bootstrap.

Here is my build process in precise detail.

Step 1. Extract to C:\Temp\gcc\msys (or any other location separate from the
working directories used here):

http://sourceforge.net/projects/mingw/files/ > MSYS Base System > msys-1.0.11 >
msysCORE-1.0.11-bin.tar.gz
http://sourceforge.net/projects/mingw/files/ > MSYS Bison > bison-2.4.1-1 >
bison-2.4.1-1-msys-1.0.11-bin.tar.lzma
http://sourceforge.net/projects/mingw/files/ > MSYS Flex > flex-2.5.35-1 >
flex-2.5.35-1-msys-1.0.11-bin.tar.lzma
http://sourceforge.net/projects/mingw/files/ > MSYS regex > regex-1.20090805-1
> libregex-1.20090805-1-msys-1.0.11-dll-1.tar.lzma

Step 2. Save decompressed .tar files to C:\Temp\gcc\sources (this is a staging
area separate from the working directories used here):

http://sourceforge.net/projects/mingw/files/ > MinGW Runtime > mingwrt-3.17 >
mingwrt-3.17-mingw32-dev.tar.gz
http://sourceforge.net/projects/mingw/files/ > MinGW API for MS-Windows >
w32api-3.14 > w32api-3.14-mingw32-dev.tar.gz
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100107/gcc-core-4.5-20100107.tar.bz2
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100107/gcc-g++-4.5-20100107.tar.bz2
ftp://ftp.gmplib.org/pub/gmp-4.3.1/gmp-4.3.1.tar.bz2
http://www.mpfr.org/mpfr-current/mpfr-2.4.2.tar.bz2
http://www.mpfr.org/mpfr-current/patches (renamed to mpfr-2.4.2.patch)
http://www.multiprecision.org/mpc/download/mpc-0.8.1.tar.gz

Step 3. In MSYS, run the following commands. This uses C:\Temp\gcc\src ,
C:\Temp\gcc\build , and C:\Temp\gcc\dest as working directories.

cd /c/temp/gcc/sources
tar -C /c/temp/gcc -xf gcc-core-4.5-20100107.tar
tar -C /c/temp/gcc -xf gcc-g++-4.5-20100107.tar
tar -C /c/temp/gcc -xf gmp-4.3.1.tar
tar -C /c/temp/gcc -xf mpfr-2.4.2.tar
patch -Z -d /c/temp/gcc/mpfr-2.4.2 -p1 < mpfr-2.4.2.patch
tar -C /c/temp/gcc -xf mpc-0.8.1.tar
mkdir -p /include
rm -rf /mingw
mkdir /mingw
tar -C /mingw -xf mingwrt-3.17-mingw32-dev.tar
tar -C /mingw -xf w32api-3.14-mingw32-dev.tar
cd /c/temp/gcc
mv gcc-4.5-20100107 src
mv gmp-4.3.1 src/gmp
mv mpfr-2.4.2 src/mpfr
mv mpc-0.8.1 src/mpc
mkdir build dest
cd build

../src/configure --prefix=c:/temp/gcc/dest --enable-languages=c,c++
--enable-threads --disable-nls --disable-win32-registry
--disable-sjlj-exceptions --with-arch=i486 --with-tune=generic
--enable-cxx-flags='-fno-function-sections -fno-data-sections'
--disable-libstdcxx-pch --disable-shared --enable-checking=release
--disable-symvers --enable-fully-dynamic-string

make

This fails with:

echo timestamp > s-fixinc_list
rm -rf include-fixed; mkdir include-fixed
chmod a+rx include-fixed
if [ -d ../prev-gcc ]; then \
  cd ../prev-gcc && \
  make real-install-headers-tar DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
else \
  set -e; for ml in `cat fixinc_list`; do \
sysroot_headers_suffix=`echo ${ml} | sed -e 's/;.*$//'`; \
multi_dir=`echo ${ml} | sed -e 's/^[^;]*;//'`; \
fix_dir=include-fixed${multi_dir}; \
if ! false && test ! -d `echo /mingw/include | sed -e :a -e
's,[^/]*/\.\.\/,,' -e ta`; then \
  echo The directory that should contain system headers does not
exist: >&2 ; \
  echo "  `echo /mingw/include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e
ta`" >&2 ; \
  tooldir_sysinc=`echo
"c:/temp/gcc/dest/lib/gcc/i686-pc-mingw32/4.5.0/../../../../i686-pc-mingw32/sys-include"
| sed -e :a -e "s,[^/]*/\.\.\/,," -e ta`; \
  if test "x`echo /mingw/include | sed -e :a -e 's,[^/]*/\.\.\/,,'
-e ta`" = "x${tooldir_sysinc}"; \
  then sleep 1; else exit 1; fi; \
fi; \
/bin/sh ../../src/gcc/../mkinstalldirs ${fix_dir}; \
chmod a+rx ${fix_dir} || true; \
(TARGET_MACHINE='i686-pc-mingw32'; srcdir=`cd ../../src/gcc;
${PWDCMD-pwd}`; \
  SHELL='/bin/sh'; MACRO_LIST=`${PWDCMD-pwd}`/macro_list ; \
  gcc_dir=`${PWDCMD-pwd}` ; \
  export TARGET_MACHINE srcdir SHELL MACRO_LIST && \
  cd ../build-i686-pc-mingw32/fixincludes && \
  /bin/sh ./fixinc.sh "${gcc_dir}/${fix_dir}" \
`echo /mingw/include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` 
); \
rm -f ${fix_dir}/syslimits.h; \
if [ -f ${fix_dir}/limits.h ]; then \
  mv ${fix_dir}/limits.h ${fix_dir}/syslimits.h; \
else \
  cp ../../src/gcc/gsyslimits.h ${fix_dir}/syslimits.h; \
fi; \
chmod a+r ${fix_dir}/syslimits.h; \
  done; \
fi
make[4]: Entering directory `/c/temp/gcc/build/prev-gcc'
../../src/gcc/cp/Make-lang.in:187: *** target pattern contains no `%'.  Stop.
make[4]: Leaving directory `/c/temp/gcc/buil

[Bug libstdc++/39243] Invalid thousands separator in russian locale

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-01-08 18:47 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libstdc++/16006] Conversions of numbers in fi_FI.UTF-8 produces incorrect UTF-8

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2010-01-08 18:47 
---
*** Bug 39243 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||Sergey dot Belyashov at
   ||gmail dot com


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

[Bug middle-end/42393] [4.5 Regression] [graphite] internal compiler error: in check_loop_closed_ssa_use

[spop at gcc dot gnu dot org]

--- Comment #11 from spop at gcc dot gnu dot org  2010-01-08 18:58 ---
On the graphite branch this fails with the following options:
gfortran -O2 -fno-loop-block -fno-loop-interchange -fno-loop-strip-mine
-fgraphite-identity pr42393.f90
Here is a further reduced testcase.

MODULE beta_gamma_psi
  INTEGER, PARAMETER :: dp=KIND(0.0D0)
CONTAINS
  FUNCTION basym () RESULT(fn_val)
REAL(dp) :: b0(21), bsum, d(21)
DO n = 2, num, 2
   DO i = n, np1
  b0(1) = 1
  DO m = 2, i
 mm1 = m - 1
 DO j = 1, mm1
bsum = bsum + b0(j)
 END DO
 b0(m) = bsum
  END DO
  d(i) = -b0(i)
   END DO
   sum = sum + d(n)
END DO
fn_val = sum
  END FUNCTION basym
END MODULE beta_gamma_psi

The problem seems to be in the code generation when replacing the end
value from a loop.


-- 


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

[Bug ada/41929] 64-bit null_pointer_deref1 gnat.dg test consumes all available memory

[ro at gcc dot gnu dot org]

--- Comment #8 from ro at gcc dot gnu dot org  2010-01-08 19:03 ---
Subject: Bug 41929

Author: ro
Date: Fri Jan  8 19:02:51 2010
New Revision: 155743

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155743
Log:
PR ada/41929
* gnat.dg/null_pointer_deref1.adb: Don't run on
sparc*-sun-solaris2.11.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gnat.dg/null_pointer_deref1.adb


-- 


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

[Bug libstdc++/37477] [Core 475] std::uncaught_exception() returns wrong value after entering terminate() in some cases

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-01-08 19:12 
---
I'm trusting Jon here: in the audi trail of PR41174 he mentioned that this
issue depends on the resolution of Core issue 475 (currently in drafting):

  http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#475




-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-08 19:12:20
   date||
Summary|std::uncaught_exception()   |[Core 475]
   |returns wrong value after   |std::uncaught_exception()
   |entering terminate() in some|returns wrong value after
   |cases   |entering terminate() in some
   ||cases


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

[Bug libstdc++/37477] [Core 475] std::uncaught_exception() returns wrong value after entering terminate() in some cases

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2010-01-08 19:12 
---
Suspending, waiting for [Ready].


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |SUSPENDED


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

[Bug libstdc++/41174] uncaught_exception always returns true

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2010-01-08 19:14 
---
I'm asking Rth to have a look to this one, apparently unrelated to DR Core 475.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||rth at gcc dot gnu dot org
   Severity|trivial |normal


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

[Bug bootstrap/42628] [4.5 regression] ICE during bootstrap when compiling several libsupc++ files: original tree changed by fold

[matt at use dot net]

--- Comment #4 from matt at use dot net  2010-01-08 19:32 ---
The crash doesn't happen with:
CFLAGS="-g -O3" CXXFLAGS="-g -O3" ../gcc-trunk/configure --prefix=/home/matt
--enable-gold --enable-build-with-cxx --enable-lto --enable-stage1-checking=all
--disable-werror --disable-bootstrap --enable-languages=c,c++,lto 
make -j6

When that build succeeded, I then tried to reproduce the previous problem using
the newly compiled GCC instead of the system's GCC 4.4.1. The problem
reproduces, so it appears to be independent of the compiler used for stage 1.

Should I test with individual options that make up -O3 to try and narrow it
down? I'll start doing that while I wait for further debugging instructions. 
You can track me down on freenode IRC as syke, if need be.


-- 


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

[Bug bootstrap/42663] GCC 4.5-20100107 doesn't bootstrap on MinGW/MSYS

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-01-08 19:40 ---
It is failing on:
c++.install-man: $(DESTDIR)$(man1dir)/$(GXX_INSTALL_NAME)$(man1ext)


I think the issue is --prefix=c:/temp/gcc/dest .


-- 


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

[Bug bootstrap/42663] GCC 4.5-20100107 doesn't bootstrap on MinGW/MSYS

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-01-08 19:42 ---
What happens if you use "--prefix=/temp/gcc/dest" instead?


-- 


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

[Bug fortran/42664] New: ICE on compilation of polyhedron benchmarks with -mfma4

[harsha dot jagasia at amd dot com]

The attached reduced test case derived from ac.f90 in the polyhedron benchmark
suite gives and ICE when compiled with gfortran 4.5 using -O3 -mfma4. This ICE
showed up in gcc 4.5 rev 154969 with the following check in:

2009-12-02  Richard Henderson  

* config/i386/i386.c (ix86_fixup_binary_operands): For FMA4, force
all operands into registers.

The ICE is as follows

bug-red.f90: In function ‘wolff’:
bug-red.f90:7:0: error: unrecognizable insn:
(insn 16 15 17 3 bug-red.f90:1 (parallel [
(set (mem:SI (reg/v/f:DI 71 [ iclsiz ]) [2 S4 A32])
(plus:SI (reg:SI 72)
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) -1 (expr_list:REG_EQUAL (plus:SI (mem:SI (reg/v/f:DI 71 [ iclsiz ])
[2 S4 A32])
(const_int 4 [0x4]))
(nil)))
bug-red.f90:7:0: internal compiler error: in extract_insn, at recog.c:2097
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE on compilation of polyhedron benchmarks with -mfma4
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: harsha dot jagasia at amd dot com
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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

[Bug fortran/42664] ICE on compilation of polyhedron benchmarks with -mfma4

[harsha dot jagasia at amd dot com]

--- Comment #1 from harsha dot jagasia at amd dot com  2010-01-08 20:34 
---
Created an attachment (id=19511)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19511&action=view)
Reduced test case for bug


-- 


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

[Bug fortran/42664] ICE on compilation of polyhedron benchmarks with -mfma4

[harsha dot jagasia at amd dot com]

--- Comment #2 from harsha dot jagasia at amd dot com  2010-01-08 20:35 
---
Created an attachment (id=19512)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19512&action=view)
Proposed Patch


-- 


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

[Bug fortran/42664] ICE on compilation of polyhedron benchmarks with -mfma4

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2010-01-08 20:47 ---
(In reply to comment #0)
> The attached reduced test case derived from ac.f90 in the polyhedron benchmark
> suite gives and ICE when compiled with gfortran 4.5 using -O3 -mfma4. This ICE
> showed up in gcc 4.5 rev 154969 with the following check in:
> 
> 2009-12-02  Richard Henderson  
> 
> * config/i386/i386.c (ix86_fixup_binary_operands): For FMA4, force
> all operands into registers.

Do we actually need this fixup after all input operands of FMA4 insn were
changed to "nonimmediate operand" in

2009-12-03  Sebastian Pop  
Richard Henderson  

* config/i386/i386-protos.h (ix86_fma4_valid_op_p): Remove.
* config/i386/i386.c (ix86_fma4_valid_op_p): Remove.
* config/i386/i386.md: Do not use ix86_fma4_valid_op_p.
* config/i386/sse.md (fma4_*): Remove alternative with operand 1
matching a memory access.  Do not use ix86_fma4_valid_op_p.
(xop_*): Same.
Do not use ix86_fma4_valid_op_p in FMA4 and XOP splitters.

and

2009-12-07  Sebastian Pop  

* config/i386/sse.md: Remove all FMA4 splitters.
Allow the second operand of FMA4 insns to be a nonimmediate.
Fix comments punctuation.

I'd say that after these commits, 2009-12-02 fixup is not needed anymore and
should be removed.


-- 


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

[Bug fortran/42664] ICE on compilation of polyhedron benchmarks with -mfma4

[harsha dot jagasia at amd dot com]

--- Comment #4 from harsha dot jagasia at amd dot com  2010-01-08 20:49 
---
Created an attachment (id=19513)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19513&action=view)
expand output file generated by -fdump-rtl-all-all


-- 


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

[Bug c/35649] Incorrect printf warning: expect double has float

[dj at redhat dot com]

--- Comment #4 from dj at redhat dot com  2010-01-08 20:51 ---
Still present in 4.5 trunk, also fails for rx-elf-gcc with -m32bit-doubles but
not with -m64bit-doubles.


-- 

dj at redhat dot com changed:

   What|Removed |Added

 CC||dj at redhat dot com
   Last reconfirmed|-00-00 00:00:00 |2010-01-08 20:51:02
   date||


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

[Bug lto/42665] New: Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[jjcogliati-r1 at yahoo dot com]

When using -fwhole-program -flto -fopenmp on a program with gcc-4.5-20100107, I
get an internal compiler exception.  If I remove the -fopenmp, the program
compiles fine.  If I remove the -flto -fwhole-program, the program compiles
fine.

I have only been able to trigger this in a multi-thousand line program
proprietary program, and have not yet figured out a small test case that causes
this.  If you have any hints as to how to create a small test case, I will try
them.  I cannot provide the full program source code.  

Approximate command line:
gfortran -march=native -std=f95 -g -Wall -pedantic -O3 -Wline-truncation
-fopenmp -fbounds-check -fwhole-program -flto -o program lots.o of.o dot.o
files.o
Error:
lto1: internal compiler error: in iterative_hash_expr, at tree.c:6592


Relevant portion of gcc/tree.c:
  /* FALL THROUGH */
default:
  tclass = TREE_CODE_CLASS (code);

  if (tclass == tcc_declaration)
{
  /* DECL's have a unique ID */
  val = iterative_hash_host_wide_int (DECL_UID (t), val);
}
  else
{
  gcc_assert (IS_EXPR_CODE_CLASS (tclass));

  val = iterative_hash_object (code, val);

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jjc/gcc/gcc45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5-20100107/configure --prefix=/home/jjc/gcc/gcc45
--enable-languages=c,c++,fortran,lto,objc --disable-multilib
Thread model: posix
gcc version 4.5.0 20100107 (experimental) (GCC)


-- 
   Summary: Internal compiler exception in with gfortran when using
-fwhole-program -flto -fopenmp
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jjcogliati-r1 at yahoo dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-08 21:10 ---
Can you run it in a debugger and print what 'code' actually is?  Can you
check if removing -g fixes the ICE?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code, lto


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

[Bug fortran/42664] ICE on compilation of polyhedron benchmarks with -mfma4

[harsha dot jagasia at amd dot com]

--- Comment #5 from harsha dot jagasia at amd dot com  2010-01-08 21:21 
---
Created an attachment (id=19514)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19514&action=view)
Proposed Patch removing  2009-12-2 fixup as suggested by Uros

FWIW, this patch passes the reduced test case. I am currently bootstrapping and
recompiling the polyhedron benchmarks.


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[jjcogliati-r1 at yahoo dot com]

--- Comment #2 from jjcogliati-r1 at yahoo dot com  2010-01-08 21:27 ---
(In reply to comment #1)
> Can you run it in a debugger and print what 'code' actually is?  Can you
> check if removing -g fixes the ICE?
> 

The ICE still happens when -g is removed.  I'm working on trying it in a
debugger.


-- 


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

[Bug c++/42355] Segmentation fault

[peter_foelsche at agilent dot com]

--- Comment #13 from peter_foelsche at agilent dot com  2010-01-08 21:37 
---
boost::mpl::sort seems to be known to be a memory hog.
Also on other platforms.
I replaced this with other code.


-- 

peter_foelsche at agilent dot com changed:

   What|Removed |Added

   Severity|normal  |minor


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[jjcogliati-r1 at yahoo dot com]

--- Comment #3 from jjcogliati-r1 at yahoo dot com  2010-01-08 21:38 ---
(In reply to comment #1)
> Can you run it in a debugger and print what 'code' actually is?  Can you
> check if removing -g fixes the ICE?
> 

Code is: 
ERROR_MARK

(gdb) break tree.c:6592
Breakpoint 1 at 0x89a063: file ../../gcc-4.5-20100107/gcc/tree.c, line 6592.
(gdb) run
Starting program:
/home/jjc/gcc/gcc45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto1 -quiet
-dumpbase program -dumpdir ./ -mtune=generic -auxbase-strip /tmp/ccxQqVMb.lto.o
-O3 -Wall -pedantic -Wline-truncation -std=f95 -version -fopenmp -fbounds-check
-fwhole-program @/tmp/cce2vBEb -o program.s
GNU GIMPLE (GCC) version 4.5.0 20100107 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20100107 (experimental), GMP version
4.3.1, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.5.0 20100107 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20100107 (experimental), GMP version
4.3.1, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Breakpoint 1, iterative_hash_expr (t=0x71e96b70, val=154387133)
at ../../gcc-4.5-20100107/gcc/tree.c:6592
6592  gcc_assert (IS_EXPR_CODE_CLASS (tclass));
(gdb) p tclass
$1 = 0 '\000'
(gdb) p code
$2 = ERROR_MARK
(gdb) c
Continuing.
lto1: internal compiler error: in iterative_hash_expr, at tree.c:6592
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Program exited with code 04.


-- 


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

[Bug c/42666] New: xgcc: Internal error: segmentation violation (program cc1)

[norbert dot huebsch at gmx dot de]

Hello, 
I have a QNX Neutrino Operating System with an AMD ATHLON Processor.
And for compiling i use the standard QNX gcc 4.3.3 compiler.
I did the following steps after unzip and tar: 
- ./configure
- ./make

.. and after round about 2 hours I got the following error. 

/root/gcc-4.4.2/host-i386-pc-nto-qnx6.4.1/prev-gcc/xgcc
-B/root/gcc-4.4.2/host-i386-pc-nto-qnx6.4.1/prev-gcc/ -B
/usr/local/i386-pc-nto-qnx6.4.1/bin/ -c  -g -O2 -fomit-frame-pointer -DIN_GCC  
-W -Wall -Wwrite-strings -Wstric
t-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pe
dantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
-DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../
.././gcc/. -I../.././gcc/../include -I./../intl -I../.././gcc/../libcpp/include
-I/usr/include -I../.././gcc/../
libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber   
../.././gcc/c-common.c -o c-common.o
xgcc: Internal error: segmentation violation (program cc1)
Please submit a full bug report.
See  for instructions.
make[3]: *** [c-common.o] Error 1
make[3]: Leaving directory `/root/gcc-4.4.2/host-i386-pc-nto-qnx6.4.1/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/root/gcc-4.4.2'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/root/gcc-4.4.2'
make: *** [all] Error 2

what´s wrong 

thanks for your help


-- 
   Summary: xgcc: Internal error: segmentation violation (program
cc1)
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: norbert dot huebsch at gmx dot de
  GCC host triplet: i386-pc-nto-qnx6.4.1


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[rguenther at suse dot de]

--- Comment #4 from rguenther at suse dot de  2010-01-08 21:41 ---
Subject: Re:  Internal compiler exception in with gfortran
 when using  -fwhole-program -flto -fopenmp

On Fri, 8 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:

> --- Comment #3 from jjcogliati-r1 at yahoo dot com  2010-01-08 21:38 
> ---
> (In reply to comment #1)
> > Can you run it in a debugger and print what 'code' actually is?  Can you
> > check if removing -g fixes the ICE?
> > 
> 
> Code is: 
> ERROR_MARK

Hm, ok.  I guess we need a testcase anyway.  A tarball with all
preprocessed sources is probably enough.  You can also try reducing
the set of files required by performing incremental linking with
-r and omit files one-by-one.

Richard.


-- 


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

[Bug c/42666] xgcc: Internal error: segmentation violation (program cc1)

[norbert dot huebsch at gmx dot de]

--- Comment #1 from norbert dot huebsch at gmx dot de  2010-01-08 21:45 
---
Created an attachment (id=19515)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19515&action=view)
Here is the config.log with my preferences


-- 


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

[Bug target/37454] gcc: unrecognized option '-rdynamic'

[sje at gcc dot gnu dot org]

--- Comment #3 from sje at gcc dot gnu dot org  2010-01-08 21:55 ---
Subject: Bug 37454

Author: sje
Date: Fri Jan  8 21:54:37 2010
New Revision: 155745

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155745
Log:
2010-01-08  Steve Ellcey  

PR target/37454
* configure.ac: Modify -rdynamic check.
* configure: Regenerate.

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


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[jjcogliati-r1 at yahoo dot com]

--- Comment #5 from jjcogliati-r1 at yahoo dot com  2010-01-08 22:28 ---
(In reply to comment #4)
> Subject: Re:  Internal compiler exception in with gfortran
>  when using  -fwhole-program -flto -fopenmp
> 
> On Fri, 8 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
> 
> > --- Comment #3 from jjcogliati-r1 at yahoo dot com  2010-01-08 21:38 
> > ---
> > (In reply to comment #1)
> > > Can you run it in a debugger and print what 'code' actually is?  Can you
> > > check if removing -g fixes the ICE?
> > > 
> > 
> > Code is: 
> > ERROR_MARK
> 
> Hm, ok.  I guess we need a testcase anyway.  A tarball with all
> preprocessed sources is probably enough.  You can also try reducing
> the set of files required by performing incremental linking with
> -r and omit files one-by-one.
> 
> Richard.
> 

(gdb) p *t
$16 = {base = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
user_align = 0, spare = 0, address_space = 0}, common = {base = {
  code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
  used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
  private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
  saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
  lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
  lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
  user_align = 0, spare = 0, address_space = 0}, chain = 0x0, 

if we go up 1 to:
(gdb) up
#1  0x005ee1cc in iterative_hash_gimple_type (type=0x71df3888, 
val=, sccstack=0x7fffda38, sccstate=0x1269440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3711
3711  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
(gdb) p type
$17 = (union tree_node *) 0x71df3888
(gdb) p *type
$18 = {base = {code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0, 
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
user_align = 0, spare = 0, address_space = 0}, common = {base = {
  code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
  used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
  private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
  saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 

Maybe that helps.  If I have inspiration over the weekend I will try to make a
test case on Monday. 


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

[rguenther at suse dot de]

--- Comment #6 from rguenther at suse dot de  2010-01-08 22:45 ---
Subject: Re:  Internal compiler exception in with gfortran
 when using  -fwhole-program -flto -fopenmp

On Fri, 8 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:

> --- Comment #5 from jjcogliati-r1 at yahoo dot com  2010-01-08 22:28 
> ---
> (In reply to comment #4)
> > Subject: Re:  Internal compiler exception in with gfortran
> >  when using  -fwhole-program -flto -fopenmp
> > 
> > On Fri, 8 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
> > 
> > > --- Comment #3 from jjcogliati-r1 at yahoo dot com  2010-01-08 21:38 
> > > ---
> > > (In reply to comment #1)
> > > > Can you run it in a debugger and print what 'code' actually is?  Can you
> > > > check if removing -g fixes the ICE?
> > > > 
> > > 
> > > Code is: 
> > > ERROR_MARK
> > 
> > Hm, ok.  I guess we need a testcase anyway.  A tarball with all
> > preprocessed sources is probably enough.  You can also try reducing
> > the set of files required by performing incremental linking with
> > -r and omit files one-by-one.
> > 
> > Richard.
> > 
> 
> (gdb) p *t
> $16 = {base = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
> addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
> unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
> used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
> private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
> saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
> lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
> lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
> user_align = 0, spare = 0, address_space = 0}, common = {base = {
>   code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
>   addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
>   unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
>   used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
>   private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
>   saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
>   lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
>   lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
>   user_align = 0, spare = 0, address_space = 0}, chain = 0x0, 
> 
> if we go up 1 to:
> (gdb) up
> #1  0x005ee1cc in iterative_hash_gimple_type (type=0x71df3888, 
> val=, sccstack=0x7fffda38, sccstate=0x1269440, 
> sccstate_obstack=0x7fffd9e0)
> at ../../gcc-4.5-20100107/gcc/gimple.c:3711
> 3711  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
> (gdb) p type
> $17 = (union tree_node *) 0x71df3888
> (gdb) p *type
> $18 = {base = {code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0, 
> addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
> unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
> used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
> private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
> saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
> lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
> lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
> user_align = 0, spare = 0, address_space = 0}, common = {base = {
>   code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0, 
>   addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
>   unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
>   used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
>   private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
>   saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
> 
> Maybe that helps.  If I have inspiration over the weekend I will try to make a
> test case on Monday. 

Try

Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 155739)
+++ gcc/gimple.c(working copy)
@@ -3707,8 +3707,10 @@ iterative_hash_gimple_type (tree type, h
   /* For integer types hash the types min/max values and the string flag.  
*/
   if (TREE_CODE (type) == INTEGER_TYPE)
 {
-  v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
-  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
+  if (TYPE_MIN_VALUE (type))
+   v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
+  if (TYPE_MAX_VALUE (type))
+   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
   v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
 }



-- 


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

[Bug target/41885] AVR Rotate patterns do not correctly consider overlap.

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #2 from hutchinsonandy at gcc dot gnu dot org  2010-01-08 23:02 
---
Subject: Bug 41885

Author: hutchinsonandy
Date: Fri Jan  8 23:01:45 2010
New Revision: 155746

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155746
Log:
2010-01-08  Andy Hutchinson  

  PR target/41885
  * avr.md (rotlqi3): Add CONST_INT_P check.
  (rotlhi3): Delete.
  (rotlhi3_8): Delete.
  (rotlsi3): Delete.
  (rotlsi3_8): Delete.
  (rotlsi3_16): Delete.
  (rotlsi3_24): Delete.
  (rotl3): New.
  (*rotw3): New.
  (*rotb3): New.
  *avr.c (avr_rotate_bytes): New function.
  *avr-proto.h (avr_rotate_bytes): New function. 

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr-protos.h
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.md


-- 


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

[Bug bootstrap/42628] [4.5 regression] ICE during bootstrap when compiling several libsupc++ files: original tree changed by fold

[matt at use dot net]

--- Comment #5 from matt at use dot net  2010-01-09 00:22 ---
This also happens with CFLAGS="-O2 -g" and CXXFLAGS="-O2 -g". I'll try
disabling the as-cxx configure option to see if that is the culprit, as odd as
that would be.


-- 


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

[Bug bootstrap/42628] [4.5 regression] ICE during bootstrap when compiling several libsupc++ files: original tree changed by fold

[matt at use dot net]

--- Comment #6 from matt at use dot net  2010-01-09 01:32 ---
Yup, the problem appears to be brought about when configuring with
--enable-build-with-cxx. I tried to work through the c++-compat warnings to try
and figure out which one could be the culprit (if any), but didn't see anything
obvious after an hour.


-- 


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