--- Comment #8 from aaronavay62 at aaronwl dot com 2007-04-05 08:05 ---
What is the status on this? I'm pretty sure this is a regression; it would be
great if this fix could get into 4.2, but it might be too late for that. This
is a serious problem for many/most users on Windows as it
--- Comment #3 from ubizjak at gmail dot com 2007-04-05 08:48 ---
> There is no corresponding define_expand for this pattern. Many define_insn
> patterns without define_expand don't call ix86_binary_operator_ok. Will that
> be a problem?
Those are sse builtins and are expanded via ix86_
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-05 08:28 ---
(In reply to comment #1)
> The problem seems to occur with procedure pointers to ENTRY points
>From a quick look at decl.c(get_proc_name), the modifications that I added, to
get module procedures with entries to wor
--- Comment #4 from ubizjak at gmail dot com 2007-04-05 09:13 ---
(In reply to comment #3)
> There is indeed a pattern without this check - sse2_pmaddwd.
> Due to %, it is commutative, so check for PLUS of V8HI mode would be OK.
Please also change operands 1 and 2 of sdot_prodv8hi expa
--- Comment #1 from pault at gcc dot gnu dot org 2007-04-05 09:31 ---
Created an attachment (id=13330)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13330&action=view)
Fix for the PR
The ICE is due to a gcc_assert blocking dummy procedures from having alternate
returns. The fix,
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-05 09:51 ---
(In reply to comment #3)
> From the standard:
> "5.2.9 PARAMETER statement
> [...]
> The named constant shall have its type, type parameters, and shape specified
> in
> a prior specification of the specification-part
--- Comment #3 from pcarlini at suse dot de 2007-04-05 10:03 ---
In order to speed-up the process, can you edit ext/type_traits.h to not include
and changing std::streamsize to int and report how it goes? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
--- Comment #2 from Klaas dot Vantournhout at UGent dot be 2007-04-05
10:35 ---
What is the difference then between 32bit and 64bit? In the 32bit it works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31484
--- Comment #13 from bonzini at gnu dot org 2007-04-05 11:01 ---
So this is an unstable sorting. Adding dnovillo.
--
bonzini at gnu dot org changed:
What|Removed |Added
Hi,
It seems that a va_list is messed up when doing multiple functioncalls
containing the va_list. This only occurs in the 64bit versions of g++ and does
NOT occur in the 32bit versions.
This has been seen in versions 4.1.1 and 4.1.2
Below is all the suff you need (buildparameters, testcode and
--- Comment #4 from pluto at agmk dot net 2007-04-05 10:42 ---
(In reply to comment #3)
> In order to speed-up the process, can you edit ext/type_traits.h to not
> include
> and changing std::streamsize to int and report how it goes? Thanks.
>
this change causes another error:
+ /us
--- Comment #2 from pcarlini at suse dot de 2007-04-05 09:59 ---
Yes, streamsize shouldn't be there, I noticed that as part of a large
rearrangment of the headers in mainline and fixed it. I'm porting that specific
bit to 4_2-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31
--- Comment #1 from schwab at suse dot de 2007-04-05 10:31 ---
Not a bug. You must call va_start/va_end whenever you want to reuse a va_list.
--
schwab at suse dot de changed:
What|Removed |Added
---
--- Comment #3 from schwab at suse dot de 2007-04-05 10:47 ---
7.15 Variable arguments
3 [...] The object ap may be passed as an argument to another function; if that
function invokes the va_arg macro with parameter ap, the value of ap in the
calling function is indeterminate and shall
--- Comment #12 from ubizjak at gmail dot com 2007-04-05 11:00 ---
(In reply to comment #11)
> with -msse compile flag. Note different variable suffixes that create
> different
> sort order. This is (IMO) due to fact that -msse enables lots of additional
> __builtin functions (these ca
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-04-05 11:05
---
Could you easily test it with a 4.1 compiler? I would like to be sure it's not
a regression in 4.2 with respect to 4.1, in which case we should try to fix it.
If the bug was also present in 4.1, then we can close
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-05 11:01
---
(In reply to comment #2)
> Or even better is there any chance to get that backported to the release
> branches?
It seems to be a regression wrt g77, which means it's possible that it will be
backported.
--
h
--- Comment #11 from ubizjak at gmail dot com 2007-04-05 10:58 ---
(In reply to comment #10)
> I would look at the lreg output, which contains the results of regclass.
No, the difference is due to ssa pass that generates:
# v1z_10 = PHI
# v1y_9 = PHI
# v1x_8 = PHI
# i_7 = PH
--- Comment #4 from ubizjak at gmail dot com 2007-04-05 12:21 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-04-05 11:17
---
The segfault happens because we come into gfc_int2int to convert the value from
TRANSFER into the integer(kind=1). But TRANSFER isn't simplified at this point,
although it should have been, which leads to referenc
--- Comment #5 from pcarlini at suse dot de 2007-04-05 11:39 ---
(In reply to comment #4)
> (In reply to comment #3)
> > In order to speed-up the process, can you edit ext/type_traits.h to not
> > include
> > and changing std::streamsize to int and report how it goes? Thanks.
> >
>
>
--- Comment #4 from ubizjak at gmail dot com 2007-04-05 12:29 ---
(In reply to comment #2)
> To implement this optimization, some support from assembler is needed. When
> displacement overflows 8bit, assembler should substitute "jecxz" with
> equivalent "test/jmp rel{16,32}" sequence.
--- Comment #14 from dnovillo at gcc dot gnu dot org 2007-04-05 12:49
---
(In reply to comment #11)
> So, why does SSA pass have to interfere with computation dataflow? This
> interferece makes things worse and effectively takes away user's control on
> the
> flow of data.
>
Huh? H
Compilation of the attached code yields an ICE in certain cases.
Environment:
System: Linux chii 2.6.20 #3 SMP Sun Feb 11 23:52:47 EET 2007 x86_64 GNU/Linux
Architecture: x86_64
host: x86_64-pc-linux-gnu
build: x86_64-pc-linux-gnu
target: x86_64-pc-linux-gnu
configured with: ../src/conf
--- Comment #5 from steven at gcc dot gnu dot org 2007-04-05 12:54 ---
Can we compute the displacement reliable enough to say that it is smaller than
some other number (e.g. 64)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29793
I get an ICE with gfortran on the following code:
$ cat ice.F
SUBROUTINE PHLOAD (READER,*)
IMPLICIT NONE
EXTERNAL READER
CALL READER (*1)
1RETURN 1
END
$ gfortran -S ice.F
ice.F: In function 'phload':
ice.F:1: internal compiler error: in gfc_conv_functio
--- Comment #2 from M dot Froehlich at science-computing dot de 2007-04-05
10:56 ---
Great!
Thank you very much!
... open source projects have the fastest response times!
The patch does not apply with 'patch' to gcc-4.1.2, but I could well hand patch
that. Do you expect problems when I
--- Comment #6 from pcarlini at suse dot de 2007-04-05 11:49 ---
Created an attachment (id=13331)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13331&action=view)
Patch
This is the patch which I'm finishing testing in the branch and should be
applied anyway, irrespective of this s
Considering that "complex" turns basically any basic type into a vector type,
complex number addition and subtraction could utilize SSE instructions to
perform the operation on real and imaginary parts simultaneously. (Only applies
to addition and subtraction.)
Code:
#include
typedef float comp
--- Comment #15 from bonzini at gnu dot org 2007-04-05 13:03 ---
Transformations do not, but out-of-SSA could. Is there a way to ensure
ordering of PHI functions unlike what Uros's dumps suggest?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
--- Comment #8 from patchapp at dberlin dot org 2007-04-05 13:05 ---
Subject: Bug number PR29507
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-04/msg00170.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #7 from ubizjak at gmail dot com 2007-04-05 13:06 ---
Not marked as a regression on branches, so fixed.
(The patch from Comment #6 applies cleanly on all branches. It is up to RM to
decide if this can still go into 4.1.2 and 4.2.)
--
ubizjak at gmail dot com changed:
--- Comment #4 from patchapp at dberlin dot org 2007-04-05 13:15 ---
Subject: Bug number PR31483
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-04/msg00171.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #16 from dnovillo at redhat dot com 2007-04-05 13:15 ---
Subject: Re: Floating point computation far slower
for -mfpmath=sse
bonzini at gnu dot org wrote on 04/05/07 08:03:
> Is there a way to ensure ordering of PHI functions unlike what Uros's
> dumps suggest?
No.
I al
--- Comment #11 from arcangelpip at hotmail dot com 2007-04-05 13:21
---
I'm sorry to drag this back up again, but it happened again on 4.2.
Again it is with the gettext package which seems to love me so much.
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc-4.2/co
--- Comment #9 from burnus at gcc dot gnu dot org 2007-04-05 13:27 ---
This probably will work automatically if inter-file checking is implemented,
but if not, here is an invalid example which should be rejected:
-
SUBROUTINE PHLOAD (READER,*)
IMPLICIT NONE
EXTE
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-05 14:13 ---
The patch is wrong since the PRIVATE/PUBLIC statement is also allowed for type:
module foo
type t
private
integer, public :: foo
end type t
end module foo
Actually, currently gfortran also invalidly rejects the
--- Comment #17 from amacleod at redhat dot com 2007-04-05 14:23 ---
Is the output from .optimized different? (once the ssa versions numbers have
been stripped). Those PHIs should be irrelevant, the question is whether the
different versioning has any effect.
The only way I can t
--- Comment #7 from pcarlini at suse dot de 2007-04-05 14:43 ---
Can be fixed by packporting a few additional forthcoming clean-up bits from
mainline...
--
pcarlini at suse dot de changed:
What|Removed |Added
---
Hi,
here's an annoying one. Default initializing a
character array in a derived type leads to zero
padded strings instead of space-padded ones.
E.g.
! This works correctly:
character(len=16) ::tdefi(2) = (/'0z1jan','1hr '/)
! 1234567890
--- Comment #1 from anlauf at gmx dot de 2007-04-05 14:51 ---
Created an attachment (id=13332)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13332&action=view)
Demo code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31487
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-05 15:00 ---
Subject: Bug 31292
Author: pault
Date: Thu Apr 5 15:00:27 2007
New Revision: 123517
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123517
Log:
2007-04-05 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-05 15:06 ---
Subject: Bug 31483
Author: pault
Date: Thu Apr 5 15:06:15 2007
New Revision: 123518
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123518
Log:
2007-04-05 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from hjl at lucon dot org 2007-04-05 15:12 ---
(In reply to comment #3)
> > There is no corresponding define_expand for this pattern. Many define_insn
> > patterns without define_expand don't call ix86_binary_operator_ok. Will that
> > be a problem?
>
> Those are sse buil
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-05 15:34 ---
note you can also use va_copy but that is c99.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31484
--- Comment #6 from ubizjak at gmail dot com 2007-04-05 16:27 ---
(In reply to comment #5)
> Can we compute the displacement reliable enough to say that it is smaller than
> some other number (e.g. 64)?
Good idea!
The (untested) patch that handles SImode compares is at
http://gcc.gnu.o
--- Comment #18 from ubizjak at gmail dot com 2007-04-05 16:39 ---
(In reply to comment #17)
> Is the output from .optimized different? (once the ssa versions numbers have
> been stripped). Those PHIs should be irrelevant, the question is whether the
> different versioning has any eff
--- Comment #4 from aesok at gcc dot gnu dot org 2007-04-05 16:43 ---
Subject: Bug 25448
Author: aesok
Date: Thu Apr 5 16:43:35 2007
New Revision: 123519
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123519
Log:
PR target/25448
* config/avr/avr.c (avr_handle_fn
--- Comment #6 from ubizjak at gmail dot com 2007-04-05 16:48 ---
(In reply to comment #5)
> So anothe word is those patterns are used by ix86_expand_binop_builtin()
> and won't be generated automatically. Will be "sse2_umulv2siv2di3"
> generated automatically? If yes, what makes it dif
--- Comment #7 from hjl at lucon dot org 2007-04-05 16:54 ---
(In reply to comment #6)
> (In reply to comment #5)
>
> > So anothe word is those patterns are used by ix86_expand_binop_builtin()
> > and won't be generated automatically. Will be "sse2_umulv2siv2di3"
> > generated automatic
--- Comment #6 from aesok at gcc dot gnu dot org 2007-04-05 16:56 ---
Subject: Bug 25448
Author: aesok
Date: Thu Apr 5 16:56:43 2007
New Revision: 123521
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123521
Log:
PR target/25448
* config/avr/avr.c (avr_handle_fn
--- Comment #5 from aesok at gcc dot gnu dot org 2007-04-05 16:50 ---
Subject: Bug 25448
Author: aesok
Date: Thu Apr 5 16:50:27 2007
New Revision: 123520
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123520
Log:
PR target/25448
* config/avr/avr.c (avr_handle_fn
--- Comment #7 from aesok at gcc dot gnu dot org 2007-04-05 16:59 ---
Fixsed in 4.1.3, 4.2 and 4.3.
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from amacleod at redhat dot com 2007-04-05 17:24 ---
what are you using for a compiler? Im using a mainline from mid march, and with
it, my .optimized files diff exactly the same, and I get the aforementioned
time differences in the executables.
(sse.c and sse-bad.c are s
--- Comment #8 from hjl at lucon dot org 2007-04-05 17:54 ---
(In reply to comment #4)
> (In reply to comment #3)
>
> > There is indeed a pattern without this check - sse2_pmaddwd.
> > Due to %, it is commutative, so check for PLUS of V8HI mode would be OK.
>
> Please also change opera
--- Comment #4 from eweddington at cso dot atmel dot com 2007-04-05 18:07
---
This is a duplicate of bug #22133.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29851
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-05 19:15 ---
*** This bug has been marked as a duplicate of 22133 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-05 19:15 ---
*** Bug 29851 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #20 from ubizjak at gmail dot com 2007-04-05 19:39 ---
(In reply to comment #19)
> what are you using for a compiler? Im using a mainline from mid march, and
gcc version 4.3.0 20070404 (experimental) on i686-pc-linux-gnu
with
> it, my .optimized files diff exactly the same
.../libjava/classpath/include/jvmti.h:1242: warning: can not pass objects
of non-POD type 'struct va_list' through '...'; call will abort at runtime
Not sure yet whether this is a target problem or not.
--
Summary: va_list considered non-POD
Product: gcc
Version
--- Comment #9 from ubizjak at gmail dot com 2007-04-05 19:50 ---
(In reply to comment #8)
> > Please also change operands 1 and 2 of sdot_prodv8hi expander to
> > register_operand to avoid further suprises.
> >
>
> I am not sure if there is an issue since op0 of sse2_pmaddwd must be
--- Comment #12 from aoliva at gcc dot gnu dot org 2007-04-05 19:50 ---
Subject: Bug 22156
Author: aoliva
Date: Thu Apr 5 19:50:34 2007
New Revision: 123524
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123524
Log:
PR middle-end/22156
* tree-sra.c (struct sra_elt): Add in_bitf
--- Comment #10 from hjl at lucon dot org 2007-04-05 20:05 ---
(In reply to comment #9)
> (In reply to comment #8)
>
> > > Please also change operands 1 and 2 of sdot_prodv8hi expander to
> > > register_operand to avoid further suprises.
> > >
> >
> > I am not sure if there is an issu
--- Comment #11 from hjl at lucon dot org 2007-04-05 20:06 ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> >
> > > > Please also change operands 1 and 2 of sdot_prodv8hi expander to
> > > > register_operand to avoid further suprises.
> > > >
> >
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-05 20:28 ---
Most likely this is because va_list is represented as an array for alpha and a
couple other targets. So maybe it might be just the warning is incorrect but
it is still undefined.
--
http://gcc.gnu.org/bugzilla/
--- Comment #2 from rth at gcc dot gnu dot org 2007-04-05 21:45 ---
It is *not* represented as an array on Alpha.
And even if it were, it wouldn't be undefined. Passing va_list by
value is non-portable, but certainly not undefined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-05 21:49 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-05 21:58 ---
I submitted a patch for this in:
http://gcc.gnu.org/ml/fortran/2007-04/msg00016.html
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31293
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-05 21:59 ---
I submitted a patch for this in:
http://gcc.gnu.org/ml/fortran/2007-04/msg00016.html
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31424
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-05 22:00 ---
I submitted a patch for this in:
http://gcc.gnu.org/ml/fortran/2007-04/msg00016.html
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31222
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-05 22:01 ---
I submitted a patch for this in:
http://gcc.gnu.org/ml/fortran/2007-04/msg00016.html
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30872
--- Comment #6 from steven at gcc dot gnu dot org 2007-04-05 22:01 ---
The tree dump for the original test case now looks like this for me:
;; Function foo (foo)
foo (p)
{
:
return (unsigned int) ((BIT_FIELD_REF <*p, 8, 0> & 1) != 0);
}
;; Function bar (bar)
bar (p)
{
:
return
--- Comment #12 from hjl at gcc dot gnu dot org 2007-04-05 22:16 ---
Subject: Bug 31478
Author: hjl
Date: Thu Apr 5 22:16:37 2007
New Revision: 123527
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123527
Log:
2007-04-05 Uros Bizjak <[EMAIL PROTECTED]>
H.J. Lu <[
--- Comment #13 from aoliva at gcc dot gnu dot org 2007-04-05 23:06 ---
Fixed in trunk for 4.3, not sure about backporting...
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from aoliva at gcc dot gnu dot org 2007-04-05 23:33 ---
FWIW, the patch for PR 22156 does not change the generated code on ppc,
although it appears to improve the x86 code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15596
--- Comment #4 from aoliva at gcc dot gnu dot org 2007-04-05 23:36 ---
No change with the patch for PR 22156.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20671
When a forward declared class is not found the error message describes it
incorrectly as a struct. See below for an example.
I'd like to submit a patch to correctly display class. Let me know if such a
patch would be considered.
$ g++ -Wall -ggdb -O0 -o t test6.cpp
test6.cpp: In function int mai
--- Comment #6 from echristo at apple dot com 2007-04-05 23:56 ---
Actually, I'll go ahead and take this, it was reported internally as well here
and I've got a patch in testing :)
--
echristo at apple dot com changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-06 00:09 ---
I don't think this matters anyways as class == struct and can be used
interchangably for tags.
if you summit a patch, see what this shows you:
struct foobar;
int main()
{
foobar * o = new foobar;
}
Or even
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-04-06 00:58
---
These testcases fail on spu-elf:
+FAIL: gcc.dg/float-range-1.c (test for warnings, line 11)
+FAIL: gcc.dg/float-range-1.c (test for excess errors)
+FAIL: gcc.dg/float-range-3.c (test for excess errors)
+FAIL: gcc.
The attached testcase does not compile for ppc64 using gcc confgured to
generate ppc/ppc64 code.
Attached is a reduced testcase from kernel. This error was not happening with
gcc 4.2 snapshot from January. I think it is related to static inline and
extern inline.
compile the attached testcase
g
--- Comment #1 from raj dot khem at gmail dot com 2007-04-06 01:28 ---
Created an attachment (id=1)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=1&action=view)
testcase
testcase to reproduce the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-06 01:57 ---
Reduced testcase:
int cpu_ (void *attr) {}
const unsigned long _1 __attribute__((section("__"))) = (unsigned long)&cpu_ ;
const unsigned long _group __attribute__((section("__"))) = 0;
--
http://gcc.gnu.org/bug
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-06 01:59 ---
> This error was not happening with gcc 4.2 snapshot from January.
My reduced testcase shows it happens even in 4.0.2. I don't have any thing
older than that right off hand.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-06 02:58 ---
Mine, I have a patch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Assig
In http://gcc.gnu.org/svn/gcc/trunk/libffi/README
/* Initialize the argument info vectors */
args[0] = &ffi_type_uint;
should be
/* Initialize the argument info vectors */
args[0] = &ffi_type_pointer;
The code happens to work stand-alone, but when included in a large
program
--- Comment #4 from dtemirbulatov at gmail dot com 2007-04-06 03:18 ---
looks like regression is caused by PR26090 fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-06 03:21 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from patchapp at dberlin dot org 2007-04-06 07:25 ---
Subject: Bug number PR31395
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-04/msg00229.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #21 from ubizjak at gmail dot com 2007-04-06 07:37 ---
Strange things happen.
I have fully removed gcc build directory and bootstrapped gcc from scratch. To
my suprise, the difference with -msse and without -msse is now gone and
optimized dumps are now the same. For referenc
90 matches
Mail list logo
