--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/
--
What|Removed |Added
CC||danglin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/sh
--
What|Removed |Added
CC||danglin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/sh
Thread.interrupt does not check if the thread is alive - it just signals the
thread regardless. This sometimes causes a segfault followed by an abort,
because the native thread library gets passed stale data.
Unable to create a reproducable test case - but I would hope it's self-evident
that the e
--- Additional Comments From hubicka at ucw dot cz 2005-06-28 01:29 ---
Subject: Re: [4.0 Regression] Quiet bad codegen (unrolling + tail call
interaction)
>
> --- Additional Comments From mmitchel at gcc dot gnu dot org 2005-06-26
> 01:53 ---
> Jan, would you please see if
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
15:38 ---
*** Bug 20686 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|Tobias dot Schlueter at |tobi at gcc dot gnu dot org
|physik dot uni-muenchen dot |
|de
--
Bug 18373 depends on bug 21959, which changed state.
Bug 21959 Summary: [4.1 Regression] vrp miscompiles Ada front-end, drops loop
exit test in well-defined wrap-around circumstances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
What|Old Value |New Valu
--
Bug 21923 depends on bug 21959, which changed state.
Bug 21959 Summary: [4.1 Regression] vrp miscompiles Ada front-end, drops loop
exit test in well-defined wrap-around circumstances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
What|Old Value |New Valu
--
Bug 21994 depends on bug 21959, which changed state.
Bug 21959 Summary: [4.1 Regression] vrp miscompiles Ada front-end, drops loop
exit test in well-defined wrap-around circumstances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
What|Old Value |New Valu
--
Bug 22019 depends on bug 21959, which changed state.
Bug 21959 Summary: [4.1 Regression] vrp miscompiles Ada front-end, drops loop
exit test in well-defined wrap-around circumstances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
What|Old Value |New Valu
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-28
01:14 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-28
01:08 ---
I'd like to point out that as documented extensively in bug report 22082, 64-bit
compilation *does* work on powerpc-darwin-8 with gcc-4.0.0, and it doesn't now
work on the mainline or the 4.0 branch. Mik
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-28
00:52 ---
Subject: Bug 21959
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-28 00:52:35
Modified files:
gcc: ChangeLog tree-ssa-loop-niter.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-06-27
23:47 ---
I don't understand this PR.
Here is evidence that c-parse.c is in fact included:
$ tar tjf gcc-core-4.0.1-20050616.tar.bz2 | grep c-parse
gcc-4.0.1-20050616/gcc/c-parse.in
gcc-4.0.1-20050616/gcc/c-parse.y
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
23:46 ---
This is not the first time I have seen this in both the Ada and gfortran
front-ends.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
23:44 ---
This is a target bug. It should be implementing the TI mode functions.
--
What|Removed |Added
---
There seems to be something weird going on in gfc_conv_array_initializer. In
the EXPR_ARRAY case, the code builds both an "index" and a "range". Then,
optionally, it adds both of them to the constructor list being built. This is
strange: I would expect either of them to be added, but not both.
All gfortran execute tests fail on mips-sgi-irix6.5 on mainline since 2005-06-
23 18:55 UTC. The run time loader rld reports that libgfortran.so has
unresolvable symbols __udivti3 __divti3 __umodti3 and __multi3
The error is:
108352656:./PR19754_2.exe: rld: Error: unresolvable symbol
in /disk4
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-27
23:32 ---
There are patches missing from 4.0 to fix some cases where regrename
could produce wrong code. Besides, enabling passes on a release branch
sounds like an awfully bad idea. Setting 4.1 as the target miles
--
What|Removed |Added
Component|libstdc++ |middle-end
GCC host triplet|i686-pc-cygwin |
GCC target triplet||i6
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22208
--
What|Removed |Added
OtherBugsDependingO||22208
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
We should renable the this flag at least at -O3 and above. See PR 15023 for
why it was disabled, every
problem except for the compiler time issue was a latent target bug.
--
Summary: [4.0/4.1 Regression] flag_rename_registers is not
enabled at -O3 or above
--- Additional Comments From brian at dessent dot net 2005-06-27 23:10
---
Created an attachment (id=9163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9163&action=view)
Preprocessed source for testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
The following reduced test case causes spurious -Wuninitialized warnings, but
only with -O2:
-
#include
#include
class OptionSet
{
public:
OptionSet ();
std::vector const &nonOptions() const;
private:
std::vector nonoptions;
};
OptionSet::OptionSet()
{
nonoptions = std::vector ();
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
23:07 ---
This is invalid code but I don't have the time to explain why except to say
that when inside a
namespace, you look into the inner most namespace first and if it does not find
any then the outer for
overl
gcc-3.4.3 fails to accept this valid program:
namespace Fwk {
int valueToStrep( char const * ) { return 100;}
}
using Fwk::valueToStrep;
namespace Foo {
int valueToStrep( int ) { return 200; }
int foo2() { return valueToStrep( "hello" ); }
}
If you comment out the second "valueToStrep" func
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
22:03 ---
Actually if you look into the email which David sent, you would see:
# 0 ""
#define __GXX_WEAK__
Which means there is weak support.
--
What|Removed |Added
--
--- Additional Comments From masse_nicolas at yahoo dot fr 2005-06-27
22:02 ---
h well. I made an include at the end of my file... it works now. But this is
not a nice solution I find.
Well, I'll continue that way for now, and wait for the export method to be
implemented. I will als
--- Additional Comments From dje at gcc dot gnu dot org 2005-06-27 22:01
---
AIX 5.2 does support weak, so I believe that there is something wrong with the
analysis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27
22:00 ---
(In reply to comment #22)
> (In reply to comment #21)
> > 2. (OTOH) Undefind situations are unhelpful the the users, they complicate
> >debugging, and make programming harder. Reducing rules that imply
>
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
21:59 ---
This is a regression in that you no longer can use the debug mode with
-fno-weak.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
21:02 ---
(In reply to comment #21)
> 1. Sometimes using "undefined" simplifies the compiler and improves
>generated code.
> 2. (OTOH) Undefind situations are unhelpful the the users, they complicate
>debuggin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
20:30 ---
And another testcase, this time with an array:
#include
template
struct function1
{
function1()
{
typeid(int[100]);
}
};
function1<1> b;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
20:28 ---
we get this ICE:
t.cc:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
And the ba
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27
20:28 ---
(In reply to comment #13)
> Invalid as the C++ standard says:
> " True if the type is modulo.203) A type is modulo if it is possible to add
> two positive numbers and
> have a result that wraps around to a t
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
20:22 ---
Reduced testcase:
#include
template
struct function1
{
function1(void (*f)(void))
{
typeid(int (*)(char&));
}
};
void inputclassifier(void){}
function1<1> b(inputclassifier) ;
-frepo is o
Hi,
Has anyone seen this?
When a prototyped function of var-arg is called without any arguments
to the variable part, "crxor 6,6,6" is not generated. "-O0
-mno-prototype" does NOT resolve the problem either.
test.c
int test(const char *a, ...);
void test1(const char *a)
{ test
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-27 19:47
---
Created an attachment (id=9162)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9162&action=view)
libstdc++.log for AIX, demonstrating issue
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
On systems without weak, debug mode tests will fail. This causes some
unpleasantness on AIX, for instance.
This can be verified on x86/linux using -fno-weak.
What needs to happen is that the debug mode tests should be smart enough to tell
if the underlying system doesn't support weak, so that the
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-27
19:41 ---
Testing patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
--
What|Removed |Added
Keywords||ice-on-valid-code
Summary|internal compiler error:|[4.0/4.1 Regression] [repo]
--
What|Removed |Added
GCC target triplet||i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22204
--- Additional Comments From pplppp at gmail dot com 2005-06-27 19:24
---
Created an attachment (id=9161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9161&action=view)
information specified in the bug reporting instructions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2220
Please see attached file for information specified in the bug reporting
instructions
--
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Com
--- Additional Comments From p dot obry at wanadoo dot fr 2005-06-27 18:50
---
Danny,
(In reply to comment #10)
> The patch that was committed to fix this is wrong.
>
> #ifdef TARGET_DLLIMPORT_DECL_ATTRIBUTES is always true. It is defined to 0
> for
> non-dll targets in defaults.h.
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 18:46 ---
Subject: Re: numeric_limits::is_modulo is inconsistend with gcc
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27
18:41 ---
I checked in the fix on cvs trunk.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27
18:41 ---
I checked this in to cvs trunk.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-27
18:40 ---
Subject: Bug 21540
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-27 18:40:17
Modified files:
libjava: ChangeLog
gcc/java : C
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-27
18:40 ---
Subject: Bug 13788
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-27 18:40:17
Modified files:
libjava: ChangeLog
gcc/java : C
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
18:34 ---
(In reply to comment #16)
> Thanks, I'm the author of . For all useful purposes, please
> Andrew go back and read the link I gave to RTH's message.
Yes and RTH's comment about trapping is wrong, because PP
The followign program should not abort on PPC because PPC has no trapping
instructions integer
division instruction.
#include
extern "C" void abort(void);
int main(void)
{
if ( std::numeric_limits::traps)
abort ();
}
--
Summary: std::numeric_limits::traps is wrong on PPC
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 18:27 ---
Subject: Re: numeric_limits::is_modulo is inconsistend with gcc
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06
--- Additional Comments From gdr at gcc dot gnu dot org 2005-06-27 18:25
---
Andrew is being silly.
--
What|Removed |Added
Status|RESOLVED|UN
The description of the parameter max-variable-expansions-in-unroller in
param.def contains a lot of white space between "of" and "times" and between
"expanded" and "during". It should just be a single space there I suppose.
--
Summary: Superfluous space in description of max-variable-
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 18:23 ---
Subject: Re: numeric_limits::is_modulo is inconsistend with gcc
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 18:19 ---
Subject: Re: numeric_limits::is_modulo is inconsistend with gcc
"pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes:
| Subject: Re: numeric_limits::is_modulo is inconsistend with gcc
|
|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
18:08 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154
In the po files for version 4.0.1-b20050607 there are two strings from
params.def:
"how much can given compilation unit grow because of the inlining (in percent)"
and
"expense of call operation relative to ordinary aritmetic operations"
All other description strings in this context begin wit
--- Additional Comments From schlie at comcast dot net 2005-06-27 18:00
---
(In reply to comment #13)
> Invalid as the C++ standard says:
> " True if the type is modulo.203) A type is modulo if it is possible to add
> two positive numbers and
> have a result that wraps around to a thir
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
17:34 ---
Invalid as the C++ standard says:
" True if the type is modulo.203) A type is modulo if it is possible to add two
positive numbers and
have a result that wraps around to a third number that is less. Genera
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
17:29 ---
(In reply to comment #7)
> Andrew --
>
> You do not seem to understand this PR. Please DO NOT close it.
> Your eagerness to close PRs is doing harms -- that was already debated
> last couple o weeks and I
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
17:21 ---
This is a regression and shows up every where.
--
What|Removed |Added
Status|UNC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
17:13 ---
*** Bug 21986 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
17:13 ---
Here is a reduced testcase:
MODULE module1
TYPE type1
INTEGER TYP1
END TYPE type1
END MODULE
MODULE module2
TYPE type2
INTEGER TYP2
END TYPE type2
END MODULE
MODULE mymodule
CONTAINS
SUBRO
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-06-27 17:09 ---
Subject: Re: [4.0/4.1 Regression] avr dwarf-2 support is broken for head
4.0/4.1
Hi Andrew,
One question about gcc policy: There exists a patch resolving 19885 since a
couple of weeks. The latest
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-27
17:05 ---
(In reply to comment #12)
> Why does ivcanon/tree-ssa-loop-niter gets this correct (at 128) but VRP
> cannot.
>
Wrong. scev fails to tell us that this variable may wrap around.
--
http://gcc.gnu.org/
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27
16:59 ---
I'm testing a fix.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tr
--- Additional Comments From pinskia at physics dot uc dot edu 2005-06-27
16:53 ---
Subject: Re: numeric_limits::is_modulo is inconsistend with gcc
On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote:
> | Actually it is modulo for all operations.
>
> But then do r
On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote:
| Actually it is modulo for all operations.
But then do read the comment as far as the loop optimizer is
concerned. It does not seem like it understands that it is modulo
arithmetic.
But that is because overflow is unde
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-27
16:52 ---
The problem here is that the code in patch_binop that
converts URSHIFT_EXPR to RSHIFT_EXPR modifies the type and
code of the tree in place -- but that is incorrect as it misses
the final cast back to a signed
--- Additional Comments From pcarlini at suse dot de 2005-06-27 16:37
---
N.B. This first part will go also in 4_0-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22102
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-27
16:36 ---
Subject: Bug 22102
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-27 16:35:51
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/inclu
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27
16:35 ---
In Comment #5 Andrew Pinski writes:
> Actually it is modulo for all operations.
> and INT_MAX/-1 does not raise a trap.
That was a typo on my part.
It was supposed to be INT_MIN/-1
INT_MAX/-1 does not re
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-27
16:32 ---
(In reply to comment #1)
> Why file this bug when the comments on the list say this is not a bug?
It's for the potentially long debate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-27
16:25 ---
mine
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc d
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 16:25 ---
Subject: Re: numeric_limits::is_modulo is inconsistend with gcc
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Actually it is modulo for all operations.
But then do read the commen
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Actually it is modulo for all operations.
But then do read the comment as far as the loop optimizer is
concerned. It does not seem like it understands that it is modulo
arithmetic.
| and INT_MAX/-1 does not raise a trap.
It that
--- Additional Comments From gdr at gcc dot gnu dot org 2005-06-27 16:21
---
(In reply to comment #1)
> INT_MAX/-1 is undefined.
> and signed overflow is undefined.
>
> Why file this bug when the comments on the list say this is not a bug?
(In reply to comment #5)
> Actually it is modu
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 16:09 ---
Subject: Re: numeric_limits::is_modulo is inconsistend with gcc
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I think we need to read:
| "ISO/IEC 10967-1 Language Independent Arithme
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
16:07 ---
Actually it is modulo for all operations.
and INT_MAX/-1 does not raise a trap.
--
What|Removed |Added
-
--- Additional Comments From gdr at integrable-solutions dot net
2005-06-27 16:06 ---
Subject: Re: numeric_limits::is_modulo is inconsistend with gcc
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| INT_MAX/-1 is undefined.
| and signed overflow is undefined.
|
| Why fi
--- Additional Comments From hurbain at cri dot ensmp dot fr 2005-06-27
15:45 ---
Sorry, no segfault of ld. My mistake - wrong compilation options.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:40 ---
I think we need to read:
"ISO/IEC 10967-1 Language Independent Arithmetic, part 1" since that is what
the standard references
for is_modulo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27
15:33 ---
This is a bug because std::numeric_limits::is_modulo
should be true only if singed overflow is defined.
This is not the case with gcc, because gcc does not have the
extension "signed oveflow == module" then i
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:23 ---
*** Bug 22198 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:23 ---
*** This bug has been marked as a duplicate of 21920 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:21 ---
INT_MAX/-1 is undefined.
and signed overflow is undefined.
Why file this bug when the comments on the list say this is not a bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
GCC does not have a proper modulo overflow semantics for signed
integral types.
1. The loop optimizer seems to assume that signed overflow does
not happen (or is undefined).
2. On x86 INT_MAX/-1 seems to trap (instead of implementing
modulo semantics).
In that case numeric_limits:is_modulo
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:17 ---
A better example as on 32bit targets long and int are the same size which
removes the casts:
extern long long int llabs (long long int __x) __attribute__ ((__const__));
int main()
{
int a,b;
foo(&a
--- Additional Comments From hurbain at cri dot ensmp dot fr 2005-06-27
15:14 ---
Well, ld do segfault now...
To be honest I don't know about C aliasing rules ;-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
15:06 ---
Does -fno-strict-aliasing help as you are violating C aliasing rules:
a128 = _mm_load_si128((__m128i *)a_storage);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
$ cat labs.c
extern long int labs (long int __x) __attribute__ ((__const__));
int main()
{
int a,b;
foo(&a, &b);
if (labs(a) > b)
return 1;
else
return 0;
}
is translated with
$ gcc -O3 -fdump-tree-optimized -S labs.c
into
:
foo (&a, &b);
return (int) (ABS_E
--- Additional Comments From hurbain at cri dot ensmp dot fr 2005-06-27
15:03 ---
Created an attachment (id=9160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9160&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22198
--
What|Removed |Added
Component|c |target
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
The attached code is OK with gcc 3.3.6 debian and gcc 4.0 without -O2 but does
not generate pmaddw
instruction with gcc 4.0 and -O2.
The compile line is
/usr/local/bin/gcc -save-temps -msse2 -Wall -O2 -o bug-report bug-report.c
and the values are NOT initialized in the gcc 4.0 -O2 setup.
--
--- Additional Comments From marc dot price at rd dot bbc dot co dot uk
2005-06-27 14:31 ---
Has this bug been fixed yet? Would really like to upgrade my linux box, but
can't because this bug prevents me from compiling a vital suite of software.
Can we bump-up the priority?
TIA
Marc
1 - 100 of 121 matches
Mail list logo
