[Bug libstdc++/21295] Configuring g++ library for various locales ?
--- Additional Comments From jpr at essi dot fr 2005-05-01 06:10 ---
Subject: Re: Configuring g++ library for various locales
?
pcarlini at suse dot de wrote:
--- Additional Comments From pcarlini at suse dot de 2005-04-30 21:24
---
For that kind of GNU x86-linux platform we have, literally, thousands of
succesful reports, everything is supposed to work well out-of-the-box. In
particular, the GNU locale model, supporting named locales is selected
automatically, by default.
I can try to help you a bit figuring out what's wrong with your specific
setup but this isn't really our job, here, sorry.
I understand this, but I also understant that we are all committed to
improve the quality of the free tools we use :-)
Anyway, are you building GCC? You should do that if you want to double check
that the right (GNU) locale model is actually used. You can check whether
this is the case by ooking at c++locale.h header in your install directory,
under /include/c++/4.0.0/i686-pc-linux-gnu/bits. Close to the beginning of
the file you should find something like:
#if __GLIBC__ 2 || (__GLIBC__ == 2 __GLIBC_MINOR__ 2)
namespace __gnu_cxx
{
extern C __typeof(uselocale) __uselocale;
}
#endif
Then, we can actually understand whether the problem begins at GCC configure
and build time.
That's the point, I do not have these lines (I attach my c++locale.h
from my 4.0.0 by=uild, since it is short).
Jean-Paul Rigault
// Wrapper for underlying C-language localization -*- C++ -*-
// Copyright (C) 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 2, or (at your option)
// any later version.
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along
// with this library; see the file COPYING. If not, write to the Free
// Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307,
// USA.
// As a special exception, you may use this file as part of a free software
// library without restriction. Specifically, if other files instantiate
// templates or use macros or inline functions from this file, or you compile
// this file and link it with other files to produce an executable, this
// file does not by itself cause the resulting executable to be covered by
// the GNU General Public License. This exception does not however
// invalidate any other reasons why the executable file might be covered by
// the GNU General Public License.
//
// ISO C++ 14882: 22.8 Standard locale categories.
//
// Written by Benjamin Kosnik [EMAIL PROTECTED]
#ifndef _C_LOCALE_H
#define _C_LOCALE_H 1
#pragma GCC system_header
#include clocale
#include cstring // get std::strlen
#include cstdio// get std::snprintf or std::sprintf
#define _GLIBCXX_NUM_CATEGORIES 0
namespace std
{
typedef int* __c_locale;
// Convert numeric value of type _Tv to string and return length of
// string. If snprintf is available use it, otherwise fall back to
// the unsafe sprintf which, in general, can be dangerous and should
// be avoided.
templatetypename _Tv
int
__convert_from_v(char* __out,
const int __size __attribute__((__unused__)),
const char* __fmt,
_Tv __v, const __c_locale, int __prec)
{
char* __old = std::setlocale(LC_NUMERIC, NULL);
char* __sav = NULL;
if (std::strcmp(__old, C))
{
__sav = new char[std::strlen(__old) + 1];
std::strcpy(__sav, __old);
std::setlocale(LC_NUMERIC, C);
}
#ifdef _GLIBCXX_USE_C99
const int __ret = std::snprintf(__out, __size, __fmt, __prec, __v);
#else
const int __ret = std::sprintf(__out, __fmt, __prec, __v);
#endif
if (__sav)
{
std::setlocale(LC_NUMERIC, __sav);
delete [] __sav;
}
return __ret;
}
}
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21295
[Bug java/21313] New: Incorrect visibility of package scope methods (compilation problem)
Linux (Fedora Core 3)
Pentium M
GCC 4.0.0
Compiling the following two classes produces error:
p2/B.java:7: error: Method p1.A.f(int) was defined with return type
booleanin class p1.A.
void f( int x ) {}
/// A.java ///
package p1;
public class A
{
boolean f( int x ) { return false; }
}
/// B.java ///
package p2;
import p1.A;
public class B extends A
{
void f( int x ) {}
}
//
To reproduce place A.java in a directory p1, and B.java in directory p2.
Then compile B.java: gcj -C p2/B.java
A.f(...) should not be visible to class B and hence not cause this compilation
error. Sun's javac compiles these classes without error.
--
Summary: Incorrect visibility of package scope methods
(compilation problem)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lhofhansl at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21313
[Bug rtl-optimization/19579] [3.3 regression] -march=i686 generates a bogus program for x86*
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01 07:23 --- Subject: Bug 19579 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2005-05-01 07:23:20 Modified files: gcc: ChangeLog ifcvt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050124-1.c Log message: PR rtl-optimization/19579 Backport from mainline 2005-01-26 Jakub Jelinek [EMAIL PROTECTED] * ifcvt.c (noce_try_cmove_arith): If emitting instructions to set up both A and B, see if they don't clobber registers the other expr uses. * gcc.c-torture/execute/20050124-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.1067r2=1.16114.2.1068 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ifcvt.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.105.4.9r2=1.105.4.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.2261.2.399r2=1.2261.2.400 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050124-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=NONEr2=1.1.32.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579
[Bug c/21275] [4.0/4.1 Regression] gcc 4.0.0 crash with mingw when using stdout in global var
--- Additional Comments From dannysmith at users dot sourceforge dot net 2005-05-01 08:00 --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
[Bug tree-optimization/18316] Missed IV optimization
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01 08:08 --- Subject: Bug 18316 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-01 08:08:14 Modified files: gcc: ChangeLog tree-scalar-evolution.c tree-scalar-evolution.h tree-ssa-loop-ivopts.c tree-ssa-loop-manip.c tree-ssa-loop-niter.c tree.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: loop-8.c Log message: PR tree-optimization/18316 PR tree-optimization/19126 * tree.c (build_int_cst_type): Avoid shift by size of type. * tree-scalar-evolution.c (simple_iv): Add allow_nonconstant_step argument. * tree-scalar-evolution.h (simple_iv): Declaration changed. * tree-ssa-loop-ivopts.c (struct iv_cand): Add depends_on field. (dump_cand): Dump depends_on information. (determine_biv_step): Add argument to simple_iv call. (contains_abnormal_ssa_name_p): Handle case expr == NULL. (find_bivs, find_givs_in_stmt_scev): Do not require step to be a constant. (add_candidate_1): Record depends_on for candidates. (tree_int_cst_sign_bit, constant_multiple_of): New functions. (get_computation_at, get_computation_cost_at, may_eliminate_iv): Handle ivs with nonconstant step. (iv_ca_set_remove_invariants, iv_ca_set_add_invariants): New functions. (iv_ca_set_no_cp, iv_ca_set_cp): Handle cand-depends_on. (create_new_iv): Unshare the step before passing it to create_iv. (free_loop_data): Free cand-depends_on. (build_addr_strip_iref): New function. (find_interesting_uses_address): Use build_addr_strip_iref. (strip_offset_1): Split the recursive part from strip_offset. Strip constant offset component_refs and array_refs. (strip_offset): Split the recursive part to strip_offset_1. (add_address_candidates): Removed. (add_derived_ivs_candidates): Do not use add_address_candidates. (add_iv_value_candidates): Add candidates with stripped constant offset. Consider all candidates with initial value 0 important. (struct affine_tree_combination): New. (aff_combination_const, aff_combination_elt, aff_combination_scale, aff_combination_add_elt, aff_combination_add, tree_to_aff_combination, add_elt_to_tree, aff_combination_to_tree, fold_affine_sum): New functions. (get_computation_at): Use fold_affine_sum. * tree-ssa-loop-manip.c (create_iv): Handle ivs with nonconstant step. * tree-ssa-loop-niter.c (number_of_iterations_exit): Add argument to simple_iv call. * gcc.dg/tree-ssa/loop-8.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8543r2=2.8544 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-scalar-evolution.c.diff?cvsroot=gccr1=2.21r2=2.22 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-scalar-evolution.h.diff?cvsroot=gccr1=2.3r2=2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gccr1=2.65r2=2.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-manip.c.diff?cvsroot=gccr1=2.31r2=2.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-niter.c.diff?cvsroot=gccr1=2.24r2=2.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gccr1=1.476r2=1.477 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5421r2=1.5422 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/loop-8.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18316
[Bug tree-optimization/19126] Missed IV optimization (redundant instruction in loop)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01 08:08 --- Subject: Bug 19126 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-01 08:08:14 Modified files: gcc: ChangeLog tree-scalar-evolution.c tree-scalar-evolution.h tree-ssa-loop-ivopts.c tree-ssa-loop-manip.c tree-ssa-loop-niter.c tree.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: loop-8.c Log message: PR tree-optimization/18316 PR tree-optimization/19126 * tree.c (build_int_cst_type): Avoid shift by size of type. * tree-scalar-evolution.c (simple_iv): Add allow_nonconstant_step argument. * tree-scalar-evolution.h (simple_iv): Declaration changed. * tree-ssa-loop-ivopts.c (struct iv_cand): Add depends_on field. (dump_cand): Dump depends_on information. (determine_biv_step): Add argument to simple_iv call. (contains_abnormal_ssa_name_p): Handle case expr == NULL. (find_bivs, find_givs_in_stmt_scev): Do not require step to be a constant. (add_candidate_1): Record depends_on for candidates. (tree_int_cst_sign_bit, constant_multiple_of): New functions. (get_computation_at, get_computation_cost_at, may_eliminate_iv): Handle ivs with nonconstant step. (iv_ca_set_remove_invariants, iv_ca_set_add_invariants): New functions. (iv_ca_set_no_cp, iv_ca_set_cp): Handle cand-depends_on. (create_new_iv): Unshare the step before passing it to create_iv. (free_loop_data): Free cand-depends_on. (build_addr_strip_iref): New function. (find_interesting_uses_address): Use build_addr_strip_iref. (strip_offset_1): Split the recursive part from strip_offset. Strip constant offset component_refs and array_refs. (strip_offset): Split the recursive part to strip_offset_1. (add_address_candidates): Removed. (add_derived_ivs_candidates): Do not use add_address_candidates. (add_iv_value_candidates): Add candidates with stripped constant offset. Consider all candidates with initial value 0 important. (struct affine_tree_combination): New. (aff_combination_const, aff_combination_elt, aff_combination_scale, aff_combination_add_elt, aff_combination_add, tree_to_aff_combination, add_elt_to_tree, aff_combination_to_tree, fold_affine_sum): New functions. (get_computation_at): Use fold_affine_sum. * tree-ssa-loop-manip.c (create_iv): Handle ivs with nonconstant step. * tree-ssa-loop-niter.c (number_of_iterations_exit): Add argument to simple_iv call. * gcc.dg/tree-ssa/loop-8.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8543r2=2.8544 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-scalar-evolution.c.diff?cvsroot=gccr1=2.21r2=2.22 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-scalar-evolution.h.diff?cvsroot=gccr1=2.3r2=2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gccr1=2.65r2=2.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-manip.c.diff?cvsroot=gccr1=2.31r2=2.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-niter.c.diff?cvsroot=gccr1=2.24r2=2.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gccr1=1.476r2=1.477 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5421r2=1.5422 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/loop-8.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19126
[Bug c++/21304] very long compile times with large cpp file from kdebindings
--- Additional Comments From olh at suse dot de 2005-05-01 08:10 --- gcc-3_4-branch takes only 5 minutes to complete. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21304
[Bug c++/21314] New: C++ performance regression with -Os
the following code takes more than twice as long to run when compiled with -Os
using gcc-4.0.0 than it does with 3.3.5 or 3.4.3.
#include stdio.h
#include vector
class mytype_A {
public:
int id;
mytype_A():id(0) {}
};
class mytype_B {
public:
mytype_A* A;
mytype_B(mytype_A* p):A(p) {}
};
class mytype_C {
public:
mytype_B* B;
mytype_C(mytype_B* p):B(p) {}
};
class mytype_D {
public:
// mytype_C* C[2]; // less performance difference if we use simple
arrays
std::vectormytype_C* C;
int junk[3];// affects performance
public:
mytype_D(mytype_A* a0, mytype_A* a1) {
//C[0] = new mytype_C(new mytype_B(a0));
//C[1] = new mytype_C(new mytype_B(a0));
C.push_back(new mytype_C(new mytype_B(a0)));
C.push_back(new mytype_C(new mytype_B(a0)));
}
};
int main() {
int k = 5000;// run-time not linear in k
mytype_A* A[k];
mytype_D* D[k];
for (int i=0;i=k;i++)
A[i] = new mytype_A();
for (int i=0;ik;i++)
D[i] = new mytype_D(A[i],A[k-i]);// intentionally make some pointers
farther apart
clock_t before = clock();
int k0 = 0;
for (int i=0;ik;i++) {
k0 = 0;
for (int j=0;jk;j++) { // run through list of D's, and reference
pointers
mytype_D* d = D[j];
if (d-C[0]-B-A-id) k0++;
if (d-C[1]-B-A-id) k0++;
}
}
printf(%d\n,k0);// don't allow compiler to optimize away k0
printf(time: %f\n,(double)(clock()-before)/CLOCKS_PER_SEC);
return 0;
}
dirtyepic ~/work $ g++ -Os -Wall -march=pentium3 cpptest.cpp
i686-pc-linux-gnu-3.3.5-20050130 - time: 6.53
i686-pc-linux-gnu-3.4.3-20050110 - time: 6.92
i686-pc-linux-gnu-4.0.0(release) - time: 16.79
i686-pc-linux-gnu-4.0.0-20050430 - time: 16.70
dirtyepic ~/work $ g++ -v -save-temps -Os -Wall -march=pentium3 cpptest.cpp -o
gcc401
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/gcc-4.0.1_alpha20050430/work/gcc-4.0-20050430/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.0.1-alpha20050430
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.1-alpha20050430
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.1-alpha20050430/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.1-alpha20050430/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-nls --with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --disable-multilib --disable-libgcj
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.0.1-alpha20050430 (Gentoo Linux 4.0.1_alpha20050430)
/usr/libexec/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/cc1plus -E -quiet -v
-D_GNU_SOURCE cpptest.cpp -march=pentium3 -Wall -Os -fpch-preprocess -o
cpptest.ii
ignoring nonexistent directory /usr/local/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/include/g++-v4
/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/include/g++-v4/i686-pc-linux-gnu
/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/include/g++-v4/backward
/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/include
/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/../../../../i686-pc-linux-gnu/include
/usr/include
End of search list.
/usr/libexec/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/cc1plus -fpreprocessed
cpptest.ii -quiet -dumpbase cpptest.cpp -march=pentium3 -auxbase cpptest -Os
-Wall -version -o cpptest.s
GNU C++ version 4.0.1-alpha20050430 (Gentoo Linux 4.0.1_alpha20050430)
(i686-pc-linux-gnu)
compiled by GNU C version 4.0.1-alpha20050430 (Gentoo Linux
4.0.1_alpha20050430).
GGC heuristics: --param ggc-min-expand=55 --param ggc-min-heapsize=48339
/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/../../../../i686-pc-linux-gnu/bin/as
-V -Qy -o cpptest.o cpptest.s
GNU assembler version 2.16.90.0.2 (i686-pc-linux-gnu) using BFD version
2.16.90.0.2 20050429
/usr/libexec/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/collect2 --eh-frame-hdr
-m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o gcc401
/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430
-L/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430
-L/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/../../../../i686-pc-linux-gnu/lib
-L/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/../../.. cpptest.o -lstdc++
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/i686-pc-linux-gnu/4.0.1-alpha20050430/crtend.o
[Bug c++/21314] C++ performance regression with -Os
--- Additional Comments From deemkay at gmail dot com 2005-05-01 08:31 --- Created an attachment (id=8780) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8780action=view) cpptest.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
[Bug libstdc++/21295] Configuring g++ library for various locales ?
--- Additional Comments From pcarlini at suse dot de 2005-05-01 09:06 --- That's the point, I do not have these lines (I attach my c++locale.h from my 4.0.0 by=uild, since it is short). Therefore, for some reason, the configury decided not to enable the GNU locale model (there are mildly complicated checks for this). Now you can do a few things: 1- The most naive one, it trying to rebuild passing *explicitly* --enable-clocale=gnu; 2- Then, you should inspect config.log in the build dir and see what's going wrong at configure time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21295
[Bug libstdc++/21295] Configuring g++ library for various locales ?
--- Additional Comments From pcarlini at suse dot de 2005-05-01 09:15 --- In the 4.0 configure, the relevant tests start at line 5668, corresponding to the code starting at line 1097 in acinclude.m4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21295
[Bug libfortran/21315] New: Unable to link Fortran executables: __builtin_isfinite is undefined
The typical error message is: Executing on host: /opt/build/eric/gcc-4_0-branch/gcc/testsuite/../gfortran -B/opt/build/eric/gcc-4_0-branch/gcc/testsuite/../ /home/eric/cvs/gcc-4_0-branch/gcc/testsuite/gfortran.dg/blockdata_1.f90 -Os -pedantic-errors -L/opt/build/eric/gcc-4_0-branch/sparc-sun-solaris2.10/./libgfortran/.libs -L/opt/build/eric/gcc-4_0-branch/sparc-sun-solaris2.10/./libiberty -lm -o ./blockdata_1.exe(timeout = 300) Undefined first referenced symbol in file __builtin_isfinite /opt/build/eric/gcc-4_0-branch/sparc-sun-solaris2.10/./libgfortran/.libs/libgfortran.so ld: fatal: Symbol referencing errors. No output written to ./blockdata_1.exe collect2: ld returned 1 exit status -- Summary: Unable to link Fortran executables: __builtin_isfinite is undefined Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21315
[Bug libstdc++/21271] Invalid free in std::string
--- Additional Comments From chris at bubblescope dot net 2005-05-01 10:08 --- Woops, false alarm, somehow I'd horribly, horribly messed up something. A clean OS reinstall seems to have cleared up this, and another unrelated problem. Sorry -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21271
[Bug c++/18886] [4.1 Regression] misleading warning from attribute sentinel in C++
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-01 10:10 --- For some reason the patch applied for the 19542 duplicate of this bug has only been applied to 4.0 branch (although normally all fixes should go on mainline first). -- What|Removed |Added CC||matz at suse dot de Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-01 10:10:54 date|| Summary|misleading warning from |[4.1 Regression] misleading |attribute sentinel in C++ |warning from attribute ||sentinel in C++ Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18886
[Bug target/21050] [4.1 Regression] vect-none.c ICE
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-01 10:14 --- Appeared on ia64-hpux between 2005-04-13 19:01 UTC and 2005-04-13 19:04 UTC (regression searching compiling vect-none.c with -O2 -ftree-vectorize). I.e., caused by 2005-04-13 Devang Patel [EMAIL PROTECTED] * tree-if-conv.c (tree_if_convert_cond_expr): Do not create extra temp variables. -- What|Removed |Added CC||dpatel at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21050
[Bug libstdc++/21295] Configuring g++ library for various locales ?
--- Additional Comments From jpr at essi dot fr 2005-05-01 10:16 --- Subject: Re: Configuring g++ library for various locales ? pcarlini at suse dot de wrote: --- Additional Comments From pcarlini at suse dot de 2005-05-01 09:06 --- That's the point, I do not have these lines (I attach my c++locale.h from my 4.0.0 by=uild, since it is short). Therefore, for some reason, the configury decided not to enable the GNU locale model (there are mildly complicated checks for this). Now you can do a few things: 1- The most naive one, it trying to rebuild passing *explicitly* --enable-clocale=gnu; 2- Then, you should inspect config.log in the build dir and see what's going wrong at configure time. Thanks for your help, but I did some search on my own and I found the problem, effectively by looking at config.log. The libstdc++ configure script, at some point (line 5731 and following), tries to determine the locale model. For this it builds a test program which tries to set the locale to the German one (de_DE). In my distribution, it is possible to selectively install the locales. Thus I installed only the ones which are of interest to me, that is French and English. In this case, the test program fails with a SEGV, and the local model defaults to generic (which, I assume, means only C and POSIX). Now I installed also the German locale, and everything seems OK. Don't you thing that there should be some notice in the doc, telling that determining the locale model depends on installing the German locale ? Or possibly some documentation about --enable-clocale (to the best of my knowledge, it is not documented). Or, much better, find a more accurate way to determine the local model. For instance, at least (but I know it won't be sufficient), try the current locale (if any, if not cross-compiling, and if different from C/POSIX...) when building C++ instead of forcing the German one (which appears to me a little Süse-oriented ;-)). Der Teufel steckt im Detail Best regards Jean-Paul Rigault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21295
[Bug libstdc++/21295] Configuring g++ library for various locales ?
--- Additional Comments From pcarlini at suse dot de 2005-05-01 10:31 --- Now I installed also the German locale, and everything seems OK. Excellent! instead of forcing the German one (which appears to me a little Süse-oriented ;-)). What if I tell you that the author of that test is Jakub Jelinek, a renowned RedHat employee? Anyway, we have already documentation clearly stating that a set of locales is *needed* when using the GNU locale model: http://gcc.gnu.org/onlinedocs/libstdc++/install.html#prereqs and of course --enable-clocale itself is completely documented http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html *and reference is made to the above requirements*: As part of the configuration process, the C library is probed both for sufficient vintage, and installed locale data. If either of these elements are not present, the C++ locale model default to 'generic.' On glibc-based systems of version 2.2.5 and above with installed locale files, 'gnu' is automatically selected. Der Teufel steckt im Detail So, you like the -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21295
[Bug libstdc++/21295] Configuring g++ library for various locales ?
--- Additional Comments From pcarlini at suse dot de 2005-05-01 10:33 --- ... wanted to add: So after all, you like the German culture and de_DE it's ok with you ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21295
[Bug c/11459] -ansi -std=c99 -pedantic warns about C90's non long-long support when in C99 mode
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01
10:33 ---
Subject: Bug 11459
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-01 10:33:40
Modified files:
gcc: ChangeLog gcc.c
gcc/testsuite : ChangeLog
Added files:
gcc/testsuite/gcc.dg: pr11459-1.c pr18502-1.c
Log message:
PR c/11459
PR c/18502
* gcc.c (cpp_unique_options): Remove %{trigraphs}.
(cpp_options, cc1_options): Change %{std*} %{ansi} to
%{std*ansitrigraphs}.
testsuite:
* gcc.dg/pr11459-1.c, gcc.dg/pr18502-1.c: New tests.
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.845r2=2.2326.2.846
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcc.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.403.4.11r2=1.403.4.12
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.382r2=1.3389.2.383
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr11459-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.54.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr18502-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.28.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11459
[Bug c/18502] [3.3/3.4 Regression] trigraphs don't work with -std=gnu99
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01
10:33 ---
Subject: Bug 18502
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-01 10:33:40
Modified files:
gcc: ChangeLog gcc.c
gcc/testsuite : ChangeLog
Added files:
gcc/testsuite/gcc.dg: pr11459-1.c pr18502-1.c
Log message:
PR c/11459
PR c/18502
* gcc.c (cpp_unique_options): Remove %{trigraphs}.
(cpp_options, cc1_options): Change %{std*} %{ansi} to
%{std*ansitrigraphs}.
testsuite:
* gcc.dg/pr11459-1.c, gcc.dg/pr18502-1.c: New tests.
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.845r2=2.2326.2.846
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcc.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.403.4.11r2=1.403.4.12
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.382r2=1.3389.2.383
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr11459-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.54.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr18502-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.28.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18502
[Bug c/20740] [3.4/4.0/4.1 Regression] cc1 segfaults
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01 10:39 --- Subject: Bug 20740 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-05-01 10:39:15 Modified files: gcc: ChangeLog c-format.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/format: asm_fprintf-2.c asm_fprintf-3.c asm_fprintf-4.c asm_fprintf-5.c gcc_diag-2.c gcc_diag-3.c gcc_diag-4.c gcc_diag-5.c gcc_diag-6.c gcc_diag-7.c gcc_diag-8.c gcc_diag-9.c Log message: PR c/20740 * c-format.c (init_dynamic_asm_fprintf_info): Give errors, not aborts, if __gcc_host_wide_int__ is not properly defined. (init_dynamic_diag_info): Give errors, not aborts, if location_t, tree or __gcc_host_wide_int__ are not properly defined. testsuite: * gcc.dg/format/asm_fprintf-2.c, gcc.dg/format/asm_fprintf-3.c, gcc.dg/format/asm_fprintf-4.c, gcc.dg/format/asm_fprintf-5.c, gcc.dg/format/gcc_diag-2.c, gcc.dg/format/gcc_diag-3.c, gcc.dg/format/gcc_diag-4.c, gcc.dg/format/gcc_diag-5.c, gcc.dg/format/gcc_diag-6.c, gcc.dg/format/gcc_diag-7.c , gcc.dg/format/gcc_diag-8.c, gcc.dg/format/gcc_diag-9.c: New tests. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.846r2=2.2326.2.847 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-format.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.51r2=1.51.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.383r2=1.3389.2.384 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/asm_fprintf-2.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/asm_fprintf-3.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/asm_fprintf-4.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/asm_fprintf-5.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/gcc_diag-2.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/gcc_diag-3.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/gcc_diag-4.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/gcc_diag-5.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/gcc_diag-6.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/gcc_diag-7.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/gcc_diag-8.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/format/gcc_diag-9.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20740
[Bug c/21213] [3.3/3.4/4.0/4.1 Regression] segfault declaring a transparent union
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-01 10:44 --- Subject: Bug 21213 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-05-01 10:44:10 Modified files: gcc: ChangeLog c-decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: transparent-union-3.c Log message: PR c/21213 * c-decl.c (finish_struct): Don't dereference NULL TYPE_FIELDS of transparent union. testsuite: * gcc.dg/transparent-union-3.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.847r2=2.2326.2.848 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.470.4.18r2=1.470.4.19 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.384r2=1.3389.2.385 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/transparent-union-3.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21213
[Bug c/11459] -ansi -std=c99 -pedantic warns about C90's non long-long support when in C99 mode
-- What|Removed |Added Target Milestone|4.0.0 |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11459
[Bug c/20740] [3.4/4.0/4.1 Regression] cc1 segfaults
-- What|Removed |Added Target Milestone|4.0.1 |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20740
[Bug c/21213] [3.3/3.4/4.0/4.1 Regression] segfault declaring a transparent union
-- What|Removed |Added Target Milestone|4.0.1 |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21213
[Bug libstdc++/21295] Configuring g++ library for various locales ?
--- Additional Comments From jpr at essi dot fr 2005-05-01 11:21 --- Subject: Re: Configuring g++ library for various locales ? pcarlini at suse dot de wrote: --- Additional Comments From pcarlini at suse dot de 2005-05-01 10:31 --- Now I installed also the German locale, and everything seems OK. Excellent! instead of forcing the German one (which appears to me a little Süse-oriented ;-)). What if I tell you that the author of that test is Jakub Jelinek, a renowned RedHat employee? Anyway, we have already documentation clearly stating that a set of locales is *needed* when using the GNU locale model: http://gcc.gnu.org/onlinedocs/libstdc++/install.html#prereqs and of course --enable-clocale itself is completely documented http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html *and reference is made to the above requirements*: As part of the configuration process, the C library is probed both for sufficient vintage, and installed locale data. If either of these elements are not present, the C++ locale model default to 'generic.' On glibc-based systems of version 2.2.5 and above with installed locale files, 'gnu' is automatically selected. OK for the documentation, except ... that this is not the one that you read when you install gcc from scratch ! Although libstdc++ is now part of gcc, there is no link from the files in gcc-xxx/INSTALL to the library documentation pages. But you are right, I should have searched for this. Jean-Paul Rigault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21295
[Bug libstdc++/21295] Configuring g++ library for various locales ?
--- Additional Comments From jpr at essi dot fr 2005-05-01 11:24 --- Subject: Re: Configuring g++ library for various locales ? pcarlini at suse dot de wrote: --- Additional Comments From pcarlini at suse dot de 2005-05-01 10:33 --- ... wanted to add: So after all, you like the German culture and de_DE it's ok with you ;) I lived in Germany for 5 years when I was a kid, and my grandfather was a German. Thus I have really nothing against these people, on the contrary ! Jean-Paul Rigault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21295
[Bug c/21275] [4.0/4.1 Regression] gcc 4.0.0 crash with mingw when using stdout in global var
--- Additional Comments From ch dot ehrlicher at gmx dot de 2005-05-01 11:28 --- the patch in comment #5 works for me -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
[Bug c++/21113] Jumps into VLA or VM scope not rejected for C++
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-01 11:32 --- It should be possible to use the existing machinery in the C++ front end which diagnoses jumps into the scope of initialized or non-POD variables to diagnose jumps into VLA or VM scope (treating VLA or VM declarations as a special case of being initialized; after all, the artificial variable with the array size is initialized by the declaration). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21113
[Bug libstdc++/21295] Configuring g++ library for various locales ?
--- Additional Comments From pcarlini at suse dot de 2005-05-01 11:39 --- OK for the documentation, except ... that this is not the one that you read when you install gcc from scratch ! Although libstdc++ is now part of gcc, there is no link from the files in gcc-xxx/INSTALL to the library documentation pages. Yes, this improvement makes a lot of sense. Would you please open a separate, specific PR and assign it to Jonathan ([EMAIL PROTECTED]) ? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21295
[Bug libfortran/21315] Unable to link Fortran executables: __builtin_isfinite is undefined
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01 12:04 --- Investigating. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-01 12:04:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21315
[Bug target/21315] Unable to link Fortran executables: __builtin_isfinite is undefined
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01 12:12 --- Basically same problem as PR target/19933. -- What|Removed |Added BugsThisDependsOn||19933 Component|libfortran |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21315
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01 12:21 --- GCC does not yet have __builtin_isfinite or __builtin_isnormal functions; they would be generically useful additions if they always avoided falling back to a library function. __builtin_fpclassify would also be useful but would only be usable where GCC is configured to know the FP_* values used on a given target. In principle all the macros can be defined along the lines of the isnan/isfinite/isinf definitions in libgcc2.c, with GNU extensions to avoid multiple evaluation, but this is not very efficient. Joseph, we are severely bitten by the __builtin_isfinite problem for the Fortran compiler (this is PR target/21315). What do you suggest? Fixincluding to GCC __builtin_* functions when possible and fixincluding away in the other cases? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug target/21050] [4.1 Regression] vect-none.c ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 13:07 --- I really think that Devang's patch exposed a latent bug either in expand or in the target specific files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21050
[Bug middle-end/21275] [4.0/4.1 Regression] gcc 4.0.0 crash with mingw when using stdout in global var
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 13:16 --- Confirmed. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg9.html Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed||1 Keywords||ice-on-valid-code, patch, ||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-05-01 13:16:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
[Bug middle-end/21275] [4.0/4.1 Regression] gcc 4.0.0 crash with mingw when using stdout in global var
-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
[Bug tree-optimization/21081] [4.0/4.1 Regression] internal compiler error: verify_stmts failed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 13:17 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg9.html Keywords||patch Last reconfirmed|2005-04-20 00:08:40 |2005-05-01 13:17:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21081
[Bug rtl-optimization/19579] [3.3 regression] -march=i686 generates a bogus program for x86*
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 13:17 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579
[Bug c++/21316] New: pointer lookup cache misses more frequent
The sample code runs 30-50% slower on my machine when compiled with 3.4.3 as opposed to 3.3.4. It creates some objects and then references them via pointer lookup, so my best guess is that somehow 3.4.3 binaries have many more cache misses. I have noticed the severe regression on AMD Athlon 3200 running linux 2.6, with compile options -O3 -march=k8. Other options (e.g. -O2 instead) don't help. -- Summary: pointer lookup cache misses more frequent Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kpmassey at gmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21316
[Bug c++/21316] pointer lookup cache misses more frequent
--- Additional Comments From kpmassey at gmail dot com 2005-05-01 13:23 --- Created an attachment (id=8781) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8781action=view) source file that illustrates problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21316
[Bug c++/21316] pointer lookup cache misses more frequent
--- Additional Comments From kpmassey at gmail dot com 2005-05-01 13:25 --- Created an attachment (id=8782) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8782action=view) .ii file from my compilation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21316
[Bug c++/21316] pointer lookup cache misses more frequent
--- Additional Comments From kpmassey at gmail dot com 2005-05-01 13:26 --- Created an attachment (id=8783) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8783action=view) .s file from my compilation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21316
[Bug ada/21317] New: ACATS c954025 c954026 failures
Excerpt from the log file: ,.,. C954025 ACATS 2.5 05-05-01 03:33:45 C954025 Check that if the original entry call was a conditional or timed entry call, the expiration time for a requeue with abort is the original expiration time. * C954025 not enough time completed accept (1). * C954025 not enough time (1). * C954025 not enough time completed accept (2). * C954025 not enough time (2). C954025 FAILED *** FAIL: c954025 ,.,. C954026 ACATS 2.5 05-05-01 03:33:48 C954026 Check that if the original entry call was a conditional or timed entry call, the expiration time for a requeue with abort to a protected entry is the original expiration time. * C954026 not enough time completed accept (1). * C954026 not enough time (1). * C954026 not enough time completed accept (2). * C954026 not enough time (2). C954026 FAILED . FAIL: c954026 Note that Rainer reports them on Solaris 8 too (unlike me): http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01272.html Might be dependent on the processor's speed. -- Summary: ACATS c954025 c954026 failures Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21317
[Bug ada/21317] ACATS c954025 c954026 failures
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01 13:27 --- By Rainer: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01800.html -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-01 13:27:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21317
[Bug target/21316] pointer lookup cache misses more frequent
-- What|Removed |Added Component|c++ |target Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21316
[Bug c++/21314] C++ performance regression with -Os
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 13:34 --- -Os is compile for size if the size is smaller than there is no bug. We don't care about runtime speed really at -Os. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
[Bug c++/21314] C++ performance regression with -Os
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 13:35 --- Oh, also I cannot reproduce the slow down that you are getting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
[Bug c++/21314] C++ performance regression with -Os
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 13:35 --- Also this is a modified compiler from Gentoo, can you try an unmodified one. -- What|Removed |Added Version|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
[Bug target/21314] C++ performance regression with -Os
-- What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
[Bug tree-optimization/19126] Missed IV optimization (redundant instruction in loop)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 13:46 --- Fixed. Thanks Zdenek. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19126
[Bug tree-optimization/18316] Missed IV optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 13:48 --- On PPC, there are two extra mr's in the first case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18316
[Bug tree-optimization/18316] Missed IV optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 13:49 --- Oh, I have forgotten to say the IV opt is caught though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18316
[Bug java/21313] Incorrect visibility of package scope methods (compilation problem)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 13:50 --- Confirmed. -- What|Removed |Added OtherBugsDependingO||13607 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-05-01 13:50:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21313
[Bug objc/18456] [4.0/4.1 Regression] ICE compiling Objective C code with protocol-qualified objects
-- What|Removed |Added Last reconfirmed|2004-11-12 17:12:21 |2005-05-01 13:55:20 date|| Summary|ICE compiling Objective C |[4.0/4.1 Regression] ICE |code with protocol-qualified|compiling Objective C code |objects |with protocol-qualified ||objects Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18456
[Bug libmudflap/18244] libmudflap installs include/mf-runtime.h in version-independent path
-- What|Removed |Added OtherBugsDependingO||346 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18244
[Bug other/346] gcc install clobbers files that it shouldn't touch
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:01 --- libmudflap does the same thing, see PR 18244. -- What|Removed |Added BugsThisDependsOn||18244 Last reconfirmed|2004-02-08 05:58:28 |2005-05-01 14:01:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=346
[Bug libmudflap/18244] libmudflap installs include/mf-runtime.h in version-independent path
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:01 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-01 14:01:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18244
[Bug java/17845] can't build GNU Classpath
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:05 --- Is this true anymore, I built classpath a couple of days ago on powerpc-darwin with a case-insensitive file system and it worked for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17845
[Bug fortran/18883] ICE in gfc_finish_var_decl
-- Bug 18883 depends on bug 15164, which changed state. Bug 15164 Summary: trans-decl.c:411: gfc_finish_var_decl: Assertion failed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15164 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18883
[Bug fortran/15164] trans-decl.c:411: gfc_finish_var_decl: Assertion failed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:14 --- Fixed for 4.0.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15164
[Bug fortran/19282] ICE in gfc_conv_array_initializer
-- Bug 19282 depends on bug 18769, which changed state. Bug 18769 Summary: gfortran: ICE in gfc_conv_array_initializer with array initialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19282
[Bug fortran/18769] gfortran: ICE in gfc_conv_array_initializer with array initialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:17 --- Fixed for 4.0.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
[Bug fortran/18283] gfortran: ICE in gfc_conv_string_parameter, trans-expr.c:1982
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:19 --- Fixed for 4.0.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18283
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
-- Bug 19276 depends on bug 18283, which changed state. Bug 18283 Summary: gfortran: ICE in gfc_conv_string_parameter, trans-expr.c:1982 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18283 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
[Bug fortran/18689] Internal compiler error with character pointer association in module subroutine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:19 --- Fixed for 4.0.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18689
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
-- Bug 19276 depends on bug 18689, which changed state. Bug 18689 Summary: Internal compiler error with character pointer association in module subroutine http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18689 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
[Bug fortran/19282] ICE in gfc_conv_array_initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:20 --- Fixed for 4.0.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19282
[Bug fortran/18878] Erronous error message on vaild USE statement
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:21 --- Fixed for 4.0.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18878
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From joseph at codesourcery dot com 2005-05-01
14:24 ---
Subject: Re: Problem with define of HUGE_VAL in math_c99.
On Sun, 1 May 2005, ebotcazou at gcc dot gnu dot org wrote:
In principle all the macros can be defined along the lines of
the isnan/isfinite/isinf definitions in libgcc2.c, with GNU extensions to
avoid multiple evaluation, but this is not very efficient.
Joseph, we are severely bitten by the __builtin_isfinite problem for the
Fortran
compiler (this is PR target/21315). What do you suggest? Fixincluding to GCC
__builtin_* functions when possible and fixincluding away in the other cases?
Fixincluding everything to working definitions if possible, even if
cumbersome, with all the fixes disabled conditional on __GNUC__ being
mentioned in the header. (If support for some of these built-in functions
is then added to GCC, remove the relevant fixes, but I suppose you want to
fix things on 4.0 branch as well as mainline for now.) I'm not sure what
is best done with the signbit definition (maybe nothing if it will never
call a library function at present, even though it isn't properly
type-generic); but the others can be done, e.g.
#define isfinite(x) __extension__ ({ __typeof (x) __x = (x); __builtin_expect
(!isnan(__x - __x), 1); })
following libgcc2.c but using statement expressions and __typeof to avoid
multiple evaluation. (This includes fixincluding isinf, per bug 20558.)
I'd recommend making each fixed definition a separate fixinclude (so they
still work if e.g. the header gets reordered; and so if Sun produce a
partially fixed header version then the disabling on __GNUC__ only needs
changing for those definitions which remain problematic).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug fortran/21300] ICE: Segmentation fault in gfc_trans_subcomponent_assign
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:25 --- This is a dup of bug 19181. *** This bug has been marked as a duplicate of 19181 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21300
[Bug fortran/19181] ICE and segmentation fault with pointer member in user defined type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:25 --- *** Bug 21300 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||andrea at poisson dot phc ||dot unipi dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19181
[Bug c++/21312] [3.4/4.0/4.1 Regression] Access violation diagnostic given twice
-- What|Removed |Added CC||redi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21312
[Bug target/21314] C++ performance regression with -Os
--- Additional Comments From giovannibajo at libero dot it 2005-05-01 14:26 --- Yes, mostly we don't care, but it's a two-fold regression so it should be justified by a significant decrease in size, otherwise it's just a bad regression. I almost think it's because of Honza's inline patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
[Bug libfortran/19481] libgfortran doesn't build -- configure doesn't handle cabs() well
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 14:33 --- (In reply to comment #2) I worked around this bug, commenting a line in /mingw/include/math.h (I quote it here for reference): //_CRTIMP double __cdecl cabs (struct _complex); The end of the compilation runs smoothly, but when I try to use gfortran, it complains at link-time about missing symbol _ftruncate. Indeed, mingw doesn't have a ftruncate (it has a chsize which has the same prototype and all), but the The ftruncate problem should be fixed now. Does this work fully or is cabs issue still there? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19481
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From ert at roe dot ac dot uk 2005-05-01 14:44 --- Subject: New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 I get the same error compiling gcc-4.0.0 on an Opteron with Debian-3 (32-bit, glibc-2.2.5, 2.4.26 kernel) The failure occurs whether using gcc-2.95.4 or gcc-3.4.3 to start the bootstrap build. No problem building gcc-4.0.0 on an athlon-xp (homegrown linux, glibc-2.3.5, gcc-3.4.3, 2.6.11.7 kernel) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug middle-end/21318] New: [4.1 Regression] ICE in instantiate_virtual_regs_in_insn
The following test failures appeared on ia64-hpux (-milp32 only) between 20050429 and 20050430. Both are cc1 segmentation faults in instantiate_virtual_regs_in_insn, which can be reproduced with a cross-compiler cc1. 0x08330cf4 in instantiate_virtual_regs_in_insn (insn=0x401b51b8) at ../../gcc-cvs-mainline/gcc/function.c:1488 1488 x = simplify_gen_subreg (insn_data[insn_code].operand[i].mode, FAIL: gcc.dg/tree-ssa/20031015-1.c (test for excess errors) FAIL: gcc.dg/tree-ssa/stdarg-2.c (test for excess errors) FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump f10: va_list escapes 1, needs to save all GPR units FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump f11: va_list escapes 0, needs to save (3|12|24) GPR units FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump f12: va_list escapes 0, needs to save [1-9][0-9]* GPR units FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump f13: va_list escapes 0, needs to save [1-9][0-9]* GPR units FAIL: gcc.dg/tree-ssa/stdarg-2.c scan-tree-dump f14: va_list escapes 0, needs to save [1-9][0-9]* GPR units Binary search shows the 20031015-1.c failure appeared between 2005-04-30 03:15 UTC and 2005-04-30 04:56 UTC, i.e. was caused by 2005-04-29 Richard Henderson [EMAIL PROTECTED] * function.c (instantiate_decls): Remove valid_only argument. (instantiate_decls_1, instantiate_decl): Likewise. (instantiate_virtual_regs_1): Delete. (instantiate_virtual_regs_lossage): Delete. (instantiate_virtual_regs_in_rtx): New. (safe_insn_predicate): New. (instantiate_virtual_regs_in_insn): New. (instantiate_virtual_regs): Update to match all that. Only run instantiate_decls once. The binary search for the stdarg-2.c failure is still running but I expect it will prove to be caused by the same patch. -- Summary: [4.1 Regression] ICE in instantiate_virtual_regs_in_insn Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,rth at gcc dot gnu dot org GCC target triplet: ia64-*-hpux11.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21318
[Bug fortran/18689] Internal compiler error with character pointer association in module subroutine
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-05-01 15:11 --- Subject: Re: Internal compiler error with character pointer association in module subroutine Andrew, I have taken my eye off the ball, after my most recent cock-up; when did this get fixed? I have searched for something related to PR18689 but have not found it - has this benefitted from fall-out from something else? If so, a wee test case should be prepared. Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18689
[Bug fortran/18689] Internal compiler error with character pointer association in module subroutine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 15:15 --- Woops, this is not fixed, I must have used the wrong file to test with. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18689
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
-- Bug 19276 depends on bug 18689, which changed state. Bug 18689 Summary: Internal compiler error with character pointer association in module subroutine http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18689 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
[Bug fortran/18689] Internal compiler error with character pointer association in module subroutine
-- What|Removed |Added Status|REOPENED|NEW Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18689
[Bug fortran/18689] Internal compiler error with character pointer association in module subroutine
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-05-01 15:17 --- Subject: Re: Internal compiler error with character pointer association in module subroutine In fact, how come it is fixed in 4.0 and not in 4.1? I get the error still with yesterday's cvs for any optmisation. I did not think that was possible? Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18689
[Bug fortran/19282] ICE in gfc_conv_array_initializer
-- Bug 19282 depends on bug 18769, which changed state. Bug 18769 Summary: gfortran: ICE in gfc_conv_array_initializer with array initialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19282
[Bug fortran/18769] gfortran: ICE in gfc_conv_array_initializer with array initialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 15:18 --- Woops I must have used the wrong file to test with. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
[Bug fortran/18769] gfortran: ICE in gfc_conv_array_initializer with array initialization
-- What|Removed |Added Status|REOPENED|NEW Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
[Bug fortran/18283] gfortran: ICE in gfc_conv_string_parameter, trans-expr.c:1982
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 15:19 --- Woops I must have used the wrong file to test with. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18283
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
-- Bug 19276 depends on bug 18283, which changed state. Bug 18283 Summary: gfortran: ICE in gfc_conv_string_parameter, trans-expr.c:1982 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18283 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
[Bug fortran/18283] gfortran: ICE in gfc_conv_string_parameter, trans-expr.c:1982
-- What|Removed |Added Status|REOPENED|NEW Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18283
[Bug fortran/19282] ICE in gfc_conv_array_initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 15:20 --- Woops must have used the wrong file to test with. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19282
[Bug fortran/19282] ICE in gfc_conv_array_initializer
-- What|Removed |Added Status|REOPENED|NEW Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19282
[Bug fortran/18878] Erronous error message on vaild USE statement
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 15:21 --- Woops must have used the wrong file to test with. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18878
[Bug fortran/18878] Erronous error message on vaild USE statement
-- What|Removed |Added Status|REOPENED|NEW Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18878
[Bug other/21319] New: Please add the feature of switching target at runtime
The current way of doing a cross-compile is way too complicated. One has to compile gcc itself for RUNTIME architecture which outputs TARGET arch binaries (hardcoded inside). It would be very user friendly if the user compiles gcc just once (for the current arch) and selects the desired output arch at runtime. -- Summary: Please add the feature of switching target at runtime Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: radek at podgorny dot cz CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21319
[Bug other/21319] Please add the feature of switching target at runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 16:02 --- This was a very long term goal of the hooking GCC but then it was proved that it slowed down the compiler too much. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-01 16:02:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21319
[Bug other/21319] Please add the feature of switching target at runtime
--- Additional Comments From radek at podgorny dot cz 2005-05-01 16:13 --- Slowed down? I'm not talking about compliling ALL the stuff in, just what I need. Like configure --with-arch-i686 --with-arch-arm... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21319
[Bug other/21319] Please add the feature of switching target at runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01 16:23 --- (In reply to comment #2) Slowed down? I'm not talking about compliling ALL the stuff in, just what I need. Like configure --with-arch-i686 --with-arch-arm... Yes that would slow down the compiler as right now we have macros for some target dependent controls and then they have to be changed to function calls which slow down the compiler. I think it slowed down the compiler about 1-5% IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21319
[Bug tree-optimization/17116] Missed jump threading/bypassing optimization with loop and % (or ands)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-01
16:29 ---
We now get:
main ()
{
int i.8;
int i;
bb 0:
Invalid sum of outgoing probabilities 0.0%
i = 0;
i.8 = i + 1;
Invalid sum of outgoing probabilities 98.9%
L0:;
if ((i.8 1) != 0) goto L1; else goto L10;
L1:;
puts (hello[0]);
Invalid sum of incoming frequencies 9813, should be 1
L10:;
i.8 = i.8 + 1;
if (i.8 != 90) goto L0; else goto L4;
L4:;
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17116
[Bug bootstrap/21230] [4.0/4.1 Regression] bootstrap failed unless bootstrap compiler is gcc.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01 16:33 --- Will take care of the patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-04-26 16:31:55 |2005-05-01 16:33:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21230
[Bug other/21319] Please add the feature of switching target at runtime
--- Additional Comments From radek at podgorny dot cz 2005-05-01 16:35 --- Oh, I see. Anyway, is 1-5% a major slowdown? I think it's still a good penalty if it saves all the headaches... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21319
[Bug c/21320] New: possible false positives for '$foo may be used uninitialized in this function'
this testcase is taken from subversion-1.1.4 subversion/libsvn_delta/svndiff.c install_gcc40-1/libexec/gcc/powerpc-unknown-linux-gnu/4.0.1/cc1 -fpreprocessed /tmp/t.i -quiet -dumpbase t.c -auxbase-strip t -O2 -Wall -version -o t.s GNU C version 4.0.1 20050429 (prerelease) (powerpc-unknown-linux-gnu) compiled by GNU C version 4.0.1 20050429 (prerelease). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 t.c: In function 'svn_txdelta_read_svndiff_window': t.c:149: warning: 'ninst' may be used uninitialized in this function -- Summary: possible false positives for '$foo may be used uninitialized in this function' Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: olh at suse dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21320
[Bug c/21320] possible false positives for '$foo may be used uninitialized in this function'
--- Additional Comments From olh at suse dot de 2005-05-01 16:44 --- Created an attachment (id=8784) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8784action=view) /tmp/pr21320-t.i.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21320
