the fix for PR middle-end/28915 causes a bootstrap failure with 4.1 20061113 on
i486 (using the Debian build); didn't yet check with a vanilla 4.1 branch or
the fedora 4.1 branch.
Matthias
./xgcc -B./ -B/usr/i486-linux-gnu/bin/ -isystem /usr/i486-linux-gnu/include
-isystem
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-11-14
08:18 ---
reverting the fix for PR28915 fixes the bootstrap error
2006-11-12 Jason Merrill [EMAIL PROTECTED]
Andrew Pinski [EMAIL PROTECTED]
PR middle-end/28915
* gimplify.c (gimplify_init_constructor): Don't
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-14 08:21 ---
(In reply to comment #1)
reverting the fix for PR28915 fixes the bootstrap error
This patch should not have any affect on bootstrap as there are no vectors
usage inside GCC.
--
--- Comment #2 from bonzini at gnu dot org 2006-11-14 08:26 ---
it is supported, it is just buggy. Jean-Pierre, it seems like you have
something like a patch. Can you expand your idea more?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29802
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-14 08:26 ---
building a plain 4.1 branch to prove it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-11-14 16:44
---
Created an attachment (id=12618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12618action=view)
Patch mentionned in previous comment
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-11-14 09:03
---
Yep, and the aforementioned patch is indeed the culprit.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from vahtras at kth dot se 2006-11-14 09:42 ---
Subject: Re: integer assignment in hexadecimal fails
On 14 nov 2006, at 02.23, jvdelisle at gcc dot gnu dot org wrote:
Try -fno-range-check or use standard conforming methods.
Thank you, this was a learning experience
--- Comment #13 from bonzini at gnu dot org 2006-11-14 08:46 ---
Subject: Bug 29798
Author: bonzini
Date: Tue Nov 14 08:46:26 2006
New Revision: 118808
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118808
Log:
2006-11-14 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #14 from bonzini at gnu dot org 2006-11-14 08:50 ---
still have to commit the patch on dataflow branch, but mainline is ok now
--
bonzini at gnu dot org changed:
What|Removed |Added
the exact version of GCC is 4.1.1
the system type is i686-pc-cygwin
the options given when GCC was configured/built:
--prefix=/tmp/local/unixutil/gcc-4.1.1
--with-local-prefix=/usr/local/myCompanyName
(myCompanyName is not the exact wording)
(also, there is a symlink
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-14 09:46 ---
So the problem is that loop.c creates a tree for:
(plus:SI (reg:SI 3 bx)
(const:SI (unspec:SI [
(symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0xb7ce10b0 dwarf_reg_size_table)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-14 09:06 ---
Looking into it, a bit more. But as far as I can tell this is a latent bug in
the x86 back-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from bonzini at gnu dot org 2006-11-14 09:06 ---
Subject: Bug 29798
Author: bonzini
Date: Tue Nov 14 09:06:42 2006
New Revision: 118809
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118809
Log:
2006-11-14 Paolo Bonzini [EMAIL PROTECTED]
Merge from
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-14 09:57 ---
(In reply to comment #8)
Hmm, isn't movl %eax, [EMAIL PROTECTED] a valid way to have an
offset?
gas accepts that as valid so I think GCC should accept this. I am now going to
bed but I am also going to say this
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-14 09:50 ---
I'm confused that for
type geodetic
real :: h
end type geodetic
gfortran is using a record type but still goes the scalar assignment path.
With
gfc_trans_scalar_assign changed to read
gcc_assert
On Tue, 2006-11-14 at 09:29 +, jakub at gcc dot gnu dot org wrote:
--- Comment #24 from jakub at gcc dot gnu dot org 2006-11-14 09:29
---
This change breaks bootstrap on x86_64-linux and i386-linux:
This is now PR 29825 and it is an x86 back-end issue about not accepting
the
--- Comment #3 from poellmann at nm dot hsd dot utc dot com 2006-11-14
10:10 ---
The problem maintains with gcc 4.1.1. The error-message is slightly different:
test.c: In function 'compare':
test.c:5: error: unrecognizable insn:
(insn 12 11 13 1 (set (reg:CCFP 123)
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-14 09:40 ---
This is a bug in loop.c ... which is why it works in 4.2.0 and above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
--- Comment #24 from jakub at gcc dot gnu dot org 2006-11-14 09:29 ---
This change breaks bootstrap on x86_64-linux and i386-linux:
/usr/src/gcc-4.1/obj/./gcc/xgcc -B/usr/src/gcc-4.1/obj/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/
--- Comment #12 from jakub at gcc dot gnu dot org 2006-11-14 11:43 ---
While that can help in this case, I think letting make_tree/expand_expr combo
create invalid RTL is very dangerous (and, at least from i386 backend POV,
some of the PIC UNSPECs not surrounded by CONST are invalid,
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-11-14 10:39
---
I'll take that one.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Assigning a function pointer with a char parameter to a pointer with an
undefined list causes gcc to emit a warning.
[EMAIL PROTECTED]:~/ntnative/loader$ cat x.c
void foo(char);
void (*f1)() = foo;
void bar(int);
void (*f2)() = bar;
[EMAIL PROTECTED]:~/ntnative/loader$ gcc -c x.c
x.c:2: warning:
--- Comment #8 from pault at gcc dot gnu dot org 2006-11-14 10:19 ---
FX,
In spite of this morning's posting to the list, I will not be submitting a
patch for %LOC but rather for %REF. I got stuck in vms space. Is there any
functional difference between %LOC and %REF, do you know?
See:
13.7.76 MIN (A1, A2 [, A3, ...])
For arguments of character type, the result is the value that would be selected
by application of intrinsic relational operators; that is, the collating
sequence for characters with the kind type parameter of the arguments is
applied. If the selected argument
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-11-14 10:37
---
%VAL, %REF and %DESCR have similar use and functionality, but %LOC is very
different. It should in fact be an alias for function LOC, but it simply adding
it in intrinsic.c with make_alias is not sufficient:
--- Comment #3 from patchapp at dberlin dot org 2006-11-14 10:00 ---
Subject: Bug number PR29642
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-11/msg00923.html
--
--- Comment #25 from pinskia at gmail dot com 2006-11-14 10:02 ---
Subject: Re: [4.1 regression] ICE: tree check:
expected class 'constant', have 'declaration' (var_decl) in
build_vector,
at tree.c:973
On Tue, 2006-11-14 at 09:29 +, jakub at gcc dot gnu dot org
--- Comment #10 from jakub at gcc dot gnu dot org 2006-11-14 10:45 ---
The problem is in the make_tree change of PR28915.
make_tree is called with (const (unspec (something) ) ), before make_tree
would just create a dummy VAR_DECL with DECL_RTL set to this, but now
calls make_tree
--- Comment #11 from pault at gcc dot gnu dot org 2006-11-14 10:16 ---
A long overdue patch for this will be submitted in the next 24hours.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
while working in a project in C++. I tried to use a forward declaration of a
class. Class is unders some name space. There I got the error message like
below.
arm-linux-g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for
--- Comment #3 from jpvial at nerim dot net 2006-11-14 11:10 ---
Subject: Re: wrong directory in makefile for ada and libada
when building the src directory
bonzini at gnu dot org wrote:
--- Comment #2 from bonzini at gnu dot org 2006-11-14 08:26 ---
it is supported, it is
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-11-14 11:11
---
The reduced testcase only fails on i?86, bootstrap also fails on x86_64 with
the same error.
At least (symbol_ref:SI (dwarf_reg_size_table) [flags 0x2] var_decl
0x2af3f74a6580 dwarf_reg_size_table) is not a valid
--- Comment #1 from jakub at gcc dot gnu dot org 2006-11-14 14:27 ---
lambda_loopnest_to_gcc_loopnest interchanges the loops and we get:
L12:;
lletmp.77_46 = 0;
lletmp.77_38 = lletmp.77_46 + 5;
lnivtmp.75_21 = lnivtmp.75_9 + 1;
lnivtmp.75_12 = lnivtmp.75_9 + 1;
if
--- Comment #7 from burnus at gcc dot gnu dot org 2006-11-14 15:49 ---
Fixed in trunk.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2006-11-14 12:23 ---
Created an attachment (id=12616)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12616action=view)
patch to fix the bug
Please try this.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #1 from Denis dot Excoffier at airbus dot com 2006-11-14 11:39
---
To be connected to Bug 29825.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-11-14 11:48
---
While that can help in this case, I think letting make_tree/expand_expr combo
create invalid RTL is very dangerous (and, at least from i386 backend POV,
some of the PIC UNSPECs not surrounded by CONST are
--- Comment #1 from pluto at agmk dot net 2006-11-14 12:53 ---
this is a dup of PR29767
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29830
Hi,
I haven't found any related bug in the known bugs database.
Also I posted this problem to several forums to be shore that this code doesn't
violate the C++ standard. ~60% replies that this should work. Moreover two
other compilers can compile without any problem:
The simplified code:
--- Comment #1 from pault at gcc dot gnu dot org 2006-11-14 14:17 ---
Confirmed.
Tobias,
What criterion are you chosing for the missing F2003 features? The reason that
I ask is that it is not clear to me when you stop; eg. should we have a PR for
polymorphism or for sub-modules?
--- Comment #2 from zjasz at yahoo dot com 2006-11-14 15:02 ---
(In reply to comment #1)
this is a dup of PR29767
Sorry for duplication, I haven't checked again after I posted to the gcc-help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29830
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-14 15:54 ---
What does adding '-v' to the compile command say? It seems Ubuntu is using a
default -march that enables 3dnow (k8 or opteron maybe) - it should use x86_64
instead.
--
rguenth at gcc dot gnu dot org changed:
Have built gcc with --prefix=/usr/local/gcc-4.1.1.
When /usr/local/gcc-4.1.1 is moved and symlinked to /stranger/gcc-4.1.1,
the include path order changes, so that fixed system headers are searched
before local headers.
In non-symlink case, where the searched include path is correct, I can see
gfortran.fortran-torture/execute/scalarize.f90 is miscompiled at least
on x86_64-linux with -O2 -ftree-loop-linear (other miscompiled fortran
tests with -ftree-loop-linear are forall_1.f90 and der_type.f90).
The only linear transformed loop in scalarize.f90 is the
b(:, 5:1:-1) = a
one (i.e.
int8
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-14 16:29 ---
Please file a bug with Ubuntu instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
--- Comment #2 from jakub at gcc dot gnu dot org 2006-11-14 14:28 ---
Forgot to mention, the problem is reproduceable also on gcc-4_1-branch
and gcc-4_2-branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Actual version string from gcc: 4.1.2 20060928 (prerelease) (Ubuntu
4.1.1-13ubuntu5)
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-11-14 16:30
---
*** Bug 29830 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-11-14 16:34
---
(In reply to comment #13)
While that can help in this case, I think letting make_tree/expand_expr
combo
create invalid RTL is very dangerous (and, at least from i386 backend POV,
some of the PIC UNSPECs
--- Comment #6 from Raimund dot Merkert at baesystems dot com 2006-11-14
15:52 ---
It does not seem to warn about unused functions. I also tried the following
test case where 4.0.0 (solaris) does not warn even about foo ( I guess because
it's referenced in Y's constructor?)
gcc
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-14 15:35 ---
Subject: Bug 29657
Author: burnus
Date: Tue Nov 14 15:35:36 2006
New Revision: 118812
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118812
Log:
fortran/
2006-11-14 Tobias Burnus [EMAIL PROTECTED]
--- Comment #5 from wolfgang dot roemer at gmx dot net 2006-11-14 15:35
---
[EMAIL PROTECTED] wrote:
Usually the problem will get caught as soon as you try to invoke a method, but
if it's something like a guard object, without methods, then it can be a
problem.
At least in this case
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-11-14 15:56 ---
For SUSE 4.1.2 I get prefetcht0 generated. So this is an Ubuntu bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tla at thrane dot com 2006-11-14 16:28 ---
(In reply to comment #4)
What's the status of this patch?
The bug is also present in arm-elf-gcc version 4.1.0
However, adding the -fno-omit-frame-pointer parameter, make
the compiler emit the correct code in the mentioned
--- Comment #4 from thaytan at noraisin dot net 2006-11-14 16:09 ---
It's using -mtune=generic:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib
More cases where g++ apparently doesn't take
enough context into account when deciding that
something can be (and thus is) a declaration.
Compiled the following (legal) program using g++ -c
---
struct Doh
{
Doh( int ) {}
} ;
int x = 0 ;
int
f()
{
Doh(
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-11-14 16:44
---
What about:
de.f90:4:
use foo, only : bar
1
Fehler: Bei (1) referenziertes Symbol »bar« nicht im Modul »foo« gefunden
My limited german knowledge seems to indicate that it's OK, but I'm not sure.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-14 16:30 ---
*** This bug has been marked as a duplicate of 14032 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from Jean-pierre dot vial at wanadoo dot fr 2006-11-14
17:11 ---
(In reply to comment #0)
when building ada on linux (x86-64)
building ada fails because the makefile looks for gnatbuild in
mydir/gcc-4.2-20061107/prev-gcc
instead of
--- Comment #1 from thaytan at noraisin dot net 2006-11-14 14:26 ---
Created an attachment (id=12617)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12617action=view)
simple test file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-14 10:09 ---
This is not a bug, the reason is because
void foo(char);
void (*f1)() = foo;
For foo, the prototype is not using int but instead char (or short) and f1 is
not reallying having a prototype (old KR rules).
Comeau C
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-14 09:53 ---
Hmm, isn't movl %eax, [EMAIL PROTECTED] a valid way to have an
offset?
Reduced testcase:
struct _Unwind_Context
{
void *reg[18];
};
static unsigned char dwarf_reg_size_table[18];
uw_install_context_1 (void
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-14 12:42 ---
You need to provide a preprocessed testcase, specify what gcc version you use
and what flags to compile.
arm-linux-g++: Internal error: Killed (program cc1plus)
this means the kernel (or you) killed the compiler,
--- Comment #25 from fche at redhat dot com 2006-11-14 12:19 ---
(In reply to comment #24)
Might the problem be that I am compiling on an old glibc?
That is possible. Try MUDFLAP_OPTIONS=-trace-calls -verbose-trace.
If you have access to a modern glibc, you could compare traces from
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-11-14 17:14
---
Subject: Bug 29106
Author: mmitchel
Date: Tue Nov 14 17:13:57 2006
New Revision: 118818
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118818
Log:
PR c++/29106
* g++.dg/init/self1.C: New
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-11-14 17:14
---
Created an attachment (id=12619)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12619action=view)
patch
This one passes a C bootstrap regtest on x86_64.
--
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-11-14 17:15
---
Subject: Bug 29106
Author: mmitchel
Date: Tue Nov 14 17:15:08 2006
New Revision: 118819
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118819
Log:
PR c++/29106
* g++.dg/init/self1.C: New
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-11-14 17:15
---
Fixed in 4.1 by the patch for PR 29106.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2006-11-14 17:16 ---
Fehler: Bei (1) referenziertes Symbol »bar« nicht im Modul »foo« gefunden
My limited german knowledge seems to indicate that it's OK, but I'm not sure.
Looks ok.
Could you try the attached patch on a few cases
--- Comment #10 from acme at mandriva dot com 2006-11-14 17:19 ---
(In reply to comment #9)
I'm quite aware of what GCC outputs here :)
However, past the initial declarations, we don't output debug
information about what the state of the IR is at random points in the
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-11-14 17:25
---
The following simpler test case is sufficient to show the same behavior:
struct X{};
void f(X x)
{
f(x);
f(x);
}
Also, it is indeed true that --param max-inline-recursive-depth-auto=3 makes
this compile
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-11-14 17:30
---
I cannot getting this to fail with current GCC 4.1.2 sources. Can others still
reproduce this problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27826
--- Comment #11 from zjasz at yahoo dot com 2006-11-14 17:40 ---
(In reply to comment #6)
Work postponed to GCC 4.1. This bug is tricky to fix.
What is the status of this bug? Will be resolved in the next release?
For us is critical because a whole framework is built up on this.:,,,(
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-11-14 17:42
---
It's true that the number of created calls is 2^N, but unfortunately the number
of created temporaries grows super-exponential:
--param max-inline-recursive-depth-auto grep 'struct X' t.C.t24.fixupcfg
| wc
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-11-14 17:44
---
Yes:
gcc41-g/gcc ./cc1plus -quiet t.C -O3
t.C: In function 'int f()':
t.C:6: internal compiler error: in copy_to_mode_reg, at explow.c:577
Please submit a full bug report,
with preprocessed source if appropriate.
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-11-14 17:46
---
Raising severity, some more people in CC. This at least seems to be an often
reported problem.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-11-14 17:50 ---
fpchg should also be enabled in sh.md for TARGET_SH4_300
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29349
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-11-14 17:54
---
(In reply to comment #12)
Raising severity, some more people in CC. This at least seems to be an often
reported problem.
It is not a regression as far as I can tell.
--
pinskia at gcc dot gnu dot org
gfortran writes:
read(1,'(Q,A)',iostat=i) n,line(:n)
1
Warning: Unexpected element in format string at (1)
And if there is a long comment it may even look like:
XLINE
1
Warning: Unexpected element in format string at (1)
Expected:
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-11-14 18:12 ---
Subject: Bug 27755
Author: dberlin
Date: Tue Nov 14 18:12:20 2006
New Revision: 118821
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118821
Log:
2006-11-14 Daniel Berlin [EMAIL PROTECTED]
Fix PR
--- Comment #16 from jason at gcc dot gnu dot org 2006-11-14 18:21 ---
(In reply to comment #15)
patch
Please apply this patch to 4.2 and the trunk. I've reverted my patch on the
4.1 branch, as it seems to be too risky there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
--- Comment #14 from bangerth at math dot tamu dot edu 2006-11-14 18:37
---
Subject: Re: Specialization of inner template using outer template argument
doesn't work
It is not a regression as far as I can tell.
True. However it does produce wrong code.
W.
--
--- Comment #2 from patchapp at dberlin dot org 2006-11-14 18:41 ---
Subject: Bug number pr24783
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-11/msg00966.html
--
--- Comment #6 from bonzini at gnu dot org 2006-11-14 18:56 ---
Created an attachment (id=12620)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12620action=view)
updated patch
Right, you need this additional hunk (I didn't include the regenerated
configure, you have to run
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-11-14 19:45
---
Please apply this patch to 4.2 and the trunk. I've reverted my patch on the
4.1 branch, as it seems to be too risky there.
Have you really done so?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
To whom it may concern,
I am trying to use the macro concatenation operator to make a conditional
comment. I want a symbol that I can sprinkle throught my C code that will be
replaced either be a C++ style // comment, or it will be replaced with nothing.
This is useful for turning on and off
--- Comment #3 from jens dot maurer at gmx dot net 2006-11-14 20:24 ---
I agree with Wolfgang's interpretation of the standard, but can't see why it
renders my original code invalid.
14.3.2/1 says that a constant expression that evaluates to a null member
pointer value is allowed as a
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-14 21:08 ---
The remark in #3 that the bug clears if the order of the procedures is reversed
is a giveaway:
Index: gcc/fortran/trans-types.c
===
***
--- Comment #18 from debian-gcc at lists dot debian dot org 2006-11-14
21:09 ---
(In reply to comment #16)
I've reverted my patch on the
4.1 branch, as it seems to be too risky there.
afaics the patch is not yet reverted.
Matthias
--
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-14 21:24 ---
If the implicit none or the module ... end module is removed, the ICE goes
away. Probably worth running using a non-optimized front-end under valgrind.
or replacing a = sum (eps(i:i) * eps)
by
a = sum (eps *
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-14 21:33 ---
I you use
( Doh ( x ) ), ++ x;
it works. (EDG accepts the code unmodified)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-14 21:48 ---
It gets better and better...
module gfcbug45
implicit none
contains
subroutine foo
integer :: i
real:: a
real, parameter :: eps(1) = (/ 1 /)
i = 1
a = mysum (eps(i:i) * eps)
end
Exchange Service from Paypal to e-gold, from StormPay to e-gold, from
Moneybookers to e-gold
SERVICE FEES:
PayPal to E-Gold: 5% - 10%
StormPay to E-Gold: 5% - 10%
Moneybookers to E-Gold: 4%-7%
PayExchange.net
www.PayExchange.net
--- Comment #1 from neil at daikokuya dot co dot uk 2006-11-14 22:49
---
Subject: Re: New: Concatenation operator ## doesn't work with this: / ## /
michael dot bishop at gdcanada dot com wrote:-
I am trying to use the macro concatenation operator to make a conditional
comment.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-14 22:51 ---
Not a bug as explained by Neil.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-14 22:55 ---
Janis can you do a regression hunt on this bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Different INTENT parameters on the first argument of overloaded subroutines
confuse the argument matching mechanism and a compiler error is generated for
code that is correct. See attached testcase.
The problem breaks my code and I see no workaround. I hope somebody can fix it
before the release.
1 - 100 of 131 matches
Mail list logo
