--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-11-01 10:25 ---
Subject: Bug 37159
Author: tkoenig
Date: Sat Nov 1 10:24:15 2008
New Revision: 141511
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141511
Log:
2008-11-01 Dennis Wassel <[EMAIL PROTECTED]>
PR fo
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-11-01 10:29 ---
Committed patch.
Not closing yet, as the GET array could also be checked,
see http://gcc.gnu.org/ml/fortran/2008-10/msg00281.html .
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37159
Hi, this is my first bug report so im sorry if i stuff this up. I have a simple
c++ program which can reproduce this. im not sure if this is expected behavior,
but i cant find anything solid saying this is expected behavior and it seems
strange to me.
#include
class A
{
public:
--- Comment #1 from carlchatfield at gmail dot com 2008-11-01 10:41 ---
my apologies, this is expected behavior
--
carlchatfield at gmail dot com changed:
What|Removed |Added
-
I would have expected a warning "statement with no effect"
for this code:
$ cat tmp.c
unsigned char foo(unsigned char a)
{
a >> 2;
return a;
}
$ gcc -S -Wall -O3 -Wextra tmp.c
$
--
Summary: unsigned char shift lacks "statement with no effect"
warning
--- Comment #4 from dodji at gcc dot gnu dot org 2008-11-01 11:03 ---
I could reproduce this on 4.3 and trunk (4.4).
Actually I think there are several problems here.
First, I think the DIE representing the defining declaration of A::elsewhere in
class2.c should have a DW_AT_specificat
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-01 11:36 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.0
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|--- |4.2.5
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||ia64-linux-gnu
Priority|P3 |P4
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.4.0
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Summary|[4.4 regression]|[4.4 Regression]
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-01 11:43 ---
Hum, this is a host problem - and we do not have a list of primary or
secondary host platforms ... extrapolating from the secondary mingw32 target
platform I set this to P2.
--
rguenth at gcc dot gnu dot org chan
I am assuming that section 5.1.3 of [1] is sufficiently close to the final TR1.
In paragraph 2, the draft allows U, U&, U* as the first template parameter of
variate_generator. However, the following minimal program:
--
#include
int main(int argc, char **argv) {
std::tr1::mt19937 mt;
std::t
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.3.3
http://gcc
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-11-01 11:51
---
How is this a regression? In fact this seems to be fixed on the trunk and
instead the 4.3 branch and earlier releases suffer from memory/compile-time
explosion during inlining.
Marked as fixed. If the problem fr
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.4.0
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-11-01 12:17
---
Steve, if I knew how to fix this, I would have done so by now. I plan to
remove st43 and st44 in 4.5, this was merely a bandaid for the ABI breakage.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #9 from tsyvarev at ispras dot ru 2008-11-01 12:21 ---
Patch seems doesn't resolve problem entirely.
The thing is that, besides of constraints on setting eofbit flag, the standard
claims, that comparision (in == end) should be perfomed only when it is needed
for identify a ma
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-11-01 12:21
---
Jack, did this problem go away on Darwin?
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
--- Comment #18 from dominiq at lps dot ens dot fr 2008-11-01 12:32 ---
I have run the tests in comment #1 and main.bad main.init still fail on
i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
--- Comment #10 from paolo dot carlini at oracle dot com 2008-11-01 12:36
---
(In reply to comment #9)
> Declaration
>
> bool __testeof = __beg == __end;
>
> in the patched code means, that implementation always compares (in == end) at
> start, even when input and target sequences are
--- Comment #6 from kkojima at gcc dot gnu dot org 2008-11-01 12:40 ---
Subject: Bug 37769
Author: kkojima
Date: Sat Nov 1 12:39:17 2008
New Revision: 141513
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141513
Log:
Backport from mainline:
2008-10-24 Kaz Kojim
--- Comment #7 from kkojima at gcc dot gnu dot org 2008-11-01 12:45 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-11-01 12:47
---
Confirmed. On trunk R 141238. I can't get a very usable backtrace on this.
Maybe valgind will give us a hint on Linux box. This could also be a
Cygwin.dll issue.
--
jvdelisle at gcc dot gnu dot org changed
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-01 12:47 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-01 12:48 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-01 12:49 ---
Subject: Bug 37976
Author: rguenth
Date: Sat Nov 1 12:47:38 2008
New Revision: 141514
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141514
Log:
2008-11-01 Richard Guenther <[EMAIL PROTECTED]>
PR
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-11-01 12:57
---
Confirmed on recent trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from janus at gcc dot gnu dot org 2008-11-01 13:25 ---
Subject: Bug 36463
Author: janus
Date: Sat Nov 1 13:24:03 2008
New Revision: 141515
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141515
Log:
2008-11-01 Janus Weil <[EMAIL PROTECTED]>
PR fortran/
--- Comment #9 from janus at gcc dot gnu dot org 2008-11-01 13:25 ---
Subject: Bug 36322
Author: janus
Date: Sat Nov 1 13:24:03 2008
New Revision: 141515
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141515
Log:
2008-11-01 Janus Weil <[EMAIL PROTECTED]>
PR fortran/3
--- Comment #15 from domob at gcc dot gnu dot org 2008-11-01 13:27 ---
Subject: Bug 35681
Author: domob
Date: Sat Nov 1 13:26:19 2008
New Revision: 141516
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141516
Log:
2008-11-01 Daniel Kraft <[EMAIL PROTECTED]>
PR fortra
--- Comment #10 from janus at gcc dot gnu dot org 2008-11-01 13:33 ---
Rev. 141515 does not fix the complete test case on c.l.f., but most of the
troubles it made, including comment #8. Still I'm closing this PR, because
PR36463 is about the same c.l.f. code, and will be kept open to tra
--- Comment #16 from domob at gcc dot gnu dot org 2008-11-01 13:37 ---
This commit implements correct dependency and temporary handling if the
arguments to MVBITS are *not* expressions; thus it does not yet fix the
original test, although it fixes it if the parentheses are taken off the
--- Comment #11 from janus at gcc dot gnu dot org 2008-11-01 13:52 ---
r141515 eliminates the ICE in comment #2 and the c.l.f. example, so I guess
this can not be called a regression any more. Removing the [4.4 Regression]
tag.
--
janus at gcc dot gnu dot org changed:
Wha
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-01 13:54 ---
This doesn't fail anymore.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-01 14:00 ---
Invalid. TARGET_EXPRs behave like SAVE_EXPRs.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from janus at gcc dot gnu dot org 2008-11-01 14:06 ---
To clarify the situation regarding the code on c.l.f.: The link in comment #0
points to a thread which contains two example programs. One is called "fptr"
and uses Cray pointers, the other one is called "gptr" and use
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-01 14:14 ---
Seems to work now. DOM1 threads the jump, if disabled PRE correctly detects
the partial redundant calls and optimizes them. But we miss a jump threading
pass after PRE which makes us end up with
:
*neig = 3;
i
--- Comment #13 from janus at gcc dot gnu dot org 2008-11-01 14:20 ---
Here is a maximally reduced (and slightly modified) version of comment #12,
which gives the same error:
module other_fun
abstract interface
function abstract_fun(x)
integer x
integer abstr
--- Comment #5 from bonzini at gnu dot org 2008-11-01 14:26 ---
The problem is that this bug is unconfirmed. I'd like to see a failure log;
mingw builds were tested very carefully when we upgraded Libtool.
Marked as waiting.
--
bonzini at gnu dot org changed:
What|R
--- Comment #7 from dodji at gcc dot gnu dot org 2008-11-01 14:29 ---
I posted a patch to http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01278.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26693
--- Comment #2 from janus at gcc dot gnu dot org 2008-11-01 14:43 ---
I'm not completely convinced yet that the code in comment #0 is valid. While
g95 accepts it, ifort 11.0 beta says:
c0.f90(4): error #6362: The data types of the argument(s) are invalid. [LEN]
character(len=len(x)
--- Comment #3 from janus at gcc dot gnu dot org 2008-11-01 14:49 ---
Here is a modified version of comment #0:
abstract interface
function foo(x)
character(len=*) :: x
character(len=len(x)) :: foo
end function foo
end interface
character(len=20) :: str
procedure(foo) :: bar
s
--- Comment #4 from janus at gcc dot gnu dot org 2008-11-01 14:58 ---
A variant of comment #3 which gives a different error:
abstract interface
function foo(x,y)
character(len=*) :: x
integer y(:)
character(len=size(y)) :: foo
end function foo
end interface
character(len=20
--- Comment #5 from janus at gcc dot gnu dot org 2008-11-01 15:03 ---
For both comment #3 and comment #4 the errors disappear if the PROCEDURE
statement is removed and instead the interface is made non-abstract.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36426
When compiling attached file with "-march=iwmmxt -mtune=iwmmxt -O
-fno-omit-frame-pointer", then following error appears on line "score= sqr -
((diff*(int64_t)diff)>>(level+3))":
svq1enc.c: In function 'encode_block':
svq1enc.c:265: error: insn does not satisfy its constraints:
(insn 1636 1634 334
--- Comment #1 from utx at penguin dot cz 2008-11-01 15:12 ---
Created an attachment (id=16606)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16606&action=view)
svq1enc_e.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37987
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2008-11-01 15:13
---
Closing, thanks for patch.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from tsyvarev at ispras dot ru 2008-11-01 15:52 ---
It is not nitpicking. Case with empty sequences is only demonstration, that
code behaviour is not confirm to the standard.
Really, it seems that in every succesfull matching it will be unnecessary
comparision (in == end
--- Comment #12 from tsyvarev at ispras dot ru 2008-11-01 16:01 ---
Created an attachment (id=16607)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16607&action=view)
Test, whether there is an unnecessary comparision (in == end)
By hooking underflow() method of stringbuf, one can v
--- Comment #6 from jwakely dot gcc at gmail dot com 2008-11-01 16:18
---
This is a compile-time test which should fail because undef cannot be
instantiated, but the deallocation function is not used.
#include
template class undef;
struct A {
A() { throw 1; }
};
template class P
--- Comment #9 from danglin at gcc dot gnu dot org 2008-11-01 16:18 ---
Breakpoint 1, cgraph_build_static_cdtor (which=-52 '?', body=0x400555d8,
priority=1074005676) at ../../gcc/gcc/cgraphunit.c:1353
1353 sprintf (which_buf, "%c_%.5d_%d", which, priority, counter++);
(gdb) bt
--- Comment #13 from paolo at gcc dot gnu dot org 2008-11-01 16:19 ---
Subject: Bug 37958
Author: paolo
Date: Sat Nov 1 16:17:42 2008
New Revision: 141517
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141517
Log:
2008-11-01 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #14 from paolo dot carlini at oracle dot com 2008-11-01 16:22
---
Ok, ok. In the future, please don't lump issues together (i.e., do not reopen
PRs if the first commit fixes the original issue, file a separate one) and
always provide specific testcases.
--
paolo dot carl
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1086da75f7aed669
The following program is invalid as the (Holerith) string has 22 and not 21
characters. Thus the format is ...T).
gfortran accepts the program at compile time, but rejects it at run time with:
Fortran
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-11-01 16:32
---
I will attend to this if you dont beat me to it.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-11-01 16:39
---
Are you trying to "make" from within the source directory?
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2008-11-01 16:43
---
Subject: Bug 19925
Author: jvdelisle
Date: Sat Nov 1 16:42:31 2008
New Revision: 141518
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141518
Log:
2008-11-01 Steven G. Kargl <[EMAIL PROTECTED]>
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-01
16:49 ---
Subject: Re: [4.4 Regression] libgcj linkage failure:
Incorrect library ABI version detected
On Sat, 01 Nov 2008, danglin at gcc dot gnu dot org wrote:
Possibly the attached change will fix the p
--- Comment #31 from jvdelisle at gcc dot gnu dot org 2008-11-01 17:02
---
Subject: Bug 19925
Author: jvdelisle
Date: Sat Nov 1 17:00:49 2008
New Revision: 141519
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141519
Log:
2008-11-01 Steven G. Kargl <[EMAIL PROTECTED]>
--- Comment #32 from jvdelisle at gcc dot gnu dot org 2008-11-01 17:07
---
Finally, I hope. :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-01 17:11 ---
We need to be careful with simplifying to SSA_NAMEs as the following example
shows:
int foo (int i, int b)
{
int mask;
int result;
if (b)
mask = -1;
else
mask = 0;
result = i + 1;
result = result
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-01 17:12 ---
Created an attachment (id=16609)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16609&action=view)
preliminary patch
preliminary patch, only dealing with optimizing to constants.
--
http://gcc.gnu.org/bugz
--- Comment #8 from manu at gcc dot gnu dot org 2008-11-01 17:44 ---
This is my current patch and it works in this testcase. However, it also
triggers on cases like: const char *p = str + sizeof(str)
Perhaps I am doing this at the wrong place. Any suggestions?
@@ -3322,10 +3323,36 @@
gcc-4.4-20081003 and later configured with --disable-shared for mingw32 attempt
to link with libgcc_eh.a even though it never built libgcc_eh.a (those object
files are included in libgcc.a):
/home/mikpe/gcc-4.4-20081031/configure --target=x86_64-pc-mingw32
--prefix=/tmp/cross-mingw64 --disable-nls
--- Comment #1 from mikpe at it dot uu dot se 2008-11-01 18:10 ---
Created an attachment (id=16610)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16610&action=view)
patch to unbreak --disable-shared on mingw32
Proposed patch to unbreak --disable-shared on mingw32. When PR37528 cha
--- Comment #15 from tsyvarev at ispras dot ru 2008-11-01 18:43 ---
I belived that the easier describe situation is the better.
Because setting flag is simpler to observe, than the fact of comparision (in ==
end), PR was reported about flag but comparision.
But the second patch is also
--- Comment #16 from paolo dot carlini at oracle dot com 2008-11-01 18:48
---
(In reply to comment #15)
> But the second patch is also not correct...
I don't see why.
> If run test in the second attachment, in the second testcase(falsename -
> "false", "truename" - true, input - "fals
--- Comment #2 from danglin at gcc dot gnu dot org 2008-11-01 18:54 ---
Except for the fail noted in PR 37610, the problems with the new .cfi
directives have been fixed by a combination of assembler and gcc fixes.
The assembler fixes are currently only available from CVS.
--
danglin
--- Comment #17 from paolo dot carlini at oracle dot com 2008-11-01 19:05
---
Ok, I see that for true in input eofbit should not be set. I'll fix this, but
your testcase is wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
--- Comment #6 from janus at gcc dot gnu dot org 2008-11-01 19:06 ---
The following patch fixes comment #3 and comment #4:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 141520)
+++ gcc/fortran/expr.c (wor
--- Comment #1 from danglin at gcc dot gnu dot org 2008-11-01 19:13 ---
No longer fails.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #10 from danglin at gcc dot gnu dot org 2008-11-01 19:25
---
This seems to be fixed with 4.4.0 as of 2008-11-01.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35193
--- Comment #7 from danglin at gcc dot gnu dot org 2008-11-01 19:39 ---
These tests no longer fail on either 4.3 or 4.4. I am fairly
certain that these failures were a libc problem.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from pault at gcc dot gnu dot org 2008-11-01 19:46 ---
Mikael,
Thanks for the report and the fix:-)
Fixed on trunk and 4.3
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pault at gcc dot gnu dot org 2008-11-01 19:47 ---
Subject: Bug 37903
Author: pault
Date: Sat Nov 1 19:45:41 2008
New Revision: 141521
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141521
Log:
2008-11-01 Mikael Morin <[EMAIL PROTECTED]>
PR fortra
--- Comment #5 from pault at gcc dot gnu dot org 2008-11-01 19:47 ---
Subject: Bug 37749
Author: pault
Date: Sat Nov 1 19:45:41 2008
New Revision: 141521
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141521
Log:
2008-11-01 Mikael Morin <[EMAIL PROTECTED]>
PR fortran
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-01 19:47 ---
Jakub,
Thanks for the report - fixed by Mikael on trunk and 4.3.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from dominiq at lps dot ens dot fr 2008-11-01 20:13 ---
With the patch in comment #6 the following code gives an ICE:
subroutine sub(x)
abstract interface
character function abs_fun()
end function
end interface
procedure(abs_fun):: x
end subroutine
end
[ibo
--- Comment #69 from danglin at gcc dot gnu dot org 2008-11-01 20:15
---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #1 from danglin at gcc dot gnu dot org 2008-11-01 20:23 ---
4.3.3 20081006 revision 140917 and 4.4.0 20081027 revision 141382
are ok.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from ubizjak at gmail dot com 2008-11-01 21:04 ---
There was similar problem on x86 target with sun as and ffreep mnemonic. This
was fixed by a configure check and conditional generation of either "ffreep" or
".word\t0x".
Please grep for HAVE_AS_IX86_FFREEP.
--
h
--- Comment #5 from janus at gcc dot gnu dot org 2008-11-01 21:19 ---
On a related note: The following snippet from PR36426 produces an ICE.
function foo(x)
character(len=len(x)) :: foo,x
end function foo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35040
DESCRIPTION:
Simple test case is below.
There is redundant stack manipulation in the assembly output.
Use gcc -Wall -Os -S test.c
-
VERSION INFO:
--
gcc -v
Using built-in specs.
Target:
I just tried to compile the attached C++ source code with both
gcc 4.3.1 and gcc 4.4.0 snapshot 20081031.
gcc 431 took less than one second and consumed a trivial amount
of virtual memory.
gcc 440 snapshot 20081031 took over 90 seconds on an idle machine,
and consumed over 11 Gig of virtual memor
--- Comment #1 from dcb314 at hotmail dot com 2008-11-01 21:28 ---
Created an attachment (id=16611)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16611&action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37991
--- Comment #8 from janus at gcc dot gnu dot org 2008-11-01 21:57 ---
Subject: Bug 36426
Author: janus
Date: Sat Nov 1 21:56:27 2008
New Revision: 141522
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141522
Log:
2008-11-01 Janus Weil <[EMAIL PROTECTED]>
PR fortran/3
--- Comment #9 from janus at gcc dot gnu dot org 2008-11-01 22:00 ---
Fixed with r141522. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Split off from PR 35040 comment 5. The following program gives now an ICE:
function foo(x)
character(len=len(x)) :: foo,x
end function foo
With 4.3 there is no ICE, but with 4.4 there is an ICE after the (new!) error
detection. ("len(x)... :: x" is invalid.)
Valgrind shows a huge number of
/Users/dave/Documents/gnu/gcc/objdir/./gcc/xgcc
-B/Users/dave/Documents/gnu/gcc/
objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.4.0/i686-apple-darwin9/bin/
-B/opt/gnu/gcc/gc
c-4.4.0/i686-apple-darwin9/lib/ -isystem
/opt/gnu/gcc/gcc-4.4.0/i686-apple-darwi
n9/include -isystem /opt/gnu/gcc/gcc-4.4.0/i686-apple-da
--- Comment #18 from paolo at gcc dot gnu dot org 2008-11-01 22:10 ---
Subject: Bug 37958
Author: paolo
Date: Sat Nov 1 22:09:43 2008
New Revision: 141523
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141523
Log:
2008-11-01 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #6 from burnus at gcc dot gnu dot org 2008-11-01 22:14 ---
(In reply to comment #5)
> On a related note: The following snippet from PR36426 produces an ICE.
> function foo(x)
>character(len=len(x)) :: foo,x
> end function foo
As this ICE is a regression, I opened the P
--- Comment #3 from hp at gcc dot gnu dot org 2008-11-01 22:17 ---
Subject: Bug 37939
Author: hp
Date: Sat Nov 1 22:16:09 2008
New Revision: 141524
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141524
Log:
PR target/37939
* config/cris/cris.c (cris_rtx_costs) :
--- Comment #4 from hp at gcc dot gnu dot org 2008-11-01 22:20 ---
Subject: Bug 37939
Author: hp
Date: Sat Nov 1 22:19:26 2008
New Revision: 141525
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141525
Log:
PR target/37939
* gcc.target/cris/biap.c: New test.
Ad
--- Comment #5 from hp at gcc dot gnu dot org 2008-11-01 22:28 ---
Subject: Bug 37939
Author: hp
Date: Sat Nov 1 22:26:43 2008
New Revision: 141526
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141526
Log:
PR target/37939
* config/cris/cris.c (cris_rtx_costs) :
--- Comment #6 from hp at gcc dot gnu dot org 2008-11-01 22:29 ---
Subject: Bug 37939
Author: hp
Date: Sat Nov 1 22:28:28 2008
New Revision: 141527
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141527
Log:
PR target/37939
* gcc.target/cris/biap.c: New test.
Ad
1 - 100 of 106 matches
Mail list logo
