On Sun, May 20, 2007 at 10:39:43PM -0700, Brooks Moses wrote:
Bernardo Innocenti wrote:
(the next proposal is likely to cause some dissent)
What about moving 4.3 to stage 3 *now* and moving everything
else in 4.4 instead? Hopefully, it will be a matter of just
a few months. From
Hi
Zuxy Meng [EMAIL PROTECTED] дÈëÏûÏ¢ÐÂÎÅ:[EMAIL PROTECTED]
Hi,
2007/3/11, Danny Smith [EMAIL PROTECTED]:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Zuxy Meng
Sent: Wednesday, 7 March 2007 12:36 a.m.
I've uploaded a proposed patch
Hello!
Maybe such optimization isn't turned on for mingw. I updated the patch
to force this by using -minline-all-stringops.
http://gcc.gnu.org/bugzilla/attachment.cgi?id=13189
Any developer to have a look at this?
Please post the patch to [EMAIL PROTECTED] Also add appropriate
ChangeLog
Hi,
2007/5/21, Uros Bizjak [EMAIL PROTECTED]:
Hello!
Maybe such optimization isn't turned on for mingw. I updated the patch
to force this by using -minline-all-stringops.
http://gcc.gnu.org/bugzilla/attachment.cgi?id=13189
Any developer to have a look at this?
Please post the patch to
On Tue, May 15, 2007 at 04:27:21PM +0100, Mark Shinwell wrote:
Part of the reason for starting this thread was that I was concerned
about invalidating reloads that could be re-used later. However, it
seems to me that in every circumstance where the reload register is a
hard register and the
Hello all,
According to GNU gprof manual
http://www.gnu.org/software/binutils/manual/gprof-2.9.1/html_chapter/gprof_5.html#SEC18
basic-block counting can be analyzed with gprof if a program is
augmented for that.For this the program is to be compiled with `gcc
... -g -pg -a' option . But '-a'
Hi,
I'd like to get an explanation why ifcvt.c checks whether 1 of the 2
successors of the IF-header block has a stmt that exits from the loop?
Why does it prevent the if-conversion?
I'm referring to the following code:
/* Nor exit the loop. */
if ((then_edge-flags EDGE_LOOP_EXIT)
||
I think push_reload() is doing something weird with this insn:
Breakpoint 1, find_reloads (insn=0xb7f7e348, replace=0, ind_levels=0,
live_known=0, reload_reg_p=0x8878a7c) at ../../../cvssrc/gcc/gcc/reload.c:2535
2535{
(gdb) call debug_rtx(insn)
(insn 12 10 16 2 /tmp/ashiftsi3_1.c:3
Hello,
We have a large app with a lot of static libraries in it (and I mean a
lot, about 20) and it compiles and links successfully. If I compile it
without optimiztion turned on
(-O2 or some more subtle with -O and others), the program also runs.
With optimizations, though, the program
On Mon, May 21, 2007 at 07:06:47PM +0200, Thomas Mittelstaedt wrote:
Hello,
We have a large app with a lot of static libraries in it (and I mean a
lot, about 20) and it compiles and links successfully. If I compile it
without optimiztion turned on
(-O2 or some more subtle with -O and
On May 19, 2007, at 11:54 AM, Manuel López-Ibáñez wrote:
We tried to be polite
And we should go back to being polite... He's email a patch
recently. That's buys him more niceness in my book. I think he does
want to help, he just needs more guidance. Our goal is to turn him
into a
On May 19, 2007, at 3:57 AM, J.C. Pizarro wrote:
you have this nice cleanup's patch of gcc/loop.c that
transliterates the logic
of the uses of the loop_invariant_p (..) and
consec_sets_invariant_p (..)
functions.
Please resubmit against 4.3 (the top of the svn tree)... This is the
On 5/21/07, Mike Stump [EMAIL PROTECTED] wrote:
Please resubmit against 4.3 (the top of the svn tree)... This is the
canonical place where developers should be doing development. Thanks.
Except loop.c has been removed already which has mentioned like 5 time already.
Thanks,
Andrew Pinski
On Mon, May 21, 2007 at 11:00:17AM -0700, Mike Stump wrote:
On May 19, 2007, at 3:57 AM, J.C. Pizarro wrote:
you have this nice cleanup's patch of gcc/loop.c that
transliterates the logic
of the uses of the loop_invariant_p (..) and
consec_sets_invariant_p (..)
functions.
Please
Tehila Meyzels [EMAIL PROTECTED] writes:
I'd like to get an explanation why ifcvt.c checks whether 1 of the 2
successors of the IF-header block has a stmt that exits from the loop?
Why does it prevent the if-conversion?
I'm referring to the following code:
/* Nor exit the loop. */
if
Brooks Moses wrote:
What about moving 4.3 to stage 3 *now* and moving everything
else in 4.4 instead? Hopefully, it will be a matter of just
a few months. From http://gcc.gnu.org/gcc-4.3/changes.html,
it looks like it would already be quite a juicy release.
Why?
I mean, I suppose there
On 5/21/07, Bernardo Innocenti [EMAIL PROTECTED] wrote:
And also: why not?
I had hoped to get my pointer plus branch merged in which should
improve code gen and memory usage and compile time.
-- Pinski
On Mon, May 21, 2007 at 11:31:19AM -0700, Andrew Pinski wrote:
On 5/21/07, Bernardo Innocenti [EMAIL PROTECTED] wrote:
And also: why not?
I had hoped to get my pointer plus branch merged in which should
improve code gen and memory usage and compile time.
There seem to be quite a large
On May 21, 2007, at 11:23 AM, Bernardo Innocenti wrote:
The reason _we_ care to get 4.3 sooner rather than later
is that we'd like to have the AMD Geode tuning
Submit to gcc 4.2. Tuning seems to be the type of thing that should
be safe to backport, if you really must have it.
Anyway,
On 5/21/07, Tehila Meyzels [EMAIL PROTECTED] wrote:
Hi,
I'd like to get an explanation why ifcvt.c checks whether 1 of the 2
successors of the IF-header block has a stmt that exits from the loop?
Why does it prevent the if-conversion?
I'm referring to the following code:
/* Nor exit the loop.
On 5/21/07, Andrew Pinski [EMAIL PROTECTED] wrote:
On 5/21/07, Mike Stump [EMAIL PROTECTED] wrote:
Please resubmit against 4.3 (the top of the svn tree)... This is the
canonical place where developers should be doing development. Thanks.
Except loop.c has been removed already which has
Joe Buck wrote:
I had hoped to get my pointer plus branch merged in which should
improve code gen and memory usage and compile time.
There seem to be quite a large number of not-yet-merged projects
on the wiki page at
Never mind, I just did some investigation and it appears that
the
2007/5/21, Mike Stump [EMAIL PROTECTED] wrote:
On May 19, 2007, at 3:57 AM, J.C. Pizarro wrote:
you have this nice cleanup's patch of gcc/loop.c that
transliterates the logic
of the uses of the loop_invariant_p (..) and
consec_sets_invariant_p (..)
functions.
Please resubmit against 4.3
I need to edit a gcc source code, then recompile. My goal is to change what
gets output in the assembly file, when using the '-S' flag.
I figured a good first step would be, being able to print out Hello World!
somewhere in the '.s' file. I'm having trouble finding which source code
file I
On May 21, 2007, at 2:43 PM, AaronCloyd wrote:
I need to edit a gcc source code, then recompile.
Wrong list... gcc-help is closer that what you want...
2007/5/21, Mike Stump [EMAIL PROTECTED] wrote:
On May 21, 2007, at 2:04 PM, J.C. Pizarro wrote:
I hate the '-b-r-a-i-n [ ... ]
We don't use that sort of language around here...
Don't you understand the b-r-a-i-n-f-u-c-k-e-d source code?
http://en.wikipedia.org/wiki/Brainfuck
I'm saying is
Thomas Mittelstaedt wrote:
Hello,
We have a large app with a lot of static libraries in it (and I mean a
lot, about 20) and it compiles and links successfully. If I compile it
without optimiztion turned on
(-O2 or some more subtle with -O and others), the program also runs.
With
I've received some feedback suggesting that some contributors may not
always be aware of what open issues are available to work on, and,
perhaps more importantly, what regressions they may have caused.
Is there a volunteer who would like to help prepare a regular list of
P3-and-higher PRs,
On Mon, May 21, 2007 at 03:35:53PM -0700, Mark Mitchell wrote:
Is there a volunteer who would like to help prepare a regular list of
P3-and-higher PRs, together with -- where known -- the name of the
person responsible for the checkin which caused the regression? Or, is
this something that
Snapshot gcc-4.1-20070521 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070521/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Bernardo Innocenti wrote:
I extracted the relevant patches that would apply
to 4.2 as they were. Currently regtesting just in
case.
Err, allow me to rephrase that more clearly: I have
extracted the Geode patches from the trunk and they
applied without modification to the 4.2 branch.
I'm
is is very difficult work? i did't know whether i can competent for it.
i'.m a volunteer.
On 5/22/07, Mark Mitchell [EMAIL PROTECTED] wrote:
I've received some feedback suggesting that some contributors may not
always be aware of what open issues are available to work on, and,
perhaps more
I've been using Google Talk and thought you might like to try it out.
We can use it to call each other for free over the internet. Here's an
invitation to download Google Talk. Give it a try!
---
Wei Chen wants to stay in
On 5/21/07, Wei Chen [EMAIL PROTECTED] wrote:
I've been using Google Talk and thought you might like to try it out.
I would suggest that you use the public IRC channel on irc.oftc.net.
See the GCC wiki page for details (http://gcc.gnu.org/wiki/GCConIRC)
Mike Stump wrote:
On May 21, 2007, at 2:43 PM, AaronCloyd wrote:
I need to edit a gcc source code, then recompile.
Wrong list... gcc-help is closer that what you want...
Is it? Changing the internals of what GCC puts into .s files seems a
topic that's more appropriate here, I would
i think you can read GCC backend to understand GCC how to
write .s files.
On 5/22/07, Brooks Moses [EMAIL PROTECTED] wrote:
Mike Stump wrote:
On May 21, 2007, at 2:43 PM, AaronCloyd wrote:
I need to edit a gcc source code, then recompile.
Wrong list... gcc-help is closer that what you
i think http://gcc.gnu.org/svn.html have a error.
Using the SVN repository
Assuming you have version 1.0.0 and higher of Subversion installed,
you can check out the GCC sources using the following command:
svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
the right is
svn -q
On 5/21/07, Wei Chen [EMAIL PROTECTED] wrote:
svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
the right is
svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk
Not really, the syntax mentioned in the page is correct. The
additional argument 'gcc' merely means that on checkout,
Wei Chen wrote:
i think http://gcc.gnu.org/svn.html have a error.
Using the SVN repository
Assuming you have version 1.0.0 and higher of Subversion installed,
you can check out the GCC sources using the following command:
svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
I think you
On 5/22/07, David Daney [EMAIL PROTECTED] wrote:
Wei Chen wrote:
i think http://gcc.gnu.org/svn.html have a error.
Using the SVN repository
Assuming you have version 1.0.0 and higher of Subversion installed,
you can check out the GCC sources using the following command:
svn -q
Wei Chen wrote:
i think http://gcc.gnu.org/svn.html have a error.
Using the SVN repository
Assuming you have version 1.0.0 and higher of Subversion installed,
you can check out the GCC sources using the following command:
svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
the right is
--- Comment #9 from matz at gcc dot gnu dot org 2007-05-21 07:45 ---
Richard, the problem isn't the compare or where to store the live values
alen and blen (FYI, the store looks invalid, because reload will not
immediately stop when it sees an invalid asm insn, but instead just patch it
--- Comment #1 from bonzini at gnu dot org 2007-05-21 08:19 ---
I know what's going on :-)
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from bonzini at gnu dot org 2007-05-21 08:21 ---
Created an attachment (id=13593)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13593action=view)
tentative patch?
Please test this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #97 from jv244 at cam dot ac dot uk 2007-05-21 08:30 ---
This morning's mainline gives a new ICE on the CVS version of CP2K (the file in
question is not in the tarbal of comment #0)
gfortran -c -O3 -ftree-vectorize -ffast-math -march=native
semi_empirical_int_ana.f90
--- Comment #10 from ubizjak at gmail dot com 2007-05-21 08:33 ---
Extending reload to make use of memory for some reloads, where allowed,
might be nice, but is unrealistic in its gory detail (even the secondary mem
support doesn't really help here).
Should we XFAIL this test?
--
--- Comment #11 from bonzini at gnu dot org 2007-05-21 08:48 ---
Micha, do you mean transforming (while expanding to RTL)
asm (: =mr (inout_2) : 0 (inout_1));
to
inout_2 = inout_1;
asm (: =mr (inout_2) : 0 (inout_2));
?
That shouldn't be too hard.
--
--- Comment #12 from matz at gcc dot gnu dot org 2007-05-21 09:03 ---
Exactly. If during expansion or at some other time before reload, doesn't
matter that much. Of course there's a remote possibility that some RTL
passes between expand and reload would do the copy propagation to
--- Comment #1 from pcarlini at suse dot de 2007-05-21 09:22 ---
Ok, thanks, but this bug is already fixed.
*** This bug has been marked as a duplicate of 25288 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2007-05-21 09:22 ---
*** Bug 32017 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2007-05-21 09:26 ---
Also see libstdc++/32017 for some additional details.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
--- Comment #13 from bonzini at gnu dot org 2007-05-21 09:32 ---
So we'd just be replacing a weak workaround with a stronger (but not
definitive) workaround. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch 2007-05-21
09:41 ---
Subject: Re: [4.3 regression] : gcc.target/i386/pr21291.c
matz at gcc dot gnu dot org wrote:
--- Comment #14 from matz at gcc dot gnu dot org 2007-05-21 09:35 ---
Yes. The place where I
--- Comment #15 from manu at gcc dot gnu dot org 2007-05-21 09:54 ---
This bug will be fixed as soon as Tom's patch goes in.
*** This bug has been marked as a duplicate of 22168 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from manu at gcc dot gnu dot org 2007-05-21 09:54 ---
*** Bug 11051 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from matz at gcc dot gnu dot org 2007-05-21 09:35 ---
Yes. The place where I would think the work-around to become definitive is
exactly before regclass. Between it and reload nothing interesting happens
transformation wise.
--
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-21 10:13 ---
My patch for PR31867 fixes this in all its manifestations: see
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00961.html
The amusing thing is that I was hurting for testcases for this latter PR:)
It shows what a
--- Comment #1 from irar at il dot ibm dot com 2007-05-21 10:43 ---
On PowerPC revision 124785 from May 17 we get:
FAIL: gcc.dg/vect/vect-64.c (internal compiler error)
FAIL: gcc.dg/vect/vect-64.c (test for excess errors)
WARNING: gcc.dg/vect/vect-64.c compilation failed to produce
--- Comment #2 from dominiq at lps dot ens dot fr 2007-05-21 10:58 ---
vect-intfloat-conversion-4b.c is four days old, but the other tests seem pretty
old so the failures are regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
--- Comment #3 from paolo at gcc dot gnu dot org 2007-05-21 11:26 ---
Subject: Bug 31621
Author: paolo
Date: Mon May 21 10:25:52 2007
New Revision: 124896
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124896
Log:
2007-05-21 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from paolo at gcc dot gnu dot org 2007-05-21 11:27 ---
Subject: Bug 31621
Author: paolo
Date: Mon May 21 10:26:49 2007
New Revision: 124897
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124897
Log:
2007-05-21 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #5 from pcarlini at suse dot de 2007-05-21 11:27 ---
Fixed for 4.2.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from uros at gcc dot gnu dot org 2007-05-21 12:31 ---
Subject: Bug 31167
Author: uros
Date: Mon May 21 11:31:14 2007
New Revision: 124900
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124900
Log:
PR target/31167
Backport from mainline.
*
--- Comment #6 from uros at gcc dot gnu dot org 2007-05-21 12:31 ---
Subject: Bug 30041
Author: uros
Date: Mon May 21 11:31:14 2007
New Revision: 124900
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124900
Log:
PR target/31167
Backport from mainline.
*
Attached code from CP2K crashes f951 on i686-pc-linux-gnu if these flags
FCFLAGS=-c -O2 -ftree-vectorize -msse2
are specified. All of them are necessary, omitting any will avoid the segfault.
The crash seems to be related to the length of the subroutine. Further reducing
the number of
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-05-21 12:33 ---
Created an attachment (id=13594)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13594action=view)
Described test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32018
--- Comment #98 from dfranke at gcc dot gnu dot org 2007-05-21 12:38
---
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
equivalent and got the ICE described in PR32018.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #3 from dominiq at lps dot ens dot fr 2007-05-21 13:04 ---
Sorry about the bad news, but I still have the very same failure with the
patch:
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/sh
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-21 13:05 ---
Daniel cleared this one on trunk.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from andreast at gcc dot gnu dot org 2007-05-21 13:06
---
Nope. It clinches somehow with this one: config/mh-ppc-darwin. Here the
BOOT_CFLAGS is set to -g -O2 -mdynamic-no-pic.
In the libgcc Makefile.in I see that MULTILIB_CFLAGS is set to CFLAGS + extra
stuff. CFLAGS
--- Comment #3 from ubizjak at gmail dot com 2007-05-21 13:06 ---
(In reply to comment #1)
FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c scan-tree-dump-times
vectorized
1 loops 1
FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c scan-tree-dump-times
vectorized
1 loops 1
These
The following program should not compile (without warnings) on two counts, but
in fact only fails on one, and not for the right reason, as far as I can see.
class C
{
public:
C(const char *);
operator const char *();
};
void
foo (bool b)
{
// Prove that the implicit convertions work both
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-21 13:15 ---
Please look to PR tree-optimization/24695
Are you sure about the number? PR24695 is
[csl-arm-branch] Bootstrap failure with current csl-arm-branch
and has only three comments.
--
The following code demonstrates that GCC raises an invalid error on certain
template function syntax. It is the same error than on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19552 but on a NON-DEPENDENT name,
so the error is not appropriate here.
Please also note that this code compiles on MSVC++
--- Comment #5 from ubizjak at gmail dot com 2007-05-21 14:01 ---
(In reply to comment #4)
Please look to PR tree-optimization/24695
Are you sure about the number? PR24695 is
Oops, PR24659.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-21 14:16 ---
Subject: Bug 31867
Author: pault
Date: Mon May 21 13:16:06 2007
New Revision: 124903
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124903
Log:
2007-05-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from pault at gcc dot gnu dot org 2007-05-21 14:16 ---
Subject: Bug 31994
Author: pault
Date: Mon May 21 13:16:06 2007
New Revision: 124903
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124903
Log:
2007-05-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #12 from pault at gcc dot gnu dot org 2007-05-21 14:18 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2007-05-21 14:21 ---
Fixed on trunk. The patch will be backported to 4.2, as soon as the dust has
settled on trunk and 4.2 is open again.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from dave at boost-consulting dot com 2007-05-21 14:25
---
I won't push the subject any further, but again, if you don't adopt the tests
mentioned in the threads cited above, you will almost certainly have further
exception safety bugs lurking. Howard Hinnant can
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-21 14:27 ---
GCC 3.2 is no longer maintained. This works with the new C++ parser that went
in
for GCC 3.4.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following environment variables exist in gfortran (inherited from g95, cf.
http://ftp.g95.org/G95Manual.pdf). They are not documented and don't seem to
work, however they are partially implemented.
GFORTRAN_FPU_PRECISION can probably be removed (cf. -mpc32, -mpc64 and -mpc80)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-21 14:29 ---
For GFORTRAN_SIG* one could also add an option to backtrace/dump in this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32021
The following code demonstrates that GCC raises an invalid error on certain
template function syntax. It is the same error than on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19552 but on a NON-DEPENDENT name,
so the error is not appropriate here.
Please also note that this code compiles on MSVC++
--- Comment #7 from pcarlini at suse dot de 2007-05-21 15:00 ---
*** Bug 32017 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25288
--- Comment #3 from pcarlini at suse dot de 2007-05-21 15:00 ---
This specific bug is already fixed and must be marked as duplicate. Then we
have 21772, more general. We know what we are doing, thanks.
*** This bug has been marked as a duplicate of 25288 ***
--
pcarlini at suse dot
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-21 15:21
---
Created an attachment (id=13595)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13595action=view)
Patch for that issue; not tested yet
--
fxcoudert at gcc dot gnu dot org changed:
What
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-21 15:25
---
Scanning the F2003 standard, MIN/MAX are the only intrinsics with a variable
number of arguments. They probably need special handling.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
The following program doesn't compile due to invalid lvalue in increment. The
most strange thing is that gcc somehow ignores type coercion
int main ()
{
int **a;
void **b;
*b++;/* works fine */
*((void **)a)++; / gives error */
return 0;
}
--
Summary: Invalid lvalue in
--- Comment #16 from hjl at lucon dot org 2007-05-21 15:33 ---
Gcc 4.1/4.2/4.3 will fail and gcc 3.4 has no problem:
---
typedef unsigned long bngdigit;
typedef bngdigit *bng;
typedef unsigned int bngcarry;
typedef unsigned long bngsize;
bngdigit
bng_ia32_mult_sub_digit (bng a,
--- Comment #99 from jv244 at cam dot ac dot uk 2007-05-21 15:40 ---
(In reply to comment #98)
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
equivalent and got the ICE described in PR32018.
thanks for adding this PR.
Looking at PR32018, I notice that the
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-21 15:42 ---
*** This bug has been marked as a duplicate of 32020 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-21 15:42 ---
*** Bug 32022 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32020
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.0
Version|unknown |3.2.3
--- Comment #3 from tru at pasteur dot fr 2007-05-21 15:43 ---
[EMAIL PROTECTED] ~]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared
--- Comment #1 from schwab at suse dot de 2007-05-21 15:45 ---
A cast is not an lvalue.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-05-21 15:57 ---
Dave, just to clarify, this is bug 21772. We're working on it.
;)
-benjamin
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #100 from jv244 at cam dot ac dot uk 2007-05-21 15:58 ---
(In reply to comment #99)
(In reply to comment #98)
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
equivalent and got the ICE described in PR32018.
thanks for adding this PR.
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-05-21 15:58 ---
This is now integrated, but the tests are still ad-hoc. We need a more
consistent application of eh-safety tests.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
1 - 100 of 169 matches
Mail list logo
