(define_insn "mov"
[(set (match_operand:MVM 0 "vg_general_operand" "=r, , r, t, r")
(match_operand:MVM 1 "vg_general_operand" "r, r, t, r,
I"))]
""
"mov %0,%1")
When both match_operands mistakenly mention 0 (instead of 0 and 1 as above),
then ...
buil
--- Comment #9 from aaw at gcc dot gnu dot org 2007-08-18 06:26 ---
Fixed by change 127600.
--
aaw at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #6 from pault at gcc dot gnu dot org 2007-08-18 06:04 ---
This one is a real head-banger. The array element reference is being
completely ignored in translation. I tried simplifying it by grabbing out the
array component and attaching the array reference to it. The resulti
This report was prompted by a mail on the lkml which was suggesting to
hand-craft memset: http://lkml.org/lkml/2007/8/17/309 . So I wondered if the
code generated for __builtin_memset was any good, and could be used instead of
hand-crafted code. I tested with (Debian) GCC 3.4.6, 4.1.3, 4.2.1, and a
--- Comment #2 from ian at airs dot com 2007-08-18 04:19 ---
Thanks for the explanation. That is new to me.
I am now going to reopen this bug because the error message is terrible. There
is no anonymous or incomplete type here. gcc should perhaps print something
like
error: invalid
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-08-18 01:25
---
(In reply to comment #11)
> The main concern on the recent LKML thread appeared to be code size rather
> than
> speed.
One should note this only helps CISC based processors, it will not help stuff
like PowerPC any
--- Comment #12 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:23 ---
(In reply to comment #9)
> s/debian/Ubuntu/
Please accept my apologies for skipping that step -- I wasn't aware of this.
Should I replicate this bug at Ubuntu, or is this strictly advice for future
bug
--- Comment #11 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:21 ---
(In reply to comment #10)
> Actually as I understand it, the expanded version is slightly faster under
> newer x86's anyways as they don't have an extra decode stage.
The main concern on the recent LKML
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-18 01:13
---
Actually as I understand it, the expanded version is slightly faster under
newer x86's anyways as they don't have an extra decode stage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-18 01:12 ---
s/debian/Ubuntu/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-18 01:11 ---
PS you should have reported this first to debian since you are using their
modified version of GCC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-18 01:10 ---
One should note this is actually hard to do without changing the code for 3506
also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:04 ---
(In reply to comment #4)
> It is still the same issue.
Perhaps I am missing something, but I don't know of any hardware that would
react differently to this two-instruction sequence:
movli,
--- Comment #5 from segher at kernel dot crashing dot org 2007-08-18 00:31
---
> It is still the same issue.
>
> *** This bug has been marked as a duplicate of 3506 ***
It isn't the same issue. The submitter of #3506 claimed the code
that GCC currently generates is incorrect, which o
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-18 00:21 ---
>omewhat also related, "(void)x;" still accesses memory when x is volatile --
> I suppose this might be desirable, however.
It is because you say to load from x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-18 00:12
---
*** Bug 33102 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-18 00:12 ---
It is still the same issue.
*** This bug has been marked as a duplicate of 3506 ***
*** This bug has been marked as a duplicate of 3506 ***
--
pinskia at gcc dot gnu dot org changed:
What|Remove
--- Comment #3 from segher at kernel dot crashing dot org 2007-08-18 00:12
---
(In reply to comment #1)
> volatile != atomic.
And that is relevant why? Paul is perfectly aware of this, btw.
There might be other reasons why GCC doesn't want to do this
optimisation, but this isn't one
--- Comment #2 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
00:11 ---
Hmmm... I wasn't asking for volatile to be atomic, just for it to avoid
generating unnecessary code.
--
paulmck at linux dot vnet dot ibm dot com changed:
What|Removed
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-18 00:05
---
*** Bug 33102 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-18 00:05 ---
volatile != atomic.
*** This bug has been marked as a duplicate of 3506 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Source code:
--
volatile int i;
int j;
int testme(void)
{
return i <= 1;
}
int testme2(void)
{
return j <= 1;
}
--
Compiler command line: "cc -S -O torvalds.c"
--
Expected results: volatile accesses not moved past sequence points,
optimization o
--- Comment #29 from pinskia at gcc dot gnu dot org 2007-08-17 23:33
---
*** Bug 33101 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 23:33 ---
This is not valid code.
*** This bug has been marked as a duplicate of 9278 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
This C++ test case works with gcc 4.1.1. With gcc 4.2 and with mainline it
gets an inexplicable error.
typedef void v;
typedef v (*pf)(v);
foo.cc:2: error: has incomplete type
foo.cc:2: error: invalid use of v
--
Summary: C++ error on valid code: has incomplete type
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 22:15
---
Fixed on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 22:15
---
Fixed on the trunk.
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-17 22:15
---
Subject: Bug 28989
Author: pinskia
Date: Fri Aug 17 22:14:47 2007
New Revision: 127603
URL: http://gcc.gnu.
--- Comment #2 from tromey at gcc dot gnu dot org 2007-08-17 22:08 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #8 from aaw at gcc dot gnu dot org 2007-08-17 21:42 ---
Subject: Bug 31749
Author: aaw
Date: Fri Aug 17 21:42:38 2007
New Revision: 127600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127600
Log:
PR c++/31749
gcc/cp/
* name-lookup.c (do_non
--- Comment #15 from pcarlini at suse dot de 2007-08-17 21:40 ---
Already fixed in 4_2-branch and mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #14 from paolo at gcc dot gnu dot org 2007-08-17 21:38 ---
Subject: Bug 32190
Author: paolo
Date: Fri Aug 17 21:38:40 2007
New Revision: 127599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127599
Log:
2007-08-17 Paolo Carlini <[EMAIL PROTECTED]>
PR c++/3
--- Comment #13 from paolo at gcc dot gnu dot org 2007-08-17 21:38 ---
Subject: Bug 32190
Author: paolo
Date: Fri Aug 17 21:38:19 2007
New Revision: 127598
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127598
Log:
2007-08-17 Paolo Carlini <[EMAIL PROTECTED]>
PR c++/3
--- Comment #1 from tromey at gcc dot gnu dot org 2007-08-17 21:32 ---
Looks like directives.c:parse_include is not handling the
"dependency" case correctly.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from paolo at gcc dot gnu dot org 2007-08-17 21:31 ---
Subject: Bug 32190
Author: paolo
Date: Fri Aug 17 21:31:40 2007
New Revision: 127597
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127597
Log:
2007-08-17 Paolo Carlini <[EMAIL PROTECTED]>
PR c++/3
I now get this during bootstrap on Solaris x86 using the native linker
(/usr/ccs/bin/ld):
ld: fatal: unwind table: file
/u01/var/tmp/gcc_trunk_svn/gcc_20070817/./gcc/amd64/crtend.o: section
.eh_frame: bad cie version 0: offset 0x0
collect2: ld returned 1 exit status
gmake[5]: *** [libgcc_s.so] Er
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-17 20:47 ---
Subject: Bug 32112
Author: paolo
Date: Fri Aug 17 20:46:59 2007
New Revision: 127596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127596
Log:
/cp
2007-08-17 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #5 from janis at gcc dot gnu dot org 2007-08-17 20:44 ---
Why use "%.9e", "%.17e", and "%.36Le" to write the binary float values to a
string, instead of using lengths of FLT_DIG, DBL_DIG, and LDBL_DIG? For
i686-linux those are 6, 15, and 18.
--
http://gcc.gnu.org/bugzil
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-17 20:42 ---
The IR is the same but scev did something different:
Visiting statement:
p_10 = i.0_9 - 1B;
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = p_10)
(get_scalar_evolution
(scalar = p_10)
(scalar_evolution =
--- Comment #5 from dnovillo at google dot com 2007-08-17 20:37 ---
Subject: Re: [4.2 Regression] Scalar evolutions
confusing VRP with pointer values that wrap around
On 8/17/07 4:34 PM, pinskia at gcc dot gnu dot org wrote:
> --- Comment #4 from pinskia at gcc dot gnu dot org 20
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-17 20:34 ---
Oh you are correct but this still worked in 4.1.1 though, I have not looked
into what changed between 4.1.1 and 4.2.0 with respect of scev yet.
--
pinskia at gcc dot gnu dot org changed:
What|Remo
--- Comment #3 from dnovillo at google dot com 2007-08-17 20:27 ---
Subject: Re: [4.2 Regression] Scalar evolutions
confusing VRP with pointer values that wrap around
On 8/17/07 4:20 PM, pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org 20
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 20:20 ---
Exposed by:
2006-02-07 Jeff Law <[EMAIL PROTECTED]>
Which added VRP after IV-OPTs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 20:18 ---
Confirmed (and yes this was fixed by PtrPlus).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from patchapp at dberlin dot org 2007-08-17 20:15 ---
Subject: Bug number PR20441
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01151.html
--
http://gcc.gnu.org/bugzilla/sh
The following test case is miscompiled with GCC 4.2:
extern void abort (void);
volatile int N = 5;
void foo (void)
{
int i;
char *p, value[10];
value[0] = 0x42;
for (i = 0; i < N; i++)
if (i > 0)
{
p = (char *)i - 1;
*(value + (int) p) = (char) i;
}
if
--- Comment #1 from janis at gcc dot gnu dot org 2007-08-17 18:21 ---
Current mainline (revision 127590) still gets this ICE for i686-pc-linux-gnu
with either bid or dpd decimal float support. The current line number for the
ICE is reload1.c:2001.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #12 from pcarlini at suse dot de 2007-08-17 18:09 ---
Hi Giovanni, any update on this?
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #11 from igodard at pacbell dot net 2007-08-17 17:25 ---
Subject: Re: wrong error recovery on parsing template arguments
Seems impractical. I don't have access to the old versions or mainline,
and don't know what magic to put in the source for your system to use.
I'm sure
--- Comment #2 from drow at gcc dot gnu dot org 2007-08-17 17:24 ---
Subject: Bug 31884
Author: drow
Date: Fri Aug 17 17:24:22 2007
New Revision: 127590
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127590
Log:
PR testsuite/31884
* testsuite/ext/pb_ds/example/pr
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from pcarlini at suse dot de 2007-08-17 16:40 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from paolo at gcc dot gnu dot org 2007-08-17 16:39 ---
Subject: Bug 33098
Author: paolo
Date: Fri Aug 17 16:39:10 2007
New Revision: 127588
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127588
Log:
2007-08-17 Chris Fairles <[EMAIL PROTECTED]>
PR libstd
--- Comment #3 from pcarlini at suse dot de 2007-08-17 16:31 ---
Yes, let's patch-up this, but really I have to finish the builtin, this is only
temporary.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2007-08-17 16:15 ---
This is fixed in the active branches. Now the diagnostic is:
18207.C: In constructor 's::s()':
18207.C:8: error: no matching function for call to 'm::m()'
18207.C:4: note: candidates are: m::m(const m&)
18207.C: In constru
--- Comment #2 from chris dot fairles at gmail dot com 2007-08-17 15:48
---
Created an attachment (id=14071)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14071&action=view)
test case that gives compile error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33098
--- Comment #1 from chris dot fairles at gmail dot com 2007-08-17 15:48
---
Created an attachment (id=14070)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14070&action=view)
patch to fix compile error when using pointers with is_convertible
--
http://gcc.gnu.org/bugzilla/show
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure CC=gcc43 CXX=g++43 --program-suffix=43
--disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20070816 (experimental)
The following code:
#include
int main() {
bool b = std::is_convertible::value;
}
--- Comment #2 from pcarlini at suse dot de 2007-08-17 15:37 ---
FWIW, Comeau gives very similar errors:
"ComeauTest.c", line 3: error: incomplete type is not allowed
union B b;
^
"ComeauTest.c", line 6: error: tag kind of class or struct is incompatible with
--- Comment #6 from pcarlini at suse dot de 2007-08-17 15:30 ---
I guess we can indeed close this one as fixed in mainline...
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #5 from patchapp at dberlin dot org 2007-08-17 15:10 ---
Subject: Bug number PR32881
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01078.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #11 from patchapp at dberlin dot org 2007-08-17 15:10 ---
Subject: Bug number PR31298
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01081.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #4 from patchapp at dberlin dot org 2007-08-17 15:10 ---
Subject: Bug number PR32875
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01077.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from ian at airs dot com 2007-08-17 14:31 ---
This patch fixes the problem and passes the g++ testsuite.
Index: cp/decl.c
===
--- cp/decl.c (revision 127491)
+++ cp/decl.c (working copy)
@@ -4963,7 +4963,
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-17 13:21 ---
> Oh, sh**, I didn't think about simplification.
> Well, I don't see an easy way to
> have error messages at runtime, so we should simply skip those.
Good idea. As long as the compiler does the right thing (TM) we do
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-17 13:10
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-08-17 13:09
---
Subject: Bug 33079
Author: fxcoudert
Date: Fri Aug 17 13:09:23 2007
New Revision: 127584
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127584
Log:
PR fortran/33079
* intrinsics/string_in
--- Comment #2 from asl at math dot spbu dot ru 2007-08-17 12:49 ---
Quick example of the problem:
>
QI
size
unit size
align 8 symtab 0 alias set -1
arg-types
chain >>
pointer_to_this >
addressable public external
--- Comment #10 from zadeck at naturalbridge dot com 2007-08-17 12:48
---
Subject: Re: [4.3 Regression] ICE with -O2 -fsee
wouter dot vermaelen at scarlet dot be wrote:
> --- Comment #9 from wouter dot vermaelen at scarlet dot be 2007-08-17
> 12:44 ---
> Here is a simpler te
--- Comment #9 from wouter dot vermaelen at scarlet dot be 2007-08-17
12:44 ---
Here is a simpler testcase:
int f(int i) { return 100LL / (1 + i); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
--- Comment #1 from asl at math dot spbu dot ru 2007-08-17 12:42 ---
Created an attachment (id=14069)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14069&action=view)
Quick and dirty patch
Attached is quick and dirty patch to populate symbol with arguments. It seems
to be incomple
Recently I discovered, that gfortran FE creates invalid decl trees for exteranl
intrinsics: only return value is added to arg chain, and none of the actual
arguments. This can potentially break much stuff, because of inconsistency of
CALL_EXPR and corresponding fndecl.
This was due to the followin
--- Comment #4 from raselmsh at hotmail dot com 2007-08-17 12:04 ---
I took a look at ccache again, and it is definitely not what I was thinking of.
ccache is more aimed at accelerating multiple full compile rounds of the same
package, whereas I was thinking of improving dependency hand
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-17 11:24
---
Oh, sh**, I didn't think about simplification. Well, I don't see an easy way to
have error messages at runtime, so we should simply skip those. We won't have
any diagnostic, but no compiler that I know of does it,
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-17 10:50 ---
(In reply to comment #9)
> Subject: Re: wrong error recovery on parsing template arguments
>
> Begging your pardon, but what's wrong with the one I put in already?
>
Nothing is wrong, but to be useful for GCC tests
--- Comment #2 from joseph at codesourcery dot com 2007-08-17 10:37 ---
Subject: Re: [4.1/4.2/4.3 Regression] spurious exceptions
with -ffloat-store
On Fri, 17 Aug 2007, pinskia at gcc dot gnu dot org wrote:
> For one, I don't think " __real__ X = R; __imag__ X = C; " is really nice
--- Comment #9 from igodard at pacbell dot net 2007-08-17 10:37 ---
Subject: Re: wrong error recovery on parsing template arguments
Begging your pardon, but what's wrong with the one I put in already?
Ivan
manu at gcc dot gnu dot org wrote:
> --- Comment #8 from manu at gcc dot g
--- Comment #8 from manu at gcc dot gnu dot org 2007-08-17 10:28 ---
Ivan, would you like to write, test and post the testcase? Once it is approved
I can commit it for you (with your name of course!).
A starting point will be http://gcc.gnu.org/wiki/HowToPrepareATestcase, if you
need fur
--- Comment #7 from pcarlini at suse dot de 2007-08-17 10:26 ---
Sure, I'll take care of that...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-17 10:24 ---
(In reply to comment #5)
> This is now fixed both in mainline and in 4_2-branch:
>
> 32190.C: In function 'int main()':
> 32190.C:5: error: template argument 1 is invalid
>
> at this point, not being a regression, I t
--- Comment #5 from pcarlini at suse dot de 2007-08-17 10:22 ---
This is now fixed both in mainline and in 4_2-branch:
32190.C: In function 'int main()':
32190.C:5: error: template argument 1 is invalid
at this point, not being a regression, I think we can close it.
--
pcarlini at
--- Comment #4 from manu at gcc dot gnu dot org 2007-08-17 10:15 ---
(In reply to comment #3)
>
> void use(const int *a)
> {
> int *b = (int*)a;
Andrew, you are right. I tend to forget how fragile is 'const', even in C++.
So, then this is invalid and thus it is PR10138.
--
http:
--- Comment #3 from pcarlini at suse dot de 2007-08-17 09:36 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-17 09:35 ---
Subject: Bug 32870
Author: paolo
Date: Fri Aug 17 09:35:23 2007
New Revision: 127581
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127581
Log:
/cp
2007-08-17 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #4 from pcarlini at suse dot de 2007-08-17 09:30 ---
Fixed for 4.2.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 09:29 ---
/* An in-class declaration of a static data member should be
external; it is only a declaration, and not a definition. */
if (init == NULL_TREE)
gcc_assert (DECL_EXTERNAL (decl));
Conf
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-17 09:28 ---
Subject: Bug 33084
Author: paolo
Date: Fri Aug 17 09:28:09 2007
New Revision: 127580
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127580
Log:
2007-08-17 Johannes Willkomm <[EMAIL PROTECTED]>
PR li
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 09:27 ---
For one, I don't think " __real__ X = R; __imag__ X = C; " is really nice
looking. Now if the person did:
*(double*) &X = R; ((double*) & X)[1] = C;
it might be a different story but then again X is still defined
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-17 09:27 ---
Subject: Bug 33084
Author: paolo
Date: Fri Aug 17 09:27:06 2007
New Revision: 127579
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127579
Log:
2007-08-17 Johannes Willkomm <[EMAIL PROTECTED]>
PR li
--- Comment #3 from pcarlini at suse dot de 2007-08-17 09:23 ---
Hi Volker. I will be away for some days on vacations... In the meanwhile, if
you could double check that we really want the fix for 27211 (not a regression)
on the branches and, in case, take care of the backport, it would
--- Comment #15 from manu at gcc dot gnu dot org 2007-08-17 09:17 ---
This seems to me a duplicate of PR179. I am going to add a dependency to
remember to check this PR when PR179 gets fixed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 09:15 ---
Fixed by:
2007-08-14 Daniel Berlin <[EMAIL PROTECTED]>
* tree-pass.h (PROP_pta): Removed.
(TODO_rebuild_alias): New.
(pass_may_alias): Removed.
* tree-ssa-ccp.c (execute_fold_all_bu
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 09:03
---
*** Bug 33096 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 09:03 ---
*** This bug has been marked as a duplicate of 11001 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from burnus at gcc dot gnu dot org 2007-08-17 08:14 ---
Rejecting "operator(.procedure.)" has been fixed by PR33072.
Accepting multiple renames/imports of an operator ("operator(.op.),
operator(.myop.)=>operator(.op.)") is fixed by the submitted patch
http://gcc.gnu.org/m
--- Comment #1 from slava at factorcode dot org 2007-08-17 07:56 ---
Created an attachment (id=14068)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14068&action=view)
Test case
This is a test case for the bug. Compile with -O1, -O2 or -O3 to trigger it.
With -O0, it compiles fine
Compile the following program with -O3 on FreeBSD or Linux, x86:
///
#include
#include
register long foo asm("esi");
register long bar asm("edi");
char * crash_me_baby(char *str) {
char *path = malloc(1024 + strlen(str));
return path;
}
///
This resul
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aldot at gcc dot gnu dot org
|dot org
97 matches
Mail list logo
