So I'm basically asking for people who want to play around with some
cool new technology to help make source code better. If this interests
you, please feel free to reach out to me directly. And of course, if
there are other packages you care about that aren't currently on the
list, I want
I reproduced this with just gcc-core, I normally also build g++ and
gfortran as well. The problem goes away if I unpack the sources for
objc, which I am not really interested in.
Any takers? How/against what do I report this?
The problem is that now configure is processing config-lang.in
Hello,
I cannot compile a code that seems correct to me. I have tried with
gcc 3.3 and gcc 4.0.1 on MacOS X-ppc, and gcc 4.0.1 on Linux i686.
Here is the code, that uses pure virtual functions and simple
inheritance.
//-
struct a
{
virtual int foo()
On Mar 6, 2006, at 8:12 AM, Pierre Chatelier wrote:
Hello,
I cannot compile a code that seems correct to me. I have tried with
gcc 3.3 and gcc 4.0.1 on MacOS X-ppc, and gcc 4.0.1 on Linux i686.
Here is the code, that uses pure virtual functions and simple
inheritance.
Thanks for the quick answer.
This is ok to fix the source, but I do not understand why it is
normal behaviour that the foo() in b hides the one from a. They have
different prototypes.
Regards,
Pierre Chatelier
This is not a bug in gcc. foo in b hides the one from a.
You can fix the
There is a wikibook that describes the internals of GCC and GEM, an
extensibility framework.
Your internals documentation looks pretty good, so I have made a link
to it from gcc.gnu.org/readings.html. Thanks,
It describes AST part of GCC source code. We would like to ask developers to
work
On Mon, 6 Mar 2006, Paolo Bonzini wrote:
It is a bit weird that objcp is included in the gcc-core download. It could
be included in the gcc-objc download (or in a separate objcp download). But
It should go in an objcp download. sourcebuild.texi includes updating the
release script as one
Mark Mitchell [EMAIL PROTECTED] wrote:
GCC 4.0.3 RC1 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.3-20060303
Please download and test!
There are failures on sh4-*-linux-gnu during libjava build and 65
unusual regressions for C++ testsuite. I don't file PRs for them
because
Paolo Bonzini's patch appears to work.
What the best solution is long term, is not really my province.
Regards
Salvatore
Hello,
Le lundi 06 mars 2006 à 13:39 +, Colm O' Flaherty a écrit :
Francois,
I'm really interested in getting a gcc port (gcc backend) for the Microchip
PIC16F family (14 bit instruction, 8 bit word) up and running. I've seen
various mails to the gcc list that refer to this, the most
Hi,
I was trying to feed the reload phase with a different hardware
register assignment to pseudo registers (using reg_renumber array)
than the ones produced by local-alloc or global-alloc. However, I get
problems with the following instruction in post-reload.c:391 in
reload_cse_simplify_operands
The architecture for which I generate code is Intel x86.
On 3/6/06, Rajkishore Barik [EMAIL PROTECTED] wrote:
Hi,
I was trying to feed the reload phase with a different hardware
register assignment to pseudo registers (using reg_renumber array)
than the ones produced by local-alloc or
I noticed that some testsuite regressions were not getting fixed.
There are 3 failures in the gcc.dg/tree-ssa (PR 26344).
And 5 in g++.dg (PR 26115 and PR 26114).
All of these testsuite regressions have been there for almost
three weeks (the C++ have been there over a month now). The
patch which
On Mon, 2006-03-06 at 12:34 -0500, Andrew Pinski wrote:
I noticed that some testsuite regressions were not getting fixed.
There are 3 failures in the gcc.dg/tree-ssa (PR 26344).
And 5 in g++.dg (PR 26115 and PR 26114).
All of these testsuite regressions have been there for almost
three weeks
You're really not helping here. I'm dealing with things as
quickly as I can and prioritizing the incorrect code issues
over minor performance issues.
If you noticed I pointed out other testsuite regressions than
just yours. If I had posted the patch (not being a global write
maintainer) and
On Sunday 05 March 2006 17:47, Mark Mitchell wrote:
GCC 4.0.3 RC1 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.3-20060303
OK on SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00347.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00346.html
On Mon, 2006-03-06 at 00:31 +0100, Eric Botcazou wrote:
cxa4025 and cxa4033 are very likely yours, originating in a miscompilation of
the runtime (a-stwifi.adb) at -O2. They succeed if the aforementioned unit
is compiled at -O2 -fno-tree-vrp. You can pass -a to gnatmake to cause the
On Mon, 2006-03-06 at 00:31 +0100, Eric Botcazou wrote:
cxa4025 and cxa4033 are very likely yours, originating in a miscompilation of
the runtime (a-stwifi.adb) at -O2. They succeed if the aforementioned unit
is compiled at -O2 -fno-tree-vrp. You can
Like you, I'm still studying the internals of gcc, but I'm close to
being confident enough to start making some changes.
Nice !
Le lundi 06 mars 2006 à 17:17 +, Colm O' Flaherty a écrit :
Francois,
There are only 35 instructions in the 14 bit instruction set, and given
that, in gcc,
On Mar 6, 2006, at 1:39 PM, Jeffrey A Law wrote:
I think it's time to hand this one to the Ada guys :-0
I bet this is actually a fold issue rather than an Ada front-end issue.
-- Pinski
On Mon, Mar 06, 2006 at 12:34:42PM -0500, Andrew Pinski wrote:
What is the policy for testsuite regressions that have been
there for over 48 hours and effect all targets and have not
been fixed yet?
In this case, wouldn't removing the patch just move breakage from C++
to Ada? Or do I
On Mar 6, 2006, at 2:21 PM, Joe Buck wrote:
On Mon, Mar 06, 2006 at 12:34:42PM -0500, Andrew Pinski wrote:
What is the policy for testsuite regressions that have been
there for over 48 hours and effect all targets and have not
been fixed yet?
In this case, wouldn't removing the patch just
Kaz Kojima wrote:
It seems that the recent changes on 4.0 branch reveal these target
problems which are latent on 4.0. There are patches for these PRs,
though the patch for 23706 touches the middle end file. I'm unsure
whether to backport it to 4.0.3 is appropriate or not at this last
I have run into a couple of linking problems trying to test/use -fopenmp
and libgomp and I was hoping for some help on where to look and how to
fix these problems.
Test failures:
I get a lot of test failures with:
| FAIL: libgomp.c/appendix-a/a.15.1.c (test for excess errors)
| Excess errors:
Looks OK for xtensa-elf:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00356.html
--Bob
That's just how C++ is designed/defined, any book on C++ should be
able to explain this in more detail.
Since it was not a bug, I have posted related questions on the gcc-
help list, and I have had valuable answers.
http://gcc.gnu.org/ml/gcc-help/2006-03/msg00026.html
Now I have understood
The pre-Berlin WG14 mailing, and the updated C99 DR logs, are now
available from the WG14 website. There's an updated decimal float draft
TR in there, among other items.
http://www.open-std.org/JTC1/SC22/WG14/www/docs/pre-berlin.htm
Here's the relevant bits from the .original dump
if (side - 1 = 1)
Of particular interest is the (side - 1 = 1) conditional which is
implementing this hunk of code from the Trim function:
if Side = Right or else Side = Both then
I think it's time to hand this one to the
When trying to submit further information for gcc bug 15020 I get
Not allowed
You tried to change the Assignee field from [EMAIL PROTECTED] to
__UNKNOWN__, but only the assignee of the bug, or a sufficiently empowered
user may change that field.
I can not figure which field of the form is
--- Comment #11 from diskman at kc dot rr dot com 2006-03-06 08:03 ---
The AlphaPC 164SX is basically the same as the AlphaPC 164LX just minus the 96k
L1 cache but with additional MVI instructions.
[EMAIL PROTECTED] gcc-4.1.0]# gdb -args
As reported here:
http://gcc.gnu.org/ml/gcc-bugs/2006-03/msg00589.html
Confirmed. Fails since GCC 4.0.0.
However, this has nothing to do with templates or inline asm as the
reduced testcase shows:
==
struct A
{
A(const A);
A operator=(const A);
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
--- Comment #3 from shanwill44 at yahoo dot com 2006-03-06 08:36 ---
(In reply to comment #1)
Thank you for your support. After setting CONFIG_SHELL to
/bin/ksh, the compilation was successful. I am sorry that
I did not noticed the existence of the Solaris specific
documentation,
the make bootstrap finish with a Error but no precise thing to do
or to operate on it's look
make[2]: *** No rule to make target `all'. Stop.
make[1]: *** [all-subdir] Error 2
make: *** [all-libiberty] Error 2
don't know what to do ...
I tryed make install BUT
it failed on :
gcc:
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-03-06 09:14
---
In Roger's court now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-06 10:26 ---
First, 2.95.2 is waay outdated, second, you don't provide any information
on how you configured gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26578
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-06 10:39 ---
gcc_assert (!TYPE_HAS_COMPLEX_INIT_REF (type)
|| !TYPE_HAS_COMPLEX_ASSIGN_REF (type)
/* But storing a CONSTRUCTOR isn't a copy. */
|| TREE_CODE (exp) ==
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-06 10:58 ---
We indeed lose alignment information of outdata-tv. We start expanding
memcpy (outdataD.1529-tvD.1528, tpD.1530, 4) [tail call]
with
(gdb) print dest_align
$1 = 32
so, builtins.c:get_pointer_alignment returns
--- Comment #2 from mpoirier at laas dot fr 2006-03-06 11:09 ---
Of course I know that gcc 2.95 is out but I need it for some prog that
only compil on gcc 2.95
I used the folloowing command to configure :
../gcc2/configure --program-suffix=-2.95 --enable-shared --enable-threads
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-06 11:58 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from martin at mpa-garching dot mpg dot de 2006-03-06 12:10
---
Mainline works correctly again, thanks!
Do you plan to commit to the 4.1-branch too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26554
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-06 12:17 ---
Works with 3.3.3, 3.4.2, fails with 4.1.0 and 4.2.0 (didn't check 4.0.x, but I
guess it's another tree-ssa fallout)
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-06 12:23 ---
It also affects ia64 and s390(x)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-06 12:31 ---
2.9.5.2 did not have support for Darwin as either the host or the target.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-06 12:42 ---
Reduced testcase which shows the real issue:
struct A
{
A(const A);
A operator=(const A);
static void bar();
void baz() volatile;
};
void A::baz() volatile
{
bar();
}
--
pinskia at gcc dot
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-06 12:45 ---
Related to PR 23167.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mpoirier at laas dot fr 2006-03-06 12:45 ---
and 2.95.3 ??
which one was on panther or Xcode 1 and 1.5
else thanx for the info
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26578
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-06 12:47 ---
(In reply to comment #3)
Related to PR 23167.
One more comment about this, the fix for that PR moved the ICE from
create_tmp_var to cp_expr_size.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-06 12:48 ---
(In reply to comment #4)
and 2.95.3 ??
All FSF 2.95.x did not have support for Darwin. The 2.95.3 you were referring
to came modified to you from Apple.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26578
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-06 12:49 ---
A workaround is to do
memcpy ((char*)outdata + 1, ...);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-03-06 12:52
---
Works on mainline (will become 4.2). Will (probably) not be backported to 4.1.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-06 13:02 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-06 13:05 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-06 13:06 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pcarlini at suse dot de 2006-03-06 13:17 ---
Working on it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
-languages=c++,fortran
--enable-checking=release
Thread model: posix
gcc version 4.2.0 20060306 (experimental)
/home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951
conf.f -ffixed-form -quiet -dumpbase conf.f -mtune=generic -auxbase conf
-version -I
/home/martin/software/ugcc/lib/gcc
If this is (as I am fairly sure) a bug, then it will
surely be a bug in the C front end, and as such be
architecture-independent.
The behaviour here complained of is peculiar to -pedantic,
which chucks an error for what I believe is correct code.
It's not even a warning otherwise, and I think
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-06 13:53 ---
Comeau C front-end also rejects this code:
Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C99
ComeauTest.c,
--- Comment #12 from dir at lanl dot gov 2006-03-06 14:06 ---
It works great on the Macintosh. Now, if someone could just get the windows
version of gfortran under MinGW to pass these I/O tests, it might become
usuable. My programs compile under MinGW, but they all crash when I try to
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-06 14:06 ---
Not a bug:
From C99, 6.9.2/3 says:
If the declaration of an identifier for an object is a tentative definition and
has internal
linkage, the declared type shall not be an incomplete type.
--
This is a
--- Comment #3 from joseph at codesourcery dot com 2006-03-06 14:10 ---
Subject: Re: New: incomplete (unsized) static array types
cannot be completed
On Mon, 6 Mar 2006, bernard at brenda-arkle dot demon dot co dot uk wrote:
static int thingy2[];
static int thingy2[1];
This
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-06 14:20 ---
Confirmed. Also happens on x86 too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-03-06 14:22
---
On Comment #8: Yes I will be committing the logical patch to 4.1 branch soon.
On Comment #9: This is not really a bug depending on how one interprets the
f95 standard. The three error families, EOR, END, and
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-06 14:26 ---
Just for future reference, here is the C testcase that Eric B. posted to the
list:
/* PR middle-end/26561 */
extern void abort(void);
int always_one_1 (int a)
{
if (a/100 = -9)
return 1;
else
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-03-06 14:30
---
Or with a pass recovering loops before vectorization.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
I get the following warnings when doing a cross (any kind of cross really)
Makefile:13366: warning: overriding commands for target `restrap'
Makefile:12658: warning: ignoring old commands for target `restrap'
--
Summary: [4.2 Regression] warning with cross build
Product:
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-03-06 14:33
---
When trying to compile the Starlink sources with gfortran I stumbled across
this too. Unfortunately it seems that one of their autoconf tests called
AC_FC_RECL_UNIT relies on the jump to the ERR label when
--- Comment #1 from paolo dot bonzini at lu dot unisi dot ch 2006-03-06
14:35 ---
Subject: Re: New: [4.2 Regression] warning with cross
build
pinskia at gcc dot gnu dot org wrote:
I get the following warnings when doing a cross (any kind of cross really)
Makefile:13366: warning:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-06 14:37 ---
Subject: Re: [4.2 Regression] warning with cross build
--- Comment #1 from paolo dot bonzini at lu dot unisi dot ch 2006-03-06
14:35 ---
Subject: Re: New: [4.2 Regression] warning with cross
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-03-06 14:39
---
The problem for the original testcase is that we don't even try to build SFTs
required for structure aliasing analysis for incoming pointers:
foo0 (f)
{
int D.1529;
bb 2:
# SMT.4_4 = V_MAY_DEF SMT.4_3;
--- Comment #11 from martin at mpa-garching dot mpg dot de 2006-03-06
14:41 ---
On Comment #9: This is not really a bug depending on how one interprets the
f95 standard. The three error families, EOR, END, and ERR are each treated
separately. EOR and END are not considered the
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-03-06 14:41
---
In principle this blocks optimization of tramp3d domain operations (if it were
not structure-aliasing fixing most of the problems).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from patchapp at dberlin dot org 2006-03-06 14:55 ---
Subject: Bug number PR middle-end/26565
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-03/msg00324.html
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-06 15:00 ---
(In reply to comment #1)
(gdb) p debug_rtx (insn)
(insn 41 39 42 5 (set (reg:DI 71 [ D.775 ])
(zero_extend:DI (subreg:QI (reg/v:DI 70 [ i ]) 7))) 129 {*pa.md:4636}
(nil)
(nil))
$9 = void
This is a
--- Comment #28 from patchapp at dberlin dot org 2006-03-06 15:07 ---
Subject: Bug number PR bootstrap/18058
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-03/msg00297.html
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26582
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-03-06 15:24
---
I might look into fix this later this week, the problem is the creating of
loads which could cause an trap/exception but not putting them into different
BB's.
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-06 15:29 ---
Any news on these three testsuite failures? It is getting annoying to have
testsuite regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
--- Comment #3 from patchapp at dberlin dot org 2006-03-06 15:30 ---
Subject: Bug number PR bootstrap/26500
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-03/msg00124.html
--
--- Comment #9 from law at redhat dot com 2006-03-06 15:35 ---
Subject: Re: [4.2 Regression] three testsuite
failures in gcc.dg/tree-ssa/
On Mon, 2006-03-06 at 15:29 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #8 from pinskia at gcc dot gnu dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-06 15:49 ---
Janis could you do a regression hunt on what caused this testcase to start to
fail?
The C testcase is:
int f(void)
{
int i;
for(i=0;i256;i++)
{
char a = i;
int ii = a;
if (ii != i)
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-03-06 16:10 ---
Paolo, versioning bits look fine.
lm
cw
ij
are the usual rules you need to keep in mind for this stuff
but fixing this is not a big deal.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26526
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-06 17:08 ---
You can read about the java programming language's requirements
for floating point here:
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3
Relevant quote:
In particular, the Java
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-06 17:10
---
(In reply to comment #9)
As I've mentioned at least 3 times now, the Ada mis-compilations
have priority. I'm working on these between fixing Ada issues.
When there's status worth mentioning, I'll certainly add
--- Comment #11 from law at redhat dot com 2006-03-06 17:21 ---
Subject: Re: [4.2 Regression] three testsuite
failures in gcc.dg/tree-ssa/
On Mon, 2006-03-06 at 17:10 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #10 from pinskia at gcc dot gnu dot org
--- Comment #8 from patchapp at dberlin dot org 2006-03-06 17:45 ---
Subject: Bug number PR c++/6634
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-03/msg00334.html
--
--- Comment #9 from paolo at gcc dot gnu dot org 2006-03-06 18:06 ---
Subject: Bug 26532
Author: paolo
Date: Mon Mar 6 18:06:47 2006
New Revision: 111789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111789
Log:
2006-03-06 Paolo Carlini [EMAIL PROTECTED]
PR
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26532
--- Comment #4 from bernard at brenda-arkle dot demon dot co dot uk
2006-03-06 18:35 ---
Thanks - I'd forgotten that 'static' declarations can be
tentative definitions too. But now I'm even more confused!
As I wrote, unsized arrays do one thing, undefined structs do another
(this is
--- Comment #5 from joseph at codesourcery dot com 2006-03-06 18:58 ---
Subject: Re: incomplete (unsized) static array types cannot be
completed
On Mon, 6 Mar 2006, bernard at brenda-arkle dot demon dot co dot uk wrote:
struct poo; /* declares an incomplete structure type, 6.7.2.3
--- Comment #6 from pault at gcc dot gnu dot org 2006-03-06 20:33 ---
This one was fixed a long time since but does not seem to have been cleared.
The recent flurry of activity on the dependency checking has made keeping it
open unnecessary IMHO.
Paul
--
pault at gcc dot gnu dot
--- Comment #7 from jakub at gcc dot gnu dot org 2006-03-06 20:44 ---
Are you sure? forall_8.f90 testcase still fails for me with gfortran
as of a few days ago.
If the problem is fixed and the testcases aren't invalid, they should be
added to the testsuite, otherwise this needs to be
--- Comment #1 from pault at gcc dot gnu dot org 2006-03-06 20:58 ---
(In reply to comment #0)
There are currently two equivalenced variable problems but I suspect there are
more which is why I am
creating this meta-bug.
I believe that 24406 has fixed itself and that both can be
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-06 21:03
---
(In reply to comment #11)
Even though the final tree dump looks correct this is a still a front-end
issue
as the front-end communicates the aliasing sets to the rtl optimizers.
I am going to take it too.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-06 21:05 ---
(In reply to comment #1)
I believe that 24406 has fixed itself and that both can be closed.
See my reply in PR 24406 to the message that it is fixed, it is just harder to
expose.
--
--- Comment #15 from kkojima at gcc dot gnu dot org 2006-03-06 22:40
---
Subject: Bug 23706
Author: kkojima
Date: Mon Mar 6 22:40:49 2006
New Revision: 111792
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111792
Log:
PR target/23706
Backport from 4.1:
*
--- Comment #9 from kkojima at gcc dot gnu dot org 2006-03-06 22:40 ---
Subject: Bug 22553
Author: kkojima
Date: Mon Mar 6 22:40:49 2006
New Revision: 111792
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111792
Log:
PR target/23706
Backport from 4.1:
*
The following Fortran 77 program declares and uses a statement function
I2C(M). When compiled with these options:
g77 -pedantic -v -save-temps
it is misread as a character substring with its : missing, but IMHO
this statement function is valid in Fortran 77. The program compiles
and runs OK
1 - 100 of 136 matches
Mail list logo
