--- Comment #2 from marcus at jet dot franken dot de 2007-07-03 20:08
---
got fixed by more recent commits ... no clue which.
will reopen if it happens again.
--
marcus at jet dot franken dot de changed:
What|Removed |Added
-
--- Comment #7 from burnus at gcc dot gnu dot org 2007-07-03 20:19 ---
Fixed in 4.3/trunk. -> Close
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from sje at cup dot hp dot com 2007-07-03 20:19 ---
I just tried to reproduce this bug on IA64 Linux (and HP-UX) with ToT sources
(version 126242) and was not able to. Can anyone else reproduce this with ToT
sources?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=322
Currently, the following is not handled:
integer :: i(10)
call foo(i(8)) ! has (8, 9, 10) -> Too short (3/4)
contains
subroutine foo(a)
integer :: a(4)
end subroutine
Longer test case, see TODO in gfortran.dg/argument_checking_5.f90.
See PR30940 for the references to the standard, see als
--- Comment #1 from dir at lanl dot gov 2007-07-03 20:36 ---
This is the last version that I have that it works with -
[dranta:~/tests/gfortran-D] dir% gfortran -c files.f90
[dranta:~/tests/gfortran-D] dir% gfortran --v
Using built-in specs.
Target: powerpc-apple-darwin8.9.0
Configured
In explow.c, there's this code:
if (GET_CODE (x) == SYMBOL_REF)
{
align = BITS_PER_UNIT;
if (SYMBOL_REF_DECL (x) && DECL_P (SYMBOL_REF_DECL (x)))
align = DECL_ALIGN (SYMBOL_REF_DECL (x));
}
If SYMBOL_REF_DECL(x) is a FUNCTION_DECL, DECL_ALIGN() does not h
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-03 21:00 ---
Mine.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-03 21:00 ---
Mine.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-03 21:05 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-07-03 21:06 ---
While I got the initially requested warning, ...
> INTENT(OUT) variables become undefined on subroutine
> or function entry. We should be able to warn if
> they are used:
... this seems to generally be the same pr
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-03 21:10 ---
Most likely:
2007-07-03 Daniel Berlin <[EMAIL PROTECTED]>
* tree-ssa-sccvn.c (set_ssa_val_to): Check for operand_equal_p
before declaring inequality.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #10 from burnus at gcc dot gnu dot org 2007-07-03 21:41 ---
Subject: Bug 25062
Author: burnus
Date: Tue Jul 3 21:41:34 2007
New Revision: 126279
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126279
Log:
2007-07-03 Tobias Burnus <[EMAIL PROTECTED]>
PR for
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-03 21:44 ---
A more general case as described in PR30939?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from burnus at gcc dot gnu dot org 2007-07-03 21:45 ---
Fixed. Note that the F95 standard is stricter than F2003. I added one -std=95
only check and two general checks. Still gfortran is too strict for F2003; see
PR32515.
--
burnus at gcc dot gnu dot org changed:
--- Comment #1 from kargl at gcc dot gnu dot org 2007-07-03 21:46 ---
Subject: Bug 32579
Author: kargl
Date: Tue Jul 3 21:45:59 2007
New Revision: 126280
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126280
Log:
2007-07-02 Christopher D. Rickett <[EMAIL PROTECTED]>
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot
|dot org
--- Comment #2 from kargl at gcc dot gnu dot org 2007-07-03 22:09 ---
Fixed. Thanks for the report Joost.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-07-03 22:15
---
Subject: Bug 32432
Author: jvdelisle
Date: Tue Jul 3 22:14:55 2007
New Revision: 126282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126282
Log:
2007-07-03 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-07-03 22:20
---
Fixed on Trunk, Closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-07-03 22:26
---
Reclassifying.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Compon
--- Comment #5 from paolo at gcc dot gnu dot org 2007-07-04 00:09 ---
Subject: Bug 31518
Author: paolo
Date: Wed Jul 4 00:09:22 2007
New Revision: 126287
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126287
Log:
2007-07-03 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-07-04 00:10
---
This is related to a recent patch of mine.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pcarlini at suse dot de 2007-07-04 00:10 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-07-04 00:21
---
Subject: Bug 31743
Author: mmitchel
Date: Wed Jul 4 00:21:33 2007
New Revision: 126292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126292
Log:
PR c++/31743
* parser.c (cp_parser_new_typ
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #4 from patchapp at dberlin dot org 2007-07-04 00:39 ---
Subject: Bug number PR32545
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-07/msg00303.html
--
http://gcc.gnu.org/bugzilla/sh
When using resize() and push_back(), an baseline instace of T is created and
then the new members are assigned via the copy constructor.
If T is complex this begins to add a non-negligible overhead, especially for
push_back.
Is there a reason /not/ to replace the [first] create & copy with in-pla
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-04 00:52 ---
> The optimization I am suggesting would produce the following [approximate]
is wrong. You have to bind a constant reference to a temp variable and then
doing a copy as you do a[0] = b;
So the optimization for res
--- Comment #2 from pcarlini at suse dot de 2007-07-04 01:02 ---
I suspect Oliver is raising a good point, in very general terms. Before going
into the details, I want to make sure he knows this proposal, which is likely
to make into C++0x, in some form:
http://www.open-std.org/jtc1/s
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-07-04 01:08
---
Subject: Bug 32545
Author: jvdelisle
Date: Wed Jul 4 01:08:48 2007
New Revision: 126295
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126295
Log:
2007-07-03 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-04 01:08
---
Subject: Bug 32612
Author: jvdelisle
Date: Wed Jul 4 01:08:48 2007
New Revision: 126295
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126295
Log:
2007-07-03 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-07-04 01:13
---
Subject: Bug 32612
Author: jvdelisle
Date: Wed Jul 4 01:13:47 2007
New Revision: 126296
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126296
Log:
2007-07-03 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-07-04 01:13
---
Subject: Bug 32545
Author: jvdelisle
Date: Wed Jul 4 01:13:47 2007
New Revision: 126296
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126296
Log:
2007-07-03 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-07-04 01:15
---
Fixed, closing. Thanks Dale for report.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-07-04 01:16
---
Fixed on trunk, closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from Joey dot ye at intel dot com 2007-07-04 01:17 ---
126198 brought the regression
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32598
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-07-04 01:25
---
This is OK now with the patch to 32432 committed today. Closing as duplicate.
*** This bug has been marked as a duplicate of 32432 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-07-04 01:25
---
*** Bug 25057 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
Using the 20070501 prerelease of gcc 4.2.0, to compile the following sample
app:
public class Foo
{
public static void main(String args[])
{
System.out.println("Hello.");
}
}
with the following command-line:
/usr/local/bin/gcj -v -save-temps -o Foo -static-libgcj --main=Foo Foo.java
yeilds a 35
--- Comment #1 from woody77 at gmail dot com 2007-07-04 02:40 ---
Same behavior with the "old style" method:
> gcj -c Foo.java
> gcj --main=Foo -save-temps Foo.java
> gcc -o Foo2 Foo.o Foomain.i -shared-libgcc -Wl,-non_shared -lgcj
> -Wl,-call_shared -lsupc++ -Wl,--as-needed -lz -lgcc_
I see a strange initialization problem. If I pass some function 'g' as an
argument fo another function 'wrap', I will get a bus error. If I call 'g'
from main before passing it as an argument, the code works correctly. In the
sample code, removing the two commented lines causes the call to 'wrap
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30243
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31941
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32108
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32164
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-04 03:23 ---
And this is not a bug, the library just got bigger. You know that your 95 byte
source pulls in all of locale, all of thread, most of the java.lang classes in
fact.
--
pinskia at gcc dot gnu dot org changed:
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32245
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32256
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32286
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- Comment #29 from mmitchel at gcc dot gnu dot org 2007-07-04 03:28
---
Diego, does this problem still exist on the 4.2 branch? I see that you checked
in a patch, which you suggest may not be a complete fix, but does this test
case still fail?
--
mmitchel at gcc dot gnu dot org c
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32414
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32519
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-07-04 03:31
---
Uros, is it feasible to backport this to 4.2?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-07-04 03:40
---
This is a very hard crash. No info from gdb.
Valgrind reports:
==14958== Conditional jump or move depends on uninitialised value(s)
==14958==at 0x430B31: strlen (in /home/jerry/prs/inwork/pr32620/a.out)
==14
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-04 03:43 ---
I don't think this is valid code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32620
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-04 03:49 ---
The main reason is that the interface for wrap is not known, and also g is
implicate(sp?) which means it is a real(4).
Actually it is the implicate(sp?) issue.
If I make what g is by doing:
external :: g
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-07-04 04:05
---
and lahey says:
2623-S: "SOURCE.F90", line 25: The actual argument shall be a procedure name
that associates the dummy argument 'f' of procedure 'wrap'. The previous
appearance is in 'line 1'.
2617-S: "SOURCE
--- Comment #5 from danp57 at optonline dot net 2007-07-04 04:16 ---
Subject: Re: dummy procedure problem
Inserting "implicit none" in the headings of all the functions/program
bodies made it clear that the main program did not know what type it was
passing. Explicit insertion of "r
--- Comment #3 from oliver at kfs dot org 2007-07-04 04:27 ---
Andrew, currently it seems to work like this (pseudo code warning):
T* newSpace = alloc(newSize);
int i = 0 ;
for ( ; i < size ; ++i ) {
newSpace[i].constructor(oldSpace[i]) ;
}
const T defaultInstance ;
for
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-04 04:34 ---
Well for one push_back takes "const T&". This is what I was talking about, you
can't really get any better in that case. Now the resize case is a different
story.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-07-04 04:58 ---
Subject: Bug 32506
Author: kkojima
Date: Wed Jul 4 04:57:59 2007
New Revision: 126299
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126299
Log:
PR target/32506
Backport from mainline.
--- Comment #5 from kkojima at gcc dot gnu dot org 2007-07-04 05:18 ---
Subject: Bug 32506
Author: kkojima
Date: Wed Jul 4 05:18:17 2007
New Revision: 126300
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126300
Log:
PR target/32506
Backport from mainline.
--- Comment #6 from kkojima at gcc dot gnu dot org 2007-07-04 05:20 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
extern int foo () __attribute__ ((weak));
extern int bar __attribute__ ((weak));
int
main ()
{
if (foo)
foo ();
if (&bar)
bar++;
return 0;
}
When compiled with -fPIC, the tests for non-zero foo and bar address have a pic
adjustment made before comparing against zero. If the code
--- Comment #10 from uros at gcc dot gnu dot org 2007-07-04 05:41 ---
Subject: Bug 31966
Author: uros
Date: Wed Jul 4 05:40:58 2007
New Revision: 126301
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126301
Log:
PR tree-optimization/31966
PR tree-optimization/32
--- Comment #13 from uros at gcc dot gnu dot org 2007-07-04 05:41 ---
Subject: Bug 32533
Author: uros
Date: Wed Jul 4 05:40:58 2007
New Revision: 126301
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126301
Log:
PR tree-optimization/31966
PR tree-optimization/32
--- Comment #5 from oliver at kfs dot org 2007-07-04 05:45 ---
Doh - yes - you're completely right about push_back. push_back itself isn't
incurring the temporary variable, Foo() is. Lost track of that investigating
the resize thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #14 from uros at gcc dot gnu dot org 2007-07-04 05:49 ---
Subject: Bug 32533
Author: uros
Date: Wed Jul 4 05:49:31 2007
New Revision: 126302
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126302
Log:
PR tree-optimization/31966
PR tree-optimization/32
--- Comment #11 from uros at gcc dot gnu dot org 2007-07-04 05:49 ---
Subject: Bug 31966
Author: uros
Date: Wed Jul 4 05:49:31 2007
New Revision: 126302
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126302
Log:
PR tree-optimization/31966
PR tree-optimization/32
--- Comment #12 from ubizjak at gmail dot com 2007-07-04 05:53 ---
(In reply to comment #11)
> It is up to bugmaster to reopen this PR, as the fix is not effective.
This is OK to leave as fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23115
--- Comment #12 from ubizjak at gmail dot com 2007-07-04 05:54 ---
Fixed on mainline and branches.
--
ubizjak at gmail dot com changed:
What|Removed |Added
St
--- Comment #15 from ubizjak at gmail dot com 2007-07-04 05:56 ---
(In reply to comment #12)
> Uros, is it feasible to backport this to 4.2?
Sure, the patch was just waiting a couple of days on mainline for possible
problems. This bug is now fixed on mainline and branches.
--
ubizj
--- Comment #5 from patchapp at dberlin dot org 2007-07-04 06:00 ---
Subject: Bug number PR24784
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-07/msg00326.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #5 from jv244 at cam dot ac dot uk 2007-07-04 06:19 ---
(In reply to comment #4)
> Subject: Bug number PR29651
>
> 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-05/msg02108.html
>
--- Comment #2 from jv244 at cam dot ac dot uk 2007-07-04 06:25 ---
(In reply to comment #1)
> This is a general problem for gfortran. A pointer to a component of an array
> of derived types cannot, at the moment be represented. Some brave soul need to
> come up with a proposal as to ho
--- Comment #7 from jv244 at cam dot ac dot uk 2007-07-04 06:29 ---
list link:
http://gcc.gnu.org/ml/fortran/2007-01/msg00361.html
this suggests that it is now an accepts-invalid bug with an easy fix
(Bug reporter / assignee should change keyword)
--
http://gcc.gnu.org/bugzilla/
--- Comment #8 from jv244 at cam dot ac dot uk 2007-07-04 06:33 ---
target milestone 4.3.0 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30625
--- Comment #4 from jv244 at cam dot ac dot uk 2007-07-04 06:35 ---
patch ping ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31119
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-04 06:40 ---
> patch ping?
Still working on this (that is, shunning it for the work involved). It does not
yet work correctly with actual arguments that are optional dummy arguments.
Thanks for the reminder :)
--
http://g
101 - 193 of 193 matches
Mail list logo
