[Bug fortran/37961] [F2003] random_seed - allow integer(8) for the arguments
--- Comment #3 from burnus at gcc dot gnu dot org 2008-10-31 06:44 --- INVALID - only default integers are allowed -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37961
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #33 from bonzini at gnu dot org 2008-10-31 06:52 --- Since the problem is that libintl.h can't be found No, the problem is that INCINTL is not set correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug fortran/37961] [F2003] random_seed - allow integer(8) for the arguments
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2008-10-31 06:57 --- Subject: Re: [F2003] random_seed - allow integer(8) for the arguments On Fri, Oct 31, 2008 at 06:44:07AM -, burnus at gcc dot gnu dot org wrote: INVALID - only default integers are allowed Tobias, thanks. In reviewing my previous post, the post may have appeared confrontational. That was completely unintention. I was just trying to convey what the various standards say. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37961
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #21 from burnus at gcc dot gnu dot org 2008-10-31 07:41 --- (In reply to comment #17) Adw_xabcd_8(1:n) = transfer(-1,1.0) ! Adw_xabcd_8 is REAL That makes sense: One assigns NaN to a real variable (though a comment would be helpful). Does this mean gfortran shouldn't give an error message on the first part (with the real variable) of the bug report? Assigning should be definitely OK: NaN is a valid REAL number (if one allows IEEE). NaN lies outside the floating-point model of Fortran, but it is not different from if(IEEE_SUPPORT_NAN(x)) x = IEEE_VALUE(x, IEEE_QUIET_NAN) The question is whether real8_number = transfer(-1, 0.0_4) ! real(4) - real(8) or real :: NaN = IEEE_VALUE(x, IEEE_QUIET_NAN) ! OK y = NaN * 5 ! Valid? are valid or not. The problem with the validity is that Fortran has a numerical model which does not allow for NaN, INF, and sub-/de-normal numbers, but Fortran 2003 has also IEEE support, which is not closer described, and (if supported by the hardware/compiler) the IEEE part of Fortran 2003 allows for NaN, +/-INF and denormal numbers (but it does not make clear when). One can argue that a NaN real(4)-real(8) conversion is OK or that it is invalid - I think one can find arguments for both; in any case NaN can be unambiguously converted from one real/complex to another real/complex kind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug ada/37977] New: System.Address size stays 64 bit with -m31
Ada currently doesn't bootstrap on s390x due to a pointer size mismatch when building the 32 bit version of a-except.o: /build2/gcc-build/./gcc/xgcc -B/build2/gcc-build/./gcc/ -B/build2/gcc-install/s390x-ibm-linux-gn u/bin/ -B/build2/gcc-install/s390x-ibm-linux-gnu/lib/ -isystem /build2/gcc-install/s390x-ibm-linux-gnu/include -isystem /build2/gcc-install/s390x-ibm-linux-gnu/sys-include -c -g -O2 -fPIC -mlong-double-128 -W -Wall -gnatpg -m31 -g -O1 -fn o-inline -fno-toplevel-reorder a-except.adb -o a-except.o -fdump-tree-all -gnatf a-exexpr.adb:169:04: warning: types for unchecked conversion have different sizes a-exexpr.adb:169:04: warning: size of Address is 64, size of Gnat_Gcc_Exception_Access is 32 a-exexpr.adb:169:04: warning: 32 trailing bits of source will be ignored in directory: gcc-build/gcc/ada/rts_32 -- Summary: System.Address size stays 64 bit with -m31 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: krebbel at gcc dot gnu dot org GCC build triplet: s390x-ibm-linux GCC host triplet: s390x-ibm-linux GCC target triplet: s390x-ibm-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37977
[Bug ada/37977] System.Address size stays 64 bit with -m31
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-10-31 08:42 --- You need to add multilib support for s390 to gcc-interface/Makefile.in, see for example SPARC/Solaris. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-31 08:42:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37977
[Bug ada/37977] Missing ada multilib support for s390x
--- Comment #2 from krebbel at gcc dot gnu dot org 2008-10-31 09:11 --- Ok. I'm bootstrapping a patch which mimics what has been done for Power. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |krebbel at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-10-31 08:42:53 |2008-10-31 09:11:34 date|| Summary|System.Address size stays 64|Missing ada multilib support |bit with -m31 |for s390x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37977
[Bug bootstrap/37915] bootstrap broken for cygwin
--- Comment #2 from mikpe at it dot uu dot se 2008-10-31 10:03 ---
(In reply to comment #1)
I rebuilt my toolchains with binutils-2.19 + three fixes and now
gcc-4.4-20081024 builds fine for me with --enable-languages=c,c++.
The three addon fixes in my binutils-2.19 are:
1. http://sourceware.org/ml/binutils-cvs/2008-10/msg00050.html
Backport pointers aren't long on Win64 fix from upstream.
2. http://sourceware.org/ml/binutils-cvs/2008-10/msg00112.html
Backport ld -r bug on Win64 (PR6945) fix from upstream.
3. Local multilib patches so i686-{cygwin,mingw32} binutils can process 64-bit
object files, and x86_64-mingw32 binutils can process 32-bit object files.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #6 from tsyvarev at ispras dot ru 2008-10-31 10:48 ---
(In reply to comment #2)
Maybe now I see, what's behind your report: you believe that, when val is set,
eofbit should be set only when seeking another character to match. But that
would essentially boil down to *never* set it, in that case, because val is
set
only when a target sequence is uniquely matched, thus we don't look beyond the
last matched character.
I suppose there is a situations when eofbit is set:
Assume, sequence is fals. Because fals is prefix of false, do_get()
should try to obtained character after 's', but it found, that (in==end). So it
should set err to (failbit | eofbit).
Here is an example of a situation when this difference between standard and
current implementation may be significant.
Consider the stream, in which operation (in == end) will block process until a
character is available. So, comparision (in == end) always returns false, until
stream is forced to close.
For example, assume the stream is connected to terminal. So if the stream is
depleted but the program performs the comparison (in == end), current process
will be blocked until the user inputs another character.
For the prompt Are you sure to perform this operation? it is sufficient for
the user to input {'y', 'e', 's'} and program will interpret this as
affirmative answer.
But for current implementation user should input {'y', 'e', 's', enter},
because after reading yes do_get() performs the comparison (in == end) to
verify whether eofbit should be set in err. But this call will block program
until the user inputs another character, which does not affect the
interpretation of the user's answer, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug c++/37962] [4.4 regression] ICE with (auto*) casts
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-31 11:26 ---
Testcase that covers more cases which should be rejected:
#include typeinfo
int i = *(auto *) 0;// { dg-error }
struct A *p = (auto *) 0;// { dg-error }
int *q = static_castauto *(0);// { dg-error }
const int *r = const_castauto *(q);// { dg-error }
const std::type_info t1 = typeid (auto);// { dg-error }
const std::type_info t2 = typeid (auto *);// { dg-error }
struct A
{
operator auto ();// { dg-error }
operator auto * ();// { dg-error }
};
void
foo ()
{
(auto) { 0 };// { dg-error }
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
[Bug c++/37964] [4.4 regression] ICE with operator auto
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-31 11:27 --- *** This bug has been marked as a duplicate of 37962 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37964
[Bug c++/37962] [4.4 regression] ICE with (auto*) casts
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-31 11:27 --- *** Bug 37964 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
[Bug bootstrap/37978] installation duplicates
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-31 11:29 --- These are hardlinks. -- 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=37978
[Bug c++/37972] static variables of template class not emitted if no initializer given
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-31 11:36 --- Because you instantiate Baseint which is not a specialization yet. Then you define foo for a specialization which is not instantiated. You want template typename T int BaseT::foo; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37972
[Bug c++/37971] [4.2/4.3/4.4 Regression] Rejects default argument that is a template via access failure
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-31 11:38 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2008-10-31 11:38:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37971
[Bug c/37975] Incorrect argument checking for printf: format not a string literal, argument types not checked, where it can be checked
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-31 11:40 --- The format string is not a string literal. A flow-insensitive warning cannot be reliably given. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||diagnostic Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37975
[Bug regression/37976] ICE in insert_into_preds_of_block
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-31 11:42 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37976
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #4 from tsyvarev at ispras dot ru 2008-10-31 10:34 --- Created an attachment (id=16595) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16595action=view) Test, modelling example from standard exactly (For targets true: 1 and false: 0, the input sequence 1 yields val == true and err == str.goodbit) Output the same: [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ test.cpp ./a.out eofbit was set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug c++/37962] [4.4 regression] ICE with (auto*) casts
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-31 11:27 --- *** Bug 37963 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
[Bug c/37979] New: GCC Overlooks Logical Operation Optimizations ?
gcc looks like it's omitting a simple optimization which can be done on logical
operations.
/* Command line and output on a linux host */
[EMAIL PROTECTED]:~$ gcc -o test test.c -Os ls -l test
-rwxr-xr-x 1 engin engin 6461 2008-10-31 12:26 test
[EMAIL PROTECTED]:~$ gcc -o test test.c -Os -DHAND_OPTIMIZED ls -l test
-rwxr-xr-x 1 engin engin 6365 2008-10-31 12:26 test
[EMAIL PROTECTED]:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7
/* Command line and ouput on cygwin */
[EMAIL PROTECTED] /cygdrive/c/Users/Engin/Code/mmc
$ gcc -o test test.c -Os ls -l test
-rwxr-xr-x 1 Engin None 9068 Oct 31 13:42 test
[EMAIL PROTECTED] /cygdrive/c/Users/Engin/Code/mmc
$ gcc -o test test.c -Os -DHAND_OPTIMIZED ls -l test
-rwxr-xr-x 1 Engin None 8556 Oct 31 13:43 test
[EMAIL PROTECTED] /cygdrive/c/Users/Engin/Code/mmc
$ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure
--verbose --prefix=/usr --exec-pref
ix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share
/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls
--without-included-gettext --enable-ver
sion-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt
--with-system-zlib --enable-interpre
ter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm
--disable-win32-registry --enable-sjl
j-exceptions --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
/* CODE **/
volatile int* foo = (volatile int*)0x23232322;
int
main(void)
{
int a, b, c, d, e, f, g, h, z = 0;
a = *foo;
b = *foo;
c = *foo;
d = *foo;
e = *foo;
f = *foo;
g = *foo;
h = *foo;
#ifndef HAND_OPTIMIZED
if (
(f c b a) ||
(f e d a) ||
(f e h a) ||
(g c b a) ||
(g e d a) ||
(g e h a)
)
#else
if ((f||g) a ( (bc) || ((d||h) e)))
#endif
{
z= a + b + c;
h=12;
d= h + b + c;
e=45;
}
e=z*2+d+a;
*foo = e;
while(1)
{
*foo = e;
}
}
--
Summary: GCC Overlooks Logical Operation Optimizations ?
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: engin at bzzzt dot biz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37979
[Bug c++/37963] [4.4 regression] ICE with (auto) cast
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-31 11:27 --- *** This bug has been marked as a duplicate of 37962 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37963
[Bug c++/37966] [4.4 regression] ICE with ptr-to-mem-fun-returning-auto
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-31 11:28 --- Again, auto in cast expressions is ill-formed. *** This bug has been marked as a duplicate of 37962 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37966
[Bug c++/37962] [4.4 regression] ICE with (auto*) casts
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-31 11:28 --- *** Bug 37966 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
[Bug tree-optimization/37969] [4.3 Regression] -O2 -funswitch-loops causes ICE in build_int_cst_wide, at tree.c:891 (OpenOffice.org)
--- Comment #7 from h dot mth at web dot de 2008-10-31 10:43 ---
Created an attachment (id=16596)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16596action=view)
more reduced testcase
With one of these changes the ICE hides.
[EMAIL PROTECTED]:/tmp $ cat hide01
--- b3dgeom.3.cpp.ice 2008-10-31 11:38:37.0 +0100
+++ b3dgeom.3.cpp 2008-10-31 11:38:46.0 +0100
@@ -1,7 +1,7 @@
#include iostream
class B3DRange {
double mnMinimum;
- double mnMaximum;
+// double mnMaximum;
public:
double getWidth() const {
if(mnMinimum)
[EMAIL PROTECTED]:/tmp $ cat hide02
--- b3dgeom.3.cpp.ice 2008-10-31 11:38:37.0 +0100
+++ b3dgeom.3.cpp 2008-10-31 11:39:02.0 +0100
@@ -4,7 +4,7 @@
double mnMaximum;
public:
double getWidth() const {
- if(mnMinimum)
+ if(!mnMinimum)
return mnMinimum;
else
return 0.0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
[Bug bootstrap/37978] New: installation duplicates
When bootstrapping and installing from scratch gcc I always find duplicate files instead of symbolic links in bindir (but i find symbolic links in libdir): [EMAIL PROTECTED]:~/local/gcc-4.3.2/bin ll total 5952 -rwxr-xr-x 4 marco users 593797 2008-09-01 10:55 c++ -rwxr-xr-x 1 marco users 591729 2008-09-01 10:55 cpp -rwxr-xr-x 4 marco users 593797 2008-09-01 10:55 g++ -rwxr-xr-x 3 marco users 585690 2008-09-01 10:55 gcc -rwxr-xr-x 1 marco users 15967 2008-09-01 10:55 gccbug -rwxr-xr-x 1 marco users 108380 2008-09-01 10:55 gcov -rwxr-xr-x 2 marco users 594685 2008-09-01 10:55 gfortran -rwxr-xr-x 4 marco users 593797 2008-09-01 10:55 x86_64-unknown-linux-gnu-c++ -rwxr-xr-x 4 marco users 593797 2008-09-01 10:55 x86_64-unknown-linux-gnu-g++ -rwxr-xr-x 3 marco users 585690 2008-09-01 10:55 x86_64-unknown-linux-gnu-gcc -rwxr-xr-x 3 marco users 585690 2008-09-01 10:55 x86_64-unknown-linux-gnu-gcc-4.3.2 -rwxr-xr-x 2 marco users 594685 2008-09-01 10:55 x86_64-unknown-linux-gnu-gfortran My build/install procedure is: mkdir Build cd Build ../configure --enable-threads=posix --prefix=/home/marco/local/gcc-4.3.2 --enable-languages=c,c++,fortran --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --with-cpu=opteron make bootstrap make install Apologize if this has already been reported, or if it is due to an error on my side. -- Summary: installation duplicates Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: morandini at aero dot polimi dot it 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=37978
[Bug tree-optimization/37969] [4.3 Regression] -O2 -funswitch-loops causes ICE in build_int_cst_wide, at tree.c:891 (OpenOffice.org)
--- Comment #8 from h dot mth at web dot de 2008-10-31 10:55 ---
To hide the ICE from reduced testcase:
$ diff -u b3dgeom.3.cpp.orig b3dgeom.3.cpp
--- b3dgeom.3.cpp.orig 2008-10-31 11:52:10.0 +0100
+++ b3dgeom.3.cpp 2008-10-31 11:52:46.0 +0100
@@ -41,9 +41,9 @@
}
typename Traits::DifferenceType getRange() const {
if(isEmpty())
- return Traits::neutral();
- else
return (mnMaximum - mnMinimum);
+ else
+ return Traits::neutral();
}
};
struct DoubleTraits {
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #5 from paolo dot carlini at oracle dot com 2008-10-31 10:36 --- Ok, thanks. I'm on it, patch forthcoming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug c++/37962] [4.4 regression] ICE with (auto*) casts
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-31 10:59 ---
Certainly e.g. cp_parser_cast_expression and cp_parser_postfix_expression
could reject types with type_uses_auto, but doesn't [dcl.spec.auto] specify
only very limited number of places where auto can be used and the rest:
A program that uses auto in a context not explicitly allowed in this section
is ill-formed.?
Enumerating all the places which parse types and auto isn't explicitly allowed
would be IMHO difficult, wouldn't it be better to add a new flag (say to
enum cp_parser_flags, CP_PARSER_FLAGS_AUTO_ALLOWED) and pass it down to
cp_parser_type_specifier*? Guess we might still need a type_uses_auto check
in a couple of places, but it will be certainly less than if we parse auto all
the time and let all the callers check for it.
E.g. ATM g++ parses without any errors:
#include typeinfo
const std::type_info foo ()
{
return typeid (auto);
}
const std::type_info bar ()
{
return typeid (auto *);
}
and returns _ZTIT_ and _ZTIPT_, which looks wrong.
BTW, seems a lot of cp_parser_type_specifier* callers still think the flags
argument is boolean and pass /*is_condition=*/false or /*is_condition=*/true to
it.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||dodji at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
[Bug regression/37976] [4.4 Regression] ICE in insert_into_preds_of_block
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-31 12:18 ---
Reduced testcase:
void percent_x(int ch, char *p, char* ok_chars)
{
char *cp = ch == 'a' ? p : ;
for (;*(cp += __builtin_strspn (cp, ok_chars));)
;
}
__builtin_strspn is partially redundant for cp == (it's zero). The
zero is of wrong type becaue fold_builtin_strspn returns integer_zero_node
instead of size_zero_node.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2008-10-31 12:18:07
date||
Summary|ICE in |[4.4 Regression] ICE in
|insert_into_preds_of_block |insert_into_preds_of_block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37976
[Bug middle-end/37979] GCC Overlooks Logical Operation Optimizations ?
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-31 12:24 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-10-31 12:24:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37979
[Bug regression/37976] [4.4 Regression] ICE in insert_into_preds_of_block
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-31 12:18 --- Mine. More functions need audit. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-10-31 12:18:07 |2008-10-31 12:18:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37976
[Bug middle-end/37976] [4.4 Regression] ICE in insert_into_preds_of_block
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|regression |middle-end Known to work||4.3.2 Priority|P3 |P2 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37976
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #22 from dominiq at lps dot ens dot fr 2008-10-31 12:52 --- One can argue that a NaN real(4)-real(8) conversion is OK or that it is invalid - I think one can find arguments for both; in any case NaN can be unambiguously converted from one real/complex to another real/complex kind. I disagree with the last sentence since there in not a single (or dual if you take into account signaling NaN's) NaN entity, but a whole class of them. So if you accept the conversion, it should be defined: for instance, for REAL(4)-REAL(8) copy the mantissa to the upper/lower bits of the mantissa, or fold all of them to a zero mantissa but for the LSB, ... . I have never read anything about the reasons for having such a wide class of NaN's nor seen any use of it (even the use of quiet/signaling NaN's is quite fuzzy in most compiler implementation). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug c++/37965] [4.4 regression] ICE with invalid auto variable in template
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg01350.html Status|NEW |ASSIGNED Last reconfirmed|2008-10-30 21:00:18 |2008-10-31 13:01:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37965
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #23 from burnus at gcc dot gnu dot org 2008-10-31 13:10 --- in any case NaN can be unambiguously converted from one real/complex to another real/complex kind. I disagree with the last sentence since there in not a single (or dual if you take into account signaling NaN's) NaN entity, but a whole class of them. Still IEEE 754-2008 defines what a signalling/quiet NaN is; with regards to a programmer, NaN is NaN and the exact bit pattern should not matter; and for qNaN and sNaN - if you don't have IEEE trapping turned on, you effectively have a quiet NaN in either case. Independent of the bit pattern x /= x is always true if x is NaN and if x is NaN, y = x*5 will assign NaN to y. Thus I don't see any ambiguity. I have never read anything about the reasons for having such a wide class of NaN's nor seen any use of it (even the use of quiet/signaling NaN's is quite fuzzy in most compiler implementation). Interestingly, IEEE 754-1985 did not specify qNaN vs. sNaN but only NaN (contrary to hardware, which supports both since a long time). With the new IEEE 754-2008 both are defined and there is also more about the bit pattern. See: IEEE section at http://gcc.gnu.org/wiki/GFortranStandards (especially the last item if your place does not have an IEEE subscription). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug target/37909] internal compiler error: in fixup_mova, at config/sh/sh.c:3756
--- Comment #8 from kkojima at gcc dot gnu dot org 2008-10-31 13:24 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37909
[Bug c++/19159] [4.2/4.3/4.4 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Comment #42 from bill dot oliver at sas dot com 2008-10-31 13:30 --- I saw Dave C's post. I am also using 4.0.0 on AIX, and seeing this problem. I'm attempting to build Firebird SQL open source. What recommendation do you have for using g++ on AIX? Should I go back to an earlier version, or where has this problem been resolved? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #10 from ro at techfak dot uni-bielefeld dot de 2008-10-31 13:27 --- Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX Since native reghunting was so slow, I've finally switched to trying with a cross compiler (from Solaris 10/x86), and could reproduce the problem. It even turned out that there are two separate breakages involved. The first is caused by this change: 2008-04-01 Jan Hubicka [EMAIL PROTECTED] * function.c (free_after_compilation): Free epilogue_delay_list. (prepare_function_start): Assert that previous compilation was freed. Since that change, the first gcc_assert() in prepare_function_start() triggers: Breakpoint 1, fancy_abort (file=0x8919114 /vol/gcc/src/gcc-reghunt/gcc/function.c, line=3940, function=0x89196cc prepare_function_start) at /vol/gcc/src/gcc-reghunt/gcc/diagnostic.c:654 (gdb) where #0 fancy_abort (file=0x8919114 /vol/gcc/src/gcc-reghunt/gcc/function.c, line=3940, function=0x89196cc prepare_function_start) at /vol/gcc/src/gcc-reghunt/gcc/diagnostic.c:654 #1 0x08424619 in prepare_function_start () at /vol/gcc/src/gcc-reghunt/gcc/function.c:3940 #2 0x08424746 in init_function_start (subr=0xfee57620) at /vol/gcc/src/gcc-reghunt/gcc/function.c:3988 #3 0x085c711e in tree_rest_of_compilation (fndecl=0xfee57620) at /vol/gcc/src/gcc-reghunt/gcc/tree-optimize.c:408 #4 0x08783ec9 in cgraph_expand_function (node=0xfedbef3c) at /vol/gcc/src/gcc-reghunt/gcc/cgraphunit.c:1157 #5 0x0878573a in cgraph_optimize () at /vol/gcc/src/gcc-reghunt/gcc/cgraphunit.c:1220 #6 0x0816255f in cp_write_global_declarations () at /vol/gcc/src/gcc-reghunt/gcc/cp/decl2.c:3471 #7 0x0855617e in compile_file () at /vol/gcc/src/gcc-reghunt/gcc/toplev.c:971 #8 0x08557b7c in do_compile () at /vol/gcc/src/gcc-reghunt/gcc/toplev.c:2161 #9 0x08557be2 in toplev_main (argc=2, argv=0x80476f8) at /vol/gcc/src/gcc-reghunt/gcc/toplev.c:2193 #10 0x0828565f in main (argc=2, argv=0x80476f8) at /vol/gcc/src/gcc-reghunt/gcc/main.c:35 Later, the following change 2008-04-03 Jan Hubicka [EMAIL PROTECTED] PR tree-optimization/35795 * alpha/alpha.c (alpha_output_mi_thunk_osf): Free after compilation. * sparc/sparc.c (sparc_output_mi_thunk): Likewise. * ia64/ia64.c (ia64_output_mi_thunk): Likewise. * m68k/m68k.c (m68k_output_mi_thunk): Likewise. * score/score3.c (score3_output_mi_thunk): Likewise. * score/score7.c (score7_output_mi_thunk): Likewise. * mips/mips.c (mips_output_mi_thunk): Likewise. broke it even more and introduced the SEGV described in the original PR. If I disable the gcc_assert() and remove the free_after_compilation() at the end of alpha_output_mi_thunk_osf(), I'm finally able to compile my minimized testcase and bootstrap mainline on alpha-dec-osf5.1b. Since your two changes introduced this breakage and it is easily reproducible in a cross compiler, could you please investigate and fix this? Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[resend][stl] std::vector::data - nonstandard method.
Hi, today i've occasionally wrote importable code :]
std::vector::data() is absent in some other (standard conformant?) STLs.
Would be a good idea to rename data() or change specifier (- protected?).
g++ -v:
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured
with: /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--disable-altivec --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror
--enable-secureplt --enable-multilib --enable-libmudflap
--disable-libssp --enable-cld --disable-libgcj
--enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2
p1.0'
Thanks!
// source example:
#include vector
#include algorithm
#include functional
#include iostream
void f()
{
std::vectorint v(1);
std::cout
// vvv
v.data() // nonstandard method (compiles, works)
//
std::endl;
}
int main()
{
f();
}
signature.asc
Description: PGP signature
[mudflap] __mf_strlen + nl_langinfo false positive
Sample session: (sources are below)
$ make
g++ main.o -g -O0 -fmudflapth -lmudflapth -pthread -o bug
$ LANG=C ./bug
***
mudflap violation 1 (check/read): time=1225460499.358020 ptr=0x7fe182d90300
size=15
pc=0x7fe183996779 location=`(strlen region)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/libmudflapth.so.0(__mf_check+0x59)
[0x7fe183996779]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/libmudflapth.so.0(__mfwrap_strlen+0x87)
[0x7fe183999017]
./bug(main+0x2e) [0x400aaa]
number of nearby objects: 0
ANSI_X3.4-1968[14]
Thanks!
--
sources:
// $ cat main.cpp
#include langinfo.h
#include string.h
#include locale.h
#include stdio.h
int main ()
{
setlocale (LC_ALL, );
char * codeset = nl_langinfo (CODESET);
printf (%s[%u]\n, codeset, (unsigned)strlen (codeset));
fflush (stdout); //mudflap goes crazy here too
return 0;
}
#make:
TARGET = bug
CXXFLAGS = -g -O0 -fmudflapth -lmudflapth -pthread
all: $(TARGET)
$(TARGET): main.o
$(CXX) $^ $(CXXFLAGS) -o $@ $(LIBS)
clean:
@rm $(TARGET)
---
g++ -v:
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured
with: /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--disable-altivec --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror
--enable-secureplt --enable-multilib --enable-libmudflap
--disable-libssp --enable-cld --disable-libgcj
--enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2
p1.0'
signature.asc
Description: PGP signature
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #24 from sgk at troutmask dot apl dot washington dot edu 2008-10-31 14:37 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Fri, Oct 31, 2008 at 01:10:21PM -, burnus at gcc dot gnu dot org wrote: --- Comment #23 from burnus at gcc dot gnu dot org 2008-10-31 13:10 --- in any case NaN can be unambiguously converted from one real/complex to another real/complex kind. I disagree with the last sentence since there in not a single (or dual if you take into account signaling NaN's) NaN entity, but a whole class of them. Still IEEE 754-2008 defines what a signalling/quiet NaN is; with regards to a programmer, NaN is NaN and the exact bit pattern should not matter; and for qNaN and sNaN - if you don't have IEEE trapping turned on, you effectively have a quiet NaN in either case. Independent of the bit pattern x /= x is always true if x is NaN and if x is NaN, y = x*5 will assign NaN to y. Thus I don't see any ambiguity. First, gfortran (especially the constant folding) doesn't follow IEEE754 for NaN. AFAIK, there is no distinction between qNaN and sNaN. That being said, from Draft 1.2.5 of the revised standard, section 8.2.3 states: Conversion of a quiet NaN to a floating-point format of the same or a different radix that does not allow the payload to be preserved, should return a quiet NaN that should provide some language-defined diagnostic information. It appears that gfortran's error message is providing some language-defined diagnostic information. I'll also note that the diagnostic information tells you how to disable the range checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/35820] internal compiler error with nested FORALL
--- Comment #10 from mikael at gcc dot gnu dot org 2008-10-31 15:38 --- Subject: Bug 35820 Author: mikael Date: Fri Oct 31 15:37:17 2008 New Revision: 141496 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141496 Log: 2008-10-31 Mikael Morin [EMAIL PROTECTED] PR fortran/35820 * resolve.c (gfc_count_forall_iterators): New function. (gfc_resolve_forall): Use gfc_count_forall_iterators to evaluate the needed memory amount to allocate. Don't forget to free allocated memory. Add an assertion to check for memory leaks. 2008-10-16 Mikael Morin [EMAIL PROTECTED] PR fortran/35820 * gfortran.dg/nested_forall_1.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/nested_forall_1.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35820
[Bug fortran/35840] ICE for character expression in I/O specifier
--- Comment #19 from mikael at gcc dot gnu dot org 2008-10-31 15:57 --- Subject: Bug 35840 Author: mikael Date: Fri Oct 31 15:56:21 2008 New Revision: 141497 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141497 Log: 2008-10-31 Mikael Morin [EMAIL PROTECTED] PR fortran/35840 * expr.c (gfc_reduce_init_expr): New function, containing checking code from gfc_match_init_expr, so that checking can be deferred. (gfc_match_init_expr): Use gfc_reduce_init_expr. * io.c (check_io_constraints): Use gfc_reduce_init_expr instead of checking that the expression is a constant. * match.h (gfc_reduce_init_expr): Prototype added. 2008-10-31 Mikael Morin [EMAIL PROTECTED] PR fortran/35840 * gfortran.dg/write_check4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/write_check4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/io.c trunk/gcc/fortran/match.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
[Bug c++/37968] [4.4 regression] ICE with auto as template parameter
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-31 16:01 --- The same applies, IMHO auto should be diagnosed already during parsing in this case. *** This bug has been marked as a duplicate of 37962 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37968
[Bug c++/37962] [4.4 regression] ICE with (auto*) casts
--- Comment #7 from jakub at gcc dot gnu dot org 2008-10-31 16:01 --- *** Bug 37968 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
[Bug middle-end/37980] New: [graphite] ICE : verify_ssa failed
gfortran -c -O2 -floop-block test_dominate.f90 test_dominate.f90: In function âspher_cartesiansâ: test_dominate.f90:3: error: definition in block 8 does not dominate use in block 17 for SSA_NAME: HEAP.22_59 in statement: HEAP.22_16 = PHI HEAP.22_59(17) PHI argument HEAP.22_59 for PHI node HEAP.22_16 = PHI HEAP.22_59(17) test_dominate.f90:3: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [graphite] ICE : verify_ssa failed Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mitul dot thakkar at amd 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=37980
[Bug middle-end/37980] [graphite] ICE : verify_ssa failed
--- Comment #1 from mitul dot thakkar at amd dot com 2008-10-31 16:15 --- Created an attachment (id=16597) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16597action=view) Reduced Test Case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37980
[Bug c++/37981] New: internal compiler error: in rest_of_handle_final, at final.c:3942
See attached preprocessed source and compiler output -- Summary: internal compiler error: in rest_of_handle_final, at final.c:3942 Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hackbunny at reactos dot com GCC build triplet: mingw32 GCC host triplet: mingw32 GCC target triplet: mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37981
[Bug c++/37981] internal compiler error: in rest_of_handle_final, at final.c:3942
--- Comment #1 from hackbunny at reactos dot com 2008-10-31 16:24 --- Created an attachment (id=16598) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16598action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37981
[Bug c++/37981] internal compiler error: in rest_of_handle_final, at final.c:3942
--- Comment #2 from hackbunny at reactos dot com 2008-10-31 16:25 --- Created an attachment (id=16599) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16599action=view) preprocessed input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37981
[Bug c++/37981] internal compiler error: in rest_of_handle_final, at final.c:3942
--- Comment #3 from hackbunny at reactos dot com 2008-10-31 16:31 --- Created an attachment (id=16600) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16600action=view) compiler output (PCH disabled) -- hackbunny at reactos dot com changed: What|Removed |Added Attachment #16598|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37981
[Bug c++/37981] internal compiler error: in rest_of_handle_final, at final.c:3942
--- Comment #4 from hackbunny at reactos dot com 2008-10-31 16:34 --- Created an attachment (id=16601) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16601action=view) preprocessed input (PCH disabled) sorry about compression, the file is too big to attach -- hackbunny at reactos dot com changed: What|Removed |Added Attachment #16599|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37981
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #7 from paolo at gcc dot gnu dot org 2008-10-31 16:49 --- Subject: Bug 37958 Author: paolo Date: Fri Oct 31 16:47:48 2008 New Revision: 141498 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141498 Log: 2008-10-31 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/37958 * include/bits/locale_facets.tcc (num_get::do_get(iter_type, iter_type, ios_base, ios_base::iostate, bool): Fix. * testsuite/22_locale/num_get/get/char/37958.cc: New. * testsuite/22_locale/num_get/get/wchar_t/37958.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/37958.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/37958.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_facets.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #8 from paolo dot carlini at oracle dot com 2008-10-31 16:50 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug c++/37981] internal compiler error: in rest_of_handle_final, at final.c:3942
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-31 16:55 --- Can you try to reduce the command-line arguments needed to cause the failure? Especially -ftracer looks dubious and is likely to cause problems. Btw, I cannot reproduce this on i686-linux. Also note that the GCC 4.1 series is no longer maintained, so you are encouraged to upgrade to the last stable release which is GCC 4.3.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37981
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #6 from ro at gcc dot gnu dot org 2008-10-31 17:18 --- alpha-dec-osf5.1b (with the workarounds mentioned in PR bootstrap/37426) is affected as well. _Jv_CheckABIVersion is invoked with 3221625473. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug c++/37971] [4.2/4.3/4.4 Regression] Rejects default argument that is a template via access failure
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mmitchel at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37971
[Bug middle-end/37861] Bogus array bounds warning
--- Comment #3 from jamborm at gcc dot gnu dot org 2008-10-31 17:52 ---
The test-case in the bug description leads to bogus warnings in the
second run of the VRP pass. Yesterday me and Richi discussed the
possibility of simply not-giving out any warnings in the second runs
(as opposed to the first which would still generate the warnings it
does).
However, I have managed to modify the test case so that bogus warnings
are spitted out in the first run and so this workaround would not
really solve the problem:
extern int printf (__const char *__restrict __format, ...);
static int f3(int v)
{
int i,j = 0;
for (i = 0; i = v; i++)
j++;
return j;
}
static int f2(char formatstr[10][100]) {
printf( %d %s\n, 0, formatstr[f3(0)] );
printf( %d %s\n, 1, formatstr[f3(1)] );
printf( %d %s\n, 2, formatstr[f3(2)] );
printf( %d %s\n, 3, formatstr[f3(3)] );
return 3;
}
static char formatstr[10][100];
int main( void ) {
int anz;
anz = f2(formatstr);
printf(%d\n,anz);
return 0;
}
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug middle-end/37861] Bogus array bounds warning
--- Comment #4 from jamborm at gcc dot gnu dot org 2008-10-31 18:01 --- (In reply to comment #2) So what is this? Is the warning logic wrong or is the IR wrong? It seems to me that IR is valid. Well, it probabaly isn't. I guess the second index should not ever exceed its upper bound (100 in these test cases) and it blatantly does. The proper solution (again, as suggested by Richi today) therefore most probabaly is not to re-create ARRAY_REF for multi-dimensional arrays at some place in folding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug debug/37959] g++ does not emit DW_AT_explicit
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-31 18:23:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37959
[Bug debug/37982] New: Extranious DW_TAG_variable tag
The attached test case compiled thus: g++ -g class.c class2.c -o class produces the following debuginfo: 0b: Abbrev Number: 1 (DW_TAG_compile_unit) c DW_AT_producer: (indirect string, offset: 0x36): GNU C++ 4.3.0 20080428 (Red Hat 4.3.0-8) 10 DW_AT_language: 4(C++) 11 DW_AT_name: (indirect string, offset: 0x0): class.c 15 DW_AT_comp_dir: (indirect string, offset: 0x19): /notnfs/swagiaal/tests/class 19 DW_AT_low_pc : 0x40055c 21 DW_AT_high_pc : 0x400568 29 DW_AT_stmt_list : 0x0 12d: Abbrev Number: 2 (DW_TAG_class_type) 2e DW_AT_name: A 30 DW_AT_byte_size : 1 31 DW_AT_decl_file : 2 32 DW_AT_decl_line : 4 33 DW_AT_sibling : 0x49 237: Abbrev Number: 3 (DW_TAG_variable) 38 DW_AT_name: (indirect string, offset: 0x5f): elsewhere 3c DW_AT_decl_file : 2 3d DW_AT_decl_line : 6 3e DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8): _ZN1A9elsewhereE 42 DW_AT_type: 0x49 46 DW_AT_external: 1 47 DW_AT_declaration : 1 [...] 186: Abbrev Number: 3 (DW_TAG_variable) 87 DW_AT_name: (indirect string, offset: 0x5f): elsewhere 8b DW_AT_decl_file : 2 8c DW_AT_decl_line : 6 8d DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8): _ZN1A9elsewhereE 91 DW_AT_type: 0x49 95 DW_AT_external: 1 96 DW_AT_declaration : 1 [...] 0a3: Abbrev Number: 1 (DW_TAG_compile_unit) a4 DW_AT_producer: (indirect string, offset: 0x36): GNU C++ 4.3.0 20080428 (Red Hat 4.3.0-8) a8 DW_AT_language: 4(C++) a9 DW_AT_name: (indirect string, offset: 0x6e): class2.c ad DW_AT_comp_dir: (indirect string, offset: 0x19): /notnfs/swagiaal/tests/class b1 DW_AT_low_pc : 0x400568 b9 DW_AT_high_pc : 0x400568 c1 DW_AT_stmt_list : 0x46 1c5: Abbrev Number: 2 (DW_TAG_class_type) c6 DW_AT_name: A c8 DW_AT_byte_size : 1 c9 DW_AT_decl_file : 1 ca DW_AT_decl_line : 4 cb DW_AT_sibling : 0xe1 2cf: Abbrev Number: 3 (DW_TAG_variable) d0 DW_AT_name: (indirect string, offset: 0x5f): elsewhere d4 DW_AT_decl_file : 1 d5 DW_AT_decl_line : 6 d6 DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8): _ZN1A9elsewhereE da DW_AT_type: 0xe1 de DW_AT_external: 1 df DW_AT_declaration : 1 [...] 1ed: Abbrev Number: 6 (DW_TAG_variable) ee DW_AT_specification: 0xcf f2 DW_AT_decl_file : 2 f3 DW_AT_decl_line : 4 f4 DW_AT_location: 9 byte block: 3 68 6 40 0 0 0 0 0 (DW_OP_addr: 400668) [...] The File Name Table: Entry Dir TimeSizeName 1 0 0 0 class.c 2 0 0 0 class.h [...] The File Name Table: Entry Dir TimeSizeName 1 0 0 0 class.h 2 0 0 0 class2.c As can be seen from the debug info there is an extra die (0x86). This die is misleading to the debugger. In that compile unit there are two die's representing declarations of the variable 'elsewhere' 0x37 and 0x86. The second one is in the incorrect scope and has no reference to the correct die. Please advise. Thanks -- Summary: Extranious DW_TAG_variable tag Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: swagiaal at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extranious DW_TAG_variable tag
--- Comment #1 from swagiaal at redhat dot com 2008-10-31 19:06 --- Created an attachment (id=16602) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16602action=view) testcase file 1 of 3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extranious DW_TAG_variable tag
--- Comment #2 from swagiaal at redhat dot com 2008-10-31 19:07 --- Created an attachment (id=16603) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16603action=view) testcase file 2 of 3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extranious DW_TAG_variable tag
--- Comment #3 from swagiaal at redhat dot com 2008-10-31 19:07 --- Created an attachment (id=16604) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16604action=view) testcase file 3 of 3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug other/37897] decNumber functions break strict-aliasing rules
--- Comment #5 from janis at gcc dot gnu dot org 2008-10-31 19:49 --- Fixed in mainline and 4.3 branch. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37897
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-31 19:50 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected alpha-dec-osf5.1b (with the workarounds mentioned in PR bootstrap/37426) is affected as well. _Jv_CheckABIVersion is invoked with 3221625473. It seems that when using collect2 the global constructor for libgcj calls _Jv_RegisterClass more than once for the same class. The default class hook, _Jv_RegisterClassHookDefault, messes with klass-next_or_version. The attempt at reregistration is not detected before _Jv_CheckABIVersion is called causing the abort. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug libgomp/37938] libgomp testsuite failures on ia64-linux
--- Comment #2 from sje at cup dot hp dot com 2008-10-31 20:03 --- It looks like it is Linux specific in addition to being IA64 specific. I can make the included test case fail on my Debian Linux box but not on my HP-UX box. If I do not optimize (-O0) then it fails more often then if I do optimize (-O2). -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37938
[Bug libgomp/37938] libgomp testsuite failures on ia64-linux
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-31 20:15 --- Linux specific because for non-Linux it uses libpthread pthread_mutex_lock etc. to do the locking, only on Linux (--enable-linux-futex) it uses __sync_* builtins for mutex.h locking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37938
[Bug c++/37967] [4.4 regression] ICE with function returning auto
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-10-30 21:00:56 |2008-10-31 21:28:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37967
[Bug c++/37965] [4.4 regression] ICE with invalid auto variable in template
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-31 21:31 --- Subject: Bug 37965 Author: jakub Date: Fri Oct 31 21:30:05 2008 New Revision: 141501 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141501 Log: PR c++/37965 * decl.c (cp_finish_decl): Diagnose type_uses_auto type with no initializer. * g++.dg/cpp0x/auto7.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37965
[Bug c++/37965] [4.4 regression] ICE with invalid auto variable in template
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-31 21:32 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37965
[Bug c++/37967] [4.4 regression] ICE with function returning auto
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-31 21:35 --- Subject: Bug 37967 Author: jakub Date: Fri Oct 31 21:33:47 2008 New Revision: 141502 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141502 Log: PR c++/37967 * decl.c (grokdeclarator): Diagnose auto function decl without late return type and late return type function decl where type is not auto. * g++.dg/cpp0x/auto8.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37967
[Bug c++/37967] [4.4 regression] ICE with function returning auto
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-31 21:37 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37967
[Bug debug/37959] g++ does not emit DW_AT_explicit
--- Comment #1 from dodji at gcc dot gnu dot org 2008-10-31 21:41 --- Created an attachment (id=16605) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16605action=view) Fix candidate #0 This patch tries to fix the problem. It works for me and applies to trunk. I am not sure if it qualifies to be sent to gcc-patches as we are in stage3 now. Please let me know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37959
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #25 from burnus at gcc dot gnu dot org 2008-10-31 21:43 --- (In reply to comment #24) First, gfortran (especially the constant folding) doesn't follow IEEE754 for NaN. AFAIK, there is no distinction between qNaN and sNaN. There is no distinction in MPFR - that also the reason why -finit-real=sNaN is not implemented. One reason for the lacking support in MPFR was that IEEE 754-1985 had no destinction (IEEE 754-2008 has). Somehow we need to support at some point sNaN - not only for -finit-real=sNaN but also for IEEE_VALUE. It appears that gfortran's error message is providing some language-defined diagnostic information. That part I think is OK. I'll also note that the diagnostic information tells you how to disable the range checking. That is actually not true: For ARITH_NAN and ARITH_UNDERFLOW there is no -fno-range-check mentioned - only for ARITH_OVERFLOW is. Question: Is this bug now fixed or remains something else to do? (Besides mentioning -fno-range-check in the error message and implementing F2003's IEEE functions.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #26 from sgk at troutmask dot apl dot washington dot edu 2008-10-31 22:14 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Fri, Oct 31, 2008 at 09:43:13PM -, burnus at gcc dot gnu dot org wrote: I'll also note that the diagnostic information tells you how to disable the range checking. That is actually not true: For ARITH_NAN and ARITH_UNDERFLOW there is no -fno-range-check mentioned - only for ARITH_OVERFLOW is. I don't use -fno-range-check unless I'm debugging some PR, so I forgot the details. ARITH_UNDERFLOW doesn't require any special handling (ie., they are set to zero). We could extend -fno-range-check to allow the conversion of a REAL NaN to a DOUBLE PRECISION NaN. I'm not too excited by that idea. Question: Is this bug now fixed or remains something else to do? (Besides mentioning -fno-range-check in the error message and implementing F2003's IEEE functions.) Personally, I think the bug is fixed, and this PR can be closed. I thought FX had opened a PR for the IEEE module, but a quick scan did not find it. I guess it doesn't make much sense opening a PR for every unimplemented F2003 feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug libgomp/37938] libgomp testsuite failures on ia64-linux
-- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-31 23:30:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37938
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-31 23:31 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected It seems that when using collect2 the global constructor for libgcj calls _Jv_RegisterClass more than once for the same class. This seems to be because org-xml.o, for example, contains two global constructors: _GLOBAL__I_65535_0__var_tmp__cc4hyJYpjx_4B3F0796_410DDDB4 _GLOBAL__I_65535_1__var_tmp__cc4hyJYpjx_4B3F0796_410DDDB4 Both register the same classes. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #3 from hjl dot tools at gmail dot com 2008-11-01 00:25 --- I changed it to middle-end. -- hjl dot tools at gmail dot com changed: What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
