[Bug target/30474] Bad 16bit constant code generation on 64bit host
--- Comment #3 from liqin at gcc dot gnu dot org 2007-05-23 07:09 --- Subject: Bug 30474 Author: liqin Date: Wed May 23 06:09:20 2007 New Revision: 124983 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124983 Log: 2007-05-23 Chen Liqin [EMAIL PROTECTED] PR target/30987 * config/score/misc.md (bitclr_c, bitset_c, bittgl_c): remove. * config/score/predicate.md (const_pow2, const_npow2): remove. * config/score/score.h (ASM_OUTPUT_EXTERNAL): add ASM_OUTPUT_EXTERNAL undef. PR target/30474 * config/score/score.c (score_print_operand): makes sure that only lower bits are used. Modified: trunk/gcc/ChangeLog trunk/gcc/config/score/misc.md trunk/gcc/config/score/predicates.md trunk/gcc/config/score/score.c trunk/gcc/config/score/score.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30474
[Bug target/30987] [4.3 Regression] Problem while compiling gcc for score
--- Comment #8 from liqin at gcc dot gnu dot org 2007-05-23 07:09 --- Subject: Bug 30987 Author: liqin Date: Wed May 23 06:09:20 2007 New Revision: 124983 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124983 Log: 2007-05-23 Chen Liqin [EMAIL PROTECTED] PR target/30987 * config/score/misc.md (bitclr_c, bitset_c, bittgl_c): remove. * config/score/predicate.md (const_pow2, const_npow2): remove. * config/score/score.h (ASM_OUTPUT_EXTERNAL): add ASM_OUTPUT_EXTERNAL undef. PR target/30474 * config/score/score.c (score_print_operand): makes sure that only lower bits are used. Modified: trunk/gcc/ChangeLog trunk/gcc/config/score/misc.md trunk/gcc/config/score/predicates.md trunk/gcc/config/score/score.c trunk/gcc/config/score/score.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30987
[Bug target/30987] [4.3 Regression] Problem while compiling gcc for score
--- Comment #9 from liqin at gcc dot gnu dot org 2007-05-23 07:31 --- * config/score/misc.md (bitclr_c, bitset_c, bittgl_c): remove. * config/score/predicate.md (const_pow2, const_npow2): remove. -- liqin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30987
[Bug target/30474] Bad 16bit constant code generation on 64bit host
--- Comment #4 from liqin at gcc dot gnu dot org 2007-05-23 07:35 --- * config/score/score.c (score_print_operand): makes sure that only lower bits are used. -- liqin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30474
[Bug objc++/32052] New: [4.3 Regression] encode-2.mm, encode-3.mm fail on at least powerpc-darwin
encode-2.mm produces Vec=ffi for its enconding of @encode(Vecfloat). which is wrong, it should produce Vecfloat=ffi. This was caused by: 2007-02-22 Michael Matz [EMAIL PROTECTED] PR c++/29433 * cp-tree.h (TFF_UNQUALIFIED_NAME): New formatting flag. * error.c (dump_aggr_type, dump_simple_decl, dump_decl, dump_function_decl): Guard emitting outer scopes by new flag. * cp-lang.c (cxx_dwarf_name): New function. (LANG_HOOKS_DWARF_NAME): Define to cxx_dwarf_name. * pt.c (classtype_mangled_name, mangle_class_name_for_template): Remove functions. (push_template_decl_real, lookup_template_class): Remove calls to above functions. -- Summary: [4.3 Regression] encode-2.mm, encode-3.mm fail on at least powerpc-darwin Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: powerpc-darwin BugsThisDependsOn: 29433 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32052
[Bug objc++/32052] [4.3 Regression] encode-2.mm, encode-3.mm fail on at least powerpc-darwin
-- 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=32052
[Bug fortran/31917] [4.1 only] GFORTRAN_CONVERT_UNIT is ignored
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-23 08:44 --- Do you plan a backport? If not, we should close this. I decided to backport it in the basis that the failures are difficult to track as there is not any feedback whether the environment are in effect or not. Additionally, the fix is very localized. Fixed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.2.0 4.1.2 |4.2.0 Known to work|4.3.0 |4.3.0 4.1.2 Resolution||FIXED Summary|[4.2, 4.1 only] |[4.1 only] |GFORTRAN_CONVERT_UNIT is|GFORTRAN_CONVERT_UNIT is |ignored |ignored Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31917
[Bug fortran/31917] [4.1 only] GFORTRAN_CONVERT_UNIT is ignored
--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-23 08:44 --- Subject: Bug 31917 Author: burnus Date: Wed May 23 07:44:23 2007 New Revision: 124984 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124984 Log: 2007-05-23 Tobias Burnus [EMAIL PROTECTED] PR fortran/31917 Backport from trunk. * runtime/environ.c (mark_range): Fix setting default convert unit. Modified: branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/runtime/environ.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31917
[Bug fortran/32046] [4.3 Regression] wrong code with -O2 for gfortran.dg/interface_12.f90 result_in_spec_1.f90
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-05-23 09:25 --- Subject: Bug 32046 Author: fxcoudert Date: Wed May 23 08:25:05 2007 New Revision: 124985 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124985 Log: PR fortran/32046 * trans-expr.c (gfc_trans_zero_assign): Convert the result of TYPE_SIZE_UNIT into a signed type. (gfc_trans_array_copy): Likewise. (gfc_trans_array_constructor_copy): Likewise. * trans-array.c (gfc_trans_create_temp_array): Likewise. (gfc_grow_array): Likewise. (gfc_array_init_size): Likewise. (gfc_duplicate_allocatable): Likewise. * trans-stmt.c (allocate_temp_for_forall_nest_1): Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32046
[Bug fortran/32046] [4.3 Regression] wrong code with -O2 for gfortran.dg/interface_12.f90 result_in_spec_1.f90
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-05-23 09:34 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32046
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #124 from rguenther at suse dot de 2007-05-23 09:35 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Tue, 22 May 2007, dberlin at dberlin dot org wrote: --- Comment #116 from dberlin at gcc dot gnu dot org 2007-05-22 18:13 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On 22 May 2007 17:01:40 -, gdr at cs dot tamu dot edu [EMAIL PROTECTED] wrote: --- Comment #114 from gdr at cs dot tamu dot edu 2007-05-22 18:01 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: | Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement | new does not change the dynamic type as it should | | gdr at cs dot tamu dot edu wrote: | --- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46 --- | Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the | dynamic type as it should | | mark at codesourcery dot com [EMAIL PROTECTED] writes: | | | But, I don't think the standard contemplated | | these issues in sufficient detail to make it useful in this respect. | | The issues has been raised on the -core reflector. | | So that I understand, do you mean that they have been raised in the | past, and settled, or that you've just raised them now? I just raised it, mainly because I do not believe your conclusions are right. The type information you can get from write and read are not just those appearing lexically in a scope. In fact, the semantics is defined in terms of the run time read and write access. That is what makes C a strongly typed and weakly check language (DMR). This whole issue does not mean you have to abandon TBAA. It means you have be careful in how you use the information gained from TBAA. In particular, many conclusions are OK when you have the definition of the objects at hand. Uh, you do more or less have to abandon TBAA for pointer arguments unless you can account for every single caller of your function, and ensure that none of them are passing you pointers external to what your compiler can see. This case is *extremely rare* outside of the user giving us a whole program guarantee. TBAA's main use is in fact, in disambiguating pointer arguments. If you take that away, it becomes pretty much useless. It's guarantees about local objects were never interesting. But you can still perform hoisting loads of incoming pointer arguments and sinking stores to incoming pointer arguments. Please read comment #105 and come up with a testcase where we wouldn't be allowed to do a useful transformation we do now. So I believe making placement new work with our current scheme will severely pessimize placement new users, but if we slightly change rules for everyone we'll be all happy. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug objc++/32052] [4.3 Regression] encode-2.mm, encode-3.mm fail on at least powerpc-darwin
--- Comment #1 from matz at gcc dot gnu dot org 2007-05-23 09:36 --- The ObjC frontend seems to use IDENTIFIER_POINTER directly to produce this encoding. This doesn't contain template arguments anymore. And from quick reading of obj-act.c it's also not clear if it was really expecting funny characters like '' in those identifiers. It happily uses these names to construct other identifiers. This works fine in C, but in C++, when they still contained template args the new identifiers would contain and ,, surely not something you expect from normal identifiers. I would suggest auditing objc-act.c carefully, if using IDENTIFIER_POINTER is really correct everywhere. Additionally, someone knowledgable in Obj-C++ should define once and for all what the encoding of such types should be. If it is supposed to include template args, then you need to use a different mean than accessing IDENTIFIER_POINTER. One way would be decl_as_string (t, TFF_DECL_SPECIFIERS | TFF_UNQUALIFIED_NAME); (Or leaving out TFF_UNQUALIFIED_NAME if you also need toplevel namespaces in there). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32052
[Bug fortran/32046] [4.3 Regression] wrong code with -O2 for gfortran.dg/interface_12.f90 result_in_spec_1.f90
--- Comment #10 from patchapp at dberlin dot org 2007-05-23 09:44 --- Subject: Bug number PR32046 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-05/msg01499.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32046
[Bug c++/32053] New: Anonymous union members' names should be distinct within enclosing scope
The following program should not compile:
extern int foo;
static union
{
int foo; // clash
};
C++ standard clause 9.5/2 states that members of anonymous unions must have
names distinct from other names in the same scope.
If the `extern' keyword is removed from the example above, the error is
diagnosed correctly (followed by an ICE).
--
Summary: Anonymous union members' names should be distinct within
enclosing scope
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32053
[Bug c++/32054] New: Storage classes on anonymous unions in classes
The following program should not compile.
class C
{
auto union // bad
{
int a;
};
register union // bad
{
int b;
};
static union // bad
{
int c;
};
extern union // bad
{
int d;
};
mutable union // bad
{
int e;
};
};
auto, register, and extern are not normally allowed in classes.
static and mutable might be allowed on other members, but not on anonymous
unions. See C++ standard clause 9.5/3.
--
Summary: Storage classes on anonymous unions in classes
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32054
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-05-23 11:17 --- This particular case is indeed an optimization issue and __udivdi3 can be avoided by using volatile as stated and verified. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug fortran/32048] max / min and NaN
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-05-23 11:21 --- Of course people are complaining that min/max as of IEEE does not propagate NaNs as other operations do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32048
[Bug fortran/31219] ICE on array of character function results
--- Comment #8 from patchapp at dberlin dot org 2007-05-23 11:25 --- Subject: Bug number PR31219 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-05/msg01540.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31219
[Bug fortran/32047] ICE (segfault) for pure function without argument
--- Comment #2 from pault at gcc dot gnu dot org 2007-05-23 11:36 --- I will submit a patch in a few minutes. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-23 11:36:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32047
[Bug fortran/32047] ICE (segfault) for pure function without argument
--- Comment #3 from patchapp at dberlin dot org 2007-05-23 11:55 --- Subject: Bug number PR32047 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-05/msg01541.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32047
[Bug target/32055] New: reload failure building libgfortran
I have configured gcc (revision 124905) like this:
/n/08/rask/src/gcc/configure --target=m32c-unknown-elf --with-gmp=${HOME}/opt
--with-mpfr=${HOME}/opt --disable-nls --with-newlib --enable-sim
--disable-multilib
Building libgfortran fails with this ICE:
/home/rask/build/gcc-m32c-unknown-elf/./gcc/gfortran
-B/home/rask/build/gcc-m32c-unknown-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/newlib/ -isystem
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/newlib/targ-include
-isystem /n/08/rask/src/gcc/newlib/libc/include
-B/usr/local/m32c-unknown-elf/bin/ -B/usr/local/m32c-unknown-elf/lib/ -isystem
/usr/local/m32c-unknown-elf/include -isystem
/usr/local/m32c-unknown-elf/sys-include
-L/home/rask/build/gcc-m32c-unknown-elf/./ld
-B/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/m32c
-L/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/m32c
-L/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/libnosys -I .
-Wall -fno-repack-arrays -fno-underscoring -fallow-leading-underscore -g -O2 -c
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90 -o
selected_int_kind.o
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90: In function
'_gfortran_selected_int_kind':
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90:42: error:
unable to find a register to spill in class 'A_REGS'
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90:42: error: this
is the insn:
(jump_insn 81 79 117 3
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90:36 (set (pc)
(if_then_else (lt (mem/s/u:HI (plus:HI (reg:SI 0 r0 [100])
(const:HI (plus:HI (symbol_ref:HI (int_infos.867)
[flags 0x2] var_decl 0x4872f1cc int_infos)
(const_int 6 [0x6] [2 variable.range+2 S2
A8])
(reg:HI 3 r3 [orig:108 pretmp.24+2 ] [108]))
(label_ref 96)
(pc))) 48 {cbranchhi4} (insn_list:REG_DEP_TRUE 79 (nil))
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil)))
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90:42: internal
compiler error: in spill_failure, at reload1.c:2002
The (plus:HI (reg:SI ...)) bit looks suspicious.
--
Summary: reload failure building libgfortran
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC build triplet: i386-unknown-netbsdelf2.0.2
GCC host triplet: i386-unknown-netbsdelf2.0.2
GCC target triplet: m32c-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32055
[Bug c++/32056] New: Storage classes on template parameters
None of the following should be accepted.
template auto int T struct A {};
template extern int T struct B {};
template static int T struct C {};
template register int T struct D {};
template mutable int T struct E {};
The extern, static and mutable are rejected with this message:
t.cxx:2: error: storage class specifiers invalid in parameter declarations
t.cxx:2: error: storage class specified for parameter T
t.cxx:3: error: storage class specifiers invalid in parameter declarations
t.cxx:3: error: storage class specified for parameter T
t.cxx:5: error: non-member T cannot be declared mutable
But static and register have been accepted.
Clause 14.1/2 of the C++ standard says that storage classes should not be used
here.
--
Summary: Storage classes on template parameters
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32056
[Bug other/32051] Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0
--- Comment #7 from manu at gcc dot gnu dot org 2007-05-23 13:06 --- (In reply to comment #6) Got mid-air colision message when clicking submit. I understand this is closed. What Andrew is trying to say in his particular way is that we cannot accept those patches (for the reasons stated), thus we are not going to spend time on discussing about it or much less reviewing the code because it will be a waste of our scarce time. Once the issues are solved (the copyright assignment is a major issue, another issue is who is going to maintain and fix bugs in all this code in the future), you may be able to convince someone to look into it. You may check out your own version and play with frameworks on it. However, GNU GCC is not a research toy. My sincere advice: find people interested on GEM, create a community around it, make it popular some many people/corporations/distributions start using it, then try to get it merged. I wish good luck and happy coding! -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #9 from manu at gcc dot gnu dot org 2007-05-23 13:15 --- (In reply to comment #3) The meaning of __builtin_expect is as defined in the documentation. This particular transformation has nothing to do with __builtin_expect. The transformation happens regardless of __builtin_expect. scev_const_prop eliminates the loop by replacing the final value with an expression using divide. Probably the right approach would be to prevent this from happening ifthe final value expression looks expensive (like DImode divide on targets without native DImode divide). Isn't there a way for __builtin_expect to modify this behaviour? After all, it is telling us that the loop is cheap. And the difference in computation time is not trivial at all. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #10 from malitzke at metronets dot com 2007-05-23 13:17 --- Mr. Guenther! The volatile fix would be fine, but (at least for me) does not work with the kernel. There is that little message: kernel/time.c:479: warning: passing argument 3 of 'div_long_rem_signed' discards qualifiers from pointer target type. and others like it, and, udivdi3 reappears. Mr. Park! The patch you kindly included in comment 3 presented two difficulties: 1. I Acould not extricate it cleanly enough from the html encoding apparently standard with bugzilla. (this is a Mozilla Product) 2. After some editing patch just accepted 1 hunk and upon checking it turned out that the svn derived tree-scalar.evolution.c did not match the enclosing lines around the lines to be added. I added those lines by hand (possibly imperfectly, enven on careful checking) the file compiled OK, but, runnign the gcc check sequence I got a stream of error. These errors disappeared on using a sequestered unpatched copy of the file. Hence, udivdi3 reappeared. If you see fit for me to test this not only on the reduced test case but on the actual kernel I suggest sending me a updated patch as a text attachment to my email. Thanks to all for trying to help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #125 from gdr at cs dot tamu dot edu 2007-05-23 14:22 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenther at suse dot de [EMAIL PROTECTED] writes: [...] | But you can still perform hoisting loads of incoming pointer arguments | and sinking stores to incoming pointer arguments. Please read comment | #105 and come up with a testcase where we wouldn't be allowed to do | a useful transformation we do now. So I believe making placement new | work with our current scheme will severely pessimize placement new | users, but if we slightly change rules for everyone we'll be all happy. Update. The only comment I have so far on the -core reflector is to the effect that the reading that the program I posted earlier violates NO aliasing rule. I'll follow with the proposal to bring the rules in line with recent C99 rules. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #126 from rguenther at suse dot de 2007-05-23 14:43 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Wed, 23 May 2007, gdr at cs dot tamu dot edu wrote: --- Comment #125 from gdr at cs dot tamu dot edu 2007-05-23 14:22 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenther at suse dot de [EMAIL PROTECTED] writes: [...] | But you can still perform hoisting loads of incoming pointer arguments | and sinking stores to incoming pointer arguments. Please read comment | #105 and come up with a testcase where we wouldn't be allowed to do | a useful transformation we do now. So I believe making placement new | work with our current scheme will severely pessimize placement new | users, but if we slightly change rules for everyone we'll be all happy. Update. The only comment I have so far on the -core reflector is to the effect that the reading that the program I posted earlier violates NO aliasing rule. I'll follow with the proposal to bring the rules in line with recent C99 rules. Note that it is important to retain the capability to implement memory allocators in C++ that are allowed to re-use memory for different typed objects. Which is not possible with C99 rules. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #11 from malitzke at metronets dot com 2007-05-23 14:51 --- Mr. Ibanez! Thank you (muchas gracias) for looking at the matter from a user's point of view and considering my arguments concerning __builtin_expect. You seem to be the first to look at the timings and amount of code generated. If you are interested I have equivalent data taken on a MAC with dual G4's. I did not send it so far because until you intervened I got mostly legalistic arguments and proposed fixes that do no solve the real problem of avoiding both udivdi3 and more importantly libgcc. -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug testsuite/32057] New: Random failure on gfortran.dg/secnds.f
I got random failure on gfortran.dg/secnds.f, which has t1 = secnds (0.0) call date_and_time (dum1, dum2, dum3, values) t1a = secnds (0.0) dat1 = 0.001*real (values(8)) + real (values(7)) + 60.0*real (values(6)) + 3600.0* real (values(5)) if (((dat1 - t1) 0.) .or. ((dat1 - t1) (t1a - t1))) call abort () do j=1,1 do i=1,1 end do end do t2a = secnds (t1a) call date_and_time (dum1, dum2, dum3, values) t2 = secnds (t1) dat2 = 0.001*real (values(8)) + real (values(7)) + 60.0*real (values(6)) + 3600.0* real (values(5)) if (((dat2 - dat1) t2a) .or. ((dat2 - dat1) t2)) call abort () I assume the dummy loop is used for delay. I don't think it is that reliable. Can't we use sleep here? -- Summary: Random failure on gfortran.dg/secnds.f Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-05-23 15:13
---
So this is now an enhancement request for sccp to honor loop roll count or
basic-block frequency and cost of the replacement. Note the loop appears to be
peeled twice before sccp already, but peeling doesn't decay probabilities
further.
Testcase:
int rmg(unsigned long long nsec)
{
int sec = 0;
nsec++;
while (__builtin_expect(nsec = 10UL, 0)) {
nsec -= 10UL;
++sec;
}
return sec;
}
note this can be worked around with -fno-tree-scev-cprop as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-05-23 15:13:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #127 from ian at airs dot com 2007-05-23 15:23 --- Re comment #105. The case where TBAA is most useful is on a deeply pipelined in-order processor with multiple function units and a high latency memory cache. One example I've worked on is an embedded VLIW processor with vector instructions. TBAA is of relatively little interest on an out-of-order processor. It's interesting to talk about PTA when you see the actual objects and you see how the pointers are taken. But in practice many real functions simply take pointers to arrays in memory. PTA can say nothing useful about those pointers, since they could point to anything. TBAA can say a lot. Losing the ability to sinks loads across stores and vice-versa means putting additional constraints on the scheduler which makes it harder to exploit the multiple function units. Conversely, it constrains the register allocator by tending to extend register lifetimes. Also, in your list of cases, you missed x = *int; *double = 1.0; x = *int; With TBAA we can eliminate the second load as a duplicate. With your proposed aliasing change we can not. I don't understand why you argue in comment #124 that our current scheme will esverely penalize placement new. On mainline there is no penalty for placement new. So you must be referring to one of the patches. But I don't think we've agreed on any of them at the moment. And I think we see the outlines of a successful patch: make placement new return a pointer which effectively aliases everything. That will permit us to reorder loads and eliminate dead stores. It won't permit us to arbitrarily re-order loads and stores, but I'm skeptical that that will count as a severe penalty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #8 from bonzini at gnu dot org 2007-05-23 15:24 --- I have a Mac so I can fix this, but I'm not sure on the timing. I'm commenting out the BOOT_CFLAGS setting for a moment to unbreak bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #9 from bonzini at gnu dot org 2007-05-23 15:26 --- Subject: Bug 32009 Author: bonzini Date: Wed May 23 14:26:31 2007 New Revision: 124990 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124990 Log: 2007-05-23 Paolo Bonzini [EMAIL PROTECTED] PR bootstrap/32009 * mh-ppc-darwin: Temporarily disable. Modified: trunk/config/ChangeLog trunk/config/mh-ppc-darwin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f
--- Comment #1 from dominiq at lps dot ens dot fr 2007-05-23 15:34 --- I assume the dummy loop is used for delay. I don't think it is that reliable. I think you are right about the delay, but not about the real problem: you have the same with secnds-1.f which does not cantain the loop. The goal of the tests is not to measure some time, but to check that intervals are properly ordered, i.e., t1=dat1=t1a and t2a=dat2-dat1= t2. I have started to investigate the problem, see the thread: http://gcc.gnu.org/ml/fortran/2007-05/msg00216.html I have started to prepare a report of my findings, but I got distracted because gcc is no longer building on Darwin. The main cause of failures is because the tests do not account for round off errors. This can easily handled for first test by comparing to the nearest values from below and above: the failure rate seems below a couple ppb (part per billion) measured on secnds-1.f, using a naive way to measure it. I think this is due to the fact that t1 and t1a are absolute times. For the second test I had to use wider tolerances (such as spacing(24.0*3600.0)) and even so I get some errors on Pentium machines ~1/1. After having removed this main source of failure I have found three more: (1) the tests do not handle timing around midnight when the counts go from 86400.0 to 0.0, (2) there is a rounding problem in secnds such that secnds(86400.0) returns 86400.0 during the 3ms before midnight, (3) on some machine the clock synchronization put the tests in jeopardy when the clock has a negative lag: the value returned after is before the value returned before! I think this is a detectable but unrecoverable error and, when detected, the tests should be skipped and repeated. I have a fix for the two other cases, although (2) should probably handled at the secnds level. In top of the report, I have started to prepare a program to do some testing on platforms I have no access to (I have used PPC Darwin, and AMD64 and Pentium Linux). I was planning to join it to the report (Encouragements are welcome !-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #128 from rguenther at suse dot de 2007-05-23 15:37 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, ian at airs dot com wrote:
--- Comment #127 from ian at airs dot com 2007-05-23 15:23 ---
Re comment #105.
The case where TBAA is most useful is on a deeply pipelined in-order processor
with multiple function units and a high latency memory cache. One example
I've
worked on is an embedded VLIW processor with vector instructions. TBAA is of
relatively little interest on an out-of-order processor.
It's interesting to talk about PTA when you see the actual objects and you see
how the pointers are taken. But in practice many real functions simply take
pointers to arrays in memory. PTA can say nothing useful about those
pointers,
since they could point to anything. TBAA can say a lot.
Losing the ability to sinks loads across stores and vice-versa means putting
additional constraints on the scheduler which makes it harder to exploit the
multiple function units. Conversely, it constrains the register allocator by
tending to extend register lifetimes.
Sure, scheduling is one of the places we sink loads or hoist stores.
Also, in your list of cases, you missed
x = *int;
*double = 1.0;
x = *int;
With TBAA we can eliminate the second load as a duplicate. With your proposed
aliasing change we can not.
We still can. We can hoist the second load before the store and so make
both loads load the same value. The fact that there is a second load
of int after the store to double disambiguates the two memory locations.
I don't understand why you argue in comment #124 that our current scheme will
esverely penalize placement new. On mainline there is no penalty for
placement
new. So you must be referring to one of the patches.
Yes, I was refering to patches that make changes to forbid sinking a load
across a store. With our current IL this will also forbid hoisting a
loop-invariant load - which is the key to good performance on tramp3d.
But I don't think we've
agreed on any of them at the moment. And I think we see the outlines of a
successful patch: make placement new return a pointer which effectively
aliases
everything. That will permit us to reorder loads and eliminate dead stores.
It won't permit us to arbitrarily re-order loads and stores, but I'm skeptical
that that will count as a severe penalty.
But...
void foo(int *p)
{
float *f = (float *)p;
new (p) float;
*f = 1.0;
}
there is no new pointer from placement new. All placement new does is
(magically) change the dynamic pointed-to type.
Or would you argue the above is invalid? It is hard to make
non-trivial cases work and not impose a full memory barrier at the
point of the placement new. In the above case you would need to
make the alias sets of float conflict with everything in which case
only trivial cases will allow to DSE stores to float or hoist loads
of floats.
As I said - with our current IL design I see no nice way to express
the constraints placement new sets without imposing more constraints
than necessary. (This is also true for my proposed changes -- those
constraints would be implicit in the IL, just optimization passes
would not need to look for PLACEMENT_NEW_EXPRs but simply follow
rules if they do optimizations on memory operations)
Maybe to find a compromise how about making PLACEMENT_NEW_EXPR
effective only after RTL expansion? So, during tree optimization
completely ignore it (from the alias IL representation perspective)
and follow the changed rules I proposed and after RTL expansion
make placement new effects explicit, like by merging target type
alias sets with alias set zero.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #10 from dominiq at lps dot ens dot fr 2007-05-23 15:39 --- I have a Mac so I can fix this, but I'm not sure on the timing. I'm commenting out the BOOT_CFLAGS setting for a moment to unbreak bootstrap. I'll give a try tonight, but it should work (I am not sure to believe the 3-5% on compile time, I'll see!-). Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #129 from gdr at cs dot tamu dot edu 2007-05-23 15:59 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenther at suse dot de [EMAIL PROTECTED] writes: | Note that it is important to retain the capability to implement | memory allocators in C++ that are allowed to re-use memory for different | typed objects. Yes, the C++ committee will never allow a rule that bans platcement-new and memory allocators :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f
--- Comment #2 from kargl at gcc dot gnu dot org 2007-05-23 16:05 --- Can't we use sleep here? No. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #130 from ian at airs dot com 2007-05-23 16:43 ---
In this example
void foo(int *p)
{
float *f = (float *)p;
new (p) float;
*f = 1.0;
}
the pointer is p. In fact the relevant pointer is always the argument to
placement new, and every pointer which PTA can associate with it.
We may simply have an impasse here. You have a set of rules which will change
the compiler to support placement new while giving better results for your
code. I believe that your change will penalize the code I used to work with.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #131 from rguenther at suse dot de 2007-05-23 16:54 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, ian at airs dot com wrote:
--- Comment #130 from ian at airs dot com 2007-05-23 16:43 ---
In this example
void foo(int *p)
{
float *f = (float *)p;
new (p) float;
*f = 1.0;
}
the pointer is p. In fact the relevant pointer is always the argument to
placement new, and every pointer which PTA can associate with it.
I don't read that into the semantics of placement new ;) Placement
new doesn't care about the pointer used to refer to the memory it
operates on.
We may simply have an impasse here. You have a set of rules which will change
the compiler to support placement new while giving better results for your
code. I believe that your change will penalize the code I used to work with.
Ok, fair enough. I'll try to teach load-store-motion for loops to not
re-order the inserted stores compared to the order on the loop exit path.
This is the only transformation on the tree-level I came across that
violates my proposed semantics.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c/32023] No casts in lvalue error message
--- Comment #10 from manu at gcc dot gnu dot org 2007-05-23 16:57 --- (In reply to comment #8) The point I'm trying to express is that it's useful for user to have more precise explanation. Would you be happy with something like? t.c:9: error: lvalue required as increment operand t.c:9: note: a cast is not a lvalue Perhaps we could even pack it in a single line. The feasibility of this depends on whether we can get this information when we emit the diagnostic. I think if someone wants to pursue it, it shouldn't be difficult. So why not keep it open? Low-hanging fruit like this is ideal for newbies. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-05-23 16:57:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
[Bug c/32023] No casts in lvalue error message
--- Comment #11 from nshmyrev at yandex dot ru 2007-05-23 17:06 --- Exactly :) Thanks Manuel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
[Bug c++/32058] New: invalid computed void parameter in template
Can't return void from type function instantiation with dependent args for use
in function declaration.
all versions from 3.4 to the latest 4.3.0 build on x86 cygwin/linux complain
with:
error: invalid parameter type 'void'
...
=
template int cond
struct F { typedef void Type; };
template int I
struct X {
// does not accept dependent computed type void!
// (void* is fine as is non-dependent F0::Type)
typedef typename FI::Type ParmT;
static int func(ParmT) { return 1; }
};
int main()
{
int i = X0::func();
}
The VisualC++ compilers are fine.
--
Summary: invalid computed void parameter in template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paul_m_doc at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32058
[Bug c/31673] `for' loop initial declaration used outside C99 mode is confusing
--- Comment #6 from manu at gcc dot gnu dot org 2007-05-23 17:36 --- (In reply to comment #1) Created an attachment (id=13431) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13431action=view) [edit] Suggested patch. Joerg, please test the patch and modify any failing testcases, then submit the patch to gcc-patches. I think your version is clearer. Perhaps `for' loop initial declarations only allowed in C99 mode is shorter and equally clear. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31673
[Bug other/32051] Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0
--- Comment #8 from rob1weld at aol dot com 2007-05-23 17:57 --- Thanks Manuel. I imagined that since I read it at http://gcc.gnu.org/readings.html that the GEM would (or _might_) be incorporated in future. My purpose in posting: 1): The patches were posted MORE with the thought that the general public would apply the patches, do some tests, submit any fixes - and AFTER all that, then (and only then) _might_ the maintainers _consider_ adding GEM. 2): To avoid the possiblility that people who write code (maintainers) would avoid writing code that shut GEM out (_if_ it _might_ be coming in the future). One example of this happening is that I tried to add boehm-gc 7 to GCC but the _Java_ code was written in such a way that you can't add gc-7 without some re-writing (if you compile GCC _WITHOUT_ Java it compiles fine). The Java maintainers went under the ABI and snooped in GC's .h files and used features that have been discontinued and did not follow exactly what is on http://gcc.gnu.org/contribute.html . 3): I thought it was GPL. 4): It was _never_ my thought that one of the maintainers were simply going to apply the patches to the SVN and unleash it on everyone. I agree with Andrew that were not putting it in SVN today - if that is what you thought I meant. I thought it was something that _might_ be coming and so made the patches for people to play with it. I'll fiddle with something else. Maybe have another look at GC7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32051
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #132 from dberlin at gcc dot gnu dot org 2007-05-23 19:03 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On 23 May 2007 08:35:12 -, rguenther at suse dot de [EMAIL PROTECTED] wrote: --- Comment #124 from rguenther at suse dot de 2007-05-23 09:35 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Tue, 22 May 2007, dberlin at dberlin dot org wrote: --- Comment #116 from dberlin at gcc dot gnu dot org 2007-05-22 18:13 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On 22 May 2007 17:01:40 -, gdr at cs dot tamu dot edu [EMAIL PROTECTED] wrote: --- Comment #114 from gdr at cs dot tamu dot edu 2007-05-22 18:01 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: | Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement | new does not change the dynamic type as it should | | gdr at cs dot tamu dot edu wrote: | --- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46 --- | Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the | dynamic type as it should | | mark at codesourcery dot com [EMAIL PROTECTED] writes: | | | But, I don't think the standard contemplated | | these issues in sufficient detail to make it useful in this respect. | | The issues has been raised on the -core reflector. | | So that I understand, do you mean that they have been raised in the | past, and settled, or that you've just raised them now? I just raised it, mainly because I do not believe your conclusions are right. The type information you can get from write and read are not just those appearing lexically in a scope. In fact, the semantics is defined in terms of the run time read and write access. That is what makes C a strongly typed and weakly check language (DMR). This whole issue does not mean you have to abandon TBAA. It means you have be careful in how you use the information gained from TBAA. In particular, many conclusions are OK when you have the definition of the objects at hand. Uh, you do more or less have to abandon TBAA for pointer arguments unless you can account for every single caller of your function, and ensure that none of them are passing you pointers external to what your compiler can see. This case is *extremely rare* outside of the user giving us a whole program guarantee. TBAA's main use is in fact, in disambiguating pointer arguments. If you take that away, it becomes pretty much useless. It's guarantees about local objects were never interesting. But you can still perform hoisting loads of incoming pointer arguments and sinking stores to incoming pointer arguments. Please read comment #105 and come up with a testcase where we wouldn't be allowed to do a useful transformation we do now. So I believe making placement new work with our current scheme will severely pessimize placement new users, but if we slightly change rules for everyone we'll be all happy. Have fun encoding this into the IL :) If TBAA can't say things about particular load/store pairs, without having to do a lot of work to see what is in between them, it's not going to be useful to us. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug middle-end/30537] [4.3 regression] ICE with -fno-unit-at-a-time an inlining
--- Comment #3 from janis at gcc dot gnu dot org 2007-05-23 19:39 --- A regression hunt on powerpc-linux using the submitter's test case identified the following patch: http://gcc.gnu.org/viewcvs?view=revrev=120835 r120835 | hubicka | 2007-01-16 21:30:54 + (Tue, 16 Jan 2007) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30537
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #133 from mark at codesourcery dot com 2007-05-23 19:43 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
The case where TBAA is most useful is on a deeply pipelined in-order processor
with multiple function units and a high latency memory cache. One example
I've
worked on is an embedded VLIW processor with vector instructions. TBAA is of
relatively little interest on an out-of-order processor.
The original motivating case for me was stuff like:
void f (int *a, double *d) {
for (int i = 1; i N; ++i) {
a[i] += i;
d[i] = d[i-1] * a[i];
}
}
That's not the right code, but the point is that TBAA can allow us to
avoid reloading d[i-1] from one iteration to the next, despite the store
to a[i]. That reduces memory access and instruction count. Ordinary
PTA does not allow this.
Of course, Gaby's memory model doesn't allow this optimization either;
we have to worry that a and d are both in some union somewhere.
That's why Gaby's model is so bad from an optimization point of view; it
makes the compiler assume a worst-case situation, even though that
worst-case situation almost never actually happens.
I'm not an expert on CPU models, so I'm not sure how out-of-order vs.
in-order might matter here.
And I think we see the outlines of a
successful patch: make placement new return a pointer which effectively
aliases
everything. That will permit us to reorder loads and eliminate dead stores.
It won't permit us to arbitrarily re-order loads and stores, but I'm skeptical
that that will count as a severe penalty.
That's exactly what I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #134 from rguenth at gcc dot gnu dot org 2007-05-23 19:54 --- But using a union for type-punning is a gcc extension (and of course the extension is only for access through the union), so with strict C99/C++ semantics we can avoid reloading d[i-1] even if a and d were in the same union because the code would then be invalid. So the union case is a non-issue here (it was only used to make available enough properly aligned storage for the particular testcase). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #135 from rguenth at gcc dot gnu dot org 2007-05-23 19:56 --- Re comment #132 -- you cannot encode this into the IL :/ And I don't propose to do so. And I say any working and optimal (from optimization perspective) variant of a fix for this PR has the same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/32059] New: include directives don't work with absolute pathnames
The include directive does not accept absolute path names that start with a /. For example (below). If I use the absolute pathname, the compiler complains that it cannot find the file. Using the relative pathname works fine. module io contains subroutine hi3 !include /data/L2TC/cmm/linux_code/gfortran/hi.f90 ! Does not work include ../gfortran/hi.f90 ! This works write(*,*) inside hi3 end subroutine hi3 end module io PROGRAM te_inc_str use io call hi3 END PROGRAM te_inc_str -- Summary: include directives don't work with absolute pathnames Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Catherine dot M dot Moroney at jpl dot nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32059
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #136 from mark at codesourcery dot com 2007-05-23 20:10 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenth at gcc dot gnu dot org wrote: --- Comment #134 from rguenth at gcc dot gnu dot org 2007-05-23 19:54 --- But using a union for type-punning is a gcc extension (and of course the extension is only for access through the union), so with strict C99/C++ semantics we can avoid reloading d[i-1] even if a and d were in the same union because the code would then be invalid. Gaby's claim, as I understand it, is that writing to a union member, even through a pointer, rather than directly through the union, is valid, and activates that part of the union. So, it is not a GCC extension. For code like: a[i] = i; d[i] = d[i-1] + a[i]; I guess you can argue that a[i] does not alias d[i-1], even in Gaby's model, because a[i] is written to right before the access to d[i-1]. But, you don't know that a[m] doesn't alias d[n] for arbitrary m and n. So, it's easy to create variations on the case I posted that can't be optimized, if you agree to Gaby's model. So the union case is a non-issue here (it was only used to make available enough properly aligned storage for the particular testcase). I agree that union case *should* be a non-issue in this context, where we were discussing how to fix placement new, but Gaby has made it one because he is claiming that placement new is not the only way to change the dynamic type of memory. Gaby's claim is that given an arbitrary pointer p, saying: (int *)p = 3; is the same as saying: *(new (p) int) = 3; That makes life for the optimizers much, much harder. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/32059] include directives don't work with absolute pathnames
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-05-23 20:33 --- Which version of gfortran are you using? This may be a duplicate of PR 30276, which was fixed in 4.2 and 4.3, but not 4.1. Upgrading to 4.2 (which is now released) may help. If the problem persists in 4.2 or 4.3, please drop us a line :-) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32059
[Bug fortran/32059] include directives don't work with absolute pathnames
--- Comment #2 from Catherine dot M dot Moroney at jpl dot nasa dot gov 2007-05-23 20:39 --- Subject: Re: include directives don't work with absolute pathnames I'm using v4.1.1, which I'm stuck at for reasons of compatability with another computing center. Catherine On May 23, 2007, at 12:33 PM, tkoenig at gcc dot gnu dot org wrote: --- Comment #1 from tkoenig at gcc dot gnu dot org 2007-05-23 20:33 --- Which version of gfortran are you using? This may be a duplicate of PR 30276, which was fixed in 4.2 and 4.3, but not 4.1. Upgrading to 4.2 (which is now released) may help. If the problem persists in 4.2 or 4.3, please drop us a line :-) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added --- - CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32059 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32059
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #137 from rguenth at gcc dot gnu dot org 2007-05-23 20:46 --- Created an attachment (id=13607) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13607action=view) patch to perserve store ordering in loop load/store motion quote Gaby's claim is that given an arbitrary pointer p, saying: (int *)p = 3; is the same as saying: *(new (p) int) = 3; That makes life for the optimizers much, much harder. /quote I say so as well (that those are the same), but I don't agree that this makes life for optimizers much harder. Anyway, this is a proposed patch for loop load/store motion that fixes the last posted testcase. Scheduling issues remain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #138 from rguenth at gcc dot gnu dot org 2007-05-23 20:57 --- Note the patch is not 100% correct as we need to preserve store ordering on the path to all exit edges which may be different for each exit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #139 from joseph at codesourcery dot com 2007-05-23 21:00 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Wed, 23 May 2007, mark at codesourcery dot com wrote: Of course, Gaby's memory model doesn't allow this optimization either; we have to worry that a and d are both in some union somewhere. DR#236 http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_236.htm was what eventually said for C that you don't need to worry about that; I'd think the aim should be to get C++ to agree with that ruling. DR#283, to appear in TC3, is what specifies type punning through unions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #140 from mark at codesourcery dot com 2007-05-23 21:07 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenth at gcc dot gnu dot org wrote:
quote
Gaby's claim is that given an arbitrary
pointer p, saying:
(int *)p = 3;
is the same as saying:
*(new (p) int) = 3;
That makes life for the optimizers much, much harder.
/quote
I say so as well (that those are the same), but I don't agree that this
makes life for optimizers much harder.
Placement new is rare; assignments to pointers are everywhere.
Note that the first case does not need to use an explicit cast. In a
function:
void f(int *p) {
*p = 3;
}
under Gaby's interpretation, we cannot be sure that p points to an
int before this function, so we can't be sure the write to *p
doesn't clobber memory of other types. TBAA is one of the few ways to
disambiguate pointers in the absence of whole-program optimization, and
this model really undermines TBAA.
Frankly, I'm surprised that you are taking this position. This is a
change to the compiler that can only hurt high-performance C++
applications, which is an area I know you care about. I know that
you're unhappy about how Ian's patches might hurt programs that use
placement-new in an inner loop, but this model will impose the same
penalties on programs that write to pointers in an inner loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #141 from mark at codesourcery dot com 2007-05-23 21:13 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should joseph at codesourcery dot com wrote: DR#236 http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_236.htm was what eventually said for C that you don't need to worry about that; I'd think the aim should be to get C++ to agree with that ruling. Thank you for the pointer. That seems directly on point, and makes C99 match the existing GCC practice: we don't need to worry that pointers might point to unions. Gaby, would you please forward that to the C++ reflector, so that the reflector has that information as well? They should be aware that the model you're proposing is at odds with C99. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #142 from rguenther at suse dot de 2007-05-23 21:14 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, mark at codesourcery dot com wrote:
--- Comment #140 from mark at codesourcery dot com 2007-05-23 21:07
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenth at gcc dot gnu dot org wrote:
quote
Gaby's claim is that given an arbitrary
pointer p, saying:
(int *)p = 3;
is the same as saying:
*(new (p) int) = 3;
That makes life for the optimizers much, much harder.
/quote
I say so as well (that those are the same), but I don't agree that this
makes life for optimizers much harder.
Placement new is rare; assignments to pointers are everywhere.
Note that the first case does not need to use an explicit cast. In a
function:
void f(int *p) {
*p = 3;
}
under Gaby's interpretation, we cannot be sure that p points to an
int before this function, so we can't be sure the write to *p
doesn't clobber memory of other types. TBAA is one of the few ways to
disambiguate pointers in the absence of whole-program optimization, and
this model really undermines TBAA.
In C inside the function f we can indeed be sure *p points to an int.
Now what matters is, that even in C for
double g(int *p, double *d)
{
f(p);
return *d;
}
we cannot be sure (in absence of whole-program optimization or the
body of f available) that the call to f does not clobber *d through
the value of the pointer p. As it can look like
void f(int *p)
{
double *d = p;
*d = 1.0;
}
Frankly, I'm surprised that you are taking this position. This is a
change to the compiler that can only hurt high-performance C++
applications, which is an area I know you care about. I know that
you're unhappy about how Ian's patches might hurt programs that use
placement-new in an inner loop, but this model will impose the same
penalties on programs that write to pointers in an inner loop.
No it won't. Or at least - I belive so - unless I see a patch that
manages to implement placement new with the same minor restrictions.
If you discount scheduling on in-order machines, what would be an
optimization that can be no longer done with Gabys and my scheme?
I believe there are none. Also other compilers manage to not
miscompile in the face of placement new but still optimize loops
with them.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug ada/31174] [4.2 regression] ACATS C380004 fails
--- Comment #4 from anhvofrcaus at gmail dot com 2007-05-23 21:19 --- Now ACATS c380004 passes in gcc-4.3-20070518. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
[Bug middle-end/31685] [4.3 regression] ICE in set_mem_attributes
--- Comment #3 from janis at gcc dot gnu dot org 2007-05-23 21:26 --- A regression hunt on powerpc-linux using the test case from comment #1 identified the following patch: http://gcc.gnu.org/viewcvs?view=revrev=120835 r120835 | hubicka | 2007-01-16 21:30:54 + (Tue, 16 Jan 2007) Yes, this really is the same result as for the other reghunt I did today, I double-checked! -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31685
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #143 from mark at codesourcery dot com 2007-05-23 21:27 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenther at suse dot de wrote:
void f(int *p) {
*p = 3;
}
under Gaby's interpretation, we cannot be sure that p points to an
int before this function, so we can't be sure the write to *p
doesn't clobber memory of other types. TBAA is one of the few ways to
disambiguate pointers in the absence of whole-program optimization, and
this model really undermines TBAA.
In C inside the function f we can indeed be sure *p points to an int.
Not before the assignment to p. In:
void f(int *p, double *q) {
double d = *q;
*p = 3;
return d;
}
your interpretation does not allow moving the load of *q after the
store to *p. That's clearly limiting the freedom of the optimizer.
Now, we can argue about how much that matters -- but it's inarguable
that it's a limitation.
If you discount scheduling on in-order machines, what would be an
optimization that can be no longer done with Gabys and my scheme?
I believe there are none. Also other compilers manage to not
miscompile in the face of placement new but still optimize loops
with them.
I'm lost.
What does Gaby's model have to do with placement new?
We're all agreed that (a) placement new can change the dynamic type of
memory, (b) therefore GCC currently has a bug, (c) we want the fix to
have as little optimization impact as possible.
Gaby's model says that we know less about dynamic types than we
presently think we do, because there might be a union out there
somewhere. (Fortunately, as Joseph points out, C99 has already answered
this question. Surely we can agree that making C99 and C++ different in
this respect is a bad idea.)
If *p = 3 changes the dynamic type of *p, that just means we know
even less. The less we know, the less optimization we can do. Making
*p = 3 change the dynamic type of *p can't possibly help us
implement placement new more efficiently. Whatever conservative
assumptions we want to make about *p = 3 we could make about new (p)
int instead.
If you have a patch that fixes the placement new problem, making us
generate correct code, and with minimal/no impact on optimization,
that's great! But, that can't possibly, in and of itself, be a reason
to change the rules we're using for TBAA.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug testsuite/32060] New: gcc/testsuite/gcc/gcc.log - WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator
A few broken spots in the testsuite ... # gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_3-trunk/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.3 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime Thread model: posix gcc version 4.3.0 20070523 (experimental) --- # grep -B 5 -A 5 gcc.dg-struct-layout-1_generate gcc/testsuite/gcc/gcc.log FAIL: gcc.dg/compat/vector-2 c_compat_x_tst.o-c_compat_y_tst.o execute testcase /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/compat/compat.exp completed in 57 seconds Running /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp ... Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ dfprt5233.c -fno-show-column -lm -o dfprt5233.x(timeout = 300) Setting LD_LIBRARY_PATH to :/opt/gcc-4_3-build/gcc::/opt/gcc-4_3-build/gcc:/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build/./gcc:/opt/gcc-4_3-build/./prev-gcc Executing on host: gcc -g -O2 -o /opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.dg-struct-layout-1_generate /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/compat/generate-random.c /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/compat/generate-random_r.c (timeout = 300) WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator testcase /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp completed in 0 seconds Running /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/cpp/cpp.exp ... Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/cpp/19921210-1.c-ansi -pedantic-errors -fno-show-column -S -o 19921210-1.s(timeout = 300) PASS: gcc.dg/cpp/19921210-1.c (test for excess errors) The message WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator is odd. The gcc.log _claims_ it is using the OS gcc to compile: # ls -l /opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.dg-struct-layout-1_generate ls: /opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.dg-struct-layout-1_generate: No such file or directory # gcc -g -O2 -o /opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.dg-struct-layout-1_generate /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/compat/generate-random.c /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/compat/generate-random_r.c # ls -l /opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.dg-struct-layout-1_generate -rwxr-xr-x 1 root root 69791 May 23 12:48 /opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.dg-struct-layout-1_generate When I cut-and-paste the gcc command from the log the generator compiles OK. The testsuite works on 4.2.0 i686-pc-cygwin and 4.2.1 i686-pc-linux-gnu. Point 1): Having the testsuite fail with this warning denies the testsuite from running a whole battery of tests that the generator creates. One warning _might_ cover-up many _possible_ errors if the test were ran (or hide many sucesses). Point 2): (Retorical Questions) Why do we use gcc ? - The OS's gcc. Which version are we using, do we care? Can it actually compile the tests? We _ought_ to use gcc/xgcc ! - then we know which version of gcc we are using. If xgcc can not compile the generator then _IT_ is at fault. If the OS's gcc can not compile the generator then does that _actually_ matter - no. If the program is so trivial that any compiler can compile it then why not have xgcc do it. That makes the warning into an error _IF_ it fails, if it succeeds then it is a pass and not a warning. The rest of the tests can then get a chance to run instead of being denied simply because the OS's gcc did not compile the file. Another problem occurs immediatly after: WARNING: Could not compile gcc.dg/compat
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #144 from rguenther at suse dot de 2007-05-23 21:48 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, mark at codesourcery dot com wrote:
rguenther at suse dot de wrote:
void f(int *p) {
*p = 3;
}
under Gaby's interpretation, we cannot be sure that p points to an
int before this function, so we can't be sure the write to *p
doesn't clobber memory of other types. TBAA is one of the few ways to
disambiguate pointers in the absence of whole-program optimization, and
this model really undermines TBAA.
In C inside the function f we can indeed be sure *p points to an int.
Not before the assignment to p. In:
void f(int *p, double *q) {
double d = *q;
*p = 3;
return d;
}
your interpretation does not allow moving the load of *q after the
store to *p. That's clearly limiting the freedom of the optimizer.
Yes, it's limiting the freedom of optimizers.
Now, we can argue about how much that matters -- but it's inarguable
that it's a limitation.
If you discount scheduling on in-order machines, what would be an
optimization that can be no longer done with Gabys and my scheme?
I believe there are none. Also other compilers manage to not
miscompile in the face of placement new but still optimize loops
with them.
I'm lost.
What does Gaby's model have to do with placement new?
Only so much that we seem to agree on the semantics of placement new.
Gaby extends this semantics to any store, so
*p = X;
is equivalent to
*(new (p) __typeof__ *p) = X;
to which semantics we thus can agree (not to whether those two should
be the same, mandated by the standard or liked by some of us or not).
Gaby's model says that we know less about dynamic types than we
presently think we do, because there might be a union out there
somewhere. (Fortunately, as Joseph points out, C99 has already answered
this question. Surely we can agree that making C99 and C++ different in
this respect is a bad idea.)
I don't think dragging in unions helps us here ;) Maybe Gaby can clarify
if and how unions relate here, but I didn't percieve any previous comment
as making implicit unions relevant here apart from what GCC and
apperantly C99 agree to.
If *p = 3 changes the dynamic type of *p, that just means we know
even less. The less we know, the less optimization we can do.
True.
Making *p = 3 change the dynamic type of *p can't possibly help us
implement placement new more efficiently.
I disagree here. Making *p = 3 change the dynamic type of *p will
make the placement new issue moot - the current library implementation
is fine then and we don't need any new explicit or implicit side-effects
of it.
Whatever conservative
assumptions we want to make about *p = 3 we could make about new (p)
int instead.
True. I say making them about *p = 3 is way easier as we are changing
semantics of memory operations and *p = 3 is one, but placement new is
not.
If you have a patch that fixes the placement new problem, making us
generate correct code, and with minimal/no impact on optimization,
that's great! But, that can't possibly, in and of itself, be a reason
to change the rules we're using for TBAA.
Well, it depends if you read it as changing TBAA rules. Does preserving
store ordering in loop load/store motion change TBAA rules? Not in
itself - but clearly changed TBAA rules would force us to. Same for
limiting scheduling of memory operations. Btw, the necessary patch
may be as simple as
Index: alias.c
===
--- alias.c (revision 124998)
+++ alias.c (working copy)
@@ -2284,7 +2284,8 @@ write_dependence_p (rtx mem, rtx x, int
|| MEM_ALIAS_SET (mem) == ALIAS_SET_MEMORY_BARRIER)
return 1;
- if (DIFFERENT_ALIAS_SETS_P (x, mem))
+ /* We cannot rely on alias set differences for C++ aliasing semantics.
*/
+ if (0 DIFFERENT_ALIAS_SETS_P (x, mem))
return 0;
/* A read from read-only memory can't conflict with read-write memory. */
but as I'm currently lacking a testcase that fails due to scheduling
I'm not 100% sure.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #11 from dominiq at lps dot ens dot fr 2007-05-23 21:48 --- With the last patch the build passed the critical point!-) I'll have the full build tomorrow morning (Paris time). Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug preprocessor/20077] [4.0/4.1/4.2/4.3 Regression] GCC accepts macro definitions that fail a constraint
--- Comment #7 from simartin at gcc dot gnu dot org 2007-05-23 21:58 --- Subject: Bug 20077 Author: simartin Date: Wed May 23 20:58:34 2007 New Revision: 125000 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125000 Log: 2007-05-23 Simon Martin [EMAIL PROTECTED] PR preprocessor/20077 * macro.c (create_iso_definition): Fixed the method to determine whether the token-pasting operator appears at the beginning or the end of a macro. Added: trunk/gcc/testsuite/gcc.dg/cpp/paste15.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20077
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #145 from dberlin at gcc dot gnu dot org 2007-05-23 22:02 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On 23 May 2007 18:57:03 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #135 from rguenth at gcc dot gnu dot org 2007-05-23 19:56 --- Re comment #132 -- you cannot encode this into the IL :/ And I don't propose to do so. And I say any working and optimal (from optimization perspective) variant of a fix for this PR has the same problem. So instead you are going to change every single optimization to preserve things like store ordering, even though the underlying aliasing information says it's okay to reorder (because it's broken in the presence of these restrictions)? No thanks! This would be a massive rathole to go down in the end, and completely at odds with the idea that our middle end IL is language independent, and like *C*. C99 has a clear proposed resolution to DR 236, and it says you need to visibly use a union (which takes care of the other issue mentioned here) If placement new needs to mean a memory barrier to get things right for placement new/C++, it needs to mean a memory barrier to get things right for now. Changing language independent optimizations to preserve something magical in the face of wrong aliasing information is not the way to fix this PR. I would support turning off TBAA over that solution, given the choice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug preprocessor/20077] [4.0/4.1/4.2/4.3 Regression] GCC accepts macro definitions that fail a constraint
--- Comment #8 from simartin at gcc dot gnu dot org 2007-05-23 22:05 --- Fixed on the mainline. -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20077
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #146 from mark at codesourcery dot com 2007-05-23 22:13 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenther at suse dot de wrote: Only so much that we seem to agree on the semantics of placement new. Gaby extends this semantics to any store, so *p = X; is equivalent to *(new (p) __typeof__ *p) = X; to which semantics we thus can agree (not to whether those two should be the same, mandated by the standard or liked by some of us or not). I think I understand. Let me just restate this, to make sure: (a) Gaby's model makes the first assignment above equivalent to the second (b) Thus, in Gaby's model, if we solve either case, we solve both. I agree with that statement. (I don't like the model -- but I agree with the logic.) Making *p = 3 change the dynamic type of *p can't possibly help us implement placement new more efficiently. I disagree here. Making *p = 3 change the dynamic type of *p will make the placement new issue moot - the current library implementation is fine then and we don't need any new explicit or implicit side-effects of it. Whatever conservative assumptions we want to make about *p = 3 we could make about new (p) int instead. True. I say making them about *p = 3 is way easier as we are changing semantics of memory operations and *p = 3 is one, but placement new is not. I think I understand what you're saying here too; again, I'll restate to make sure: (a) In the model where *p = 3 changes the dynamic type of memory, we don't need to do anything special to handle placement new. (b) It's relatively easy to implement support for *p = 3 changing the dynamic type of memory. (c) Therefore, it's relatively easy to fix our placement new problem. I agree with those statements too. However, I don't like this approach because I believe it will result in inferior code. I think that you're looking at the proposed placement new patches, then looking at what they do to a particular codebase, which happens to use placement-new in an inner loop, and becoming unhappy with the patches. I suspect that the changes required to support the *p = 3 model, while perhaps better for that case, will be worse for many others. I can't prove that. But, I did implement TBAA after looking at what other compilers did, specifically to improve performance of (ironically) POOMA. So, I'm afraid that you're going to find that if we allow memory writes to change the type of memory, that we will get worse performance. That's why I'm much more comfortable with a change that only affects placement new. At least, if placement new is slow, we can tell users not to use it in inner loops. If using pointers are slow, there's nothing we can do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug other/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure
--- Comment #2 from sje at cup dot hp dot com 2007-05-23 22:19 --- I am not sure what, if anything, we should do with this bug report. The compiler is working as designed, the test case has a very large number of nested parenthesis which causes the parser to recurse over and over as it parses through the expression. If you have enough stack space (and swap space) the test seems to compile fine in a reasonable amount of time. If you run out of stack space or run out of swap space then the test fails. This test runs fine on my IA64 HP-UX and Linux boxes and on my HPPA HP-UX boxes where I have increased the stack size. If I change the test case to do more nesting, I can get it to fail. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31827
[Bug boehm-gc/21942] boehm-gc doesn't compile on Solaris 10/amd64
--- Comment #6 from philip_walker at raytheon dot com 2007-05-23 22:43 --- I experienced the same error trying to compile 4.2.0 using gcc 4.1.2. gcc -v output is: Target: i386-pc-solaris2.10 configured with: ./configure --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --languages=c,c++ --enable-shared Thread model =posix gcc version 4.1.2 I get two errors about the -- before token, one on line 466 and one on line 2177 of gcconfig.h I will be glad to provide more info if needed. Philip -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21942
[Bug java/32010] bootstrap fails; chooses wrong zlib for building jc1
--- Comment #1 from lucier at math dot purdue dot edu 2007-05-23 23:11 --- I believe you need to add BOOT_LDFLAGS='-Wl,-search_paths_first' to make bootstrap to get it to work. If this fixes bootstrap, then I'll prepare a brief patch to the documentation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32010
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #147 from gdr at cs dot tamu dot edu 2007-05-23 23:42 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: | Of course, Gaby's memory model doesn't allow this optimization either; | we have to worry that a and d are both in some union somewhere. | That's why Gaby's model is so bad from an optimization point of view; it A meta comment: I would highly appreciate if you stopped calling it Gaby's model. It is the *current C++ standard object model*. If you don't like it; that is fine. But, you don't have to like it. (I don't). But, please don't call it Gaby's model. The fact that you don't like it does not suddenly make it not the standard model. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #148 from gdr at cs dot tamu dot edu 2007-05-23 23:50 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: | Gaby's claim, as I understand it, is that writing to a union member, | even through a pointer, rather than directly through the union, is | valid, and activates that part of the union. Yes; that is what the current C++ standard says. C99 tried to fix things with the notion of effective type, but that notion does not fully address the issue and it is not part of C++98 and C++03. What I'm doing is making sure that we all know where (potential existing codes) we are starting from and make sure that we do understand the implications of the changes we would like to make to make optimizers easier. I spent some of my time this afternoon going through this with the original inventor of C++ and trying to see whether we have choice to make things less hard. It is clear to us that, *if* we have a choice -- note *if* we have a choice -- when the aliasing through union should be made appearant; but for the moment, that is hard to formulate correctly and simply (with the constraint of not breaking the existing object model badly). -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #149 from gdr at cs dot tamu dot edu 2007-05-23 23:56 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| --- Comment #140 from mark at codesourcery dot com 2007-05-23 21:07
---
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
| new does not change the dynamic type as it should
|
| rguenth at gcc dot gnu dot org wrote:
|
| quote
| Gaby's claim is that given an arbitrary
| pointer p, saying:
|
| (int *)p = 3;
|
| is the same as saying:
|
| *(new (p) int) = 3;
|
| That makes life for the optimizers much, much harder.
| /quote
|
| I say so as well (that those are the same), but I don't agree that this
| makes life for optimizers much harder.
|
| Placement new is rare; assignments to pointers are everywhere.
Naked placement new may be rare; but, placement new is general are not
rare because of the STL-style containers and algorithms.
|
| Note that the first case does not need to use an explicit cast. In a
| function:
|
| void f(int *p) {
| *p = 3;
| }
|
| under Gaby's interpretation, we cannot be sure that p points to an
| int before this function, so we can't be sure the write to *p
| doesn't clobber memory of other types.
Note that is is a problem only with PODs -- because only those can
appear in unions. That does not help much, but it is a distinction
you have to make when you're considering what the standard says.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #150 from gdr at cs dot tamu dot edu 2007-05-23 23:57 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: | Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement | new does not change the dynamic type as it should | | joseph at codesourcery dot com wrote: | | DR#236 http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_236.htm was | what eventually said for C that you don't need to worry about that; I'd | think the aim should be to get C++ to agree with that ruling. | | Thank you for the pointer. That seems directly on point, and makes C99 | match the existing GCC practice: we don't need to worry that pointers | might point to unions. | | Gaby, would you please forward that to the C++ reflector, so that the | reflector has that information as well? They should be aware that the | model you're proposing is at odds with C99. | Yes, I'll right now. Since I brought upt this issue, Nick MacLaren sent me a note he had circulated about these very issues on C99. It is also being discussed on the -core reflector. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c/32061] New: wrong warning wording
This warning is logically incorrect:
logical '' with non-zero constant will always evaluate as true
should say '... will have no effect'?
Reproduce with
==
/* run: gcc -v -save-temps -Wlogical-op -c xx.c
*/
#define FORCE 1
#define FLAG1
static int func (int resp, int flags)
{
return (resp (FORCE || (FLAG flags)));
}
output
==
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /usr/local/src/gcc/src/gcc-current/configure
--srcdir=/usr/local/src/gcc/src/gcc-current --prefix=/usr/local/gcc-current
--enable-languages=c,c++ --with-mpfr=/usr/local/mpfr --with-gmp=/usr/local/gmp
Thread model: posix
gcc version 4.3.0 20070518 (experimental)
/data2/usr/local/gcc-current-20070519-083055/bin/../libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1
-E -quiet -v -iprefix
/data2/usr/local/gcc-current-20070519-083055/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/
xx.c -mtune=generic -Wlogical-op -fpch-preprocess -o xx.i
ignoring nonexistent directory
/data2/usr/local/gcc-current-20070519-083055/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include
ignoring duplicate directory
/data2/usr/local/gcc-current-20070519-083055/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.0/include
ignoring duplicate directory
/data2/usr/local/gcc-current-20070519-083055/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed
ignoring nonexistent directory
/data2/usr/local/gcc-current-20070519-083055/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/data2/usr/local/gcc-current-20070519-083055/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include
/data2/usr/local/gcc-current-20070519-083055/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed
/usr/local/include
/data2/usr/local/gcc-current-20070519-083055/bin/../lib/gcc/../../include
/usr/include
End of search list.
/data2/usr/local/gcc-current-20070519-083055/bin/../libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1
-fpreprocessed xx.i -quiet -dumpbase xx.c -mtune=generic -auxbase xx
-Wlogical-op -version -o xx.s
GNU C version 4.3.0 20070518 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.3.0 20070518 (experimental), GMP version
4.2.1, MPFR version 2.2.1.
warning: GMP header version 4.2.1 differs from library version 4.1.4.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 128b6cbfc01a7daaa897672777a1e4cb
xx.c: In function 'func':
xx.c:7: warning: logical '' with non-zero constant will always evaluate as
true
as -V -Qy -o xx.o xx.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15
--
Summary: wrong warning wording
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eyal at eyal dot emu dot id dot au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32061
[Bug c/32061] wrong warning wording
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-24 00:47 --- I don't see the problem because xx.c:7: warning: logical '' with non-zero constant will always evaluate as true means the non-zero constant will evaluate as true and not the logical will evaluate as true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32061
[Bug other/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-24 00:53 --- Subject: Re: limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure This test runs fine on my IA64 HP-UX and Linux boxes and on my HPPA HP-UX boxes where I have increased the stack size. If I change the test case to do more nesting, I can get it to fail. For the record, these are the limits on the machine where I saw the failure: -bash-2.05b$ ulimit -a core file size(blocks, -c) 2097151 data seg size (kbytes, -d) 786432 file size (blocks, -f) unlimited max memory size (kbytes, -m) unlimited open files(-n) 256 pipe size (512 bytes, -p) 16 stack size(kbytes, -s) 16384 cpu time (seconds, -t) unlimited max user processes(-u) 76 virtual memory(kbytes, -v) unlimited I believe the stack size limit is double the default value. The machine has 7 GB of memory, so I doubt swap is an issue. It's my personal belief that nesting routines to great depths is bad design. It makes debugging nearly impossible. It's possible we are hurt on hppa64 because the argument pointer isn't a fixed register and this prevents the sibcall optimization from occurring. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31827
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #151 from gdr at cs dot tamu dot edu 2007-05-24 00:58 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
rguenther at suse dot de [EMAIL PROTECTED] writes:
[...]
| Gaby's model says that we know less about dynamic types than we
| presently think we do, because there might be a union out there
| somewhere. (Fortunately, as Joseph points out, C99 has already answered
| this question. Surely we can agree that making C99 and C++ different in
| this respect is a bad idea.)
|
| I don't think dragging in unions helps us here ;) Maybe Gaby can clarify
| if and how unions relate here, but I didn't percieve any previous comment
| as making implicit unions relevant here apart from what GCC and
| apperantly C99 agree to.
I believe we all agree that placement new changes the dynamic type.
I brought in the union example to point of a fundamental problem with
this issue. I have been following the discussion without saying much,
until I realized that the interpretation Mark was offering is a
redefinition of the C++ object model that conflicts with the current
standard text. That was the point of the union example. In the
example
void f(int* p, double* q) {
*p = 42;
*q = 3.12;
}
All we know is that after the store to *p, the object there will have
type int (if it did not already have one). Similarly, for the store
to *q, the object there will have type double. Can the stores be
rearranged? Under the current C++ rules (which were inherited from
C90, and not C99) yes if we know that the objects are distinct.
Can we infer the disjoinctness from the types? Not always under
current C++ rules for union, and in this specific case, the answer is
no.
I never said I liked that model. I was merely pointing out that
people where on the slope of redefining the object model.
I spent the afternoon trying to see how C++ can move forward.
The effective types of C99 has its own sets of incompleteness and
inconsistency problems that Nick MacLaren has brought to my attention
since I raised the issue on the C++ -core reflector.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c/32061] wrong warning wording
--- Comment #2 from eyal at eyal dot emu dot id dot au 2007-05-24 01:00 --- (In reply to comment #1) I don't see the problem because xx.c:7: warning: logical '' with non-zero constant will always evaluate as true means the non-zero constant will evaluate as true and not the logical will evaluate as true. (In reply to comment #1) I don't see the problem because xx.c:7: warning: logical '' with non-zero constant will always evaluate as true means the non-zero constant will evaluate as true and not the logical will evaluate as true. But it says 'logical... will always evaluate as true' which clearly refers to the result of the logical operator, not to one of its arguments. BTW, why no warning for this? resp == 0 0 Naturally, all the above constants will hide behind some macros which could indicate a real error, hence the value of the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32061
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #152 from gdr at cs dot tamu dot edu 2007-05-24 01:06 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should mark at codesourcery dot com [EMAIL PROTECTED] writes: [...] | However, I don't like this approach because I believe it will result in | inferior code. I believe (without offering data, sorry) it *may* yield inferior code. However, my original point was to make sure that we understood your interpretation was a change to the C++ standard object model. Given the consequences, I think it was appropriate to raise the issue to the C++ committee. So far, the only response I got was the sentiment that it is a change in semantics. Given C99's move, it is essential for C++ to get to a better state of the object model. However, C99's notion of effective type is not without its own set of problems (already in C99). The details can be found in Nick MacLaren's paper. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug testsuite/32062] New: gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
I have 4.3.0 SVN 20070523 and just updated it a minute ago to revision 125011. I ran make -i check and noticed a number of UNSUPPORTED in the C tests. # grep -B 5 -A 0 15233 gcc/testsuite/gcc/gcc.log PASS: gcc.target/i386/sse3-movshdup.c execution test Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.target/i386/sse3-movsldup.c -O2 -msse3 -fno-show-column -lm -o ./sse3-movsldup.exe(timeout = 300) PASS: gcc.target/i386/sse3-movsldup.c (test for excess errors) Setting LD_LIBRARY_PATH to :/opt/gcc-4_3-build/gcc::/opt/gcc-4_3-build/gcc:/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build/./gcc:/opt/gcc-4_3-build/./prev-gcc PASS: gcc.target/i386/sse3-movsldup.c execution test Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4.1 -fno-show-column -c -o sse4.15233.o sse4.15233.c(timeout = 300) Notice that the test of sse3-movsldup.c uses the path gcc.target/i386/ . Notice that the test of sse4.15233.c uses the path . In addition, the file sse4.15233.c did not exist the other day when I got the SVN _AND_ it still does not exist now when I re-got the SVN a few minutes ago. I checked my HD to see if it was generated, it does not exist. When the compilation of sse4.15233.c fails it causes a number of tests that follow to be ASSUMED (or at least reported) as unsupported. Here are a few: UNSUPPORTED: gcc.target/i386/sse4_1-blendpd.c UNSUPPORTED: gcc.target/i386/sse4_1-blendps.c UNSUPPORTED: gcc.target/i386/sse4_1-blendvpd.c _MY_ test method: # ls -l sse4_1* ls: sse4_1*: No such file or directory # /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4.1 -fno-show-column -c -o sse4_1-blendpd.o /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.target/i386/sse4_1-blendpd.c # /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4.1 -fno-show-column -c -o sse4_1-blendps.o /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.target/i386/sse4_1-blendps.c # /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4.1 -fno-show-column -c -o sse4_1-blendvpd.o /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.target/i386/sse4_1-blendvpd.c : Assembler messages: :187: Error: no such instruction: `blendvpd %xmm0,-1000(%ebx,%ebp),%xmm1' # ls -l sse4_1* -rw-r--r-- 1 root root 1648 May 23 17:38 sse4_1-blendpd.o -rw-r--r-- 1 root root 1664 May 23 17:39 sse4_1-blendps.o So the more correct message would be: PASS: gcc.target/i386/sse4_1-blendpd.c PASS: gcc.target/i386/sse4_1-blendps.c UNSUPPORTED: gcc.target/i386/sse4_1-blendvpd.c The testsuite thinks that the failure of a non-existant file means the rest of the tests won't pass. I'm not an SSE expert but with so many processors types and variables you _might_ need to test for processor capability with a _COORECT_ program. Then use a huge chart that says exactly what is supported by the manufacturer - unless you actually wish to test unsupported but working instructions. Many cpuid programs are not bleading edge and you don't want to keep updating. Keeping a chart is a pain. Using cat /proc/cpuinfo is not reliable. cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 43 ... fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm cmp_legacy ts fid vid ttp I bet you think I have an Opteron, many programs do. There were so many problems with the gcc tests that I'll need to poke around and type make -i check-gcc to re-check gcc only. The other tests are not as bad. It is important that C work as it affects all the other compilers - and thus the results. We need ZERO errors in C (and Ada since it is a first-stager). -- Summary: gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com 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=32062
[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-24 01:56 --- What binutils version do you have? Check via as --version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-24 02:01 --- The check in gcc/gcc/testsuite/gcc.target/i386/i386.exp checks if pabsd128 works, so that means if that does not work, then all the testcases will cause an unsupported. This is not really a bug, as the unsupported test means it is not supported on your configuration which is true (too of a fine checking is just causes more problems than it solves). -- 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=32062
[Bug fortran/32059] include directives don't work with absolute pathnames
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-24 02:17 --- *** This bug has been marked as a duplicate of 30276 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32059
[Bug fortran/30276] gfortran include problem
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-05-24 02:17 --- *** Bug 32059 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Catherine dot M dot Moroney ||at jpl dot nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30276
[Bug fortran/30276] gfortran include problem
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.1 4.2.0 4.3.0 |4.1.1 Known to work||4.2.0 4.3.0 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30276
[Bug java/32010] bootstrap fails; chooses wrong zlib for building jc1
--- Comment #2 from lucier at math dot purdue dot edu 2007-05-24 02:19 --- My guess was correct, but I don't see where to put the note in the documentation. Perhaps I'll ask Jack to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32010
[Bug c++/32058] invalid computed void parameter in template
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-24 02:56 --- GCC is correct, this code is invalid C++. See PR 9278. *** This bug has been marked as a duplicate of 9278 *** -- 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=32058
[Bug c++/9278] Illegal use of typedef to void
--- Comment #26 from pinskia at gcc dot gnu dot org 2007-05-24 02:56 --- *** Bug 32058 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||paul_m_doc at hotmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9278
[Bug c++/32042] linkage confused with scope?
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-24 03:11 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Known to fail||4.3.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2007-05-24 03:11:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32042
[Bug c++/32029] Internal Compiler Error on instantiation of template parameter
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-24 03:18 ---
Here is a reduced testcase:
templateclass Base
struct Factory0Arg
{
templateclass T struct Factory { };
};
templateclass T, class Al=class Factory0ArgT::FactoryT
struct thing {
Al allocator;
};
thingint t;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32029
[Bug testsuite/32063] New: contrib/test_summary script could output results more neatly
This affects any HTB triplet if the person runs the contrib/test_summary script. The script creates results that are not pretty-printed and mails them to [EMAIL PROTECTED] which automatically generates ugly web pages. We might improved the line spacing in the mailer script, here is an example: ---START--- /opt/gcc-4_3-build/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070523 (experimental) === gnat tests === Running target unix FAIL: gnat.dg/address_conversion.adb execution test === gnat Summary === # of expected passes168 # of unexpected failures1 === obj-c++ tests === Running target unix --- END --- I suggest it would look better if it were like this: ---START--- /opt/gcc-4_3-build/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070523 (experimental) (Add a blank line here) === gnat tests === (Subtract a blank line here) Running target unix FAIL: gnat.dg/address_conversion.adb execution test === gnat Summary === # of expected passes168 # of unexpected failures1 (Add a blank line here) (Add a blank line here) === obj-c++ tests === (Subtract a blank line here) Running target unix --- END --- That is only a dozen line example. The _whole_ output is like that; with extra C/R's where they are not needed and too few C/R's in some spots. I realize that the output is supposed to be machine readable, so is our ource code. We have _standards_ for the appearance of the source, why not the output. While this is trivial we should have pride in our great compiler and the usually great results. Even if there are failures we should still present them neatly. See here for many examples: http://gcc.gnu.org/ml/gcc-testresults/2007-05/ -- Summary: contrib/test_summary script could output results more neatly Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32063
[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
--- Comment #3 from rob1weld at aol dot com 2007-05-24 04:39 --- # as --version GNU assembler 2.17 Debian GNU/Linux That is the _newest_ apt-get from Debian. My test results are here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01171.html This is not really a bug, as the unsupported test means it is not supported on your configuration which is true (too of a fine checking is just causes more problems than it solves). You know I am big fan of everything ON, and working ;) It seems a shame that the test works when ran manually but that the automated mechanism is not going to be too fine grained. Another interesting command to run is this: # grep -B 5 -A 5 Assembler\ messages gcc/testsuite/gcc/gcc.log Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.target/i386/sse3-movsldup.c -O2 -msse3 -fno-show-column -lm -o ./sse3-movsldup.exe(timeout = 300) PASS: gcc.target/i386/sse3-movsldup.c (test for excess errors) Setting LD_LIBRARY_PATH to :/opt/gcc-4_3-build/gcc::/opt/gcc-4_3-build/gcc:/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libmudflap/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libssp/.libs:/opt/gcc-4_3-build/i686-pc-linux-gnu/libgomp/.libs:/opt/gcc-4_3-build/./gcc:/opt/gcc-4_3-build/./prev-gcc PASS: gcc.target/i386/sse3-movsldup.c execution test Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4.1 -fno-show-column -c -o sse4.125141.o sse4.125141.c(timeout = 300) /tmp/ccKqTs3N.s: Assembler messages: /tmp/ccKqTs3N.s:8: Error: no such instruction: `pmulld %xmm1,%xmm0' compiler exited with status 1 output is: /tmp/ccKqTs3N.s: Assembler messages: /tmp/ccKqTs3N.s:8: Error: no such instruction: `pmulld %xmm1,%xmm0' UNSUPPORTED: gcc.target/i386/sse4_1-blendpd.c UNSUPPORTED: gcc.target/i386/sse4_1-blendps.c UNSUPPORTED: gcc.target/i386/sse4_1-blendvpd.c -- UNSUPPORTED: gcc.target/i386/sse4_1-roundss-1.c UNSUPPORTED: gcc.target/i386/sse4_1-roundss-2.c UNSUPPORTED: gcc.target/i386/sse4_1-roundss-3.c UNSUPPORTED: gcc.target/i386/sse4_1-roundss-4.c Executing on host: /opt/gcc-4_3-build/gcc/xgcc -B/opt/gcc-4_3-build/gcc/ -O2 -msse4a -fno-show-column -c -o sse4a25141.o sse4a25141.c(timeout = 300) /tmp/ccMwoETb.s: Assembler messages: /tmp/ccMwoETb.s:8: Error: no such instruction: `insertq %xmm1,%xmm0' compiler exited with status 1 output is: /tmp/ccMwoETb.s: Assembler messages: /tmp/ccMwoETb.s:8: Error: no such instruction: `insertq %xmm1,%xmm0' UNSUPPORTED: gcc.target/i386/sse4a-extract.c UNSUPPORTED: gcc.target/i386/sse4a-insert.c UNSUPPORTED: gcc.target/i386/sse4a-montsd.c Even though the assembler does not support _some_ instructions I can manually compile _some_ of the test programs. I guess ./configure must test as . It is not the fault of the (average) user if they have the newest apt-get of Debian GNU/Linux and something is broken. I am not average and I would be more than happy to compile binutils. I would want to use the same ./configure flags so I don't screw my as .(TM) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes UNSUPPORTED for working tests
--- Comment #4 from rob1weld at aol dot com 2007-05-24 06:01 ---
According to this page: http://www.gnu.org/software/binutils/
The newest version is being called binutils-2.17.50 (name for snapshot).
ftp://sourceware.org/pub/binutils/snapshots/
05/17/2006 12:00AM 13,716,872 binutils-2.16.93.tar.bz2
06/12/2006 12:00AM 13,814,217 binutils-2.16.94.tar.bz2
05/22/2007 05:47AM 14,958,122 binutils-2.17.50.tar.bz2
The best solution for Debian _might_ be:
cvs -z 9 -d :pserver:[EMAIL PROTECTED]:/cvs/src login
{enter anoncvs as the password}
cvs -z 9 -d :pserver:[EMAIL PROTECTED]:/cvs/src co binutils
and then go here: http://packages.debian.org/unstable/source/binutils and apply
http://ftp.debian.org/debian/pool/main/b/binutils/binutils_2.17cvs20070426-5.diff.gz
- making sure not to _undo_ anything, just planning to get the Debian'isms and
GNU/Linix'ishness .
After I do this it can not be my fault, correct ?
Do you have better advice?
I maintain that this should not be neccesary. It is like this for a lot of
parts of GCC, requiring bleeding edge (Like GTK libs). I can do it and don't
mind but it reduces the number of people who can do everything and increases
tech-support / bug reports.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062
[Bug fortran/31716] segfault with real array bounds
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-05-24 06:04 --- Subject: Bug 31716 Author: jvdelisle Date: Thu May 24 05:03:51 2007 New Revision: 125013 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125013 Log: 2007-05-23 Jerry DeLisle [EMAIL PROTECTED] PR fortran/31716 * array.c (spec_dimen_size): Test for correct BT_INTEGER type. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31716
[Bug bootstrap/30341] Makefile using mv instead of ln not working on WinXP Cygwin Bash
--- Comment #4 from rob1weld at aol dot com 2007-05-24 06:05 --- I have found that with very low system load that it _can_ occur using an XTerm window afterall - infrequently. If your compiling for Cygwin it is best to make the mod to the Makefile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30341
[Bug fortran/31716] segfault with real array bounds
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-05-24 06:05 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31716
