--- Comment #37 from developer at sandoe-acoustics dot co dot uk
2010-02-19 08:43 ---
(In reply to comment #36)
> I've checked in a slightly updated fix in r156877. Let us know if all the
> regressions are fixed now.
i686/powerpc-darwin9 - YES, thanks.
--
http://gcc.gnu.org/bugzil
--- Comment #11 from paolo dot carlini at oracle dot com 2010-02-19 09:16
---
Maybe it was a mistake on my part closing PR43113 as duplicate of this one.
Unless you can soon manage to fix both at once with a single patch, maybe
better separating the PRs again. Anyway, with your draft, P
--- Comment #7 from jakub at gcc dot gnu dot org 2010-02-19 09:49 ---
Created an attachment (id=19919)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19919&action=view)
gcc45-pr43077-test.patch
Updated test, let's move the initialization before call scheduling issue into a
separate
--- Comment #11 from jakub at gcc dot gnu dot org 2010-02-19 09:50 ---
Subject: Bug 42233
Author: jakub
Date: Fri Feb 19 09:50:30 2010
New Revision: 156888
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156888
Log:
PR middle-end/42233
* gimplify.c (gimple_boolify
--- Comment #7 from cgerdy at wanadoo dot fr 2010-02-19 09:53 ---
Subject: Re: bug with gfortran on Windows vista, correct on Linux
Excuse me but I do not understand how correctly use "gfortran -v"
I download gfortran on :
http://gcc.gnu.org/wiki/GFortranBinaries
and on that page : in
--- Comment #12 from jakub at gcc dot gnu dot org 2010-02-19 09:54 ---
Subject: Bug 42233
Author: jakub
Date: Fri Feb 19 09:53:51 2010
New Revision: 156889
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156889
Log:
PR middle-end/42233
* expr.h (jumpifnot, jumpifn
--- Comment #13 from jakub at gcc dot gnu dot org 2010-02-19 10:03 ---
Fixed on the trunk so far. I might try to do a backport in a few days to 4.4
branch, though the second patch won't be trivial, as dojump.c changed massively
with SSA expansion changes.
--
jakub at gcc dot gnu dot
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-19 10:09 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-02-19 10:09
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #25 from rguenth at gcc dot gnu dot org 2010-02-19 10:22
---
(In reply to comment #24)
> Richard, can you comment on this issue? Do you think it's currently correct to
> have numeric_limits<>:is_modulo == true for all our signed integral types? We
> are not making any progre
--- Comment #26 from paolo dot carlini at oracle dot com 2010-02-19 10:30
---
Ah, thanks, that pre-processor macro idea looks very nice to me. Let's see what
people think, and in case, I'll take care of that as soon as 4.5 branches.
--
paolo dot carlini at oracle dot com changed:
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-19 10:40 ---
Subject: Bug 42944
Author: rguenth
Date: Fri Feb 19 10:40:17 2010
New Revision: 156890
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156890
Log:
2010-02-19 Richard Guenther
PR tree-optimization/
--- Comment #22 from paolo dot carlini at oracle dot com 2010-02-19 10:49
---
Update: per LWG 1170, for basic_string we are back to POD types only, not the
much larger class of literal types,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
The vldX and vstX variation of NEON intrinsics, where X > 1, seem to cause the
compiler to generate an obscene amount of code.
Example:
void blend1(uint8_t *src, uint8_t *dst)
{
uint8x8_t temp = vld1_u8(src);
vst1_u8(dst, temp);
}
generates the sensible
vld1.8 {d16}, [r
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-19 11:08 ---
Likely because of the union in
__extension__ static __inline void __attribute__ ((__always_inline__))
vst4_u8 (uint8_t * __a, uint8x8x4_t __b)
{
union { uint8x8x4_t __i; __builtin_neon_oi __o; } __bu = { __b };
--- Comment #27 from joseph at codesourcery dot com 2010-02-19 11:13
---
Subject: Re: numeric_limits::is_modulo is
inconsistent with gcc
The issue with -fwrapv not making INT_MIN / -1 and INT_MIN % -1 have
modulo semantics is discussed in bug 30484.
--
http://gcc.gnu.org/bugzil
--- Comment #28 from paolo dot carlini at oracle dot com 2010-02-19 11:18
---
Thanks Joseph. Indeed, I remember well when my friend Roberto opened that
issue, but didn't expect it was still open ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
--- Comment #8 from jakub at gcc dot gnu dot org 2010-02-19 11:23 ---
Details for Alex:
/* { dg-options "-m32 -O2 -g -march=i386 -mtune=generic -dA" } */
int foo (unsigned long *);
int
fn3 (void)
{
unsigned long a = 0, b = 0;
a = foo (&b);
unsigned long varb = b;
asm volatile (""
--- Comment #29 from paolo dot carlini at oracle dot com 2010-02-19 11:26
---
So, if I understand correctly the dependencies, I think we should mark this as
blocked by 30484: when -fwrapv makes INT_MIN / -1 and INT_MIN % -1 have modulo
semantics we can conditionalize numeric_limits::is_
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-19 11:55 ---
The recent patch to add PARAM_MAX_VARTRACK_SIZE didn't fix this. We still
top out beyond what my machine with 3GB ram and 1GB swap can handle.
GCC 4.4.3 tops at 620MB
GCC 4.5 with -fno-var-tracking-assignments tops
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-19 11:55 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-02-19 12:05
---
And nobody cares?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-02-19 12:17
---
The patch would need updating now. Micha, does your tracer handle this case?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from laurent at guerby dot net 2010-02-19 12:17 ---
Note: c87b39a also fails on sparc-linux 32 bits but not 64 bits
sparc http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg01785.html
sparc64 http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg01689.html
--
http://gcc.gnu
On the following testcase I wonder if VTA couldn't help a little bit with
debugging experience.
(insn 6 5 7 2 prN.c:17 (set (mem/c/i:DI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [2 b+0 S8 A64])
(const_int 0 [0x0])) 89 {*movdi_1_rex64} (nil))
(insn 7 6 8 2 prN.c
--- Comment #22 from amylaar at gcc dot gnu dot org 2010-02-19 12:29
---
(In reply to comment #21)
> The patch would need updating now. Micha, does your tracer handle this case?
See comment #20 for an updated patch. However, I don't have EEMBC available
at the moment to make absolute
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-19 12:31 ---
Created an attachment (id=19920)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19920&action=view)
pr43119.c
Testcase for gcc/testsuite/gcc.dg/guality/ framework.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #9 from jakub at gcc dot gnu dot org 2010-02-19 12:32 ---
Initialization before call issue moved to PR43119.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
--- Comment #10 from matz at gcc dot gnu dot org 2010-02-19 12:33 ---
Okay. You were right, my tree was a outdated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-19 12:35 ---
I've tried
--- gcc/lambda-code.c.jj 2009-11-25 16:47:37.0 +0100
+++ gcc/lambda-code.c 2010-02-17 15:00:40.0 +0100
@@ -1885,7 +1885,8 @@ not_interesting_stmt (gimple stmt)
loop, we would have alrea
--- Comment #14 from jakub at gcc dot gnu dot org 2010-02-19 12:47 ---
Subject: Bug 42233
Author: jakub
Date: Fri Feb 19 12:47:18 2010
New Revision: 156893
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156893
Log:
PR middle-end/42233
* loop-doloop.c (add_test):
--- Comment #12 from burnus at gcc dot gnu dot org 2010-02-19 12:48 ---
First patches for (single-image) Coarray support, see
http://gcc.gnu.org/wiki/GFortranPatchTracker
about half of the work is already done & approved for committal when the 4.6
development starts.
--
http://gcc
--- Comment #11 from vincent at vinc17 dot org 2010-02-19 13:08 ---
(In reply to comment #10)
> This issue was discussed on the WG14 reflector in October 2008, and the
> general
> view was that the standard should not make INT_MIN % -1 well defined (as this
> would impose a significant
--- Comment #23 from matz at gcc dot gnu dot org 2010-02-19 13:19 ---
Richi: not really. It tries to separate paths where at least one has mostly
constants in their PHI args. This applies to this testcase for the first
chain of PHI nodes, which are separated as intended. But this simp
--- Comment #6 from jakub at gcc dot gnu dot org 2010-02-19 13:23 ---
Assuming this is fixed. Please reopen if it is not.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-19 13:40 ---
The difference is in alignment and some part of a patch of mine seems to
fix it ...
-(insn 230 229 231 3 t.i:5 (set (reg/v:SI 383 [ h ])
-(mem/c/i:SI (symbol_ref:DI ("seed") )
[0
seed+0 S4 A128])) -1 (nil)
--- Comment #5 from jakub at gcc dot gnu dot org 2010-02-19 13:45 ---
Heh, have just been looking into this too and figured out it is the alignment,
already in *.expand dump. With -O2 as opposed to -O1 the testcase now succeeds
for both -m32 and -m64 though (but I have in my tree PR4289
--- Comment #2 from ramana at gcc dot gnu dot org 2010-02-19 13:45 ---
Trunk behaves similarly - I wonder if this is similar to 41021.
Here's what trunk generates.
push{r4, r5, r6, r7}
vld4.8 {d16-d19}, [r0]
sub sp, sp, #96
mov r7, r1
--- Comment #6 from rguenther at suse dot de 2010-02-19 13:47 ---
Subject: Re: [4.5 Regression] "-fcompare-debug
failure" with "-O1 -funroll-loops -ftree-vectorize"
On Fri, 19 Feb 2010, jakub at gcc dot gnu dot org wrote:
> --- Comment #5 from jakub at gcc dot gnu dot org 2010-0
--- Comment #24 from drow at gcc dot gnu dot org 2010-02-19 14:08 ---
If no one else has EEMBC available, ask me and we can verify any fix. We've
been using Steven's and Joern's patches; we tried other approaches, but in the
end we weren't able to come up with any other approach that wo
--- Comment #5 from jakub at gcc dot gnu dot org 2010-02-19 14:17 ---
Assigning to myself to fix the VTA issues in this pass (and perhaps switch it
to use XNEW*/XCNEW*), but not to give it the rest of TLC the pass needs...
--
jakub at gcc dot gnu dot org changed:
What
Diamond shaped class structure with a covariant return method causes GCC to
fail to adjust base pointers. In the attached program, the output is a huge
number instead of the expected 123.
Looking at what happens in GDB, it appears that the this pointer in the call of
A(const A &other) gets a B re
--- Comment #1 from goeran at uddeborg dot se 2010-02-19 14:24 ---
Created an attachment (id=19921)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19921&action=view)
Test case
No special flags, just compile with "c++ thunk.cc -o thunk".
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-19 14:33 ---
Ping?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42427
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-19 14:39 ---
Confirmed. Broken since it is supported.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from jakub at gcc dot gnu dot org 2010-02-19 14:56 ---
Created an attachment (id=19922)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19922&action=view)
gcc45-pr43084.patch
So far untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43084
On Linux/ia64, I got
/libdecnumber/libdecnumber.a-lmpc -lmpfr -lgmp -rdynamic -ldl -lz -lelf
libbackend.a(except.o): In function `sjlj_emit_function_enter':
/export/gnu/import/svn/gcc-test/bld/gcc/../../src-trunk/gcc/except.c:1165:
undefined reference to `add_reg_br_prob_note'
collect2: ld re
--- Comment #1 from hjl dot tools at gmail dot com 2010-02-19 15:14 ---
It is caused by revision 156889:
http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00472.html
Jakub, you missed:
[...@gnu-12 gcc]$ grep add_reg_br_prob_note *.[ch]
except.c:add_reg_br_prob_note (get_insns (), REG_BR_PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-19 15:42 ---
Subject: Bug 42916
Author: rguenth
Date: Fri Feb 19 15:42:31 2010
New Revision: 156898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156898
Log:
2010-02-19 Richard Guenther
PR tree-optimization/
When trying to overload operators for __m128 and __m128d types. For example,
the following code:
#include
#include
inline __m128 operator + (const __m128 A, const __m128 B)
{
return _mm_add_ps(A, B);
}
int main()
{
float a[4];
float b[4];
for(size_t i = 0; i <
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43121
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43122
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #8 from jakub at gcc dot gnu dot org 2010-02-19 15:59 ---
Fixed, thanks.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
Well there is already a builtin operator+ for vector types with the
generic vector support.
Sent from my iPhone
On Feb 19, 2010, at 7:50 AM, "mr dot nuke dot me at gmail dot com" > wrote:
When trying to overload operators for __m128 and __m128d types. For
example,
the following code:
#i
--- Comment #1 from pinskia at gmail dot com 2010-02-19 16:05 ---
Subject: Re: New: g++ does not allow overloading operators for sse types
(__m128, __m128d)
Well there is already a builtin operator+ for vector types with the
generic vector support.
Sent from my iPhone
On Feb 19, 2
--- Comment #7 from bergner at gcc dot gnu dot org 2010-02-19 16:28 ---
Sorry, David and I talked offline about the last patch and he still has some
reservations about the code (even the pre-patched code). After discussing
this, I'm going to try adding a splitter which should hopefully
--- Comment #14 from jason at gcc dot gnu dot org 2010-02-19 18:00 ---
Created an attachment (id=19923)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19923&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #15 from jakub at gcc dot gnu dot org 2010-02-19 18:19 ---
Subject: Bug 42233
Author: jakub
Date: Fri Feb 19 18:19:06 2010
New Revision: 156903
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156903
Log:
PR middle-end/42233
* dojump.c (do_jump) : Inver
--- Comment #16 from jakub at gcc dot gnu dot org 2010-02-19 18:28 ---
Created an attachment (id=19924)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19924&action=view)
gcc44-pr42233.patch
Backported patch for 4.4 branch, so far only compile tested.
--
http://gcc.gnu.org/bugz
--- Comment #7 from jakub at gcc dot gnu dot org 2010-02-19 18:30 ---
Subject: Bug 43084
Author: jakub
Date: Fri Feb 19 18:30:22 2010
New Revision: 156904
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156904
Log:
PR debug/43084
* ipa-struct-reorg.c (add_access_t
--- Comment #8 from jakub at gcc dot gnu dot org 2010-02-19 18:31 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from mr dot nuke dot me at gmail dot com 2010-02-19 18:34
---
I'm assuming you are referring to and F32vec4. While I will apply this
workaround (one of many many workarounds to get fancy C++ code to work with
g++) it still doesn't solve the underlying problem, and affect
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-19 18:39 ---
(In reply to comment #2)
> I'm assuming you are referring to and F32vec4. While I will apply
> this
> workaround (one of many many workarounds to get fancy C++ code to work with
> g++) it still doesn't solve the un
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-19 18:51 ---
FYI, this is 15.3/6. __m128 isn't a class nor an enumeration. Maybe it is
for the other compilers as implementation detail.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-02-19 18:56
---
If the date is correct, it is an older version.
At the command line just type: gfortran -v
gfortran will then display the version information for you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43115
--- Comment #38 from mrs at gcc dot gnu dot org 2010-02-19 19:06 ---
Subject: Bug 43061
Author: mrs
Date: Fri Feb 19 19:06:38 2010
New Revision: 156907
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156907
Log:
PR objc/43061
* cgraphunit.c (process_function_and_v
--- Comment #5 from mr dot nuke dot me at gmail dot com 2010-02-19 19:15
---
> Which means there is already an operator+ defined which is done using the
> generic GNU vector support. If you remove your definition of operator+, it
> works without it.
>
I could have sworn I saw
error
--- Comment #39 from mikestump at comcast dot net 2010-02-19 19:15 ---
I checked in the real back end change in r156907.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
--- Comment #5 from jason at gcc dot gnu dot org 2010-02-19 20:13 ---
The problem is that instantiate_decl_rtl isn't being run on the rtl for the
upper bound temporary, because it isn't visible to instantiate_decls. This
happens because even though the temp got added to cfun->local_decl
--- Comment #6 from jason at gcc dot gnu dot org 2010-02-19 20:59 ---
Yeah, the Expand from SSA patch broke Jakub's fix for PR 34037. I'm testing a
patch that just tweaks the logic a bit to make it work again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-19 21:12 ---
Subject: Bug 41779
Author: manu
Date: Fri Feb 19 21:12:09 2010
New Revision: 156911
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156911
Log:
2010-02-19 Manuel López-Ibáñez
PR 41779
* c-
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-19 21:14 ---
FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from burnus at gcc dot gnu dot org 2010-02-19 21:20 ---
(In reply to comment #3)
> This could be somewhat similar, I really wonder if this needs a temp:
>
> TYPE T1
> INTEGER :: a(3)
> END TYPE T1
> TYPE(T1), POINTER :: x,y
> ALLOCATE(x,y)
> x%a=y%a
> END
I think one ne
--- Comment #11 from manu at gcc dot gnu dot org 2010-02-19 21:21 ---
Subject: Bug 36513
Author: manu
Date: Fri Feb 19 21:21:34 2010
New Revision: 156912
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156912
Log:
2010-02-19 Manuel López-Ibáñez
PR 36513
testsuite/
--- Comment #9 from jason at gcc dot gnu dot org 2010-02-19 21:21 ---
Suspending until the committee can rule on this, but I expect the result to be
that the testcase is ill-formed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from jason at gcc dot gnu dot org 2010-02-19 21:23 ---
Not working on this now.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #12 from manu at gcc dot gnu dot org 2010-02-19 21:25 ---
FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-19 21:29 ---
EDG 4.1 gives the same mangled name, so if anything needs to be fixed, it's the
ABI document.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #19 from jason at gcc dot gnu dot org 2010-02-19 21:39 ---
Created an attachment (id=19925)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19925&action=view)
patch for 4.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41970
--- Comment #11 from jason at gcc dot gnu dot org 2010-02-19 21:41 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|NEW
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
AssignedTo|jason at gcc dot gnu do
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40315
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-19 22:12 ---
Subject: Bug 43121
Author: jakub
Date: Fri Feb 19 22:12:25 2010
New Revision: 156913
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156913
Log:
PR bootstrap/43121
* except.c (sjlj_emit_function
--- Comment #9 from cgerdy at wanadoo dot fr 2010-02-19 22:17 ---
Subject: Re: bug with gfortran on Windows vista, correct on Linux
thank you
That is the answer to your question :
C:\Users\gerdy>gfortran -v
Using built-in specs.
Target: i586-pc-mingw32
Configured with:
../gcc-trunk/c
./xgcc -B . -march=generic ~/test.c
/home/manuel/test.c:1:0: error: generic CPU can be used only for -mtune= switch
/home/manuel/test.c:1:0: error: bad value (generic) for -march= switch
/home/manuel/test.c:1:0: error: bad value (generic) for -march= switch
Tested on x86_64-unknown-linux-gnu
--
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org
Severity|normal
--- Comment #40 from developer at sandoe-acoustics dot co dot uk
2010-02-19 23:28 ---
(In reply to comment #39)
> I checked in the real back end change in r156907.
OK on i686/powerpc d9
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
--- Comment #10 from mikpe at it dot uu dot se 2010-02-19 23:32 ---
The binutils patch that broke libjava came from CodeSourcery, so I decided to
test their latest G++ lite for arm-linux-gnueabi (2009q3-67). That compiler is
based on gcc-4.4.1, and it does not have the libjava regression
--- Comment #25 from stevenb dot gcc at gmail dot com 2010-02-19 23:32
---
Subject: Re: [4.3/4.4/4.5 Regression] huge
performance regression on EEMBC bitmnp01
On 2/19/10, drow at gcc dot gnu dot org wrote:
>
>
> --- Comment #24 from drow at gcc dot gnu dot org 2010-02-1
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2010-02-19
23:32 ---
Created an attachment (id=19926)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19926&action=view)
updated patch against 156812
gcc/testsuite/Changelog:
2009-10-06 Iain Sandoe
PR teststuite/41
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2010-02-19
23:36 ---
Created an attachment (id=19927)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19927&action=view)
updated patch against 156812
gcc/testsuite/Changelog:
2009-12-17 Iain Sandoe
PR testsuite/4234
--- Comment #10 from amodra at gcc dot gnu dot org 2010-02-19 23:38 ---
Subject: Bug 42344
Author: amodra
Date: Fri Feb 19 23:38:20 2010
New Revision: 156914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156914
Log:
PR middle-end/42344
* cgraph.h (cgraph_make_de
--- Comment #11 from amodra at gmail dot com 2010-02-19 23:39 ---
Fixed
--
amodra at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2010-02-19
23:42 ---
updated patches & test results:
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00742.html
explanation of the intention of those patches:
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00712.html
--
ht
I'm using the stock Fedora 12 gcc, RPM gcc-4.4.3-4.fc12.x86_64.
Whereas it appears to align __m128 variables correctly (16-bytes), it accesses
them as if they were only 8 byte aligned.
I read various threads etc about aligning variables on the stack, but my belief
is that this never was a problem
--- Comment #9 from manu at gcc dot gnu dot org 2010-02-19 23:56 ---
This is not an uninitialized issue.
The reason this requires -O2 is that -Warray-bounds requires VRP to warn. The
gimple output already looks quite different.
-funsigned-char:
:
[pr35903.i : 309:15] D
1 - 100 of 127 matches
Mail list logo
