[Bug middle-end/29305] local label-as-value being placed before function prolog
--- Comment #8 from jeremy at goop dot org 2006-10-01 05:58 --- Reopen as enhancement, in the hope gcc implements more useful semantics for taking the address of a label. -- jeremy at goop dot org changed: What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug middle-end/29305] local label-as-value being placed before function prolog
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-01 06:24 --- (In reply to comment #8) Reopen as enhancement, in the hope gcc implements more useful semantics for taking the address of a label. They are useful if used correctly. You are not using them correctly. They are only for computed gotos and nothing else. They are not designed for anything else. In fact if GCC changes the behavior, it would be for the worse as then people using them correctly would be punished. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-01 07:43 --- Apart from the warnings in PR 26540, the situation is stable with the only warning being: ../../../trunk/libgfortran/io/list_read.c: In function list_formatted_read_scalar: ../../../trunk/libgfortran/io/list_read.c:1460: warning: argument type might be clobbered by longjmp or vfork I think this warning is not worth the trouble of rewriting this critical part of the code, potentially introducing a nasty regression or something like that. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||howarth at nitro dot med dot ||uc dot edu GCC host triplet|i686-pc-linux-gnu | Last reconfirmed|2006-05-19 17:04:21 |2006-10-01 07:43:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug preprocessor/29245] want way to #include but still able to finish compiling
--- Comment #11 from acahalan at gmail dot com 2006-10-01 07:50 ---
(In reply to comment #10)
I'm more familiar with the POSIX/UNIX standardization than the C/C++
standardization. Perhaps they have very different rules, but what
I've seen with the one group is that the committee strongly prefers
that there be an existing implementation.
But after the proposal has been written formally.
I have been assuming you have representatives on the committees.
Hopefully it is no big deal to submit something.
BTW, though most useful if standardized, it is still useful for
semi-portable code when not standardized. Sometimes people write
gcc-specific code but wish to support more than one OS or more
than one OS version.
Something simple, as shown above, is probably best.
Just in case something really powerful would be
more appealing though...
Fourth idea:
#try
# include foo.h
# include bar.h
# define GOT_THE_HEADERS
#endtry
#catch MY_HEADERS
# if MY_HEADERS != _Notincluded
#throw MY_HEADERS
# endif
#endcatch
#finally
# ifndef FOO
#define FOO 0
# endif
#endfinally
Fifth idea:
#func get_header_file(a)
##include a
#endfunc
#if eval(get_header_file(foo.h))
#define NO_FOO_HEADER
#endif
Sixth idea (hey it works for web pages):
#script safeinc(hf,def) { \
file=open(hf); \
if(file) emit(read(file)); \
else emit(#define + def); \
}
#eval safeinc(foo.h,NO_FOO_HEADER)
(with that one maybe the script could manipulate
the content a bit, editing the text before parsing
or editing the parse tree representation afterward)
Seventh idea (hey, it works for the Makefile):
#shell cat _Realname(foo.h) || true
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29245
[Bug middle-end/29305] local label-as-value being placed before function prolog
--- Comment #10 from jeremy at goop dot org 2006-10-01 08:47 --- In fact if GCC changes the behavior, it would be for the worse as then people using them correctly would be punished. How so? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
[Bug fortran/29284] [4.1/4.2 Regression] ICE for optional subroutine argument
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-01 09:23 --- Created an attachment (id=12364) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12364action=view) Fix for this problem This seems to be my doing - I forgot all about missing optionals when I introduced this test. I will submit to the list, when it has finished regression testing. Thanks for the PR. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29284
[Bug preprocessor/29245] want way to #include but still able to finish compiling
--- Comment #12 from joseph at codesourcery dot com 2006-10-01 11:25 --- Subject: Re: want way to #include but still able to finish compiling On Sun, 1 Oct 2006, acahalan at gmail dot com wrote: But after the proposal has been written formally. I have been assuming you have representatives on the committees. Hopefully it is no big deal to submit something. Countries have representatives on the committees, not compilers. Go via your National Body's C committee. You can implement a feature for a development branch - not trunk - to provide evidence of an existing implementation. Since documentation for new extensions should include edits to the standard text, you can reuse that documentation for a WG14 paper. Then get on your National Body delegation to a WG14 meeting and see what they think of your proposal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29245
[Bug fortran/29284] [4.1/4.2 Regression] ICE for optional subroutine argument
--- Comment #3 from patchapp at dberlin dot org 2006-10-01 13:45 --- Subject: Bug number PR29284 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-10/msg00011.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29284
[Bug testsuite/29307] New: libiberty/testsuite/test-demangle : parsing errors after unknown demangling style
When running libiberty/testsuite/test-demangle with an unknown demangling style, parsing gets confused... NOTE: I came accross this while investigating adding support for vc-style mangling to libiberty, so failure is expected, but the unknown demangling style for lines other than the --format=msvc is misleading. Input: # Symbols from C:\WINDOWS\$hf_mig$\KB896358\SP2QFE\hhsetup.dll --format=msvc --no-params ??0CFIFOString@@[EMAIL PROTECTED] public: __thiscall CFIFOString::CFIFOString(void) CFIFOString::CFIFOString # --format=msvc --no-params ??0CPointerList@@[EMAIL PROTECTED] public: __thiscall CPointerList::CPointerList(void) CPointerList::CPointerList Output: FAIL at line 4: unknown demangling style msvc FAIL at line 4, options --format=msvc: in: ??0CFIFOString@@[EMAIL PROTECTED] out: (null) exp: public: __thiscall CFIFOString::CFIFOString(void) FAIL at line 8: unknown demangling style CFIFOString::CFIFOString FAIL at line 11: unknown demangling style public: __thiscall CPointerList::CPointerList(void) test-demangle: 3 tests, 4 failures -- Summary: libiberty/testsuite/test-demangle : parsing errors after unknown demangling style Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: phil dot lello at homecall dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29307
[Bug libgomp/29308] New: TLS / non-TLS mismatch for COMMON declared in both ways
Compiling CAMx_v4.20, i'm getting: /usr/bin/ld: equk_: TLS reference in ./CF_AERO/isocom_v1.6.o mismatches non-TLS reference in ./CMU_AERO/diffund.o ./CMU_AERO/diffund.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [model] Error 1 make[1]: Leaving directory `/home/cow/src/CAMX/CAMx_Bench/CAMx_v4.20/src' make: *** [gfortran_linuxomp] Error 2 The error stems from a common that is used $omp threadprivate in one file and without annotation in another file (which may be an application glitch but ifort deals with this nicely): $ cat inc1.inc COMMON /EQUK/ XK1 c$omp threadprivate(/EQUK/) $ cat inc2.inc COMMON /EQUK/ XK1 $ cat sub1.f SUBROUTINE sub1 INCLUDE 'inc1.inc' END SUBROUTINE sub1 $ cat sub2.f SUBROUTINE sub2 INCLUDE 'inc2.inc' END SUBROUTINE sub2 $ cat main.f call sub1 call sub2 END $ cat Makefile all: sub1.o sub2.o main.o $(FC) $^ $ make FC=gfortran-4.2.orig-HEAD FFLAGS=-fopenmp gfortran-4.2.orig-HEAD -fopenmp -c -o sub1.o sub1.f gfortran-4.2.orig-HEAD -fopenmp -c -o sub2.o sub2.f gfortran-4.2.orig-HEAD -fopenmp -c -o main.o main.f gfortran-4.2.orig-HEAD sub1.o sub2.o main.o /usr/bin/ld: equk_: TLS reference in sub1.o mismatches non-TLS reference in sub2.o sub2.o: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [all] Error 1 $ gfortran-4.2.orig-HEAD -v Using built-in specs. Target: i686-linux-gnu Configured with: ../../src/gcc-4.2.orig/configure -v --enable-languages=c,c++,fortran,treelang --prefix=/opt/gcc-4.2.orig/ --enable-shared --with-system-zlib --libexecdir=/opt/gcc-4.2.orig/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.2.orig-HEAD --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --disable-libstdcxx-debug --enable-mpfr --disable-werror --enable-checking=release --enable-debug i686-linux-gnu Thread model: posix gcc version 4.2.0 20060930 (experimental) -- Summary: TLS / non-TLS mismatch for COMMON declared in both ways Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rep dot nop at aon dot at GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29308
[Bug testsuite/29307] libiberty/testsuite/test-demangle : parsing errors after unknown demangling style
--- Comment #1 from phil dot lello at homecall dot co dot uk 2006-10-01 14:47 --- btw, I'm currently using the libiberty from binutils, but have reported here as I believe the gcc version is the 'master' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29307
[Bug fortran/27900] ICE using intrinsics as arguments
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-01 15:02 --- I'm about to submit a patch that globally fixes this problem of intrinsics as actual arguments, but this one is still eluding me. It's due to the implicit none statement, and it works otherwise. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2006-06-05 20:33:07 |2006-10-01 15:02:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27900
[Bug fortran/29284] [4.1/4.2 Regression] ICE for optional subroutine argument
--- Comment #4 from rep dot nop at aon dot at 2006-10-01 15:28 ---
Note that i don't think i can approve anything.
This patch fixes the following ICE for me:
http://gcc.gnu.org/ml/fortran/2006-09/msg00460.html
$ cat no.f90
MODULE MOD1
CONTAINS
SUBROUTINE SUB1(arg)
IMPLICIT NONE
CHARACTER (LEN=*), OPTIONAL :: arg
IF (PRESENT(arg)) WRITE(0,*) 'arg was ', arg
STOP
END SUBROUTINE SUB1
SUBROUTINE SUB2
CALL SUB1
END SUBROUTINE SUB2
END MODULE
Used to give before this fix
$ gfortran-4.2-HEAD -c no.f90
no.f90: In function 'sub2':
no.f90:3: internal compiler error: Segmentation fault
And with the fix compiles now as expected.
PS: Just curious..
Why isn't this part of gfc_conv_function_call() coded to check for fsym once
and only then have the additional checks?
if (fsym)
{
CHECKS_NOT_INVOLVING_e;
if (e)
{
CHECK_e_STUFF;
}
}
It doesn't look like the order of most of these is significant since very
different things are checked, so there should be no risk in writing this in a
sleek manner.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29284
[Bug ada/28733] GNAT crash while compiling Ada-2005 code
--- Comment #6 from al at svao dot net 2006-10-01 15:55 --- Created an attachment (id=12366) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12366action=view) ada_3d-system-containers-single_list.adb Yes, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28733
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2006-10-01
16:38 ---
FX,
I found a thread that discusses a simple fix...
http://curl.haxx.se/mail/lib-2004-10/0089.html
All we have to change is...
Index: io/list_read.c
===
--- io/list_read.c (revision 117347)
+++ io/list_read.c (working copy)
@@ -1457,7 +1457,7 @@ check_type (st_parameter_dt *dtp, bt typ
greater than one, we copy the data item multiple times. */
static void
-list_formatted_read_scalar (st_parameter_dt *dtp, bt type, void *p, int kind,
+list_formatted_read_scalar (st_parameter_dt *dtp, volatile bt type, void *p,
int kind,
size_t size)
{
char c;
...to keep type out of a register and the warning goes away! Can you test that
change
on your system?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug c/29309] New: Compiling an assembler-less file generates error from assembler
I'm trying to compile svgalib (http://www.svgalib.org/) on my
FreeBSD/amd64 system.
Although the package uses assembler in a few places, this can be
disabled with the -DNO_ASSEMBLY flag. After the pre-processor
there is no assembler code in the trouble-some C-file, except
for the (unused) definitions of bswap*, which come from system
headers (sys/endian.h).
Both, the system compiler (gcc-3.4.6) and the optional gcc41
give the same error:
{standard input}:30: Error: Incorrect register `%rax' used with `l' suffix
The line number differs depending on the compiler and the
optimization options, but the error is the same, and talks about
the same piece of the gcc-generated assembly:
[...]
#APP
outl %rax,%dx ## -- here
#NO_APP
leave
ret
[...]
Environment:
System: FreeBSD aldan.algebra.com 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Sat
Sep 30 16:33:20 EDT 2006 [EMAIL PROTECTED]:/meow/obj/var/src/sys/SILVER
amd64
host: x86_64-portbld-freebsd6.1
build: x86_64-portbld-freebsd6.1
target: x86_64-portbld-freebsd6.1
configured with: ./..//gcc-4.1-20060623/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/opt --program-suffix=41
--libdir=/opt/lib/gcc/x86_64-portbld-freebsd6.1/4.1.2
--with-gxx-include-dir=/opt/lib/gcc/x86_64-portbld-freebsd6.1/4.1.2/include/c++/
--infodir=/opt/info/gcc41 --disable-libgcj --prefix=/opt
x86_64-portbld-freebsd6.1
How-To-Repeat:
# 1 /var/ports/graphics/svgalib/work/svgalib-1.4.3/src/vgapci.c
# 1 built-in
# 1 command line
# 1 /var/ports/graphics/svgalib/work/svgalib-1.4.3/src/vgapci.c
# 1 /usr/include/stdio.h 1 3 4
# 43 /usr/include/stdio.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 44 /usr/include/stdio.h 2 3 4
# 1 /usr/include/sys/_null.h 1 3 4
# 45 /usr/include/stdio.h 2 3 4
# 1 /usr/include/sys/_types.h 1 3 4
# 33 /usr/include/sys/_types.h 3 4
# 1 /usr/include/machine/_types.h 1 3 4
# 51 /usr/include/machine/_types.h 3 4
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef short __int16_t;
typedef unsigned short __uint16_t;
typedef int __int32_t;
typedef unsigned int __uint32_t;
typedef long __int64_t;
typedef unsigned long __uint64_t;
typedef __int32_t __clock_t;
typedef unsigned int __cpumask_t;
typedef __int64_t __critical_t;
typedef double __double_t;
typedef double __float_t;
typedef __int64_t __intfptr_t;
typedef __int64_t __intmax_t;
typedef __int64_t __intptr_t;
typedef __int32_t __int_fast8_t;
typedef __int32_t __int_fast16_t;
typedef __int32_t __int_fast32_t;
typedef __int64_t __int_fast64_t;
typedef __int8_t __int_least8_t;
typedef __int16_t __int_least16_t;
typedef __int32_t __int_least32_t;
typedef __int64_t __int_least64_t;
typedef __int64_t __ptrdiff_t;
typedef __int64_t __register_t;
typedef __int64_t __segsz_t;
typedef __uint64_t __size_t;
typedef __int64_t __ssize_t;
typedef __int64_t __time_t;
typedef __uint64_t __uintfptr_t;
typedef __uint64_t __uintmax_t;
typedef __uint64_t __uintptr_t;
typedef __uint32_t __uint_fast8_t;
typedef __uint32_t __uint_fast16_t;
typedef __uint32_t __uint_fast32_t;
typedef __uint64_t __uint_fast64_t;
typedef __uint8_t __uint_least8_t;
typedef __uint16_t __uint_least16_t;
typedef __uint32_t __uint_least32_t;
typedef __uint64_t __uint_least64_t;
typedef __uint64_t __u_register_t;
typedef __uint64_t __vm_offset_t;
typedef __int64_t __vm_ooffset_t;
typedef __uint64_t __vm_paddr_t;
typedef __uint64_t __vm_pindex_t;
typedef __uint64_t __vm_size_t;
typedef __builtin_va_list __va_list;
typedef __va_list __gnuc_va_list;
# 34 /usr/include/sys/_types.h 2 3 4
typedef __uint32_t __blksize_t;
typedef __int64_t __blkcnt_t;
typedef __int32_t __clockid_t;
typedef __uint32_t __fflags_t;
typedef __uint64_t __fsblkcnt_t;
typedef __uint64_t __fsfilcnt_t;
typedef __uint32_t __gid_t;
typedef __int64_t __id_t;
typedef __uint32_t __ino_t;
typedef long __key_t;
typedef __int32_t __lwpid_t;
typedef __uint16_t __mode_t;
typedef int __nl_item;
typedef __uint16_t __nlink_t;
typedef __int64_t __off_t;
typedef __int32_t __pid_t;
typedef __int64_t __rlim_t;
typedef __uint8_t __sa_family_t;
typedef __uint32_t __socklen_t;
typedef long __suseconds_t;
typedef __int32_t __timer_t;
typedef __uint32_t __uid_t;
typedef unsigned int __useconds_t;
# 82 /usr/include/sys/_types.h 3 4
typedef int __ct_rune_t;
typedef __ct_rune_t __rune_t;
typedef __ct_rune_t __wchar_t;
typedef __ct_rune_t __wint_t;
typedef __uint32_t __dev_t;
typedef __uint32_t __fixpt_t;
typedef union {
char __mbstate8[128];
__int64_t _mbstateL;
} __mbstate_t;
# 46 /usr/include/stdio.h 2 3 4
typedef __off_t fpos_t;
typedef __size_t size_t;
typedef __va_list va_list;
# 70 /usr/include/stdio.h 3 4
struct __sbuf {
unsigned char *_base;
int _size;
};
struct __sFILEX;
# 102 /usr/include/stdio.h 3 4
typedef
[Bug c/29309] Compiling an assembler-less file generates error from assembler
--- Comment #1 from schwab at suse dot de 2006-10-01 17:23 --- port_outl is broken, long is 64 bits on x86-64. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29309
[Bug c/29309] Compiling an assembler-less file generates error from assembler
--- Comment #2 from mi at aldan dot algebra dot com 2006-10-01 17:46 --- Oh, yes indeed. Sorry... -- mi at aldan dot algebra dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29309
[Bug fortran/29308] TLS / non-TLS mismatch for COMMON declared in both ways
--- Comment #1 from jakub at gcc dot gnu dot org 2006-10-01 18:16 --- That testcase is invalid. See OpenMP 2.5 standard, 2.8.2, which states: If a threadprivate directive specifying a common block name appears in one program unit, then such a directive must also appear in every other program unit that contains a COMMON statement specifying the same name. I don't see a big advantage in silently accepting invalid code. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29308
[Bug c/29309] Compiling an assembler-less file generates error from assembler
--- Comment #3 from mi at aldan dot algebra dot com 2006-10-01 18:17 --- Actually, in any case, should not the error message have referred me to the source of the problem in port_outl's definition in libvga.h? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29309
[Bug bootstrap/29310] New: GCC 4.1.1 fails to bootstrap on a dual G4 Machine (PowerPC 7450 processor)
Hello. Today i tried to bootstrap gcc on my G4 machine (OS X 10.4.8 aka Tiger)
The first stage of bootstrapping finished successfully but at a certain point
gcc spit some errors:
./xgcc -B./ -B/usr/local/powerpc-apple-darwin8/bin/ -isystem
/usr/local/powerpc-apple-darwin8/include -isystem
/usr/local/powerpc-apple-darwin8/sys-include
-L/Volumes/Titanium/build/gcc/../ld -O2 -O2 -O2 -mcpu=7450 -pipe
-fomit-frame-pointer -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include
-Wa,-force_cpusubtype_ALL -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/.
-I../../gcc-4.1.1/gcc/../include -I../../gcc-4.1.1/gcc/../libcpp/include
-fexceptions -fvisibility=hidden -DHIDE_EXPORTS -c
../../gcc-4.1.1/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o
../../gcc-4.1.1/gcc/unwind.inc: In function '_Unwind_RaiseException':
../../gcc-4.1.1/gcc/unwind.inc:140: internal compiler error: in
rs6000_emit_prologue, at config/rs6000/rs6000.c:14092
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
{standard input}:3988:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L010$pb
{standard input}:3988:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3984:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L010$pb
{standard input}:3984:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3870:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L009$pb
{standard input}:3870:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3869:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L009$pb
{standard input}:3869:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3824:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L009$pb
{standard input}:3824:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3757:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L009$pb
{standard input}:3757:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3749:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L009$pb
{standard input}:3749:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3566:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L008$pb
{standard input}:3566:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3562:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L008$pb
{standard input}:3562:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3556:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L008$pb
{standard input}:3556:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3498:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L008$pb
{standard input}:3498:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3490:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L008$pb
{standard input}:3490:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3489:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L008$pb
{standard input}:3489:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3480:non-relocatable subtraction expression,
_once_regsizes.7311 minus L008$pb
{standard input}:3480:symbol: _once_regsizes.7311 can't be undefined in a
subtraction expression
{standard input}:3478:non-relocatable subtraction expression,
_once_regsizes.7311 minus L008$pb
{standard input}:3478:symbol: _once_regsizes.7311 can't be undefined in a
subtraction expression
{standard input}:3352:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L007$pb
{standard input}:3352:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3351:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L007$pb
{standard input}:3351:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3317:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L007$pb
{standard input}:3317:symbol: _dwarf_reg_size_table can't be undefined in a
subtraction expression
{standard input}:3313:non-relocatable subtraction expression,
_dwarf_reg_size_table minus L007$pb
{standard
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #15 from mmitchel at gcc dot gnu dot org 2006-10-01 18:39
---
I cannot see any plausible way to argue that this is a library bug.
Implementation of placement new should not need barriers or other compiler
intrinsics. It's twisted to argue that the C++ standard itself would prevent
implementation of placement new without non-standard facilities, since the
people that wrote the standard all certainly expected the implementation to be
just:
void *operator new(size_t, void *p) {
return p;
}
Variations on that definition also occur in various user-defined new operators,
including those for class-scoped operators. I don't think we can reasonably
ask people to change this code, which works with every other C++ compiler.
Therefore, the only possible conclusion is that either the compiler is buggy or
that the examples are invalid. Unfortunately, I don't think Andrew's example
is invalid.
There are two possible approaches to fixing the compiler: either (a) the C++
front end should mark all new operators as special, in some way that the middle
end then uses to avoid this over-optimization, or (b) relax the aliasing rules
used by the middle end.
I think the right solution is (b). Fundamentally, I'm not sure that the object
models in C and C++ are sufficiently well-defined to permit the kind
of optimization that we are discussing. I also think that people use functions
not named operator new to do the kinds of things being discussed (i.e., to
allocate blocks of memory) and that C and C++ are intended to support that
usage. Certainly, in C, people can't use operator new. So, I'd probably
suggest that we relax the aliasing rules, at least for heap-allocated objects.
As an example of the kind of problems the standard poses, [basic.life] says:
The lifetime of an object is a runtime property of the object. The
lifetime of an object of type T begins when:
--storage with the proper alignment and size for type T is obtained,
and
--if T is a class type with a non-trivial constructor (_class.ctor_),
the constructor call has completed.
The lifetime of an object of type T ends when:
--if T is a class type with a non-trivial destructor (_class.dtor_),
the destructor call starts, or
--the storage which the object occupies is reused or released.
So, by that definition, it might seem that:
int i = 3;
*((float *)(i)) = 7.0;
is valid; we're reusing the int memory, as a float, and it has the right
size and alignment (on most systems). But, that would effectively nullify the
[basic.lval] language that suggests that you can't access an object through a
type other than its dynamic type -- or, at least, it would limit such access to
writes. I don't think anyone would expect the dynamic type of i to be
float in this example, even if someone had written:
new (i) float;
Surely, the dynamic type of something explicitly declared int must be int.
But, for something with dynamic storage duration, perhaps we should assume that
any write to the storage, with a type other than the one that it already has,
forces it to possibly alias things of both types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug driver/29311] New: configure script does not test for GNU Make
Typescript from Solaris 9 using SUNWspro/bin and no GNU tools available (i.e., make comes from that same directory): echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o ./argv.o./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o./fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o./ternary.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o./xstrerror.o ./xstrndup.o required-list make: Fatal error in reader: Makefile, line 51: Unexpected end of line seen Current working directory /usr/share/src/gcc/gcc-4.1.1/_b/fixincludes *** Error code 1 make: Fatal error: Command failed for target `all-fixincludes' Current working directory /usr/share/src/gcc/gcc-4.1.1/_b *** Error code 1 make: Fatal error: Command failed for target `all' The line in question: target_noncanonical:=sparc-sun-solaris2.9 ``:='' ?? If you are going to require GNU make, you *MUST* cause configure to fail and issue such a message. Thanks - Bruce -- Summary: configure script does not test for GNU Make Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkorb at gnu dot org GCC build triplet: *-*-solaris* GCC host triplet: *-*-solaris* GCC target triplet: *-*-solaris* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29311
[Bug target/29201] [4.2 Regression] ICE in create_recovery_block, at haifa-sched.c:3692 at -O3
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2006-10-01 19:03 --- I posted the patch for this bug at: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00023.html -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-01 19:03:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29201
[Bug c/20533] documentation: attribute 'used', applied to a variable
--- Comment #1 from sayle at gcc dot gnu dot org 2006-10-01 19:03 --- Subject: Bug 20533 Author: sayle Date: Sun Oct 1 19:03:24 2006 New Revision: 117349 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117349 Log: 2006-10-01 Ryan Mansfield [EMAIL PROTECTED] PR c/20533 * doc/extend.texi: Add used variable attribute description. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20533
[Bug fortran/29284] [4.1/4.2 Regression] ICE for optional subroutine argument
--- Comment #5 from paulthomas2 at wanadoo dot fr 2006-10-01 19:59 ---
Subject: Re: [4.1/4.2 Regression] ICE for optional subroutine
argument
Dear All,
PS: Just curious..
Why isn't this part of gfc_conv_function_call() coded to check for fsym once
and only then have the additional checks?
if (fsym)
{
CHECKS_NOT_INVOLVING_e;
if (e)
{
CHECK_e_STUFF;
}
}
It doesn't look like the order of most of these is significant since very
different things are checked, so there should be no risk in writing this in a
sleek manner.
...because it grew like Topsy. An occasion was always going to occur,
like now, when it would get rationlised.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29284
[Bug c/20533] documentation: attribute 'used', applied to a variable
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-01 20:15 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20533
[Bug c/29309] Compiling an assembler-less file generates error from assembler
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-01 20:16 --- (In reply to comment #3) Actually, in any case, should not the error message have referred me to the source of the problem in port_outl's definition in libvga.h? How can it, this is inline-asm after all, so the constraints are incorrect just for the instruction you (the code) is using. There is not much GCC can do unless you add all of binutils to GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29309
[Bug bootstrap/29310] GCC 4.1.1 fails to bootstrap on a dual G4 Machine (PowerPC 7450 processor)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-01 20:19 --- This is a dup of bug 25127. The work-around is not to use --with-cpu=7450 or --with-cpu=7400. *** This bug has been marked as a duplicate of 25127 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29310
[Bug target/25127] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-01 20:19 --- *** Bug 29310 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||frunzales at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug bootstrap/29310] GCC 4.1.1 fails to bootstrap on a dual G4 Machine (PowerPC 7450 processor)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-01 20:20 --- Or make sure you don't have -mcpu=7450 in your Cflags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29310
[Bug target/25127] [4.0/4.1/4.2 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-01 20:25 --- Caused by: 2004-08-18 Fariborz Jahanian [EMAIL PROTECTED] * config/rs6000/altivec.md: Add new patterns for calls to save_world/rest_world functions. * config/rs6000/rs6000-protos.h: (save_world_operation, restore_world_operation) new declarations. * config/rs6000/rs6000.c: (struct rs6000_stack) new world_save_p field added. (rs6000_stack_info): Set world_save_p field. (save_world_operation): New function. (restore_world_operation): New function. (compute_save_world_info): New function. (rs6000_stack_info): Call compute_save_world_info. (rs6000_emit_prologue): Check for world_save_p and generate pattern to call save_world for saving all non-volatile and special registers. (rs6000_emit_epilogue): Check for world_save_p and generate pattern to call rest_world to restore saved registers. config/rs6000/rs6000.h: macros FIRST_SAVED_ALTIVEC_REGNO, FIRST_SAVED_FP_REGNO, FIRST_SAVED_GP_REGNO defined. (rs6000_reg_names): New entries added for save_world_operation and restore_world_operation. Which makes this a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Summary|internal compiler error: in |[4.0/4.1/4.2 Regression] |rs6000_emit_prologue, at|internal compiler error: in |config/rs6000/rs6000.c:14039|rs6000_emit_prologue, at ||config/rs6000/rs6000.c:14039 Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug c++/29266] Rule that binding rvalue to a refernce need a copy ctor don't work
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-01 20:33 --- (In reply to comment #3) Plesae seee Comment #2 From Kelvin 2006-09-28 23:25 [reply]. In addition 2 questions I raised in the Commet2. I also have one more question about the rule bind an rvalue to a reference, we need to let copy ctor of the class be accessible., I found that this rule only effective when the reference is delcared as const , but if we remove keyword const, then no matching happen again. Because it will not be a copy constructor that can bind a rvalue to a reference at that point so this is still not a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29266
[Bug c/29309] Compiling an assembler-less file generates error from assembler
--- Comment #5 from mi at aldan dot algebra dot com 2006-10-01 21:31 --- By propagating the `#line' information from the original C-source into the *.S file, maybe? Not sure... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29309
[Bug ada/27936] [4.2 Regression] gnatbind fails to link on Tru64 UNIX
--- Comment #9 from falk at debian dot org 2006-10-01 21:50 --- FWIW, the same problem breaks bootstrap on Alpha Linux: http://buildd.debian.org/fetch.php?pkg=gcc-snapshotver=20060922-1arch=alphastamp=1158945554file=logas=raw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27936
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #12 from jakub at gcc dot gnu dot org 2006-10-01 22:35 --- Wrt #8, can you come up with a C++ testcase where using var = x; is invalid, but using memcpy (var, x, sizeof (var)); (where sizeof (var) == sizeof (x)) makes it valid C++ (from aliasing point of view)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug target/25127] [4.0/4.1/4.2 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug tree-optimization/28230] [4.2 Regression] -O2 -fwrapv miscompiles gcc, binutils, gzip.
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug c/29154] [4.0/4.1/4.2 Regression] *(* ppointer++)++ = *pointer++ generates bad code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29154
[Bug c++/29175] [4.0/4.1/4.2 regression] ICE on invalid: C++ static variable length array
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29175
[Bug objc/29197] [4.0/4.1/4.2 Regression] ICE after error with array type with undefined variable
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29197
[Bug target/29198] [4.0/4.1/4.2 Regression] Incorrect reference to __thread array with -fPIC -O2 on x86
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-10-01 22:59 --- I'm marking this P2, rather than P1, because the use of TLS structures seems a bit of a corner-case. Feel free to lobby to make this a P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29198
[Bug target/29201] [4.2 Regression] ICE in create_recovery_block, at haifa-sched.c:3692 at -O3
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29201
[Bug debug/29202] [4.1/4.2 Regression] ICE with external template and const data in the template
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29202
[Bug fortran/29312] New: Errors in subnormal calculation
Copy of http://gcc.gnu.org/ml/fortran/2006-10/msg9.html With gcc version 4.2.0 20060930 (experimental), gmp 4.2.1, and mpfr 2.2.0, on OSX 10.3.9/G5, the following code real x x = -0.375*tiny(x) end fails with: init2.c:51: assertion failed: p = 2 p = ((mpfr_prec_t)((mpfr_prec_t)(~(mpfr_prec_t)0)1)) test_spacing_red.f90:0: internal compiler error: Abort trap Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Copy of http://gcc.gnu.org/ml/fortran/2006-10/msg00013.html The following code real x, xd, xu x = -3.0*epsilon(x) xd = abs(fraction(x))*set_exponent(real(radix(x), kind=kind(x)), 1+digits(x)) print *, -3.0*epsilon(1.0)-x print *, x, spacing(x), spacing(-3.0*epsilon(1.0)) print *, x, xd, rrspacing(x), rrspacing(-3.0*epsilon(1.0)) end gives 0.00 -3.5762787E-07 2.8421709E-14 5.6843419E-14 -3.5762787E-07 1.2582912E+07 1.2582912E+07 6291456. where the last column of the two last lines computed from spacing(-3.0*epsilon(1.0)) and rrspacing(-3.0*epsilon(1.0)) (hence the 'compile time' in the subject) do not match the values computed through a variable. Copy of http://gcc.gnu.org/ml/fortran/2006-10/msg00014.html The following code real x x = -3.0*(nearest(tiny(x),1.0)-tiny(x)) print *, x end gives 0.00 instead of something like (xlf) -0.4203895393E-44 -- Summary: Errors in subnormal calculation Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: gcc version 4.2.0 20060930 GCC host triplet: PPC OSX 10.3.9 GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29312
[Bug middle-end/29215] [4.0/4.1/4.2 Regression] memcpy is not fully optimized any more
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
[Bug c++/29225] [4.0/4.1/4.2 regression] ICE in gimplify_expr, at gimplify.c:4513
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29225
[Bug c++/29226] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:886
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29226
[Bug middle-end/29241] [4.0/4.1/4.2 Regression] [non unit-at-a-time] ICE with always inline
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29241
[Bug tree-optimization/29254] [4.2 Regression] verify_cgraph_node failed (inlined_to pointer is set but no predecessors found)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
[Bug middle-end/29256] [4.2 regression] loop performance regression
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug fortran/29284] [4.1/4.2 Regression] ICE for optional subroutine argument
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29284
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/29291] [4.2 regression] ICE on invalid use of new
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29291
[Bug fortran/29312] Errors in subnormal calculation
--- Comment #1 from dominiq at lps dot ens dot fr 2006-10-01 23:05 --- Created an attachment (id=12367) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12367action=view) test of NEAREST, SPACING, and RRSPACING The reported errors come from the attached code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29312
[Bug middle-end/29299] [4.2 Regresion] gcc used attribute has no effect on local-scope static variables
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29299
[Bug c/29313] New: [middle-end]Possible bogus warning: argument 'type' might be clobbered
This warning occurs for libgfortran/io/list_read.c (list_formatted_read_scalar)
It can be cleared up using the 'volatile' on the argument 'type' shown here.
'type' is never changed anywhere.
static void
list_formatted_read_scalar (st_parameter_dt *dtp, volatile bt type, void *p,
int kind,
size_t size)
{
char c;
int m;
jmp_buf eof_jump;
dtp-u.p.namelist_mode = 0;
dtp-u.p.eof_jump = eof_jump;
if (setjmp (eof_jump))
{
generate_error (dtp-common, ERROR_END, NULL);
goto cleanup;
}
--- snip ---
--
Summary: [middle-end]Possible bogus warning: argument 'type'
might be clobbered
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jvdelisle at gcc dot gnu dot org
GCC host triplet: linux-ppc, darwin-ppc, linux-x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29313
[Bug c/29313] [middle-end]Possible bogus warning: argument 'type' might be clobbered
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-10-01 23:50 --- From the gfortran list: Reviewing my buildlog of gcc trunk on Darwin PPC, I noticed we have the warning... /sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ -B/sw/li b/gcc4/powerpc-apple-darwin8/lib/ -isystem /sw/lib/gcc4/powerpc-apple-darwin8/include -isystem /sw/lib/gcc4/powerpc-apple-darwin8/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.2-2 0060928/libgfortran -I. -iquote../../../gcc-4.2-20060928/libgfortran/io -I../../../gcc-4.2-20060928/libgfortran/../gcc -I../../../gcc-4.2-20060928/libgfortran/../gcc/config -I../../. /gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 -c ../../../gcc-4.2-20060928/libgfortran/io/lis t_read.c -fno-common -DPIC -o .libs/list_read.o ../../../gcc-4.2-20060928/libgfortran/io/list_read.c: In function 'list_formatted_read_scalar': ../../../gcc-4.2-20060928/libgfortran/io/list_read.c:1460: warning: argument 'type' might be clobbered by 'longjmp' or 'vfork' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29313
[Bug fortran/29312] Errors in subnormal calculation
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-01 23:52 --- I believe the bugs with the various intrinsics are all related. The problem stems from some confusion over the meaning of emin and emax in gfortran, the IEEE 754 standard, and mpfr. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-01 23:52:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29312
[Bug c++/29105] [4.2 Regression] segfault in add_candidates with a non template base class and a template member function
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29105
[Bug target/29314] New: SPARC V9 uses bad FP register for VIS instructions
This code sample generates incorrect code on 64 bit SPARC when compiled -O2
-mvis -mcpu=ultrasparc.
typedef short v16_2_t __attribute__((vector_size(4)));
void vis_mul_block(const v16_2_t * __restrict in1,
const v16_2_t * __restrict in2,
v16_2_t * __restrict out)
{
/* assumes caller set GSR */
out[0] = __builtin_vis_fpackfix(__builtin_vis_fmuld8ulx16(in1[0], in2[0]));
out[1] = __builtin_vis_fpackfix(__builtin_vis_fmuld8ulx16(in1[1], in2[1]));
}
The function body is
ld [%o0+4], %f9
ld [%o1+4], %f11
ld [%o0], %f8
fmuld8ulx16 %f9, %f11, %f9
fmuld8ulx16 %f8, %f10, %f8
fpackfix%f9, %f9
fpackfix%f8, %f8
st %f9, [%o2+4]
jmp %o7+8
st %f8, [%o2]
The compiler does not realize that 64 bit floating point registers are even+odd
pairs of 32 bit floating point registers when the register number is less than
32. Odd numbered 32 bit registers can not be used as 64 bit output registers,
such as the output of fmuld8ulx16.
Perhaps the definition of HARD_REGNO_MODE_OK or HARD_REGNO_NREGS needs revision
for vector-integer types.
--
Summary: SPARC V9 uses bad FP register for VIS instructions
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jfc at mit dot edu
GCC build triplet: sparc64-sun-solaris2.9
GCC host triplet: sparc64-sun-solaris2.9
GCC target triplet: sparc64-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29314
[Bug target/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error
--- Comment #5 from sangsu at gmail dot com 2006-10-02 02:15 --- (In reply to comment #4) Can you attach the preprocessed source as requested by the website: http://gcc.gnu.org/bugs.html what do you mean 'preprocessed source'? do you mean original full source? i cant understand exactly about that... and i even don't know how to attach that... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29281
[Bug target/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-02 02:18 --- Read http://gcc.gnu.org/bugs.html . It should tell you how to do everything we need to be able to reproduce this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29281
[Bug fortran/29315] New: error passing an array derived from struc ture elements
Could you please examine the code below. The code constructs an array of structures, where the structure contains an array of integers. The code then attempts to pass the first element of each structure's array into an array in a subroutine - this step fails. It appears as though the memory locations being accessed to generate the temporary array in the subroutine has an incorrect stride. The stride appears to be 1, instead of the size of the structure. The code appears to run correctly when compiled with SGI and Cray compilers. Results are: Results when compiled with gfc compiler: Original: 1 11 21 Original: 2 12 22 Original: 3 13 23 Original: 4 14 24 Original: 5 15 25 Added 100 to a(1): 101 102 103 Added 100 to a(1): 104 105 22 Added 100 to a(1):3 13 23 Added 100 to a(1):4 14 24 Added 100 to a(1):5 15 25 Results when compiled with SGI compiler, or Cray compiler: Original:1, 11, 21 Original: 2, 12, 22 Original: 3, 13, 23 Original: 4, 14, 24 Original: 5, 15, 25 Added 100 to a(1): 101, 11, 21 Added 100 to a(1): 102, 12, 22 Added 100 to a(1): 103, 13, 23 Added 100 to a(1): 104, 14, 24 Added 100 to a(1): 105, 15, 25 Code is: program test_f90 integer, parameter :: N = 5 type test_type integer a(3) end type type (test_type) s(N) integer i ! s is an array of structures,where the structure contains an array of length 3 do i=1, N s(i)%a(1) = i s(i)%a(2) = i + 10 s(i)%a(3) = i + 20 enddo ! s is initialised as follows: s(1)%a(1) = 1, s(1)%a(2) = 11, s(1)%a(3) = 21 ! s(2)%a(1) = 2, s(2)%a(2) = 12, s(2)%a(3) = 22 ! s(3)%a(1) = 3, s(3)%a(2) = 13, s(3)%a(3) = 23 ! s(4)%a(1) = 4, s(4)%a(2) = 14, s(4)%a(3) = 24 ! s(5)%a(1) = 5, s(5)%a(2) = 15, s(5)%a(3) = 25 do i=1, N write(*, *) 'Original: ', s(i)%a(1), s(i)%a(2), s(i)%a(3) enddo write(*, *) ' ' ! Add an offset to: s(1)%a(1), s(2)%a(1), s(3)%a(1), s(4)%a(1), s(5)%a(1) call test_sub(s%a(1), 100) ! s should now contain: s(1)%a(1) = 101, s(1)%a(2) = 11, s(1)%a(3) = 21 ! s(2)%a(1) = 102, s(2)%a(2) = 12, s(2)%a(3) = 22 ! s(3)%a(1) = 103, s(3)%a(2) = 13, s(3)%a(3) = 23 ! s(4)%a(1) = 104, s(4)%a(2) = 14, s(4)%a(3) = 24 ! s(5)%a(1) = 105, s(5)%a(2) = 15, s(5)%a(3) = 25 do i=1, N write(*, *) 'Added 100 to a(1): ', s(i)%a(1), s(i)%a(2), s(i)%a(3) enddo contains subroutine test_sub(array, offset) integer array(:), offset integer i do i=1, N array(i) = i + offset enddo end subroutine end program -- Summary: error passing an array derived from struc ture elements Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: stephen dot jeffrey at nrm dot qld dot gov dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29315
[Bug fortran/29315] error passing an array derived from struc ture elements
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29315
[Bug fortran/29315] error passing an array derived from type element
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 02:53 --- I know I have seen a bug like this before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29315
[Bug fortran/29315] error passing an array derived from type element
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-02 03:07 --- Confirmed, we don't set the stride correctly as far as I can tell. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-02 03:07:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29315
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2006-10-02 03:10 --- Latest version builds fine and shows no regressions on Darwin PPC at -m32 and -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug target/29281] natPlainDatagramSocketImpl.cc:148: internal compiler error
--- Comment #7 from sangsu at gmail dot com 2006-10-02 03:19 --- (In reply to comment #6) Read http://gcc.gnu.org/bugs.html . It should tell you how to do everything we need to be able to reproduce this bug. this error is occured during linking. it's not occured during compiling. do you want really preprocessed file?? then, the way to produced preprocessed file is ../glibc-2.3.6/configure --target=arm-linux --host=arm-linux --prefix=/usr/local/arm/arm-linux/ --enable-add-ons=linuxthreads --with-headers=/usr/src/linux/include/ -save-temps is it right?? i think that you and i have different way think... because of my poor english... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29281
[Bug c++/29080] [4.0/4.1/4.2 Regression] Multiple-inheritance with template method function code triggers internal compiler error: in build_base_path, at cp/class.c:273
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29080
[Bug c++/29080] [4.0/4.1/4.2 Regression] Multiple-inheritance with template method function code triggers internal compiler error: in build_base_path, at cp/class.c:273
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-10-02 04:12 --- Subject: Bug 29080 Author: mmitchel Date: Mon Oct 2 04:12:30 2006 New Revision: 117360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117360 Log: PR c++/29080 * parser.c (cp_parser_postfix_dot_deref_expression): Use BASELINK_ACCESS_BINFO as the qualifying scope when calling adjust_result_of_qualified_name_lookup. PR c++/29080 * g++.dg/template/member7.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/member7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29080
[Bug c++/29105] [4.2 Regression] segfault in add_candidates with a non template base class and a template member function
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-10-02 04:13 --- Subject: Bug 29105 Author: mmitchel Date: Mon Oct 2 04:12:51 2006 New Revision: 117361 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117361 Log: PR c++/29105 * pt.c (tsubst_baselink): Substituteinto the qualifying scope. * semantics.c (baselink_for_fns): Build a baselink, even when processing a template. PR c++/29105 * g++.dg/template/member6.C: New test. * g++.dg/parse/typename7.C: Adjust error markers. Added: trunk/gcc/testsuite/g++.dg/template/member6.C Modified: trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/g++.dg/parse/typename7.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29105
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2006-10-02 04:15 --- alloc_comps0929.diff tests OK for me on i686-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug c++/29105] [4.2 Regression] segfault in add_candidates with a non template base class and a template member function
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-10-02 04:34 --- Fixed in 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29105
[Bug c++/29226] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:886
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29226
[Bug c++/29080] [4.0/4.1 Regression] Multiple-inheritance with template method function code triggers internal compiler error: in build_base_path, at cp/class.c:273
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-10-02 04:51 --- Subject: Bug 29080 Author: mmitchel Date: Mon Oct 2 04:51:28 2006 New Revision: 117363 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117363 Log: PR c++/29080 * parser.c (cp_parser_postfix_dot_deref_expression): Use BASELINK_ACCESS_BINFO as the qualifying scope when calling adjust_result_of_qualified_name_lookup. PR c++/29080 * g++.dg/template/member7.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/member7.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29080
[Bug c++/29080] [4.0 Regression] Multiple-inheritance with template method function code triggers internal compiler error: in build_base_path, at cp/class.c:273
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1 Regression]|[4.0 Regression] Multiple- |Multiple-inheritance with |inheritance with template |template method function|method function code |code triggers internal |triggers internal compiler |compiler error: in |error: in build_base_path, |build_base_path, at |at cp/class.c:273 |cp/class.c:273 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29080
[Bug bootstrap/29316] New: gcc-4.1.1 fails to bootstrap again
Hello. libstdc++-v3 failed to bootstrap on my dual g4 (PowerPC 7450) machine. No CFLAGS specified. Here are the 'configure' options specified at the command line: Titanium:/Volumes/Titanium/Sources/build andreif$ ../gcc-4.1.1/configure --prefix=/Volumes/Titanium/toolchain -enable-languages=c,c++ --enable-threads=posix --enable-shared --disable-nls --host=powerpc-apple-darwin8.8.0 --build=powerpc-apple-darwin8.8.0 --target=powerpc-apple-darwin8.8.0 I've tried taking a look at config.log after this but there was nothing relevant. I'll try to attach the whole output as an attachement of this bug. -- Summary: gcc-4.1.1 fails to bootstrap again Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: frunzales at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29316
[Bug bootstrap/29316] gcc-4.1.1 fails to bootstrap again
--- Comment #1 from frunzales at gmail dot com 2006-10-02 05:45 --- Created an attachment (id=12368) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12368action=view) libstdc issue Here's the log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29316
[Bug bootstrap/29316] gcc-4.1.1 fails to bootstrap again
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-02 05:57 --- Use --disable-multilib as ppc-darwin is configured by default to also build the 64bit libraries. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29316
