--- Comment #22 from bert dot hubert at netherlabs dot nl 2006-05-22 05:20
---
Subject: Re: __gnu_cxx::__exchange_and_add is called even for single threaded
applications
On Sun, May 21, 2006 at 08:28:45PM -, pcarlini at suse dot de wrote:
> --- Comment #21 from pcarlini at sus
--- Comment #2 from patchapp at dberlin dot org 2006-05-22 04:35 ---
Subject: Bug number PR27634
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/2006-05/msg01083.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from arjen dot markus at wldelft dot nl 2006-05-22 04:33
---
Subject: Re: Linking example programs for PLplot causes error messages about
multiple definition of __gfortran_transfer_character
>
>
> --- Comment #1 from kargl at gcc dot gnu dot org 2006-05-21 16:01
>
--- Comment #51 from mark at codesourcery dot com 2006-05-22 02:15 ---
Subject: Re: [4.0/4.1/4.2 regression] ICE in create_tmp_var
with C99 style struct initializer
pinskia at gcc dot gnu dot org wrote:
> --- Comment #50 from pinskia at gcc dot gnu dot org 2006-05-21 20:51
> ---
--- Comment #5 from vincent at vinc17 dot org 2006-05-22 01:08 ---
IMHO, -frounding-math should be the default, unless -ffast-math is given.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-05-21 23:53 ---
Confirmed, my first guess as to a fix would be to make build_component_ref
arrange for the type of the COMPONENT_REF to have the necessary qualifiers via
c_build_qualified_type.
--
jsm28 at gcc dot gnu dot org chan
--- Comment #10 from tbm at cyrius dot com 2006-05-21 23:52 ---
virtual Virtual::~Virtual() Virtual::~Virtual() virtual Virtual::~Virtual()
virtual Virtual::~Virtual() const void* get_vptr() Virtual::Virtual()
Virtual::Virtual() Virtual::Virtual() void
__static_initialization_and_destru
--- Comment #2 from carenas at sajinet dot com dot pe 2006-05-21 23:20
---
also affects latest gcc release (http://gcc.gnu.org/releases.html) 3.4.6 while
trying to do a plain --enable-languages="C"
--
carenas at sajinet dot com dot pe changed:
What|Removed
--- Comment #3 from neil at daikokuya dot co dot uk 2006-05-21 23:17
---
Subject: Re: [4.0/4.1/4.2 Regression] incorrect warning about constness of
pointer to an array in a const struct
pinskia at gcc dot gnu dot org wrote:-
>
>
> --- Comment #2 from pinskia at gcc dot gnu dot
--- Comment #9 from tbm at cyrius dot com 2006-05-21 23:14 ---
(In reply to comment #8)
> (In reply to comment #7)
> > This is interesting, I cannot reproduce this with a cross compiler to
> > alphaev68-unknown-linux-gnu from powerpc-darwin.
>
> Hrm :-(. Can anybody try a cross-compiler
--- Comment #2 from kazu at gcc dot gnu dot org 2006-05-21 22:21 ---
Reduced to:
void
foo (void const * P, unsigned int E, unsigned int H)
{
__builtin_ia32_monitor (P, E, H);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27696
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-21 22:07
---
Of course, I wanted to close it also. This is now done, please reopen if you
think I'm wrong.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-21 22:06
---
(In reply to comment #1)
> The code as given is not valid, but since we segfault at runtime even with
> -fbounds-check one can argue that this is a real deficiency.
With the inline dot_product on mainline, we now
--- Comment #19 from patchapp at dberlin dot org 2006-05-21 21:35 ---
Subject: Bug number PR27155
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/2006-05/msg01055.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #7 from patchapp at dberlin dot org 2006-05-21 21:35 ---
Subject: Bug number PR27613
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/2006-05/msg01044.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 21:26 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 21:24 ---
Janis, could you regression hunt on this bug?
Thanks,
Andrew Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 21:11 ---
Janis, could you do a regression hunt on this bug, using the testcase in
comment #1?
Thanks,
Andrew Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-21 20:53 ---
Any news on this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
--- Comment #50 from pinskia at gcc dot gnu dot org 2006-05-21 20:51
---
Any news on this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-05-21 20:49
---
Subject: Bug 26855
Author: pinskia
Date: Sun May 21 20:48:30 2006
New Revision: 113960
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113960
Log:
Add forgot changelog:
+2006-05-19 Daniel Berlin <[EMAIL P
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-21 20:49
---
Proposed patch (wording from the g95 error message). With that patch, compiling
the testcase is a bit noisy (additional errors after the first error message),
I'll try to find a cleaner solution.
Index: interfa
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-21 20:48 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2006-05/msg00519.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-21 20:37
---
Why is this code invalid? (the keywork ice-on-invalid-code is set)
No error is reported with Sun, Intel and g95.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |
--- Comment #15 from pcarlini at suse dot de 2006-05-21 20:36 ---
(In reply to comment #14)
> (In reply to comment #13)
> > No news about this one. Frankly, since x86-* would not benefit in any way, I
> > consider the work low priority.
>
> What about x86_64
Of course by x86-* I meant
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-05-21 20:33
---
(In reply to comment #13)
> No news about this one. Frankly, since x86-* would not benefit in any way, I
> consider the work low priority.
What about x86_64 or even PowerPC64 both of which are becoming more popula
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-21 20:32 ---
yes but you should report the bug to the distros that change the rules and let
them work out a solution instead of having the FSF GCC fix their bug.
Anyways Ada needs trampolines. Also it is harder to use mmap and
--- Comment #13 from pcarlini at suse dot de 2006-05-21 20:30 ---
No news about this one. Frankly, since x86-* would not benefit in any way, I
consider the work low priority.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
--- Comment #21 from pcarlini at suse dot de 2006-05-21 20:28 ---
Yes, the audit trail doesn't say that in private mail with Loren we agreed that
for now we only want to minimally take into account --enable-threads, that is
exploit the __GTHREADS macro, consistently with other parts of t
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 20:27 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 20:27 ---
I am no longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from subdino2004 at yahoo dot fr 2006-05-21 20:25 ---
(In reply to comment #1)
> This is not a bug in GCC but with your distro changing the rules that are
> always used.
Why should being unable to use local functions be an acceptable side-effect of
prohibiting executable
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-21 20:23 ---
Jeff any thoughts about this bug since it was caused by your patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26251
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 20:22 ---
Any thoughts on this one? It seems like someone connected with the OpenMP
project should document these.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26237
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-05-21 20:21
---
Any news on this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 20:19 ---
Any news on this one? Shouldn't we have better autoconf for libgomp to dect
the case where SYS_futex does not exist?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26175
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-05-21 20:14
---
Any news on this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-05-21 20:13
---
(In reply to comment #10)
> Evaluation of Steven's patch should occur after 4.1 is branched.
Any progress on this, it has been over 3 months since that was written.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #9 from aldot at gcc dot gnu dot org 2006-05-21 20:11 ---
>
> Your original patch is OK for 4.1 -- but I would like the fix I
> suggested for 4.2. Also, we don't like to fix a problem on a release
> branch without also having a fix in mainline.
>
> Therefore, would you pl
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
The code below causes gfortran to internal error when compiled as follows:
gfortran -c Elements.F90
gfortran -c Global_Numbering.F90
In file Global_Numbering.F90:9
end module global_numbering
1
Internal Error at (1):
find_array_spec(): Component not found
This is sim
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org
--- Comment #11 from patchapp at dberlin dot org 2006-05-21 18:03 ---
Subject: Bug number PR C++/27592
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/2006-05/msg01065.html
--
http://gcc.gnu.org/bugzi
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-21 18:02
---
I actually got time to test it last night.
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01065.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from mark at codesourcery dot com 2006-05-21 17:58 ---
Subject: Re: install failure due to unconditional invocation
of makeinfo for treelang.texi
aldot at gcc dot gnu dot org wrote:
> --- Comment #7 from aldot at gcc dot gnu dot org 2006-05-21 17:46 ---
>> Woul
--- Comment #7 from aldot at gcc dot gnu dot org 2006-05-21 17:46 ---
> Wouldn't it be better just to modify gcc/Makefile.in to do:
>
> ifneq($(BUILD_INFO),)
> info: $(INFOFILES) lang.info @GENINSRC@ srcinfo lang.srcinfo
> else
> info:
> fi
>
> Then, in the subdirectory Makefiles we ca
--- Comment #9 from hjl at lucon dot org 2006-05-21 17:42 ---
I have verified that the proposed patch fixes the C++ run-time problem on
Linux/x86, Linux/x86-64 and Linux/ia64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-05-21 17:27
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-05-21 17:24
---
Subject: Bug 27210
Author: mmitchel
Date: Sun May 21 17:23:59 2006
New Revision: 113958
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113958
Log:
PR c++/27210
* cp-tree.h (cp_save_expr): N
--- Comment #6 from mark at codesourcery dot com 2006-05-21 17:07 ---
Subject: Re: install failure due to unconditional invocation
of makeinfo for treelang.texi
aldot at gcc dot gnu dot org wrote:
> --- Comment #5 from aldot at gcc dot gnu dot org 2006-05-21 12:16 ---
> Setti
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-05-21 16:58 ---
Formerly passed (PASS in revision 113624, FAIL in revision 113643), so a
regression.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hjl at lucon dot org 2006-05-21 16:57 ---
The proposed patch works Linux/ia64:
http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01188.html
The visual inspection shows memcpy is used instead of ld8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
FAIL: gcc.dg/tree-ssa/ssa-fre-4.c scan-tree-dump Replaced \(int\) f_.*with D
appeared on mainline on ia64-hp-hpux11.23 when the test was added.
gcc-testresults shows it also failing on several other targets (e.g.
ia64-linux, PowerPC, ARM).
--
Summary: gcc.dg/tree-ssa/ssa-fre-4.c sca
FAIL: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not &x\[5\]
FAIL: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not offset: -4B
appeared on mainline on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11 when the
test was added.
--
Summary: g++.dg/tree-ssa/ivopts-1.C fails
Product:
--- Comment #1 from schwab at suse dot de 2006-05-21 16:40 ---
It is a testsuite bug. The problem is that on ia64 the call frame is allocated
on the register stack, not on the normal stack. Thus the recursive call to
recurser_void does not change the stack pointer.
--
schwab at sus
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 16:36 ---
Confirmed. Darwin has the same issue. It was xfailed there.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
FAIL: gcc.dg/pr27095.c scan-assembler-not (?n)strlen(.*\n)+.*strlen
appeared on HP-UX targets when the test was added. These targets explicitly
import external symbols used, so on such targets the test should test for
exactly two appearances of "strlen" instead of one.
--
Summary: g
--- Comment #8 from falk at debian dot org 2006-05-21 16:34 ---
(In reply to comment #7)
> This is interesting, I cannot reproduce this with a cross compiler to
> alphaev68-unknown-linux-gnu from powerpc-darwin.
Hrm :-(. Can anybody try a cross-compiler on i386 with valgrind?
--
ht
FAIL: gcc.dg/sibcall-7.c execution test
appeared on ia64-hp-hpux11.23 (both ilp32 and lp64) when the test was added on
both mainline and 4.1 branch; gcc-testresults shows it also on ia64-linux. I
don't know whether this is a target bug (i.e. the test should pass) or a
testsuite bug (i.e. it shoul
The following should not produce a runtime error.
OPEN(8, FORM = 'unformatted', STATUS = 'scratch')
OPEN(8, FORM = 'unformatted', STATUS = 'scratch')
end
There may be other combinations of arguments to open that should not error,
See the following thread:
http://gcc.gnu.or
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 16:22 ---
Oh, it works the other way in that the CC on the bug which is still opened are
transfered over to the bug which is closed now.
Anyways this should be reported upstream so closing as will not fix.
--
pinskia at g
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-21 16:18 ---
This is interesting, I cannot reproduce this with a cross compiler to
alphaev68-unknown-linux-gnu from powerpc-darwin.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-21 16:15 ---
This is also rejects valid with -pedantic-errors.
I don't understand what is correct here so I am not going to confirm it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from kargl at gcc dot gnu dot org 2006-05-21 16:14 ---
Bernhard,
Your patch only addresses one aspect of the problem.
Consider
function _foo
entry _bar
end function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
Known to work|3.4.3 |3.4.3 4.2.0
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-21 16:09
---
Only fixed on the trunk so reopening as this is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from kargl at gcc dot gnu dot org 2006-05-21 16:03 ---
The problem occurs on i386-*-freebsd
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 16:01 ---
There is a bug in the Redhat's kernel for FC5 that causes the trampoline to
fail, someone should report this to them.
This is not a bug in GCC but with your distro changing the rules that are
always used.
--
p
--- Comment #1 from kargl at gcc dot gnu dot org 2006-05-21 16:01 ---
Arjen,
There appears to be something strange with your report. The "Reported Against"
field in bugzilla shows 4.2.0. But, the verbose output shows that you are
linking against a 4.1.0-20050522 libgfortran. Can you
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-21
15:57 ---
Subject: Re: FAIL: gfortran.dg/secnds.f -O0 execution test
I now think that this comment was likely correct.
> This test can sometimes fail if you have a lot of background tasks running.
I found yester
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 15:53 ---
Actually this is done already when closing as a dup.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27699
--- Comment #9 from kazu at gcc dot gnu dot org 2006-05-21 15:17 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-21 15:17 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #8 from kazu at gcc dot gnu dot org 2006-05-21 15:16 ---
Subject: Bug 26622
Author: kazu
Date: Sun May 21 15:16:19 2006
New Revision: 113956
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113956
Log:
gcc/
PR tree-optimization/26622.
* fold-const.c (fo
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-21 15:13 ---
Subject: Bug 27671
Author: kazu
Date: Sun May 21 15:13:36 2006
New Revision: 113955
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113955
Log:
gcc/
PR rtl-optimization/27671
* simplify-rtx.c (si
Unfortunately I have not succeeded in reproducing this error in a small
program.
The error messages are:
/bin/sh ../../libtool --tag=F77 --mode=link gfortran -I../../include -g -O2
-o x01f.exe x01f.o ../../src/libplplotd.la
../../bindings/f77/libplplotf77cd.la ../../bindings/f77/libplplotf77d.l
As discussed in this thread:
http://gcc.gnu.org/ml/gcc-help/2005-12/msg00173.html>
Many GNU/Linux distributions (such as Debian, Ubuntu and RedHat) are planning
to prohibit executable stacks completely, regardless of the presence of the
executable stack flag. At the moment, GCC produces trampolin
The source code:
module aha
contains
subroutine aa
write(*,*) 'AA'
end subroutine aa
subroutine aa
write(*,*) 'BB'
end subroutine aa
end module
causes an internal error:
Driving: gfortran -v -save-temps double_routine.f90 -lgfortranbegin -lgfortran
Using built-in specs.
Target: i686-pc-cyg
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:11
---
Yes, this is confirmed. I'm not sure what is the less dirty way to make the
warnings disappear (and not fix the code, which is, as Andrew said, expected
not to work well on 64bits platforms).
--
fxcoudert at g
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:05
---
Confirmed. I think that having a io/io.h file instead of having all prototypes
in libgfortran.h is fundamentally a bad idea, especially since things are now
spread all around the libgfortran directory.
--
fxco
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:03
---
Confirmed. I don't understand why, though. I'll try it harder when I have some
leisure time.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-21 14:02
---
Unless we have some more information about this one, I'd like to close it
because it's most likely to be a timeout error than a real problem in the code.
Especially if it only fails at -O0, while being a library t
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-21 13:59 ---
Created an attachment (id=11491)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11491&action=view)
Patch for this PR and PR27155
This is a belt-and-braces fix that uses memcpy to effect the transfer. I will
look
--- Comment #1 from pault at gcc dot gnu dot org 2006-05-21 13:49 ---
Dale,
This looks like a library problem. Jerry committed a change that might have
required a completely clean tree to build.
I had no trouble with the trunk of two hours ago on FC5/Athlon.
Paul
--
http://gcc.g
--- Comment #15 from aldot at gcc dot gnu dot org 2006-05-21 13:10 ---
Subject: Bug 25776
Author: aldot
Date: Sun May 21 13:10:37 2006
New Revision: 113952
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113952
Log:
ACKed by Jan Hubicka in http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #5 from aldot at gcc dot gnu dot org 2006-05-21 12:16 ---
Setting Target Milestone to 4.1.1.
Ok for trunk and the 4.1 branch?
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywor
--- Comment #6 from pault at gcc dot gnu dot org 2006-05-21 11:53 ---
Subject: Bug 27613
Author: pault
Date: Sun May 21 11:53:02 2006
New Revision: 113951
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113951
Log:
2006-05-21 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from aldot at gcc dot gnu dot org 2006-05-21 11:50 ---
Created an attachment (id=11490)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11490&action=view)
print error invalid form for SUBROUTINE at
Not tested.
2006-05-21 Bernhard Fischer <[EMAIL PROTECTED]>
PR 27251 was closed as a duplicate of PR 18058. I was
on the CC: list of PR 27251 and had to add myself to
the CC: list of PR 18058 manually (as the bug activity
will show).
--
Summary: [bugzilla] CC should be transferred when closing a bug
as duplicate
--- Comment #17 from laurent at guerby dot net 2006-05-21 10:24 ---
This is fixed with:
gcc version 4.2.0 20060518 (experimental)
gcc version 4.1.1 20060517 (prerelease)
--
laurent at guerby dot net changed:
What|Removed |Added
---
subroutine _foo
end
draws the following error:
In file bhatt.f:1
subroutine _foo
1
Error: Unclassifiable statement at (1)
whereas the compiler would be far more helpful pointing out that _foo is
against the Standard (Rule R3
--- Comment #6 from kazu at gcc dot gnu dot org 2006-05-21 09:53 ---
Unassigning myself.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|ka
--- Comment #11 from kazu at gcc dot gnu dot org 2006-05-21 09:51 ---
Unassignining myself.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #7 from kazu at gcc dot gnu dot org 2006-05-21 09:39 ---
Posted a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #1 from fischer at td dot mw dot tum dot de 2006-05-21 09:31
---
In the function above:
bar.x[0][0] = 23; // gcc 4.1 gives error
*bar.x[0] = 23; // gcc 4.1 gives NO error
both lines do the same
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27697
In this snippet of code:
struct foo {
int x[2][10];
};
void f(void)
{
const struct foo bar;
const int (*baz)[10] = bar.x; /* should be ok */
int (*qoox)[10] = bar.x; /* should warn */
bar.x[0][1] = 23; /* error: asignment to const */
(*qoox)[1] = 23;
}
bar is const, so bar.x is (con
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-21 08:45 ---
Confirmed based on:
http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01139.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
/home/pinskia/src/gcc/checkin/gcc/objdir/gcc/testsuite/g++/../../include/pmmintrin.h:
In function 'void _mm_monitor(const void*, unsigned int, unsigned int)':^M
/home/pinskia/src/gcc/checkin/gcc/objdir/gcc/testsuite/g++/../../include/pmmintrin.h:116:
internal compiler error: in copy_to_mode_reg, at
1 - 100 of 110 matches
Mail list logo
