[Bug bootstrap/43287] [4.5 Regression] Bootstrap fails at stage 1 on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #12 from dominiq at lps dot ens dot fr  2010-03-09 08:08 ---
Bootstrapping all languages minus ADA with the patch in comment #10 succeeded
at revision 157293.

> Needs testing on darwin as well as verification that there
> really isn't any indirection etc. missed (i.e. that (lo_sum ((reg X),
> (symbol_ref "foo"))) is always equivalent to (symbol_ref "foo").

I'll try to some testing in the coming nights, but I am leaving the
"verification ..." to those who really know the details about Darwin.


-- 


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

[Bug bootstrap/43299] [4.5 Regression] Subversion id 157264 breaks powerpc 64-bit bootstraps

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-03-09 08:11 ---
Created an attachment (id=20052)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20052&action=view)
gcc45-pr43299.patch

In the end, at least for the release, I think we want something like this
patch,
which will avoid seeing strange stuff in .debug_loc/.debug_info and various
ICEs in target constant output routines even for targets which don't have
adequate delegitimize_address langhook.

But I'd prefer as many delegitimize_address hooks as possible to be actually
written/enhanced.  Just burying the message about unhandled UNSPEC in -da logs
is not enough to get target maintainer attention I'm afraid, perhaps the
message to stderr would be sufficient.


-- 


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

[Bug rtl-optimization/42216] [4.5 Regression] changes in scheduling regress 464.h264ref 20%

[dominiq at lps dot ens dot fr]

--- Comment #24 from dominiq at lps dot ens dot fr  2010-03-09 08:35 ---
> If you wouldn't mind, please test the attached patch which should be an
> alternative fix for 42220 and avoids the need to set fail_block for some 
> cases.

I cannot test if the patch in comment #23 fixes the regression for SPEC, but a
partial test indicates that it does not reintroduce pr42220 (patch applied on
top of r157293 with the patch from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43287#c10 and a simple update).
More testing during the coming nights).


-- 


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

[Bug bootstrap/43287] [4.5 Regression] Bootstrap fails at stage 1 on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #13 from dominiq at lps dot ens dot fr  2010-03-09 08:49 ---
AFAICT the patch in comment #10 affects only powerpc-apple-darwin*. Could it be
committed now in order to allow the automatic tester 'regress' to start again?


-- 


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

[Bug bootstrap/43287] [4.5 Regression] Bootstrap fails at stage 1 on powerpc-apple-darwin9

[developer at sandoe-acoustics dot co dot uk]

--- Comment #14 from developer at sandoe-acoustics dot co dot uk  
2010-03-09 08:54 ---
(In reply to comment #12)
> Bootstrapping all languages minus ADA with the patch in comment #10 succeeded
> at revision 157293.

at 157294 (minus ada and java) with the patch.
I see the following new 4.5 regressions (possibly unrelated)

FAIL: gcc.dg/vmx/7-01.c  -O3 -g  (internal compiler error)
FAIL: gcc.dg/vmx/7-01.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/vmx/7-01a.c  -O3 -g  (internal compiler error)
FAIL: gcc.dg/vmx/7-01a.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/vmx/fft.c  -O3 -g  (internal compiler error)
FAIL: gcc.dg/vmx/fft.c  -O3 -g  (test for excess errors)

> > Needs testing on darwin as well as verification that there
> > really isn't any indirection etc. missed (i.e. that (lo_sum ((reg X),
> > (symbol_ref "foo"))) is always equivalent to (symbol_ref "foo").
> 
> I'll try to some testing in the coming nights, but I am leaving the
> "verification ..." to those who really know the details about Darwin.

ditto [157304 is building at present] - but, to be sure, this needs someone
familiar with the nitty gritty of macho.


-- 


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

[Bug bootstrap/43276] [4.5 Regression] lto-elf.c:388:10: error: 'EM_SPARC'

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2010-03-09 08:56 
---
Fixing.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|
   |org |
 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-08 15:53:03 |2010-03-09 08:56:28
   date||


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

[Bug bootstrap/43276] [4.5 Regression] lto-elf.c:388:10: error: 'EM_SPARC'

[ebotcazou at gcc dot gnu dot org]

--- Comment #8 from ebotcazou at gcc dot gnu dot org  2010-03-09 09:02 
---
Subject: Bug 43276

Author: ebotcazou
Date: Tue Mar  9 09:01:56 2010
New Revision: 157305

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157305
Log:
PR bootstrap/43276
* lto-elf.c: Define EM_* constants if not already defined.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-elf.c


-- 


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

[Bug bootstrap/43276] [4.5 Regression] lto-elf.c:388:10: error: 'EM_SPARC'

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2010-03-09 09:04 
---
Sorry for this late breakage.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/43287] [4.5 Regression] Bootstrap fails at stage 1 on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #15 from dominiq at lps dot ens dot fr  2010-03-09 09:14 ---
> at 157294 (minus ada and java) with the patch.
> I see the following new 4.5 regressions (possibly unrelated)
>
> FAIL: gcc.dg/vmx/7-01.c  -O3 -g  (internal compiler error)
> FAIL: gcc.dg/vmx/7-01.c  -O3 -g  (test for excess errors)
> FAIL: gcc.dg/vmx/7-01a.c  -O3 -g  (internal compiler error)
> FAIL: gcc.dg/vmx/7-01a.c  -O3 -g  (test for excess errors)
> FAIL: gcc.dg/vmx/fft.c  -O3 -g  (internal compiler error)
> FAIL: gcc.dg/vmx/fft.c  -O3 -g  (test for excess errors)

Minimal options '-O1 -g' for 7-01.c and fft.c, and '-O2 -g' for 7-01a.c giving

[karma] f90/bug% gcc45 -O1 -g
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vmx/7-01.c
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vmx/7-01.c: In function 'haar':
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vmx/7-01.c:36:1: internal compiler
error: in simplify_binary_operation_1, at simplify-rtx.c:2958
[karma] f90/bug% gcc45 -O1 -g
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vmx/fft.c
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vmx/fft.c: In function 'transpose4x4':
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vmx/fft.c:18:1: internal compiler
error: in simplify_binary_operation_1, at simplify-rtx.c:2958


-- 


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

[Bug java/43302] New: [Regression] gcc creates "dummy" resources in object files

[michele at focuseek dot com]

gcj adds a java resource named ".dummy" to most (all?) the object file it
produces. That resource doesn't appear anywhere in the sources.

This is a problem when I try to link an application made from multiple .o
produced by separate gcj invocations: I get the link-time error:

 multiple definition of `java resource .dummy'

Also this is a regression as gcj 4.2.2 didn't add it and thus the linker didn't
complain.

gcc was built with the following options:

../gcc-4.4.3/configure --prefix="/opt/focuseek-build-fsk" \
--program-suffix=-fsk \
--enable-languages=c,c++,java \
--enable-shared --enable-threads \
--enable-__cxa_atexit \
--enable-libgcj-multifile

on a centos 5.4. The md5 for ecj.jar is d7cd6a27c8801e66cbaa964a039ecfdb which,
as of today, is what contrib/download_ecj retrieves.

I'm aware of bug 42143 but I'm not able to say whether this is the same bug or
another one.

I will attach a test case as soon as possible.


-- 
   Summary: [Regression] gcc creates "dummy" resources in object
files
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michele at focuseek dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug java/43302] [Regression] gcc creates "dummy" resources in object files

[michele at focuseek dot com]

--- Comment #1 from michele at focuseek dot com  2010-03-09 09:25 ---
Created an attachment (id=20053)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20053&action=view)
A simple test exhibiting the .dummy resources problem

As I said this works with gcc 4.2.2


-- 


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

[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2010-03-09 09:44 ---
The problem here is that when resolving a polymorphic TBP call, we resolve the
call for each member of the CLASS (i.e. the declared type and all its children,
cf. 'resolve_class_compcall'). In 'check_class_members' we set the correct type
for the passed object. However, this does not work if the passed object is a
component, because the ts we set is overridden when the expr is resolved (e.g.
in resolve_actual_arglist).


-- 


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

[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2010-03-09 09:49 ---
(In reply to comment #2)
> The problem here is that when resolving a polymorphic TBP call, we resolve the
> call for each member of the CLASS (i.e. the declared type and all its 
> children,
> cf. 'resolve_class_compcall').

Paul, since you were the one who implemented this: Could you me remind me why
this is needed at all? Shouldn't it be enough to resolve the call as is, i.e.
just for the base class? Checking the actual arguments for every descendant of
the base class seems unnecessary to me.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org


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

[Bug bootstrap/43287] [4.5 Regression] Bootstrap fails at stage 1 on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #16 from dominiq at lps dot ens dot fr  2010-03-09 10:01 ---
Backtrace of run -maltivec -O1 -g
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vmx/7-01.c:

(gdb) bt
#0  fancy_abort (file=0x81ed14 "../../gcc-4.5-work/gcc/simplify-rtx.c",
line=2958, function=0x9f3c14 "simplify_binary_operation_1") at
../../gcc-4.5-work/gcc/diagnostic.c:763
#1  0x00523314 in simplify_binary_operation (code=, mode=V8HImode, op0=0x4160a178,
op1=0x416bc828) at ../../gcc-4.5-work/gcc/simplify-rtx.c:2958
#2  0x002378c4 in cselib_expand_value_rtx_1 (orig=, evd=0xbfffcba8, max_depth=) at
../../gcc-4.5-work/gcc/cselib.c:1388
#3  0x00237528 in cselib_expand_value_rtx_1 (orig=0x416f5a10, evd=0xbfffcba8,
max_depth=) at
../../gcc-4.5-work/gcc/cselib.c:1286
#4  0x00238220 in cselib_expand_value_rtx_cb (orig=, regs_active=, max_depth=, cb=,
data=) at
../../gcc-4.5-work/gcc/cselib.c:1095
#5  0x007030dc in vt_expand_loc_callback (x=0x416fbccc, regs=0x4181faa4,
max_depth=5, data=0xbfffce78) at ../../gcc-4.5-work/gcc/var-tracking.c:6563
#6  0x00237698 in cselib_expand_value_rtx_1 (orig=0x416fbccc, evd=0xbfffcce8,
max_depth=5) at ../../gcc-4.5-work/gcc/cselib.c:1214
#7  0x00238258 in cselib_dummy_expand_value_rtx_cb (orig=, regs_active=, max_depth=, cb=,
data=) at
../../gcc-4.5-work/gcc/cselib.c:1113
#8  0x007032fc in vt_expand_loc_callback (x=0x4182dc08, regs=0x4181faa4,
max_depth=5, data=0xbfffce78) at ../../gcc-4.5-work/gcc/var-tracking.c:6647
#9  0x002377cc in cselib_expand_value_rtx_1 (orig=0x4182dc08, evd=0xbfffce28,
max_depth=5) at ../../gcc-4.5-work/gcc/cselib.c:1249
#10 0x00238258 in cselib_dummy_expand_value_rtx_cb (orig=, regs_active=, max_depth=, cb=,
data=) at
../../gcc-4.5-work/gcc/cselib.c:1113
#11 0x006f9f1c in vt_expand_loc_dummy (loc=, vars=,
pcur_loc_changed=0xbfffced8 "") at ../../gcc-4.5-work/gcc/var-tracking.c:6718
#12 0x006fa700 in check_changed_vars_3 (slot=, data=0x41513df0) at
../../gcc-4.5-work/gcc/var-tracking.c:7070
#13 0x007c9cac in htab_traverse_noresize (htab=, callback=, info=0x41513df0) at ../../gcc-4.5-work/libiberty/hashtab.c:753
#14 0x00700064 in emit_notes_for_changes (insn=0x416f7264,
where=EMIT_NOTE_AFTER_INSN) at ../../gcc-4.5-work/gcc/var-tracking.c:7107
#15 0x007064d8 in vt_emit_notes () at
../../gcc-4.5-work/gcc/var-tracking.c:7507
#16 0x007095cc in variable_tracking_main () at
../../gcc-4.5-work/gcc/var-tracking.c:8126
#17 0x0047edf0 in execute_one_pass (pass=0xa8a358) at
../../gcc-4.5-work/gcc/passes.c:1567
#18 0x0047f124 in execute_pass_list (pass=0xa8a358) at
../../gcc-4.5-work/gcc/passes.c:1622
#19 execute_pass_list (pass=0xa76b70) at ../../gcc-4.5-work/gcc/passes.c:1624
#20 execute_pass_list (pass=0xa76b3c) at ../../gcc-4.5-work/gcc/passes.c:1624
#21 0x005ac81c in tree_rest_of_compilation (fndecl=0x416a2c80) at
../../gcc-4.5-work/gcc/tree-optimize.c:413
#22 0x00752054 in cgraph_expand_function (node=0x416bd1a0) at
../../gcc-4.5-work/gcc/cgraphunit.c:1545
#23 0x00754f64 in cgraph_optimize () at
../../gcc-4.5-work/gcc/cgraphunit.c:1624
#24 0x0075537c in cgraph_finalize_compilation_unit () at
../../gcc-4.5-work/gcc/cgraphunit.c:1093
#25 0x000208e4 in c_write_global_declarations () at
../../gcc-4.5-work/gcc/c-decl.c:9510
#26 0x00545328 in toplev_main (argc=5, argv=Cannot access memory at address
0x1c
) at ../../gcc-4.5-work/gcc/toplev.c:1065
#27 0x27d4 in start ()


-- 


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

[Bug bootstrap/43299] [4.5 Regression] Subversion id 157264 breaks powerpc 64-bit bootstraps

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-03-09 10:13 ---
Distilled testcase -g -O2 -m64:
extern void *emit_insn (void *);
extern void *gen_load_locked_si (void *, void *);
extern void *gen_load_locked_di (void *, void *);

void
emit_load_locked (int mode, void *reg, void *mem)
{
  void * (*fn) (void *, void *) = ((void *)0);
  if (mode == 9)
fn = gen_load_locked_si;
  else if (mode == 10)
fn = gen_load_locked_di;
  emit_insn (fn (reg, mem));
}

The problem here is we have:
(insn:TI 8 38 120 5 pr43299.i:12 (set (reg/v/f:DI 9 9 [orig:119 fn ] [119])
(mem/u/c:DI (plus:DI (reg:DI 2 2)
(const:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC1") [flags 0x2])
] 49))) [5 S8 A8])) 357 {*movdi_internal64}
(expr_list:REG_EQUAL (symbol_ref:DI ("gen_load_locked_di") [flags 0x41]  )
(nil)))

(which is correctly tracked as following):
(note 120 8 73 5 (var_location fn (expr_list:REG_DEP_TRUE (mem/u/c:DI
(symbol_ref/u:DI ("*.LC1") [flags 0x2]) [5 S8 A8])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)

but then the incoming TOC register is spilled:
(insn 24 23 22 4 pr43299.i:13 (set (mem:DI (plus:DI (reg/f:DI 1 1)
(const_int 40 [0x28])) [0 S8 A8])
(reg:DI 2 2)) 357 {*movdi_internal64} (expr_list:REG_DEAD (reg:DI 2 2)
(nil)))
and some new value is loaded into r2.  As fn at this point is a MEM with
address
PLUS (value incoming_r2) (const (unspec)) and (value incoming_r2) after the
load of some other value into r2 no longer holds that value, but [r1 + 40]
does, we end up with:
(note 121 76 77 5 (var_location fn (expr_list:REG_DEP_TRUE (mem/u/c:DI (plus:DI
(mem:DI (plus:DI (reg/f:DI 1 1)
(const_int 40 [0x28])) [0 S8 A8])
(const:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC1") [flags 0x2])
] 49))) [5 S8 A8])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)

and rs6000_delegitimize_address understandably can't do anything there, as it
doesn't know [r1 + 40] holds the current function's TOC register value.

Obviously the patch I've attached earlier, without the ENABLE_CHECKING hunk, is
going to "fix" this, but at the expense of not providing good debug info.

As we can't delegitimize such stuff so late, I'm afraid we need to either
attempt to delegitimize MEMs (at least MEM_READONLY_Ps) early, during
vt_initialize, or use REG_EQUIV notes.


-- 


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

[Bug fortran/43303] New: ICE with C_ASSOCIATED

[dennis dot wassel at googlemail dot com]

It seems something broke C_ASSOCIATED:

PROGRAM c_assoc
  use iso_c_binding
  type(c_ptr) :: x
  PRINT *, C_ASSOCIATED(x)
END PROGRAM c_assoc

breaks here for me:

Starting program: /localdata/libexec/gcc/i686-pc-linux-gnu/4.4.3/f951 foo.f90
-quiet -dumpbase foo.f90 -mtune=generic -march=athlon64 -auxbase foo -version
-fintrinsic-modules-path /localdata/lib/gcc/i686-pc-linux-gnu/4.4.3/finclude -o
/tmp/ccEGPG6g.s
GNU Fortran (GCC) Version 4.4.3 (i686-pc-linux-gnu)
kompiliert von GNU-C-Version 4.4.3, GMP-Version 4.3.1, MPFR-Version
2.4.2.
GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Program received signal SIGSEGV, Segmentation fault.
0x08135756 in gfc_conv_expr_reference (se=0xbfffed78, expr=0x8906ce8) at
../../gcc-4.4.3/gcc/fortran/trans-expr.c:3960
3960   && expr->value.function.esym->result->attr.pointer
(gdb) bt
#0  0x08135756 in gfc_conv_expr_reference (se=0xbfffed78, expr=0x8906ce8) at
../../gcc-4.4.3/gcc/fortran/trans-expr.c:3960
#1  0x08144681 in gfc_trans_transfer (code=0x8906d58) at
../../gcc-4.4.3/gcc/fortran/trans-io.c:2223
#2  0x0810db28 in gfc_trans_code (code=0x8906d58) at
../../gcc-4.4.3/gcc/fortran/trans.c:1207
#3  0x0814956f in build_dt (function=, code=) at ../../gcc-4.4.3/gcc/fortran/trans-io.c:1803
#4  0x0810db58 in gfc_trans_code (code=0x8906e30) at
../../gcc-4.4.3/gcc/fortran/trans.c:1179
#5  0x0812d27d in gfc_generate_function_code (ns=0x88ff070) at
../../gcc-4.4.3/gcc/fortran/trans-decl.c:3886
#6  0x080c5215 in gfc_parse_file () at ../../gcc-4.4.3/gcc/fortran/parse.c:3851
#7  0x0810a18d in gfc_be_parse_file (set_yydebug=0) at
../../gcc-4.4.3/gcc/fortran/f95-lang.c:236
#8  0x0833b18a in compile_file (argc=14, argv=0xb304) at
../../gcc-4.4.3/gcc/toplev.c:970
#9  do_compile (argc=14, argv=0xb304) at ../../gcc-4.4.3/gcc/toplev.c:2197
#10 toplev_main (argc=14, argv=0xb304) at ../../gcc-4.4.3/gcc/toplev.c:2229
#11 0x0815c2bb in main (argc=14, argv=0xb304) at
../../gcc-4.4.3/gcc/main.c:35


-- 
   Summary: ICE with C_ASSOCIATED
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dennis dot wassel at googlemail dot com
  GCC host triplet: i686-pc-linux-gnu


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

[Bug bootstrap/43307] New: ICE in assign_temp()

[pluto at agmk dot net]

hi,

during bootstrap multilib gcc with i386.h:#define STRICT_ALIGNMENT=1
xgcc ICEs in assign_temp().


(...)
make[5]: Entering directory
`/home/users/pluto/rpm/BUILD/gcc-4.4.3/builddir/x86_64-pld-linux/32/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/home/users/pluto/rpm/BUILD/gcc-4.4.3/builddir/./gcc/xgcc \
-B/home/users/pluto/rpm/BUILD/gcc-4.4.3/builddir/./gcc/ \
-B/usr/x86_64-pld-linux/bin/ -B/usr/x86_64-pld-linux/lib/ \
-isystem /usr/x86_64-pld-linux/include -isystem
/usr/x86_64-pld-linux/sys-include \
-g -O2 -march=x86-64 -gdwarf-2 -g2 -m32 -O2  -g -O2 -march=x86-64 -gdwarf-2 -g2
\
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes \
-Wcast-qual -Wold-style-definition  -isystem ./include  -fPIC \
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED \
-I. -I. -I../../.././gcc -I../../../../libgcc -I../../../../libgcc/. \
-I../../../../libgcc/../gcc -I../../../../libgcc/../include
-I../../../../libgcc/config/libbid \
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS \
-o _powitf2.o -MT _powitf2.o -MD -MP -MF _powitf2.dep -DL_powitf2 -c
../../../../libgcc/../gcc/libgcc2.c \
-fvisibility=hidden -DHIDE_EXPORTS

../../../../libgcc/../gcc/libgcc2.c: In function '__powitf2':
../../../../libgcc/../gcc/libgcc2.c:1734: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


(gdb) bt
#0  0x005be683 in assign_temp ()
#1  0x005638ad in emit_push_insn ()
#2  0x004bf3ce in emit_library_call_value_1 ()
#3  0x004c012b in emit_library_call_value ()
#4  0x00661d4e in expand_binop ()
#5  0x00553712 in expand_mult ()
#6  0x00571d69 in expand_expr_real_1 ()
#7  0x0056bf42 in expand_expr_real ()
#8  0x005660a3 in store_expr ()
#9  0x00565585 in expand_assignment ()
#10 0x00573589 in expand_expr_real_1 ()
#11 0x0056bf42 in expand_expr_real ()
#12 0x0074327d in expand_expr ()
#13 0x00746018 in expand_expr_stmt ()
#14 0x00bafea1 in expand_gimple_basic_block ()
#15 0x00bb0e61 in gimple_expand_cfg ()
#16 0x0067a6f4 in execute_one_pass ()
#17 0x0067a898 in execute_pass_list ()
#18 0x007a698e in tree_rest_of_compilation ()
#19 0x00933ede in cgraph_expand_function ()
#20 0x009340a1 in cgraph_expand_all_functions ()
#21 0x00934652 in cgraph_optimize ()
#22 0x0041a8e2 in c_write_global_declarations ()
#23 0x00751f20 in compile_file ()
#24 0x00753b53 in do_compile ()
#25 0x00753bc2 in toplev_main ()
#26 0x00483724 in main ()

$ /home/users/pluto/rpm/BUILD/gcc-4.4.3/builddir/./gcc/xgcc -v
Using built-in specs.
Target: x86_64-pld-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info
--mandir=/usr/share/man --x-libraries=/usr/lib64 --enable-checking=release
--enable-shared --enable-threads=posix --enable-linux-futex
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java --enable-libgomp
--enable-libmudflap --enable-c99 --enable-long-long --enable-decimal-float=yes
--enable-multilib --enable-nls --disable-werror --disable-cld --with-gnu-as
--with-gnu-ld --with-demangler-in-ld --with-system-zlib --with-slibdir=/lib64
--without-system-libunwind --enable-cmath --with-long-double-128
--with-gxx-include-dir=/usr/include/c++/4.4.3 --disable-libstdcxx-pch
--enable-__cxa_atexit --enable-libstdcxx-allocator=new
--enable-libjava-multilib=no --disable-gconf-peer --enable-java-awt=xlib,gtk
--enable-libgcj --enable-libgcj-multifile --enable-libgcj-database
--enable-gtk-cairo --enable-jni --enable-xmlj --enable-bootstrap
--with-pkgversion=PLD-Linux --with-bugurl=http://bugs.pld-linux.org
x86_64-pld-linux
Thread model: posix
gcc version 4.4.3 20100205 (release) (PLD-Linux)


-- 
   Summary: ICE in assign_temp()
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
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=43307

[Bug target/43305] [4.4/4.5 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()

[zsojka at seznam dot cz]

--- Comment #2 from zsojka at seznam dot cz  2010-03-09 15:19 ---
I don't have 4.3 (or older) builds with enabled checking available. But without
checking, the code below prints "0.00" for 4.4/4.5 and "6.00" for 4.3
and older (4.2.4, 4.1.2, 3.3.6, 3.4.6).

Command line:
gcc -Os -ffast-math main.c -lm && ./a.out
--- main.c --
extern int ilogbl(long double);
extern int printf(const char *format, ...);

__attribute__((noinline, noclone))
int foo(long double x) { return ilogbl(x); }
int main() { printf("%f\n", (float)foo(100)); }
-

In 4.4/4.5 without checking, foo() is reduced to:
xorl%eax, %eax
ret
while in 4.3/4.2/4.1, it is:
jmp ilogbl


-- 

zsojka at seznam dot cz changed:

   What|Removed |Added

   Keywords||ice-checking, ice-on-valid-
   ||code, wrong-code
Summary|ICE: in emit_unop_insn, at  |[4.4/4.5 Regression] ICE: in
   |optabs.c:3838 with -Os -|emit_unop_insn, at
   |ffast-math and ilogbl() |optabs.c:3838 with -Os -
   ||ffast-math and ilogbl()


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

[Bug fortran/43303] ICE with C_ASSOCIATED

[dennis dot wassel at googlemail dot com]

--- Comment #1 from dennis dot wassel at googlemail dot com  2010-03-09 
10:30 ---
This looks like a 4.4.2 -> 4.4.3 regression.
It worls with 4.3.{2,3,4} and 4.4.2


-- 


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

[Bug bootstrap/43299] [4.5 Regression] Subversion id 157264 breaks powerpc 64-bit bootstraps

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-03-09 11:49 ---
Created an attachment (id=20054)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20054&action=view)
gcc45-pr43299.patch

Untested patch that fixes this.


-- 


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

[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)

[dominiq at lps dot ens dot fr]

--- Comment #9 from dominiq at lps dot ens dot fr  2010-03-09 15:20 ---
For the record, the patch in comment #5 won't apply on fortran-dev (no
class_try in the branch).


-- 


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

[Bug target/32219] optimizer causes wrong code in pic/hidden/weak symbol checking.

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-03-09 12:39 
---
Well, simply re-ordering the visibility and the weak check in
varasm.c:default_binds_local_p_1 should do the trick.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug bootstrap/43287] [4.5 Regression] Bootstrap fails at stage 1 on powerpc-apple-darwin9

[jakub at gcc dot gnu dot org]

--- Comment #17 from jakub at gcc dot gnu dot org  2010-03-09 12:22 ---
The vmx/{fft,7-01{,a}}.c failures are tracked in PR43304.


-- 


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

[Bug debug/43304] [4.5 Regression] ICE on vmx/fft.c and vmx/7-01{,a}.c

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-09 12:21:18
   date||
   Target Milestone|--- |4.5.0


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

[Bug target/43297] [4.4 regression] -O2 -fPIC breaks htmlnorm.c

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-09 12:30 ---
Please test a more recent version from the 4.4 branch (and trunk if possible).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Known to fail||4.4.1
  Known to work||4.3.3
   Target Milestone|--- |4.4.4


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

[Bug tree-optimization/43306] New: [4.5 Regression] ICE: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:713 with -O1 -fstrict-overflow -fgraphite-identity

[zsojka at seznam dot cz]

Command line:
gcc -O1 -fstrict-overflow -fgraphite-identity testcase.c

-- testcase.c --
void foo(int x[])
{
  int i, j;
  for (i = 0; i < 2; i++)
for (j = 0; j < 2; j++)
  x[i] = x[i*j];
}

(almost the same as testsuite/gcc.dg/tree-ssa/pr34635.c)

Tested revisions:
trunk r157292 - crash
trunk r156999 - crash
trunk r153685 - crash
4.4 r157120 - OK

Output:
$ /mnt/svn/gcc-trunk/binary-156999-lto/bin/gcc -O1 -fstrict-overflow
-fgraphite-identity testcase.c
testcase.c: In function 'foo':
testcase.c:1:6: internal compiler error: in scan_tree_for_params_right_scev, at
graphite-sese-to-poly.c:713


-- 
   Summary: [4.5 Regression] ICE: in
scan_tree_for_params_right_scev, at graphite-sese-to-
poly.c:713 with -O1 -fstrict-overflow -fgraphite-
identity
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz


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

[Bug target/43305] [4.4/4.5 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()

[zsojka at seznam dot cz]

--- Comment #3 from zsojka at seznam dot cz  2010-03-09 15:23 ---
Created an attachment (id=20058)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20058&action=view)
more readable testcase for comment #2


-- 


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

[Bug middle-end/42181] [4.5 Regression][graphite] -fgraphite-identity miscompiles air.f90

[dominiq at lps dot ens dot fr]

--- Comment #22 from dominiq at lps dot ens dot fr  2010-03-09 13:32 ---
The following variant of spectop.f90 is miscompiled with '-fgraphite-identity
-O3':

  SUBROUTINE SPECTOP(Dr,N)
  IMPLICIT REAL*8(A-H,o-Z)
  DIMENSION d1(0:32,0:32) , Dr(0:32,0:32) , x(0:32)
  REAL*8 Dr
!
! PROGRAM TO COMPUTE THE CHEBYSHEV SPECTRAL OPERATOR
!
  ang = DBLE(1)
  s = DBLE(6)
  o = DBLE(1)
  t = DBLE(2)
  pi = t*DASIN(ang)
  DO i = 0 , N
 x(i) = DCOS(pi*DBLE(i)/DBLE(N))
  ENDDO
!
! IF J=K
!
  DO j = 1 , N - 1
 d1(j,j) = -x(j)/(t*(o-x(j)**2))
  ENDDO
  d1(0,0) = (t*DBLE(N)**2+o)/s
  d1(N,N) = -d1(0,0)
!
! IF J.NE.K
!
  fctr = -t
  DO j = 1 , N-1
 d1(0,j) = fctr/(x(0)-x(j))
 fctr = -fctr
  ENDDO
  d1(0,N) = fctr/(t*(x(0)-x(N)))
  fctr1 = -1.0D0
  DO k = 1 , N-1
 d1(k,0) = fctr1/(t*(x(k)-x(0)))
 fctr = -fctr1
 DO j = 1 , N-1
if (j.ne.k) d1(k,j) = fctr/(x(k)-x(j))
fctr = -fctr
 ENDDO
 d1(k,N) = fctr/(t*(x(k)-x(N)))
 fctr1 = -fctr1
  ENDDO
  d1(N,0) = fctr1/(x(N)-x(0))
  fctr = -t*fctr1
  DO j = 1 , N-1
 d1(N,j) = fctr/(x(N)-x(j))
 fctr = -fctr
  ENDDO
  DO k = 0 , N
 DO j = 0 , N
Dr(k,j) = d1(N-k,N-j)
 ENDDO
  ENDDO
  CONTINUE
  END

but is correctly compiled if 

 DO j = 1 , N-1
if (j.ne.k) d1(k,j) = fctr/(x(k)-x(j))
fctr = -fctr
 ENDDO

is replaced with

 DO j = 1 , k-1
d1(k,j) = fctr/(x(k)-x(j))
fctr = -fctr
 ENDDO
 fctr = -fctr
 DO j = k+1 , N-1
d1(k,j) = fctr/(x(k)-x(j))
fctr = -fctr
 ENDDO


-- 


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

[Bug debug/43304] [4.5 Regression] ICE on vmx/fft.c and vmx/7-01{,a}.c

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-03-09 13:40 ---
Created an attachment (id=20057)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20057&action=view)
gcc45-pr43304.patch

Sorry, that's because I've attached a different patch (one for PR43299).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20055|0   |1
is obsolete||


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

[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2010-03-09 11:33 ---
(In reply to comment #3)

> 
> Paul, since you were the one who implemented this: Could you me remind me why
> this is needed at all? Shouldn't it be enough to resolve the call as is, i.e.
> just for the base class? Checking the actual arguments for every descendant of
> the base class seems unnecessary to me.
> 
Dear Janus,

I believe that it is not necessary. The code reuses the original
resolve_compcall for class hierarchies in order to get the specific instance of
the procedure for the given class member.  You will note that resolution for
each class members is foregone in the case of subroutines. Perhaps the most
straightforward thing to do would be to add a further static boolean flag that
signals that the derived type is the declared type?

I have just updated my tree to take the fixes in that you mention below. I'll
try to check out what I say later but don wait for me - the painkillers that I
am taking after my operation are leaving me very prone to nodding off to sleep.

Paul


-- 


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

[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2010-03-09 13:09 ---
Created an attachment (id=20056)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20056&action=view)
Fix for the PR

This is just now regtesting.  I believe that it is OK, since it works for
gfortran.dg/class* and gfortran.dg/select* :-)

If all appears to be well with the regtest and I do not hear back from you, I
will commit the patch to trunk tonight.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug debug/43304] [4.5 Regression] ICE on vmx/fft.c and vmx/7-01{,a}.c

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-03-09 12:21 ---
Created an attachment (id=20055)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20055&action=view)
gcc45-pr43304.patch

Fix.


-- 


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

[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)

[sfilippone at uniroma2 dot it]

--- Comment #8 from sfilippone at uniroma2 dot it  2010-03-09 14:14 ---
(In reply to comment #6)
> > If all appears to be well with the regtest and I do not hear back from you, 
> > I
> > will commit the patch to trunk tonight.
> 
> Confidence before the fall and all that.
> 
> The patch clobbers dynamic_dispatch_4.f03.  Remember it Salvatore?
> 
Ah, yes, how nice to see old friends again :-) 

> OK, back to the drawing board!
> 
> Paul
> 

Good luck 
Salvatore
.who would obviously like to see the segfault 42274 in the -dev branch
solved, but knows better than to ask forcefully during regression-only fix
frenzy.. 


-- 


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

[Bug debug/43304] [4.5 Regression] ICE on vmx/fft.c and vmx/7-01{,a}.c

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2010-03-09 13:25 ---
After a simple update the patch in comment #1 does not fix the failures (BTW
nor the patch inhttp://gcc.gnu.org/bugzilla/attachment.cgi?id=20054&action=view
).


-- 


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

[Bug bootstrap/43307] ICE in assign_temp()

[pluto at agmk dot net]

--- Comment #1 from pluto at agmk dot net  2010-03-09 15:31 ---
detailed backtrace:

#0  0x005be683 in assign_temp (type_or_decl=0x0, keep=0,
memory_required=1, dont_promote=1) at ../../gcc/function.c:889
#1  0x005638ad in emit_push_insn (x=0x709a2400, mode=TFmode,
type=0x0, size=0x77eb9570, align=32, partial=0, reg=0x0,
extra=0, args_addr=0x77ebb880, args_so_far=0x77eb9670,
reg_parm_stack_space=0, alignment_pad=0x77eb9470)
at ../../gcc/expr.c:3758
#2  0x004bf3ce in emit_library_call_value_1 (retval=1,
orgfun=0x709a2a80, value=0x0, fn_type=LCT_CONST, outmode=TFmode, nargs=3,
p=0x7fffc460) at ../../gcc/calls.c:3701
#3  0x004c012b in emit_library_call_value (orgfun=0x709a2a80,
value=0x0, fn_type=LCT_CONST, outmode=TFmode, nargs=2)
at ../../gcc/calls.c:3973
#4  0x00661d4e in expand_binop (mode=TFmode, binoptab=0x1142ca0,
op0=0x709a2400, op1=0x709a2400, target=0x709a2400,
unsignedp=0, methods=OPTAB_LIB_WIDEN) at ../../gcc/optabs.c:2167
#5  0x00553712 in expand_mult (mode=TFmode, op0=0x709a2400,
op1=0x709a2400, target=0x709a2400, unsignedp=0)
at ../../gcc/expmed.c:3173
#6  0x00571d69 in expand_expr_real_1 (exp=0x709a5140,
target=0x709a2400, tmode=TFmode, modifier=EXPAND_NORMAL,
alt_rtl=0x7fffcf40) at ../../gcc/expr.c:8770
#7  0x0056bf42 in expand_expr_real (exp=0x709a5140,
target=0x709a2400, tmode=TFmode, modifier=EXPAND_NORMAL,
alt_rtl=0x7fffcf40) at ../../gcc/expr.c:7125
#8  0x005660a3 in store_expr (exp=0x709a5140,
target=0x709a2400, call_param_p=0, nontemporal=0 '\000')
at ../../gcc/expr.c:4611
#9  0x00565585 in expand_assignment (to=0x70983f30,
from=0x709a5140, nontemporal=0 '\000') at ../../gcc/expr.c:4395
#10 0x00573589 in expand_expr_real_1 (exp=0x709a5180, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/expr.c:9251
#11 0x0056bf42 in expand_expr_real (exp=0x709a5180,
target=0x77eb9470, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/expr.c:7125
#12 0x0074327d in expand_expr (exp=0x709a5180,
target=0x77eb9470, mode=VOIDmode, modifier=EXPAND_NORMAL)
at ../../gcc/expr.h:539
#13 0x00746018 in expand_expr_stmt (exp=0x709a5180) at
../../gcc/stmt.c:1352
#14 0x00bafea1 in expand_gimple_basic_block (bb=0x7099af60) at
../../gcc/cfgexpand.c:1987
(...)


-- 


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

[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2010-03-09 13:34 ---

> If all appears to be well with the regtest and I do not hear back from you, I
> will commit the patch to trunk tonight.

Confidence before the fall and all that.

The patch clobbers dynamic_dispatch_4.f03.  Remember it Salvatore?

OK, back to the drawing board!

Paul


-- 


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

[Bug debug/42959] g++ does not emit DW_AT_default_value

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-09 14:07:28
   date||


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

[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

[burnus at gcc dot gnu dot org]

--- Comment #13 from burnus at gcc dot gnu dot org  2010-03-09 15:36 ---
(In reply to comment #11)
> Regarding the additional test cases given here:
> http://gcc.gnu.org/ml/fortran/2010-03/msg00037.html
> 
> I do believe that gfortran has this correct. [...]

I believe otherwise and thus think a follow up patch is needed, which covers
the related but different issues, cf.
http://gcc.gnu.org/ml/fortran/2010-03/msg00046.html

(I think the patch in for this PR (comment 10) is fine and thus I approved it.)

Do you plan to backport the patch to 4.4? (Probably not to 4.3, I'd guess.)


-- 


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

[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2010-03-09 14:41 
---
Subject: Bug 43265

Author: jvdelisle
Date: Tue Mar  9 14:41:17 2010
New Revision: 157310

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157310
Log:
2010-03-09  Jerry DeLisle  

PR libfortran/43265
* io/read.c: Include fbuf.h and unix.h to enable lower level I/O for
read_x. (read_x): Replace the use of read_sf with equivalent lower
level
I/O, eliminating unneeded code and handling EOF and EOR conditions.
* io/io.h: Revise prototype for read_sf.
* io/transfer.c (read_sf): Delete no_error parameter and all uses of
it.
(read_block_form): Likewise.
(next_record_r): Delete wrong code call to hit_eof.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/read.c
trunk/libgfortran/io/transfer.c


-- 


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

[Bug rtl-optimization/43305] New: ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()

[zsojka at seznam dot cz]

Command line:
gcc -Os -ffast-math testcase.c
or
gcc -Os -fno-math-errno -funsafe-math-optimizations testcase.c
crashes with -m32 as well

 testcase.c 
extern int ilogbl(long double);
int foo(long double x)
{
  return ilogbl(x);
}

(reduced from testsuite/gcc.dg/builtins-38.c)

Tested revisions:
trunk r157161 - crash
trunk r153685 - crash
4.4 r157120 - crash (checking)
4.4 r155365 - crash (release checking)

Output:
$ /mnt/svn/gcc-trunk/binary-157161/bin/gcc -Os -ffast-math testcase.c
testcase.c: In function 'foo':
testcase.c:4:3: internal compiler error: in emit_unop_insn, at optabs.c:3838


-- 
   Summary: ICE: in emit_unop_insn, at optabs.c:3838 with -Os -
ffast-math and ilogbl()
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86(_64)-pc-linux-gnu


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

[Bug rtl-optimization/42216] [4.5 Regression] changes in scheduling regress 464.h264ref 20%

[rguenther at suse dot de]

--- Comment #25 from rguenther at suse dot de  2010-03-09 10:31 ---
Subject: Re:  [4.5 Regression] changes in scheduling
 regress 464.h264ref 20%

On Mon, 8 Mar 2010, bernds_cb1 at t-online dot de wrote:

> --- Comment #23 from bernds_cb1 at t-online dot de  2010-03-08 23:04 
> ---
> Created an attachment (id=20048)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20048&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20048&action=view)
> Alternative fix for 42220
> 
> If you wouldn't mind, please test the attached patch which should be an
> alternative fix for 42220 and avoids the need to set fail_block for some 
> cases.

The patch fixes the regression for me.

Thanks,
Richard.


-- 


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

[Bug fortran/43303] [4.4/4.5 Regression] ICE with C_ASSOCIATED

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-03-09 10:51 ---
Confirmed. Caused by the fix for PR 41777.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|i686-pc-linux-gnu   |
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2010-03-09 10:51:27
   date||
Summary|ICE with C_ASSOCIATED   |[4.4/4.5 Regression] ICE
   ||with C_ASSOCIATED
   Target Milestone|--- |4.4.4


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

[Bug fortran/43291] [4.5 regression] [OOP] Type mismatch in argument; passed CLASS(t1) to CLASS(t2)

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2010-03-09 13:46 ---
(In reply to comment #6)

> The patch clobbers dynamic_dispatch_4.f03.  Remember it Salvatore?

I should have said that this is for -O1 and higher.

/svn/trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_4.f03: In function
‘getit’:
/svn/trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_4.f03:79:0: error:
statement makes a memory store, but has no VDEFS
a_3.$vptr = D.1823_2;
/svn/trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_4.f03:79:0: internal
compiler error: verify_ssa failed

which means a whole lot to me!

Paul


-- 


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

[Bug target/43305] [4.4/4.5 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-03-09 15:49 ---
Confirmed.  Introduced by Honza with the optimize_insn_for_size_p () changes.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-09 15:49:38
   date||
   Target Milestone|--- |4.4.4


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

[Bug fortran/43303] [4.4/4.5 Regression] ICE with C_ASSOCIATED

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-03-09 12:48 ---
Patch:

diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 5370f0d..8aa57b6 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -4542,6 +4542,8 @@ get_iso_c_sym (gfc_symbol *old_sym, char *new_name,
   new_symtree->n.sym->module = gfc_get_string (old_sym->module);
   new_symtree->n.sym->from_intmod = old_sym->from_intmod;
   new_symtree->n.sym->intmod_sym_id = old_sym->intmod_sym_id;
+  if (old_sym->attr.function)
+new_symtree->n.sym->result = new_symtree->n.sym;
   /* Build the formal arg list.  */
   build_formal_args (new_symtree->n.sym, old_sym, add_optional_arg);


-- 


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

[Bug debug/43304] [4.5 Regression] ICE on vmx/fft.c and vmx/7-01{,a}.c

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2010-03-09 14:54 ---
> that's because I've attached a different patch

The patch in comment #3 fixes the failures in gcc.dg/vmx/* (more tests
tonight).


-- 


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

[Bug other/43295] zlib: two C++ member functions could be marked const

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2010-03-09 10:34 ---
besides which, making it const would allow:

void bork_the_stream(const izstream& i)
{
::gzclose(i.fp());
}

which doesn't help anyone.  cppcheck is a very simplistic pattern matcher, in
this case it's wrong IMHO, that it could be const does not mean _should_ be
const.


-- 


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

[Bug middle-end/34668] [4.3 Regression] ICE in find_compatible_field with -combine

[bmei at broadcom dot com]

--- Comment #12 from bmei at broadcom dot com  2010-03-09 14:20 ---
It seems that this bug still fails on my build:

~/work/install-x86/bin/gcc 
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.dg/pr34668-1.c
--combine -O2
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.dg/pr34668-2.c
-S -o pr34668-1.s

/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.dg/pr34668-2.c:
In function 'set_conv_libfunc':
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.dg/pr34668-2.c:5:15:
error: type mismatch in array reference
struct optab

struct optab

# .MEM_3 = VDEF <.MEM_1(D)>
optab_table[0].code = 57005;

/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.dg/pr34668-2.c:5:15:
internal compiler error: verify_stmts failed
...

My build is revision 143368, target x86_64-unknown-linux-gnu. 
../trunk/configure --prefix=/home/bmei/work/install-x86
--with-mpfr=/projects/firepath/tools/work/bmei/packages/mpfr/2.4.1/x86-64
--with-gmp=/projects/firepath/tools/work/bmei/packages/gmp/4.3.0/x86-64
--with-mpc=/projects/firepath/tools/work/bmei/packages/mpc/0.8.1/x86-64
--enable-languages=c,c++ --disable-bootstrap : (reconfigured)
../trunk/configure --prefix=/home/bmei/work/install-x86
--with-mpfr=/projects/firepath/tools/work/bmei/packages/mpfr/2.4.1/x86-64
--with-gmp=/projects/firepath/tools/work/bmei/packages/gmp/4.3.0/x86-64
--with-mpc=/projects/firepath/tools/work/bmei/packages/mpc/0.8.1/x86-64
--enable-languages=c --disable-bootstrap : (reconfigured) ../trunk/configure
--prefix=/home/bmei/work/install-x86
--with-mpfr=/projects/firepath/tools/work/bmei/packages/mpfr/2.4.1/x86-64
--with-gmp=/projects/firepath/tools/work/bmei/packages/gmp/4.3.0/x86-64
--with-mpc=/projects/firepath/tools/work/bmei/packages/mpc/0.8.1/x86-64
--disable-bootstrap CC='gcc -static' CFLAGS='-g -O0' --enable-languages=c
--no-create --no-recursion


-- 

bmei at broadcom dot com changed:

   What|Removed |Added

 CC||bmei at broadcom dot com


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

[Bug target/43294] [4.5 Regression] Error: junk at end of line, first unrecognized character is `@'

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Error: junk at end of line, |[4.5 Regression] Error: junk
   |first unrecognized character|at end of line, first
   |is `@'  |unrecognized character is
   ||`@'
   Target Milestone|--- |4.5.0


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

[Bug target/43305] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-03-09 15:01 ---
emit_unop_insn doesn't allow the expansion to fail, but ilogbxf2 has FAIL if
-Os.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|rtl-optimization|target


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

[Bug debug/43304] New: [4.5 Regression] ICE on vmx/fft.c and vmx/7-01{,a}.c

[jakub at gcc dot gnu dot org]

Tracking http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43287#c14 here.
FAIL: gcc.dg/vmx/7-01.c  -O3 -g  (internal compiler error)
FAIL: gcc.dg/vmx/7-01.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/vmx/7-01a.c  -O3 -g  (internal compiler error)
FAIL: gcc.dg/vmx/7-01a.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/vmx/fft.c  -O3 -g  (internal compiler error)
FAIL: gcc.dg/vmx/fft.c  -O3 -g  (test for excess errors)


-- 
   Summary: [4.5 Regression] ICE on vmx/fft.c and vmx/7-01{,a}.c
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc64-linux


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

[Bug target/43297] [4.4 regression] -O2 -fPIC breaks htmlnorm.c

[edwintorok at gmail dot com]

--- Comment #4 from edwintorok at gmail dot com  2010-03-09 13:01 ---
(In reply to comment #3)
> Please test a more recent version from the 4.4 branch (and trunk if possible).
> 

Ok, I found gcc 4.4.3 on gcc200 and it still produces wrong code:
$ /opt/cfarm/release/4.4.3/bin/gcc -v
Using built-in specs.
Target: sparc64-unknown-linux-gnu
Configured with: ../gcc-4.4.3/configure --prefix=/opt/cfarm/release/4.4.3
--disable-werror --enable-languages=c,c++,fortran,ada --enable-__cxa_atexit
--disable-nls --enable-threads=posix --with-gmp=/opt/cfarm/gmp-4.2.4
--with-mpfr=/opt/cfarm/mpfr-2.4.2 --with-cpu=v8 --disable-multilib
Thread model: posix
gcc version 4.4.3 (GCC)

$ /opt/cfarm/release/4.4.3/bin/gcc -O2 -fPIC hh.c
$ ./a.out
Aborted

It seems to be a problem only when creating 32-bit code, -m64 works fine:
$ /opt/cfarm/release/4.4.3-64/bin/gcc -O2 -fPIC -m64 hh.c
$./a.out
And -m32 aborts of course:
$ /opt/cfarm/release/4.4.3-64/bin/gcc -O2 -fPIC -m32 hh.c
$./a.out

/opt/cfarm/release/4.4.3-64/bin/gcc -v
Using built-in specs.
Target: sparc64-unknown-linux-gnu
Configured with: ../gcc-4.4.3/configure --prefix=/opt/cfarm/release/4.4.3-64
--disable-werror --enable-languages=c,c++,fortran,ada --enable-__cxa_atexit
--disable-nls --enable-threads=posix --with-gmp=/opt/cfarm/gmp-4.2.4-64
--with-mpfr=/opt/cfarm/mpfr-2.4.2-64
Thread model: posix
gcc version 4.4.3 (GCC)
Aborted


-- 

edwintorok at gmail dot com changed:

   What|Removed |Added

  Known to fail|4.4.1   |4.4.3


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

[Bug middle-end/43300] [4.5 Regression] ICE: in emit_move_insn, at expr.c:3432

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2010-03-09 16:47 ---
This happens only for vector modes which aren't supported by the target.
They will be assigned BLKmode stack slots which right now aren't handled
correctly (incidentally I wonder why Graphite is needed to expose this
situation, without graphite we don't have conflicting SSA partitions).
Anyway, mine.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |matz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-09 00:34:38 |2010-03-09 16:47:50
   date||


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

[Bug tree-optimization/43306] [4.5 Regression] ICE: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:713 with -O1 -fstrict-overflow -fgraphite-identity

[spop at gcc dot gnu dot org]

--- Comment #1 from spop at gcc dot gnu dot org  2010-03-09 16:48 ---
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-03-09 16:48:37
   date||


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

[Bug tree-optimization/43236] -ftree-loop-distribution produces wrong code in reload1.c:delete_output_reload(), bootstrap fails

[amonakov at gcc dot gnu dot org]

--- Comment #8 from amonakov at gcc dot gnu dot org  2010-03-09 16:55 
---
Given the fact that loop distribution only works for two-bb loops, I think the
fix is to simply take number of latch executions when the stmt is in the latch.

diff --git a/gcc/tree-loop-distribution.c b/gcc/tree-loop-distribution.c
--- a/gcc/tree-loop-distribution.c
+++ b/gcc/tree-loop-distribution.c
@@ -389,6 +391,8 @@ generate_builtin (struct loop *loop, bitmap partition, bool
copy_p)
goto end;

  write = stmt;
+ if (bb == loop->latch)
+   nb_iter = number_of_latch_executions (loop);
}
}
 }


-- 


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

[Bug c++/43308] New: internal compiler error: in simplify_binary_operation_1

[gcc at dpinol dot com]

I got this compiling a qt file
../../include/QtGui/private/../../../src/gui/painting/qdrawhelper_mmx_p.h: In
function ‘void comp_func_SourceAtop(uint*, const uint*, int, uint) [with MM =
QMMXIntrinsics, uint = unsigned int]’:
../../include/QtGui/private/../../../src/gui/painting/qdrawhelper_mmx_p.h:540:1:
internal compiler error: in simplify_binary_operation_1, at simplify-rtx.c:3022

I attach .ii. Be aware that the problem can only be reproduce when compiled
both -O2 and -g


-- 
   Summary: internal compiler error: in simplify_binary_operation_1
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at dpinol dot com
 GCC build triplet: i686-gnu-linux
  GCC host triplet: i686-gnu-linux
GCC target triplet: i686-gnu-linux


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

[Bug tree-optimization/43257] [4.5 Regression] IPA-SRA changes DECL_ASSEMBLER_NAME

[jamborm at gcc dot gnu dot org]

--- Comment #1 from jamborm at gcc dot gnu dot org  2010-03-09 17:25 ---
Mine.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-04 17:04:04 |2010-03-09 17:25:37
   date||


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

[Bug tree-optimization/43306] [4.5 Regression] ICE: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:713 with -O1 -fstrict-overflow -fgraphite-identity

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2010-03-09 
17:39 ---
Might this be related to PR42181 since it also involves problems with the
-fgraphite-identity -fstrict-overflow?


-- 


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

[Bug target/43309] New: amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[ro at gcc dot gnu dot org]

While investigating the Solaris 11/x86 testsuite results, I noticed that some 
64-bit libgomp test cases were failing.  The failure boils down to the attached
tie.c program.

If compiled/linked with GNU as/Sun ld, the resulting binary SEGVs:

$ gcc -m64 -fopenmp -o tie.sun tie.c
$ ./tie.sun
Segmentation Fault

If instead GNU as and ld are used, everything works fine:

$ gcc -m64 -fopenmp -o tie.gnu tie.c
$ ./tie.gnu
$ 

As described in an initial patch submission, it turns out that the amd64 TLS
IE code sequence emitted by gcc doesn't follow the published Solaris 2 ABI,
nor the current `ELF Handling for Thread-Local Storage' spec at

  http://people.redhat.com/drepper/tls.pdf

While GNU ld copes with that just fine, Sun ld cannot handle this and breaks
the code emitted by gcc.


-- 
   Summary: amd64 TLS IE code sequence on Solaris 2/x86 violates
spec
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[ro at gcc dot gnu dot org]

--- Comment #1 from ro at gcc dot gnu dot org  2010-03-09 17:50 ---
Created an attachment (id=20059)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20059&action=view)
Test program


-- 


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

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2010-03-09 17:50 ---
Created an attachment (id=20060)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20060&action=view)
Executable created with GNU ld


-- 


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

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[ro at gcc dot gnu dot org]

--- Comment #3 from ro at gcc dot gnu dot org  2010-03-09 17:51 ---
Created an attachment (id=20061)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20061&action=view)
Executable created with Sun ld


-- 


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

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-03-09 18:11 ---
Please also upload tie.o.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com
 Status|UNCONFIRMED |WAITING


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

[Bug debug/43308] internal compiler error: in simplify_binary_operation_1

[gcc at dpinol dot com]

--- Comment #1 from gcc at dpinol dot com  2010-03-09 18:18 ---
Created an attachment (id=20062)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20062&action=view)
text

build it with g++ -g -O2 -mmmx qdrawhelper_mmx.ii to reproduce the error
(btw, upgrading a file to bugzilla is a pain!)


-- 


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

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-03-09 18:29 ---
case R_X86_64_GOTTPOFF:
  /* Check transition from IE access model:
movq f...@gottpoff(%rip), %reg
addq f...@gottpoff(%rip), %reg
   */
is very much intentional.


-- 


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

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2010-03-09 18:30 ---
Please also update tie executables generated by Sun and GNU linkers
with the SAME relocatable input.


-- 


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

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-03-09 18:35 ---
  /* IE->LE transition:
 Originally it can be one of:
 movq f...@gottpoff(%rip), %reg
 addq f...@gottpoff(%rip), %reg
 We change it into:
 movq $foo, %reg
 leaq foo(%reg), %reg
 addq $foo, %reg.  */


-- 


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

[Bug debug/43308] [4.5 Regression] internal compiler error: in simplify_binary_operation_1

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-03-09 18:37 ---
Worked with:
gcc version 4.5.0 20100304 (experimental) [trunk revision 157233] (GCC) 

But fails with:
GNU C++ (GCC) version 4.5.0 20100309 (experimental) [trunk revision 157311]
(x86_64-unknown-linux-gnu)


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|internal compiler error: in |[4.5 Regression] internal
   |simplify_binary_operation_1 |compiler error: in
   ||simplify_binary_operation_1
   Target Milestone|--- |4.5.0


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

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[ro at gcc dot gnu dot org]

--- Comment #8 from ro at gcc dot gnu dot org  2010-03-09 18:37 ---
Created an attachment (id=20063)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20063&action=view)
Object file


-- 


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

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-03-09 
18:38 ---
Subject: Re:  amd64 TLS IE code sequence on Solaris 2/x86 violates spec

> --- Comment #4 from hjl dot tools at gmail dot com  2010-03-09 18:11 
> ---
> Please also upload tie.o.

Done.
Rainer


-- 


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

[Bug debug/43308] [4.5 Regression] internal compiler error: in simplify_binary_operation_1

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-03-09 18:39 ---
Reducing ...


-- 


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

[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty

[jzwinck at gmail dot com]

--- Comment #17 from jzwinck at gmail dot com  2010-03-09 18:40 ---
(In reply to comment #16)
> there is evidence (eg, the Dinkumware implementation) that returning an
> iterator doesn't necessarily impact performance.

The GCC implementation does have poor performance.  Why not leave the
(performance-improving) patch in place until someone actually comes up with an
implementation for GCC which does perform well?
As it stands, users are left in a strange situation, being told that the
performance (in GCC) is poor, but that it has to be this way because of
Dinkumware (which, it's claimed, is fast).  Doesn't this only serve to drive
users away from GCC's implementation?

To be clear, I am very much in favor of any solution which provides
approximately optimal performance.  Boost, for example, chose to implement a
new method called "erase_return_void" for users who care about performance of
this operation--a workaround, but with emphasis on "work."


-- 


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

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-03-09 
18:43 ---
Subject: Re:  amd64 TLS IE code sequence on Solaris 2/x86 violates spec

> --- Comment #6 from hjl dot tools at gmail dot com  2010-03-09 18:30 
> ---
> Please also update tie executables generated by Sun and GNU linkers
> with the SAME relocatable input.

What do you mean?  I've compiled and linked tie.c in two separate trees,
one configured with gas and Sun ld, the other with gas and gld, and used
everything from the corresponding tree.

Rainer


-- 


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

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2010-03-09 18:45 
---
Sun linker changes

   4:   64 48 8b 14 25 00 00 00 00  mov%fs:0x0,%rdx
   d:   48 8b 05 00 00 00 00mov0x0(%rip),%rax# 14   
10: R_X86_64_GOTTPOFF   cnt-0x4

to

  400e0c:   64 48 8b 04 25 00 00 00 00  mov%fs:0x0,%rax
  400e15:   48 8d 80 f0 ff ff fflea-0x10(%rax),%rax

Nowhere in TLS spec allows the linker to change

   d:   48 8b 05 00 00 00 00mov0x0(%rip),%rax# 14   
10: R_X86_64_GOTTPOFF   cnt-0x4

to

 400e15:   48 8d 80 f0 ff ff fflea-0x10(%rax),%rax

It is Sun linker bug. Please report it to them.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-03-09 18:49 ---
Subject: Bug 43290

Author: jakub
Date: Tue Mar  9 18:48:43 2010
New Revision: 157313

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157313
Log:
PR debug/43290
* config/i386/i386.c (ix86_get_drap_rtx): Don't set
RTX_FRAME_RELATED_P.

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

Added:
trunk/gcc/testsuite/g++.dg/eh/unwind2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty

[paolo dot carlini at oracle dot com]

--- Comment #18 from paolo dot carlini at oracle dot com  2010-03-09 18:49 
---
Because would be non-conforming. In case my previous message was not clear
enough, in C++1x erase will return *iterator*.


-- 


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

[Bug debug/43293] Invalid unwind info for i?86 -fpic

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-03-09 18:51 ---
Subject: Bug 43293

Author: jakub
Date: Tue Mar  9 18:50:40 2010
New Revision: 157314

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157314
Log:
PR debug/43293
* config/i386/t-i386 (i386.o): Depend on debug.h and dwarf2out.h.
* config/i386/i386.c: Include debug.h and dwarf2out.h.
(ix86_file_end): If dwarf2out_do_cfi_asm (), emit .cfi_startproc
and .cfi_endproc around the pic thunks.
(output_set_got): For TARGET_DEEP_BRANCH_PREDICTION pic, ensure
all queued unwind info register saves are saved before the call.
For !TARGET_DEEP_BRANCH_PREDICTION pic, ensure the call is
considered as sp-=4 for unwind info and the pop as sp+=4 which
also clobbers dest, but doesn't actually restore it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/t-i386


-- 


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

[Bug debug/43304] [4.5 Regression] ICE on vmx/fft.c and vmx/7-01{,a}.c

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-03-09 18:51 ---
Subject: Bug 43304

Author: jakub
Date: Tue Mar  9 18:51:44 2010
New Revision: 157315

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157315
Log:
PR debug/43304
* var-tracking.c (vt_expand_loc_callback) : If dummy,
call cselib_dummy_expand_value_rtx_cb instead of
cselib_expand_value_rtx_cb.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c


-- 


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

[Bug bootstrap/43299] [4.5 Regression] Subversion id 157264 breaks powerpc 64-bit bootstraps

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-03-09 18:53 ---
Subject: Bug 43299

Author: jakub
Date: Tue Mar  9 18:53:38 2010
New Revision: 157316

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157316
Log:
PR debug/43299
* var-tracking.c (adjust_sets): New function.
(count_with_sets, add_with_sets): Use it.
(get_adjusted_src): New inline function.
(add_stores): Use it.

* gcc.dg/pr43299.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr43299.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/var-tracking.c


-- 


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

[Bug bootstrap/43299] [4.5 Regression] Subversion id 157264 breaks powerpc 64-bit bootstraps

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-03-09 18:54 ---
Subject: Bug 43299

Author: jakub
Date: Tue Mar  9 18:54:25 2010
New Revision: 157317

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157317
Log:
PR debug/43299
* dwarf2out.c (const_ok_for_output_1): Return 1 for UNSPECs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c


-- 


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

[Bug target/43305] [4.4/4.5 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2010-03-09 18:59 ---
(In reply to comment #4)
> Confirmed.  Introduced by Honza with the optimize_insn_for_size_p () changes.
> 

That is revision 138835:

http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg00394.html


-- 


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

[Bug bootstrap/43299] [4.5 Regression] Subversion id 157264 breaks powerpc 64-bit bootstraps

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-03-09 19:00 ---
Fixed (at least powerpc64-linux --with-cpu=default64 bootstrapped and its
regtest is currently pending).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug debug/43304] [4.5 Regression] ICE on vmx/fft.c and vmx/7-01{,a}.c

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-03-09 19:00 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/43293] Invalid unwind info for i?86 -fpic

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-03-09 19:01 ---
Fixed for 4.5+.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2010-03-09 19:01 ---
Fixed for 4.5+.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug debug/43176] var-tracking fails to notice a value change

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2010-03-09 19:02 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/43310] New: -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result

[giese025 at umn dot edu]

Easier to explain with a trivial piece of code...
PROGRAM BAR
  LOGICAL :: foo
  INTEGER,PARAMETER :: a = HUGE(1)
  INTEGER :: b
  b = HUGE(1)
  foo = NOT(a) >= 0  ! FAILS WITH -pedantic
  foo = NOT(b) >= 0  ! OK WITH -pedantic
END PROGRAM BAR

If -pedantic is used, then PARAMETERs appear to be handled differently
then if -pedantic is not used.
Moreover, this only seems to be an issue if the parameter is set to the result
of some other function, e.g., huge. 
Additionally, the program compiles as expected if the same code is used but
making the variable NOT a parameter.

This code snippet hasn't been a problem with intel nor nag compilers.
Nor is it a problem with gfortran if -pedantic is not used.

I would expect this to not be a problem with gfortran when -pedantic is used.

The error messege that I receive is

[n...@host dir]$ gfortran -c -pedantic bar.f90
bar.f90:6.12:

  foo = NOT(a) >= 0  ! FAILS* WITH -pedantic
1
Error: Result of NOT gives range error for its kind at (1)


My version

Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.2 20091222 (Red Hat 4.4.2-20) (GCC)


-- 
   Summary: -pedantic errors on valid code involving PARAMETERs
initialized to intrinsic function result
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giese025 at umn dot edu


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

[Bug target/43311] New: missed 'movw' optimization.

[pluto at agmk dot net]

reduced testcase:

typedef struct { unsigned char b1, b2; } __attribute__((aligned(8))) S;
void f( S const* s, unsigned char* b1, unsigned char* b2 )
{
*b1 = s->b1;
*b2 = s->b2;
}

generates at -Os and -O3:

f:
movb(%rdi), %al # .b1, .b1
movb%al, (%rsi) # .b1,* b1
movb1(%rdi), %al# .b2, .b2
movb%al, (%rdx) # .b2,* b2
ret

gcc could (at least at -Os) reduce code size and memory accesses to:

movw(%rdi), %ax
movb%al, (%rsi) # .b1,* b1
movb%ah, (%rdx) # .b2,* b2
ret


-- 
   Summary: missed 'movw' optimization.
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
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=43311

[Bug target/43309] amd64 TLS IE code sequence on Solaris 2/x86 violates spec

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-03-09 
19:14 ---
Subject: Re:  amd64 TLS IE code sequence on Solaris 2/x86 violates spec

> --- Comment #11 from hjl dot tools at gmail dot com  2010-03-09 18:45 
> ---
> Sun linker changes
>
>4:   64 48 8b 14 25 00 00 00 00  mov%fs:0x0,%rdx
>d:   48 8b 05 00 00 00 00mov0x0(%rip),%rax# 14  
>  
> 10: R_X86_64_GOTTPOFF   cnt-0x4
>
> to
>
>   400e0c:   64 48 8b 04 25 00 00 00 00  mov%fs:0x0,%rax
>   400e15:   48 8d 80 f0 ff ff fflea-0x10(%rax),%rax
>
> Nowhere in TLS spec allows the linker to change
>
>d:   48 8b 05 00 00 00 00mov0x0(%rip),%rax# 14  
>  
> 10: R_X86_64_GOTTPOFF   cnt-0x4
>
> to
>
>  400e15:   48 8d 80 f0 ff ff fflea-0x10(%rax),%rax
>
> It is Sun linker bug. Please report it to them.

True, this is a bug, but the input sequence isn't valid according to the
spec: 

4:   64 48 8b 14 25 00 00 00 00  mov%fs:0x0,%rdx
d:   48 8b 05 00 00 00 00mov0x0(%rip),%rax# 14   

This should be

 mov%fs:0x0,%rax

instead.  As I said, garbage in, garbage out.  If you disagree, point me
at where the spec allows this.  Even if so, we should either fix (if
allowing other registers is a GNU extension to the base spec) or work
around (if it is a misunderstanding on Sun's part) the problem if
targetting Solaris: there are linkers in the field that behave as
observed, and generating code that causes binaries to crash isn't a good
option.

Rainer


-- 


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

[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty

[sjackman at gmail dot com]

--- Comment #19 from sjackman at gmail dot com  2010-03-09 19:15 ---
How does the Dinkumware implementation avoid the performance hit of erase
returning an iterator?


-- 


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

[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty

[paolo dot carlini at oracle dot com]

--- Comment #20 from paolo dot carlini at oracle dot com  2010-03-09 19:19 
---
Nobody knows the gory details, but Plauger said that people can look into the
headers of the last beta of Visual Studio... Knowledgeable people are under the
impression they are using a different, double linked, implementation for the
hash table, which has its own problem, still, at this point it's pretty clear
that in C++1x erase will return an iterator and we have to live with that.


-- 


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

[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
   |dot com |dot org
 Status|REOPENED|NEW


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

[Bug target/32951] missed memcpy -> movdqa optimization.

[pluto at agmk dot net]

--- Comment #7 from pluto at agmk dot net  2010-03-09 19:34 ---
current 4.4.x generates 'movdqa (%rdi), %xmm0' in both cases.
4.2 branch is closed, 4.3 is near to close.
can we close this bug as fixed?


-- 


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

[Bug c++/41185] size of array ... has non-integral type ...

[pluto at agmk dot net]

--- Comment #2 from pluto at agmk dot net  2010-03-09 19:35 ---
ping^0


-- 


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

[Bug tree-optimization/43306] [4.5 Regression] ICE: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:713 with -O1 -fstrict-overflow -fgraphite-identity

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-03-09 19:39 ---
Subject: Bug 43306

Author: spop
Date: Tue Mar  9 19:39:27 2010
New Revision: 157322

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157322
Log:
Fix PR43306: correct evolution_function_right_is_integer_cst.

2010-03-09  Sebastian Pop  

PR middle-end/43306
* tree-chrec.c (evolution_function_right_is_integer_cst): CHREC_RIGHT
should be an INTEGER_CST.  Also handle CASE_CONVERT.
* gcc.dg/graphite/pr43306.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr43306.c
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/tree-chrec.c


-- 


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

[Bug fortran/43310] -pedantic errors on valid code involving PARAMETERs initialized to intrinsic function result

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2010-03-09 19:40 ---
Don't use -pedantic.  It forces a symmetric range on
the integer type, [-huge():huge].  This can be checked
during constant folding, and NOT(A) is detected as an
error.  gfortran does not instrument the runtime code
for NOT(B), so it cannot detect that you are violating
the range of the pedantic integer type.  The GCC middle
end and back end do not enforce the symmetry of the range.

There was a long, long, long debate about this years ago
in the fort...@gcc.gnu.org mailing list.  See the archives
for details.


-- 


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

[Bug debug/43308] [4.5 Regression] internal compiler error: in simplify_binary_operation_1

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-03-09 19:41 ---
Reduced testcase:
#include 
typedef __m64 m64;
static inline m64 alpha(m64 x) {
  x = _mm_unpackhi_pi16(x, x);
  x = _mm_unpackhi_pi16(x, x);
  return x;
}
static inline m64 _byte_mul(const m64 &a, const m64 &b, const m64 &mmx_0x0080){
  m64 res = _mm_mullo_pi16(a, b);
  return _mm_srli_pi16(res, 8);
}
static inline m64 _load(unsigned x, const m64 &mmx_0x) {
  return _mm_unpacklo_pi8(_mm_cvtsi32_si64(x), mmx_0x);
}
static inline unsigned _store(const m64 &x, const m64 &mmx_0x) {
  return _mm_cvtsi64_si32(_mm_packs_pu16(x, mmx_0x));
}
void comp_func_solid_SourceOver(unsigned *dest, unsigned src)
{
  const m64 mmx_0x00ff = _mm_set1_pi16(0xff);
  const m64 mmx_0x0080 = _mm_set1_pi16(0x80);
  const m64 mmx_0x = _mm_setzero_si64();
  m64 s = _load(src, mmx_0x);
  m64 a = _mm_xor_si64(alpha(s), mmx_0x00ff);
  *dest =  _store(_mm_adds_pu16(s, _byte_mul(_load(*dest, mmx_0x), a,
mmx_0x0080)), mmx_0x);
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-gnu-linux  |
   GCC host triplet|i686-gnu-linux  |
 GCC target triplet|i686-gnu-linux  |i?86-gnu-linux
   Last reconfirmed|-00-00 00:00:00 |2010-03-09 19:41:48
   date||


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

[Bug c++/41185] size of array ... has non-integral type ...

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-03-09 19:42 
---
If you could provide a small self contained snippet exhibiting the problem, it
would be great.

Jason, can you have a look at this? Just in case it's actually a regression...
Thanks in advance.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug debug/43304] [4.5 Regression] ICE on vmx/fft.c and vmx/7-01{,a}.c

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2010-03-09 19:55 ---
*** Bug 43308 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gcc at dpinol dot com


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

[Bug debug/43308] [4.5 Regression] internal compiler error: in simplify_binary_operation_1

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2010-03-09 19:55 ---
C testcase:
#include 
typedef __m64 m64;
static inline m64 alpha(m64 x) {
  x = _mm_unpackhi_pi16(x, x);
  x = _mm_unpackhi_pi16(x, x);
  return x;
}
static inline m64 _byte_mul(const m64 a, const m64 b, const m64 mmx_0x0080){
  m64 res = _mm_mullo_pi16(a, b);
  return _mm_srli_pi16(res, 8);
}
static inline m64 _load(unsigned x, const m64 mmx_0x) {
  return _mm_unpacklo_pi8(_mm_cvtsi32_si64(x), mmx_0x);
}
static inline unsigned _store(const m64 x, const m64 mmx_0x) {
  return _mm_cvtsi64_si32(_mm_packs_pu16(x, mmx_0x));
}
void comp_func_solid_SourceOver(unsigned *dest, unsigned src)
{
  const m64 mmx_0x00ff = _mm_set1_pi16(0xff);
  const m64 mmx_0x0080 = _mm_set1_pi16(0x80);
  const m64 mmx_0x = _mm_setzero_si64();
  m64 s = _load(src, mmx_0x);
  m64 a = _mm_xor_si64(alpha(s), mmx_0x00ff);
  *dest =  _store(_mm_adds_pu16(s, _byte_mul(_load(*dest, mmx_0x), a,
mmx_0x0080)), mmx_0x);
}
--- CUT ---
This is a dup of bug 43304

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


-- 

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=43308