--- Comment #39 from bonzini at gnu dot org 2007-08-06 08:08 ---
committed??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
--- Comment #1 from nickc at redhat dot com 2007-08-06 08:12 ---
Subject: Re: New: -frecord-gcc-switches issues
Hi Jakub,
> .ascii "-isystem ./include-fixed"
> .zero 1
> .ascii "-D_GNU_SOURCE a.c"
> .zero 1
> The main issue I have with this is t
--- Comment #9 from zhouyi04 at ios dot cn 2007-08-06 08:40 ---
(In reply to comment #8)
I try to compile my giving C program using gcc-4.2.1, the problem still exists.
As my solution 1 suggests:
a caller function is inlinable only if all of its callee functions are
inlinable. while thi
--- Comment #8 from sgh at sgh dot dk 2007-08-06 09:08 ---
also fails on 4.2.1
--
sgh at sgh dot dk changed:
What|Removed |Added
CC|
--- Comment #3 from pcarlini at suse dot de 2007-08-06 09:13 ---
Yes, the standard is clear that array of unknown bound of T and array of N of T
are different types. And we are all implementing the is_array trait with 2
specializations (Vandevoorde and Josuttis included in their book).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-06 09:18 ---
Subject: Bug 19532
Author: paolo
Date: Mon Aug 6 09:18:39 2007
New Revision: 127238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127238
Log:
2007-08-06 Paolo Carlini <[EMAIL PROTECTED]>
PR c++/19
--- Comment #3 from pcarlini at suse dot de 2007-08-06 09:19 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-06 09:20
---
Without any more news, let's consider this fixed. Douglas, if it so happens
that your bug wasn't fixed by the patch, please reopen this bug-report.
--
fxcoudert at gcc dot gnu dot org changed:
What
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-06 09:49
---
OK, I downloaded GlobSol and have a reduced testcase:
$ cat pr32926.f90
subroutine foo (fcn)
external fcn
contains
subroutine bar
call fcn
end subroutine bar
end subroutine foo
$ gfortran pr32926.f90
pr
d1mach.f:90.43:
DATA LARGE(1), LARGE(2) / Z'', Z'7FEF' /
1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1)
--
Summary: error with hexadecimal DATA
Product: gcc
Versi
--- Comment #1 from sliwa at cft dot edu dot pl 2007-08-06 11:03 ---
Created an attachment (id=14028)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14028&action=view)
sample source that does not compile
This is a SLATEC machine file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
Statements like:
DATA DMACH(1) / Z'0010' /
DATA DMACH(2) / Z'7FEF' /
DATA DMACH(3) / Z'3CA0' /
DATA DMACH(4) / Z'3CB0' /
DATA DMACH(5) / Z'3FD34413509F79FF' /
generate incorrect data.
--
Summary: 64-bit he
--- Comment #1 from sliwa at cft dot edu dot pl 2007-08-06 11:15 ---
Created an attachment (id=14029)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14029&action=view)
sample source that demonstrates the problem
This is a SLATEC machine file
--
http://gcc.gnu.org/bugzilla/show
--- Comment #17 from gerald at gcc dot gnu dot org 2007-08-06 11:10 ---
Subject: Bug 13676
Author: gerald
Date: Mon Aug 6 11:10:19 2007
New Revision: 127239
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127239
Log:
PR pch/13676
* doc/invoke.texi: Add .hp, .hxx,
--- Comment #2 from sliwa at cft dot edu dot pl 2007-08-06 11:18 ---
There is also bug #33001. Both the bugs together make life difficult.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
--- Comment #3 from sliwa at cft dot edu dot pl 2007-08-06 11:21 ---
Now I see that 32-bit data is incorrect also.
DATA RMACH(1) / Z'0080' /
DATA RMACH(2) / Z'7F7F' /
DATA RMACH(3) / Z'3380' /
DATA RMACH(4) / Z'3400' /
DATA RMACH(5) / Z'3E9A
--- Comment #40 from pinskia at gcc dot gnu dot org 2007-08-06 11:35
---
(In reply to comment #39)
> committed??
This is now more like a meta-bug, see the other two bugs which are opened for
the current issues (yes both are assigned to me and both are actively being
worked on, well one
--- Comment #6 from pcarlini at suse dot de 2007-08-06 11:52 ---
The subtle issue here is that this specific error message should be emitted
*only* when the incorrectly specified return type doesn't match, thus a plain
error instead of a pedwarn:
case sfk_conversion:
if (type
--- Comment #41 from paolo dot bonzini at lu dot unisi dot ch 2007-08-06
11:52 ---
Subject: Re: [4.2/4.3 Regression] Performace problem
with indexed load/stores on powerpc
> This is now more like a meta-bug, see the other two bugs which are opened for
> the current issues (yes both
class X
{
public:
static X& instance();
static void init();
private:
X();
};
void f()
{
X& x = X::instance();
x.init();
}
in this case the 'x' variable is initialized and unused.
gcc-4.2 accepts this w/o any warning at -Wall -Wextra
but vs2005-express repor
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-06 12:11 ---
DATA LARGE(1), LARGE(2) / Z'', Z'7FEF' /
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1)
The error message is correct: You cannot fit the number into an INTEGER(
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 12:33 ---
To the developer (and me), x is not unused.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33003
On 6 Aug 2007 12:42:18 -, pluto at agmk dot net
<[EMAIL PROTECTED]> wrote:
> moreover i'm wondering why gcc uses movdqa for unaligned loads?
Because __m128i is assumed to be aligned.
-- Pinski
--- Comment #4 from sliwa at cft dot edu dot pl 2007-08-06 12:45 ---
With -fno-range-check I get:
d1mach.f: In function 'd1mach':
d1mach.f:2: fatal error: gfc_todo: Not Implemented: Initialization of
overlapping variables
compilation terminated.
See also bug #33002.
--
http://gcc.
--- Comment #12 from aph at gcc dot gnu dot org 2007-08-06 12:48 ---
Subject: Bug 32843
Author: aph
Date: Mon Aug 6 12:48:07 2007
New Revision: 127241
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127241
Log:
PR testsuite/32843
* src/x86/sysv.S (ffi_closure_raw
--- Comment #2 from pluto at agmk dot net 2007-08-06 12:42 ---
thanks for ths explanation about aligned attribute.
moreover i'm wondering why gcc uses movdqa for unaligned loads?
it should use movdqu for *((__m128i*)ptr) and _mm_set_epi8(ptr[15],...,ptr[0]).
--
http://gcc.gnu.org/b
--- Comment #3 from sliwa at cft dot edu dot pl 2007-08-06 12:41 ---
1. The attached d1mach.f works fine with g77.
2. The numbers are 32-bit, so why an overflow? Maybe the number is extended as
a signed number (padded with ones), and the conversion is unsigned.
--
http://gcc.gnu.or
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-06 12:49 ---
Using
REAL RMACH(5)
DATA RMACH(1) / Z'0080' /
is invalid Fortran 77/90/95/2003 as Fortran only allows:
"If a data-stmt-constant is a boz-literal-constant, the corresponding variable
shall be of type
--- Comment #13 from aph at gcc dot gnu dot org 2007-08-06 12:53 ---
> The 32bit psABI specifies Integral Arguments as 'Functions pass all
> integer-valued
> arguments as words, expanding or padding signed or unsigned bytes and
> halfwords as needed'. For return values the best I can fin
--- Comment #4 from pluto at agmk dot net 2007-08-06 12:56 ---
(In reply to comment #3)
> Subject: Re: missed memcpy -> movdqa optimization.
>
> On 6 Aug 2007 12:42:18 -, pluto at agmk dot net
> <[EMAIL PROTECTED]> wrote:
> > moreover i'm wondering why gcc uses movdqa for unaligned
--- Comment #3 from pinskia at gmail dot com 2007-08-06 12:43 ---
Subject: Re: missed memcpy -> movdqa optimization.
On 6 Aug 2007 12:42:18 -, pluto at agmk dot net
<[EMAIL PROTECTED]> wrote:
> moreover i'm wondering why gcc uses movdqa for unaligned loads?
Because __m128i is assu
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-06 13:15
---
Maybe I'm completely off, but isn't the -fpack-derived option what is needed to
play with this padding? (it's hard for me to tell exactly, because I don't
really read assembly) If so, could we close the PR?
--
--- Comment #2 from drow at gcc dot gnu dot org 2007-08-06 13:21 ---
Subject: Re: New: [Regression] gdb has symbol table issues
On Sat, Aug 04, 2007 at 11:13:11PM -, scovich at gmail dot com wrote:
> When debugging code produced by g++-4.3.0-20070716 the debugger regularly
> outpu
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-06 13:06 ---
> The numbers are 32-bit, so why an overflow?
huge(0): 2147483647 ! biggest (positive) number fitting into integer(4)
Z'': 4294967295
I would argue that 4294967295 is bigger than 2147483647. If one allo
--- Comment #14 from aph at gcc dot gnu dot org 2007-08-06 13:35 ---
In addition: I suspect that this bug also is manifested on x86 Darwin, but my
patch should not affect that system at all, and therefore I suspect that this
bug is still manifested on that system.
--
http://gcc.gnu.
--- Comment #1 from hjl at lucon dot org 2007-08-06 13:44 ---
Can you verify if it is the same as PR 31868? There is a a patch for PR 31868.
--
hjl at lucon dot org changed:
What|Removed |Added
--
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2007-01-31 23:01:50 |2007-08-06 13:47:12
date|
The following code doesn't compile under gcc-4.2.1 on i686-pc-linux-gnu:
template void foo(T);
void foo(int);
void bar()
{
&foo;
}
According to the discussion that began on thread
http://gcc.gnu.org/ml/gcc/2007-07/msg00663.html, then resumed on thread
http://gcc.gnu.org/ml/gcc/2007-07/msg00
The code below doesn't compile under gcc-4.2.1 on a i686-pc-linux-gnu
template void foo(T);
void bar()
{
&foo;
}
The compiler returns the following error message:
teste.cpp: In function void bar():
teste.cpp:4: error: statement cannot resolve address of overloaded function
As we're specif
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 13:57 ---
*** This bug has been marked as a duplicate of 11407 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-06 13:57
---
*** Bug 33005 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 13:58 ---
*** This bug has been marked as a duplicate of 5458 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-06 13:58
---
*** Bug 33004 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-06 14:18 ---
Subject: Bug 30731
Author: pinskia
Date: Mon Aug 6 14:17:59 2007
New Revision: 127242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127242
Log:
2007-08-06 Andrew Pinski <[EMAIL PROTECTED]>
PR li
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-06 14:18 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from rodolfo at rodsoft dot org 2007-08-06 14:18 ---
This is an yet simpler case where this bug shows up:
template void foo(T);
void foo(int);
void bar()
{
&foo;
}
i686-pc-linux-gnu-g++-4.2.1 fails with:
teste.cpp: In function void bar():
teste.cpp:6: error: st
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-06 14:41 ---
We get a different ICE now:
t1.cc:4: internal compiler error: same canonical type node for different types
A and A
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-06 14:57
---
Has this been fixed now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Keywords||error-recovery
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-06 15:12 ---
I no longer get a segfault for the trunk for the first testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-06 15:25 ---
Fixed. And has been for a while.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:28 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:29 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:38 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:44 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-08-06 15:47
---
Fixed for the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:53 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #7 from dcb314 at hotmail dot com 2007-08-06 16:06 ---
(In reply to comment #6)
> This is one which you need huge dataflow analysis
Doubtful. Yes/No/Don't know flag on each pointer data
member of a class would be some of it.
> and whole program to detect this problem.
I'd
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-08-06 16:16
---
Not that I know. For my purposes, I use a hand-modified version of the _mingw.h
header; maybe more recent versions of mingw have been fixed. Still, current
trunk doesn't work with older mingw (more than a few mon
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-08-06 16:16 ---
thanks for adding this bug report here and ccing me.
Is there an easy way to separate out the include and link (-I, -L) bits from
the macro defines and compiler option flags? Could the just the include bits be
put int
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|powerpc64-unknown-linux-gnu |
GCC host triplet|powerpc64-unknown-linux-gnu |
GCC target triplet
--- Comment #6 from kargl at gcc dot gnu dot org 2007-08-06 17:30 ---
*** This bug has been marked as a duplicate of 18026 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from kargl at gcc dot gnu dot org 2007-08-06 17:30 ---
*** Bug 33001 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
When I attempt to compile the program listed below I get the following message:
a.f90: In function 'MAIN__':
a.f90:2: internal compiler error: in simplify_subreg, at simplify-rtx.c:4676
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for
--- Comment #5 from kargl at gcc dot gnu dot org 2007-08-06 17:32 ---
*** This bug has been marked as a duplicate of 18026 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from kargl at gcc dot gnu dot org 2007-08-06 17:32 ---
*** Bug 33002 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 17:35 ---
>3. The program was compiled with the flag "-fdefault-integer-8". It does not
> produce the error without this flag.
Yes we know, we are trying to resolve more and more of these
-fdefault-integer-8 bugs.
*** This b
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-06 17:35 ---
*** Bug 33006 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #18 from pluto at agmk dot net 2007-08-06 17:49 ---
(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > (In reply to comment #14)
> > > > (In reply to comment #13)
> > > > > Created an attachment (id=13550)
--> (http://gcc.gnu.org/bugzil
--- Comment #19 from hjl at lucon dot org 2007-08-06 18:02 ---
If we can find which patch causes this regression, it will help find a
solution for 4.2.
--
hjl at lucon dot org changed:
What|Removed |Added
---
--- Comment #7 from patchapp at dberlin dot org 2007-08-06 18:20 ---
Subject: Bug number PR33001
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00374.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #20 from pluto at agmk dot net 2007-08-06 18:28 ---
(In reply to comment #19)
> If we can find which patch causes this regression, it will help find a
> solution for 4.2.
>
i'll we do a bisect hunting...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
--- Comment #3 from roland at redhat dot com 2007-08-06 19:19 ---
Absolute file names are a very bad idea. That makes for gratuitous differences
in builds due to the build or source directory name, i.e. unrepeatable builds.
The names in .debug_line and .debug_info are already expected
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-06 19:22 ---
This patch helps more than just PR 28690 as we now have the ablity to use r0
more for the index which causes us to use one less callee saved register in
some cases and reduces the stack size. I saw that result whil
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-06 19:23 ---
Patch for the first part. Missing: Check for default initializer.
Index: resolve.c
===
--- resolve.c (revision 127246)
+++ resolve.c (working copy)
--- Comment #3 from hjl at gcc dot gnu dot org 2007-08-06 19:58 ---
Subject: Bug 31868
Author: hjl
Date: Mon Aug 6 19:58:11 2007
New Revision: 127248
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127248
Log:
2007-08-06 H.J. Lu <[EMAIL PROTECTED]>
Daniel Jacobowit
--- Comment #15 from doko at gcc dot gnu dot org 2007-08-06 20:13 ---
Subject: Bug 32843
Author: doko
Date: Mon Aug 6 20:13:06 2007
New Revision: 127249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127249
Log:
- Revert the changes for PR testsuite/32843, not needed on the bra
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-06 20:18 ---
Besides default initializers (TODO), I also forgot about the following, to be
added after the if clause of previous patch:
else if (csym->ts.type == BT_DERIVED
&& csym->ts.derived->att
--- Comment #8 from andreast at gcc dot gnu dot org 2007-08-06 20:34
---
Happens since r125624. Same situation on ppc-linux (32-bit)
In the libjava testsuite you'll see the following test cases failing since
then:
FAIL: noclass execution - gij test
FAIL: pr11951 execution - gij test
F
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-06 20:47
---
Subject: Bug 29828
Author: fxcoudert
Date: Mon Aug 6 20:47:17 2007
New Revision: 127252
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127252
Log:
PR fortran/29828
* trans.h (gfor_fndecl
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-06 20:49
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-06 21:13
---
It's not about being allocatable, it's the I/O operation that doesn't perform
the necessary check:
$ cat a.f90
real :: x(2,2)
x = 0.
print *, x(5,:)
x(5,:) = 1.
end
$ gfortran -fbounds-check a.f90 && ./a.
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-06 21:18
---
I don't think it's a duplicate, and I don't think it has anything to do with
allocatable either:
$ cat b.f90
subroutine foo(n)
integer, allocatable :: ivec(:)
integer :: jvec(n)
allocate (ivec(n))
ivec =
--- Comment #5 from aaw at gcc dot gnu dot org 2007-08-06 21:24 ---
No segfault, but it does give an "is already declared in this scope" error.
Contrary to the claim in the initial bug submission, this is valid code.
>From paragraph 10, section 7.3.3 of the C++ standard:
Since a using
--- Comment #21 from pluto at agmk dot net 2007-08-06 21:39 ---
rev. 101665:
convert:movl%edi, -4(%rsp)
movl%edi, -20(%rsp)
movss -4(%rsp), %xmm0
ret
load: movzwl (%rdi), %eax
ret
rev. 101666 (-fforce-mem removal):
convert:movl%edi, -4(
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-06 21:40 ---
well to some extend dealloc is special method which is why the warning is
there. Also dealloc does not belong to the the original Object class (which is
based on the old NX Object base class). This is true of the N
--- Comment #18 from pinskia at gcc dot gnu dot org 2007-08-06 21:43
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Target Milestone|--- |4.3.0
http:/
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:29
---
Subject: Bug 30933
Author: fxcoudert
Date: Mon Aug 6 22:29:24 2007
New Revision: 127256
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127256
Log:
PR fortran/30933
* iresolve.c (gfc_resol
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:29
---
Last bit fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:44
---
Subject: Bug 30933
Author: fxcoudert
Date: Mon Aug 6 22:44:27 2007
New Revision: 127257
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127257
Log:
PR fortran/30933
* intrinsic.c (add_fun
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:45
---
Last bit fixed: http://gcc.gnu.org/viewcvs?view=rev&revision=127257
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-06 23:03
---
Subject: Bug 30947
Author: fxcoudert
Date: Mon Aug 6 23:02:38 2007
New Revision: 127259
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127259
Log:
PR fortran/30947
* iresolve.c (gfc_reso
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-08-06 23:05
---
This should fix the remaining part.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janis at gcc dot gnu dot org 2007-08-06 23:15 ---
A regression hunt of mainline on powerpc-linux identified the following patch,
where the compiler went from compiling in a reasonable time to taking more than
three seconds for the submitter's testcase:
r117696 |
--- Comment #6 from aaw at gcc dot gnu dot org 2007-08-06 23:17 ---
Created an attachment (id=14030)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14030&action=view)
Fix for PR 31749.
This patches fixes this PR and includes some ambiguous decl cleanup as well.
Submission pending
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-06 23:46
---
Hi Tobias, what do you think about this patch? I think it would add %u for
unsigned int, %lu for unsigned long int, %li and %ld for long int. I have no
time to test, but I think it should work ok (I wrote the curr
--- Comment #22 from hjl at lucon dot org 2007-08-07 00:22 ---
There are 2 issues, convert and load. They may be caused by different
patches and should be tracked separately when doing binary search.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
1 - 100 of 107 matches
Mail list logo
