--- 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 (l
--- 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 a
--- 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 regr
--- 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
--- 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
--- 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|ebo
--- 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 E
--- 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
--- 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
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
--- 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.o
--- 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
--- 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_compca
--- 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_o
--- 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 *me
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 -
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/plu
--- 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 -f
--- 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
--- 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
--- 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
--- 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 |A
--- 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
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||aoliva at gcc dot gnu dot
|
--- 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
--
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 rev
--- 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
--- 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
--- 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
--- 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? Ch
--- 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 g
--- 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
--- 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 pa
--- 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
--- 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,
typ
--- 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. Reme
--
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
--- 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
--- 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/4326
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/
--- 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
> --
--- 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
--- 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 f
--- 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
---
--- 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_
--- 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
--- 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, t
--- 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/g
--
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 ch
--- 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
---
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 er
--- 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
--- 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
si
--- 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 gc
--- 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-l
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
--- 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
--- 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
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
Segment
--- 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
--- 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
--- 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
--- 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
--- 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 pa
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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.
Raine
--- 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
--- 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
--- 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
--- 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
--- 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_dr
--- 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
--- 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): Dep
--- 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_ca
--- 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): Ne
--- 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
--- 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/bu
--- 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
--- 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
--- 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|UNCO
--- 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|ASS
--- 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
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 han
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)
--- 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 2
--- 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
--- 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 linke
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
|dot com
--- 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
--- 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
--- 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
--- 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
fo
--- 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, cons
--- 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
--- 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
---
--- 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 mm
1 - 100 of 167 matches
Mail list logo
