--- Comment #1 from fang at csl dot cornell dot edu 2008-07-31 07:00
---
See PR 25950 and all of its dupes.
The copy constructor needs to be publicly accessible where the temporary rvalue
is bound to a reference parameter.
--
fang at csl dot cornell dot edu changed:
--- Comment #30 from pinskia at gcc dot gnu dot org 2008-07-31 07:03
---
*** Bug 36490 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 2008-07-31 07:03 ---
*** This bug has been marked as a duplicate of 25950 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-31 07:08 ---
Yes this code is definitely wrong as on the PPC, we can load the stack pointer
from memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36980
Template nested inner classes are not resolved:
template
class A
{
public:
class AA { };
};
template
class B : public A
{
public:
class BB : public AA { };
//class BB : public A::AA { }; // Workaround.
};
int main(int argc, char* argv[])
{
B b;
return 0;
}
Brings the following error:
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-07-31 07:16
---
Just to confirm that reverting r138135-r138140 makes the bug vanish.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36980
--- Comment #1 from 4ekucT at tut dot by 2008-07-31 07:17 ---
Created an attachment (id=15981)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15981&action=view)
Template nested inner classes are not resolved.
Compile to reproduce the bug.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #1 from fang at csl dot cornell dot edu 2008-07-31 07:19
---
Dupe of PR 30734 (first reported as PR 2708).
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
--- Comment #21 from aldot at gcc dot gnu dot org 2008-07-31 07:56 ---
Lothar, see #10
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
--- Comment #4 from jakub at gcc dot gnu dot org 2008-07-31 08:00 ---
Subject: Bug 36649
Author: jakub
Date: Thu Jul 31 07:59:18 2008
New Revision: 138360
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138360
Log:
PR preprocessor/36649
* c-pch.c (c_common_read_pc
--- Comment #3 from jakub at gcc dot gnu dot org 2008-07-31 08:02 ---
Subject: Bug 36278
Author: jakub
Date: Thu Jul 31 08:01:25 2008
New Revision: 138361
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138361
Log:
PR debug/36278
* dwarf2out.c (get_context_die): N
--- Comment #1 from jakub at gcc dot gnu dot org 2008-07-31 08:04 ---
Subject: Bug 36970
Author: jakub
Date: Thu Jul 31 08:02:49 2008
New Revision: 138362
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138362
Log:
PR c/36970
* builtins.c (maybe_emit_free_warning)
// The following self-contained code (see below, I dont know how to
// attach files to this report) produces the bug (see embedded comments).
//
// The command compiler command line and output is as this:
//
// g++ -c -O2 -I . -DSTATIC_BUILD -Wall x.cpp
// x.cpp: In function bool ReadSpace::R
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-31 08:34
---
This is standard conforming behavior.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-31 08:39
---
*** This bug has been marked as a duplicate of 30734 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-31 08:39
---
*** Bug 36709 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2008-07-31 08:45 ---
Subject: Bug 36649
Author: jakub
Date: Thu Jul 31 08:44:24 2008
New Revision: 138368
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138368
Log:
PR preprocessor/36649
* c-pch.c (c_common_read_pc
--- Comment #4 from jakub at gcc dot gnu dot org 2008-07-31 08:49 ---
Subject: Bug 36278
Author: jakub
Date: Thu Jul 31 08:48:26 2008
New Revision: 138369
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138369
Log:
PR debug/36278
* dwarf2out.c (get_context_die): N
--- Comment #6 from jakub at gcc dot gnu dot org 2008-07-31 08:51 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2008-07-31 08:51 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jakub at gcc dot gnu dot org 2008-07-31 08:52 ---
Implemented on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #5 from paolo dot carlini at oracle dot com 2008-07-31 08:59
---
Hi again. I have essentially only one substantive comment: can you double check
the implementation is correct vs 20.7.12.2.1/37 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36962
$ cat mgrid.f
SUBROUTINE RESID(U,V,R,N,A)
INTEGER N
REAL*8 U(N,N,N),V(N,N,N),R(N,N,N),A(0:3)
INTEGER I3, I2, I1
DO 600 I3=2,N-1
DO 600 I2=2,N-1
DO 600 I1=2,N-1
600 R(I1,I2,I3)=V(I1,I2,I3)
> -A(0)*( U(I1, I2, I3 ) )
> -A(1)*( U(I1-1,
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-31 09:19 ---
Works for me. Very likely a dup of PR36967.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2008-07-31 09:25 ---
Downgrading to P2, as the required changes are probably too big and risky for
the branches.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
lapack-lite-3.1.1/TESTING/LIN/schkeq.f
gfortran -c schkeq.f -O3 -msse2 -mfpmath=sse -funroll-loops -fbounds-check
schkeq.f: In function 'schkeq':
schkeq.f:445: internal compiler error: in df_ref_chain_change_bb, at
df-scan.c:1828
Please submit a full bug report,
with preprocessed source if approp
--- Comment #1 from domob at gcc dot gnu dot org 2008-07-31 10:31 ---
So the following two lines should give this error, right:
subroutine test (a)
character(len(a)) :: a
end subroutine test
subroutine test2 (n, arr)
integer :: arr(n), n
end subroutine test2
where in test2, revers
GCC:
% /usr/local/gcc-4.3.1/bin/g++-4.3.1 -v
Using built-in specs.
Target: i386-apple-darwin9.3.0
Configured with: ../gcc-4.3.1/configure --disable-nls --enable-languages=c,c++
--program-suffix=-4.3.1 --prefix=/usr/local/gcc-4.3.1
Thread model: posix
gcc ve
--- Comment #1 from alexandre dot hamez at gmail dot com 2008-07-31 10:41
---
I don't how to attach the preprocessed source. The file weight more than 1000k
so it is refused by bugzilla. And I think that copy-paste 56000 lines of code
is not the right thing to do?
At least, it seams tha
--- Comment #2 from Joey dot ye at intel dot com 2008-07-31 10:50 ---
Yes. Just notice that latest trunk passes.
--
Joey dot ye at intel dot com changed:
What|Removed |Added
--
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-31 11:03
---
By the way, I'm under the impression that the differences between the TR1 and
the C++0x versions are by now too many, way too many macros. At some point we
should byte the bullet and separate completely for a g
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-31 11:14 ---
> subroutine test2 (n, arr)
> integer :: arr(n), n
> end subroutine test2
That example is valid as "n" is then implicitly typed as integer, which is
later confirmed. It only becomes invalid using:
implicit none
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-31 11:24 ---
1000k compressed? If not, compress it. Otherwise put it on the web somewhere
and post the link. We really need it to do anything about it...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36985
This bug is also caused by 138207, and latest trunk still fails (138353)
$ g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure --disable-bootstrap
--enable-languages=c,c++,fortran --enable-checking=assert
Thread model: posix
gcc version 4.4.0 20080731
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-31 11:33 ---
There is an easy workaround. Just do not fold the re-generated condition.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from Joey dot ye at intel dot com 2008-07-31 11:33 ---
Created an attachment (id=15982)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15982&action=view)
Preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36986
--- Comment #3 from alexandre dot hamez at gmail dot com 2008-07-31 11:33
---
Created an attachment (id=15983)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15983&action=view)
Preprocessed sources.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36985
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-31 11:35 ---
Note it is not "miscompiled", but instead the compiler crashes.
*** This bug has been marked as a duplicate of 36978 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-07-31 11:35 ---
*** Bug 36986 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from krebbel at gcc dot gnu dot org 2008-07-31 11:36 ---
Fixed.
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #24 from tkoenig at gcc dot gnu dot org 2008-07-31 11:38
---
Is this still an issue after the tuples merge?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
--- Comment #3 from domob at gcc dot gnu dot org 2008-07-31 11:54 ---
Thanks for the quick reply, Tobias. I'll try to get the "used but not yet
typed" part implemented to emit errors for -std != gnu.
To fix the problem in this PR, I see those possible solutions:
a) Disallow not-yet-ty
--- Comment #2 from dodji at gcc dot gnu dot org 2008-07-31 12:22 ---
Created an attachment (id=15984)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15984&action=view)
candidate partial fix
This patch fixes the problem patially.
if you have:
void
foo ()
{
#define W
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
An initializer for a C struct with a variable sized last component is accepted,
but the data generated excludes the variable sized component.
struct s {
int16_t a,b,c,d;
int16_t y[];
} data = {0,0,0,0, {2,3,4,5}};
results in only the leading four int16_t values in the data segment.
Either
--- Comment #59 from bonzini at gnu dot org 2008-07-31 12:44 ---
Should be fixed by the patch at
http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/8574
which is waiting to be applied upstream.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #1 from howard dot thomson at dial dot pipex dot com
2008-07-31 12:50 ---
Created an attachment (id=15985)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15985&action=view)
test for unexpected C struct field alteration
Due to the variable sized component of the struct
--- Comment #9 from bonzini at gnu dot org 2008-07-31 12:58 ---
Michael, any news?
--
bonzini at gnu dot org changed:
What|Removed |Added
CC|
src/gcc-work/gcc/configure --enable-languages=c
--disable-bootstrap --enable-checking=all --prefix=/usr/gcc-4.4-work
--with-local-prefix=/usr/local
Thread model: posix
gcc version 4.4.0 20080731 (experimental) [trunk revision 138402] (GCC)
COLLECT_GCC_OPTIONS='-B../' '-m32'
--- Comment #1 from jason at gcc dot gnu dot org 2008-07-31 13:16 ---
*** This bug has been marked as a duplicate of 11309 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from jason at gcc dot gnu dot org 2008-07-31 13:16 ---
*** Bug 36394 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from jakub at gcc dot gnu dot org 2008-07-31 13:49 ---
This got actually fixed by Alan's PR target/36634 fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from hjl dot tools at gmail dot com 2008-07-31 13:50 ---
The analysis and a patch are posted at
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02441.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-07-31 14:12 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-07-31 14:13 ---
Subject: Bug 36978
Author: rguenth
Date: Thu Jul 31 14:12:24 2008
New Revision: 138415
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138415
Log:
2008-07-31 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #1 from hjl at gcc dot gnu dot org 2008-07-31 14:35 ---
Subject: Bug 36976
Author: hjl
Date: Thu Jul 31 14:33:43 2008
New Revision: 138416
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138416
Log:
2008-07-31 H.J. Lu <[EMAIL PROTECTED]>
PR debug/36976
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-07-31 14:44 ---
Richard, there is one problem that is "yours". We conclude that call is
uninlinable due to type missmatch. This should not happen on C++.
This gets misdiagnozed as originally recursive inlning was only reason why
i
typedef unsigned short __u16;
typedef unsigned int __u32;
typedef __u8 uint8_t;
typedef __u16 uint16_t;
typedef __u32 uint32_t;
typedef struct {
uint8_t mbxCommand;
} MAILBOX_t;
typedef struct lpfcMboxq {
};
int lpfc_sli_brdrestart(struct lpfc_hba * phba)
{
MAILBOX_t *mb;
uint16_t skip_post
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-31 14:51 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
With the code below, gcc complains over line 8, but not lines 14 and 17
because it deduces the wrong type for the ?: operator. The type of that
operator's result is dependent on whether something is a null pointer
constant and not. gcc fails to track that properly: it knows that
(const void *)0 i
--- Comment #6 from hjl at gcc dot gnu dot org 2008-07-31 15:34 ---
Subject: Bug 36980
Author: hjl
Date: Thu Jul 31 15:32:51 2008
New Revision: 138424
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138424
Log:
2008-07-31 H.J. Lu <[EMAIL PROTECTED]>
PR debug/36980
--- Comment #7 from hjl dot tools at gmail dot com 2008-07-31 15:35 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from hjl dot tools at gmail dot com 2008-07-31 15:35 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from hjl dot tools at gmail dot com 2008-07-31 15:38 ---
Jason, can you comment on it? Thanks.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #3 from hjl dot tools at gmail dot com 2008-07-31 15:39 ---
Patch with updated ChangeLog is at
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02391.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-07-31 15:44 ---
Bug 456 covers c9[09]-const-expr-[12].c, bug 5675 covers
c9[0-9]-const-expr-3.c.
*** This bug has been marked as a duplicate of 456 ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from jsm28 at gcc dot gnu dot org 2008-07-31 15:44 ---
*** Bug 36989 has been marked as a duplicate of this bug. ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from matz at gcc dot gnu dot org 2008-07-31 16:13 ---
I submitted a patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00722.html
but got no feedback or review.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
ase submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE when gcc (4.4.0-20080731) uses -fipa-cp with -O
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
--- Comment #16 from jason at gcc dot gnu dot org 2008-07-31 17:39 ---
Subject: Bug 36633
Author: jason
Date: Thu Jul 31 17:38:08 2008
New Revision: 138425
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138425
Log:
PR c++/36633
* init.c (build_new_1): Don't conve
--- Comment #17 from jason at gcc dot gnu dot org 2008-07-31 17:41 ---
The offending optimization in forwprop2 seems to have been disabled on the
trunk. I also just checked in a patch to simplify the code generated for new,
though it doesn't seem to have been the problem in this PR.
-
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-07-31 17:47
---
Confirmed, thanks for the quick turnaround!
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2008-07-31 18:08 ---
Subject: Bug 36405
Author: jakub
Date: Thu Jul 31 18:07:20 2008
New Revision: 138426
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138426
Log:
PR c++/36405
* rtti.c (get_tinfo_decl_dynamic, ge
--- Comment #19 from jakub at gcc dot gnu dot org 2008-07-31 18:09 ---
Subject: Bug 36419
Author: jakub
Date: Thu Jul 31 18:08:36 2008
New Revision: 138427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138427
Log:
PR rtl-optimization/36419
* dwarf2out.c (barrier
Output of gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.1-8ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --li
--- Comment #1 from eagle at cs dot ucla dot edu 2008-07-31 18:38 ---
Created an attachment (id=15986)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15986&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36991
--- Comment #2 from eagle at cs dot ucla dot edu 2008-07-31 18:38 ---
command line:
gcc -std=gnu99 temp.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36991
--- Comment #7 from jakub at gcc dot gnu dot org 2008-07-31 19:04 ---
Subject: Bug 36405
Author: jakub
Date: Thu Jul 31 19:02:33 2008
New Revision: 138430
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138430
Log:
PR c++/36405
* rtti.c (get_tinfo_decl_dynamic, ge
--- Comment #20 from jakub at gcc dot gnu dot org 2008-07-31 19:09 ---
Subject: Bug 36419
Author: jakub
Date: Thu Jul 31 19:07:51 2008
New Revision: 138431
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138431
Log:
PR rtl-optimization/36419
* dwarf2out.c (barrier
--- Comment #7 from jakub at gcc dot gnu dot org 2008-07-31 19:13 ---
Subject: Bug 36649
Author: jakub
Date: Thu Jul 31 19:12:14 2008
New Revision: 138432
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138432
Log:
PR preprocessor/36649
* files.c (struct report_mi
--- Comment #8 from jakub at gcc dot gnu dot org 2008-07-31 19:16 ---
Subject: Bug 36649
Author: jakub
Date: Thu Jul 31 19:15:08 2008
New Revision: 138433
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138433
Log:
PR preprocessor/36649
* files.c (struct report_mi
--- Comment #11 from uweigand at gcc dot gnu dot org 2008-07-31 19:31
---
I'll have a look tomorrow ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-31 19:41 ---
This works correctly on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-31 19:45 ---
This was fixed in 4.1.0 and above already.
*** This bug has been marked as a duplicate of 25805 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-07-31 19:45 ---
*** Bug 36987 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from howard dot thomson at dial dot pipex dot com
2008-07-31 19:53 ---
OK Thanks to all.
I did look for previous reports, honest!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36987
--- Comment #21 from jakub at gcc dot gnu dot org 2008-07-31 20:19 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from jakub at gcc dot gnu dot org 2008-07-31 20:20 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #11 from jakub at gcc dot gnu dot org 2008-07-31 20:38 ---
Subject: Bug 35100
Author: jakub
Date: Thu Jul 31 20:37:21 2008
New Revision: 138435
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138435
Log:
PR target/35100
* gcc.target/powerpc/longcall-1.
--- Comment #4 from hjl at gcc dot gnu dot org 2008-07-31 21:30 ---
Subject: Bug 36977
Author: hjl
Date: Thu Jul 31 21:28:54 2008
New Revision: 138438
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138438
Log:
2008-07-31 H.J. Lu <[EMAIL PROTECTED]>
PR debug/36977
--- Comment #5 from hjl dot tools at gmail dot com 2008-07-31 21:32 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #1 from aaronavay62 at aaronwl dot com 2008-07-31 22:59 ---
Created an attachment (id=15987)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15987&action=view)
Allocate argv array first
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36968
--- Comment #5 from andry at inbox dot ru 2008-08-01 02:14 ---
I check it without these flags and crash happend again, here:
"xgcc.exe -v"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
We should generate "movq" for _mm_move_epi64. But instead, we
generate very strange code and never movq:
[EMAIL PROTECTED] gcc]$ cat /tmp/m.c
#include
__m128i
test (__m128i b)
{
return _mm_move_epi64 (b);
}
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -S /tmp/m.c
[EMAIL PROTECTED] gcc]$ cat m.s
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-08-01
04:34 ---
This kind of path
'--prefix=/c/_GccBuilds/gcc-4.3.1-install/mingw-32-i686' may be understood by
your shell, but won't be found by the xgcc driver or cc1.exe which are native
windows apps. Search the
95 matches
Mail list logo
