[Bug target/30769] compile error / segmentation fault / 64bit compiler
--- Comment #11 from armin at xos dot net 2007-02-16 08:07 --- Subject: Re: compile error / segmentation fault / 64bit compiler > Note that you don't need -fno-strict-aliasing with -O, it's the default. > You don't need -mcpu=v9 -m64 -Wa,-xarch=v9 either, it's also the default. ok. i guess configure did find them out somehow. however i used the patches from your referred bug and could compile and run the modules without problems. thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
[Bug target/30769] compile error / segmentation fault / 64bit compiler
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2007-02-16 08:21 --- > however i used the patches from your referred bug and could compile and > run the modules without problems. Thanks for letting us know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
[Bug middle-end/30391] [4.3 regression] ICE at -O1 with conditional expressions and GIMPLE_MODIFY_STMT
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-02-16 08:31 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30391
[Bug other/27843] gcc-4.2-20060527 make install fails on alphaev68-dec-osf5.1b
--- Comment #7 from bonzini at gnu dot org 2007-02-16 08:54 --- Subject: Bug 27843 Author: bonzini Date: Fri Feb 16 08:53:51 2007 New Revision: 122032 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122032 Log: 2007-02-16 Ralf Wildenhues <[EMAIL PROTECTED]> PR other/27843 * Makefile.in (SYSTEM_HEADER_DIR): Use single quotes to avoid nested double- and backquotes. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27843
[Bug rtl-optimization/30773] [4.3 Regression] Spec cpu2k6/h264ref and sphinx3 miscompare regression
--- Comment #7 from grigory_zagorodnev at linux dot intel dot com 2007-02-16 08:58 --- (In reply to comment #6) > What Ian said is probably right, and the patch below should fix it. I haven't > tried it yet, though... I've tried in the given conditions. This patch really solves both h264ref and sphinx3 miscompare regressions. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30773
[Bug other/27843] gcc-4.2-20060527 make install fails on alphaev68-dec-osf5.1b
--- Comment #8 from bonzini at gnu dot org 2007-02-16 09:06 --- Subject: Bug 27843 Author: bonzini Date: Fri Feb 16 09:06:05 2007 New Revision: 122033 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122033 Log: 2007-02-16 Ralf Wildenhues <[EMAIL PROTECTED]> PR other/27843 * Makefile.in (SYSTEM_HEADER_DIR): Use single quotes to avoid nested double- and backquotes. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27843
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #22 from pcarlini at suse dot de 2007-02-16 09:06 --- Frankly, I think it would make sense to remove completely this XFAIL-ing mess and just wait for Diego to fix the compiler issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug other/27843] gcc-4.2-20060527 make install fails on alphaev68-dec-osf5.1b
--- Comment #9 from bonzini at gnu dot org 2007-02-16 09:13 --- Subject: Bug 27843 Author: bonzini Date: Fri Feb 16 09:13:47 2007 New Revision: 122035 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122035 Log: 2007-02-16 Ralf Wildenhues <[EMAIL PROTECTED]> PR other/27843 * Makefile.in (SYSTEM_HEADER_DIR): Use single quotes to avoid nested double- and backquotes. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27843
[Bug other/27843] gcc-4.2-20060527 make install fails on alphaev68-dec-osf5.1b
--- Comment #10 from bonzini at gnu dot org 2007-02-16 09:14 --- committed to all active branches. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27843
[Bug other/27843] gcc-4.2-20060527 make install fails on alphaev68-dec-osf5.1b
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-02-16 09:22 --- > committed to all active branches. Thanks to Ralf and you! -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27843
[Bug fortran/30793] Segfault on calling a function returning a pointer
--- Comment #13 from sfilippone at uniroma2 dot it 2007-02-16 09:40 --- (In reply to comment #3) > For both test cases, xlf gives: > > ** class_mesh === End of Compilation 1 === > ** class_field === End of Compilation 2 === > . > (second test case). I don't know if they are right, but the errors may give a > clue. > Must be a bug in that version, because on an AIX SP with XLF 10 I get a clean compile <[EMAIL PROTECTED] /data/ado/sfilippo>xlf95 -o test_pnt test_pnt.f90 ** class_mesh === End of Compilation 1 === ** class_field === End of Compilation 2 === ** class_scalar_field === End of Compilation 3 === ** test_pnt === End of Compilation 4 === 1501-510 Compilation successful for file test_pnt.f90. <[EMAIL PROTECTED] /data/ado/sfilippo>./test_pnt <[EMAIL PROTECTED] /data/ado/sfilippo>lslpp -h xlfcmp Fileset Level Action Status Date Time Path: /usr/lib/objrepos xlfcmp 10.1.0.0 COMMIT COMPLETE 07/10/06 10:23:41 10.1.0.1 COMMIT COMPLETE 07/10/06 10:26:42 10.1.0.2 COMMIT COMPLETE 01/12/07 18:53:02 Path: /etc/objrepos xlfcmp 10.1.0.0 COMMIT COMPLETE 07/10/06 10:23:52 10.1.0.1 COMMIT COMPLETE 07/10/06 10:26:42 10.1.0.2 COMMIT COMPLETE 01/12/07 18:53:02 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30793
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #12 from manu at gcc dot gnu dot org 2007-02-16 09:53 --- I get warning for gcc/testsuite/objc.dg/headers.m /home/manuel/src/trunk/gcc/testsuite/../../libobjc/objc/objc-list.h:144: warning: 'list_free' defined but not used What should I do about this? 1) there is no warning if I add the keyword "inline" to objc-list.h (list_free). 2) add -Wno-unused-function to the testcase. 3) ?? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug fortran/30793] Segfault on calling a function returning a pointer
--- Comment #14 from burnus at gcc dot gnu dot org 2007-02-16 09:55 --- Subject: Bug 30793 Author: burnus Date: Fri Feb 16 09:55:20 2007 New Revision: 122037 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122037 Log: fortran/ 2007-02-16 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30793 * trans-decl.c (gfc_generate_function_code): Do not initialize pointers to derived components. testsuite/ 2007-02-16 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30793 * gfortran.dg/func_derived_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/func_derived_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30793
[Bug c++/20423] Warning -Woverloaded-virtual triggers to often
--- Comment #6 from manu at gcc dot gnu dot org 2007-02-16 10:01 ---
A really wild-guess patch. Comments?
Index: gcc/cp/class.c
===
--- gcc/cp/class.c (revision 121953)
+++ gcc/cp/class.c (working copy)
@@ -2377,6 +2377,8 @@ warn_hidden (tree t)
tree binfo;
int j;
+ bool just_hidden = false;
+
/* All functions in this slot in the CLASSTYPE_METHOD_VEC will
have the same name. Figure out what name that is. */
name = DECL_NAME (OVL_CURRENT (fns));
@@ -2408,8 +2410,14 @@ warn_hidden (tree t)
/* If the method from the base class has the same
signature as the method from the derived class, it
has been overridden. */
- if (same_signature_p (fndecl, TREE_VALUE (*prev)))
- *prev = TREE_CHAIN (*prev);
+ if (same_signature_p (fndecl, TREE_VALUE (*prev)))
+ {
+ *prev = TREE_CHAIN (*prev);
+ /* If at least one method has the same signature,
+ the not overloaded variants are just
+ hidden. */
+ just_hidden = true;
+ }
else
prev = &TREE_CHAIN (*prev);
}
@@ -2419,9 +2427,17 @@ warn_hidden (tree t)
as they are hidden. */
while (base_fndecls)
{
- /* Here we know it is a hider, and no overrider exists. */
- warning (0, "%q+D was hidden", TREE_VALUE (base_fndecls));
- warning (0, " by %q+D", fns);
+ /* If Here we know it is a hider, and no overrider exists. */
+ if (just_hidden)
+ {
+ warning (OPT_Wpartial_overloaded_virtual, "%q+D was hidden",
TREE_VALUE (base_fndecls));
+ warning (OPT_Wpartial_overloaded_virtual, " by %q+D", fns);
+ }
+ else
+ {
+ warning (OPT_Woverloaded_virtual, "%q+D was hidden", TREE_VALUE
(base_fndecls));
+ warning (OPT_Woverloaded_virtual, " by %q+D", fns);
+ }
base_fndecls = TREE_CHAIN (base_fndecls);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20423
[Bug c++/30818] New: [4.1.2 Regression] templates and typedefs cause function prototype not to match
the following compiled fine on gcc-3.4.6 but gives error on gcc-4.1.2
error: prototype for 'typename A::B::type A::B::f()' does not match any
in class 'A::B'
error: candidate is: typename A::type A::B::f()
error: template definition of non-template 'typename A::B::type
A::B::f()'
template < typename T >
class A
{
typedef int type;
class B;
};
template < typename T >
class A::B
{
typedef typename A::type type;
type g() { return 0;}
type f();
};
template < typename T >
typename A::B::type
A::B::f() { return 0; }
( I have no vanilla gcc available, so hopefully gentoo guys did not screw up
gcc-4.1.2 )
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/home/portage/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.2
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-libunwind-exceptions
--disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2)
--
Summary: [4.1.2 Regression] templates and typedefs cause function
prototype not to match
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sschunck at pdf dot de
GCC host triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30818
[Bug c/30819] New: php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
http://bugs.php.net/bug.php?id=39418 short summary: during the install process of php. php is called and segfaults. detailed info in the above link. the php people think its a gcc fault. i could reproduce the bug (with or without their trim patch). what's the information you need. how to produce a .i file - of which php component? -- Summary: php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: armin at xos dot net GCC build triplet: sparcv9-sun-solaris2.9 GCC host triplet: sparcv9-sun-solaris2.9 GCC target triplet: sparcv9-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug fortran/30820] New: -Wno-error not necessary in Make-lang.in any more?
gcc/fortran/Make-lang.in has: # These files get warnings from an inline function in GMP saying: # "control may reach end of non-void function '__gmpz_get_ui' being inlined" fortran/expr.o-warn = -Wno-error fortran/resolve.o-warn = -Wno-error fortran/simplify.o-warn = -Wno-error fortran/trans-common.o-warn = -Wno-error I've never seen these warnings happen, so I'm wondering if we still need these -Wno-error. Removing them would enable us to spot more easily mistakes made while changing these files. -- Summary: -Wno-error not necessary in Make-lang.in any more? Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: build Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30820
[Bug fortran/30820] -Wno-error not necessary in Make-lang.in any more?
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-02-16 11:08 --- I'll add that before removing the code, one should do a build with minimal versions of GMP & MPFR (GMP 4.1 and MPFR 2.2.0), and see if the warnings happen. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-16 11:08:24 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30820
[Bug rtl-optimization/30787] [4.1 Regression] Strength reduction bug
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-02-16 11:08
---
It's a variant of a bug you fixed
2005-12-16 Jakub Jelinek <[EMAIL PROTECTED]>
PR rtl-optimization/24899
* loop.c (strength_reduce): Don't reduce giv that is not always
computable and where add_val or mult_val can trap.
The discrepancy is that the giv is a DEST_ADDR instead of a DEST_REG and
/* The v->always_computable field is used in update_giv_derive, to
determine whether a giv can be used to derive another giv. For a
DEST_REG giv, INSN computes a new value for the giv, so its value
isn't computable if INSN insn't executed every iteration.
However, for a DEST_ADDR giv, INSN merely uses the value of the giv;
it does not compute a new value. Hence the value is always computable
regardless of whether INSN is executed each iteration. */
if (type == DEST_ADDR)
v->always_computable = 1;
else
v->always_computable = ! not_every_iteration;
$4 = {insn = 0x556e6cd0, new_reg = 0x0, src_reg = 0x55753a00,
giv_type = DEST_ADDR, dest_reg = 0x55753b20, location = 0x5575e3dc,
mode = SImode, mem = 0x5575e3d8, mult_val = 0x556db230,
add_val = 0x5575e384, benefit = 24, final_value = 0x0, combined_with = 1,
replaceable = 1, not_replaceable = 0, ignore = 0, always_computable = 1,
always_executed = 0, maybe_multiple = 0, cant_derive = 0, maybe_dead = 0,
auto_inc_opt = 0, shared = 0, no_const_addval = 1, lifetime = 2,
derive_adjustment = 0x0, ext_dependent = 0x0, next_iv = 0x8662cf8,
same = 0x0, same_insn = 0x0, last_use = 0x0}
The fix is probably to test v->always_executed instead.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||24899
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30787
[Bug c++/30818] [4.1/4.2/4.3 Regression] templates and typedefs cause function prototype not to match
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-16 11:25 --- EDG happily eats this. With mainline the error looks like t.ii:18: error: prototype for typename A::B::type A::B::f() does not match any in class A::B t.ii:13: error: candidate is: typename A::type A::B::f() t.ii:18: error: typename A::B::type A::B::f() cannot be overloaded t.ii:13: error: with typename A::type A::B::f() t.ii:18: error: template definition of non-template typename A::B::type A::B::f() -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail|4.1.2 |4.1.2 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-02-16 11:25:02 date|| Summary|[4.1.2 Regression] templates|[4.1/4.2/4.3 Regression] |and typedefs cause function |templates and typedefs cause |prototype not to match |function prototype not to ||match http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30818
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-16 11:29 --- Try building with -fno-strict-aliasing and/or with -fwrapv. If this fixes it it is a bug in PHP. Also try 4.1.2 which was released a few days ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-02-16 12:06 --- > what's the information you need. how to produce a .i file - of which php > component? You have to do half of the work, i.e. find out which part of the code has been miscompiled. Could you try with 4.1.2 as Richard suggested? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug c++/30821] New: [4.1.2 Regression] templates and typedefs cause function prototype not to match
the following compiled fine on gcc-3.4.6 but gives error on gcc-4.1.2
error: prototype for 'typename A::B::type A::B::f()' does not match any
in class 'A::B'
error: candidate is: typename A::type A::B::f()
error: template definition of non-template 'typename A::B::type
A::B::f()'
template < typename T >
class A
{
typedef int type;
class B;
};
template < typename T >
class A::B
{
typedef typename A::type type;
type g() { return 0;}
type f();
};
template < typename T >
typename A::B::type
A::B::f() { return 0; }
( I have no vanilla gcc available, so hopefully gentoo guys did not screw up
gcc-4.1.2 )
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/home/portage/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.2
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-libunwind-exceptions
--disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2)
--
Summary: [4.1.2 Regression] templates and typedefs cause function
prototype not to match
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sschunck at pdf dot de
GCC host triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30821
[Bug c++/30822] New: wrong choice of overloaded template functions in recursive call
Hello, in the attached piece of code two pairs of template functions are
defined which differ just in the order of their definitions.
The first pair (for_all_1) is accepted by the compiler (gcc 4.1.1) the second
(for_all_2) is rejected. (The aim of the code is to iterate over a list of
elements of different types and execute an operation on each element.) The code
compiles with the Visual Studio 2005 c++ compiler. gcc 3.3.1 claims that the
function calls are ambiguous.
I do not have the newest gcc compiler. Could some one please confirm that this
is a bug and that it is not fixed with gcc 4.1.2 or later?
Thanks
Volker
#include
class element
{
public:
void test() { std::cout << "Hello World" << std::endl; }
};
template
class op
{
public:
void operator()(TElement elem) { elem.test(); }
};
class cons_end
{
};
template
class cons
{
public:
TElement elem;
TTail tail;
};
// note the order of the definitions of the two functions named for_all_1
template class TOperator,typename TElement>
void for_all_1(TElement elem, cons_end tail)
{
TOperator()(elem);
}
template class TOperator,typename TElement, typename TTail>
void for_all_1(TElement elem, TTail tail)
{
TOperator()(elem);
for_all_1(tail.elem,tail.tail);
}
// now the order changed and the compiler complains!
template class TOperator,typename TElement, typename TTail>
void for_all_2(TElement elem, TTail tail)
{
TOperator()(elem);
for_all_2(tail.elem,tail.tail);
}
template class TOperator,typename TElement>
void for_all_2(TElement elem, cons_end tail)
{
TOperator()(elem);
}
int main(int argc, char *argv[])
{
cons > list;
for_all_1(list.elem,list.tail);
for_all_2(list.elem,list.tail);
}
--
Summary: wrong choice of overloaded template functions in
recursive call
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Zarathustra at gentlemansclub dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30822
[Bug fortran/30381] [4.1 and 4.2] ISHFTC() constant folding is broken.
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-02-16 12:19 --- Subject: Bug 30381 Author: fxcoudert Date: Fri Feb 16 12:19:01 2007 New Revision: 122039 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122039 Log: 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30720 * trans-array.c (gfc_trans_create_temp_array): Remove use of the function argument. Always generate code for negative extent. Simplify said code. * trans-array.h (gfc_trans_create_temp_array): Change prototype. * trans-expr.c (gfc_conv_function_call): Remove use of last argument of gfc_trans_create_temp_array. * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Likewise. * trans-stmt.c (gfc_conv_elemental_dependencies): Likewise. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * trans-intrinsic.c (gfc_conv_intrinsic_repeat): Evaluate arguments only once. Generate check that NCOPIES argument is not negative. 2007-02-16 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.h: Remove gfc_simplify_init_1. * arith.h: Remove third argument from gfc_compare_string. * arith.c(gfc_compare_expression): Remove third argument from call to gfc_compare_string. (gfc_compare_string): Remove third argument xcoll_table. Remove use of xcoll_table. * misc.c(gfc_init_1): Remove call to gfc_simplify_init_1. * simplify.c(ascii_table): Remove. (xascii_table): Likewise. (gfc_simplify_achar): ICE if extract_int fails. Remove use of ascii_table. Warn if -Wsurprising and value < 0 or > 127. (gfc_simplify_char): ICE if extract_int fails. Error if value < 0 or value > 255. (gfc_simplify_iachar): Remove use of xascii_table. Char values outside of 0..255 are an ICE. (gfc_simplify_lge): Remove use of xascii_table. (gfc_simplify_lgt): Likewise. (gfc_simplify_lle): Likewise. (gfc_simplify_llt): Likewise. (invert_table): Remove. (gfc_simplify_init_1): Remove. 2007-02-16 Brooks Moses <[EMAIL PROTECTED]> PR 30381 PR 30420 * simplify.c (convert_mpz_to_unsigned): New function. (convert_mpz_to_signed): New function, largely based on twos_complement(). (twos_complement): Removed. (gfc_simplify_ibclr): Add conversions to and from an unsigned representation before bit-twiddling. (gfc_simplify_ibset): Same. (gfc_simplify_ishftc): Add checks for overly large constant arguments, only check the third argument if it's present, carry over high bits into the result as appropriate, and perform the final conversion back to a signed representation using the correct sign bit. (gfc_simplify_not): Removed unnecessary masking. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30720 * gfortran.dg/array_function_1.f90: New test. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * gcc/testsuite/gfortran.dg/repeat_1.f90: New test. 2007-02-16 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.dg/achar_2.f90: New test. * gfortran.dg/achar_3.f90: New test. 2007-02-16 Brooks Moses <[EMAIL PROTECTED]> * gfortran.dg/chkbits.f90: Added IBCLR tests; test calls for different integer kinds. * gfortran.dg/ishft.f90: Renamed to ishft_1.f90... * gfortran.dg/ishft_1.f90: ...Renamed from ishft.f90. * gfortran.dg/ishft_2.f90: New test. * gfortran.dg/ishft_3.f90: New test. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * intrinsics/string_intrinsics.c (string_repeat): Don't check if ncopies is negative. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/achar_2.f90 - copied unchanged from r121255, trunk/gcc/testsuite/gfortran.dg/achar_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/achar_3.f90 - copied unchanged from r121255, trunk/gcc/testsuite/gfortran.dg/achar_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/array_function_1.f90 - copied unchanged from r121773, trunk/gcc/testsuite/gfortran.dg/array_function_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_1.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_2.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_3.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/repeat_1.f90 - copied unc
[Bug fortran/30389] [4.2, 4.1 only] ACHAR() intrinsic gives erroneous errors in constant-folding.
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-02-16 12:19 --- Subject: Bug 30389 Author: fxcoudert Date: Fri Feb 16 12:19:01 2007 New Revision: 122039 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122039 Log: 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30720 * trans-array.c (gfc_trans_create_temp_array): Remove use of the function argument. Always generate code for negative extent. Simplify said code. * trans-array.h (gfc_trans_create_temp_array): Change prototype. * trans-expr.c (gfc_conv_function_call): Remove use of last argument of gfc_trans_create_temp_array. * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Likewise. * trans-stmt.c (gfc_conv_elemental_dependencies): Likewise. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * trans-intrinsic.c (gfc_conv_intrinsic_repeat): Evaluate arguments only once. Generate check that NCOPIES argument is not negative. 2007-02-16 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.h: Remove gfc_simplify_init_1. * arith.h: Remove third argument from gfc_compare_string. * arith.c(gfc_compare_expression): Remove third argument from call to gfc_compare_string. (gfc_compare_string): Remove third argument xcoll_table. Remove use of xcoll_table. * misc.c(gfc_init_1): Remove call to gfc_simplify_init_1. * simplify.c(ascii_table): Remove. (xascii_table): Likewise. (gfc_simplify_achar): ICE if extract_int fails. Remove use of ascii_table. Warn if -Wsurprising and value < 0 or > 127. (gfc_simplify_char): ICE if extract_int fails. Error if value < 0 or value > 255. (gfc_simplify_iachar): Remove use of xascii_table. Char values outside of 0..255 are an ICE. (gfc_simplify_lge): Remove use of xascii_table. (gfc_simplify_lgt): Likewise. (gfc_simplify_lle): Likewise. (gfc_simplify_llt): Likewise. (invert_table): Remove. (gfc_simplify_init_1): Remove. 2007-02-16 Brooks Moses <[EMAIL PROTECTED]> PR 30381 PR 30420 * simplify.c (convert_mpz_to_unsigned): New function. (convert_mpz_to_signed): New function, largely based on twos_complement(). (twos_complement): Removed. (gfc_simplify_ibclr): Add conversions to and from an unsigned representation before bit-twiddling. (gfc_simplify_ibset): Same. (gfc_simplify_ishftc): Add checks for overly large constant arguments, only check the third argument if it's present, carry over high bits into the result as appropriate, and perform the final conversion back to a signed representation using the correct sign bit. (gfc_simplify_not): Removed unnecessary masking. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30720 * gfortran.dg/array_function_1.f90: New test. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * gcc/testsuite/gfortran.dg/repeat_1.f90: New test. 2007-02-16 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.dg/achar_2.f90: New test. * gfortran.dg/achar_3.f90: New test. 2007-02-16 Brooks Moses <[EMAIL PROTECTED]> * gfortran.dg/chkbits.f90: Added IBCLR tests; test calls for different integer kinds. * gfortran.dg/ishft.f90: Renamed to ishft_1.f90... * gfortran.dg/ishft_1.f90: ...Renamed from ishft.f90. * gfortran.dg/ishft_2.f90: New test. * gfortran.dg/ishft_3.f90: New test. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * intrinsics/string_intrinsics.c (string_repeat): Don't check if ncopies is negative. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/achar_2.f90 - copied unchanged from r121255, trunk/gcc/testsuite/gfortran.dg/achar_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/achar_3.f90 - copied unchanged from r121255, trunk/gcc/testsuite/gfortran.dg/achar_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/array_function_1.f90 - copied unchanged from r121773, trunk/gcc/testsuite/gfortran.dg/array_function_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_1.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_2.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_3.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/repeat_1.f90 - copied unc
[Bug fortran/30611] [4.2/4.1 only] Confusing error message for negative ncopies in REPEAT
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-02-16 12:19 --- Subject: Bug 30611 Author: fxcoudert Date: Fri Feb 16 12:19:01 2007 New Revision: 122039 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122039 Log: 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30720 * trans-array.c (gfc_trans_create_temp_array): Remove use of the function argument. Always generate code for negative extent. Simplify said code. * trans-array.h (gfc_trans_create_temp_array): Change prototype. * trans-expr.c (gfc_conv_function_call): Remove use of last argument of gfc_trans_create_temp_array. * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Likewise. * trans-stmt.c (gfc_conv_elemental_dependencies): Likewise. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * trans-intrinsic.c (gfc_conv_intrinsic_repeat): Evaluate arguments only once. Generate check that NCOPIES argument is not negative. 2007-02-16 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.h: Remove gfc_simplify_init_1. * arith.h: Remove third argument from gfc_compare_string. * arith.c(gfc_compare_expression): Remove third argument from call to gfc_compare_string. (gfc_compare_string): Remove third argument xcoll_table. Remove use of xcoll_table. * misc.c(gfc_init_1): Remove call to gfc_simplify_init_1. * simplify.c(ascii_table): Remove. (xascii_table): Likewise. (gfc_simplify_achar): ICE if extract_int fails. Remove use of ascii_table. Warn if -Wsurprising and value < 0 or > 127. (gfc_simplify_char): ICE if extract_int fails. Error if value < 0 or value > 255. (gfc_simplify_iachar): Remove use of xascii_table. Char values outside of 0..255 are an ICE. (gfc_simplify_lge): Remove use of xascii_table. (gfc_simplify_lgt): Likewise. (gfc_simplify_lle): Likewise. (gfc_simplify_llt): Likewise. (invert_table): Remove. (gfc_simplify_init_1): Remove. 2007-02-16 Brooks Moses <[EMAIL PROTECTED]> PR 30381 PR 30420 * simplify.c (convert_mpz_to_unsigned): New function. (convert_mpz_to_signed): New function, largely based on twos_complement(). (twos_complement): Removed. (gfc_simplify_ibclr): Add conversions to and from an unsigned representation before bit-twiddling. (gfc_simplify_ibset): Same. (gfc_simplify_ishftc): Add checks for overly large constant arguments, only check the third argument if it's present, carry over high bits into the result as appropriate, and perform the final conversion back to a signed representation using the correct sign bit. (gfc_simplify_not): Removed unnecessary masking. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30720 * gfortran.dg/array_function_1.f90: New test. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * gcc/testsuite/gfortran.dg/repeat_1.f90: New test. 2007-02-16 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.dg/achar_2.f90: New test. * gfortran.dg/achar_3.f90: New test. 2007-02-16 Brooks Moses <[EMAIL PROTECTED]> * gfortran.dg/chkbits.f90: Added IBCLR tests; test calls for different integer kinds. * gfortran.dg/ishft.f90: Renamed to ishft_1.f90... * gfortran.dg/ishft_1.f90: ...Renamed from ishft.f90. * gfortran.dg/ishft_2.f90: New test. * gfortran.dg/ishft_3.f90: New test. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * intrinsics/string_intrinsics.c (string_repeat): Don't check if ncopies is negative. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/achar_2.f90 - copied unchanged from r121255, trunk/gcc/testsuite/gfortran.dg/achar_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/achar_3.f90 - copied unchanged from r121255, trunk/gcc/testsuite/gfortran.dg/achar_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/array_function_1.f90 - copied unchanged from r121773, trunk/gcc/testsuite/gfortran.dg/array_function_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_1.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_2.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_3.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/repeat_1.f90 - copied unc
[Bug fortran/30420] [4.1 and 4.2] IBCLR() fails to properly handle clearing the sign bit.
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-16 12:19 --- Subject: Bug 30420 Author: fxcoudert Date: Fri Feb 16 12:19:01 2007 New Revision: 122039 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122039 Log: 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30720 * trans-array.c (gfc_trans_create_temp_array): Remove use of the function argument. Always generate code for negative extent. Simplify said code. * trans-array.h (gfc_trans_create_temp_array): Change prototype. * trans-expr.c (gfc_conv_function_call): Remove use of last argument of gfc_trans_create_temp_array. * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Likewise. * trans-stmt.c (gfc_conv_elemental_dependencies): Likewise. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * trans-intrinsic.c (gfc_conv_intrinsic_repeat): Evaluate arguments only once. Generate check that NCOPIES argument is not negative. 2007-02-16 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.h: Remove gfc_simplify_init_1. * arith.h: Remove third argument from gfc_compare_string. * arith.c(gfc_compare_expression): Remove third argument from call to gfc_compare_string. (gfc_compare_string): Remove third argument xcoll_table. Remove use of xcoll_table. * misc.c(gfc_init_1): Remove call to gfc_simplify_init_1. * simplify.c(ascii_table): Remove. (xascii_table): Likewise. (gfc_simplify_achar): ICE if extract_int fails. Remove use of ascii_table. Warn if -Wsurprising and value < 0 or > 127. (gfc_simplify_char): ICE if extract_int fails. Error if value < 0 or value > 255. (gfc_simplify_iachar): Remove use of xascii_table. Char values outside of 0..255 are an ICE. (gfc_simplify_lge): Remove use of xascii_table. (gfc_simplify_lgt): Likewise. (gfc_simplify_lle): Likewise. (gfc_simplify_llt): Likewise. (invert_table): Remove. (gfc_simplify_init_1): Remove. 2007-02-16 Brooks Moses <[EMAIL PROTECTED]> PR 30381 PR 30420 * simplify.c (convert_mpz_to_unsigned): New function. (convert_mpz_to_signed): New function, largely based on twos_complement(). (twos_complement): Removed. (gfc_simplify_ibclr): Add conversions to and from an unsigned representation before bit-twiddling. (gfc_simplify_ibset): Same. (gfc_simplify_ishftc): Add checks for overly large constant arguments, only check the third argument if it's present, carry over high bits into the result as appropriate, and perform the final conversion back to a signed representation using the correct sign bit. (gfc_simplify_not): Removed unnecessary masking. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30720 * gfortran.dg/array_function_1.f90: New test. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * gcc/testsuite/gfortran.dg/repeat_1.f90: New test. 2007-02-16 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.dg/achar_2.f90: New test. * gfortran.dg/achar_3.f90: New test. 2007-02-16 Brooks Moses <[EMAIL PROTECTED]> * gfortran.dg/chkbits.f90: Added IBCLR tests; test calls for different integer kinds. * gfortran.dg/ishft.f90: Renamed to ishft_1.f90... * gfortran.dg/ishft_1.f90: ...Renamed from ishft.f90. * gfortran.dg/ishft_2.f90: New test. * gfortran.dg/ishft_3.f90: New test. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * intrinsics/string_intrinsics.c (string_repeat): Don't check if ncopies is negative. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/achar_2.f90 - copied unchanged from r121255, trunk/gcc/testsuite/gfortran.dg/achar_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/achar_3.f90 - copied unchanged from r121255, trunk/gcc/testsuite/gfortran.dg/achar_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/array_function_1.f90 - copied unchanged from r121773, trunk/gcc/testsuite/gfortran.dg/array_function_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_1.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_2.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_3.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/repeat_1.f90 - copied unc
[Bug fortran/30720] [4.2/4.1 only] runtime: check for empty array slices before allocating a negative amount of memory
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-02-16 12:19 --- Subject: Bug 30720 Author: fxcoudert Date: Fri Feb 16 12:19:01 2007 New Revision: 122039 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122039 Log: 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30720 * trans-array.c (gfc_trans_create_temp_array): Remove use of the function argument. Always generate code for negative extent. Simplify said code. * trans-array.h (gfc_trans_create_temp_array): Change prototype. * trans-expr.c (gfc_conv_function_call): Remove use of last argument of gfc_trans_create_temp_array. * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Likewise. * trans-stmt.c (gfc_conv_elemental_dependencies): Likewise. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * trans-intrinsic.c (gfc_conv_intrinsic_repeat): Evaluate arguments only once. Generate check that NCOPIES argument is not negative. 2007-02-16 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.h: Remove gfc_simplify_init_1. * arith.h: Remove third argument from gfc_compare_string. * arith.c(gfc_compare_expression): Remove third argument from call to gfc_compare_string. (gfc_compare_string): Remove third argument xcoll_table. Remove use of xcoll_table. * misc.c(gfc_init_1): Remove call to gfc_simplify_init_1. * simplify.c(ascii_table): Remove. (xascii_table): Likewise. (gfc_simplify_achar): ICE if extract_int fails. Remove use of ascii_table. Warn if -Wsurprising and value < 0 or > 127. (gfc_simplify_char): ICE if extract_int fails. Error if value < 0 or value > 255. (gfc_simplify_iachar): Remove use of xascii_table. Char values outside of 0..255 are an ICE. (gfc_simplify_lge): Remove use of xascii_table. (gfc_simplify_lgt): Likewise. (gfc_simplify_lle): Likewise. (gfc_simplify_llt): Likewise. (invert_table): Remove. (gfc_simplify_init_1): Remove. 2007-02-16 Brooks Moses <[EMAIL PROTECTED]> PR 30381 PR 30420 * simplify.c (convert_mpz_to_unsigned): New function. (convert_mpz_to_signed): New function, largely based on twos_complement(). (twos_complement): Removed. (gfc_simplify_ibclr): Add conversions to and from an unsigned representation before bit-twiddling. (gfc_simplify_ibset): Same. (gfc_simplify_ishftc): Add checks for overly large constant arguments, only check the third argument if it's present, carry over high bits into the result as appropriate, and perform the final conversion back to a signed representation using the correct sign bit. (gfc_simplify_not): Removed unnecessary masking. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30720 * gfortran.dg/array_function_1.f90: New test. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * gcc/testsuite/gfortran.dg/repeat_1.f90: New test. 2007-02-16 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/30389 * gfortran.dg/achar_2.f90: New test. * gfortran.dg/achar_3.f90: New test. 2007-02-16 Brooks Moses <[EMAIL PROTECTED]> * gfortran.dg/chkbits.f90: Added IBCLR tests; test calls for different integer kinds. * gfortran.dg/ishft.f90: Renamed to ishft_1.f90... * gfortran.dg/ishft_1.f90: ...Renamed from ishft.f90. * gfortran.dg/ishft_2.f90: New test. * gfortran.dg/ishft_3.f90: New test. 2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/30611 * intrinsics/string_intrinsics.c (string_repeat): Don't check if ncopies is negative. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/achar_2.f90 - copied unchanged from r121255, trunk/gcc/testsuite/gfortran.dg/achar_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/achar_3.f90 - copied unchanged from r121255, trunk/gcc/testsuite/gfortran.dg/achar_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/array_function_1.f90 - copied unchanged from r121773, trunk/gcc/testsuite/gfortran.dg/array_function_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_1.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_2.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ishft_3.f90 - copied unchanged from r120634, trunk/gcc/testsuite/gfortran.dg/ishft_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/repeat_1.f90 - copied unc
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #3 from armin at xos dot net 2007-02-16 12:23 --- Subject: Re: php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit > You have to do half of the work, i.e. find out which part of the code has been > miscompiled. Could you try with 4.1.2 as Richard suggested? i used the above cflags and it compiled well. and no segmentation faults anymore. some php errors now. i opened a bug at: http://bugs.php.net/bug.php?id=40507 don't have time to change to 4.1.2. but you can probably close the bug anyway - thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #23 from dnovillo at gcc dot gnu dot org 2007-02-16 12:35 --- (In reply to comment #22) > Frankly, I think it would make sense to remove completely this XFAIL-ing mess > and just wait for Diego to fix the compiler issue. > Agreed. I don't understand why the rush to XFAIL a test that's obviously exposing a bug. At most, I would like to understand which patch started triggering the failure. It can't have been too long ago, the 2-3 day old mainline tree I have in my box does not have this failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #4 from tony2001 at php dot net 2007-02-16 12:55 --- >Try building with -fno-strict-aliasing and/or with -fwrapv. >If this fixes it it is a bug in PHP. Any hints on what it might be and why it's reproducible only on SPARC and GCC 4.x ? -- tony2001 at php dot net changed: What|Removed |Added CC||tony2001 at php dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-02-16 13:06 --- > i used the above cflags and it compiled well. and no segmentation faults > anymore. I wouldn't personally recommend -fwrapv, this may uncover other problems. On the contrary, -fno-strict-aliasing is always safe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-02-16 13:12 --- > Any hints on what it might be and why it's reproducible only on SPARC and GCC > 4.x ? If the trigger happens to be -fstrict-aliasing, it's very likely a violation of the type-based aliasing rules of the C/C++ languages. They are usually exposed by the scheduler, which is more aggressive on SPARC than on x86 for example. It's another (and more convoluted) story for -fwrapv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug bootstrap/30810] top-level BOOT_CFLAGS not being used for bootstrapping
--- Comment #3 from sdack at gmx dot de 2007-02-16 13:17 --- Subject: Re: top-level BOOT_CFLAGS not being used for bootstrapping pinskia at gcc dot gnu dot org schrieb: > --- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-15 21:28 > --- > You mentioned BOOT_STRAP in your comment is that correct? > Also did you use "make bootstrap" and not just a plain make? Yes, I did (bootstrap and profiledbootstrap). What happens is, that when I pass i.e. BOOT_CFLAGS="-O3 -s" to make, it actually does get passed, but then is followed by a "-g -O2" resulting in "-O3 -s -O2 -g", which simply clobbers the user's flags. I did not see that earlier when I made that report, sorry. One little thing if I may add: Another triviality is that the Makefiles somehwere do the assumption that following passes will get compiled with gcc and not by an unknown compiler and therefore prepends CFLAGS with -O2 to produce optimized output. This does not cause problems when you pass it -O1 since it will clobber the -O2. However, I think it should not make this assumption or optimisation and leave it all to the user since it might not be wanted or applicable. It is good enough when CFLAGS has a default value that will then be used wherever possible. Sven -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30810
[Bug bootstrap/30810] top-level BOOT_CFLAGS not being used for bootstrapping
--- Comment #4 from sdack at gmx dot de 2007-02-16 13:18 --- Subject: Re: top-level BOOT_CFLAGS not being used for bootstrapping pinskia at gcc dot gnu dot org schrieb: > --- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-16 01:48 > --- >> I believe this is due to BOOT_CFLAGS missing in the top-level's Makefile >> lists > They are passed down, see EXTRA_GCC_FLAGS. Yes, but please see my other email. They are being passed down but then get clobbered. Sven -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30810
[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
--- Comment #7 from tobi at gcc dot gnu dot org 2007-02-16 13:31 ---
The backtrace ends in mpfr_erf, I couldn't go further up. To overcome this
difficulty, I set a breakpoint on the caller, see below.
For the record as there seems to have been some confusion: this bug doesn't
appear during gfortran's constant folding, but during later compilation stages
(as evidenced by its dependence on -O, also I don't think we fold erf at all in
the Fortran FE).
If I find out how I can have my own mpfr and gmp coexist with the fink
libraries, I'll try setting up my own. In the past, attempts I made at doing
this (on Linux) have failed. Looking through the fink scripts, it seems that
its mpfr is a build with no unusual configure arguments, gmp is patched to
disable the assembly fragments but nothing unusual except for that.
Here's what it looks like on entry to do_mpfr_arg1 with Steve's testcase:
(gdb) run -O erf.f
Starting program: /Users/tobi/src/pristine/build/gcc/f951 -O erf.f
MAIN__
Breakpoint 1, do_mpfr_arg1 (arg=0x42692b60, type=0x426f4a80, func=0x3179ab
, min=0x1adcee, max=0x42692000, inclusive=66 'B') at
../../gcc/builtins.c:11923
11923 {
(gdb) p debug_tree (arg)
constant invariant 32>
unit size constant
invariant 4>
align 32 symtab 0 alias set -1 canonical type 0x42692b60 precision 32
pointer_to_this >
$9 = void
(gdb) bt
#0 do_mpfr_arg1 (arg=0x42692b60, type=0x426f4a80, func=0x3179ab
, min=0x1adcee, max=0x42692000, inclusive=66 'B') at
../../gcc/builtins.c:11923
#1 0x000e3e8d in fold_builtin_1 (fndecl=0x426df300, arg0=0x20, ignore=0 '\0')
at ../../gcc/builtins.c:9301
Previous frame inner to this frame (corrupt stack?)
(gdb)
(understanding the stack seems to be a hard problem on Darwin, gdb fails quite
often making it fairly annoying to step through the code)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
--- Comment #8 from tobi at gcc dot gnu dot org 2007-02-16 13:33 --- Oh, just noticed this by chance: Steve's testcase also fails with optimization disabled, again the call to mpfr_erf is issued in do_mpfr_arg1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
[Bug c++/30818] [4.1/4.2/4.3 Regression] templates and typedefs cause function prototype not to match
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-16 13:46 --- *** Bug 30821 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30818
[Bug c++/30821] [4.1.2 Regression] templates and typedefs cause function prototype not to match
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-16 13:46 --- *** This bug has been marked as a duplicate of 30818 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30821
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #7 from armin at xos dot net 2007-02-16 14:00 --- (In reply to comment #5) > > i used the above cflags and it compiled well. and no segmentation faults > > anymore. > > I wouldn't personally recommend -fwrapv, this may uncover other problems. On > the contrary, -fno-strict-aliasing is always safe. with just -fno-strict-aliasing it compiles and executes fine as well. so no -fwrapv needed. -- armin at xos dot net changed: What|Removed |Added CC||armin at xos dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug bootstrap/27822] [4.1 only] fastjar is asking for makeinfo in gmake bootstrap
--- Comment #7 from tony2001 at php dot net 2007-02-16 14:05 --- Still valid for GCC 4.1.2: WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[3]: *** [fastjar.info] Error 1 make[3]: Leaving directory `/space/tony/gcc-4.1.2/host-sparc-sun-solaris2.8/fastjar' make[2]: *** [all] Error 2 make[2]: Leaving directory `/space/tony/gcc-4.1.2/host-sparc-sun-solaris2.8/fastjar' make[1]: *** [all-fastjar] Error 2 make[1]: Leaving directory `/space/tony/gcc-4.1.2' make: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27822
[Bug bootstrap/27822] [4.1 only] fastjar is asking for makeinfo in gmake bootstrap
--- Comment #8 from WILLIAMPAUL dot PHILIBERT at telus dot com 2007-02-16 14:11 --- Subject: RE: [4.1 only] fastjar is asking for makeinfo in gmake bootstrap I found that installing GNU Textutil prior to compiling GCC fix this issue. William Paul Philibert -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27822
[Bug fortran/30512] [4.2, 4.1 only] MAXVAL() incorrect for zero-size int arrays, and for -HUGE-1 maximum values.
--- Comment #12 from burnus at gcc dot gnu dot org 2007-02-16 14:15 --- Subject: Bug 30512 Author: burnus Date: Fri Feb 16 14:15:36 2007 New Revision: 122043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122043 Log: fortran/ 2007-02-16 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30512 * trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc, gfc_conv_intrinsic_minmaxval): Use HUGE-1 for most negative integer. testsuite/ 2007-02-16 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30512 * gfortran.dg/maxlocval_1.f90: New test. libgfortran/ 2007-02-16 Thomas Koenig <[EMAIL PROTECTED]> Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30512 * m4/iparm.m4: Use HUGE-1 for most negative integer. * generated/maxloc1_8_i4.c: Regenerate. * generated/maxloc0_8_i8.c: Regenerate. * generated/maxloc1_16_i4.c: Regenerate. * generated/maxloc0_16_i8.c: Regenerate. * generated/maxval_i4.c: Regenerate. * generated/maxloc1_4_i8.c: Regenerate. * generated/maxloc0_16_i16.c: Regenerate. * generated/maxloc1_4_i16.c: Regenerate. * generated/maxloc0_8_i16.c: Regenerate. * generated/maxloc0_4_i4.c: Regenerate. * generated/maxloc1_8_i8.c: Regenerate. * generated/maxloc0_8_i4.c: Regenerate. * generated/maxloc0_16_i4.c: Regenerate. * generated/maxloc1_16_i8.c: Regenerate. * generated/maxloc1_4_i4.c: Regenerate. * generated/maxval_i8.c: Regenerate. * generated/maxloc0_4_i16.c: Regenerate. * generated/maxloc1_8_i16.c: Regenerate. * generated/maxloc0_4_i8.c: Regenerate. * generated/maxloc1_16_i16.c: Regenerate. * generated/maxval_i16.c: Regenerate. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/maxlocval.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/generated/maxloc0_16_i16.c branches/gcc-4_2-branch/libgfortran/generated/maxloc0_16_i4.c branches/gcc-4_2-branch/libgfortran/generated/maxloc0_16_i8.c branches/gcc-4_2-branch/libgfortran/generated/maxloc0_4_i16.c branches/gcc-4_2-branch/libgfortran/generated/maxloc0_4_i4.c branches/gcc-4_2-branch/libgfortran/generated/maxloc0_4_i8.c branches/gcc-4_2-branch/libgfortran/generated/maxloc0_8_i16.c branches/gcc-4_2-branch/libgfortran/generated/maxloc0_8_i4.c branches/gcc-4_2-branch/libgfortran/generated/maxloc0_8_i8.c branches/gcc-4_2-branch/libgfortran/generated/maxloc1_16_i16.c branches/gcc-4_2-branch/libgfortran/generated/maxloc1_16_i4.c branches/gcc-4_2-branch/libgfortran/generated/maxloc1_16_i8.c branches/gcc-4_2-branch/libgfortran/generated/maxloc1_4_i16.c branches/gcc-4_2-branch/libgfortran/generated/maxloc1_4_i4.c branches/gcc-4_2-branch/libgfortran/generated/maxloc1_4_i8.c branches/gcc-4_2-branch/libgfortran/generated/maxloc1_8_i16.c branches/gcc-4_2-branch/libgfortran/generated/maxloc1_8_i4.c branches/gcc-4_2-branch/libgfortran/generated/maxloc1_8_i8.c branches/gcc-4_2-branch/libgfortran/generated/maxval_i16.c branches/gcc-4_2-branch/libgfortran/generated/maxval_i4.c branches/gcc-4_2-branch/libgfortran/generated/maxval_i8.c branches/gcc-4_2-branch/libgfortran/m4/iparm.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #8 from tony2001 at php dot net 2007-02-16 14:16 --- (In reply to comment #6) > If the trigger happens to be -fstrict-aliasing, it's very likely a violation > of > the type-based aliasing rules of the C/C++ languages. They are usually > exposed > by the scheduler, which is more aggressive on SPARC than on x86 for example. Do you mean it is some kind of "improvement" in GCC 4.x that makes the result binary to segfault in random places when compiled without -fstrict-aliasing ? (GCC 3.x works perfectly fine in the same time ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug fortran/30512] [4.1 only] MAXVAL() incorrect for zero-size int arrays, and for -HUGE-1 maximum values.
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2, 4.1 only] MAXVAL()|[4.1 only] MAXVAL() |incorrect for zero-size int |incorrect for zero-size int |arrays, and for -HUGE-1 |arrays, and for -HUGE-1 |maximum values. |maximum values. Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #24 from paolo at gcc dot gnu dot org 2007-02-16 14:26 --- Subject: Bug 30768 Author: paolo Date: Fri Feb 16 14:26:21 2007 New Revision: 122044 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122044 Log: 2007-02-16 Paolo Carlini <[EMAIL PROTECTED]> Revert. 2007-02-14 Hans-Peter Nilsson <[EMAIL PROTECTED]> PR middle-end/30768 * testsuite/ext/pb_ds/regression/list_update_data_map_rand.cc: Xfail ICE for cris-*-*. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/list_update_data_map_rand.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #25 from pcarlini at suse dot de 2007-02-16 14:28 --- Ok, just reverted the XFAILing. I think Andrew Pinski is already working on reducing the testcase, in case we can also ask Janis to do a binary search. -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug pending/30823] New: ICE on cpu2006/453.povray with -O1 and above
GCC 4.2 fails to compile spec cpu2006/453.povray benchmark sources at -O1 and above optimization level both on x86_64-redhat-linux and i386-redhat-linux. Compiler must be configured with '--enable-checking' to see this failure. messageoutput.cpp: In constructor 'pov_frontend::MessageOutput::MessageOutput(void*)': messageoutput.cpp:13: internal compiler error: in sra_build_assignment, at tree-sra.c:1661 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. It appears that the regression has been introduced with GCC 4.2 revision 122009, which is "SRA and inconsistencies in bit-field types" patch http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01126.html. PS: that would take some time to get a minimal reproducer. -- Summary: ICE on cpu2006/453.povray with -O1 and above Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pending AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grigory_zagorodnev at linux dot intel dot com GCC host triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30823
[Bug c++/13088] templatizing outer class hides specialization of inner template class
--- Comment #26 from twhitehe at uwo dot ca 2007-02-16 15:04 ---
There is actually two different bugs here.
The original bug is a (rather convoluted) duplicate of 4882. It still remains
unresolved as of gcc-4.1.
The nested_deduction.zip source, which was submitted much later, demonstrated a
different problems. Nested templates didn't match on template template
specializations. A vastly simplified (over the nested_deductions code) example
is:
template
struct A {
template
struct B { };
};
template
struct C { };
template class c,typename t>
struct C > {
typedef int type;
};
int main(void) {
C >::type val0 = 0;
C::B >::type val1 = 0; // Dies here
return val0+val1;
}
With earlier versions of gcc, this would give the error
Simplified.cpp:17: error: `type' is not a member of type `C::B
>',
with gcc 4.1 it now compiles fine.
I appear, however, to not have the power to change the status of this report,
so someone else will have to.
--
twhitehe at uwo dot ca changed:
What|Removed |Added
CC||twhitehe at uwo dot ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13088
[Bug pending/30823] ICE on cpu2006/453.povray with -O1 and above
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-16 15:05 --- Can you attach unreduced preprocessed source? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30823
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #15 from twhitehe at uwo dot ca 2007-02-16 15:10 --- This is a duplicate of 4882, however, I don't have the power to mark it as that (not that that would necessarily be a good thing as this contains more recent begging and is flagged with a higher priority). -- twhitehe at uwo dot ca changed: What|Removed |Added CC||twhitehe at uwo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug pending/30823] ICE on cpu2006/453.povray with -O1 and above
--- Comment #2 from grigory_zagorodnev at linux dot intel dot com 2007-02-16 15:16 --- Created an attachment (id=13054) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13054&action=view) Slightly minimized failing source file run 'g++ -c -O2 messageoutput.i' to reproduce the failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30823
[Bug target/30813] Numerical error--#define value differs from declared variable value
--- Comment #3 from kevin dot glass at pnl dot gov 2007-02-16 15:29 --- I ran this on a Pentium III and a Pentium IV using gcc 3.4.5 and gcc 4.01(?). These produced incorrect results. I also ran them on an itanium using an older gcc (2.9.2) in these cases, it produced correct results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30813
[Bug c++/8715] '~' operator for unsigned char and conversion to bool
--- Comment #10 from manu at gcc dot gnu dot org 2007-02-16 15:33 --- (In reply to comment #9) > (In reply to comment #8) > > I meant that the warning is appropriate but > > the message is confusing because it is exposing that when doing > > > > bool x = ~b; > > > > we actually do > > > > bool x = (~b != 0); > > > Or, more precisely, > bool x = (~(int) b) != 0; > > > So an appropriate message would say something like: > > > > test.cpp:5: warning: '(bool) ~b' is always true > > > Don't you agree? > > > > Yes, that would be nice, but hard to implement. > Isn't any way to tell that "!= 0" was introduced by GCC rather than by the original source code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8715
[Bug c++/20201] requesting -Wfatal-errors=n
--- Comment #6 from manu at gcc dot gnu dot org 2007-02-16 15:43 --- (In reply to comment #5) > I agree with Manuel. One error should be one error, regardless of the number > of > lines it takes to print it. > > Two errors should be two errors, etc etc etc. > > Seems like a pretty simple rule to me. > > I find myself wishing for this rule more and more as metaprogramming becomes > more and more established in the C++ community. > I think -Wfatal-errors=n is the wrong fix to a broader problem. I have read the thread started by Jim Wilson and I concluded two things: 1) People are annoyed by GCC spilling lots of error messages for a single error. So they want to use -Wfatal-errors. 2) Sometimes a single error message does not contain enough information to identify the source of the problem (see PR 15766). I think both issues should be reported as bugs always.[*] I have seen a lot of messages in forums and blogs complaining that GCC error messages are confusing or redundant or simply too many errors for a single issue. However, there are less than 20 PRs open for cases like these. I hope it is not because the PRs have been being closed systematically since the error messages are *true*. The messages can be completely *true* and conforming to the standards but that doesn't mean that they are *useful* (see PR 29062). Perhaps it sounds strange but a compiler can have usability issues. And GCC haves them. [*] Also, they are normally the kind of low-hanging fruit that could attract occassional contributors that don't have much free time to hack on a big project but are willing to dedicate two or three hours of a raining weekend to fix a PR like that. That is, like me ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20201
[Bug c++/30822] wrong choice of overloaded template functions in recursive call
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-16 15:47 --- // now the order changed and the compiler complains! I think GCC 4.1.x and above are doing the correct behavior with respect of the C++ standard. The C++ standard has specific rules about namelookup in templates which differs from what most people think they are as before GCC 4.1.x did not implement them and I think Microsoft's VS also still does not implement them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30822
[Bug tree-optimization/30823] [4.2/4.3 Regression] ICE on cpu2006/453.povray with -O1 and above
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|pending |tree-optimization Summary|ICE on cpu2006/453.povray |[4.2/4.3 Regression] ICE on |with -O1 and above |cpu2006/453.povray with -O1 ||and above Target Milestone|--- |4.2.0 Version|4.2.1 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30823
[Bug fortran/30720] [4.1 only] runtime: check for empty array slices before allocating a negative amount of memory
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-02-16 15:55 --- Fixed on mainline and 4.2. Empty slices are hopelessly broken on 4.1, I think, so closing. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.2.0 4.1.2 |4.1.2 Known to work|4.3.0 |4.3.0 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30720
[Bug fortran/30611] [4.1 only] Confusing error message for negative ncopies in REPEAT
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-16 15:55 --- Fixed on 4.2 and mainline. Closing. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.2.0 4.1.2 |4.1.2 Known to work|4.3.0 |4.3.0 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30611
[Bug fortran/30389] [4.1 only] ACHAR() intrinsic gives erroneous errors in constant-folding.
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-02-16 15:56 --- Fixed on mainline and 4.2. Unless you really want to backport it to 4.1.3, I'm closing this bug. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.2.0 | Known to work|4.3.0 |4.3.0 4.2.0 Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30389
[Bug fortran/30381] [4.1 only] ISHFTC() constant folding is broken.
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-02-16 15:56 --- Fixed on mainline and 4.2. Unless you really want to backport it to 4.1.3, I'm closing this bug. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30381
[Bug fortran/30420] [4.1 only] IBCLR() fails to properly handle clearing the sign bit.
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-02-16 15:57 --- Fixed on mainline and 4.2. Unless you really want to backport it to 4.1.3, I'm closing this bug. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30420
[Bug c/30824] New: -Werror -Wfatal-errors should stop after the first warning
Testcase:
void f(int c)
{
return c;
}
int g(int c)
{
return;
}
~$ gcc -Wreturn-type -c test.c -Werror -Wfatal-errors
cc1: warnings being treated as errors
test.c: In function f:
test.c:3: warning: return with a value, in function returning void
test.c: In function g:
test.c:8: warning: return with no value, in function returning non-void
If should have stopped after the first warning.
--
Summary: -Werror -Wfatal-errors should stop after the first
warning
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30824
[Bug c/30824] -Werror -Wfatal-errors should stop after the first warning
--- Comment #1 from manu at gcc dot gnu dot org 2007-02-16 15:59 --- > If should have stopped after the first warning. I meant "It should have". -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30824
[Bug c/11051] -Wno-deprecated needed also for C
--- Comment #13 from manu at gcc dot gnu dot org 2007-02-16 16:04 --- (In reply to comment #12) > Subject: Re: -Wno-deprecated needed also for C > > manu at gcc dot gnu dot org wrote: > > > > Wouldn't it be better to remove the dead code? Or is there a policy against > > touching things that are not broken? I think that at least one comment on > > the > > code would be appropriate. > > > > The dead code should presumably be removed, too. > OK. But back to this PR. Is there anything deprecated in the C front-end that would be suitable for -Wno-deprecated ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
[Bug fortran/25020] NAG extension: module F90_UNIX providing access to UNIX functions (abort ...)
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-16 16:05 --- Harald, if you were to assign copyright of your code (or modified code) to the FSF by filing a copyright assignment, we could integrate that into gfortran. [I don't think you have a copyright assignment, do you?] So, if you want to integrate it, please ask on the list how to get sent the form (it comes by snail mail, so it takes some time to receive and send back). Otherwise, please close this PR. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25020
[Bug fortran/27989] -fbounds-check should check for too small arrays on subroutine calls
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-16 16:07:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27989
[Bug fortran/30814] non-conforming array sizes in PACK should raise an error
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||27766 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-redhat-linux | GCC host triplet|x86_64-redhat-linux | GCC target triplet|x86_64-redhat-linux | Keywords||diagnostic Known to work||4.2.0 4.3.0 4.1.3 Last reconfirmed|-00-00 00:00:00 |2007-02-16 16:08:46 date|| Summary|non-conforming array sizes |non-conforming array sizes |in assignment using pack not|in PACK should raise an |caught |error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30814
[Bug fortran/30676] Incomplete warning on non-conforming code with -fopenmp
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-02-16 16:09:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30676
[Bug bootstrap/30825] New: current mainline fails to bootstrap with --with-arch=athlon64
Hi, current mainline (revision 122038) produces an ICE in stage 2 when configured with --with-arch=athlon64: ~/rcs-data/gcc-svn/configure --prefix=$HOME/env/gcc --enable-languages=c --with-arch=athlon64 && make ... /home/julian/build/bld.gcc/./gcc/xgcc -B/home/julian/build/bld.gcc/./gcc/ -B/home/julian/env/gcc/i686-pc-linux-gnu/bin/ -B/home/julian/env/gcc/i686-pc-linux-gnu/lib/ -isystem /home/julian/env/gcc/i686-pc-linux-gnu/include -isystem /home/julian/env/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2 -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/home/julian/rcs-data/gcc-svn/libgcc -I/home/julian/rcs-data/gcc-svn/libgcc/. -I/home/julian/rcs-data/gcc-svn/libgcc/../gcc -I/home/julian/rcs-data/gcc-svn/libgcc/../include -I/home/julian/rcs-data/gcc-svn/libgcc/../libdecnumber -I../../libdecnumber -o _fixunsxfdi.o -MT _fixunsxfdi.o -MD -MP -MF _fixunsxfdi.dep -DL_fixunsxfdi -c /home/julian/rcs-data/gcc-svn/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS /home/julian/rcs-data/gcc-svn/libgcc/../gcc/libgcc2.c: In function '__fixunsxfdi': /home/julian/rcs-data/gcc-svn/libgcc/../gcc/libgcc2.c:1245: error: verify_flow_info: Wrong probability of edge 7->9 -2147483648 /home/julian/rcs-data/gcc-svn/libgcc/../gcc/libgcc2.c:1245: error: verify_flow_info: Wrong probability of edge 7->8 -2147473648 /home/julian/rcs-data/gcc-svn/libgcc/../gcc/libgcc2.c:1245: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [_fixunsxfdi.o] Error 1 make[3]: Leaving directory `/home/julian/build/bld.gcc/i686-pc-linux-gnu/libgcc' make[2]: *** [all-stage2-target-libgcc] Error 2 make[2]: Leaving directory `/home/julian/build/bld.gcc' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/julian/build/bld.gcc' make: *** [all] Error 2 When configured without --with-arch=athlon64 the build succeeds. The problem has probably been introduced since 2007-02-09. -- Summary: current mainline fails to bootstrap with --with- arch=athlon64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvb at wongr dot net GCC host triplet: i386-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30825
[Bug libfortran/23770] unaligned buffers in i/o library force use of memcpy()
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-02-16 16:15 --- OK, given that we now have a fine memcpy code generation and nobody seems to have an example, I'm closing this. Please reopen if you think I'm wrong. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23770
[Bug fortran/30123] Document INQUIRE, especially UNFORMATTED and FORMATTED
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-16 16:19:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30123
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-16 16:21:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug c++/30822] wrong choice of overloaded template functions in recursive call
--- Comment #2 from Zarathustra at gentlemansclub dot de 2007-02-16 16:35 --- I know the rules for template function name lookup are complicated, and I do not claim that I understand them completely. But I am pretty sure that the order of the definitions should not matter. There is a partial ordering of template functions to decide which function is used. This ordering depends on which function is "more specialized" than the other, but not the sequence of the definitions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30822
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-02-16 16:44 --- > Do you mean it is some kind of "improvement" in GCC 4.x that makes the result > binary to segfault in random places when compiled without -fstrict-aliasing ? No, -fstrict-aliasing is not new, it's there since GCC 2.95 and the rules haven't changed since then. But GCC 4 is much more aggressive than GCC 3 in some cases and this may uncover subtle aliasing violations in the code. See the section in the manual about -fstrict-aliasing. Or this could be a bug in the compiler. That's why it would be interesting to try with the 4.1.2 release too. In either case, someone familiar with the PHP code will have to determine what goes wrong exactly. Only then will we be able to find a remedy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #26 from hp at gcc dot gnu dot org 2007-02-16 17:01 --- Paolo Carlini, why did you revert the xfail? That's *not* according to procedure. I really resent that, but please discuss the issue on the gcc@ or gcc-patches@ lists, not here. If it was the extra FAIL lines for ICEing targets, I now know how to limit the xfail using dg-xfail-if. I also don't see any message on gcc-patches@ or libstdc++@ about the reversion. Regarding binary search, I suggest you read the description of this PR. The revision exposing the bug is already identified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #27 from pcarlini at suse dot de 2007-02-16 17:04 --- (In reply to comment #26) > Paolo Carlini, why did you revert the xfail? That's *not* according to > procedure. You can resent whatever you want, but I'm maintaining the library and both Benjamin (another maintainer) and Diego are with me. Therefore the discussion ends together with the unnecessary noise your commit produced. > The revision exposing the bug is already identified. Excellent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug c++/23689] Malformed typedef silently ignored
--- Comment #6 from patchapp at dberlin dot org 2007-02-16 17:17 --- Subject: Bug number PR c++/23689 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-02/msg00114.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23689
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #10 from tony2001 at php dot net 2007-02-16 17:33 --- >That's why it would be interesting to try with the 4.1.2 release too. Well, to do that I need to compile it first. Still working on that - compiling GCC on Solaris is a big deal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug other/30083] double quotes in Makefile confuse solaris /bin/sh
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2007-02-16 17:40 --- This is a duplicate of 27843 (Solaris and Tru64 /bin/sh share the same issue), which has been resolved as fixed. :-) Someone empowered enough please reflect this in the settings, thank you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30083
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-02-16 17:41 --- > Still working on that - compiling GCC on Solaris is a big deal. That depends on what "big deal" means. :-) You just have to unpack the tarball and follow the instructions at http://gcc.gnu.org/install/specific.html#x-x-solaris2 http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2 and http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2 for the 64-bit compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug tree-optimization/30826] New: alignment error when optimizing with inlining
Attached test program dumps core when built with optimization using gcc-4.1.1 on ia64-hp-hpux11.23. It works without optimization, or when using "-O1 -fno-inline". It is same both with HP's gcc-4.1.1 as well with self-built gcc-4.1.1, both using GNU as. $ /opt/hp-gcc-4.1.1/bin/gcc -v Using built-in specs. Target: ia64-hp-hpux11.23 Configured with: /tmp/gcc-4.1.1.tar.gz/gcc-4.1.1/configure --host=ia64-hp-hpux11.23 --target=ia64-hp-hpux11.23 --build=ia64-hp-hpux11.23 --prefix=/opt/hp-gcc-4.1.1 --enable-languages=c,c++ --with-gnu-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix Thread model: posix gcc version 4.1.1 $ /opt/hp-gcc-4.1.1/bin/gcc inline.c $ ./a.out $ /opt/hp-gcc-4.1.1/bin/gcc inline.c -O1 $ ./a.out Bus error (core dumped) $ /opt/langtools/bin/gdb a.out HP gdb 5.6.0 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 5.6.0 (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. ..(no debugging symbols found)... (gdb) r Starting program: /mnt/big/logins/haubi/a.out (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)... Program received signal SIGBUS, Bus error si_code: 1 - BUS_ADRALN - Invalid address alignment. 0x20007edb4130:0 in mallinfo+0x180 () from /usr/lib/hpux32/libc.so.1 (gdb) bt #0 0x20007edb4130:0 in mallinfo+0x180 () from /usr/lib/hpux32/libc.so.1 #1 0x40008b0:0 in main+0x30 () (gdb) -- Summary: alignment error when optimizing with inlining Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot haubenwallner at salomon dot at GCC build triplet: ia64-hp-hpux11.23 GCC host triplet: ia64-hp-hpux11.23 GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30826
[Bug tree-optimization/30826] alignment error when optimizing with inlining
--- Comment #1 from michael dot haubenwallner at salomon dot at 2007-02-16 17:50 --- Created an attachment (id=13055) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13055&action=view) testcase, extracted from preprocessor output of real application code. Have looked at assembler output: There is a difference in call to mallinfo() from f1(), when f2() is empty, or when using 'long long' as datatype for 'status'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30826
[Bug tree-optimization/30826] alignment error when optimizing with inlining
--- Comment #2 from michael dot haubenwallner at salomon dot at 2007-02-16 17:56 --- Created an attachment (id=13056) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13056&action=view) the failing assembler output, created with '-O1' Have the focus on line 18: 18 adds r8 = 20, r12 19 br.call.sptk.many b0 = mallinfo# -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30826
[Bug tree-optimization/30826] alignment error when optimizing with inlining
--- Comment #3 from michael dot haubenwallner at salomon dot at 2007-02-16 17:58 --- Created an attachment (id=13057) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13057&action=view) assembler output without the bug-trigger, built with '-O1 -DNOTRIGGER' Again, focus on line 18: 18 adds r8 = 16, r12 19 br.call.sptk.many b0 = mallinfo# -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30826
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #13 from mrs at apple dot com 2007-02-16 17:59 --- Adding inline seems obvious to me, all the other functions are marked inline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug tree-optimization/30826] alignment error when optimizing with inlining
--- Comment #4 from michael dot haubenwallner at salomon dot at 2007-02-16 18:06 --- Have already debugged inside mallinfo(), where gdb says: Program received signal SIGBUS, Bus error si_code: 1 - BUS_ADRALN - Invalid address alignment. 0x20007edb4130:0 in mallinfo+0x180 () from /usr/lib/hpux32/libc.so.1 The disassembly snippet of mallopt() is: (gdb) disassemble $pc $pc+0x10 Dump of assembler code from 0x20007edb4130:0 to 0x20007edb4140:0: 0x20007edb4130:0 :st8 [r79]=r9 0x20007edb4130:1 :st8 [r38]=r8,8 0x20007edb4130:2 :adds r14=-8,r11;; End of assembler dump. (gdb) p /x $r79 $2 = 0x20007fffe914 (gdb) The value of r79 comes from that r8 set on line#18, which is incorrectly aligned to 4 when calculated from '20, r12'. Seems that it needs to be aligned to 8 for 'st8'... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30826
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #12 from tony2001 at php dot net 2007-02-16 18:12 --- Yes, sounds really easy. But the fact is that Solaris is very useful platform - if there are any hidden bugs/problems/whatever, you can be sure you'll encounter them on Solaris. - native tar fails to unpack the archive (had to unpack it on Linux and copy to Solaris); - fastjar compilation requires "makeinfo" (had to patch Makefile to make it work); see Bug 27822 - native sed doesn't work (had to install GNU sed); - GNU sed failed either (see http://gcc.gnu.org/ml/gcc/2007-02/msg00039.html, the patch does help); - gperf was missing and there was no configure check for it (had to install gperf); So it took only 2-3 hours to get this: /space/tony/bin/gcc -m64 conftest.c >&5 ld: fatal: file elf64_sparc: open failed: No such file or directory Any idea how to make it work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug fortran/29507] INDEX in an array initialization causes ICE
--- Comment #4 from pault at gcc dot gnu dot org 2007-02-16 18:22 --- Thanks for the reminder - I had not forgotten. I am trying to work my way through the list with very limited time. I'll get there though! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29507
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-02-16 18:32 --- > - fastjar compilation requires "makeinfo" (had to patch Makefile to make it > work); see Bug 27822 Do not build Java. > - native sed doesn't work (had to install GNU sed); GNU sed is not required. > - GNU sed failed either (see http://gcc.gnu.org/ml/gcc/2007-02/msg00039.html, > the patch does help); You didn't set CONFIG_SHELL. > - gperf was missing and there was no configure check for it (had to install > gperf); Why on Earth do you need gperf? > So it took only 2-3 hours to get this: > /space/tony/bin/gcc -m64 conftest.c >&5 > ld: fatal: file elf64_sparc: open failed: No such file or directory Do not use GNU binutils. > Any idea how to make it work? Use the Sun tools, read the instructions, build only C/C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug c++/4882] fails to lookup a template specialization dependent of an outer template
--- Comment #10 from bangerth at dealii dot org 2007-02-16 18:39 --- This is a duplicate of PR14032, which has more information on the matter than the present one. W. *** This bug has been marked as a duplicate of 14032 *** -- bangerth at dealii dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4882
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #16 from bangerth at dealii dot org 2007-02-16 18:39 --- *** Bug 4882 has been marked as a duplicate of this bug. *** -- bangerth at dealii dot org changed: What|Removed |Added CC||duret_g at epita dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #14 from armin at xos dot net 2007-02-16 18:40 --- Subject: Re: php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit > Use the Sun tools, read the instructions, build only C/C++. that's how i did it: CC="cc -xarch=v9" configure --prefix=/usr/local --enable-languages=c,c++ --enable-shared sparcv9-sun-solaris2.9 on solaris 2.9. take care to have the 64bit compiler and 64bit linker in your path first. and take care of the LD_LIBRARY_PATH as well. just 64bit. other than that and maybe 1-2 gnu tools there is no problem. well yes: make install installes some 32bit libraries into lib, but you find the 64bit ones in your build tree. just copy them over. i dunno why that is. (there is a spracv7 dir and those get instlled). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #17 from bangerth at dealii dot org 2007-02-16 18:47 --- If anyone ever fixes this, the various duplicates of this bug have a number of interesting variants that may be worth adding to the testsuite as well. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #15 from tony2001 at php dot net 2007-02-16 18:53 --- (In reply to comment #14) > Subject: Re: php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit > > > Use the Sun tools No Sun compilere here. > read the instructions, build only C/C++. That's what I did. > CC="cc -xarch=v9" configure --prefix=/usr/local --enable-languages=c,c++ > --enable-shared sparcv9-sun-solaris2.9 > > on solaris 2.9. take care to have the 64bit compiler and 64bit linker in your > path first. > well yes: make install installes some 32bit libraries into lib, but you find > the 64bit ones in your build tree. I'm sorry to say that, but there are none. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2007-02-16 19:00 --- > No Sun compiler here. The Sun tools are /usr/ccs/bin/as and /usr/ccs/bin/ld . > > read the instructions, build only C/C++. > > That's what I did. Did you set CONFIG_SHELL? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug bootstrap/30810] top-level BOOT_CFLAGS not being used for bootstrapping
--- Comment #5 from sdack at gmx dot de 2007-02-16 19:03 --- What I now did was the following: I set CFLAGS, CXXFLAGS, LIBCFLAGS, LIBCXXFLAGS and BOOT_CFLAGS on the command line to make to: "-pipe -march=athlon-xp -msse -mmmx -m3dnow -mfpmath=sse -O3 -mpreferred-stack-boundary=6 -falign-functions=64 -falign-jumps=64 -fomit-frame-pointer -fforce-addr -fno-keep-static-consts -fgcse-sm -fgcse-las -fgcse-after-reload -floop-optimize2 -fsched2-use-superblocks -ftree-loop-linear -ftree-loop-im -ftree-loop-ivcanon -fivopts -ftree-vectorize -ftracer -fsplit-ivs-in-unroller -fvariable-expansion-in-unroller -freorder-blocks-and-partition" I want to do this to see what I get as a result. I then get during the first build of libcpp this: ... make[3]: Entering directory `/home/sven/obj/stage1-libcpp' gcc -I../../gcc-4.1.2/libcpp -I. -I../../gcc-4.1.2/libcpp/../include -I../../gcc-4.1.2/libcpp/include -g -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -I../../gcc-4.1.2/libcpp -I. -I../../gcc-4.1.2/libcpp/../include -I../../gcc-4.1.2/libcpp/include -c -o charset.o -MT charset.o -MD -MP -MF .deps/charset.Po ../../gcc-4.1.2/libcpp/charset.c ... None of the flags I passed are being used but I currently do not see a reason why they should not. Later on libgcc: ... /home/sven/obj/./gcc/xgcc -B/home/sven/obj/./gcc/ -B/home/sven/gnu/i686-pc-linux-gnu/bin/ -B/home/sven/gnu/i686-pc-linux-gnu/lib/ -isystem /home/sven/gnu/i686-pc-linux-gnu/include -isystem /home/sven/gnu/i686-pc-linux-gnu/sys-include -O2 -O2 -pipe -march=athlon-xp -msse -mmmx -m3dnow -mfpmath=sse -O3 -mpreferred-stack-boundary=6 -falign-functions=64 -falign-jumps=64 -fomit-frame-pointer -fforce-addr -fno-keep-static-consts -fgcse-sm -fgcse-las -fgcse-after-reload -floop-optimize2 -fsched2-use-superblocks -ftree-loop-linear -ftree-loop-im -ftree-loop-ivcanon -fivopts -ftree-vectorize -ftracer -fsplit-ivs-in-unroller -fvariable-expansion-in-unroller -freorder-blocks-and-partition -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc-4.1.2/gcc -I../../gcc-4.1.2/gcc/. -I../../gcc-4.1.2/gcc/../include -I../../gcc-4.1.2/gcc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \ -c ../../gcc-4.1.2/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o ... All flags are now being used but also a "-O2 -O2" shows up. That is no problem at all but could get cleaned out anyway. Next, again libcpp but during the first stage: ... make[3]: Entering directory `/home/sven/obj/stageprofile-libcpp' /home/sven/obj/./prev-gcc/xgcc -B/home/sven/obj/./prev-gcc/ -B/home/sven/gnu/i686-pc-linux-gnu/bin/ -I../../gcc-4.1.2/libcpp -I. -I../../gcc-4.1.2/libcpp/../include -I../../gcc-4.1.2/libcpp/include -O2 -g -fomit-frame-pointer -fprofile-generate -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -I../../gcc-4.1.2/libcpp -I. -I../../gcc-4.1.2/libcpp/../include -I../../gcc-4.1.2/libcpp/include -c -o charset.o -MT charset.o -MD -MP -MF .deps/charset.Po ../../gcc-4.1.2/libcpp/charset.c ... Now there is a "-O2 -g -fomit-frame-pointer" but again none of my flags. In any case that should be identical to the first build of libcpp, shouldn't it? Next is another build of libgcc: ... /home/sven/obj/./gcc/xgcc -B/home/sven/obj/./gcc/ -B/home/sven/gnu/i686-pc-linux-gnu/bin/ -B/home/sven/gnu/i686-pc-linux-gnu/lib/ -isystem /home/sven/gnu/i686-pc-linux-gnu/include -isystem /home/sven/gnu/i686-pc-linux-gnu/sys-include -O2 -O2 -pipe -march=athlon-xp -msse -mmmx -m3dnow -mfpmath=sse -O3 -mpreferred-stack-boundary=6 -falign-functions=64 -falign-jumps=64 -fomit-frame-pointer -fforce-addr -fno-keep-static-consts -fgcse-sm -fgcse-las -fgcse-after-reload -floop-optimize2 -fsched2-use-superblocks -ftree-loop-linear -ftree-loop-im -ftree-loop-ivcanon -fivopts -ftree-vectorize -ftracer -fsplit-ivs-in-unroller -fvariable-expansion-in-unroller -freorder-blocks-and-partition -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc-4.1.2/gcc -I../../gcc-4.1.2/gcc/. -I../../gcc-4.1.2/gcc/../include -I../../gcc-4.1.2/gcc/../libcpp/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \ -c ../../gcc-4.1.2/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o ... This again includes a "-O2 -O2". The first time it appears to be working the way I think it should is here: ... make[3]: Entering directory `/home/sven/obj/stagefeedback-libiberty' if [ x"" != x ] && [ ! -d pic ]; then \ mkdir pic; \ else true; fi tou
[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
--- Comment #9 from ghazi at gcc dot gnu dot org 2007-02-16 19:13 --- (In reply to comment #8) > Oh, just noticed this by chance: Steve's testcase also fails with optimization > disabled, again the call to mpfr_erf is issued in do_mpfr_arg1. Do you get a failure with a C testcase equivalent to Steve's fortran one? Does the GCC testcase gcc.dg/torture/builtin-math-3.c pass for you? That one tests for erf(1.0) and erf(-1.0). I'm curious if it's the value 1.5 or whether having it come from the fortran frontend (or either/both) which is the bug trigger. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
[Bug middle-end/30816] gfortran.dg/g77/intrinsic-unix-erf.f tests fail with optimization
--- Comment #10 from ghazi at gcc dot gnu dot org 2007-02-16 19:23 --- (In reply to comment #7) > The backtrace ends in mpfr_erf, I couldn't go further up. To overcome this > difficulty, I set a breakpoint on the caller, see below. That's perhaps because mpfr_erf is called from do_mpfr_arg1 via a function pointer rather than directly, which confuses gdb (I'm guessing). > the Fortran FE). > If I find out how I can have my own mpfr and gmp coexist with the fink > libraries, I'll try setting up my own. In the past, attempts I made at doing > this (on Linux) have failed. Looking through the fink scripts, it seems that > its mpfr is a build with no unusual configure arguments, gmp is patched to > disable the assembly fragments but nothing unusual except for that. To have your own gmp/mpfr co-exist, simply build them yourself and install them in some private directory. Configure then as none-apple-darwin I think. Make sure you run "make check" for both libraries before installing them and make sure everything passes. Then when configuring gcc, pass the configure flag --with-gmp=PATH --with-mpfr=PATH. Run the top level configure --help for more docs on those flags. Note if gmp and mpfr are installed in the same prefix, then you only need one of the two flags, but having both should not hurt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
