[Bug target/18444] New: Multithreading broken on Unix95-class platforms
The patch 2004-08-27 Jason Merrill [EMAIL PROTECTED] PR c++/13684 * gimplify.c (gimplify_cleanup_point_expr): Handle CLEANUP_EH_ONLY. (gimple_push_cleanup): Add eh_only parm. (gimplify_target_expr): Pass it. * c.opt (-fno-threadsafe-statics): New option. * c-opts.c (c_common_handle_option): Handle it. * c-common.h (flag_threadsafe_statics): Declare it. * c-common.c (flag_threadsafe_statics): Record it. * doc/invoke.texi: Document it. * tsystem.h (_GNU_SOURCE): Define. * gthr-posix.h (__gthread_recursive_mutex_t): New typedef. (__GTHREAD_RECURSIVE_MUTEX_INIT): New macro. (__GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION): New macro. (__gthread_recursive_mutex_init_function): New fn. (__gthread_recursive_mutex_lock): New fn. (__gthread_recursive_mutex_trylock): New fn. (__gthread_recursive_mutex_unlock): New fn. * gthr-solaris.h, gthr-single.h, gthr-dce.h: Likewise. * gthr-win32.h, gthr-vxworks.h: Likewise. * gthr.h: Document. makes it impossible to build the compiler without --enable-threads=single on Unix95-class (i.e. non Unix98-class platforms), because recursive mutexes support is now mandatory for POSIX threads. Among the affected platforms are sparc-sun-solaris2.5.1 and sparc-sun-solaris2.6. A recursive mutexes emulation was implemented in gthr-win32.h, so I think it should be doable to do the same in gthr-posix.h (and gthr-solaris.h). -- Summary: Multithreading broken on Unix95-class platforms Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18444
[Bug ada/18417] [4.0 Regression]Ada bootstrap failure on IRIX 6.5: tb-gcc.c missing
--- Additional Comments From hainque at act-europe dot fr 2004-11-12 08:36 --- Subject: Re: [4.0 Regression]Ada bootstrap failure on IRIX 6.5: tb-gcc.c missing pinskia at gcc dot gnu dot org wrote: Caused by: 2004-06-25 Olivier Hainque [EMAIL PROTECTED] * tracebak.c: Introduce support for a GCC infrastructure based implementation of __gnat_backtrace. I'm out of the office until monday and will only be able to properly address that by then. You may just not define USE_GCC_UNWINDER in the SGI section to workaround in the meantime. Olivier -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18417
[Bug c++/18445] New: ice during overload resolution in template instantiation
This (invalid) code gives a nice error message with gcc 3.3.3, but fails with an
ICE on 3.4.3. Using the correct ex.what() syntax fixes the problem.
#include iostream
#include exception
templateclass T
void f()
{
try {
} catch(std::exception ex) {
std::cout ex.what std::endl;
}
}
int main()
{
fint();
}
t.cc: In function `void f()':
t.cc:10: internal compiler error: in resolve_overloaded_unification, at
cp/pt.c:9331
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ice during overload resolution in template instantiation
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jens dot maurer at gmx dot net
CC: gcc-bugs at gcc dot gnu dot org,niemayer at isg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18445
[Bug other/18423] [4.0 Regression] powerpc-eabisim build broken due to configure skipping fixincludes
--- Additional Comments From bonzini at gcc dot gnu dot org 2004-11-12 08:45 --- The patch that caused it to fail is actually this one. 2004-11-04 Geoffrey Keating [EMAIL PROTECTED] * Makefile.in (distclean): Don't delete nonexistent fixinc/ directory. (install-mkheaders): Install the version built for the host, not for the build machine. Now I'm not going to rant much, because Geoff's patch was fixing a deficiency in my moving fixincludes to the toplevel; I'll work to fix this. But it's not the fault of my patch that Aaron applied; and I want to note that the change to the stmp-fixinc target's dependencies is *not* mentioned in the ChangeLog. -- What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2004-11-11 15:17:33 |2004-11-12 08:46:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18423
[Bug tree-optimization/16803] PowerPC - invariant code motion could be removed from loop.
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-12 09:24 --- We cannot generate better code, without having a different meaning for the sign_extend action that occurs in the loop. As zdenek points out, we cannot use dbra, because we cannot tell if the loop will actually terminate -- because of the = continuation condition. on ppc64 ints are 32 bits and pointers are 64 bits. the base address 'x' is a pointer to an array that we cannot tell the bounds of -- x might point into the middle of an array. Therefore both negative and positive ints of any value might be valid offsets. If the loop is unbounded, then there is the possibility of wrap-around during the increment of i. What happens in this case is undefined. We could therefore remove the sign-extension from int-long, and optimize further on the basis that undefined things never happen in a well-formed program. Unfortunately we cannot do this with the current RTL structure. The sign-extend operation is used in two different circumstances, (a) when it really is sign extending a shorter (valid) value to a longer representation, and (b) when we're truncating a possibly out-of-range value. (b) is undefined, yet we do not represent that undefinedness, and cannot distinguish it from (a), which is well defined. I will add a meta-bug noting this problem with extend operations. -- What|Removed |Added AssignedTo|nathan at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16803
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-12 09:32 --- It is not what I thought it was. The array case is optimized at the tree level, the pointer case is optimized at the rtl level. -- What|Removed |Added AssignedTo|nathan at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug rtl-optimization/18446] New: [meta-bug] We need to distinguish value extension and value truncation
We use zero_extend and sign_extend in two different circumstances. One is well defined and one is conditionally undefined. a) When extending a valid value in one representation to a valid value in a longer representation. For instance when converting a short to a long. This is well defined. b) When truncating a possibly value from a longer representation to a shorter one, where the value is possibly out of range of the shorter value. (1) If this is a straight type conversion, the operation is implementation defined (in C and C++). (2) If, however, it this is the result of performing an operation at a longer precision and then converting the result back to the orginal precision, it is undefined. For instance on 64bit hardware we might implement 32-bit integer addition at 64 bits, followed by a truncation back to 32 bits. Because we cannot later distinguish b2 from b1, we fail to optimize loops as best we could. In addition we have explicit extension operations that are nops in a well formed program. This is undoubtably a special case of annotating the regular mathematical operations as wrap,undefined,dont-care on overflow. I suspect this needs addressing at both the tree-level and the rtl-level -- Summary: [meta-bug] We need to distinguish value extension and value truncation Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: missed-optimization, meta-bug Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nathan at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18446
[Bug rtl-optimization/18446] [meta-bug] We need to distinguish value extension and value truncation
-- What|Removed |Added OtherBugsDependingO||16803 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18446
[Bug c++/18436] [3.4/4.0 Regression] ICE in perform_or_defer_access_check (binfo is NULL)
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-12
10:22 ---
Reduced testcase:
=
struct A
{
static void foo(A);
};
struct B
{
friend void foo(B);
};
templatetypename T struct C : T
{
C() { foo(T()); }
};
CA c;
=
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18436
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug target/18447] New: Variable with the initial-exec tls-model attribute causes spill failure
The following foo.c which is a reduced case of libc/grp/initgroup.c
causes an ICE:
foo.c:13: error: unable to find a register to spill in class 'R0_REGS'
foo.c:13: error: this is the insn:
(insn:HI 28 32 34 1 (set (reg:SI 147 t)
(eq:SI (reg/v:SI 2 r2 [orig:161 result ] [161])
(const_int -1 [0x]))) 1 {cmpeqsi_t}
(insn_list:REG_DEP_ANTI 23 (insn_list:REG_DEP_ANTI 24 (insn_list:REG_DEP_ANTI 25
(insn_list:REG_DEP_TRUE 26 (nil)
(nil))
with -O2.
foo.c:
--
extern __thread int err __attribute__ ((tls_model (initial-exec)));
int
foo (int n, int *grp)
{
int result;
do
result = bar (n, grp);
while (result == -1 err == 22 --n 0);
return result;
}
--
--
Summary: Variable with the initial-exec tls-model attribute
causes spill failure
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh4-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18447
[Bug c++/18436] [3.4/4.0 Regression] ICE in perform_or_defer_access_check (binfo is NULL)
--- Additional Comments From jakub at gcc dot gnu dot org 2004-11-12 10:35
---
I see segfault in perform_or_defer_access_check too, on:
template class T1, class T2
struct P
{
T1 t1;
T2 t2;
P () : t1(), t2() { }
template class U1, class U2
P (const PU1, U2 x) : t1(x.t1), t2(x.t2) { }
};
template typename T
inline void
f (T x, T y)
{
const T t = x; x = y; y = t;
}
template class T
struct A
{
static void f (T x, T y) { T t = x; x = y; y = t; }
};
template class T
struct B : public AT
{
static void g (T *x, T *y) { f (*y, *x); }
};
int
foo ()
{
Plong, long *a, *b;
BPlong, long ::g (a, b);
}
Works with GCC 3.3, segfaults with 3.4.3 and 4.0 current.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18436
[Bug target/18447] Variable with the initial-exec tls-model attribute causes spill failure
-- What|Removed |Added Known to fail||4.0.0 Known to work||3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18447
[Bug fortran/18108] [gfortran] overloading does not work for functions
--- Additional Comments From martin at mpa-garching dot mpg dot de 2004-11-12 10:40 --- Could one of the bug masters please confirm this bug, to put it on the radar of the Fortran developers? Thanks, Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18108
[Bug c++/18448] New: g++ attempts to use copy constructor instead of operator = on instantiated object
gcc-3.4.2/4.0.0
Linux 2.6.9 #17 Fri Nov 12 15:59:30 NOVT 2004 i686 athlon i386 GNU/Linux
Fedora Core 3
gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix --disa
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
g++ test.cpp
[EMAIL PROTECTED] temp]$ g++ test.cpp
test.cpp: In function `int main()':
test.cpp:10: error: `A::A(const A)' is private
test.cpp:16: error: within this context
test.cpp:
class A {
public:
A() {}
const A operator=(const A a) {
return *this;
}
private:
A(const A a) {}
};
A a;
int main() {
A *pa = a;
*pa = A();
}
--
Summary: g++ attempts to use copy constructor instead of operator
= on instantiated object
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: megath at iof dot ru
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18448
[Bug c++/18448] g++ attempts to use copy constructor instead of operator = on instantiated object
--- Additional Comments From megath at iof dot ru 2004-11-12 10:43 --- Created an attachment (id=7527) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7527action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18448
[Bug c++/18449] New: Problems when using function overloadtemplates across namespaces.
Hi there, My apologies for not filling target triplet build-triplet, I uses the stock Fedora core 2 gcc-c++ package (3.3.3-7) with all packages updates. Here is a self-contained source file (needs nothing but STL) which show the problem. I have three namespaces (NS1, NS2 NS3) and a GetString() function which have overload for POD and non-POD types in NS1 NS2. If there are overload of GetString() for POD types in NS3, the overload of POD types from other namesspaces seems to be not taken in account. Anyway, thanks for developping that great compiler. Source Source Source Source # include string # include iostream # include iomanip # include sstream using namespace std; // Characterics common to all tests : // // In namespace NS1 : // - GetString for class type Int. // - GetString for POD type Char. // // In namespace NS2 : // - GetString for class type Long. // - NO GetString for any POD type. # define CHECK_1 0 // CHECK_1 : // // In namespace NS1 : // - GetString template for Data*. // // In namespace NS3 : // - No GetString of any kind. // // Result : // - Works OK for types from NS1 NS2. // - Pointer template OK for types from NS1 NS2. # if CHECK_1 # define NS3_OVERLOAD_CLASS 0 # define NS3_PODIMPORT 0 # define NS1_TEMPLATE 1 # endif # if CHECK_2 # define NS3_OVERLOAD_CLASS 1 # define NS3_PODIMPORT 0 # define NS1_TEMPLATE 0 # endif # define CHECK_3 0 // CHECK_3 : // // In namespace NS3 : // - GetString overload for class type Char. // - GetString manual importation of NS1::GetString(float). // // Result : // - Works OK for class types from NS1, NS2 NS3. // - Uses manual importation for POD type float. // - # if CHECK_3 # define NS3_OVERLOAD_CLASS 1 # define NS3_PODIMPORT 1 # define NS1_TEMPLATE 0 # endif # define CHECK_4 0 // CHECK_4 : // // In namespace NS1 : // - GetString template for Data*. // // In namespace NS3 : // - GetString overload for class type Char. // - GetString manual importation of NS1::GetString(float). // // Result : // - Works OK for class types from NS1, NS2 NS3. // - Uses manual importation for POD type float. // - Template seems to be ignored for types coming from // namespaces other than NS1. # if CHECK_4 # define NS3_OVERLOAD_CLASS 1 # define NS3_PODIMPORT 1 # define NS1_TEMPLATE 1 # endif # define CHECK_5 1 // CHECK_5 : // // In namespace NS3 : // - NO overload for of kind. // - GetString manual importation of NS1::GetString(float). // // Result : //- Works OK : overload is correctly handled for POD type float. //(uses first the manual importation in NS3). // - As in CHECK_4, Template seems to be ignored for types
[Bug inline-asm/18450] New: Wrong code generated by gcc from inline assembler
I wrote an x86 specific program that uses inline assembler to set and unset the alignment check bit in the EFLAGS register. In between setting and unsetting the bit, I use more inline assembler to save the state of the EFLAGS register. The problem is that I get different results depending on whether optimization is turned on or not. Further inspection reveals that when optimization is turned on, gcc decides to optimize out the chunk of inline assembler I use to verify the AC bit was turned off. When optimization is disabled, the chunk of inline assembler re-appears. The Intel C compiler v8.1 on the same machine does not exhibit this problem. -- Summary: Wrong code generated by gcc from inline assembler Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thalakan at technologist dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-portbld-freebsd5.1 GCC host triplet: i386-portbld-freebsd5.1 GCC target triplet: i386-portbld-freebsd5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18450
[Bug c++/18449] Problems when using function overloadtemplates across namespaces.
--- Additional Comments From Jean-Paul dot Chaput at lip6 dot fr 2004-11-12 11:03 --- Created an attachment (id=7528) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7528action=view) Test function overload across namespaces Sorry to have also included the test file into the bug description. But this is my first time with bugzilla... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18449
[Bug inline-asm/18450] Wrong code generated by gcc from inline assembler
--- Additional Comments From thalakan at technologist dot com 2004-11-12 11:08 --- Created an attachment (id=7529) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7529action=view) Preprocessed source of program This is the preprocessed source of the program. Compile and run it with and without optimization. When optimization is turned on, the program will output a nonzero value in the second line; this is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18450
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-11-12 11:24 --- The problem seems to be that licm does not move load of q from the loop. Ivopts then do not recognize q + 2*i as induction variable, and thus they are optimizing it not like an address of memory reference, but just like a computation of 2*i, for which it obviously does not make sense to perform strength reduction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug c++/18436] [3.4/4.0 Regression] ICE in perform_or_defer_access_check (binfo is NULL)
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-12
11:58 ---
The examples from comment #3 and comment #4 can both be reduced to
=
void foo(int);
struct A
{
static void foo(A);
};
templatetypename T struct B : T
{
B() { foo(T()); }
};
BA b;
=
I'm not sure whether this is valid or not - icc for example rejects the
code in strict mode.
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Severity|normal |critical
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC host triplet|i686-pc-linux-gnu |
Keywords||monitored
Last reconfirmed|-00-00 00:00:00 |2004-11-12 11:58:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18436
[Bug c++/18436] [3.4/4.0 Regression] ICE in perform_or_defer_access_check (binfo is NULL)
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-12 12:26 --- Mark, the ICE on mainline appears with your patch http://gcc.gnu.org/ml/gcc-cvs/2004-09/msg01274.html -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18436
[Bug c++/18448] g++ attempts to use copy constructor instead of operator = on instantiated object
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 12:39 --- Invalid, did you read the release notes? -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18448
[Bug c++/18436] [3.4/4.0 Regression] ICE in perform_or_defer_access_check (binfo is NULL)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 12:42 --- : Search converges between 2004-09-27-014001-trunk (#563) and 2004-09-27-161002-trunk (#564). : Search converges between 2004-09-27-004002-3.4 (#82) and 2004-09-28-004001-3.4 (#83). -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18436
[Bug inline-asm/18450] Wrong code generated by gcc from inline assembler
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 12:46 --- Since the asm is not violate or have outputs which are used they are removed, this is not a bug: asm( pushf\n orl %0, (%%esp)\n popf\n : : i (0x0004)); -- What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC host triplet|i386-portbld-freebsd5.1 |i386-portbld-freebsd5.1 Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18450
[Bug c++/18445] [3.4/4.0 Regression] ice during overload resolution in template instantiation
-- What|Removed |Added Keywords||ice-on-invalid-code Summary|ice during overload |[3.4/4.0 Regression] ice |resolution in template |during overload resolution |instantiation |in template instantiation Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18445
[Bug rtl-optimization/8361] [3.3/3.4/4.0 regression] C++ compile-time performance regression
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-12 12:52 --- GCC 3.4 (CVS today) takes 35s usr on my machine. GCC 4.0 (CVS today) takes 46s usr on the same machine. The difference is entirely in DOM, into-SSA and SSA-other which is really also into-SSA: usr sys wall dominator optimization 3.160.023.26 tree SSA rewrite3.240.013.27 tree SSA other 3.470.093.40 Per-pass and cummulative time spent (top 10 only): integration 1.092.30% 48.88% tree PHI insertion 1.212.56% 51.44% loop invariant motion 1.302.75% 54.18% global alloc1.302.75% 56.93% CSE 1.723.63% 60.56% parser 3.056.44% 67.00% dominator optimization 3.166.68% 73.68% tree SSA rewrite3.246.84% 80.52% tree SSA other 3.477.33% 87.85% expand 5.7512.15% 100.00% Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 1.82 8.19 8.19 13878865 0.00 0.00 is_gimple_reg 1.50 14.95 6.76 6594 0.00 0.00 synth_mult 1.28 20.69 5.74 12785589 0.00 0.00 ggc_alloc_stat 1.27 26.38 5.69 3433257 0.00 0.00 free_df_for_stmt 1.25 32.01 5.63 16868123 0.00 0.00 bitmap_set_bit 1.19 37.35 5.34 4846931 0.00 0.00 get_stmt_operands 1.17 42.59 5.2462034 0.00 0.00 alloc_page 1.15 47.75 5.16 3559 0.00 0.01 compute_immediate_uses 0.99 52.18 4.43 6408238 0.00 0.00 htab_find_slot_with_hash 0.98 56.60 4.42 2104725 0.00 0.00 compute_immediate_uses_for_phi 0.93 60.76 4.16 821051 0.00 0.00 gt_ggc_mx_lang_tree_node 0.91 64.83 4.07 7802758 0.00 0.00 register_new_def 0.90 68.87 4.04 951728 0.00 0.00 rewrite_stmt 0.88 72.82 3.95 30035694 0.00 0.00 bitmap_bit_p 0.84 76.61 3.79 574332 0.00 0.00 cse_insn 0.81 80.26 3.65 196671 0.00 0.00 compute_global_livein 0.81 83.91 3.65 177070 0.00 0.00 insert_phi_nodes_for 0.81 87.54 3.63 2697441 0.00 0.00 for_each_rtx 0.81 91.16 3.62 1079773 0.00 0.00 check_phi_redundancy which is a different way of saying all over the map :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
[Bug c++/18448] g++ attempts to use copy constructor instead of operator = on instantiated object
--- Additional Comments From megath at iof dot ru 2004-11-12 13:10 --- about iCopy constructor access check while initializing a reference./i ? yes. sorry. *p = A() constructs copy of object now? what for ? doesnt it degrades perfomance? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18448
[Bug c++/18448] g++ attempts to use copy constructor instead of operator = on instantiated object
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 13:41 --- (In reply to comment #3) about iCopy constructor access check while initializing a reference./i ? yes. sorry. *p = A() constructs copy of object now? what for ? No we don't contruct a copy of the object, did you really read it. I just says it has to be accessable, it will not be used. doesnt it degrades perfomance? Only slightly compile time and that is it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18448
[Bug c++/18448] g++ attempts to use copy constructor instead of operator = on instantiated object
--- Additional Comments From megath at iof dot ru 2004-11-12 13:48 --- I just says it has to be accessable so, if gcc dont use copy ctor - what for it complains ?! and why is it error btw ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18448
[Bug c++/18445] [3.4/4.0 Regression] ice during overload resolution in template instantiation
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12
13:51 ---
Confirmed, reduced to:
struct a
{
int what();
};
void g(void*);
templateclass T
void f()
{
a ex;
g(ex.what);
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-11-12 13:51:46
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18445
[Bug c++/18448] g++ attempts to use copy constructor instead of operator = on instantiated object
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 13:54 --- (In reply to comment #5) I just says it has to be accessable so, if gcc dont use copy ctor - what for it complains ?! Because this is the requirement of the C++ standard. and why is it error btw ? because we could use the ctor if we wantted to in this case but we don't so the requirement of the C++ standard says it has to be accessable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18448
[Bug c++/18445] [3.4/4.0 Regression] ice during overload resolution in template instantiation
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 13:54 --- : Search converges between 2003-07-08-trunk (#288) and 2003-07-09-trunk (#289). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18445
[Bug target/18444] [4.0 Regression] Multithreading broken on Unix95-class platforms
-- What|Removed |Added Summary|Multithreading broken on|[4.0 Regression] |Unix95-class platforms |Multithreading broken on ||Unix95-class platforms Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18444
[Bug target/18447] [4.0 Regression] Variable with the initial-exec tls-model attribute causes spill failure
-- What|Removed |Added Summary|Variable with the initial- |[4.0 Regression] Variable |exec tls-model attribute|with the initial-exec tls- |causes spill failure|model attribute causes spill ||failure Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18447
[Bug c++/18448] g++ attempts to use copy constructor instead of operator = on instantiated object
--- Additional Comments From megath at iof dot ru 2004-11-12 13:57 --- thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18448
[Bug c++/18451] New: [3.4 Regression] C++ error message regression
The following erroneous code gives an error message I do not understand
file.cc:
1 template class T
2 class A
3 {
4 public:
5 class B
6 {
7 public:
8 B( int inVal ) : m_i( inVal ) { }
9 int m_i;
10 };
11 static B s;
12 };
13
14 template class T AT::B AT::s( 10 );
gives the following error message witch g++-3.4.3 -Wall -c file.cc
14: error: expected constructor, destructor, or type conversion before A
14: error: expected `;' before A
I have difficulties in understancing the message
with g++-3.3.2 -Wall -c file.cc
14: warning: `AT::B' is implicitly a typename
14: warning: implicit typename is deprecated, please see the documentation for
details
This message seems much clearer to me
--
Summary: [3.4 Regression] C++ error message regression
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sschunck at pdf dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18451
[Bug other/14264] [4.0 Regression] testsuite should set LC_ALL/LANG to C
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 14:07 --- Full patch here which does it in the .exp files instead of the makefiles so you can use runtest also: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00953.html Mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14264
[Bug c++/18451] C++ error message regression
-- What|Removed |Added Keywords||diagnostic Summary|[3.4 Regression] C++ error |C++ error message regression |message regression | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18451
[Bug c++/18451] C++ error message regression
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 14:11 --- *** This bug has been marked as a duplicate of 15946 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18451
[Bug c++/15946] Unhelpful error message when typename is omitted
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 14:11 --- *** Bug 18451 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||sschunck at pdf dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15946
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 14:38 --- Patch here which should fix not pulling the load of q out of the loop: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00957.html Then the only thing left is for IV-OPTS to be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2004-11-12 14:42 --- Subject: Re: Code for arrays and pointers are not the same Patch here which should fix not pulling the load of q out of the loop: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00957.html Then the only thing left is for IV-OPTS to be fixed. no -- once this is done, ivopts work just fine, producing the same code as for array access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12
14:44 ---
huh a compiler built with that patch gives:
L4:
slwi r2,r9,1
addi r9,r9,1
sthx r0,r2,r11
bdnz L4
Also pulling the load manually out loop also produce the same asm as I just
produced:
unsigned short *q;
#define NOSB 10
int last;
void h1()
{
int i;
unsigned short *q1 = q;
for (i=0;ilast+NOSB;i++)
{
q1[i] = 0;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2004-11-12 14:46 --- Subject: Re: Code for arrays and pointers are not the same Patch here which should fix not pulling the load of q out of the loop: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00957.html Then the only thing left is for IV-OPTS to be fixed. no -- once this is done, ivopts work just fine, producing the same code as for array access. btw. the patch above might be wrong -- I think ssa names also pass the is_gimple_addressable test: is_gimple_addressable - is_gimple_id - is_gimple_variable - SSA_NAME. So the correct patch would be Index: tree-ssa-loop-im.c === RCS file: /cvs/gcc/gcc/gcc/tree-ssa-loop-im.c,v retrieving revision 2.21 diff -c -3 -p -r2.21 tree-ssa-loop-im.c *** tree-ssa-loop-im.c 8 Nov 2004 13:54:39 - 2.21 --- tree-ssa-loop-im.c 12 Nov 2004 11:29:40 - *** stmt_cost (tree stmt) *** 367,373 /* Hoisting memory references out should almost surely be a win. */ if (!is_gimple_variable (lhs)) cost += 20; ! if (is_gimple_addressable (rhs) !is_gimple_variable (rhs)) cost += 20; switch (TREE_CODE (rhs)) --- 367,373 /* Hoisting memory references out should almost surely be a win. */ if (!is_gimple_variable (lhs)) cost += 20; ! if (is_gimple_addressable (rhs) TREE_CODE (rhs) != SSA_NAME) cost += 20; switch (TREE_CODE (rhs)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2004-11-12 14:48 ---
Subject: Re: Code for arrays and pointers are not the same
huh a compiler built with that patch gives:
L4:
slwi r2,r9,1
addi r9,r9,1
sthx r0,r2,r11
bdnz L4
Also pulling the load manually out loop also produce the same asm as I just
produced:
unsigned short *q;
#define NOSB 10
int last;
void h1()
{
int i;
unsigned short *q1 = q;
for (i=0;ilast+NOSB;i++)
{
q1[i] = 0;
}
}
not for me:
.L4:
sth 0,0(9)
addi 9,9,2
bdnz .L4
what architecture/flags are you using?
Zdenek
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug rtl-optimization/17107] Opportunity to improve code generated for complex logical expression
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17107
[Bug c++/17344] completely wacky error with matching template template classes and default arguments
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-12 14:51 --- Got it. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lerdsuwa at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17344
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 14:52 --- powerpc-darwin just -O3 hmm, must be a local modification which changes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 14:53 --- (In reply to comment #8) is_gimple_addressable - is_gimple_id - is_gimple_variable - SSA_NAME. So the correct patch would be I did post that patch also before it was rejected as I did not look into the aliasing problem we had. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2004-11-12 15:10 --- Subject: Re: Code for arrays and pointers are not the same powerpc-darwin just -O3 hmm, must be a local modification which changes it. maybe you are checking 64 bit? That still looks terrible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug fortran/18452] New: -fno-second-underscore induces warning
Using -fno-second-underscore with gfortran gives a spurious warning: $ gfortran -fno-second-underscore -c common.F90 cc1: warning: command line option -fno-second-underscore is valid for F95 but not for C -- Summary: -fno-second-underscore induces warning Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: coudert at clipper dot ens dot fr CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 15:22 --- Confirmed, the issue is that we are passing the options to the cc1, the preprocessor (and the C compiler). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2004-11-12 15:22:49 date|| Summary|-fno-second-underscore |-fno-second-underscore |induces warning |induces warning for fortran ||that needs preprocessing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug tree-optimization/18431] Code for arrays and pointers are not the same
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 15:33 --- The local patch which I had in which caused this was a not so correct for PR 18293 (which we remove an extra copy RTL as we expand it so it looks like the cost analysis is doing something wrong which is why we don't do the IV-OPT when at the RTL either). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18431
[Bug middle-end/18293] Redundant copy operation introduced by expand
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 15:35 --- Note if we change this we have to look at the IV-OPT cost analysis mechanism and retune it to be more correct as we will miss some optimizations. -- What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18293
[Bug ada/18453] New: Legal instantiation rejected; illegal instantiation accepted
(Debian bug #279893) -- legal instantiation rejected; illegal instantiation accepted -- adapted from John Woodruff c.l.a. post generic type T1 is private; package pak1 is subtype T3 is T1; end pak1; with pak1; generic type T2 is private; package pak2 is package the_pak1 is new pak1 (T1 = T2); end pak2; generic type T2 is access the_pak1.T3; package pak2.pak3 is end pak2.pak3; with pak1; with pak2.pak3; package Test_129 is type T4 is null record; type T5 is null record; subtype T3 is T5; -- line 9: triggers the bug at line 16 type T4_ptr is access T4; type T5_ptr is access T5; package new_pak2 is new pak2 (T2 = T4); package new_pak3a is new new_pak2.pak3(T2 = T4_ptr); -- line 15: Legal package new_pak3b is new new_pak2.pak3(T2 = T5_ptr); -- line 16: Illegal end Test_129; The instantiation at line 15 is legal because T4_ptr is an access to T4, and the previous instantiations make it so that T4 = new_pak2.T2 = new_pak2.the_pak1.T1 = pak2.the_pak1.T3. In contrast, line 16 is illegal because T5 /= new_pak2.T2. Thus, the expected output from gnat is: test_129.ads:16:49: designated type of actual does not match that of formal T2 test_129.ads:16:49: instantiation abandoned gnatmake: test_129.ads compilation error The actual output from gnat is: test_129.ads:15:49: designated type of actual does not match that of formal T2 test_129.ads:15:49: instantiation abandoned gnatmake: test_129.ads compilation error The subtype at line 9 happens to be a homograph of pak1.T3. Removing this line, or renaming Test_129.T3, causes the actual output to become: test_129.ads:15:49: designated type of actual does not match that of formal T2 test_129.ads:15:49: instantiation abandoned test_129.ads:16:49: designated type of actual does not match that of formal T2 test_129.ads:16:49: instantiation abandoned gnatmake: test_129.ads compilation error -- Summary: Legal instantiation rejected; illegal instantiation accepted Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic dot brenta at insalien dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18453
[Bug target/18300] Infinite loop when passing object with 3+ base classes by value
--- Additional Comments From zak at transversal dot com 2004-11-12 16:33 --- Amended patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00948.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300
[Bug ada/18454] New: Illegal program not detected, RM 10.1.5(4), 8.1(16)
(Debian bug #280939) -- RM 10.1.5(4) the pragma shall have an argument that is a name -- denoting that declaration. -- RM 8.1(16) The children of a parent library unit are inside the -- parent's declarative region. package pak1 is pragma Pure; end pak1; procedure pak1.p2; pragma Pure (p2); -- ERROR: need expanded name pragma Import (ada, p2); -- ERROR: need expanded name pragma Inline (p2);-- ERROR: need expanded name with Pak1.P2; procedure Test_130 is begin Pak1.P2; end Test_130; Expected output all three errors diagnosed: pak1-p2.ads:3:13: p2 is not directly visible pak1-p2.ads:4:20: p2 is not directly visible pak1-p2.ads:5:15: p2 is not directly visible Actual output: the compiler says nothing, the linker, as expected, can't find pak1.p2: ./test_130.o(.text+0x4): In function `_ada_test_130': : undefined reference to `p2' gnatlink: cannot call /usr/bin/gnatgcc gnatmake: *** link failed. -- Summary: Illegal program not detected, RM 10.1.5(4), 8.1(16) Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic dot brenta at insalien dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18454
[Bug c++/18416] [4.0 regression] ICE in import_export_decl
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-12 16:38 --- Subject: Bug 18416 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-12 16:37:52 Modified files: gcc: ChangeLog passes.c toplev.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/init: global1.C Log message: PR c++/18416 * passes.c (rest_of_decl_compilation): Do not look at DECL_RTL when deciding whether to pass a variable to cgraph_varpool_finalize_decl or assemble_variable. * toplev.c (check_global_declarations): Do not clear DECL_RTL. PR c++/18416 * g++.dg/init/global1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6299r2=2.6300 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/passes.c.diff?cvsroot=gccr1=2.54r2=2.55 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?cvsroot=gccr1=1.931r2=1.932 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4585r2=1.4586 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/global1.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18416
[Bug ada/18455] New: Legal rejected in gnat 3.15p, RM 3.10(15); incorrect execution in gcc 3.4.2
(Debian bug #280940) -- RM 3.10(15) An access value satisfies a composite_constraint -- of an access subtype if it ... designates an object whose value -- satisfies the constraint. with text_io; procedure Test_131 is type string_ptr is access all string; subtype str10 is string_Ptr(1..10); xstr20: aliased string := (1..20 = 'a'); xstr10: str10; begin xstr10 := xstr20'Access; -- line 12 text_io.put_line(FAILED, constraint_error not raised); exception when constraint_error = text_io.put_line(PASSED, constraint_error raised); end Test_131; Expected output: the compiler says nothing, the program prints: PASSED, constraint_error raised Actual output with gnat 3.15p: test_131.adb:12:14: object subtype must statically match designated subtype gnatmake: test_131.adb compilation error which is incorrect. With gnat-3.4 3.4.2-2, the compiler says nothing (correct) but the program runs and outputs: FAILED, constraint_error not raised -- Summary: Legal rejected in gnat 3.15p, RM 3.10(15); incorrect execution in gcc 3.4.2 Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic dot brenta at insalien dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18455
[Bug c++/18416] [4.0 regression] ICE in import_export_decl
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-12 16:45 --- Fixed in GCC 4.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18416
[Bug target/7013] [IA64] redeclaring volatile objects forces them always into long data
--- Additional Comments From sje at cup dot hp dot com 2004-11-12 16:54 --- I tried to reproduce this using a native IA64 GCC on Linux and HP-UX and 3.2.3 and 3.3 looked fine to me. I am not sure how to reconcile this with Dara's results but I think the bug is fixed in 3.2.3 and subsequent releases and that this defect should be closed out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7013
[Bug c++/18276] [4.0 Regression] template classes that are friends of template classes
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-12 16:57 --- Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00971.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18276
[Bug c++/15664] Template friend injection fails
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-12 16:58 --- Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00971.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15664
[Bug objc/18456] New: ICE compiling Objective C code with protocol-qualified objects
The attached program ICEs the Objective C compiler. Two situations in which it won't are if it is compiled with -DNOCRASH1 or -DNOCRASH2. $ gcc -v Reading specs from /packages/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: /src/gcc/configure --prefix=/packages/gcc --srcdir=/src/gcc Thread model: posix gcc version 4.0.0 20041112 (experimental) -- Summary: ICE compiling Objective C code with protocol-qualified objects Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: objc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mgd at santafe dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.5.0, i686-pc-linux-gnu GCC host triplet: powerpc-apple-darwin7.5.0, i686-pc-linux-gnu GCC target triplet: powerpc-apple-darwin7.5.0, i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18456
[Bug objc/18456] ICE compiling Objective C code with protocol-qualified objects
--- Additional Comments From mgd at santafe dot edu 2004-11-12 17:02 --- Created an attachment (id=7530) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7530action=view) Objective C file that crashes compiler Compiling with no -D preprocessor defines will ICE gcc 4.0.0 20041112 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18456
[Bug c++/15410] Wrong template signature accepted in friend declaration
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-12 17:03 --- One more patch is required. And libjava problem has to be fixed before this bug is revisited. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15410
[Bug c++/14513] Friend name injection problem (implicit declaration)
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-12 17:03 --- One more patch is required. And libjava problem has to be fixed before this bug is revisited. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14513
[Bug objc/18456] ICE compiling Objective C code with protocol-qualified objects
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 17:12 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|powerpc-apple-darwin7.5.0, | |i686-pc-linux-gnu | GCC host triplet|powerpc-apple-darwin7.5.0, | |i686-pc-linux-gnu | GCC target triplet|powerpc-apple-darwin7.5.0, | |i686-pc-linux-gnu | Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2004-11-12 17:12:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18456
[Bug ada/18455] incorrect execution
-- What|Removed |Added Keywords||wrong-code Summary|Legal rejected in gnat |incorrect execution |3.15p, RM 3.10(15); | |incorrect execution in gcc | |3.4.2 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18455
[Bug c++/18436] [3.4/4.0 Regression] ICE in perform_or_defer_access_check (binfo is NULL)
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18436
[Bug c++/18384] [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer...
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
[Bug c++/18457] New: Ordering of member variables breaks code
Sorry, I do not know what host triplet, target triplet, or build triplet mean. None of them are discussed in http://gcc.gnu.org/bugs.html. Here is the output of gcc -v: [EMAIL PROTECTED]:~/sandbox/newchords$ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-2) The gcc commands I am using are: [EMAIL PROTECTED]:~/sandbox/newchords$ g++ -g ChordData.cpp Progression.cpp ChordSearchTree.cpp CAHServer.cpp -o CAHServer and [EMAIL PROTECTED]:~/sandbox/newchords$ g++ -g ChordData.cpp Progression.cpp ChordSearchTree.cpp CAHClient.cpp -o CAHClient The bug involves two members of class CCHChordSearchTree, which you can find in ChordSearchTree.ii. The two members are CCHProgression m_nBest[ 10 ]; and listCCHProgression * m_lQueue; If the members are listed in that order, everything works perfectly. If their order is reversed, compilation and linking succeeds, but there is an error at runtime. Specifically, the call to recvfrom() in CCHChordSearchTree::ClientLoop() fails with an error Invalid argument. At the time of the call, I know that each of the arguments is in fact valid. Perhaps this should be a bug report to the writers of the Standard Template Library or the socket interface, but because it is affected by the order of member variables it seems to be a compiler problem. By the way, everything works on another system I have tried, where gcc -v provides this: io:~/sandbox/newchords2% gcc -v Reading specs from /opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs gcc version 2.95.3 20010315 (release) -- Summary: Ordering of member variables breaks code Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cmh204 at lehigh dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18457
[Bug c++/18457] Ordering of member variables breaks code
--- Additional Comments From cmh204 at lehigh dot edu 2004-11-12 18:30 --- Created an attachment (id=7531) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7531action=view) broken example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18457
[Bug c++/18457] Ordering of member variables breaks code
--- Additional Comments From cmh204 at lehigh dot edu 2004-11-12 18:31 --- Created an attachment (id=7532) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7532action=view) broken example (file2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18457
[Bug c++/18389] [3.4/4.0 regression] ICE on struct declaration in for statement
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18389
[Bug c++/18457] Ordering of member variables breaks code
--- Additional Comments From cmh204 at lehigh dot edu 2004-11-12 18:32 --- Created an attachment (id=7533) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7533action=view) broken example (file3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18457
[Bug c++/18457] Ordering of member variables breaks code
--- Additional Comments From cmh204 at lehigh dot edu 2004-11-12 18:32 --- Created an attachment (id=7534) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7534action=view) broken example (file4) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18457
[Bug c++/18457] Ordering of member variables breaks code
--- Additional Comments From cmh204 at lehigh dot edu 2004-11-12 18:34 --- Created an attachment (id=7535) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7535action=view) broken example (file5) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18457
[Bug other/18423] [4.0 Regression] powerpc-eabisim build broken due to configure skipping fixincludes
--- Additional Comments From geoffk at gcc dot gnu dot org 2004-11-12 19:04 --- I have a patch to fix this. -- What|Removed |Added AssignedTo|bonzini at gcc dot gnu dot |geoffk at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18423
[Bug target/14815] -frename-registers produces incorrect code on ia64
--- Additional Comments From sje at cup dot hp dot com 2004-11-12 19:07 --- I have run this testcase with the 3.3.* and 3.4.* and ToT (pre-4.0) compilers on IA64 linux. The bug exists in all 3.3.* compilers (3.3.[012345]) and none of the 3.4 compilers (3.4.[0123]). Nor does it happen on ToT. Are we still doing 3.3 patches? If I knew what change between 3.3 and 3.4 fixed this I could look into backporting it but I don't know what change fixed it and I don't know if it is worth trying to find out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14815
[Bug other/18423] [4.0 Regression] powerpc-eabisim build broken due to configure skipping fixincludes
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-12 19:15 --- Subject: Bug 18423 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-12 19:15:25 Modified files: . : ChangeLog configure.in configure Log message: PR 18423 * configure.in: Remove all instances of build-fixincludes from noconfigdirs. (build_configargs): Supply --target to subdirectories. * configure: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gccr1=1.1017r2=1.1018 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.in.diff?cvsroot=gccr1=1.331r2=1.332 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.diff?cvsroot=gccr1=1.194r2=1.195 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18423
[Bug c++/18407] [3.4/4.0 Regression] ICE with mem-fun-ptr as template parameter for nested function template (build_base_path, cp/class.c)
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18407
[Bug target/16343] invalid code when using -meabi -msdata=eabi
--- Additional Comments From a_fisch at gmx dot de 2004-11-12 19:20 ---
The Bug is in gcc/config/rs6000/rs6000.c in function
rs6000_elf_in_small_data_p()
With gcc version 3.4.x? (2003-05-02) the macro SYMBOL_REF_SMALL_P () was
introduced, which checks for a flag, which is not properly set, if the
referenced symbol is a function.
The flag is used in small_data_operand () but has to be set in
rs6000_elf_in_small_data_p ().
I compared the implementation of ??_in_small_data_p() for different cpu's
(alpha, mips) and changed rs6000_elf_in_small_data_p () as follows:
static bool
rs6000_elf_in_small_data_p (tree decl)
{
if (rs6000_sdata == SDATA_NONE)
return false;
/* - Begin of code to insert -- */
/* We want to merge strings, so we never consider them small data. */
if (TREE_CODE (decl) == STRING_CST)
return false;
/* Functions are never in the small data area. */
if (TREE_CODE (decl) == FUNCTION_DECL)
return false;
/* - End of code to insert -- */
if (TREE_CODE (decl) == VAR_DECL DECL_SECTION_NAME (decl))
{
const char *section = TREE_STRING_POINTER (DECL_SECTION_NAME (decl));
if (strcmp (section, .sdata) == 0
|| strcmp (section, .sdata2) == 0
|| strcmp (section, .sbss) == 0
|| strcmp (section, .sbss2) == 0
|| strcmp (section, .PPC.EMB.sdata0) == 0
|| strcmp (section, .PPC.EMB.sbss0) == 0)
return true;
}
else
{
HOST_WIDE_INT size = int_size_in_bytes (TREE_TYPE (decl));
if (size 0
(unsigned HOST_WIDE_INT) size = g_switch_value
/* If it's not public, and we're not going to reference it there,
there's no need to put it in the small data section. */
(rs6000_sdata != SDATA_DATA || TREE_PUBLIC (decl)))
return true;
}
return false;
}
I tested the changed code and the result is promising. As far as I know this
error must have effected all powerpc-targets which use ELF and have small data
areas (powerpc-elf, powerpc-eabi, ...)
Because I'm not familiar with the process of generating patches and sending
the result back to the mainline, I would like to ask one of you, watching this
error to integerate it.
--
What|Removed |Added
CC||a_fisch at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16343
[Bug c++/18429] [4.0 Regression] ICE on invalid code with array size being a non constant variable
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18429
[Bug target/14815] -frename-registers produces incorrect code on ia64
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 19:29 --- Fixed in 3.4.0, 3.3.x is just on regression fixing mode and since this is most likely not a regression I am closing as fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14815
[Bug other/14264] [4.0 Regression] testsuite should set LC_ALL/LANG to C
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 19:44 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14264
[Bug other/14264] [4.0 Regression] testsuite should set LC_ALL/LANG to C
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-12 19:44 --- Subject: Bug 14264 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-12 19:43:58 Modified files: libstdc++-v3/testsuite/lib: libstdc++.exp libjava/testsuite/lib: libjava.exp gcc/testsuite : ChangeLog libstdc++-v3 : ChangeLog libjava: ChangeLog gcc/testsuite/lib: g++.exp gcc-dg.exp gfortran.exp objc.exp treelang.exp Log message: 2004-11-12 Andrew Pinski [EMAIL PROTECTED] PR other/14264 * lib/g++.exp: Set LC_ALL and LANG to C. * lib/gcc-dg.exp: Likewise. * lib/gfortran.exp: Likewise. * lib/objc.exp: Likewise. * lib/treelang.exp: Likewise. 2004-11-12 Andrew Pinski [EMAIL PROTECTED] PR other/14264 * testsuite/lib/libstdc++.exp: Set LC_ALL and LANG to C. 2004-11-12 Andrew Pinski [EMAIL PROTECTED] PR other/14264 * testsuite/lib/libjava.exp: Set LC_ALL and LANG to C. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/lib/libstdc++.exp.diff?cvsroot=gccr1=1.27r2=1.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/lib/libjava.exp.diff?cvsroot=gccr1=1.61r2=1.62 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4587r2=1.4588 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gccr1=1.2758r2=1.2759 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3200r2=1.3201 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/lib/g++.exp.diff?cvsroot=gccr1=1.42r2=1.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/lib/gcc-dg.exp.diff?cvsroot=gccr1=1.40r2=1.41 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/lib/gfortran.exp.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/lib/objc.exp.diff?cvsroot=gccr1=1.27r2=1.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/lib/treelang.exp.diff?cvsroot=gccr1=1.5r2=1.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14264
[Bug other/18423] [4.0 Regression] powerpc-eabisim build broken due to configure skipping fixincludes
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 19:46 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18423
[Bug c++/18457] Ordering of member variables breaks code
-- What|Removed |Added GCC target triplet||i486-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18457
[Bug c++/18449] Problems when using function overloadtemplates across namespaces.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 20:16 --- Not a bug, templates do really get added to namespaces by using if -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18449
[Bug target/17778] [3.4/4.0 Regression] regression in evaluating long double hexadecimal constants
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-12 21:15 --- Subject: Bug 17778 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-12 21:15:24 Modified files: gcc: ChangeLog gcc/config/i386: freebsd.h i386-modes.def i386.h Log message: PR 17778 * config/i386/i386.h (TARGET_96_ROUND_53_LONG_DOUBLE): New. * config/i386/freebsd.h (SUBTARGET_OVERRIDE_OPTIONS): Remove. (TARGET_96_ROUND_53_LONG_DOUBLE): New. * config/i386/i386-modes.def (XF): Use it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6301r2=2.6302 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/freebsd.h.diff?cvsroot=gccr1=1.44r2=1.45 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386-modes.def.diff?cvsroot=gccr1=1.9r2=1.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.h.diff?cvsroot=gccr1=1.402r2=1.403 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17778
[Bug target/17778] [3.4/4.0 Regression] regression in evaluating long double hexadecimal constants
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-12 21:27 --- Subject: Bug 17778 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-11-12 21:26:55 Modified files: gcc: ChangeLog gcc/config/i386: freebsd.h i386-modes.def i386.h Log message: PR 17778 * config/i386/i386.h (TARGET_96_ROUND_53_LONG_DOUBLE): New. * config/i386/freebsd.h (SUBTARGET_OVERRIDE_OPTIONS): Remove. (TARGET_96_ROUND_53_LONG_DOUBLE): New. * config/i386/i386-modes.def (XF): Use it. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.688r2=2.2326.2.689 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/freebsd.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.41.10.1r2=1.41.10.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386-modes.def.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.6r2=1.6.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.368.2.4r2=1.368.2.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17778
[Bug target/17778] [3.4/4.0 Regression] regression in evaluating long double hexadecimal constants
--- Additional Comments From rth at gcc dot gnu dot org 2004-11-12 21:29 --- Fixed. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17778
[Bug c++/18457] Ordering of member variables breaks code
--- Additional Comments From cmh204 at lehigh dot edu 2004-11-12 21:39 --- After further reflection, this is a problem with my code. Although it is now an interesting question of why it worked at all in one order. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18457
[Bug c++/18389] [3.4/4.0 regression] ICE on struct declaration in for statement
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-12 21:47 --- Subject: Bug 18389 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-12 21:47:13 Modified files: gcc/cp : ChangeLog decl.c decl2.c parser.c pt.c tree.c gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/ext: vla1.C vlm1.C gcc/testsuite/g++.dg/template: crash2.C Added files: gcc/testsuite/g++.dg/parse: cond1.C gcc/testsuite/g++.dg/template: array9.C call3.C ptrmem11.C Log message: PR c++/18389 * decl.c (start_decl): Make sure to set *pop_scope_p. Return error_mark_node to indicate errors. PR c++/18429 * parser.c (cp_parser_direct_declarator): Disallow non-constant array bounds when not inside a function. PR c++/18436 * pt.c (tsubst_copy_and_build): Do not do Koenig lookup when an unqualified name resolves to a member function. PR c++/18407 * pt.c (tsubst_copy_and_build): Handle qualified names used from a derived class correctly. * decl2.c (import_export_decl): Fix typo in comment. * tree.c (pod_type_p): Likewise. PR c++/18389 * g++.dg/parse/cond1.C: New test. PR c++/18429 * g++.dg/template/array9.C: New test. * g++.dg/ext/vla1.C: Adjust error messages. * g++.dg/ext/vlm1.C: Likewise. * g++.dg/template/crash2.C: Likewise. PR c++/18436 * g++.dg/template/call3.C: New test. PR c++/18407 * g++.dg/template/ptrmem11.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4480r2=1.4481 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1326r2=1.1327 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gccr1=1.756r2=1.757 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.278r2=1.279 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.944r2=1.945 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gccr1=1.418r2=1.419 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4588r2=1.4589 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/vla1.C.diff?cvsroot=gccr1=1.1r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/vlm1.C.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/cond1.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/array9.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/call3.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ptrmem11.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash2.C.diff?cvsroot=gccr1=1.2r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18389
[Bug c++/18407] [3.4/4.0 Regression] ICE with mem-fun-ptr as template parameter for nested function template (build_base_path, cp/class.c)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-12 21:47 --- Subject: Bug 18407 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-12 21:47:13 Modified files: gcc/cp : ChangeLog decl.c decl2.c parser.c pt.c tree.c gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/ext: vla1.C vlm1.C gcc/testsuite/g++.dg/template: crash2.C Added files: gcc/testsuite/g++.dg/parse: cond1.C gcc/testsuite/g++.dg/template: array9.C call3.C ptrmem11.C Log message: PR c++/18389 * decl.c (start_decl): Make sure to set *pop_scope_p. Return error_mark_node to indicate errors. PR c++/18429 * parser.c (cp_parser_direct_declarator): Disallow non-constant array bounds when not inside a function. PR c++/18436 * pt.c (tsubst_copy_and_build): Do not do Koenig lookup when an unqualified name resolves to a member function. PR c++/18407 * pt.c (tsubst_copy_and_build): Handle qualified names used from a derived class correctly. * decl2.c (import_export_decl): Fix typo in comment. * tree.c (pod_type_p): Likewise. PR c++/18389 * g++.dg/parse/cond1.C: New test. PR c++/18429 * g++.dg/template/array9.C: New test. * g++.dg/ext/vla1.C: Adjust error messages. * g++.dg/ext/vlm1.C: Likewise. * g++.dg/template/crash2.C: Likewise. PR c++/18436 * g++.dg/template/call3.C: New test. PR c++/18407 * g++.dg/template/ptrmem11.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4480r2=1.4481 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1326r2=1.1327 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gccr1=1.756r2=1.757 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.278r2=1.279 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.944r2=1.945 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gccr1=1.418r2=1.419 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4588r2=1.4589 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/vla1.C.diff?cvsroot=gccr1=1.1r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/vlm1.C.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/cond1.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/array9.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/call3.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ptrmem11.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash2.C.diff?cvsroot=gccr1=1.2r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18407
[Bug c++/18429] [4.0 Regression] ICE on invalid code with array size being a non constant variable
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-12 21:47 --- Subject: Bug 18429 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-12 21:47:13 Modified files: gcc/cp : ChangeLog decl.c decl2.c parser.c pt.c tree.c gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/ext: vla1.C vlm1.C gcc/testsuite/g++.dg/template: crash2.C Added files: gcc/testsuite/g++.dg/parse: cond1.C gcc/testsuite/g++.dg/template: array9.C call3.C ptrmem11.C Log message: PR c++/18389 * decl.c (start_decl): Make sure to set *pop_scope_p. Return error_mark_node to indicate errors. PR c++/18429 * parser.c (cp_parser_direct_declarator): Disallow non-constant array bounds when not inside a function. PR c++/18436 * pt.c (tsubst_copy_and_build): Do not do Koenig lookup when an unqualified name resolves to a member function. PR c++/18407 * pt.c (tsubst_copy_and_build): Handle qualified names used from a derived class correctly. * decl2.c (import_export_decl): Fix typo in comment. * tree.c (pod_type_p): Likewise. PR c++/18389 * g++.dg/parse/cond1.C: New test. PR c++/18429 * g++.dg/template/array9.C: New test. * g++.dg/ext/vla1.C: Adjust error messages. * g++.dg/ext/vlm1.C: Likewise. * g++.dg/template/crash2.C: Likewise. PR c++/18436 * g++.dg/template/call3.C: New test. PR c++/18407 * g++.dg/template/ptrmem11.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4480r2=1.4481 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1326r2=1.1327 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gccr1=1.756r2=1.757 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.278r2=1.279 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.944r2=1.945 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gccr1=1.418r2=1.419 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4588r2=1.4589 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/vla1.C.diff?cvsroot=gccr1=1.1r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/vlm1.C.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/cond1.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/array9.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/call3.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ptrmem11.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash2.C.diff?cvsroot=gccr1=1.2r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18429
[Bug c++/18436] [3.4/4.0 Regression] ICE in perform_or_defer_access_check (binfo is NULL)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-12 21:47 --- Subject: Bug 18436 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-12 21:47:13 Modified files: gcc/cp : ChangeLog decl.c decl2.c parser.c pt.c tree.c gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/ext: vla1.C vlm1.C gcc/testsuite/g++.dg/template: crash2.C Added files: gcc/testsuite/g++.dg/parse: cond1.C gcc/testsuite/g++.dg/template: array9.C call3.C ptrmem11.C Log message: PR c++/18389 * decl.c (start_decl): Make sure to set *pop_scope_p. Return error_mark_node to indicate errors. PR c++/18429 * parser.c (cp_parser_direct_declarator): Disallow non-constant array bounds when not inside a function. PR c++/18436 * pt.c (tsubst_copy_and_build): Do not do Koenig lookup when an unqualified name resolves to a member function. PR c++/18407 * pt.c (tsubst_copy_and_build): Handle qualified names used from a derived class correctly. * decl2.c (import_export_decl): Fix typo in comment. * tree.c (pod_type_p): Likewise. PR c++/18389 * g++.dg/parse/cond1.C: New test. PR c++/18429 * g++.dg/template/array9.C: New test. * g++.dg/ext/vla1.C: Adjust error messages. * g++.dg/ext/vlm1.C: Likewise. * g++.dg/template/crash2.C: Likewise. PR c++/18436 * g++.dg/template/call3.C: New test. PR c++/18407 * g++.dg/template/ptrmem11.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4480r2=1.4481 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1326r2=1.1327 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gccr1=1.756r2=1.757 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.278r2=1.279 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.944r2=1.945 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gccr1=1.418r2=1.419 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4588r2=1.4589 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/vla1.C.diff?cvsroot=gccr1=1.1r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/vlm1.C.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/cond1.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/array9.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/call3.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ptrmem11.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash2.C.diff?cvsroot=gccr1=1.2r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18436
