double _Complex
test (int d, int t, double *x, double *y, double *z, int n,
double _Complex (*fnp) (double))
{
int m = n / 2;
double min = y[t], max = z[t], med = x[m * d + t];
double _Complex result = 0.0;
if (n == 0)
return 0.0;
if (min > med)
result += test (d, (t + 1)
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40669
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-07 09:07 ---
Why do you limit your stack boundary artificially?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667
--- Comment #2 from debian-gcc at lists dot debian dot org 2009-07-07
09:08 ---
proposed patch at http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00322.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-07 09:15 ---
With my local 4.3 copy it prints
t.i: In function test:
t.i:22: error: PHI def is not a GIMPLE value
add_acc.0_64 = PHI (0), add_acc.0_60(7),
add_acc.0_64(6), add_acc.0_64(4)>
COMPLEX_EXPR <0.0, 0.0>;
t.i:22: er
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-07 09:23 ---
Yeah, PR40328. Then we are left with
t.i: In function test:
t.i:22: error: invalid operand to binary operator
add_acc.0_64
t.i:22: error: invalid operand to binary operator
add_acc.0_64
t.i:22: internal compile
Compile following function with options -Os -mthumb -march=armv5te
float return_zero()
{
return 0;
}
Gcc generates:
ldr r0, .L2
bx lr
.L3:
.align 2
.L2:
.word 0
Floating point 0 is also integer 0. So the function body can be simplified as
mo
--- Comment #1 from carrot at google dot com 2009-07-07 09:38 ---
Created an attachment (id=18149)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18149&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40670
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-07 09:46 ---
Created an attachment (id=18150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18150&action=view)
gcc45-pr40669.patch
Patch I'm going to bootstrap/regtest.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=406
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-07 10:01 ---
4.4 will need a backport of PR40328 as well. Your attached patch is ok.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mikpe at it dot uu dot se 2009-07-07 10:18 ---
(In reply to comment #1)
> Now I'm trying to compile gcc-4.4.0 configured as follows:
>
> ../gcc-4.4.0/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
> --target=x86_64-pc-linux-gnu --enable-languages=c
--- Comment #6 from manu at gcc dot gnu dot org 2009-07-07 10:25 ---
(In reply to comment #5)
>
> Thus code is undefined you have an acess of a char array as a struct.
> Yes you are only taking the address of an element but it is still
> considered an acess by the standards.
I see
--- Comment #3 from pluto at agmk dot net 2009-07-07 10:33 ---
sounds like PR36485.
--
pluto at agmk dot net changed:
What|Removed |Added
CC|
--- Comment #4 from booleandomain at gmail dot com 2009-07-07 10:39 ---
I created a symlink from /usr/lib to /usr/lib64 and now gcc is built fine!
Thanks a lot!
(Probably this bug is going to be marked as invalid...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40602
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-07-07 10:45
---
Did this work with 4.4.0?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-07-07 10:45
---
Fixing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.4.1 Regression] Ada rts |[4.4.1 regression] Ada tools
|build failure
--- Comment #3 from mikpe at it dot uu dot se 2009-07-07 11:35 ---
Confirmed, with gcc-4.3-20090705 it works, with gcc-4.4-20090630 it fails.
Compiling with -S and comparing the .s files it looks like 4.4 completely
mis-schedules the code for put_uint32:
put_uint32:
.register
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-07 12:18 ---
Subject: Bug 40669
Author: jakub
Date: Tue Jul 7 12:18:38 2009
New Revision: 149319
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149319
Log:
PR middle-end/40669
* tree-tailcall.c (adjust_ret
Probably due to revision 148869 the following tests fail on
powerpc-apple-darwin9 with -m32
FAIL: gcc.dg/vect/vect-82_64.c (internal compiler error)
FAIL: gcc.dg/vect/vect-83_64.c (internal compiler error)
FAIL: gcc.target/powerpc/darwin-misaligned.c (internal compiler error)
FAIL: gcc.target/powe
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-07 12:44 ---
Subject: Bug 40328
Author: rguenth
Date: Tue Jul 7 12:44:32 2009
New Revision: 149321
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149321
Log:
2009-07-07 Richard Guenther
PR middle-end/40328
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-07 12:44 ---
Subject: Bug 40669
Author: rguenth
Date: Tue Jul 7 12:44:32 2009
New Revision: 149321
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149321
Log:
2009-07-07 Richard Guenther
PR middle-end/40328
--- Comment #12 from burnus at gcc dot gnu dot org 2009-07-07 12:47 ---
> You were right - contiguous does need initializing. Not for this case but
> some of the other uses that I referred to.
Paul, what is the plan? You had a 4.4 and 4.5 check in, contiguous is not
initialized in 4.5.
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-07
13:35 ---
Subject: Re: [4.4.1 Regression] Ada rts build failure
> Did this work with 4.4.0?
Yes.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40666
--- Comment #10 from jakub at gcc dot gnu dot org 2009-07-07 14:07 ---
Subject: Bug 40328
Author: jakub
Date: Tue Jul 7 14:07:19 2009
New Revision: 149329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149329
Log:
PR middle-end/40669
* tree-tailcall.c (adjust_re
--- Comment #7 from jakub at gcc dot gnu dot org 2009-07-07 14:07 ---
Subject: Bug 40669
Author: jakub
Date: Tue Jul 7 14:07:19 2009
New Revision: 149329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149329
Log:
PR middle-end/40669
* tree-tailcall.c (adjust_ret
--- Comment #8 from jakub at gcc dot gnu dot org 2009-07-07 14:09 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.3 4.4.0
Known to work||4.3.4 4.5
--- Comment #2 from hjl dot tools at gmail dot com 2009-07-07 14:41 ---
I think it is related to PR 39137.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667
The testcase below:
typedef unsigned char uint8_t;
#define UART3_LSR (*(volatile uint8_t *)(0x4902+20))
#define UART3_RBR (*(volatile uint8_t *)(0x4902+0))
int IsSerialBufferFull(void)
{
return (UART3_LSR & 0x20) == 0;
}
void SendSerialByte(uint8_t byte)
{
while (IsSerialBufferFull(
--- Comment #1 from drow at gcc dot gnu dot org 2009-07-07 15:03 ---
It looks, roughly speaking, like the two nearby addresses are initially
commonized. In the process, the use after the loop ends up sharing a REG with
the use in the loop. Then the use in the loop is changed to use a n
--- Comment #13 from burnus at gcc dot gnu dot org 2009-07-07 15:27 ---
(In reply to comment #12)
> > You were right - contiguous does need initializing. Not for this case but
> > some of the other uses that I referred to.
> Paul, what is the plan? You had a 4.4 and 4.5 check in, contig
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-07 15:47 ---
The issue is likely the sequence
load upper half of cache line 1
load lower half of cache line 2
store upper half of cache line 1
store lower half of cache line 2 <---
load upper half of cache line 2
Building lapack-3.2.1 results in a testsuite routine that fails with:
Testing DOUBLE PRECISION LAPACK linear equation routines
./xlintstd < dtest.in > dtest.out 2>&1
/bin/sh: line 1: 21385 Illegal instruction (core dumped) ./xlintstd
dtest.out 2>&1
make[1]: *** [dtest.out] Error 132
I've tri
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-07 16:07 ---
confirmed with trunk revision 149279.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
--- Comment #4 from mikpe at it dot uu dot se 2009-07-07 16:28 ---
A reghunt identified Jakub's (added to cc: list) r142481 (PR38367 fix) as the
source of this regression.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
--
--- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 16:31 ---
> > extern int c;
> > int a(void)
> > {
> >return *(short *)(void *)&c;
> > }
>
> This is a very bad example of a false positive as you are acessing an
> int as a short; that is undefine
--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 16:48 ---
"Why do you limit your stack boundary artificially?"
Because if I don't use FP code there is no point in aligning the stack.
Aligning the stack wastes stack space and code size and doesn't impr
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-07-07 16:54 ---
>So you say that converting the char * pointer to struct * pointer is understood
as "accessing the stored value" by the standard?
No.
Let's look at the code:
char buffer[512];
(void *)&((struct structure *)(void *)
--- Comment #8 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 16:45 ---
> Thus code is undefined you have an acess of a char array as a struct.
> Yes you are only taking the address of an element but it is still
> considered an acess by the standards.
Why is it und
--- Comment #1 from kargl at gcc dot gnu dot org 2009-07-07 17:28 ---
What happens if you compile with only '-O -pipe'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
On LTO branh, as of revision 149328
27_io/basic_filebuf/imbue/char/13171-2.cc
hangs on Linux/ia64.
--
Summary: [LTO] 27_io/basic_filebuf/imbue/char/13171-2.cc hangs
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
P
--- Comment #1 from hjl dot tools at gmail dot com 2009-07-07 17:31 ---
27_io/basic_filebuf/imbue/wchar_t/14975-2.cc also hangs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40674
--- Comment #2 from ubizjak at gmail dot com 2009-07-07 17:32 ---
Please add (minimized) testcase and all other info, as explained in [1].
Also, please post /proc/cpuid.
[1] http://gcc.gnu.org/bugs.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
--- Comment #2 from jason at gcc dot gnu dot org 2009-07-07 17:55 ---
Subject: Bug 40639
Author: jason
Date: Tue Jul 7 17:55:26 2009
New Revision: 149341
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149341
Log:
PR c++/37816
* decl.c (build_enumerator): Don't a
--- Comment #1 from jason at gcc dot gnu dot org 2009-07-07 17:55 ---
Subject: Bug 40633
Author: jason
Date: Tue Jul 7 17:55:26 2009
New Revision: 149341
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149341
Log:
PR c++/37816
* decl.c (build_enumerator): Don't a
--- Comment #2 from jason at gcc dot gnu dot org 2009-07-07 17:55 ---
Subject: Bug 37816
Author: jason
Date: Tue Jul 7 17:55:26 2009
New Revision: 149341
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149341
Log:
PR c++/37816
* decl.c (build_enumerator): Don't a
--- Comment #10 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 18:07 ---
So you mean that that ->x operator is invalid and break the standard?
Anyway the standard means "if you write your code according to the standard =>
the code will run correctly", but the inver
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-07-07 18:18
---
(In reply to comment #10)
> For example, you write "unsigned char *framebuffer = vga_getgraphmem();" and
> now you want to access the framebuffer. According to the standard, you could
> only do it by bytes. But tha
--- Comment #3 from ronis at ronispc dot chem dot mcgill dot ca 2009-07-07
18:41 ---
As per comment 2, here's my /proc/cupinfo. As to finding a minimized testcase,
this is nontrivial as I don't know if the problem is in a lapack routine or in
the testsuite routine itself. The package
--- Comment #4 from ronis at ronispc dot chem dot mcgill dot ca 2009-07-07
18:45 ---
As per comment #1, I compiled with '-O -pipe' (lapack added -fimplicit-none).
I get the same behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
--- Comment #9 from t dot artem at mailcity dot com 2009-07-07 18:45
---
Qt 4.5.2 /lib directory (without *.debug files) occupies
GCC 4.2.4: 43,649,379 bytes in 107 files
GCC 4.4.0: 46,544,895 bytes in 107 files
I don't like it at all. Compilation flags are still the same: -march=pent
sahp7641> /var/scratch2/gcc4/bin/gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4.0/configure --prefix=/var/scratch2/gcc4/
--enable-languages=c++,c,fortran --with-mpfr=/var/scratch2
Thread model: posix
gcc version 4.4.0 (GCC)
The sign intrinsic gives a
--- Comment #5 from ubizjak at gmail dot com 2009-07-07 18:57 ---
Unfortunately, it is nearly impossible to debug your problem without the
testcase, since the problem can not be analyzed.
Can you at least run the breaking case through a gdb? It will show invalid
instruction at the point
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-07 19:02 ---
Zeros have sign for FP value. Though I don't know if that is true for Fortran
standard ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-07 19:05 ---
Created an attachment (id=18151)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18151&action=view)
gcc44-pr40668.patch
Untested patch that fixes this testcase. I believe my commit was correct, but
apparently it
--- Comment #12 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 19:40 ---
So if there was char *buffer = malloc(512) instead of char buffer[512], would
it be correct to cast it to the pointer to structure?
> And it is not about the cast between the pointer types whi
--- Comment #2 from kargl at gcc dot gnu dot org 2009-07-07 19:43 ---
(In reply to comment #0)
> sahp7641> /var/scratch2/gcc4/bin/gfortran -v
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: ../gcc-4.4.0/configure --prefix=/var/scratch2/gcc4/
> --enable-langu
--- Comment #6 from ronis at ronispc dot chem dot mcgill dot ca 2009-07-07
19:45 ---
Turns out that the problem isn't in lapack/gfortran at all; rather the tests
link to blas (here atlas) and one of my blas libs was corrupted. I
rebuilt/reinstalled atlas and the problem goes away, eve
--- Comment #3 from gdsjaar at sandia dot gov 2009-07-07 19:51 ---
Subject: Re: sign intrinsic fails for value of 0.0
kargl at gcc dot gnu dot org wrote:
> --- Comment #2 from kargl at gcc dot gnu dot org 2009-07-07 19:43 ---
> (In reply to comment #0)
>
>> sahp7641> /var/s
--- Comment #4 from dominiq at lps dot ens dot fr 2009-07-07 19:53 ---
Steven beats me with the f95 standard: sign(0.5,-0.0) shall give -0.5.
Note that the code in comment #0 gives 'pass' with ifort but fails with g77.
I think the code is invalid since mysign is implicitely typed as int
--- Comment #2 from rwild at gcc dot gnu dot org 2009-07-07 19:57 ---
Subject: Bug 40010
Author: rwild
Date: Tue Jul 7 19:57:15 2009
New Revision: 149345
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149345
Log:
gcc/
2009-06-23 Mark Loeser
PR build/40010
*
--- Comment #5 from dominiq at lps dot ens dot fr 2009-07-07 19:59 ---
> OK, so I should instead be submitting a bug report for intel and g77 and
> pgi. gfortran is the only correct implementation?
The key point is: "If the processor cannot distinguish between positive and
negative re
--- Comment #6 from kargl at gcc dot gnu dot org 2009-07-07 20:05 ---
(In reply to comment #3)
> OK, so I should instead be submitting a bug report for intel and g77 and
> pgi. gfortran is the only correct implementation?
g77 is no longer supported. You can do want you want with bug
--- Comment #7 from kargl at gcc dot gnu dot org 2009-07-07 20:09 ---
(In reply to comment #5)
> > OK, so I should instead be submitting a bug report for intel and g77 and
> > pgi. gfortran is the only correct implementation?
>
> The key point is: "If the processor cannot distinguish
--- Comment #8 from gdsjaar at sandia dot gov 2009-07-07 20:13 ---
Subject: Re: sign intrinsic fails for value of 0.0
OK, sorry for the buggy example code. It illustrates the folly of
improving the code after doing the runs. A better fixed code
illustrating my point is:
progr
extracted from Wine
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -c -O2 dialog.i
dialog.i: In function 'xmsi_dialog_create':
dialog.i:33:1: error: definition in block 5 does not dominate use in block 7
for SSA_NAME: .MEM_21 in statement:
# VUSE <.MEM_21>
D.2749_15 = *szDialogName_13;
dialog.i:3
--- Comment #1 from marcus at jet dot franken dot de 2009-07-07 20:14
---
Created an attachment (id=18152)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18152&action=view)
dialog.i
gcc -c -O2 dialog.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40676
The compiler fails to generate lmw/stmw when compiling the attached test case.
(no_global_regs_above) never returns true.
Obvious fix with attached patch.
Note: I have no write privilege.
Compiled with:
gcc -Os -mcpu=601 -S test.c
--
Summary: flag -mmultiple is ignored
Pr
--- Comment #1 from edmar at freescale dot com 2009-07-07 20:21 ---
Created an attachment (id=18153)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18153&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from edmar at freescale dot com 2009-07-07 20:22 ---
Created an attachment (id=18154)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18154&action=view)
patch to fix bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-07-07 20:24
---
(In reply to comment #12)
> So if there was char *buffer = malloc(512) instead of char buffer[512], would
> it be correct to cast it to the pointer to structure?
Yes.
> > And it is not about the cast between the
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-07-07 20:46
---
Subject: Bug 40666
Author: ebotcazou
Date: Tue Jul 7 20:46:06 2009
New Revision: 149346
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149346
Log:
PR debug/40666
* dbxout.c (dbxout_symbol
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-07-07 20:46
---
Subject: Bug 40666
Author: ebotcazou
Date: Tue Jul 7 20:46:41 2009
New Revision: 149347
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149347
Log:
PR debug/40666
* dbxout.c (dbxout_symbol
--- Comment #9 from twscofi at sandia dot gov 2009-07-07 20:54 ---
(In reply to comment #6)
>
> g77 is no longer supported.
Per
http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gfortran/GNU-Fortran-and-G77.html#GNU-Fortran-and-G77
[Gfrortran] is an entirely new program that has been designed
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-07-07 20:57
---
Reopen if not.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #8 from jason at gcc dot gnu dot org 2009-07-07 22:04 ---
Subject: Bug 35828
Author: jason
Date: Tue Jul 7 22:03:42 2009
New Revision: 149351
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149351
Log:
PR c++/35828
* pt.c (tsubst_decl): Don't abort if
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-07 22:08 ---
Subject: Bug 40639
Author: jason
Date: Tue Jul 7 22:08:01 2009
New Revision: 149352
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149352
Log:
PR c++/37816
* decl.c (build_enumerator): Don't a
--- Comment #2 from jason at gcc dot gnu dot org 2009-07-07 22:08 ---
Subject: Bug 40633
Author: jason
Date: Tue Jul 7 22:08:01 2009
New Revision: 149352
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149352
Log:
PR c++/37816
* decl.c (build_enumerator): Don't a
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-07 22:08 ---
Subject: Bug 37816
Author: jason
Date: Tue Jul 7 22:08:01 2009
New Revision: 149352
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149352
Log:
PR c++/37816
* decl.c (build_enumerator): Don't a
--- Comment #9 from jason at gcc dot gnu dot org 2009-07-07 22:11 ---
Subject: Bug 35828
Author: jason
Date: Tue Jul 7 22:11:31 2009
New Revision: 149353
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149353
Log:
PR c++/35828
* pt.c (tsubst_decl): Don't abort if
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-07 22:12 ---
Fixed for 4.4.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from jason at gcc dot gnu dot org 2009-07-07 22:13 ---
Fixed for 4.4.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from jason at gcc dot gnu dot org 2009-07-07 22:13 ---
Done.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from jason at gcc dot gnu dot org 2009-07-07 22:14 ---
Fixed for 4.4.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #10 from jason at gcc dot gnu dot org 2009-07-07 22:16 ---
Fixed for 4.4.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NE
--- Comment #29 from manu at gcc dot gnu dot org 2009-07-07 22:18 ---
Subject: Bug 31246
Author: manu
Date: Tue Jul 7 22:18:35 2009
New Revision: 149354
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149354
Log:
2009-07-08 Manuel López-Ibáñez
PR c++/31246
--- Comment #30 from manu at gcc dot gnu dot org 2009-07-07 22:20 ---
FIXED in GCC 4.5.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|REO
--- Comment #8 from manu at gcc dot gnu dot org 2009-07-07 22:42 ---
I cannot reproduce this in GCC 4.4.0 or GCC 4.5 revision 149265. This was
probably FIXED at some moment but the testcase is too large for the testsuite.
--
manu at gcc dot gnu dot org changed:
What|R
Gfortran does not like me forgetting () on function calls.
Simple test code:
module ice
implicit none
contains
subroutine in_the
logical :: there_is
there_is = sunshine ! () are missing!
end subroutine
function sunshine()
logical :: sunshine
sunshine = .true.
--- Comment #6 from mikpe at it dot uu dot se 2009-07-07 23:10 ---
(In reply to comment #5)
> Created an attachment (id=18151)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18151&action=view) [edit]
> gcc44-pr40668.patch
>
> Untested patch that fixes this testcase.
Thanks. This f
--- Comment #2 from rth at gcc dot gnu dot org 2009-07-07 23:38 ---
I'll go farther than that and say that all single-precision fp numbers
destined for integer registers should be passed through the normal
constant splitting routines.
For instance, all positive powers of two satisfy th
--- Comment #2 from pault at gcc dot gnu dot org 2009-07-08 04:38 ---
Subject: Bug 40591
Author: pault
Date: Wed Jul 8 04:38:06 2009
New Revision: 149362
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149362
Log:
2008-07-08 Paul Thomas
PR fortran/40591
* dec
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-08 04:42 ---
Working in r149354.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCO
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-08 04:53 ---
Confirmed in r149354.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39022
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-08 05:28 ---
Working in r149354.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCO
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-08 05:41 ---
Fixed with:
2009-05-19 Diego Novillo
* lib/target-supports.exp (check_effective_target_lto): New.
* lib/c-torture.exp: Call it to set LTO_TORTURE_OPTIONS.
* lib/gcc-dg.exp: Likewise.
1 - 100 of 114 matches
Mail list logo
