[Bug middle-end/33581] OpenMP segmentation fault

[spollmann at gmail dot com]

--- Comment #4 from spollmann at gmail dot com  2007-09-29 07:04 ---
(In reply to comment #3)
> What happens if you don't use -static?

if static is not used (and the LD_LIBRARY_PATH points to the correct location
;)
the program seems to execute correctly.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33581

[Bug middle-end/33581] OpenMP segmentation fault

[spollmann at gmail dot com]

--- Comment #5 from spollmann at gmail dot com  2007-09-29 07:10 ---
(In reply to comment #4)
> (In reply to comment #3)
> > What happens if you don't use -static?
> if static is not used (and the LD_LIBRARY_PATH points to the correct location
> ;)
> the program seems to execute correctly.

I didn't think that -static was causing the problem since the application seems
to execute correctly with the -m32 option removed, and with the -static
remaining.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33581

[Bug fortran/33354] [4.2 only] MINLOC in combination with SUM gives wrong result

[tobi at gcc dot gnu dot org]

--- Comment #4 from tobi at gcc dot gnu dot org  2007-09-29 07:57 ---
Subject: Bug 33354

Author: tobi
Date: Sat Sep 29 07:57:37 2007
New Revision: 128882

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128882
Log:
PR fortran/33354
* gfortran.dg/minmaxloc_4.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/minmaxloc_4.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33354

[Bug fortran/33354] [4.2 only] MINLOC in combination with SUM gives wrong result

[tobi at gcc dot gnu dot org]

--- Comment #5 from tobi at gcc dot gnu dot org  2007-09-29 08:00 ---
I added a testcase for this.  Can this bug be closed or does anyone feel
strongly enough about it to fix it in 4.2?


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tobi at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33354

[Bug target/33587] New: INIT_SECTION_ASM_OP defined twice in tm.texi

[kai-gcc-bugs at khms dot westfalen dot de]

Line 6399:

@defmac INIT_SECTION_ASM_OP
If defined, a C expression whose value is a string, including spacing,
containing the assembler operation to identify the following data as
initialization code.  If not defined, GCC will assume such a section does
not exist.  This section has no corresponding @code{init_section}
variable; it is used entirely in runtime code.
@end defmac

Line 7755:

@defmac INIT_SECTION_ASM_OP
If defined, a C string constant, including spacing, for the assembler
operation to identify the following data as initialization code.  If not
defined, GCC will assume such a section does not exist.  When you are
using special sections for initialization and termination functions, this
macro also controls how @file{crtstuff.c} and @file{libgcc2.c} arrange to
run the initialization functions.
@end defmac


-- 
   Summary: INIT_SECTION_ASM_OP defined twice in tm.texi
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kai-gcc-bugs at khms dot westfalen dot de
 GCC build triplet: n/a
  GCC host triplet: n/a
GCC target triplet: n/a


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33587

[Bug target/33587] INIT_SECTION_ASM_OP defined twice in tm.texi

[kai-gcc-bugs at khms dot westfalen dot de]

--- Comment #1 from kai-gcc-bugs at khms dot westfalen dot de  2007-09-29 
08:35 ---
Forgot to mention, this is revision 127595.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33587

[Bug fortran/33566] fortran : wrong rank of derived type parameters array components

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2007-09-29 08:48 ---
(In reply to comment #1)

This causes one regression - data_components_1.f90. I either have to check if
the reference is not constant or to try to simplify the expression and see if
the result is constant.

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33566

[Bug middle-end/33581] OpenMP segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-09-29 08:50 ---
(In reply to comment #5)
> I didn't think that -static was causing the problem since the application 
> seems
> to execute correctly with the -m32 option removed, and with the -static
> remaining.

glibc is slightly different between the 32bit version and the 64bit version.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33581

[Bug fortran/33566] fortran : wrong rank of derived type parameters array components

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2007-09-29 09:21 ---
(In reply to comment #2)

I take that back - I had to copy the patch by hand and, inevitably, got it
wrong.

I'll regtest over again and then submit it.

Je te remercie, Mikael!

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33566

[Bug fortran/33566] fortran : wrong rank of derived type parameters array components

[patchapp at dberlin dot org]

--- Comment #4 from patchapp at dberlin dot org  2007-09-29 09:40 ---
Subject: Bug number PR33566

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/2007-09/msg02054.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33566

[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-09-29 12:45 ---
libgfortran in general assumes that a full C99 runtime is available.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583

[Bug fortran/33584] FAIL: gfortran.dg/integer_exponentiation_4.f90 -O (internal compiler error)

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-09-29 12:48 ---
GNU MP: Cannot reallocate memory (old_size=4 new_size=268435472)

this looks like a GMP bug, not a GCC bug [GCC doesn't even use GMP, only
MPFR which is used does].

What's your GMP version?  Try updating to the latest-and-greatest here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33584

[Bug fortran/33354] [4.2 only] MINLOC in combination with SUM gives wrong result

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2007-09-29 13:12 ---
(In reply to comment #5)
> I added a testcase for this.

Thanks!

> Can this bug be closed or does anyone feel
> strongly enough about it to fix it in 4.2?

If we can identify which patch fixed this, I'd be in favor
of backporting (even though we'll miss 4.2.2).

Thomas


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33354

[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2007-09-29 
16:15 ---
Subject: Re:  FAIL: gfortran.dg/gamma_1.f90

> libgfortran in general assumes that a full C99 runtime is available.

lgamma and lgamma_r are available, so it should be possible to fudge
a f version.  This is done for some other functions.

I suspect that this has something to do with mpfr as HP-UX 11 doesn't
have lgammaf and I'm not seeing the fail there.  I updated mpfr from
2.2.1 to 2.3.0 last night, and started a new build.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583

[Bug c++/33588] New: gcc warns of (char*) conversion on client-side varargs funcs

[stephan at s11n dot net]

(i submitted this via gccbugs, but the script gave me no feedback about whether
the report was actually sent or not, so i'm re-posting here.)

gcc 4.2.1 appears to incorrectly(?) give a warning when a client-written
varargs func is passed a string literal (e.g. __FILE__) as one of the
arguments. e.g.

my_func( "format string: %s", __FILE__ )

warning: deprecated conversion from string constant to ‘char'

Curiously, the warning is not emitted when printf() is used.

This apparently bogus warning causes -Werror builds (that is, all of my builds)
to fail.

i will attach a demo file after saving this bug (assuming bugzilla lets me,
otherwise i'll paste it in as a comment).


-- 
   Summary: gcc warns of (char*) conversion on client-side varargs
funcs
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stephan at s11n dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33588

[Bug c++/33588] gcc warns of (char*) conversion on client-side varargs funcs

[stephan at s11n dot net]

--- Comment #1 from stephan at s11n dot net  2007-09-29 16:31 ---
Created an attachment (id=14266)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14266&action=view)
Demonstrates the problem.

Demonstrates this seeming bug, including the discrepancy between client-defined
varargs funcs and built-ins. Compile with: gcc gcc-421-charptr.cpp -lstdc++


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33588

[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2007-09-29 
16:47 ---
Subject: Re:  FAIL: gfortran.dg/gamma_1.f90

> Subject: Re:  FAIL: gfortran.dg/gamma_1.f90
> 
> > libgfortran in general assumes that a full C99 runtime is available.

It was the fortran frontend that generated the call to lgammaf.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583

[Bug ada/32299] 4.3-20070608 gnat bug detected in gimplify_addr_expr, at gimplify.c:3919

[oliver dot kellogg at eads dot com]

--- Comment #1 from oliver dot kellogg at eads dot com  2007-09-29 17:10 
---
No longer crashes for me using r128881 (4.3.0 20070929)


-- 

oliver dot kellogg at eads dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32299

[Bug c++/33589] New: [4.3 regression] ICE on valid code at -O2: verify_flow_info failed

[a dot chavasse at gmail dot com]

g++43 -v output:

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --program-suffix=43 --disable-multilib
--enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20070929 (experimental) (GCC)

Built from svn trunk, revision 128885


Compiling this with -O2 or -O3 fails with the following message:

verify_flow_info_failed.cpp: In function 'void somefunction()':
verify_flow_info_failed.cpp:29: error: BB 2 last statement has incorrectly set
region
verify_flow_info_failed.cpp:29: internal compiler error: verify_flow_info
failed


struct base
{
void somemethod() {}
};

struct derived : public base
{
};

struct smartpointer
{
~smartpointer()
{
}

operator derived*() const
{
return 0;
}
};

typedef void ( derived::* methodptr_type )();

methodptr_type getmemberptr()
{
return &derived::somemethod;
}

void somefunction()
{
smartpointer pObj;
( pObj->*getmemberptr() )();
}


-- 
   Summary: [4.3 regression] ICE on valid code at -O2:
verify_flow_info failed
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a dot chavasse at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33589

[Bug c++/33588] gcc warns of (char*) conversion on client-side varargs funcs

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-09-29 18:04 ---
va_list on the target you are using just happens to be a char* and not a
seperate type.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33588

[Bug c++/33590] New: c++ crash in KDE's qca module

[dancecile at gmail dot com]

Running c++ on Kubuntu Fiesty Fawn, with gcc version 4.1.2 (Ubuntu
4.1.2-0ubuntu4).

c++ crashes while processes the file, saying "c++: Internal error: Killed
(program cc1plus)"

The command is:
/usr/bin/c++ -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align
-Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security
-fno-check-new -fno-common -O3 -DNDEBUG
-I/home/kde-devel/kde/build/kdesupport/qca/unittest/cipherunittest
-I/home/kde-devel/kde/src/kdesupport/qca/unittest/cipherunittest
-I/home/kde-devel/kde/src/kdesupport/qca/include/QtCrypto
-I/home/kde-devel/qt-copy/include -I/home/kde-devel/qt-copy/include/Qt
-I/home/kde-devel/qt-copy/mkspecs/default
-I/home/kde-devel/qt-copy/include/QtCore
-I/home/kde-devel/qt-copy/include/QtGui
-I/home/kde-devel/qt-copy/include/Qt3Support
-I/home/kde-devel/qt-copy/include/QtAssistant
-I/home/kde-devel/qt-copy/include/QtDesigner
-I/home/kde-devel/qt-copy/include/QtNetwork
-I/home/kde-devel/qt-copy/include/QtOpenGL
-I/home/kde-devel/qt-copy/include/QtSql -I/home/kde-devel/qt-copy/include/QtXml
-I/home/kde-devel/qt-copy/include/QtSvg
-I/home/kde-devel/qt-copy/include/QtUiTools
-I/home/kde-devel/qt-copy/include/QtTest   -D_BSD_SOURCE
-DQCA_SYSTEMSTORE_PATH="\"/etc/ssl/certs/ca-certificates.crt\"" -o
qca/unittest/cipherunittest/CMakeFiles/cipherunittest.dir/cipherunittest.o -c
/home/kde-devel/kde/src/kdesupport/qca/unittest/cipherunittest/cipherunittest.cpp

The debug messages when running with "-v -save-temps" is:
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
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
 /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -E -quiet -v
-I/home/kde-devel/kde/build/kdesupport/qca/unittest/cipherunittest
-I/home/kde-devel/kde/src/kdesupport/qca/unittest/cipherunittest
-I/home/kde-devel/kde/src/kdesupport/qca/include/QtCrypto
-I/home/kde-devel/qt-copy/include -I/home/kde-devel/qt-copy/include/Qt
-I/home/kde-devel/qt-copy/mkspecs/default
-I/home/kde-devel/qt-copy/include/QtCore
-I/home/kde-devel/qt-copy/include/QtGui
-I/home/kde-devel/qt-copy/include/Qt3Support
-I/home/kde-devel/qt-copy/include/QtAssistant
-I/home/kde-devel/qt-copy/include/QtDesigner
-I/home/kde-devel/qt-copy/include/QtNetwork
-I/home/kde-devel/qt-copy/include/QtOpenGL
-I/home/kde-devel/qt-copy/include/QtSql -I/home/kde-devel/qt-copy/include/QtXml
-I/home/kde-devel/qt-copy/include/QtSvg
-I/home/kde-devel/qt-copy/include/QtUiTools
-I/home/kde-devel/qt-copy/include/QtTest -D_GNU_SOURCE -DNDEBUG -D_BSD_SOURCE
-DQCA_SYSTEMSTORE_PATH="/etc/ssl/certs/ca-certificates.crt"
/home/kde-devel/kde/src/kdesupport/qca/unittest/cipherunittest/cipherunittest.cpp
-mtune=generic -ansi -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align
-Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security
-fno-check-new -fno-common -O3 -fpch-preprocess -o cipherunittest.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /home/kde-devel/kde/build/kdesupport/qca/unittest/cipherunittest
 /home/kde-devel/kde/src/kdesupport/qca/unittest/cipherunittest
 /home/kde-devel/kde/src/kdesupport/qca/include/QtCrypto
 /home/kde-devel/qt-copy/include
 /home/kde-devel/qt-copy/include/Qt
 /home/kde-devel/qt-copy/mkspecs/default
 /home/kde-devel/qt-copy/include/QtCore
 /home/kde-devel/qt-copy/include/QtGui
 /home/kde-devel/qt-copy/include/Qt3Support
 /home/kde-devel/qt-copy/include/QtAssistant
 /home/kde-devel/qt-copy/include/QtDesigner
 /home/kde-devel/qt-copy/include/QtNetwork
 /home/kde-devel/qt-copy/include/QtOpenGL
 /home/kde-devel/qt-copy/include/QtSql
 /home/kde-devel/qt-copy/include/QtXml
 /home/kde-devel/qt-copy/include/QtSvg
 /home/kde-devel/qt-copy/include/QtUiTools
 /home/kde-devel/qt-copy/include/QtTest
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/i486-linux-gnu
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.1.2/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -fpreprocessed cipherunittest.ii
-quiet -dumpbase cipherunittest.cpp -mtune=generic -ansi -auxbase-strip
qca/unittest/cipherunittest/CMakeFiles/cipherunittest.dir/cipherunittest.o -O3
-Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall
-W -Wpointer-arith -Wwrite-strings -

[Bug libmudflap/33591] New: mudflap gives warnings exceeding bounds on valid code, when using readdir(2) on large directories

[edwintorok at gmail dot com]

When reading entries of a directory with readdir() on a directory 
containing many files, mudflap gives warning about out-of-bound writes.

mudflap.c: MF_VALIDATE_EXTENT (p, sizeof (*p), __MF_CHECK_WRITE, "readdir
result");

mudflap checks that the entire struct dirent is writable, however the size of
struct dirent is undefined (according to the manpage).

I think it should only check that d_reclen bytes are accessible, instead of the
entire structure.

Bug initially discovered on directory with 76000 entries, reproduced on
directory with 1000 entries.

I have run the test on a reiserfs filesystem, but it can also be
reproduced by creating a directory with 1000 entries on a tmpfs filesystem
mounted on /tmp

Steps to reproduce:

$ mkdir test/
$ for i in `seq 1 1000`; do touch test/$i; done
$ gcc  -fmudflap mudflap_readdir.i -lmudflap -o mudflap_readdir
$ ./mudflap_readdir test/ 2>error_log
$ grep ^\  error_log|sort -u
  /lib/libc.so.6 [0x3dfd295d89]
  /lib/libc.so.6(opendir+0x58) [0x3dfd295e58]
  ./mudflap_readdir(main+0xc9) [0x400a11]
  /usr/lib/libmudflap.so.0(__mf_check+0x41) [0x2b7f247ffdb1]
  /usr/lib/libmudflap.so.0(__mf_register+0x41) [0x2b7f247ff8e1]
  /usr/lib/libmudflap.so.0(__mfwrap_readdir+0x91) [0x2b7f24804b91]
  /usr/lib/libmudflap.so.0(__wrap_malloc+0xdd) [0x2b7f24800b8d]

Snippet of error_log:

***
mudflap violation 1 (check/write): time=1191088752.714610 ptr=0x7043c8 size=280
pc=0x2b7f247ffdb1 location=`(readdir result)'
  /usr/lib/libmudflap.so.0(__mf_check+0x41) [0x2b7f247ffdb1]
  /usr/lib/libmudflap.so.0(__mfwrap_readdir+0x91) [0x2b7f24804b91]
  ./mudflap_readdir(main+0xc9) [0x400a11]
Nearby object 1: checked region begins 3896B into and ends 24B after
mudflap object 0x7044f0: name=`malloc region'
bounds=[0x703490,0x7044c7] size=4152 area=heap check=0r/163w liveness=163
alloc time=1191088752.713885 pc=0x2b7f247ff8e1
  /usr/lib/libmudflap.so.0(__mf_register+0x41) [0x2b7f247ff8e1]
  /usr/lib/libmudflap.so.0(__wrap_malloc+0xdd) [0x2b7f24800b8d]
  /lib/libc.so.6 [0x3dfd295d89]
  /lib/libc.so.6(opendir+0x58) [0x3dfd295e58]
number of nearby objects: 1
***


Environment:
$ uname -a
Linux lightspeed2 2.6.23-rc8-hrt1-cfs-v22-g1bef7dc0-dirty #16 Sat Sep 29 
15:54:22 EEST 2007 x86_64 GNU/Linux

$ cat /etc/debian_version
lenny/sid

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-werror
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.1 (Debian 4.2.1-5)

$ mount|grep /home
/dev/mapper/main-home on /home type reiserfs (rw,noatime,notail)

$ mount|grep tmp
tmpfs on /tmp type tmpfs (rw,nosuid,mode=1777)


-- 
   Summary: mudflap gives warnings exceeding bounds on valid code,
when using readdir(2) on large directories
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33591

[Bug libmudflap/33591] mudflap gives warnings exceeding bounds on valid code, when using readdir(2) on large directories

[edwintorok at gmail dot com]

--- Comment #1 from edwintorok at gmail dot com  2007-09-29 18:10 ---
Created an attachment (id=14267)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14267&action=view)
preprocessed C program to reproduce bug


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33591

[Bug c++/33590] c++ crash in KDE's qca module

[dancecile at gmail dot com]

--- Comment #1 from dancecile at gmail dot com  2007-09-29 18:35 ---
Created an attachment (id=14268)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14268&action=view)
"the preprocessed file (*.i*) that triggers the bug"

Here's the .ii file that was generated (uncompressed 1.8 MB, too big to attach)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33590

[Bug target/33592] New: FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/test/gnu/gcc/gcc/gcc/testsui
te/gfortran.dg/array_constructor_11.f90   -O0   -pedantic-errors 
-L/test/gnu/gc
c/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-h
p-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./lib
iberty  -lm   -o ./array_constructor_11.exe(timeout = 300)
PASS: gfortran.dg/array_constructor_11.f90  -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfort
ran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu
/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/
test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir
/gcc
Operating system error: Not a typewriter
Out of memory
FAIL: gfortran.dg/array_constructor_11.f90  -O0  execution test

Simplified test:

! Like array_constructor_6.f90, but check iterators with non-default stride,
! including combinations which lead to zero-length vectors.
! { dg-do run }
program main
  implicit none
  call build (77)
contains
  subroutine build (order)
integer :: order, i, j

! Triggers compile-time iterator calculations in trans-array.c
call test (1, 0, 3,  (/ (i, i = 1, 0, 3),  (i, i = order, 0, 1) /))
  end subroutine build

  subroutine test (from, to, step, values)
integer, dimension (:) :: values
integer :: from, to, step, last, i

last = 0
do i = from, to, step
  last = last + 1
  if (values (last) .ne. i) call abort
end do
if (size (values, dim = 1) .ne. last) call abort
  end subroutine test
end program main


-- 
   Summary: FAIL: gfortran.dg/array_constructor_11.f90  -O1
execution test
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa*-*-hpux*
  GCC host triplet: hppa*-*-hpux*
GCC target triplet: hppa*-*-hpux*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33592

[Bug target/33592] FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-09-29 19:00 ---
Operating system error: Not a typewriter
Out of memory

uhm, this doesn't make too much sense.  Can you debug this?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33592

[Bug c++/33590] c++ crash in KDE's qca module

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-09-29 19:01 ---
c++: Internal error: Killed (program cc1plus)

something killed g++, likely your system ran out of memory.  Consult output
of 'dmesg'.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33590

[Bug treelang/33593] New: tree-outof-ssa moves sources of non-call exceptions past sequence points

[rsandifo at gcc dot gnu dot org]

tree-outof-ssa can move potentially-trapping operations across what were
sequence points, even when compiled with -fnon-call-exceptions.  E.g.,
consider the following C++ code, compiled with -fnon-call-exceptions:


#include 

void foo (int) { printf ("Bar\n"); }

int
main (void)
{
  int a = 1 / 0;
  printf ("Foo\n");
  foo (a);
}


The tree optimisers themselves preserve the intent of the code,
but tree-outof-ssa.c propogates the division into the call to foo():


int main() ()
{
:
  __builtin_puts (&"Foo"[0]);
  foo (1 / 0);
  return 0;

}


So the unoptimised program behaves as expected, raising the divide-by-zero
trap before printing "Foo".  The optimised version prints "Foo" first.


-- 
   Summary: tree-outof-ssa moves sources of non-call exceptions past
sequence points
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: treelang
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33593

[Bug tree-optimization/33593] tree-outof-ssa moves sources of non-call exceptions past sequence points

[rsandifo at gcc dot gnu dot org]

--- Comment #1 from rsandifo at gcc dot gnu dot org  2007-09-29 19:05 
---
Assigning to Diego as he already has a patch (thanks!)


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dnovillo at google dot com
   |dot org |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33593

[Bug middle-end/33589] [4.3 regression] ICE on valid code at -O2: verify_flow_info failed

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-09-29 19:05 ---
Confirmed.  Happens after final_cleanup of the following function:

;; Function void somefunction() (_Z12somefunctionv)

void somefunction() ()
{
  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  somemethod (0B);
  goto ;
  # SUCC: 3 (ab,eh,exec) 4 [100.0%]  (fallthru,exec)

  # BLOCK 3
  # PRED: 2 (ab,eh,exec)
:;
  <<>> = <<>>;
  <<>> = <<>>;
  resx 1;
  # SUCC:

  # BLOCK 4 freq:1
  # PRED: 2 [100.0%]  (fallthru,exec)
  return;
  # SUCC: EXIT [100.0%]

}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c++ |middle-end
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-29 19:05:05
   date||
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33589

[Bug tree-optimization/33593] tree-outof-ssa moves sources of non-call exceptions past sequence points

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-09-29 19:05 ---
1 / 0;

that does not aways trap.  on ppc an undefined value is returned.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33593

[Bug tree-optimization/33593] tree-outof-ssa moves sources of non-call exceptions past sequence points

[dnovillo at google dot com]

--- Comment #3 from dnovillo at google dot com  2007-09-29 19:08 ---
Subject: Re:  tree-outof-ssa moves sources of non-call exceptions past sequence
points

On 29 Sep 2007 19:05:20 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:

> 1 / 0;
>
> that does not aways trap.  on ppc an undefined value is returned.

In which case tree_could_trap_p() will/should return false on this
expression then.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33593

[Bug tree-optimization/33593] tree-outof-ssa moves sources of non-call exceptions past sequence points

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-09-29 19:08 ---
I think 1/0 should not be marked as throwing though as it is target dependent
if it actually will trap or not.  In fact as I mentioned on PPC, it does not
trap.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33593

[Bug c++/33590] c++ crash in KDE's qca module

[dancecile at gmail dot com]

--- Comment #3 from dancecile at gmail dot com  2007-09-29 19:33 ---
wow, thanks :) dmesg was full of low memory stuff, and it turns out my swap
wasn't mounted so thanks for pointing this out quick.

i ran the compile again and it worked ok. looking at my memory consumption, i
saw that cc1plus was using _about_ 330 MB of memory. this seems like a kinda
strange amount of memory used, so i just want to double-check its not a bug.


-- 

dancecile at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33590

[Bug c/33594] New: Local (stack) arrays not aligned on word boundaries

[amruth dot laxman at nsn dot com]

gcc version: 4.2.1 (also occurs with versions as early as 4.0.2)
configured with: ../gcc-4.2.1/configure --enable-languages=c,c++

With gcc 4.x, local variable arrays declared on the stack are no longer aligned
at word boundaries. For example:

void somefunc()
{
...
  char buf[100];
...
}

In gcc 3.x, buf would be aligned on a word boundary. With gcc 4.x, the
alignment assigned is that of the underlying type - in this case 1-byte for
char array.  

The cause of the change in alignment seems to be the following:
- gcc 4.x allocates stack in cfgexpand.c, function expand_one_stack_var()
- this calls get_decl_align_unit(), also in cfgexpand.c
- the alignment is then read using macro DECL_ALIGN, which returns the
alignment of the type
- a further revision is made using macro LOCAL_ALIGNMENT
- however, LOCAL_ALIGNMENT is not defined for the sparc architecture (in
gcc/config/sparc.h), causing the alignment to remain as default

In contrast, gcc 3.4.6 seems to allocate stack in function.c,
assign_stack_local_1(), which does not use the alignment macros

Why this is a problem:
- on the sparc platform, a cast from a stack allocated buffer to a structure
pointer fails due to the new alignment. Although such code is inherently
non-portable, there is a lot of it out there which used to work with the 3.x
family.
- there is also a small performance loss from accessing unaligned structures.
This is seen in software that receives data from external sources (a socket for
example) into a stack buffer.

Suggested modification:
- add a LOCAL_ALIGNMENT macro for sparc and align arrays on word-boundaries, as
was done before

See Also:
- bug id 22605 reported against gcc 4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22605


-- 
   Summary: Local (stack) arrays not aligned on word boundaries
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amruth dot laxman at nsn dot com
 GCC build triplet: sparc-sun-solaris2.10
  GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594

[Bug c/33594] Local (stack) arrays not aligned on word boundaries

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-09-29 20:03 ---
As you say, you cannot rely on alignment > 1 for an array of char.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594

[Bug middle-end/22605] Alignment of struct on stack is no longer the maxium alignment

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-09-29 20:06 ---
As of comment #2 this is a possible enhancement for non -Os (or stack saving
mode) on STRICT_ALIGNMENT targets.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|minor   |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2007-09-29 20:06:29
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22605

[Bug c/33594] Local (stack) arrays not aligned on word boundaries

[amruth dot laxman at nsn dot com]

--- Comment #2 from amruth dot laxman at nsn dot com  2007-09-29 20:12 
---
Two questions:
- why change the behavior of gcc from 3.x to 4.x?
- is there any harm in adding alignment for arrays? If not, can we make this an
enhancement request?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594

[Bug target/33592] FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2007-09-29 20:18 ---
realloc is called with a NULL pointer and 0 size.
realloc (0, 0) returns NULL.  This causes _gfortran_os_error
to get called and the above error to get printed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33592

[Bug c/33594] Local (stack) arrays not aligned on word boundaries

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-09-29 20:40 ---
You should able to use the attribute aligned to get what you want.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594

[Bug middle-end/22605] Alignment of struct on stack is no longer the maxium alignment

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-09-29 20:42 ---
if you want aligned arrays use attribute aligned.  Now GCC should automatically
doing it for non -Os/stack saving mode for optimization reasons but other than
that, you cannot depend on the alignment.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22605

[Bug fortran/33375] ICE (segfault) gfortran.dg/common_6.f90

[danglin at gcc dot gnu dot org]

--- Comment #3 from danglin at gcc dot gnu dot org  2007-09-29 20:42 ---
Also occurs on hppa64-hp-hpux11.11.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375

[Bug fortran/33595] New: FAIL: gfortran.dg/nint_2.f90 -O0 execution test

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/nint_2.f90   -O0   -pedantic-errors
 -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libiberty  -lm   -o ./nint_2.exe  
 (timeout = 300)
PASS: gfortran.dg/nint_2.f90  -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/gcc

FAIL: gfortran.dg/nint_2.f90  -O0  execution test

30if (j1 /= 0 .or. j2 /= 0) call abort
(gdb)

Program received signal SIGABRT, Aborted.
0xc01fa3dc in ?? ()
(gdb) p j1
$1 = 1
(gdb) p j2
$2 = 0
(gdb) p b
$3 = 0.4997


-- 
   Summary: FAIL: gfortran.dg/nint_2.f90  -O0  execution test
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa*-*-hpux*
  GCC host triplet: hppa*-*-hpux*
GCC target triplet: hppa*-*-hpux*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33595

[Bug fortran/33596] New: ICE on ppc-darwin with ISNAN

[fxcoudert at gcc dot gnu dot org]

$ cat o1.f90 
print *, isnan (0.)
end
$ gfortran o1.f90 
o1.f90: In function 'MAIN__':
o1.f90:1: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6830

The backtrace is:

#0  fancy_abort (file=0x81818c "../../trunk/gcc/expr.c", line=6830,
function=0x818638 "expand_expr_addr_expr_1") at
../../trunk/gcc/diagnostic.c:660
#1  0x00276774 in expand_expr_addr_expr_1 (exp=0x4264ac60, target=0x0,
tmode=SImode, modifier=EXPAND_NORMAL) at ../../trunk/gcc/expr.c:6830
#2  0x00276418 in expand_expr_addr_expr_1 (exp=0x4260f360, target=0x0,
tmode=SImode, modifier=EXPAND_NORMAL) at ../../trunk/gcc/expr.c:6756
#3  0x0026f614 in expand_expr_real_1 (exp=0x4264ac80, target=0x0, tmode=SImode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../trunk/gcc/expr.c:6892
#4  0x00271698 in expand_expr_real (exp=0x4264ac80, target=0x0, tmode=VOIDmode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../trunk/gcc/expr.c:7088
#5  0x0038b0c4 in expand_call (exp=0x42605540, target=0x0, ignore=0) at
../../trunk/gcc/expr.h:520
#6  0x00262b28 in expand_expr_real_1 (exp=0x42605540, target=0x4260c400,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../trunk/gcc/expr.c:8048
#7  0x00271664 in expand_expr_real (exp=0x42605540, target=0x4260c400,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../trunk/gcc/expr.c:7082
#8  0x00556ac8 in expand_expr_stmt (exp=0x42605540) at
../../trunk/gcc/expr.h:514
#9  0x0058a6b0 in expand_gimple_basic_block (bb=0x42605780) at
../../trunk/gcc/cfgexpand.c:1606
#10 0x0058b2ac in tree_expand_cfg () at ../../trunk/gcc/cfgexpand.c:1913


-- 
   Summary: ICE on ppc-darwin with ISNAN
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin8.10.0
  GCC host triplet: powerpc-apple-darwin8.10.0
GCC target triplet: powerpc-apple-darwin8.10.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33596

[Bug fortran/33596] ICE on ppc-darwin with ISNAN

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-29 21:58:56
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33596

[Bug libffi/28313] libffi has not been ported to mips64-linux-gnu

[daney at gcc dot gnu dot org]

-- 

daney at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28313

[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c

[daney at gcc dot gnu dot org]

-- 

daney at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437

[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3

[daney at gcc dot gnu dot org]

-- 

daney at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406

[Bug c/33597] New: Internal compiler error while compiling libswcale from ffmpeg

[ismail at pardus dot org dot tr]

Specs:

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr/lib/gcc-snapshot --disable-libgcj
--disable-libssp --disable-nls --disable-werror --disable-checking
--enable-clocale=gnu --enable-__cxa_atexit
--enable-languages=c,c++,fortran,objc --enable-libstdcxx-allocator=new
--enable-shared --enable-ssp --enable-threads=posix
--enable-version-specific-runtime-libs --without-included-gettext
--without-system-libunwind --with-system-zlib
Thread model: posix
gcc version 4.3.0 20070928 (experimental) (GCC)


And internal compiler error :

[/packages/mplayer/libswscale]> cc  -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I.. -I../libavutil
-Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -I.
-I.. -I../libavutil -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4
-march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
-DHAVE_CONFIG_H -I/usr/include/  -I/usr/include/SDL  -D_REENTRANT 
-I/usr/include/freetype2 -I/usr/include  -c -o rgb2rgb.o rgb2rgb.c
rgb2rgb_template.c: In function 'rgb15to24_C':
rgb2rgb_template.c:936: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

rgb2rgb.s is attached.


-- 
   Summary: Internal compiler error while compiling libswcale from
ffmpeg
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ismail at pardus dot org dot tr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597

[Bug c/33597] Internal compiler error while compiling libswcale from ffmpeg

[ismail at pardus dot org dot tr]

--- Comment #1 from ismail at pardus dot org dot tr  2007-09-29 22:58 
---
Created an attachment (id=14269)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14269&action=view)
rgb2rgb.s produced with -save-temps


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597

[Bug middle-end/33597] Internal compiler error while compiling libswcale from ffmpeg

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-09-29 22:59 ---
The .i file is important and not the .s file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597

[Bug middle-end/33597] Internal compiler error while compiling libswcale from ffmpeg

[ismail at pardus dot org dot tr]

--- Comment #3 from ismail at pardus dot org dot tr  2007-09-29 23:03 
---
Created an attachment (id=14270)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14270&action=view)
Corresponding *.i file


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597

[Bug libfortran/32841] [4.3 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8

[fxcoudert at gcc dot gnu dot org]

--- Comment #24 from fxcoudert at gcc dot gnu dot org  2007-09-29 23:15 
---
First, I should note that this doesn't affect real kinds 4 and 8, due to
Jerry's per-kind I/O change; this bug now only shows up for real(kind=16).
Second, this is a problem with huge(0._16) not being equal to LDBL_MAX, see
http://gcc.gnu.org/ml/fortran/2007-09/msg00461.html for details.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jvdelisle at gcc dot gnu dot|fxcoudert at gcc dot gnu dot
   |org |org
Summary|[4.3 regression] HUGE(1.0d0)|[4.3 regression]
   |output as +Infinity on ppc- |HUGE(1.0_16) output as
   |darwin8 |+Infinity on ppc-darwin8


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841

[Bug libfortran/32841] [4.3 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8

[fxcoudert at gcc dot gnu dot org]

--- Comment #25 from fxcoudert at gcc dot gnu dot org  2007-09-29 23:20 
---
I should have posted my reduced testcase, so that I don't lose it:

real(16) :: y
y=huge(y)
write(*,"(G60.50E4)") y
write(*,"(G60.50E4)") nearest(y,1.)
end


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841

[Bug libfortran/33253] namelist: reading back a string with apostrophe

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2007-09-30 01:58 
---
It turns out that the original patch for this bug is probably what we want. 
Unfortunately it uncovers a nasty latent bug where an extraneous namelist read
is attempted.  It only seems to occur with multiple levels of derived types. 
For example:

&MYNML
 x(2)%m(1)%ch(2) ='q', ,
&end

Will read correctly with the initial patch for the bug here if the extra comma
is placed at the end.  This is a bugger since it involves both recursive calls
and incrementing of loop specs all within a do - while loop.

Still working on it. :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33253

[Bug c/33598] New: gcc 4.2.1 ignores GNU LD in Solaris 9

[dhaliK at jla dot rutgers dot edu]

We recently upgraded to 4.2.1 and noticed an immediate issue. After compiling
gcc for sparcv9 and specifically setting --with-ld=/usr/local/gnu/bin/ld,
whenever gcc actually runs it internally calls the Sun linker and therefore
dies with unknown options. A simple "hello world" refuses to build because of
bad LD options. Setting LD= seems to have little effect. I'm pasting a -v
output of it below. Note I was using g++ here because that was handy, but it is
the same for eitehr gcc or g++:

/usr/local/bin/sparcv9/g++ -v hello.cpp   
Using built-in specs.
Target: sparc-sun-solaris2.9
Configured with: ../configure --enable-shared --enable-threads
--with-ld=/usr/local/gnu/bin/ld --with-as=/usr/local/gnu/bin/as
--disable-multilib --disable-libgcj --disable-libffi --disable-libjava
--disable-nls --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9
Thread model: posix
gcc version 4.2.1
 /usr/local/libexec/gcc/sparc-sun-solaris2.9/4.2.1/cc1plus -quiet -v
-D__sparcv8 hello.cpp -quiet -dumpbase hello.cpp -mcpu=v9 -auxbase hello
-version -o /var/tmp//ccM6WkGY.s
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../sparc-sun-solaris2.9/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../include/c++/4.2.1

/usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../include/c++/4.2.1/sparc-sun-solaris2.9

/usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../include/c++/4.2.1/backward
 /usr/local/include
 /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/include
 /usr/include
End of search list.
GNU C++ version 4.2.1 (sparc-sun-solaris2.9)
compiled by GNU C version 4.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7f9cd0c7cc891b25f4cbce210dc67670
 /usr/local/gnu/bin/as -V -Qy -s -xarch=v8plus -o /var/tmp//ccZD9lJS.o
/var/tmp//ccM6WkGY.s
GNU assembler version 2.17 (sparc-sun-solaris2.9) using BFD version 2.17
 /usr/local/libexec/gcc/sparc-sun-solaris2.9/4.2.1/collect2 -V -Y
P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy
/usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crt1.o
/usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crti.o
/usr/ccs/lib/values-Xa.o
/usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crtbegin.o
-L/usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1 -L/usr/ccs/lib
-L/usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/../../..
/var/tmp//ccZD9lJS.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc
/usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crtend.o
/usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.390
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status


-- 
   Summary: gcc 4.2.1 ignores GNU LD in Solaris 9
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dhaliK at jla dot rutgers dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598

[Bug c/33594] Local (stack) arrays not aligned on word boundaries

[amruth dot laxman at nsn dot com]

--- Comment #4 from amruth dot laxman at nsn dot com  2007-09-29 23:58 
---
You're right - I can use aligned, but I will have to search through 100,000+
lines of code to find all the places that character arrays are used and then
add the aligned directive. A lot of this code is open-source or vendor-supplied
that we build and use. Not a fun task...

Any chance of the enhancement request?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594

[Bug c++/33094] [4.2/4.3 Regression] ICE on valid C++ virtual template static member in anonymous namespace

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2007-09-30 02:41 ---
Subject: Bug 33094

Author: jason
Date: Sun Sep 30 02:41:39 2007
New Revision: 128890

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128890
Log:
PR c++/33094
* decl.c (make_rtl_for_nonlocal_decl): It's ok for a member
constant to not have DECL_EXTERNAL if it's file-local.

Added:
trunk/gcc/testsuite/g++.dg/ext/visibility/anon6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33094