--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-26 09:46 ---
Seems to work for me on x86_64 with -m32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
Following code results in output 0 0 0 0 with -O1 and higher. -O0 is OK and
gives output ff ff ff ff. gcc-3.4.6 produces correct output even with -O3.
--
Summary: SSE2 generation bug with shifts
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
--- Comment #1 from prakash at punnoor dot de 2007-03-26 09:54 ---
Created an attachment (id=13287)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13287action=view)
triggers bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31361
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-26 10:13 ---
openssl is a weird beast of macro hell ;) (enough reason to fix it...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-26 10:14 ---
I guess the cost of loading zero is cheaper then?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rakdver at gcc dot gnu dot org 2007-03-26 10:17 ---
(In reply to comment #0)
For:
int *f(int *a, int b, int c)
{
int i;
a --;
*a = 1;
for (i = 0;ib;i+=c)
(a[i]) = 0;
return a;
}
CUT
I get in the final_cleanup:
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-03-26 10:33
---
Below is a patch to use geteuid() and getpwuid(). One minor thing is that
linking with glibc now warns at compile time for static linking:
../../../../trunk/libgfortran/intrinsics/getlog.c:97: warning: Using
--- Comment #2 from prakash at punnoor dot de 2007-03-26 10:53 ---
Uhm, looking at the docs again, I am not so sure whether I understood the shift
instructions correctly. It seems I cannot shift the (in this case) 32 bit
portions individually? Rather the second operand to psrld has to
--- Comment #12 from pault at gcc dot gnu dot org 2007-03-26 11:37 ---
(In reply to comment #11)
(In reply to comment #10)
Do you have any idea what I cold do to turn this into an array?
All the interesting gfc_conv_intrinsic_* functions have the
if (se-ss) statement on top.
I'll
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #13 from pault at gcc dot gnu dot org 2007-03-26 12:43 ---
(In reply to comment #11)
(In reply to comment #10)
Thomas,
It does not look too bad:
Look at the tail end of array_transfer -
gfc_trans_create_temp_array (se-pre, se-post, se-loop,
--- Comment #32 from jv244 at cam dot ac dot uk 2007-03-26 13:15 ---
Unfortunately I don't
have the SPEC test case to see to try to weed this out.
have a look a comment #24 the sources are actually available
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
--- Comment #8 from thierry dot galas at med dot ge dot com 2007-03-26
13:56 ---
Subject: Re: undetected class name clash
Thanks for the explanation,
I agree that it is hard to detect for a compiler to detect ODL violation,
especially if we want to exclude from ODL local classes
--- Comment #3 from dirtyepic at gentoo dot org 2007-03-26 14:27 ---
All true. But this report is not about openssl, it's about GCC purposely going
out of it's way to break undefined code for no good reason. It does silently
crash, for all intents and purposes. I'm not saying that's
gcc should never inline functions which have a 'section' attribute set
on them.
If the section is placed at a specific location in memory via a linker
script, then the function will not be placed into its correct address,
and the resultant executable is incorrect.
gcc 4.1.1 will inline static
--- Comment #1 from thutt at vmware dot com 2007-03-26 15:08 ---
Created an attachment (id=13288)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13288action=view)
Simple Script which will build the original C source
Simple Script which will build the original C source
--
--- Comment #2 from thutt at vmware dot com 2007-03-26 15:09 ---
Created an attachment (id=13289)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13289action=view)
original source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
--- Comment #3 from thutt at vmware dot com 2007-03-26 15:09 ---
Created an attachment (id=13290)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13290action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
gcc version 4.0.4
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/var/tmp
compiling with -O on input:
void
foo(unsigned long long c)
{
if (c 0x8000)
puts(bug);
}
int
main(void)
{
foo(0x1ULL);
return 0;
}
produces bug.
--- Comment #9 from bangerth at dealii dot org 2007-03-26 15:17 ---
(In reply to comment #8)
but I guess it could be possible at link time, as it is already the case
for C symbols.
We also don't do that in C: if you have two functions of the same name defined
in two different .c
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-26 15:11 ---
If it is incorrect to inline a function you should specify that with
__attribute__((noinline)), I don't see why in general inlining a function which
out of line copy is in a special section is wrong.
--
rguenth
--- Comment #5 from thutt at vmware dot com 2007-03-26 15:40 ---
I'm going to argue that comment #4 is incorrect.
1. This new behavior is a regression from previous versions of gcc.
2. The 4.1.1 compiler gets it right at -O0 and -O3. Previous
versions of gcc which we've been
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-26 15:47 ---
qoute
In the actual implementation from which this test case was derived,
the function *must* reside at a specific location in memory, but due
to the inlining, it does not. This causes failures in the
application.
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-26 15:51 ---
Note that for your testcase even if you specify the noinline attribute the
function calls will be optimized away as the function calls do not have
side-effects.
--
--- Comment #8 from thutt at vmware dot com 2007-03-26 15:57 ---
Furthermore,
4. By placing the code in a different section, I'm instructing the
the compiler to *not* put it in '.text'. By inlining it, it
places it in '.text' despite my instructions.
--
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-26 16:28 ---
We inline static functions used once (special_function_0 in your testcase)
starting with the tree inliner which appeared in 3.4.0. So the bug is
present
in all releases starting from 3.4.0 and still present in
--- Comment #2 from tobi at gcc dot gnu dot org 2007-03-26 16:43 ---
This is one of the additional constraints given in 12.7.1 of the F95 standard:
A dummy argument, or a subobject thereof, shall not appear in
aspecification-expr
except as the argument to one of the intrinsic functions
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-26 16:43 ---
Works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31363
I get the following ICE during bootstrap on powerpc with current SVN (revision
123217):
(sid)227:[EMAIL PROTECTED]: ..build/powerpc-linux-gnu/64]
/home/tbm/build/gcc-snapshot-20070326/build/./gcc/xgcc
-B/home/tbm/build/gcc-snapshot-20070326/build/./gcc/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnu
--- Comment #62 from bonzini at gnu dot org 2007-03-26 16:50 ---
dataflow branch cannot complete this at -O3 -fno-tree-pre -fno-tree-fre
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-26 16:51 ---
I guess the cost of loading zero is cheaper then?
Cheaper than loading 0xDEADBEEF but not cheap enough not to pull out of the
loop. All the easy (one instruction) constants are not pulled out.
Really I think rtl
--- Comment #1 from tbm at cyrius dot com 2007-03-26 16:51 ---
Reduced testcase, you need -fPIC:
struct _pthread_fastlock
{
}
pthread_mutexattr_t;
extern void abort (void) __attribute__ ((__nothrow__))
__attribute__ ((__noreturn__));
typedef int SItype __attribute__ ((mode (SI)));
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #33 from spark at gcc dot gnu dot org 2007-03-26 16:54 ---
(In reply to comment #31)
Here is a new patch. I need someone to test on SPEC. It is very simple.
Index: transfer.c
===
*** transfer.c
--- Comment #2 from tbm at cyrius dot com 2007-03-26 16:55 ---
Further reduced (-fPIC):
__subvsi3 ()
{
abort ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-26 16:58
---
And now there is already an option to stop this inlining static functions
called once.
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-finline_002dfunctions_002dcalled_002donce-507
--
pinskia at
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-26 17:02
---
4.1.2 also inlines the other one, so that won't help. Still noinline will.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
Right now gcj will make a vtable slot for a non-static private method.
We speculate that this is done for CNI.
However, there's no point to a private method having a vtable slot,
since private methods are never inherited. Ideally both gcj and g++
would emit calls to private methods directly (not
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-26 17:18 ---
It does silently crash, for all intents and purposes.
No, it is not silent at all, it warns loudly (you cannot turn off the warning
except by using -w).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
When the last record written to a direct access file is shorter than the record
length of the file, gfortran truncates the record. The following test program
produces a file whose length is 1 when it should be 10.
PROGRAM test
OPEN (76, FILE=test.txt, ACCESS=DIRECT, STATUS=NEW, RECL=10)
WRITE(76,
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-26 17:35 ---
Even if this MEM is ok, we still get bad results as we have *(a+b-4) inside the
loop now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
--- Comment #12 from thutt at vmware dot com 2007-03-26 17:46 ---
I respectfully submit that I think you guys are missing the point.
The problem isn't that the compiler is inlining functions which
are called once, the problem is that the compiler is inlining a
function
--- Comment #4 from ian at airs dot com 2007-03-26 17:57 ---
I'm continuing to look into the best way to avoid the compiler crash. I want
to note that this code is being clobbered by undefined signed overflow.
Computing (19780211 + [-128,127]) * 43321879 is always going to overflow,
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-26 18:00 ---
Subject: Re: [4.3 Regression] rtl loop invariant is broken
I guess the cost of loading zero is cheaper then?
Cheaper than loading 0xDEADBEEF but not cheap enough not to pull out of the
--- Comment #10 from sylvain dot pion at sophia dot inria dot fr
2007-03-26 18:03 ---
Let me mention that this is against 4.2. The trunk works well for me.
I tried several times during March (including today), and the bug is still
here.
Note that varrying the conditions slightly
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-26 18:09 ---
I would agree, if we had RA capable of that (which I am not quite sure
whether we do or not, although this seems simple enough), or better,
RA doing better job under high register pressure.
Then how do you
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-26 18:10
---
Why do you think sections are special?
GCC does not know if a section is special or not and it really should not know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-26 18:18 ---
Subject: Re: [4.3 Regression] rtl loop invariant is broken
I would agree, if we had RA capable of that (which I am not quite sure
whether we do or not, although this seems simple enough),
--- Comment #5 from ian at airs dot com 2007-03-26 18:27 ---
I'm testing this patch.
Index: tree-vrp.c
===
--- tree-vrp.c (revision 123218)
+++ tree-vrp.c (working copy)
@@ -1982,10 +1982,18 @@
--- Comment #9 from hjl at lucon dot org 2007-03-26 18:37 ---
Any tuning target doesn't set x86_accumulate_outgoing_args will fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
--- Comment #14 from thutt at vmware dot com 2007-03-26 18:54 ---
Why do you think sections are special?
GCC does not know if a section is special or not and it really should not
know.
I don't necessarily think that sections are 'special', but since gcc
has the capability to change
--- Comment #2 from gr at collax dot com 2007-03-26 19:03 ---
(In reply to comment #1)
Works for me.
Hm. Just to be completely sure, my source archive gcc-4.0.4.tar.bz2 has md5sum
8970debbc55bea85ee80961d733080f0, as two other copies fetched from different
mirrors. I compiled it on
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-26 19:09 ---
I could reproduce this with 4.0.4 20060622 but it works on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31363
--- Comment #3 from rth at gcc dot gnu dot org 2007-03-26 19:14 ---
Confirmed. We've modeled the instruction incorrectly; it takes the shift
count from the entire 128-bit xmm register, not the low 32 or 8 bits.
--
rth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from tromey at gcc dot gnu dot org 2007-03-26 19:27 ---
This seems reasonable to me.
Could you write a ChangeLog entry and submit the patch to
[EMAIL PROTECTED]
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from hjl at lucon dot org 2007-03-26 19:30 ---
I think dfp should be disabled by default on x86. We are missing patterns
for movsd, movdd, and maybe movtd.
--
hjl at lucon dot org changed:
What|Removed |Added
When a deprecated type is used in a struct which is itself deprecated, we
should not warn. That would be consistent with the current behaviour of not
warning about applying a deprecated type to a deprecated variable.
Test case:
typedef __attribute__((deprecated)) int foo;
typedef
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-26 19:39
---
The ICE is still a bug which needs to be fixed Plus this is still a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 19:42 ---
Confirmed, the C front-end also gives the warning.
[EMAIL PROTECTED]:~$ ~/x86-local-fsf/bin/gcc t.c -S
t.c:4: warning: 'foo' is deprecated
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from hjl at lucon dot org 2007-03-26 19:56 ---
(In reply to comment #11)
The ICE is still a bug which needs to be fixed Plus this is still a
regression.
Failing to compile this code isn't a regression since the same code always
fails with gcc 4.2 and 4.3 when DFP
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-26 20:04
---
The build failure is still a regression, no matter which you look at it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from eweddington at cso dot atmel dot com 2007-03-26 20:22
---
FWIW, I agree with the OP. This will place a burden on users who work with
embedded systems such as the AVR. Special sections are sometimes needed in the
AVR to place code into a special bootloader area that
--- Comment #14 from hjl at lucon dot org 2007-03-26 20:41 ---
This isn't a real patch. But it seems to work on the testcase.
--- i386.md.dfp 2007-03-24 12:21:45.0 -0700
+++ i386.md 2007-03-26 12:30:21.0 -0700
@@ -1850,6 +1850,59 @@
ix86_expand_move (DImode,
--- Comment #2 from bangerth at dealii dot org 2007-03-26 20:44 ---
Yes, indeed.
*** This bug has been marked as a duplicate of 27102 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #17 from bangerth at dealii dot org 2007-03-26 20:44 ---
*** Bug 31330 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2007-03-26 20:46 ---
(In reply to comment #2)
well, priv is a pointer..
What I really meant was a typedef:
template class T struct Base {
typedef typename T::X X;
};
struct A : BaseA
{
typedef int X;
};
--- Comment #5 from bangerth at dealii dot org 2007-03-26 20:48 ---
Yup, Andrew is right.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #42 from manu at gcc dot gnu dot org 2007-03-26 20:48 ---
Created an attachment (id=13291)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13291action=view)
version 2 of fixtestsuite script
This new version of the script makes more automatic fixes.
--
manu at gcc dot
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-03-26 21:21
---
You supposed to mark all functions which you don't want inlined as noinline.
that is what the noinline attribute is there for. The inliner is just too
smart that is all. If you want a dumber inliner fine, but
--- Comment #2 from david at luyer dot net 2007-03-26 21:27 ---
Two other related cases which generate warnings. I'm not sure
which is the correct syntax to mark a field deprecated, but
both are currently generating warnings, and marking a field
which uses a deprecated type as
--- Comment #3 from dj at redhat dot com 2007-03-26 21:36 ---
30972 is Windows, this is DJGPP - different operating systems.
Are you using the stock 2.03 files, or the 2.04 (beta) files? There are known
incompatibilities in XP and Vista that require the 2.04 builds of the GNU
tools,
--- Comment #4 from mesti_mudam at yahoo dot com 2007-03-26 21:49 ---
ive no idea which part of the standard should imply/allow this. if one replaces
typename T::privIC * priv with T * priv, its valid and it compiles. I
thought T::privC is equally accessible 'incomplete' as T itself
Main application dynamically loads shared library and uses function from
library to fill out string. If basic_stringchar or basic_stringwchar_t are
used then no problem observed. In case of basic_stringunsigned short
application aborts (MALLOC_CHECK_=2) with message
*** glibc detected ***
--- Comment #34 from jvdelisle at gcc dot gnu dot org 2007-03-26 21:55
---
Regarding comment 24 and 32.
I have that downloaded and tried to compile and there are duplications of
subroutines and multiple main programs. As I get time, I intend to get it
sorted out and add it to my
--- Comment #2 from pcarlini at suse dot de 2007-03-26 22:08 ---
The message to the libstdc++ list:
http://gcc.gnu.org/ml/libstdc++/2006-01/msg00155.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25956
--- Comment #1 from pcarlini at suse dot de 2007-03-26 22:10 ---
Seems the same as libstdc++/25956. Can you try whether instantiating the string
class at global scope works for you too:
http://gcc.gnu.org/ml/libstdc++/2006-01/msg00162.html
???
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-26 22:11 ---
Plus I just tested the 4.2 branch and it is broken there also, G.
Sorry for finding this late in the release cycle but I guess nobody really
looked at the code quality after loop.c was turned off and
--- Comment #8 from steven at gcc dot gnu dot org 2007-03-26 22:13 ---
Re. comment #5
Andrew, stop spreading nonsense. Other compilers do take register pressure
into account. In fact, they do so much better than GCC usually does. (In GCC
you can't do it well because instructions
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-26 22:17 ---
This is still a 4.2 regression.
4.2 produces:
.L2:
li 0,100
stwx 0,9,3
addi 9,9,4
bdnz .L2
blr
While 4.1 produces:
.L2:
stwx 0,9,3
addi 9,9,4
bdnz
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-03-26 22:18
---
Adding Thomas to cc.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-26 22:27 ---
3.2.3 produced:
.L6:
slwi 0,9,2
add 9,9,5
cmpw 0,9,4
stwx 11,3,0
bgelr- 0
b .L6
While 4.1.0 and above produces:
.L4:
add 9,9,5
stw 10,-4(3)
--- Comment #2 from gregoryk at edifecs dot com 2007-03-26 22:28 ---
Though the problem from bug 25956 looks same the instantiating didn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
--- Comment #10 from steven at gcc dot gnu dot org 2007-03-26 22:33 ---
Just a small heuristics problem. This could be fixed by giving insns to move
with comp_cost - size_cost == 0 in gain_for_invariant a small gain anyway. Or
maybe comp_cost should overrule size_cost.
Just as a
--- Comment #11 from steven at gcc dot gnu dot org 2007-03-26 22:36 ---
And of course the hack doesn't actually work :-) But it's still just a
heuristics tweak what we need here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #12 from steven at gcc dot gnu dot org 2007-03-26 22:43 ---
Zdenek, what is the size heuristic for anyway? For powerpc, the current
heuristic tells the compiler not to move any simple moves:
1) An invariant with a gain of 0 will not be moved.
2) gain = comp_cost -
--- Comment #6 from ian at gcc dot gnu dot org 2007-03-26 22:43 ---
Subject: Bug 31345
Author: ian
Date: Mon Mar 26 22:43:30 2007
New Revision: 123237
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123237
Log:
./:
PR tree-optimization/31345
* tree-vrp.c
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #3 from pcarlini at suse dot de 2007-03-26 22:52 ---
Ok, but before we take any further action we badly need a better reproduce: on
any up to date x86 and x86-64 linux machine I tried, your testcase segfault
immediately both for unsigned short and for char (and the
--- Comment #3 from paolo at gcc dot gnu dot org 2007-03-26 22:55 ---
Subject: Bug 30500
Author: paolo
Date: Mon Mar 26 22:55:03 2007
New Revision: 123238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123238
Log:
2007-03-26 Paolo Carlini [EMAIL PROTECTED]
PR c++/30500
--- Comment #4 from paolo at gcc dot gnu dot org 2007-03-26 22:55 ---
Subject: Bug 30500
Author: paolo
Date: Mon Mar 26 22:55:19 2007
New Revision: 123239
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123239
Log:
2007-03-26 Paolo Carlini [EMAIL PROTECTED]
PR c++/30500
--- Comment #5 from pcarlini at suse dot de 2007-03-26 22:56 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-26 23:05 ---
Subject: Re: [4.2/4.3 Regression] rtl loop invariant is broken
Zdenek, what is the size heuristic for anyway? For powerpc, the current
heuristic tells the compiler not to move any simple
--- Comment #4 from gregoryk at edifecs dot com 2007-03-26 23:13 ---
Ok. Can I help you somehow?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
--- Comment #5 from pcarlini at suse dot de 2007-03-26 23:24 ---
Yes, as I said, we need a better reproducer, that is a testcase that on most of
the current x86-linux or x86-64-linux machines behaves as you are reporting: if
you want to help you should look for a recent machine (e.g.,
--- Comment #3 from spark at gcc dot gnu dot org 2007-03-27 00:56 ---
# cat -n t.c
1 typedef __attribute__((deprecated)) int foo;
2 typedef
3 struct
4 __attribute__((deprecated))
5 bar1
6 {
7foo baz;
8 }
9 bop1;
--- Comment #4 from rth at gcc dot gnu dot org 2007-03-27 01:30 ---
Subject: Bug 31361
Author: rth
Date: Tue Mar 27 01:30:32 2007
New Revision: 123250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123250
Log:
PR target/31361
* config/i386/i386.c
--- Comment #5 from rth at gcc dot gnu dot org 2007-03-27 01:37 ---
You can shift the 32-bit portions individually. But your test case will now
result in 0,0,0,0 for all optimization levels, since the shift count is taken
from the entire xmm register. In this case, since there is an 8
--- Comment #5 from dirtyepic at gentoo dot org 2007-03-27 01:49 ---
I was referring to what the user gets to experience at runtime.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
--- Comment #1 from tromey at gcc dot gnu dot org 2007-03-27 02:44 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 110 matches
Mail list logo
