See: http://gcc.gnu.org/ml/fortran/2008-09/msg00380.html
and following emails.
The configure script does link tests which cause some kinds of cross
compilations to fail.
Solution (cf. email thread, see above link):
a) Approved patch in the link above
b) Remove "AC_LIBTOOL_DLOPEN" which does not s
--- Comment #3 from doug dot gregor at gmail dot com 2008-09-24 06:01
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01667.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37553
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2008-09-24 05:14
---
Created an attachment (id=16399)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16399&action=view)
New patch that is much better
I could not submit this to the list for approval, my email is not working.
R
--
doug dot gregor at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |doug dot gregor at gmail dot
|dot org
--- Comment #7 from jakub at gcc dot gnu dot org 2008-09-24 03:24 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-24
03:12 ---
This bug is linker related. It is fixed on 32-bit windows by this patch
http://sourceware.org/ml/binutils-cvs/2007-10/msg2.html
Have you tried with recent binutils and explict -Wl,--enable-auto-imp
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from nemet at gcc dot gnu dot org 2008-09-24 02:09 ---
I am seeing this too with a 4.1 system compiler.
It seems that CFLAGS_FOR_TARGET is incorrectly (?) used for building libiberty
in stage1 (all-stage1-libiberty). This is not a target library but a sort of
build libra
--- Comment #2 from lucier at math dot purdue dot edu 2008-09-24 01:34
---
And it doesn't happen if I use Apple's builtin gcc-4.0.1. Blah.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37632
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633
Currently many tests for string builtin functions fail on
sh64-unknown-linux-gnu. Here is a small test case:
extern void abort (void);
char buf[64];
int
main (void)
{
__builtin_strcpy (buf, "mystring");
if (strcmp (buf, "mystring") != 0)
abort ();
__builtin_strcpy (buf, "mystring");
--- Comment #1 from lucier at math dot purdue dot edu 2008-09-24 00:53
---
I forgot to mention the linker version:
[descartes:objdirs/mainline/gcc] lucier% ld -v
@(#)PROGRAM:ld PROJECT:ld64-85.2.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37632
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-24 00:35 ---
IIRC these are not documented because they can and will change at any time and
don't always produce correct code.
Also you can use most of the builtin functions to get the same as the
inline-asm ...
--
http://g
Configured with
#!/bin/tcsh
/bin/rm -rf *; ../../mainline/configure CC='gcc -mcpu=970 -m64'
--build=powerpc64-apple-darwin9.5.0 --host=powerpc64-apple-darwin9.5.0
--target=powerpc64-apple-darwin9.5.0 --with-gmp-include=/sw/include/
--with-gmp-lib=/sw/lib/ppc64 --with-mpfr-include=/sw/include/
--wi
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-09-24 00:21
---
The one thing which we should do after sra_early is another
pass_rename_ssa_copies so we get more correct variable/debug names. (but that
is not the issue).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3744
ome/janis/tools/gmp-mpfr-32 --with-long-double-128
--enable-secureplt --disable-libstdcxx-pch
Thread model: posix
gcc version 4.4.0 20080923 (experimental) [trunk revision 140601] (GCC)
elm3b149% $GCC -O1 -ffast-math 37449-3.c -lm && a.out
cn = -2
neig = 3
Aborted
elm3b149% $GCC -O1 37449-
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-09-23 23:51 ---
You want --with-arch or -march=i686.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37509
--- Comment #26 from pinskia at gcc dot gnu dot org 2008-09-23 23:50
---
*** Bug 37631 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-23 23:50 ---
A volatile asm is not a full barrier.
Please read http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Extended-Asm.html.
" Note that even a volatile asm instruction can be moved relative to other
code, including across jump
--- Comment #19 from Hans dot Boehm at hp dot com 2008-09-23 23:39 ---
I looked at this a bit, trying to remind myself of the logic. I'm not
positive, but it looks plausible to me that doing without the finalizer might
work for most applications. Historically, the finalizer was the onl
--- Comment #6 from timothy dot krause at shaw dot ca 2008-09-23 22:56
---
(In reply to comment #5)
> Setting
> CFLAGS="-m32 -march=i686 -O2"
> fixed the problem for
> host=i686-pc-linux-gnu
> target=i686-pc-linux-gnu
> I later noticed that configure has a --with-cpu option. This genera
--- Comment #5 from timothy dot krause at shaw dot ca 2008-09-23 22:53
---
Setting
CFLAGS="-m32 -march=i686 -O2"
fixed the problem for
host=i686-pc-linux-gnu
target=i686-pc-linux-gnu
I later noticed that configure has a --with-cpu option. This generates a
-mcpu=i?86 option which also wo
--- Comment #1 from joseph at codesourcery dot com 2008-09-23 22:24 ---
Subject: Re: New: gcc.dg/20001012-1.c depends on IEEE
FP encoding
As a maintainer of a non-mainstream target you'll need to submit testsuite
patches to disable tests inapplicable on your target; it's unlikely an
I'm not 100% sure this is a bug; it seems like one.
A non-volatile asm passes a volatile asm. Intuitively, it seems a volatile asm
should be a pretty "heavy" barrier.
As a workaround, declaring both volatile does limit code motion, but also
limits the optimizer more than just keeping the relati
--- Comment #13 from law at redhat dot com 2008-09-23 21:55 ---
Subject: Re: Missed jump threading optimization
steven at gcc dot gnu dot org wrote:
> --- Comment #12 from steven at gcc dot gnu dot org 2008-09-21 13:58
> ---
> tree PRE now *does* handle the partially redundan
and thus fails on platforms which don't use IEEE FP encoding such as VAX.
--
Summary: gcc.dg/20001012-1.c depends on IEEE FP encoding
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
--- Comment #7 from tromey at gcc dot gnu dot org 2008-09-23 20:48 ---
Jan> Tom, could you elaborate why x1 and x2 should be printed differently?
Jan> I do not say they should not but I do not see a clear reason for either
way.
My view is that "whatis" should print the declared type, as
Compiling ffmpeg (see
http://sourceforge.net/tracker2/?func=detail&aid=2118261&group_id=202880&atid=983354)
under mingw-w64 into a DLL results in a runtime crash involving two dlls.
in libavutil.dll:
const uint8_t ff_log2_tab[256];
in libavcodec.dll:
extern const uint8_t ff_log2_tab[256];
static
--- Comment #55 from jason at gcc dot gnu dot org 2008-09-23 20:43 ---
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-23 19:43 ---
It fails for the following assert:
gfc_conv_descriptor_data_get (tree desc)
{
tree field, type, t;
type = TREE_TYPE (desc);
gcc_assert (GFC_DESCRIPTOR_TYPE_P (type));
Reduced test case:
function unique_A (x
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-09-23 19:27
---
> Clean build from a source tree that was the result of svn switching to the
> 4.3.2 release tag (was previously a 4.3.0 release I think).
Update your tree with contrib/gcc_update.
--
ebotcazou at gcc dot gnu
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-09-23 19:26
---
> That probably means you have too old mpfr.
Yes, I just upgraded from 2.2.x to 2.3.1 on Solaris and the failure vanished.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from brian at dessent dot net 2008-09-23 19:23 ---
Subject: Re: New: In function `fold_builtin_1': undefined
reference to `mpfr_j0'
It sounds like you have an older system copy of mpfr in /usr/lib which
is being used instead of the one you built. Use --with-mpfr=foo
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-23 19:03 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-23 18:58 ---
Subject: Bug 37533
Author: jakub
Date: Tue Sep 23 18:57:18 2008
New Revision: 140613
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140613
Log:
PR c++/37533
* semantics.c (finish_omp_for): If p
--- Comment #1 from dominiq at lps dot ens dot fr 2008-09-23 18:48 ---
On ppc/intel Darwin9, I get
pr37626.f90: In function 'unique_a':
pr37626.f90:42: internal compiler error: in gfc_conv_descriptor_data_get, at
fortran/trans-array.c:147
with 4.2.3, 4.3.2, and trunk.
--
http://gc
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-23 18:48 ---
Just a few nits:
1) why do you need to call nreverse? I don't think the order of vars in
BLOCK_VARS matters, and when you call nreverse you reorder them all but the one
you added anyway
2) have you checked that gimple
--- Comment #13 from mmitchel at gcc dot gnu dot org 2008-09-23 18:38
---
The C++ WP draft I have (a bit old) says:
If the second and third operands are lvalues and have the same type, the result
is of that type and is an lvalue and it is a bit-field if the second or the
third operand
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-23 18:33 ---
That probably means you have too old mpfr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
--- Comment #1 from cfriedt at visible-assets dot com 2008-09-23 18:31
---
Created an attachment (id=16397)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16397&action=view)
output of 'gcc -v -save-temps'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37627
It assumes the existence of signed 0.0 which is not available across all FP
implementations. Specifically, this test fails on VAX since VAX FP has no
concept of -0.0. In fact, -0.0 would cause a reserved operand fault.
--
Summary: gcc.c-torture/execute/pr35456.c is not generic
I just finished compiling mpfr-2.3.2 and was moving on to compile gcc-4.3.2,
and i'm consistently getting the attached build error which ends with the
snippet below. The error would suggest that, for example, the symbol / function
mpfr_j0 is not defined in libmpfr, although it is clearly defined gl
The sample code below produces the following internal compiler error:
unique_A.f90: In function 'unique_a':
unique_A.f90:42: internal compiler error: Segmentation fault
The error seems to be associated with use of the PACK() intrinsic.
--CUT HERE--
function unique_A (x, sorted) result (x_unique)
--- Comment #18 from daney at gcc dot gnu dot org 2008-09-23 17:40 ---
Created an attachment (id=16396)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16396&action=view)
Possible work-around
This is a patch against 3.4.3 that we are seriously considering using
internally. The theo
--- Comment #1 from lucier at math dot purdue dot edu 2008-09-23 17:35
---
Forget it, the problem seems to be fixed by configuring with
env CC=/usr/bin/gcc-4.0 ../gcc-4.3.2/configure --with-libiconv-prefix=/sw/
--enable-languages=c --enable-checking=release
--build=powerpc-apple-darwin
--- Comment #9 from hp at gcc dot gnu dot org 2008-09-23 17:20 ---
(In reply to comment #2)
> Ok, I think I know what's going wrong: please confirm that your target is
> using
> sscanf.
You're too fast for me! :)
Being a newlib cross target, it doesn't use strtold; newlib has no generi
--- Comment #8 from paolo dot carlini at oracle dot com 2008-09-23 17:15
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|ASS
--- Comment #7 from paolo at gcc dot gnu dot org 2008-09-23 17:13 ---
Subject: Bug 37624
Author: paolo
Date: Tue Sep 23 17:12:26 2008
New Revision: 140602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140602
Log:
2008-09-23 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #6 from paolo dot carlini at oracle dot com 2008-09-23 16:45
---
Unfortunately, I think we have to "xfail" the test for targets not having
available strtold and falling back to sscanf for long double parsing. Note that
DR 23 mandates, for a reason, a behaviour equivalent to
--- Comment #5 from paolo dot carlini at oracle dot com 2008-09-23 16:36
---
Never mind, I know what's going wrong but the patch is not ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
--- Comment #4 from paolo dot carlini at oracle dot com 2008-09-23 16:30
---
Created an attachment (id=16395)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16395&action=view)
Draft
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
--- Comment #3 from paolo dot carlini at oracle dot com 2008-09-23 16:29
---
Assuming the weak check on sscanf return value is the issue, please test the
attached patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-23 16:24
---
Ok, I think I know what's going wrong: please confirm that your target is using
sscanf.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
I configured gcc with
env CC=/usr/bin/gcc-4.0 ../gcc-4.3.2/configure --enable-languages=c
--enable-checking=release --build=powerpc-apple-darwin9.5.0
--host=powerpc-apple-darwin9.5.0 --target=powerpc-apple-darwin9.5.0
--with-gmp-include=/sw/include/ --with-gmp-lib=/sw/lib/
--with-mpfr-include=/sw/
--- Comment #1 from paolo dot carlini at oracle dot com 2008-09-23 16:12
---
I'm certainly willing to help but please provide more info: e.g., what is the
value of err? Which is the path followed by cris-axis-elf in
__convert_to_v(const char* __s, long double& __v, ...)?
--
http://
With revision 140565 this test passed.
>From revision 140575 and on, this test has failed as follows:
Running
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
FAIL: 22_locale/num_get/get/char/10.cc execution test
With the message in the logfile being:
assertion "e
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-09-23 16:08 ---
Subject: Bug 37391
Author: bkoz
Date: Tue Sep 23 16:06:43 2008
New Revision: 140600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140600
Log:
2008-09-23 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstd
--- Comment #43 from b0ntrict0r at yandex dot ru 2008-09-23 14:31 ---
(In reply to comment #42)
> Created an attachment (id=16389)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389&action=view) [edit]
> internal-error-testcase
>
Hm... I can reproduce it with gcc 4.3.2 and canno
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-23 14:29 ---
Fixed on trunk.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-23 14:28 ---
Subject: Bug 37588
Author: domob
Date: Tue Sep 23 14:26:47 2008
New Revision: 140594
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140594
Log:
2008-09-23 Daniel Kraft <[EMAIL PROTECTED]>
PR fortran
--- Comment #7 from aph at gcc dot gnu dot org 2008-09-23 13:52 ---
Subject: Bug 8995
Author: aph
Date: Tue Sep 23 13:51:58 2008
New Revision: 140593
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140593
Log:
2008-09-17 Andrew Haley <[EMAIL PROTECTED]>
PR libgcj/8995:
--- Comment #1 from tim dot vanholder at anubex dot com 2008-09-23 13:45
---
Created an attachment (id=16394)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16394&action=view)
Test results for "builtin-math-4.c -O3 -g"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
Clean build from a source tree that was the result of svn switching to the
4.3.2 release tag (was previously a 4.3.0 release I think).
make check reports a handful of errors; I'm logging each separately once I
determine the likely cause.
The builtin-math-4.c test (8 flavours) from gcc.dg fails.
Lo
Clean build from a source tree that was the result of svn switching to the
4.3.2 release tag (was previously a 4.3.0 release I think).
make check reports a handful of errors; I'm logging each separately once I
determine the likely cause.
the gcc.dg/cpp/direct2s.c test fails with "test for excess e
--- Comment #3 from dodji at gcc dot gnu dot org 2008-09-23 13:08 ---
(From update of attachment 16393)
The idea of the patch is to add an IMPORTED_DECL node to the lexical BLOCK
enclosing the "using directive".This is done at gimplification time.
Then the patch modifies dwarf2out.c to
--- Comment #2 from dodji at gcc dot gnu dot org 2008-09-23 13:04 ---
Created an attachment (id=16393)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16393&action=view)
first fix candidate
This patch seems to fix the problem for me and passes regtests on trunk.
--
http://gcc.g
--- Comment #3 from janus at gcc dot gnu dot org 2008-09-23 12:44 ---
(In reply to comment #2)
> How about the following patch?
Looks very good, and does what it should. Just one thing: We will also have to
check for attr.in_common, so that normal procptrs don't get messed up.
Otherwise
I came across the following modifiers for inline assembler:
asm ("rorw $8, %w0" : "=q" (y) : "0" (x));
asm ("xchg %b0, %h0" : "=q" (y) : "0" (x));
They work very well. No bug in the compiler itself, but I haven't found
anything about them in the online documentation.
Note: The %w0, %b0 and
--- Comment #3 from brian at dessent dot net 2008-09-23 11:43 ---
Subject: Re: libgcc/configure (as script)fail with "line
77 exec : : not found."
Your cross-assembler and linker should be named $target-as and
$target-ld so they can't clash with the host tools, and this is what th
--- Comment #4 from sam at gcc dot gnu dot org 2008-09-23 11:32 ---
I don't agree with your reasoning: X is not referenced. The fact that it has a
constructor should not change anything. For example, access types are
initialized to Null as well, so you could count that as a reference.
Y
--- Comment #3 from esigra at gmail dot com 2008-09-23 10:32 ---
Created an attachment (id=16392)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16392&action=view)
Makefile
--
esigra at gmail dot com changed:
What|Removed |Added
--
--- Comment #2 from esigra at gmail dot com 2008-09-23 10:27 ---
Created an attachment (id=16391)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16391&action=view)
implementation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37620
--- Comment #1 from esigra at gmail dot com 2008-09-23 10:26 ---
Created an attachment (id=16390)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16390&action=view)
Makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37620
Even though a variable is referenced by (implicit) procedure calls (such as
Initialize and Finalize), GCC gives:
warning: variable "X" is not referenced
This happens especially when using the RAII design pattern. The warning should
not be shown when the variable is referenced by a procedure call
--- Comment #42 from pluto at agmk dot net 2008-09-23 10:13 ---
Created an attachment (id=16389)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389&action=view)
internal-error-testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
--- Comment #41 from pluto at agmk dot net 2008-09-23 10:12 ---
and the lastest patch causes internal error in cc1plus in my codebase:
$
/local/devel/toolchain43/x86_64-gnu-linux.host64.diag/bin/x86_64-gnu-linux-g++
smsSimClock.ii -c -std=gnu++0x
Internal compiler error: Error reportin
--- Comment #8 from pault at gcc dot gnu dot org 2008-09-23 10:10 ---
(In reply to comment #6)
Thanks to you both - I did not look subsequently at this PR. I hit the problem
with ENTRY_1.F90, of course and my solution was one and the same. Many thanks
for the coup de main and sorry tha
--- Comment #3 from esigra at gmail dot com 2008-09-23 09:52 ---
Created an attachment (id=16388)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16388&action=view)
implementation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619
--- Comment #2 from esigra at gmail dot com 2008-09-23 09:51 ---
Created an attachment (id=16387)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16387&action=view)
specification
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619
--- Comment #1 from esigra at gmail dot com 2008-09-23 09:51 ---
Created an attachment (id=16386)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16386&action=view)
Makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619
The procedure Finalize is supposed to be overridden to get a constructor for a
type, but doing so gives a warning, eventhough the code explicitly states that
the new Finalize should override the old one. Sample code attached.
--
Summary: overriding Finalize gives: warning: declaration
--- Comment #3 from esigra at gmail dot com 2008-09-23 09:39 ---
Created an attachment (id=16385)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16385&action=view)
implementation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37618
--- Comment #2 from esigra at gmail dot com 2008-09-23 09:39 ---
Created an attachment (id=16384)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16384&action=view)
specification
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37618
--- Comment #1 from esigra at gmail dot com 2008-09-23 09:38 ---
Created an attachment (id=16383)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16383&action=view)
Makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37618
A parameter of a type without actual data components, that is only used for
dispatching, gives:
warning: formal parameter "X" is not referenced
But the type is a null record, so there is nothing that could be referenced.
And the parameter is actually used to select which function to call. Sampl
--- Comment #2 from nospamname at web dot de 2008-09-23 08:19 ---
thanks when i copy as ln for quick test to gcc dir then this error not come.
I remove that path before, because i fear clashes between the x86 cygwin
compilers and old 3.4 68k compilers and binutils.
maybe in the as scri
--- Comment #5 from burnus at gcc dot gnu dot org 2008-09-23 08:01 ---
Subject: Bug 37580
Author: burnus
Date: Tue Sep 23 08:00:01 2008
New Revision: 140580
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140580
Log:
2008-09-22 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
88 matches
Mail list logo