[Bug bootstrap/30921] Bootstrap failure with -ftree-vectorize on i386
--- Comment #1 from irar at il dot ibm dot com 2007-02-22 07:58 --- Here is the ChangeLog entry for that patch: 2007-02-09 Richard Henderson [EMAIL PROTECTED] * config/i386/constraints.md (Ym): New constraint. * config/i386/i386.md (movsi_1): Change Y2 to Yi constraints. (movdi_1_rex64): Split sse and xmm general register moves from memory move alternatives. Use conditional register constraints. (movsf_1, movdf_integer): Likewise. (zero_extendsidi2_32, zero_extendsidi2_rex64): Likewise. (movdf_integer_rex64): New. (pushsf_rex64): Fix output constraints. * config/i386/sse.md (sse2_loadld): Split rm alternative, use Yi. (sse2_stored): Likewise. (sse2_storeq_rex64): New. * config/i386/i386.c (x86_inter_unit_moves): Enable for not amd and not generic. (ix86_secondary_memory_needed): Don't bypass TARGET_INTER_UNIT_MOVES for optimize_size. Remove SF/DFmode hack. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30921
[Bug bootstrap/30921] Bootstrap failure with -ftree-vectorize on i386
--- Comment #2 from ubizjak at gmail dot com 2007-02-22 08:11 --- (In reply to comment #0) Bootstrap with vectorization enabled fails on i386 starting from revision 121767: http://gcc.gnu.org/viewcvs?view=revrevision=121767 Could you post exact steps how to reproduce this failure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30921
[Bug tree-optimization/30858] [4.3 Regression] ice for legal code with -O2 -ftree-vectorize
--- Comment #10 from dorit at gcc dot gnu dot org 2007-02-22 08:16 --- Subject: Bug 30858 Author: dorit Date: Thu Feb 22 08:16:18 2007 New Revision: 10 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=10 Log: PR tree-optimization/30858 * tree-vectorizer.c (vect_is_simple_reduction): Check that the stmts in the reduction cycle have a single use in the loop. * tree-vectorizer.h (relevant): Add documentation. Added: trunk/gcc/testsuite/gcc.dg/vect/pr30858.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vectorizer.c trunk/gcc/tree-vectorizer.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30858
[Bug bootstrap/30921] Bootstrap failure with -ftree-vectorize on i386
--- Comment #3 from irar at il dot ibm dot com 2007-02-22 08:22 --- (In reply to comment #2) (In reply to comment #0) Bootstrap with vectorization enabled fails on i386 starting from revision 121767: http://gcc.gnu.org/viewcvs?view=revrevision=121767 Could you post exact steps how to reproduce this failure? Run make bootstrap BOOT_CFLAGS=-O2 -g -ftree-vectorize -msse2 Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30921
[Bug rtl-optimization/30841] Missed optimizations for sbi/cbi instructions
--- Comment #1 from bonzini at gnu dot org 2007-02-22 08:27 --- It's actually a small oversight in fwprop, which is supposed to replace find_best_addr indeed. The patch indicated in the URL is enough for dataflow-branch; on mainline you need also http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01797.html because of a bug in df that is already fixed on the branch. -- bonzini at gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||02/msg01796.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30841
[Bug tree-optimization/30904] VRP does not track values of shifts and/or bitfields?
--- Comment #7 from bonzini at gnu dot org 2007-02-22 08:41 --- Now that the patch has been applied to dataflow branch, this remains as a missed optimization on the tree level. -- bonzini at gnu dot org changed: What|Removed |Added CC|spark at gcc dot gnu dot org| Component|middle-end |tree-optimization Keywords||TREE Summary|[dataflow] No longer|VRP does not track values of |optimizes shifts with large |shifts and/or bitfields? |count | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- Comment #18 from peb at mppmu dot mpg dot de 2007-02-22 08:58 --- I have tried to analyze the cause of the -L flags passed to libtool when linking libsupc++ and libstdc++ and found these two: (1) explicit flags in the top-level RAW_CXX_FOR_TARGET passed as CXX to the libstdc++ and libjava modules, and (2) flags implicitly added by the GCC-modified libtool --tag CXX --mode=link for all directories in the compiler search path. This part is easily corrected by instead using --tag CC when linking libraries. I'd like to try to fix all this, but in order to do so I need some additional info. As far as I can see there are in principle three ways to build libstdc++: (A) as part of building GCC (with language c++), (B) independently with a prebuilt g++, or (C) independently with a non-GCC compiler. I think there is an obvious way to handle issue (1) above in case (A), but cases (B) and in particular (C) may pose additional problems. Question: are the possibilities (B) and (C) still viable? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug fortran/30922] New: IMPORT fails for same symbol in multiple interface bodies of same interface block
IMPORT fails, if one imports the same symbol in multiple interface bodies of
same interface block.
Found by Christopher D. Rickett,
http://gcc.gnu.org/ml/fortran/2007-02/msg00466.html
Test case:
module test_import
implicit none
type :: my_type
integer :: data
end type my_type
interface
integer function func1(param)
import :: my_type
type(my_type) :: param
end function func1
integer function func2(param)
import :: my_type
type(my_type), value :: param
end function func2
end interface
end module test_import
Error message:
integer function func1(param)
1
test_import.f03:4.17:
type :: my_type
2
Error: The type my_type cannot be host associated at (1) because it is
blocked by an incompatible object of the same name at (2)
Simple fix:
--
Index: resolve.c
===
--- resolve.c (revision 122189)
+++ resolve.c (working copy)
@@ -5656,7 +5656,8 @@
/* Check to see if a derived type is blocked from being host associated
by the presence of another class I symbol in the same namespace.
14.6.1.3 of the standard and the discussion on comp.lang.fortran. */
- if (sym-ts.type == BT_DERIVED sym-ns != sym-ts.derived-ns)
+ if (sym-ts.type == BT_DERIVED sym-ns != sym-ts.derived-ns
+ sym-ns-proc_name-attr.if_source != IFSRC_IFBODY)
{
gfc_symbol *s;
gfc_find_symbol (sym-ts.derived-name, sym-ns, 0, s);
--
Currently, IMPORT :: symbol copies the symbol like follows (simplified code;
decl.c, gfc_match_import):
---
gfc_find_symbol (name, gfc_current_ns-parent, 1, sym)
st = gfc_new_symtree (gfc_current_ns-sym_root, name);
st-n.sym = sym;
sym-refs++;
sym-ns = gfc_current_ns;
---
Possible implementation alternative, suggested by Paul Thomas,
http://gcc.gnu.org/ml/fortran/2007-02/msg00484.html
alternatively, I have wondered for a long time if
int ambiguous; in gfc_symtree is not out-of-order extravigant?
A bit-field, like symbol_attribute might be very useful. Needless to say,
imported could be added to ambiguous.
If we change the implementation, we could re-add
http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/trans-decl.c?r1=119412r2=119651pathrev=119651diff_format=h
cf. PR 27546.
--
Summary: IMPORT fails for same symbol in multiple interface
bodies of same interface block
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug fortran/30923] New: Warn by default when respecifiying USE associated NAMELIST
Cf. http://gcc.gnu.org/ml/fortran/2007-02/msg00145.html The following code is invalid Fortran as the USE-associated NAMELIST is respecified in the main program: MODULE debug LOGICAL debug_area NAMELIST/debugging/debug_area END MODULE debug PROGRAM ding USE debug IMPLICIT NONE NAMELIST/debugging/debug_area INTEGER :: ios OPEN(unit=10, status='unknown', file='input.dat') READ(unit=10, nml=debugging, iostat=ios) PRINT*, 'nml=debugging',ios END PROGRAM ding Gfortran and Portland group Fortran accept it by default, while xlf, ifort, NAG f95 and g95 reject it by default. Note that gfortran rejects it with -std=f2003: Error: Namelist group name 'debugging' at (1) already is USE associated and cannot be respecified. Should the GFC_STD_GNU be changed into GFC_STD_LEGACY? Or should there be a warning only for -std=gnu (= default option)? Or keep status quo? -- Summary: Warn by default when respecifiying USE associated NAMELIST Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30923
[Bug fortran/30882] size with initialization expression value for dim= is rejected
--- Comment #2 from pault at gcc dot gnu dot org 2007-02-22 09:30 --- (In reply to comment #1) This fixes it: Index: gcc/fortran/check.c === *** gcc/fortran/check.c (revision 122101) --- gcc/fortran/check.c (working copy) *** dim_rank_check (gfc_expr *dim, gfc_expr *** 337,343 ar = gfc_find_array_ref (array); rank = array-rank; ! if (ar-as-type == AS_ASSUMED_SIZE !allow_assumed) rank--; if (mpz_cmp_ui (dim-value.integer, 1) 0 --- 337,346 ar = gfc_find_array_ref (array); rank = array-rank; ! if (ar-as-type == AS_ASSUMED_SIZE !!allow_assumed !ar-type != AR_ELEMENT !ar-type != AR_SECTION) rank--; if (mpz_cmp_ui (dim-value.integer, 1) 0 As with other recent PRs, I cannot do anything with it for a bit - feel free to see it to completion. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30882
[Bug c++/30917] [4.1/4.2/4.3 Regression] ICE with friend in local class (to a function)
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-22 09:35 ---
This is a regression on the 4.1 branch. For reference, the valid testcase is
class QGList;
unsigned count()
{
class QGListIterator {
friend class QGList;
QGListIterator( const QGList );
};
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.1.2 4.3.0
Known to work||4.1.1 4.0.4
Last reconfirmed|-00-00 00:00:00 |2007-02-22 09:35:53
date||
Summary|[4.3 Regression] ICE with |[4.1/4.2/4.3 Regression] ICE
|friend in local class (to a |with friend in local class
|function) |(to a function)
Target Milestone|4.3.0 |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30917
[Bug target/30919] [4.1 regression] unable to find a register to spill in class 'CREG'
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-22 09:41 --- Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30919
[Bug bootstrap/30921] Bootstrap failure with -ftree-vectorize on i386
--- Comment #4 from ubizjak at gmail dot com 2007-02-22 09:54 --- Confirmed, the bootstrap breaks with; /home/uros/gcc-i386/./gcc/xgcc -B/home/uros/gcc-i386/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/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../../../gcc-svn/trunk/libgcc -I../../../gcc-svn/trunk/libgcc/. -I../../../gcc-svn/trunk/libgcc/../gcc -I../../../gcc-svn/trunk/libgcc/../include -I../../../gcc-svn/trunk/libgcc/../libdecnumber -I../../libdecnumber -o _floatdisf.o -MT _floatdisf.o -MD -MP -MF _floatdisf.dep -DL_floatdisf -c ../../../gcc-svn/trunk/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc-svn/trunk/libgcc/../gcc/libgcc2.c: In function â__fixunsxfdiâ: ../../../gcc-svn/trunk/libgcc/../gcc/libgcc2.c:1245: error: verify_flow_info: Wrong probability of edge 7-9 -2147483648 ../../../gcc-svn/trunk/libgcc/../gcc/libgcc2.c:1245: error: verify_flow_info: Wrong probability of edge 7-8 -2147473648 ../../../gcc-svn/trunk/libgcc/../gcc/libgcc2.c:1245: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_fixunsxfdi.o] Error 1 -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-22 09:54:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30921
[Bug c++/30924] New: Array of pointer type argument in partial template specialization fails
A quite simple array specialization construct is rejected by g++ with a
compiler error message. Not being a language specialist icc 9.1 accepts the
code even with -strict-ansi flag. Allegedly also comeau accepts the code. The
g++ compiler error message is also pretty strange and indicates a compiler bug.
templatetypename T
struct x {};
templatetypename T, unsigned N
struct xT*[N] {};
int main() {
xint a;
xint*[10] b;
return 0;
}
bash g++-4.1.2 -c tst.cpp
tst.cpp:7: error: template parameters not used in partial
specialization: tst.cpp:7: error: T
--
Summary: Array of pointer type argument in partial template
specialization fails
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enok at lysator dot liu dot se
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30924
[Bug c++/30924] Array of pointer type argument in partial template specialization fails
--- Comment #1 from enok at lysator dot liu dot se 2007-02-22 10:16 --- I'm unable to create attachments, bugzilla crashes. I have reported the bugzilla bug also to [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30924
[Bug middle-end/30907] [dataflow] Bad interaction with addressing mode selection and regalloc
--- Comment #3 from bonzini at gnu dot org 2007-02-22 10:20 --- This will also appear in mainline when the patch for PR30841 is applied -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30907
[Bug tree-optimization/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__
--- Comment #3 from ubizjak at gmail dot com 2007-02-22 11:04 ---
These warnirngs disappear by commenting out TARGET_HAS_SINCOS in
config/linux.h.
These warnings indeed point to pov::create_ray, where we have quite some tree
sincos transformations:
int pov::create_ray(pov::RAY*, double, double, int) (Ray, x, y, ray_number)
{
complex double sincostmp.447;
complex double sincostmp.446;
complex double sincostmp.445;
complex double sincostmp.444;
complex double sincostmp.443;
complex double sincostmp.442;
complex double sincostmp.441;
complex double sincostmp.440;
complex double sincostmp.439;
complex double sincostmp.438;
complex double sincostmp.437;
I'm adding Richard Guenther to the CC as he worken on tree sincos
transformation a while ago.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666
[Bug target/30919] [4.1 regression] unable to find a register to spill in class 'CREG'
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-22 11:04 ---
Confirmed. Whoever wrote that code should be
typedef long unsigned int size_t;
typedef signed int sal_Int32;
typedef unsigned int sal_uInt32;
typedef unsigned long int sal_uInt64;
extern C void *memcpy (void *__restrict __dest, __const void *__restrict
__src, size_t __n) throw () __attribute__ ((__nonnull__ (1, 2)));
void callVirtualMethod(void * pThis, sal_uInt64 *pStack, sal_uInt32 nStack)
{
sal_uInt64 *stack = (sal_uInt64 *) __builtin_alloca( nStack * 8 );
memcpy( stack, pStack, nStack * 8 );
register sal_uInt64 a0 asm(rdi);
register sal_uInt64 a1 asm(rsi);
register sal_uInt64 a2 asm(rdx);
register sal_uInt64 a3 asm(rcx);
register sal_uInt64 a4 asm(r8);
register sal_uInt64 a5 asm(r9);
sal_uInt64 pMethod = *((sal_uInt64 *)pThis);
typedef struct {} ReturnValue;
typedef ReturnValue (* FunctionCall )( sal_uInt64, sal_uInt64, sal_uInt64,
sal_uInt64, sal_uInt64, sal_uInt64 );
ReturnValue aRet = ( ( FunctionCall ) pMethod )( a0, a1, a2, a3, a4, a5 );
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2007-02-22 11:04:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30919
[Bug c++/30925] New: c++ frontend error: ?-operator parameter binding
When trying to compile test.cpp:
'
namespace {
struct A
{
A() {}
explicit A(short i) :m_value(i) {}
A operator = (short i) {
m_value = i;
return *this;
}
operator short () { return m_value; }
operator short () const { return m_value; }
private:
short m_value;
};
const A CONSTA(-1);
struct M {
void set(A value) const {
value = 1 ? m_a : CONSTA;
}
short m_a;
};
}
int main(int argc, char** argv) {
return 0;
}
'
test.cpp: In member function 'voidunnamed::M::set(unnamed::A) const':
test.cpp:28: error: passing 'constunnamed::A' as 'this' argument of
'unnamed::A::operator short int()' discards qualifiers
expected: convert const A to short and proceed.
Build/Plattform/Version/Config info, as requested:
Using built-in specs.
Target: sparc-sun-solaris2.9
Configured with: ../gcc-4.1.1/configure --prefix=/opt/gnu//gcc-4.1.1
--enable-languages=c,c++ --with-ld=/opt/gnu//bin/ld --with-as=/opt/gnu//bin/as
Thread model: posix
gcc version 4.1.1
/opt/gnu/gcc-4.1.1/bin/../libexec/gcc/sparc-sun-solaris2.9/4.1.1/cc1plus -E
-quiet -v -iprefix
/opt/gnu/gcc-4.1.1/bin/../lib/gcc/sparc-sun-solaris2.9/4.1.1/ test.cpp -mcpu=v7
-fpch-preprocess -o test.ii
ignoring nonexistent directory
/opt/gnu/gcc-4.1.1/bin/../lib/gcc/sparc-sun-solaris2.9/4.1.1/../../../../sparc-sun-solaris2.9/include
ignoring duplicate directory
/opt/gnu//gcc-4.1.1/lib/gcc/sparc-sun-solaris2.9/4.1.1/../../../../include/c++/4.1.1
ignoring duplicate directory
/opt/gnu//gcc-4.1.1/lib/gcc/sparc-sun-solaris2.9/4.1.1/../../../../include/c++/4.1.1/sparc-sun-solaris2.9
ignoring duplicate directory
/opt/gnu//gcc-4.1.1/lib/gcc/sparc-sun-solaris2.9/4.1.1/../../../../include/c++/4.1.1/backward
ignoring duplicate directory
/opt/gnu//gcc-4.1.1/lib/gcc/sparc-sun-solaris2.9/4.1.1/include
ignoring nonexistent directory
/opt/gnu//gcc-4.1.1/lib/gcc/sparc-sun-solaris2.9/4.1.1/../../../../sparc-sun-solaris2.9/include
#include ... search starts here:
#include ... search starts here:
/opt/gnu/gcc-4.1.1/bin/../lib/gcc/sparc-sun-solaris2.9/4.1.1/../../../../include/c++/4.1.1
/opt/gnu/gcc-4.1.1/bin/../lib/gcc/sparc-sun-solaris2.9/4.1.1/../../../../include/c++/4.1.1/sparc-sun-solaris2.9
/opt/gnu/gcc-4.1.1/bin/../lib/gcc/sparc-sun-solaris2.9/4.1.1/../../../../include/c++/4.1.1/backward
/opt/gnu/gcc-4.1.1/bin/../lib/gcc/sparc-sun-solaris2.9/4.1.1/include
/usr/local/include
/opt/gnu//gcc-4.1.1/include
/usr/include
End of search list.
/opt/gnu/gcc-4.1.1/bin/../libexec/gcc/sparc-sun-solaris2.9/4.1.1/cc1plus
-fpreprocessed test.ii -quiet -dumpbase test.cpp -mcpu=v7 -auxbase test
-version -o test.s
GNU C++ version 4.1.1 (sparc-sun-solaris2.9)
compiled by GNU C version 4.1.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3f2c8f59f6f5b35c02abcffa8ee26357
test.cpp: In member function 'voidunnamed::M::set(unnamed::F) const':
test.cpp:28: error: passing 'constunnamed::A' as 'this' argument of
'unnamed::A::operator short int()' discards qualifiers
--
Summary: c++ frontend error: ?-operator parameter binding
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: istvan at benedek-home dot de
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30925
[Bug target/30919] [4.1 regression] unable to find a register to spill in class 'CREG'
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-02-22 11:25 --- Confirmed. Whoever wrote that code should be You meant whoever wrote a compiler which accepts that code..., right. :-) -- 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=30919
[Bug tree-optimization/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-02-22 12:21 --- Dough - how is the middle-end supposed to handle this? The case in question get's a double sin(double) and wants to build _Complex double cexpi(double) It now uses tree.c:build_complex_type which seems to fix TYPE_CANONICAL in some way. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||doug dot gregor at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666
[Bug tree-optimization/30843] [4.3 Regression] ice for legal code with -ftree-vectorize -O2
--- Comment #8 from irar at gcc dot gnu dot org 2007-02-22 12:30 --- Subject: Bug 30843 Author: irar Date: Thu Feb 22 12:30:12 2007 New Revision: 15 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=15 Log: PR tree-optimization/30843 * tree-vect-transform.c (vect_transform_loop): Remove strided scalar stores only after all the group is vectorized. Added: trunk/gcc/testsuite/gcc.dg/vect/pr30843.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30843
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #5 from pmason at ricardo dot com 2007-02-22 12:40 --- Get same problem with equivalent P/E format: write(6,'(1pe6.0)') 1.0e-1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #6 from burnus at gcc dot gnu dot org 2007-02-22 13:50 ---
I think I found why the output is wrong. The following condition has been
introduced 2006-08-27 with the patch
http://gcc.gnu.org/viewcvs?view=revrevision=116502
Before the if the value is 0.1, afterwards it is 0.0.
/* Special case when format specifies no digits after the decimal point. */
if (d == 0)
{
if (value 0.5)
value = 0.0;
else if (value 1.0)
value = value + 0.5;
}
The changelog of that patch is:
PR libgfortran/28354
* io/write.c: Check for special case of zero precision in format
and pre-round the real value.
which fixed the bug 0.9 printed as 0. instead of 1. by format(f3.0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #7 from burnus at gcc dot gnu dot org 2007-02-22 13:59 --- Forget to mention: If I comment out that if-block, the output is correct (1.E-01). Now you need only to fix it without breaking the other PR ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-02-22 14:23 --- Thanks Tobias. I suspected a connection with that patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug debug/30898] [4.3 regression] ICE with anonymous union and -g
--- Comment #5 from ian at gcc dot gnu dot org 2007-02-22 14:55 --- Subject: Bug 30898 Author: ian Date: Thu Feb 22 14:55:09 2007 New Revision: 18 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=18 Log: ./: PR debug/30898 * dwarf2out.c (concatn_mem_loc_descriptor): New static function. (mem_loc_descriptor): Call it. testsuite/: * g++.dg/debug/pr30898.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/pr30898.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30898
[Bug libgcj/30886] Memory collection deadlock
--- Comment #3 from swagiaal at redhat dot com 2007-02-22 15:11 --- Expected: The collection quota (500 objects) is met and the program exits with a pass Actual; The program hangs before the quota is met. Some times not a single object is collected. This happens more frequently if System.gc() is called -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30886
[Bug libgcj/30886] Memory collection deadlock
--- Comment #4 from aph at gcc dot gnu dot org 2007-02-22 15:19 --- I can't see anything in the Java Language Standard that suggests that your test case must terminate. Garbage collection is not deterministic, and may not collect all objects. When I tried your test case one object was not reclaimed, probably because a reference to it still existed in the stack. In gcj we do a conservative scan of the stack, and there may be stale references that prevent objects from being collected. To guarantee that everything is collected you have to do a precise scan, and we deliberately don't do that. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30886
[Bug libgcj/30886] Memory collection deadlock
--- Comment #5 from swagiaal at redhat dot com 2007-02-22 15:35 --- Fare enough, I just thought I would bring my test case to your attention. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30886
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- Comment #19 from bfriesen at simple dot dallas dot tx dot us 2007-02-22 15:58 --- (In reply to comment #8) Note that, on PA, the linker does indeed annotate an executable with the location in which it found the library, but that's just a cache, it doesn't require the library to be there in order to function. Libtool knows about that, and does the right thing when linking with a libtool library, but libgcc_s isn't a libtool library, so libtool can't do much. It seems to me that on systems which encode the default library search path, this behavior becomes a security weakness associated with the installed library. If the GCC build directory is not secure in that it can't be re-created by another party, then applications searching for libraries in the build tree become subject to trojan horse type attacks. This is particularly the case when GCC is built under /tmp (as some people do) since once the tree has been removed, any other user on the system may create the necessary paths. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug debug/30898] [4.3 regression] ICE with anonymous union and -g
--- Comment #6 from ian at airs dot com 2007-02-22 16:00 --- Fixed. -- ian at airs dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30898
[Bug libgcj/17002] java.util.TimeZone.getDefault() is broken
--- Comment #6 from jakub at gcc dot gnu dot org 2007-02-22 16:05 ---
Subject: Bug 17002
Author: jakub
Date: Thu Feb 22 16:04:55 2007
New Revision: 19
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=19
Log:
libjava/
PR libgcj/17002
PR classpath/28550
* java/util/VMTimeZone.java (getDefaultTimeZoneId): To read
/etc/localtime, use ZoneInfo.readTZFile instead of
VMTimeZone.readtzFile. Get better timezone name for /etc/localtime,
either if it is a symlink or through /etc/sysconfig/clock.
(readSysconfigClockFile): New static method.
(readtzFile): Removed.
* java/lang/System.java: Add gnu.java.util.zoneinfo.dir to comments.
* posix.cc (_Jv_platform_initProperties): Set
gnu.java.util.zoneinfo.dir.
* sources.am (gnu_java_util_source_files): Add
classpath/gnu/java/util/ZoneInfo.java.
* Makefile.in: Regenerated.
* java/util/VMTimeZone.h: Regenerated.
* java/util/TimeZone.h: Regenerated.
* gnu/java/util/ZoneInfo.h: Generated.
libjava/classpath/
* java/util/Date.java (parse): Properly parse 09:01:02 as
hours/minutes/seconds, not as hours/minutes/year.
* java/util/SimpleTimeZone.java (SimpleTimeZone): Simplify
{start,end}TimeMode constructor by calling shorter constructor,
set {start,end}TimeMode fields after it returns.
(setStartRule): Don't adjust startTime into WALL_TIME. Set
startTimeMode to WALL_TIME.
(endStartRule): Similarly.
(getOffset): Handle properly millis + dstOffset overflowing into the
next day. Adjust startTime resp. endTime based on startTimeMode
resp. endTimeMode.
* java/util/TimeZone.java (zoneinfo_dir, availableIDs, aliases0): New
static fields.
(timezones): Remove synchronized keyword. Set zoneinfo_dir.
If non-null, set up aliases0 and don't put anything into
timezones0.
(defaultZone): Call getTimeZone instead of timezones().get.
(getDefaultTimeZone): Fix parsing of EST5 or EST5EDT6. Use
getTimeZoneInternal instead of timezones().get.
(parseTime): Parse correctly hour:minute.
(getTimeZoneInternal): New private method.
(getTimeZone): Do the custom ID checking first, canonicalize
ID for custom IDs as required by documentation. Call
getTimeZoneInternal to handle the rest.
(getAvailableIDs(int)): Add locking. Handle zoneinfo_dir != null.
(getAvailableIDs(File,String,ArrayList)): New private method.
(getAvailableIDs()): Add locking. Handle zoneinfo_dir != null.
* gnu/java/util/ZoneInfo.java: New file.
Added:
trunk/libjava/classpath/gnu/java/util/ZoneInfo.java
trunk/libjava/classpath/lib/gnu/java/util/ZoneInfo.class (with props)
trunk/libjava/gnu/java/util/ZoneInfo.h
Modified:
trunk/libjava/ChangeLog
trunk/libjava/Makefile.in
trunk/libjava/classpath/ChangeLog
trunk/libjava/classpath/java/util/Date.java
trunk/libjava/classpath/java/util/SimpleTimeZone.java
trunk/libjava/classpath/java/util/TimeZone.java
trunk/libjava/classpath/lib/java/util/Date.class
trunk/libjava/classpath/lib/java/util/SimpleTimeZone.class
trunk/libjava/classpath/lib/java/util/TimeZone$1.class
trunk/libjava/classpath/lib/java/util/TimeZone.class
trunk/libjava/classpath/lib/java/util/VMTimeZone.class
trunk/libjava/java/lang/System.java
trunk/libjava/java/util/TimeZone.h
trunk/libjava/java/util/VMTimeZone.h
trunk/libjava/java/util/VMTimeZone.java
trunk/libjava/posix.cc
trunk/libjava/sources.am
Propchange: trunk/libjava/classpath/lib/gnu/java/util/ZoneInfo.class
('svn:mime-type' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17002
[Bug c++/30112] pragma redefine_extname fails when namespaces are involved
--- Comment #3 from marc dot glisse at normalesup dot org 2007-02-22 16:20 --- Actually, the patch is not sufficient. With the patch, it works if the function is in the global namespace or the pragma is before the declaration (or both), but not for a function in the std namespace where the pragma is after the declaration, as is the case for wcsftime in solaris iso/wchar_iso.h. The little I understand: it seems that in c-pragma.c, for some reason, identifier_global_value(oldname) returns 0 in this case, so the renaming is not done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30112
[Bug preprocessor/30926] New: undef prepocessor directive ignored ?
trying to build cvs glibc as per instructions at cross-lfs.org's sysroot branch. with recent versions of mainline trunk(statically linked, no threads build) i get build errors like: ../sysdeps/ieee754/dbl-64/s_signbit.c:27: error: redefinition of '__signbit' ../sysdeps/x86_64/fpu/bits/mathinline.h:43: error: previous definition of '__sig nbit' was here it doesn't happen with 4.1 the command line was: x86_64-maxxcorp-linux-gnu-gcc ../sysdeps/ieee754/dbl-64/s_signbit.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-strings -combine -fmerge-all-constants -m64 -march=athlon64 -save-temps -Wstrict-prototypes -Wno-uninitialized -D__NO_MATH_INLINES -D __LIBC_INTERNAL_MATH_INLINES -I../include -I/mnt/lfs/sources/glibc-build/math -I /mnt/lfs/sources/glibc-build -I../sysdeps/x86_64/elf -I../nptl/sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/fpu -I../nptl/sysdeps/x86_64 -I../sysdeps/x86_64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I.. -I../libio -I. -nostdinc -isystem /mnt/lfs/cross-tools/lib/gcc/x86_64-maxxcorp-linux-gnu/4.3.0/include -isystem /mnt/lfs/usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /mnt/lfs/sources/glibc-build/math/s_signbit.o -MD -MP -MF /mnt/lfs/sources/glibc-build/math/s_signbit.o.dt -MT /mnt/lfs/sources/glibc-build/math/s_signbit.o -- Summary: undef prepocessor directive ignored ? Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: maxim_m at gmx dot net GCC build triplet: x86_64-cross-linux-gnu GCC host triplet: x86_64-maxxcorp-linux-gnu GCC target triplet: x86_64-maxxcorp-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30926
[Bug rtl-optimization/30841] Missed optimizations for sbi/cbi instructions
--- Comment #2 from bonzini at gnu dot org 2007-02-22 16:46 --- Changing the patch address since part 1 was approved. And adding bug 30907 since committing part 2 would cause that bug to surface on mainline. -- bonzini at gnu dot org changed: What|Removed |Added BugsThisDependsOn||30907 URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2007- |patches/2007- |02/msg01796.html|02/msg01797.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30841
[Bug middle-end/30907] [4.3 regression] Propagation of addresses within loops pessimizes code
--- Comment #4 from bonzini at gnu dot org 2007-02-22 16:48 --- Though we don't have a testcase for mainline, the bug is there too. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Known to fail||4.3.0 Known to work||4.2.0 Last reconfirmed|2007-02-21 15:53:40 |2007-02-22 16:48:27 date|| Summary|[dataflow] Bad interaction |[4.3 regression] Propagation |with addressing mode|of addresses within loops |selection and regalloc |pessimizes code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30907
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-02-22 17:04 ---
Can you walk me through some of the checks and why they can be removed? I see
(.004.gimple dump):
source = source_first;
target = target_first;
source_last.0 = (js__TsB) source_last;
source_first.1 = (js__TsB) source_first;
if (source_last.0 source_first.1)
{
if (target_first == 10)
{
__gnat_rcheck_04 (join_equal.adb, 13);
}
else
{
}
if (target_first == 128)
{
__gnat_rcheck_12 (join_equal.adb, 15);
iftmp.2 = target_first;
}
else
{
iftmp.2 = target_first;
}
iftmp.3 = iftmp.2;
iftmp.4 = (js__TtB) iftmp.3;
if (iftmp.4 = 10)
{
goto D1039;
}
else
{
}
iftmp.4 = (js__TtB) iftmp.3;
if (iftmp.4 21)
{
goto D1039;
}
else
{
goto D1040;
}
D1039:;
__gnat_rcheck_12 (join_equal.adb, 15);
D1040:;
if (target_first == 128)
{
__gnat_rcheck_12 (join_equal.adb, 15);
iftmp.5 = target_first;
}
else
{
iftmp.5 = target_first;
}
iftmp.6 = iftmp.5;
iftmp.7 = (js__TtB) iftmp.6;
D.1047 = iftmp.7 + -1;
target_last = (j__target_type___XDLU_10__20) D.1047;
goto D1016;
I assume all of the above is gimplified from just
if Source_Last Source_First then
if Target_First = Target_Type'First then
raise Constraint_Error;
end if;
Target_Last := Target_Type'Pred (Target_First);
return;
? So in essence VRP should somehow be able to see that
Target_Type'Pred (Target_First) cannot be out of bounds because Target_First
is not Target_Type'First, correct? But given the gimplified form above
we also need to prove Target_First is not 128 (where does that come from?
It looks like __gnat_rcheck_12 is not a noreturn function?). We also
need to prove that (js__TtB) Target_First is 10 (that looks doable from
the != 10 range we can extract from the first range check). But where
does the check against 21 come from? The 2nd check for 128 looks redundant
and indeed we remove it in VRP1.
I need to look closer at what js__TtB actually is looking like, but this
is at least a useful testcase.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug target/30921] [4.3 Regression] Bootstrap failure with -ftree-vectorize on i386
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target Keywords||build Summary|Bootstrap failure with -|[4.3 Regression] Bootstrap |ftree-vectorize on i386 |failure with -ftree- ||vectorize on i386 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30921
[Bug middle-end/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-22 17:21 --- There is also code in build_common_tree_nodes_2 which needs changed to use build_complex_type which also could be causing issues too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666
[Bug preprocessor/30926] undef prepocessor directive ignored ?
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-22 17:29 --- __signbit is not a macro so it cannot be undefined. Also this is because extern inline changed meaning for -std=c99/-std=gnu99 to be the C99 meaning instead of what GNU C decided it ment. You need to use a newer version of glibc which has this fix in it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30926
[Bug tree-optimization/30927] New: tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
If a nested subroutine calls another nested subroutine that follows it
lexically, then convert_all_function_calls will force the called function to
take a static chain even though it may not need one. The most trivial example
of this is a recursive nested subroutine, as in example n1.c:
void n1(void) { void a(void) { a(); } }
$ gcc -c n1.c -fdump-tree-nested
$ grep chain n1.c.*nested
a () [static-chain: CHAIN.1];
A pointless static chain has been created.
Here's an example n2.c in which the caller and callee disagree about whether a
static chain is needed or not: the caller thinks it is needed, the callee does
not.
void n2(void) {
auto void a(void);
void b(void) { a(); }
void a(void) {}
}
This might seem fairly harmless, but can become expensive when trampolines are
needlessly created. Example n3.c:
void n3(void) {
auto void a(void *);
void b(void) { a(b); }
void a(void *f) {}
}
$ gcc -c n3.c -fdump-tree-nested
$ grep trampoline n3.c.*nested
struct __builtin_trampoline * D.1631;
D.1632 = __builtin_adjust_trampoline (D.1631);
__builtin_init_trampoline (FRAME.0.b, b, FRAME.0);
In Ada, nested subroutines are widely used, and unneeded static chains are
frequently being created by gcc: I first noticed this problem while
bootstrapping the compiler with a patch that happened to print a warning in
case n2.c: the warning fired hundreds of times during the Ada build. The most
common reason for this seems to be due to the instantiation of generic packages
inside library level procedures.
--
Summary: tree-nested creates pointless static chains and
trampolines when the callgraph is non-trivial
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-02-22 17:33 --- Do not work too hard on this, there is code in the AdaCore tree to disable VRP in more cases, lest language-mandated checks are erroneously removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-02-22 17:40 --- Try this: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01201.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-22 17:40:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #6 from baldrick at gcc dot gnu dot org 2007-02-22 17:41 --- Bonus points if you can reduce this to a C test case ;-) Starting with the gimple dumps, this is usually not hard to do. It can't be reduced because it relies on integer types with restricted ranges, i.e. TYPE_MIN_VALUE and/or TYPE_MAX_VALUE different from what you'd get from TYPE_PRECISION and the signedness. Adding some kind of attribute to C so that you can create similar types there would be helpful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-02-22 18:00 --- Do not work too hard on this, there is code in the AdaCore tree to disable VRP in more cases, lest language-mandated checks are erroneously removed. For example PR ada/26797. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26797 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-22 18:00:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug target/30921] [4.3 Regression] Bootstrap failure with -ftree-vectorize on i386
--- Comment #5 from rth at gcc dot gnu dot org 2007-02-22 18:07 --- I don't think this has anything to do with either vectorization or my patch. I was seeing that same failure with --with-arch=pentium4 before my patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30921
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #8 from baldrick at gcc dot gnu dot org 2007-02-22 18:14 --- Can you walk me through some of the checks and why they can be removed? I see (.004.gimple dump): ... I assume all of the above is gimplified from just if Source_Last Source_First then if Target_First = Target_Type'First then raise Constraint_Error; end if; Target_Last := Target_Type'Pred (Target_First); return; Yes. Amazing, isn't it ;) The important thing to keep in mind is that all target variables must be in the range 10..20, and all source variables in the range 0..100 (see the definitions type S is range 0 .. 100; -- S corresponds to Source_Type in Join_Equal type T is range 10 .. 20; -- T corresponds to Target_Type in Join_Equal ). What does must be in the range mean? Firstly, the program behaviour is undefined if a variable is outside its range. This is the same as for signed overflow. It's just that here overflow starts at 100 or at 20, not at INT_MAX! Secondly, the language requires the compiler to check at the point of the call that the values passed to the Join_Equal subprogram are in the right ranges. If not, an exception is raised. Likewise, at points where you do arithmetic like adding or subtracting 1, the compiler inserts checks that the result will not go out of range. If not, an exception is raised. That's where all this code is coming from. Anyway, the practical upshot is that VRP is allowed to assume that source_first and source_last have values in the range 0..100, and target_first and target_last have values in the range 10..20. Using this, it should be able to eliminate all of the compiler inserted range checking. ? So in essence VRP should somehow be able to see that Target_Type'Pred (Target_First) cannot be out of bounds because Target_First is not Target_Type'First, correct? Exactly. But given the gimplified form above we also need to prove Target_First is not 128 (where does that come from? It cannot be 128 because it is in the range 10..20. As to why the compiler inserted 128, good question! Probably it has placed target in an unsigned variable with 8-bit precision, and is checking that some computation it is about to do in that variable will not overflow. It looks like __gnat_rcheck_12 is not a noreturn function?). It is a noreturn function. It just raises a language defined exception. We also need to prove that (js__TtB) Target_First is 10 (that looks doable from the != 10 range we can extract from the first range check). But where does the check against 21 come from? It seems to be another pointless check the compiler has inserted. It can be removed because iftmp.4 is in the range 11..20. The 2nd check for 128 looks redundant and indeed we remove it in VRP1. Yes. I need to look closer at what js__TtB actually is looking like, but this is at least a useful testcase. Probably this is the base type for the type js__T (aka JS.T) in the original source. The idea of a base type is that that's the type that has the full range you would expect from the precision. Most likely type T, with range 10..20, has been assigned 8 bit precision by the compiler, and has a base type js__TtB with range -128..127, i.e. a normal C signed byte. The compiler systematically converts to the base type before doing arithmetic. After the arithmetic, it checks whether the result is in the range of the original type (10..20). If not, it raises an exception (__gnat_rcheck_12), and otherwise it it put the result back in the type T variable. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|26797 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #9 from baldrick at gcc dot gnu dot org 2007-02-22 18:18 --- (In reply to comment #7) Do not work too hard on this, there is code in the AdaCore tree to disable VRP in more cases, lest language-mandated checks are erroneously removed. For example PR ada/26797. That is quite a different issue. Eliminating the checks in this example is perfectly valid and useful. I certainly hope that you are not planning to turn off VRP permanently, since it is particularly important for Ada. I can understand that you have to be careful with validity checks (which is what VIEW_CONVERT_EXPR is for) but that's orthogonal to this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-02-22 18:19 --- Please do not overwrite changes, thanks. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26797 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug libstdc++/30928] New: add casts to libc overloads
Headers like cwchar add overloads to libc functions. Here I am interested in
the functions for which the standard C version takes a const pointer and
returns a non-const pointer and in C++ this version is replaced by one with
const everywhere and one with no const anywhere. For this, in c_std mode, g++
takes the libc version (instead of the full-const version) and adds an overload
which looks like:
inline wchar_t*
wcschr(wchar_t* __p, wchar_t __c)
{ return wcschr(const_castconst wchar_t*(__p), __c); }
The const_cast does not look very useful, but that is not the issue (it makes
it easier to understand, which is good). I was wondering whether it would be
acceptable to add a const_castwchar_t* to the returned value? For the current
uses, it would do nothing. But now if a libc decided to provide the full-const
version when called by a c++ compiler, this would make it work.
Is there any real case where it would help? Well if bugs 27340 (trivial) and
30112 get fixed, with the following fixinclude rule, it would be the last thing
preventing from being able to set __cplusplus to either 1 or 199711L with no
testsuite regression (except for breaking the ABI) on solaris (I only checked
with 8). Of course this is only one way to achieve this (not the best one, but
it requires very little patching).
I will understand if you say no, I am just hoping for a why not? It doesn't
hurt. (remember that in this bug I am only talking about adding some
const_casts, the __cplusplus value is an other issue)
The fixinclude rule, for info (I am not proposing it here, just mentionning it
for completeness)
/*
* Remove extern C++ parts of solaris libc
*/
fix = {
hackname = solaris_no_extern_cpp;
mach = '*-*-solaris*';
files = iso/ctype_iso.h;
files = iso/limits_iso.h;
files = iso/locale_iso.h;
files = iso/math_iso.h;
files = iso/setjmp_iso.h;
files = iso/signal_iso.h;
files = iso/stdarg_iso.h;
files = iso/stddef_iso.h;
files = iso/stdio_iso.h;
files = iso/stdlib_iso.h;
files = iso/string_iso.h;
files = iso/time_iso.h;
files = iso/wchar_iso.h;
files = iso/wctype_iso.h;
select= 'extern[ \t]*C\+\+';
shell = perl -e 'undef $/;$_=;s/extern[ \t]*\C\\\+\\\+\[
\t]*{([^{}]*{[^{}]*})*[^{}]*}//gs;print';
test_text = 'extern C++ {void f();}';
};
(this uses perl, which I think has been part of the system for a very long
time, because I don't know how to do it with sed. I also don't know if the
files field accepts wildcards)
--
Summary: add casts to libc overloads
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928
[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
--- Comment #3 from sdirkse at gams dot com 2007-02-22 18:52 --- I took out the restriction in resolve.c that leads to the error message, and it does give me a clean compile, but the code does not do what I expect. For example, passing a real(kind=8) by-value to C doesn't get me a good double, ditto for a integer(kind=8). The examples work when using ifort/icc. I can send them if you'd like, but they are vanilla one-liners, almost. Enough facts, now for some ignorant speculation: I suppose there is some logic missing to pass a value from the caller when the size of the value is not the default size (i.e. 4 for my platform, Linux 32-bit). -- sdirkse at gams dot com changed: What|Removed |Added CC||sdirkse at gams dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
[Bug middle-end/30864] [4.3 Regression] ice for legal code with -O2
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-22 19:04 ---
Reduced testcase:
struct QString { ~QString(); };
template class T struct QValueListNode {
QValueListNodeT* next;
T data;
};
template class T struct QValueListPrivate
{
~QValueListPrivate()
{
QValueListNodeT* p = node-next;
while( p != node )
{
QValueListNodeT* x = p-next;
delete p;
p = x;
}
}
QValueListNodeT* node;
};
struct Option { QString sarg; };
struct Options {
QString helptext;
QValueListPrivate QString filelist;
QValueListPrivate Option optlist;
};
Options options;
Backtrace:
#0 fancy_abort (file=0xda8f04 ../../gcc/cfg.c, line=665, function=0xda92c0
alloc_aux_for_block) at ../../gcc/diagnostic.c:642
#1 0x00797674 in alloc_aux_for_block (bb=0xf6fbe0, size=24) at
../../gcc/cfg.c:665
#2 0x007979d8 in alloc_aux_for_blocks (size=24) at ../../gcc/cfg.c:693
#3 0x00989adc in estimate_bb_frequencies () at ../../gcc/predict.c:1712
#4 0x004b7594 in execute_function_todo (data=0x463d) at ../../gcc/passes.c:899
#5 0x004b6e70 in do_per_function (callback=0x4b71d4 execute_function_todo,
data=0x463d) at ../../gcc/passes.c:754
#6 0x004b76d8 in execute_todo (flags=17981) at ../../gcc/passes.c:932
#7 0x004b7e0c in execute_one_pass (pass=0xe9956c) at ../../gcc/passes.c:1077
(gdb) p *pass
$2 = {
name = 0xd82eb0 apply_inline,
Note I reduced this to be able to reproduce with just -O2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2007-02-22 19:04:49
date||
Summary|[4.3 Regression] ice for|[4.3 Regression] ice for
|legal code with -O3 |legal code with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30864
[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-22 19:24 --- (In reply to comment #3) Enough facts, now for some ignorant speculation: I suppose there is some logic missing to pass a value from the caller when the size of the value is not the default size (i.e. 4 for my platform, Linux 32-bit). See conv_arglist_function in trans-expr.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
[Bug libstdc++/25896] [DR 526] hash_map::erase, unordered_map::erase fail if key is inside the table
--- Comment #5 from pcarlini at suse dot de 2007-02-22 19:29 --- Now that we have a resolution for DR 526: http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#526 we can fix this problem too, similarly to like libstdc++/17012. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|SUSPENDED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25896
[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-20 17:32:54 |2007-02-22 19:50:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
[Bug c++/29475] [4.0/4.1/4.2 Regression] incomplete template diagnostics.
--- Comment #8 from simartin at gcc dot gnu dot org 2007-02-22 19:58 --- Subject: Bug 29475 Author: simartin Date: Thu Feb 22 19:57:55 2007 New Revision: 122236 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122236 Log: 2007-02-22 Simon Martin [EMAIL PROTECTED] PR c++/29475 * cp-tree.h (struct deferred_access_check): New structure to represent a deferred access check. It replaces the previous representation as a tree. (get_deferred_access_checks): Return a vector of struct deferred_access_check instead of a tree list. (perform_access_checks): Take a vector of struct deferred_access_check instead of a tree list. (enforce_access, perform_or_defer_access_check): Added an extra argument that represents the declaration to use to print potential error messages. * semantics.c (struct deferred_access): Store the deferred access checks as a vector of struct deferred_access_check instead of a tree list. (push_deferring_access_checks): Handle the change in struct deferred_access. (get_deferred_access_checks): Likewise. (pop_to_parent_deferring_access_checks): Likewise. (perform_or_defer_access_check): Likewise. (perform_access_checks): Take a vector of struct deferred_access_check instead of a tree list. (finish_non_static_data_member, check_accessibility_of_qualified_id, finish_id_expression): Adjusted the call to perform_or_defer_access_check. (pop_to_parent_deferring_access_checks, perform_access_checks, perform_or_defer_access_check): Adjusted the call to enforce_access. * parser.c (struct tree_check): New structure to store various data associated with a CPP_NESTED_NAME_SPECIFIER or CPP_TEMPLATE_ID token. (struct cp_token): Changed the value field to be a union with a pointer to a struct tree_check for CPP_NESTED_NAME_SPECIFIER or CPP_TEMPLATE_ID tokens and a tree field for all other tokens. (eof_token): Adjusted due to the change in struct cp_token. (cp_lexer_get_preprocessor_token): Likewise. (cp_lexer_purge_token): Likewise. (cp_lexer_purge_tokens_after): Likewise. (cp_lexer_print_token): Likewise. (cp_parser_error): Likewise. (cp_parser_identifier): Likewise. (cp_parser_string_literal): Likewise. (cp_parser_primary_expression): Likewise. (cp_parser_unqualified_id): Likewise. (cp_parser_parenthesized_expression_list): Likewise. (cp_parser_storage_class_specifier_opt): Likewise. (cp_parser_function_specifier_opt): Likewise. (cp_parser_type_specifier): Likewise. (cp_parser_simple_type_specifier): Likewise. (cp_parser_initializer_list): Likewise. (cp_parser_member_specification_opt): Likewise. (cp_parser_attribute_list): Likewise. (cp_parser_objc_expression): Likewise. (cp_parser_objc_protocol_qualifiers): Likewise. (cp_parser_objc_selector): Likewise. (cp_parser_objc_declaration): Likewise. (cp_parser_objc_statement): Likewise. (cp_parser_omp_clause_name): Likewise. (cp_parser_omp_clause_default): Likewise. (cp_parser_omp_clause_schedule): Likewise. (cp_parser_omp_parallel): Likewise. (cp_parser_initial_pragma): Likewise. (pragma_lex): Likewise. (cp_parser_pre_parsed_nested_name_specifier): Likewise. (cp_parser_nested_name_specifier_opt): Likewise. Use cp_token::u::tree_check_value to save the token's value, the associated deferred checks and its qualifying scope. (cp_parser_template_id): Likewise. (cp_parser_template_declaration_after_export): Adjusted the call to get_deferred_access_checks. (cp_parser_init_declarator): Take the access checks as a vector of struct deferred_access_check instead of a tree list. (cp_parser_single_declaration): Likewise. (cp_parser_perform_template_parameter_access_checks): Likewise. (cp_parser_simple_declaration): Adjusted the call to cp_parser_init_declarator. (cp_parser_explicit_specialization): Adjusted the call to cp_parser_single_declaration. (cp_parser_template_id, cp_parser_pre_parsed_nested_name_specifier): Adjusted the call to perform_or_defer_access_check. * init.c (build_offset_ref): Adjusted the call to perform_or_defer_access_check. * class.c (alter_access, resolve_address_of_overloaded_function): Likewise. * decl.c (make_typename_type, make_unbound_class_template): Likewise. * search.c (lookup_member): Likewise. * friend.c (add_friend): Likewise. * call.c (enforce_access): Use the new extra argument to build the error message. (build_op_delete_call): Adjusted the call to
[Bug c++/29475] [4.0/4.1 Regression] incomplete template diagnostics.
--- Comment #9 from simartin at gcc dot gnu dot org 2007-02-22 20:09 --- Fixed on 4.2 as well. I will not apply it on 4.1 as requested by Mark here: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01781.html -- simartin at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] |incomplete template|incomplete template |diagnostics.|diagnostics. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29475
[Bug c++/29475] [4.0/4.1 Regression] incomplete template diagnostics.
--- Comment #10 from pluto at agmk dot net 2007-02-22 20:23 --- fixed for = 4.2 wontfix for 4.2 ( too big impact for mature branches ). -- pluto at agmk dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29475
[Bug fortran/30531] allocatable component and intent(out) yield ICE in fold_convert
--- Comment #7 from pault at gcc dot gnu dot org 2007-02-22 20:36 --- (In reply to comment #6) Created an attachment (id=12987) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12987action=view) [edit] This fixes the PR This is just now regtesting - I am pretty sure that it is OK. It will take a day or two to feed into the loop. Paul This patch fixes the problem but does not regtest - needs thought. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
--- Comment #5 from patchapp at dberlin dot org 2007-02-22 21:10 --- Subject: Bug number PR30887 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/msg01839.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
[Bug fortran/30929] New: -pedantic-error produced only warnings and no errors
Example:
...testsuite/gfortran.dg gfortran -c -pedantic-errors c_by_val_4.f ; echo $?
c_by_val_4.f:14.22:
CALL DOIT( %VAL( P ) ) ! { dg-warning Extension: argument list fu
1
Warnung: Extension: argument list function at (1)
c_by_val_4.f:16.22:
CALL DOIT( %VAL( P ) ) ! { dg-warning Extension: argument list fu
1
Warnung: Extension: argument list function at (1)
0
Expected:
- Non-zero exit code
- Error: instead of Warning:
Have fun when fixing this as several dg-do run tests have -pedantic warnings,
-no-pedantic does not exist, and dg.exp contains:
set DEFAULT_FFLAGS -pedantic-errors
--
Summary: -pedantic-error produced only warnings and no errors
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
[Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
--- Comment #6 from sdirkse at gams dot com 2007-02-22 21:35 --- (In reply to comment #4) (In reply to comment #3) Enough facts, now for some ignorant speculation: I suppose there is some logic missing to pass a value from the caller when the size of the value is not the default size (i.e. 4 for my platform, Linux 32-bit). See conv_arglist_function in trans-expr.c. Brilliant! I changed the code in there to use a size of MAX(default_kind,expression_kind) instead of just default_kind, and it seems to work now, i.e. the one-liner example is OK. The code was easier to read and modify than I was expecting, a pleasant surprise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
[Bug tree-optimization/30930] New: [4.3 Regression] vector can cause to create an extra variable
While trying to make DECL_GIMPLE_REG_P more generic, I ran into a regression
due to we never change non gimple register variables into gimple registers so I
looked into it and found that I could also reproduce it in the current sources
with vector types (complex does not matter as much as they are always SRA'd).
Testcase:
#define vector __attribute__(( vector_size(16) ))
vector float f(vector float a, int b, vector float c)
{
vector float dd = c*a;
if (0)
{
vector float *d = a;
vector float *d1 = c;
g:;
}
if (b)
return dd * a;
return c*a;
}
You will see that a is never turned into a gimple register which could cause
some issues with debugging info and also this introduces an extra variable
which could cause a memory usage/compile time slow down.
--
Summary: [4.3 Regression] vector can cause to create an extra
variable
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30930
[Bug fortran/30660] [4.2 and 4.1 only] Allocatable components of a derived type require the SAVE attribute.
--- Comment #9 from patchapp at dberlin dot org 2007-02-22 22:10 --- Subject: Bug number PR30660 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/msg01848.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30660
[Bug rtl-optimization/30931] New: Simple test case loops infinitely with -O1 -fstrength-reduce.
The simple test which I'll attach shortly, loops infinitely when compiled with -O1 -fstrength-reduce and executes fine with plain -O1. Doing a little debugging, it seems the loop index variable i is not incremented within the loop causing us to loop forever. I have tested this using the latest FSF 4.1, 4.2 and mainline compiler sources and it only fails using the 4.1 compiler. Using an older 3.4.6 distro compiler, it executes fine, so this _looks_ like a regression. -- Summary: Simple test case loops infinitely with -O1 -fstrength- reduce. Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bergner at gcc dot gnu dot org GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug rtl-optimization/30931] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #1 from bergner at gcc dot gnu dot org 2007-02-22 22:40 --- Created an attachment (id=13092) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13092action=view) Reduced testcase showing the infinite looping -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #11 from baldrick at gcc dot gnu dot org 2007-02-22 22:54 --- Please do not overwrite changes, thanks. Sorry about that - it wasn't on purpose: your comment and mine collided. I actually checked the two bugs after getting the message that I'd manage to wipe out your change, and the relationship between 26797 and 30911 that you'd set up still seemed to be there. So I guess bugzilla is too subtle for me... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30930] [4.3 Regression] vector can cause to create an extra variable
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30930
[Bug fortran/30932] New: [meta-bug] fortran intrinsics
A meta-bug for PRs about fortran intrinsics. -- Summary: [meta-bug] fortran intrinsics Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org OtherBugsDependingO 30372 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30932
[Bug rtl-optimization/30931] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #2 from steven at gcc dot gnu dot org 2007-02-22 23:26 --- I cannot reproduce this. Please paste the output of gcc -v. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug rtl-optimization/30931] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-22 23:29 --- it only fails using the 4.1 compiler. Well that is because loop.c has been removed in 4.2 and above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug rtl-optimization/30931] Simple test case loops infinitely with -O1 -fstrength-reduce.
--- Comment #4 from bergner at gcc dot gnu dot org 2007-02-22 23:32 --- This is using source checked out this afternoon (revision 122219): bg47:bergner% ./install/gcc-4.1/bin/gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc-4_1-20070222/configure --enable-shared --enable-threads=posix --enable-checking --enable-languages=c --prefix=/tmp/bergner/install/gcc-4.1 Thread model: posix gcc version 4.1.3 20070222 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug fortran/30933] New: intrinsic: EXIT
CALL exit(status=i) The documented argument name status is rejected (but count is allowed): gcc/fortran/intrinsic.c:2458-2460: add_sym_1s (exit, 0, BT_UNKNOWN, 0, GFC_STD_GNU, gfc_check_exit, NULL, gfc_resolve_exit, c, BT_INTEGER, di, OPTIONAL); -- Summary: intrinsic: EXIT Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug c++/30925] c++ frontend error: ?-operator parameter binding
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-22 23:37 --- Hmm, ?: is a lvalue in C++. Since m_a is still an lvalue (a non modifiable one though) we try to use operator short so we get the same type, const short, on both sides of the : as short is a closer match to const short as for short you have to bind a rvalue to a lvalue which is a longer way around. So is not a bug in GCC. If you want this to work, change operator short to operator const short and it will just work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30925
[Bug fortran/30933] intrinsic: EXIT
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-02-22 23:40 --- Created an attachment (id=13093) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13093action=view) testcase (dg-do compile) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30933] intrinsic: EXIT
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-02-22 23:40 --- Created an attachment (id=13094) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13094action=view) testcase (dg-do link) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug c++/30924] [4.1/4.2/4.3 Regression] Array of pointer type argument in partial template specialization fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-22 23:43 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||4.0.2 4.3.0 Known to work||3.3.5 Last reconfirmed|-00-00 00:00:00 |2007-02-22 23:43:19 date|| Summary|Array of pointer type |[4.1/4.2/4.3 Regression] |argument in partial template|Array of pointer type |specialization fails|argument in partial template ||specialization fails Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30924
[Bug tree-optimization/30913] SRA bugs with anon bitfields
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-22 23:45 --- The second part of this bug is recorded as PR 22156. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30913
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|bootstrap |libstdc++ Keywords||build Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug bootstrap/30914] Bootstrap fails on HP-UX
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-22 23:54 --- How did you configure GCC? Can you try building in a different directory from the source directory? Also make sure you have read http://gcc.gnu.org/install/ . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30914
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/30900] relocation R_X86_64_PC32 BUG
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-22 23:58 --- This is a bug in libstdc++ which was fixed in 4.2.0. But note the code uses -fvisibility-inlines-hidden -fvisibility=hidden without testing if the system library has been fixed. It only checks if those options work. *** This bug has been marked as a duplicate of 19664 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30900
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #102 from pinskia at gcc dot gnu dot org 2007-02-22 23:58 --- *** Bug 30900 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||centi_riccardo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug bootstrap/30828] make bootstrap failed on linux
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-23 00:01 --- *** This bug has been marked as a duplicate of 30889 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30828
[Bug bootstrap/30889] make bootstrap failed on linux
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-23 00:01 --- *** Bug 30828 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30889
[Bug target/30868] can't compile empty main in c on hppa 11iv1 (11.11)
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-23 00:03 --- This is a precompiled GCC which means we don't support this. What is happening is that somene compiled it for their OS (which has a new symbol) and then copied it to your machine and now it does not work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30868
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #30 from pinskia at gcc dot gnu dot org 2007-02-23 00:07 --- I think this is really a duplicate of bug 30509 which has a nice short testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30509 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug c++/30866] [4.3 regression] Another ICE in calc_dfs_tree()
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-23 00:07 --- I think this is really a duplicate of bug 30509 which has a nice short testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30866
[Bug middle-end/30833] [4.3 Regression] ICE with -fdump-tree-all
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-23 00:10 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30833
[Bug bootstrap/30853] warnings about traditional.c during bootstrap with -O3, leading to internal error
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-23 00:11 --- --enable-bootstrap Don't use that option for 4.1.x. Can you try again without that option? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30853
[Bug fortran/30933] intrinsic: EXIT
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-02-23 00:21 --- A note on the testcase: gfortran seems to resolve EXIT only once. If CALL exit() CALL exit(int_1) gfortran happily compiles and links. If CALL exit(int_1) CALL exit() then /tmp/ccuE9OGi.o: In function `MAIN__': subroutine-exit-link.f90:(.text+0x31): undefined reference to `_gfortran_exit_i1' collect2: ld returned 1 exit status The same goes for `_gfortran_exit_i2': if CALL exit(int_1) CALL exit(int_2) then only `_gfortran_exit_i1' is missing -- and vice versa. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30933] intrinsic: EXIT
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-02-23 00:38 --- The documentation states: Arguments: STATUS The type of the argument shall be INTEGER(*). but arguments of kind INTEGER(kind=1) and INTEGER(kind=2) may lead to unresolved symbols (see also comment #3). -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Keywords||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug target/30825] [4.3 Regression] current mainline fails to bootstrap with --with-arch=athlon64
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target Summary|current mainline fails to |[4.3 Regression] current |bootstrap with --with- |mainline fails to bootstrap |arch=athlon64 |with --with-arch=athlon64 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30825
[Bug target/30921] [4.3 Regression] Bootstrap failure with -ftree-vectorize on i386
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-23 00:43 --- *** This bug has been marked as a duplicate of 30825 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30921
[Bug target/30825] [4.3 Regression] current mainline fails to bootstrap with --with-arch=athlon64
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-23 00:43 --- *** Bug 30921 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30825
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #1 from pcarlini at suse dot de 2007-02-23 01:59 --- Frankly, I have no idea what to do with this... Certainly lately we have got plenty of succesful builds on x86_64-linux and other linux platforms (just look to testresults). Something mysterious is going on during the build: bits/c++locale.h includes cstdio which then doesn't find the normal stdio.h facilities in the global namespace?!? Maybe submitter could attempt narrowing the problem somehow, for example by building snapshots older and newer... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-02-23 05:43 --- Subject: Bug 30910 Author: jvdelisle Date: Fri Feb 23 05:43:16 2007 New Revision: 122250 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122250 Log: 2007-02-22 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/30910 * io/write.c (output_float): Add condition of format F only for special case rounding with zero precision. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2007-02-23 05:50 --- Sorry about that - it wasn't on purpose: your comment and mine collided. I actually checked the two bugs after getting the message that I'd manage to wipe out your change, and the relationship between 26797 and 30911 that you'd set up still seemed to be there. I added it again. Note that you had received a warning before overwriting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug fortran/30910] [Regression 4.2, 4.3] Gfortran: ES format not quite right...
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-02-23 06:29 --- Subject: Bug 30910 Author: jvdelisle Date: Fri Feb 23 06:29:03 2007 New Revision: 122251 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122251 Log: 2007-02-22 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/30910 * gfortran.dg/fmt_zero_precision.f90: Update test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_zero_precision.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
