Hi,
I am using gcc (GCC) 4.2.1 (SUSE Linux).
SUSE 10.3
While compiling a .c file I get following error
Configuration.h:70: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘extern’
can anybody tell me ways to sort out such problems.
Thanks
--
View this message in context:
http
gcc --v
Using built-in specs.
Target: i486-linux-gnu
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 --enable-nls
--with-gxx-incl
--- Comment #17 from hjl dot tools at gmail dot com 2008-08-04 06:32
---
(In reply to comment #16)
> (In reply to comment #14)
> > The complete make check from the boot strap is still running but the g++
> > stackalign failures have been reduced down to just...
> >
> > FAIL: g++.dg/tor
--- Comment #5 from hjl dot tools at gmail dot com 2008-08-04 05:52 ---
It is the problem with -mno-accumulate-outgoing-args:
bash-3.2$ /export/build/gnu/gcc-avx/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -m32 -msse2 -DDEBUG
-mno-accumulate-outgoing-
The gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and
"$EGGREP" (but not "ggrep") in a non-portable and inconsistent manner.
Examples:
1. Lines 5224, 5254, 5295, 5298, etc... use "egrep" but "EGREP" is not tested
for (to decide if we will use "grep -E" or "egrep") until line
--- Comment #16 from hjl dot tools at gmail dot com 2008-08-04 03:26
---
(In reply to comment #14)
> The complete make check from the boot strap is still running but the g++
> stackalign failures have been reduced down to just...
>
> FAIL: g++.dg/torture/stackalign/eh-alloca-1.C -O3 -
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2008-08-04
02:32 ---
Testresults from the proposed patch are at...
http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00333.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
--- Comment #3 from gcc at karrels dot org 2008-08-04 01:39 ---
(In reply to comment #0)
Bug only occurs with optimization turned on.
--
gcc at karrels dot org changed:
What|Removed |Added
--
--- Comment #2 from gcc at karrels dot org 2008-08-04 01:37 ---
Created an attachment (id=16008)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16008&action=view)
Output from "gcc -v -save-temps -O -c foo.c"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37018
--- Comment #1 from gcc at karrels dot org 2008-08-04 01:35 ---
Created an attachment (id=16007)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16007&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37018
In this sample, which includes inline assembly code, GCC produces assembly that
uses 64-bit registers when the target is 32-bit code. The assembler complains:
foo.c: Assembler messages:
foo.c:17: Error: bad register name `%dil'
--
Summary: compiling inline assembly for ia32 produces
--- Comment #2 from rob1weld at aol dot com 2008-08-04 01:28 ---
> Is there a reason why you are not using just --enable-threads=pthreads?
A few reasons.
1. I test _all_ of gcc's configure options, submit bug reports and email test
results - "--enable-threads=solaris" is a valid choic
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2008-08-04
00:53 ---
The complete make check from the boot strap is still running but the g++
stackalign failures have been reduced down to just...
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C -O3 -g execution test
FAIL: g
--- Comment #1 from dje at gcc dot gnu dot org 2008-08-03 23:59 ---
This is fixed in G++ 4.3, probably due to a libstdc++ fix.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-03 23:08 ---
I really don't think using solaris threads is that well supported anymore. Is
there a reason why you are not using just --enable-threads=pthreads?
--
pinskia at gcc dot gnu dot org changed:
What|
When configuring with --enable-threads=solaris the build runs for hours and
then breaks after the libgfortran finished when configuring boehm-gc .
It would be nice if the main configure script caught this instead of the build
failing just as it was about to finish.
I am building gcc-4.2.3 releas
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-03 21:47 ---
Confirmed.
SRA messing up again when there is different FIELD decls.
itemfunptrD.21695.__pfnD.21700 ={v} itemfunD.21696;
memfunD.24341 ={v} itemfunptrD.21695;
memfun$__pfnD.24346_4 = memfunD.24341.__pfnD.21692
#include
/*
Basic design concept is that WorldObject implements remote method call
functionality using the "curiously recurring template pattern" to enable
forwarding calls from the generic base clas
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-03 20:32 ---
That is correct. % is not really the modulo operator but instead the remainder
operator :). So (-a) %b is the same as -(a%b).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
using negative numbers, like for example
(-1)%4 results in -1 instead of the right result, which is 3
--
Summary: modulo operations which use negative numbers return
unexpected results
Product: gcc
Version: 4.3.1
Status: UNCONFIRM
--- Comment #13 from hjl dot tools at gmail dot com 2008-08-03 20:26
---
(In reply to comment #12)
> HJ,
>Your proposed patch eliminated all the stackalign failures in 'make -k
> check-gcc' reducing the total gcc failures down to 14 unexpected. I will do a
> 'make -k check-g++' next
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-08-03
20:24 ---
HJ,
Your proposed patch eliminated all the stackalign failures in 'make -k
check-gcc' reducing the total gcc failures down to 14 unexpected. I will do a
'make -k check-g++' next but this fix looks good
--- Comment #4 from hjl dot tools at gmail dot com 2008-08-03 20:11 ---
A run-time testcase:
bash-3.2$ cat y.c
/* PR middle-end/37010 */
/* { dg-do run { target { { i?86-*-* x86_64-*-* } && ilp32 } } } */
/* { dg-options "-msse2" } */
typedef __PTRDIFF_TYPE__ ptrdiff_t;
extern void abo
--- Comment #11 from hjl dot tools at gmail dot com 2008-08-03 19:26
---
Created an attachment (id=16006)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16006&action=view)
A patch
Jack, can you try this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-08-03 18:54
---
The regparm-* failures are really PR 26553.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
--- Comment #9 from hjl dot tools at gmail dot com 2008-08-03 18:48 ---
Joey, I think the problem is the usage of STACK_BOUNDARY / BITS_PER_UNIT
for stack alignment. On MacOS, STACK_BOUNDARY 128 on ia32. Shouldn't
we use UNITS_PER_WORD in some cases? Please double check all usages of
STA
--- Comment #3 from hjl dot tools at gmail dot com 2008-08-03 18:40 ---
Joey, when we compute frame layout, we don't count the duplicated
return address pushed onto stack when DRAP is used. Also when we
push return address, shouldn't we use -UNITS_PER_WORD, instead of
-(STACK_BOUNDARY /
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-08-03
18:22 ---
Created an attachment (id=16005)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16005&action=view)
assembly file for gcc.dg/torture/stackalign/regparm-1.c
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-08-03
18:22 ---
Created an attachment (id=16004)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16004&action=view)
preprocessed source file for gcc.dg/torture/stackalign/regparm-1.c
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-08-03
18:19 ---
Another of the testsuite execution tests that are failing is regparm-1.exe.
When compiled as in the testsuite run as...
gcc-4 ./regparm-1.c -Os -mstackrealign -mpreferred-stack-boundary=5 -g -fpic
-fno-sho
--- Comment #2 from hjl dot tools at gmail dot com 2008-08-03 18:18 ---
(In reply to comment #1)
> A patch is posted at
>
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00123.html
>
This patch is incorrect. The problem is between ACCUMULATE_OUTGOING_ARGS,
ix86_compute_frame_layout and
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-08-03
17:52 ---
The eh-alloca-1.exe always segfaults even after commenting all of the abort()
calls. I'll see if I can find one of the gcc c testsuite executions that are
failing as that may be easier to debug.
--
htt
--- Comment #8 from ubizjak at gmail dot com 2008-08-03 17:44 ---
CCing HJ for ABI issue.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #6 from ubizjak at gmail dot com 2008-08-03 17:38 ---
Can we have a final word from ABI people here please?
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from ubizjak at gmail dot com 2008-08-03 17:30 ---
This enhancement was implemented at least for gcc-4.3.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #4 from ubizjak at gmail dot com 2008-08-03 17:23 ---
The testcase works OK with gcc-4.3.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2008-08-03 17:01 ---
Please narrow down where the problem is since we don't have MacOS:
1. Turn eh-alloca-1.ii into eh-alloca-1.C by removing those
# x
2. Remove abort from eh-alloca-1.C one by one to track down
to single abort.
--- Comment #3 from ubizjak at gmail dot com 2008-08-03 16:59 ---
GNU C (GCC) version 4.4.0 20080803 (experimental) is now much smarter, several
rewrites of math ops now result in:
foobar:
pushl %ebp
movl%esp, %ebp
fldsa
fmuls b
flds
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #15 from andry at inbox dot ru 2008-08-03 12:18 ---
I found where the bug is:
"/mingw/lib/libmsvcrt.a" and "/mingw/lib/libmsvcrtd.a" should be Microsoft
Visual Studio v6.0 libraries. I just run "gccmrt.bat" attached to TDM builds of
GCC (http://www.tdragon.net/recentgcc/) and
--- Comment #1 from sam at gcc dot gnu dot org 2008-08-03 12:08 ---
Confirmed on SVN trunk:
+===GNAT BUG DETECTED==+
| 4.4.0 20080803 (experimental) (i686-pc-linux-gnu) Assert_Failure
einfo.adb:2446|
| Error detected at b.ads:1:6
--- Comment #1 from sam at gcc dot gnu dot org 2008-08-03 12:07 ---
Confirmed on 4.4.0 20080803 (i686-pc-linux-gnu).
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sam at gcc dot gnu dot org 2008-08-03 12:04 ---
It appears to be fixed already in GCC 4.3.1.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-08-03 09:22 ---
(In reply to comment #4)
> > Created an attachment (id=16001)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16001&action=view) [edit]
> > better patch
>
> I think some of the run-time checks (with -fbounds-che
--- Comment #1 from ubizjak at gmail dot com 2008-08-03 09:16 ---
Stack asm constraints have some annoying properties. Please note, that in your
testcase, value in %st1 isn't popped from the stack. Also, reverse subtract can
be used to avoid fxch. I propose to rewrite your function as:
--- Comment #5 from alex at ozo dot com 2008-08-03 08:43 ---
please discard the above entry and accept my apologies as this is my first
attempt to report a bug issue using bugzilla.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
trying to compile ath9k for mips or mipsel under openwrt toolchain with
gcc-4.2.4 produces the following error:
make[3]: Entering directory `/extra3/openwrt/ar71xx/trunk/package/ath9k'
make -C "/extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/linux-2.6.26"
ARCH="mips" CROSS_COMPILE="mips-linux-
--- Comment #4 from alex at ozo dot com 2008-08-03 08:33 ---
trying to compile ath9k for mips or mipsel under openwrt toolchain with
gcc-4.2.4 produces the following error:
make[3]: Entering directory `/extra3/openwrt/ar71xx/trunk/package/ath9k'
make -C "/extra3/openwrt/ar71xx/trunk/bui
--- Comment #4 from burnus at gcc dot gnu dot org 2008-08-03 07:23 ---
> Created an attachment (id=16001)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16001&action=view) [edit]
> better patch
I think some of the run-time checks (with -fbounds-checks) for PR 36874 can be
best done
--- Comment #5 from livubuntu at lalescu dot ro 2008-08-03 07:23 ---
(In reply to comment #4)
> (In reply to comment #2)
> > g++: Internal error: Killed (program cc1plus)
> >
> > this means your system ran out of memory and the operating system decided
> > to kill the compiler. Note th
50 matches
Mail list logo
