[Bug target/17390] missing floating point compare optimization
--- Comment #14 from ubizjak at gmail dot com 2007-08-23 08:33 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01513.html. This is target-only patch that fakes fcomi instructions. It doesn't need to rescan insn stream and creates the same output as in Comment #8. It also doesn't ice for the testcase in Comment #10. -- ubizjak at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2005- |patches/2007- |10/msg01298.html|08/msg01513.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
[Bug tree-optimization/33154] FAIL: gcc.c-torture/execute/20010119-1.c compilation, -Os
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-23 08:56 --- Indeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33154
[Bug c++/33156] preprocessor precedence of string concatenation backwards?
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-23 09:33 --- IIRC # processing happens first before string concatenation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
maybe bug regarding intptr_t and NULL
Hi GCC people,
the following code gives me a warning when compiling
(on an IA32 host).
~/c/tests 37> cat intptr.cpp
#include "stdint.h"
#include "stdlib.h"
int main(void)
{
intptr_t t = 0;
if (t != ((intptr_t)NULL)) t = 1;
return 0;
}
lnxsodt25 ~/c/tests 38> g++ --version
g++ (GCC) 4.2.1
lnxsodt25 ~/c/tests 39> g++ -c intptr.cpp
intptr.cpp: In function 'int main()':
intptr.cpp:7: warning: NULL used in arithmetic
If I use uintptr_t, gcc gives no warning.
After reading cp/typeck.c around build_binary_op
and knowing that NULL is in fact null_node
with type integer (integer_type_node I think),
I guess that the cast is removed in some way
so that build_binary_op produces a warning
believing I pass NULL as is, without the cast.
Of course I could use uintptr_t and everything
would be fine, but it's not my own code.
Or I might also misunderstand something
in there in which case I apologize for this
email.
Take care,
and keep on the good work on this great compiler.
Cedric.
[Bug rtl-optimization/32557] [4.3 Regression] internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:956
--- Comment #10 from bonzini at gnu dot org 2007-08-23 10:18 --- fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32557
[Bug fortran/33095] MAX with optional arguments gives run-time error
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-23 10:22 --- Subject: Bug 33095 Author: fxcoudert Date: Thu Aug 23 10:22:18 2007 New Revision: 127732 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127732 Log: PR fortran/33095 * trans-intrinsic.c (gfc_conv_intrinsic_minmax): Remove runtime error checking. * gfortran.dg/min_max_optional_5.f90: New test. * gfortran.dg/min_max_optional_2.f90: Remove. * gfortran.dg/min_max_optional_3.f90: Remove. * gfortran.dg/min_max_optional_4.f90: Remove. Added: trunk/gcc/testsuite/gfortran.dg/min_max_optional_5.f90 Removed: trunk/gcc/testsuite/gfortran.dg/min_max_optional_2.f90 trunk/gcc/testsuite/gfortran.dg/min_max_optional_3.f90 trunk/gcc/testsuite/gfortran.dg/min_max_optional_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33095
[Bug fortran/33095] MAX with optional arguments gives run-time error
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-23 10:22 --- 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=33095
[Bug middle-end/33157] New: [4.3 Regression] cmov4.c fails on i686
The failure was not detected because of an incorrect scan-assembler pattern. -- Summary: [4.3 Regression] cmov4.c fails on i686 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
[Bug tree-optimization/33158] New: missed store sinking opportunity
In gcc.target/i386/cmov4.c no store sinking is performed for this code
for (i = 0; i < ARCHnodes; i++) {
nodekind[i] = (int) nodekindf[i];
if (nodekind[i] == 3)
nodekind[i] = 1;
}
I would expect it to be rewritten as
for (i = 0; i < ARCHnodes; i++) {
int x = (int) nodekindf[i];
if (x == 3)
x = 1;
nodekind[i] = x;
}
--
Summary: missed store sinking opportunity
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 33157
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33158
[Bug tree-optimization/33159] New: [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
The testcase looks like this:
int *nodekind;
float *nodekindf;
...
for (i = 0; i < ARCHnodes; i++) {
nodekind[i] = (int) nodekindf[i]; /* <<< */
if (nodekind[i] == 3)
nodekind[i] = 1;
}
In the marked statement, the nodekind variable gets a new VDEF, which is wrong:
D.2012_13 = (int) D.2011_12;
# ARCHnodes_36 = VDEF
# nodekind_37 = VDEF
# nodekindf_38 = VDEF
# SMT.8_39 = VDEF
*D.2008_7 = D.2012_13;
--
Summary: [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 33158
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33159
[Bug tree-optimization/33158] missed store sinking opportunity
-- bonzini at gnu dot org changed: What|Removed |Added BugsThisDependsOn|33159 | Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-23 10:27:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33158
[Bug middle-end/33157] [4.3 Regression] cmov4.c fails on i686
-- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-23 10:28:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
[Bug middle-end/33157] [4.3 Regression] cmov4.c fails on i686
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||i?86-*-* Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
[Bug c++/33160] New: wrong "NULL used in arithmetic" warning
typedef int __attribute__((mode(pointer))) intptr_t;
int main(void)
{
intptr_t t = 0;
if (t != ((intptr_t)__null)) t = 1;
return 0;
}
sss.cc: In function 'int main()':
sss.cc:5: warning: NULL used in arithmetic
--
Summary: wrong "NULL used in arithmetic" warning
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33160
[Bug c++/33160] wrong "NULL used in arithmetic" warning
-- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.3 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-08-23 10:46:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33160
[Bug c/30428] vector float | vector float is accepted
--- Comment #6 from tbptbp at gmail dot com 2007-08-23 11:01 --- (In reply to comment #5) > Fixed. Please fix the extension documentation accordingly. -- tbptbp at gmail dot com changed: What|Removed |Added CC||tbptbp at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30428
[Bug c++/33161] New: Undefined symbols at link for referenced static const data member
Compiling the following program, with "g++ A.cpp" fails to link
with the following error message :
/tmp/ccehheUK.o:(.rodata+0x0): undefined reference to `A::x'
collect2: ld returned 1 exit status
struct A {
static const int x = 0;
};
const int & i = A::x;
int main() {}
It can be reproduced with g++ versions ranging from 3.2 to 4.3,
on Linux and Darwin.
Note that changing one "int" to "unsigned" makes it pass.
Is this really expected to fail ?
--
Summary: Undefined symbols at link for referenced static const
data member
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33161
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #16 from jakub at gcc dot gnu dot org 2007-08-23 12:13 ---
But doesn't ipa_type_escape_field_does_not_clobber_p do what is documented?
At least for the uses in nonoverlapping_memrefs_p where
ipa_type_escape_field_does_not_clobber_p is always called on some field, first
argument is a DECL_FIELD_CONTEXT of some field ans second argument is its type.
Then IMHO ipa_type_escape_field_does_not_clobber_p does the right thing.
If you take address of the whole struct rather than some specific field and
that address doesn't escape the CU, then that still doesn't explain how
could a pointer var with first field's type point to the struct. Say for
struct A { int i; float f; } you still need (int *) ptrA where ptrA is
struct A *, or &ptrA->i. Optimizations before ipa-type-escape will transform
the former to the latter and if they don't, I believe check_cast will handle
it anyway. The only problem in alias.c might be if exprx is COMPONENT_REF
of the first field and expry is a var pointer to the whole struct A (or vice
versa), then any taking of address of the whole struct anywhere would mean
the MEMs could overlap. But in that case both MEMs will have different alias
sets, don't they?
The ipa_type_escape_field_does_not_clobber_p call in may_alias_p is very
different though. Here we don't necessarily call it with some record (or
union)
type and a type of one of its fields, but rather with some record type (or
pointer to it, pointer to pointer etc.) and some possibly completely unrelated
other pointer type. Well, because of previous
if (!alias_sets_conflict_p (mem_alias_set, var_alias_set)) return false;
it shouldn't be completely unrelated. In most cases it will actually be the
same
type and that's something ipa_type_escape_field_does_not_clobber_p wasn't
meant to answer. I have instrumented may_alias_p, so that if
ipa_type_escape_field_does_not_clobber_p returned false for reasons other than
!initialized or !ipa_type_escape_type_contained_p, it would abort.
The only testcase in the whole make check-{gcc,g++,gfortran} testsuite
triggering this was gcc.c-torture/execute/builtins/pr22237.c, where var had a
union type which contained ptr's type as one of its subfields.
The whole use of ipa_type_escape_field_does_not_clobber_p in may_alias_p
is very much unclear to me.
E.g.:
else if (ptr_star_count == 0)
{
/* If PTR_TYPE was not really a pointer to type, it cannot
alias. */
alias_stats.structnoaddress_queries++;
alias_stats.structnoaddress_resolved++;
alias_stats.alias_noalias++;
return false;
}
Isn't ptr guaranteed to be have POINTER_TYPE or REFERENCE_TYPE? Both from the
way how is ->pointers array populated and e.g. that PTR_IS_REF_ALL is used
before may_alias_p on the p_map->var resp. p_map1->var? That implies
ptr_star_count > 0, so the above listed chunk is never executed. Also, as
we don't care in the code whether ptr_star_count is 37 or just 1, I don't see
the point in computing ptr_star_count at all, nor the existence of ptr_type
variable.
If ipa_type_escape_star_count_of_interesting_type (var_type) > 0 (i.e. var is
a pointer to struct/union rather than struct/union itself, how is the fact that
something took address of fields within the struct itself relevant to whether
some pointer may point to the pointer var or not? If
ipa_type_escape_star_count_of_interesting_type (var_type) == 0, then
ipa_type_escape_field_does_not_clobber_p call would make sense if ptr was
a pointer to some field (field of field etc.), but then it needs to be called
with TREE_TYPE (TREE_TYPE (ptr)) as second argument, otherwise it is asking
a wrong question. But if ptr's type is the struct/union itself, all we care is
if that record/union's address has been taken, which is not something
ipa-type-escape won't answer. Isn't that what TREE_ADDRESSABLE can be used
for?
Please explain.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug rtl-optimization/32557] [4.3 Regression] internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:956
--- Comment #11 from rask at gcc dot gnu dot org 2007-08-23 12:18 --- I don't know if it has been fixed on powerpc64-suse-linux-gnu yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32557
[Bug c/32295] [4.1/4.2/4.3 Regression] An invalid c code causes an ICE in create_tmp_var, at gimplify.c:489
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-23 12:38 ---
Another testcase:
extern enum warn overflow;
int
foo (void)
{
return overflow;
}
Here 3.4.x silently compiled it and used SImode for the variable, eventhough
TYPE_SIZE on the enum warn type nor DECL_SIZE on overflow DECL_EXTERNAL
variable
was set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32295
[Bug tree-optimization/32328] [4.2 Regression] -fstrict-aliasing causes skipped code
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-08-23 12:42 --- Subject: Bug 32328 Author: rguenth Date: Thu Aug 23 12:41:59 2007 New Revision: 127736 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127736 Log: 2007-08-23 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/32328 * testsuite/gcc.dg/pr32328.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr32328.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug tree-optimization/32772] [4.3 Regression] error: found real variable when subvariables should have appeared
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-08-23 12:43 --- The testcase is not fixed and you didn't add a testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772
[Bug libfortran/23138] [mingw32] real(16) values are printed incorrectly
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-08-23 13:03 --- Subject: Bug 23138 Author: fxcoudert Date: Thu Aug 23 13:03:35 2007 New Revision: 127739 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127739 Log: PR libfortran/23138 * acinclude.m4 (LIBGFOR_CHECK_MINGW_SNPRINTF): New check. * configure.ac: Use LIBGFOR_CHECK_MINGW_SNPRINTF. * libgfortran.h: If HAVE_MINGW_SNPRINTF is true, use __mingw_snprintf instead of snprintf. * config.h.in: Regenerate. * configure: Regenerate. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/acinclude.m4 trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/libgfortran.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23138
[Bug c++/31941] [4.1/4.2/4.3 Regression] "confused by earlier errors" message without earlier error message
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-23 13:16:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31941
[Bug tree-optimization/33154] FAIL: gcc.c-torture/execute/20010119-1.c compilation, -Os
--- Comment #3 from danglin at gcc dot gnu dot org 2007-08-23 13:25 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33154
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #17 from dberlin at gcc dot gnu dot org 2007-08-23 13:45
---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On 23 Aug 2007 12:13:13 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #16 from jakub at gcc dot gnu dot org 2007-08-23 12:13
> ---
> But doesn't ipa_type_escape_field_does_not_clobber_p do what is documented?
I was there when it was written. It may be documented to do one thing,
but the intent was to do another :)
> At least for the uses in nonoverlapping_memrefs_p where
> ipa_type_escape_field_does_not_clobber_p is always called on some field, first
> argument is a DECL_FIELD_CONTEXT of some field ans second argument is its
> type.
> Then IMHO ipa_type_escape_field_does_not_clobber_p does the right thing.
It doesn't.
> If you take address of the whole struct rather than some specific field and
> that address doesn't escape the CU, then that still doesn't explain how
> could a pointer var with first field's type point to the struct.
> Say for
> struct A { int i; float f; } you still need (int *) ptrA
Uh, no.
&ptrA will do just fine. You can clobber all fields through it if it escapes.
>
> The ipa_type_escape_field_does_not_clobber_p call in may_alias_p is very
> different though. Here we don't necessarily call it with some record (or
> union)
> type and a type of one of its fields, but rather with some record type (or
> pointer to it, pointer to pointer etc.) and some possibly completely unrelated
> other pointer type. Well, because of previous
> if (!alias_sets_conflict_p (mem_alias_set, var_alias_set)) return false;
> it shouldn't be completely unrelated. In most cases it will actually be the
> same
> type and that's something ipa_type_escape_field_does_not_clobber_p wasn't
> meant to answer. I have instrumented may_alias_p, so that if
> ipa_type_escape_field_does_not_clobber_p returned false for reasons other than
> !initialized or !ipa_type_escape_type_contained_p, it would abort.
> The only testcase in the whole make check-{gcc,g++,gfortran} testsuite
> triggering this was gcc.c-torture/execute/builtins/pr22237.c, where var had a
> union type which contained ptr's type as one of its subfields.
>
> The whole use of ipa_type_escape_field_does_not_clobber_p in may_alias_p
> is very much unclear to me.
The whole *point* of ipa_type_escape was to be used in may_alias_p.
The use in alias.c was actually an afterthought.
> E.g.:
> else if (ptr_star_count == 0)
> {
> /* If PTR_TYPE was not really a pointer to type, it cannot
> alias. */
> alias_stats.structnoaddress_queries++;
> alias_stats.structnoaddress_resolved++;
> alias_stats.alias_noalias++;
> return false;
> }
> Isn't ptr guaranteed to be have POINTER_TYPE or REFERENCE_TYPE?
yes.
> Both from the
> way how is ->pointers array populated and e.g. that PTR_IS_REF_ALL is used
> before may_alias_p on the p_map->var resp. p_map1->var? That implies
> ptr_star_count > 0, so the above listed chunk is never executed.
Also true.
> Also, as
> we don't care in the code whether ptr_star_count is 37 or just 1, I don't see
> the point in computing ptr_star_count at all, nor the existence of ptr_type
> variable.
>
> If ipa_type_escape_star_count_of_interesting_type (var_type) > 0 (i.e. var is
> a pointer to struct/union rather than struct/union itself, how is the fact
> that
> something took address of fields within the struct itself relevant to whether
> some pointer may point to the pointer var or not?
If the address was never taken anywhere, it can't be pointed to.
Type-escape tries to go a little further, and see if, when the address
of a field is taken, if that address is ever cast'd,
incremented/decremented, or escapes. If not, then only that field is
clobbbered, not the entire structure. Otherwise, it is equivalent to
calculating TREE_ADDRESSABLE.
The other part of type-escape was to see if the address ever actually
escapes the CU, because if it does not, it could be transformed by
struct-reorg.
> If
> ipa_type_escape_star_count_of_interesting_type (var_type) == 0, then
> ipa_type_escape_field_does_not_clobber_p call would make sense if ptr was
> a pointer to some field (field of field etc.), but then it needs to be called
> with TREE_TYPE (TREE_TYPE (ptr)) as second argument, otherwise it is asking
> a wrong question.
Also possible. Kenny is not always good at knowing the intricacies of
our compiler.
> Please explain.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug tree-optimization/32772] [4.3 Regression] error: found real variable when subvariables should have appeared
--- Comment #11 from dberlin at gcc dot gnu dot org 2007-08-23 13:45 --- It did not fail for me at the point i committed the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772
[Bug tree-optimization/33159] [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-08-23 13:48 --- I'm not sure what you are talking about. Do you mean nodekindf? Do you have a case i can compile on another platform? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33159
[Bug tree-optimization/33159] [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
--- Comment #2 from bonzini at gnu dot org 2007-08-23 13:55 --- The testcase is cross-platform (at least as far as this PR and PR33158 are concerned). Of the four VDEFs, only the ones for SMT.8 and ARCHnodes seem correct to me. The "int" assignment should not cause aliasing for either the nodekind global (an "int *") or nodekindf (a "float *"). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33159
[Bug tree-optimization/33159] [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-08-23 14:01 --- Subject: Re: [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c On 23 Aug 2007 13:55:21 -, bonzini at gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #2 from bonzini at gnu dot org 2007-08-23 13:55 --- > The testcase is cross-platform (at least as far as this PR and PR33158 are > concerned). > > Of the four VDEFs, only the ones for SMT.8 and ARCHnodes seem correct to me. > The "int" assignment should not cause aliasing for either the nodekind global > (an "int *") or nodekindf (a "float *"). Uh, it's a store into an int *. Thus it could touch nodekind. nodekindf it can't, and i'll see what is up there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33159
[Bug tree-optimization/33159] [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
--- Comment #4 from bonzini at gnu dot org 2007-08-23 14:04 --- Hmmm, a store into an "int *" could not touch nodekind itself, only a store into an "int **" could. Isn't SMT.8 the VDEF saying it could touch *the thing pointed to by nodekind*? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33159
[Bug tree-optimization/33159] [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-08-23 14:05 --- Subject: Re: [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c On 8/23/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 23 Aug 2007 13:55:21 -, bonzini at gnu dot org > <[EMAIL PROTECTED]> wrote: > > > > > > --- Comment #2 from bonzini at gnu dot org 2007-08-23 13:55 --- > > The testcase is cross-platform (at least as far as this PR and PR33158 are > > concerned). > > > > Of the four VDEFs, only the ones for SMT.8 and ARCHnodes seem correct to me. > > The "int" assignment should not cause aliasing for either the nodekind > > global > > (an "int *") or nodekindf (a "float *"). > > Uh, it's a store into an int *. > Thus it could touch nodekind. > nodekindf it can't, and i'll see what is up there. > On my platform, i get # ARCHnodes_33 = VDEF # SMT.8_34 = VDEF *D.1997_7 = D.2001_13; Which seems to be what you wanted. I'm not sure what you are testing on, or what version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33159
Re: [Bug tree-optimization/33159] [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
Yes, you are right. I wasn't thinking clearly > --- Comment #4 from bonzini at gnu dot org 2007-08-23 14:04 --- > Hmmm, a store into an "int *" could not touch nodekind itself, only a store > into an "int **" could. > > Isn't SMT.8 the VDEF saying it could touch *the thing pointed to by nodekind*? >
[Bug tree-optimization/33159] [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-08-23 14:09 --- Subject: Re: [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c Yes, you are right. I wasn't thinking clearly > --- Comment #4 from bonzini at gnu dot org 2007-08-23 14:04 --- > Hmmm, a store into an "int *" could not touch nodekind itself, only a store > into an "int **" could. > > Isn't SMT.8 the VDEF saying it could touch *the thing pointed to by nodekind*? > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33159
[Bug middle-end/20644] bogus uninitialized warning on unused variable
--- Comment #9 from manu at gcc dot gnu dot org 2007-08-23 14:17 ---
(In reply to comment #8)
> Despite what I said before, for this particular case, we should never give a
> "is used" warning if the BB is not executed with 100% probability. Hmm, I'll
> check whether we can detect this.
We could avoid the warning by doing the following:
--- gcc/tree-ssa.c (revision 126606)
+++ gcc/tree-ssa.c (working copy)
@@ -1302,8 +1334,11 @@
}
}
static unsigned int
execute_early_warn_uninitialized (void)
{
block_stmt_iterator bsi;
basic_block bb;
FOR_EACH_BB (bb)
-for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
- {
- tree context = bsi_stmt (bsi);
- walk_tree (bsi_stmt_ptr (bsi), warn_uninitialized_var,
- context, NULL);
- }
+{
+ edge e;
+ edge_iterator ei;
+ FOR_EACH_EDGE (e, ei, bb->preds)
+if (e->flags & EDGE_FALLTHRU)
+ {
+for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
+ {
+tree context = bsi_stmt (bsi);
+walk_tree (bsi_stmt_ptr (bsi), warn_uninitialized_var,
+ context, NULL);
+ }
+break;
+ }
+}
I think this is the "Right Thing To Do". Otherwise, we are giving "is used"
warnings for BBs that are conditionally executed. On the other hand, we will
miss a few of the correct warnings that we get by chance by not doing the
"Right Thing".
Comments?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20644
[Bug target/17390] missing floating point compare optimization
--- Comment #15 from uros at gcc dot gnu dot org 2007-08-23 14:23 --- Subject: Bug 17390 Author: uros Date: Thu Aug 23 14:23:40 2007 New Revision: 127742 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127742 Log: PR target/17390 * config/i386/i386.c (ix86_expand_fp_compare): Expand fp comparison to fake fcomi i387 instruction for !TARGET_CMOVE. (ix86_expand_branch): Expand natural sequence with one jump for all targets, not only TARGET_CMOVE. * config/i386/i386.md (*cmpfp_0_cc): New define_insn_and_split pattern to implement fake fcomi sequence. Split instruction after reload to correct compare sequences. (*cmpfp_xf_cc): Ditto. (*cmpfp__cc): Ditto. (*cmpfp_u_cc): Ditto. (*cmpfp__cc): Ditto. testsuite/ChangeLog: PR target/17390 * gcc.target/i386/pr17390.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr17390.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
[Bug target/17390] missing floating point compare optimization
--- Comment #16 from ubizjak at gmail dot com 2007-08-23 14:26 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
[Bug tree-optimization/33159] [4.3 Regression] wrong VDEF for gcc.target/i386/cmov4.c
--- Comment #7 from bonzini at gnu dot org 2007-08-23 14:26 --- -O does not enable strict-aliasing, invalid -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33159
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #8 from ubizjak at gmail dot com 2007-08-23 14:28 --- (In reply to comment #7) > Created an attachment (id=13911) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13911&action=view) [edit] > Updated patch with test case a bug fix. > > I've added a test case of the changes. It did find a bug in the patch and I've > fixed that. I did a full bootstap and C/C++/ObjC dejagnu with top of > 4.2-branch > as of 20070713 and had no problem. Any news with this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #18 from jakub at redhat dot com 2007-08-23 14:49 ---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On Thu, Aug 23, 2007 at 01:45:11PM -, dberlin at dberlin dot org wrote:
> > If you take address of the whole struct rather than some specific field and
> > that address doesn't escape the CU, then that still doesn't explain how
> > could a pointer var with first field's type point to the struct.
>
> > Say for
> > struct A { int i; float f; } you still need (int *) ptrA
>
> Uh, no.
>
> &ptrA will do just fine. You can clobber all fields through it if it escapes.
See "that address doesn't escape the CU" above I wrote. But if so,
it will be in global_types_full_escape and so
ipa_type_escape_field_does_not_clobber_p will return false.
> > If ipa_type_escape_star_count_of_interesting_type (var_type) > 0 (i.e. var
> > is
> > a pointer to struct/union rather than struct/union itself, how is the fact
> > that
> > something took address of fields within the struct itself relevant to
> > whether
> > some pointer may point to the pointer var or not?
>
> If the address was never taken anywhere, it can't be pointed to.
> Type-escape tries to go a little further, and see if, when the address
> of a field is taken, if that address is ever cast'd,
> incremented/decremented, or escapes. If not, then only that field is
> clobbbered, not the entire structure. Otherwise, it is equivalent to
> calculating TREE_ADDRESSABLE.
I was talking about say
struct S { int i; float f; struct S **s1; struct S ***s2; struct S s3; };
struct S ***var;
struct S ptr;
If we are asking whether
may_alias (ptr, get_alias_set (TREE_TYPE (TREE_TYPE (ptr))), var, get_alias_set
(var), false)
then we are only interested in whether var is TREE_ADDRESSABLE,
and this is IMHO exactly the same as asking in case of:
void ***var;
void ptr;
But in the former case ipa_type_escape_star_count_of_interesting_type
(var_type) == 3 and so we will call
ipa_type_escape_field_does_not_clobber_p, in the latter case
not. How are these two different?
In the c#8 testcase this is similar,
ipa_type_escape_star_count_of_interesting_type (var_type) == 1,
we have
struct S *var;
struct S **ptr;
again, why does it matter if *var is a struct or not? What matters
is if var is TREE_ADDRESSABLE, if there is no &var, then it can't
point to it, otherwise it can. The same as for
void *var;
void **ptr;
But if var isn't TREE_ADDRESSABLE, I'd bet nothing ever calls
may_alias_p with it as third argument.
So, do you agree the only case may_alias_p should handle with
ipa_type_escape_field_does_not_clobber_p is
ipa_type_escape_star_count_of_interesting_type (var_type) == 0 ?
Jakub
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug tree-optimization/21596] [4.0/4.1/4.2/4.3 Regression] extra temporaries when using global register variables
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-08-23 16:14 --- So, on the mainline we now generate wrong-code?! -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21596
[Bug fortran/33162] New: Type checking absent for specific names of INTRINSIC functions
Example: print *, dcos(1.0) print *, dcos(1d0) gfortran treats them as it does with "cos()": Any kind of REAL is accepted. However, DCOS is a specific name of COS which only accepts REAL(8). The bug should be fixed such that the following works as well: PROCEDURE(DCOS):: my1 PROCEDURE(COS) :: my2 "MY1" is a function with the interface: interface double precision function my1(x) double precision, intent(in) :: x end function my1 end interface (Note especially also the intent(in) and the dummy argument "x".) "MY1" takes the interface from the specific name of COS: Only REAL(4) is accepted. -- Summary: Type checking absent for specific names of INTRINSIC functions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #9 from dougkwan at google dot com 2007-08-23 16:32 --- Subject: Re: [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations No, FALSE, `(), nil, #f, 0 :) -Doug 23 Aug 2007 14:28:51 -, ubizjak at gmail dot com <[EMAIL PROTECTED]>: > > > --- Comment #8 from ubizjak at gmail dot com 2007-08-23 14:28 --- > (In reply to comment #7) > > Created an attachment (id=13911) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13911&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13911&action=view) [edit] > > Updated patch with test case a bug fix. > > > > I've added a test case of the changes. It did find a bug in the patch and > > I've > > fixed that. I did a full bootstap and C/C++/ObjC dejagnu with top of > > 4.2-branch > > as of 20070713 and had no problem. > > Any news with this patch? > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug c++/33161] Undefined symbols at link for referenced static const data member
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-23 16:34 --- *** This bug has been marked as a duplicate of 30745 *** -- 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=33161
[Bug c++/30745] Undefined static const
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-23 16:34 --- *** Bug 33161 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sylvain dot pion at sophia ||dot inria dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30745
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #19 from dberlin at gcc dot gnu dot org 2007-08-23 17:08
---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On 23 Aug 2007 14:49:43 -, jakub at redhat dot com
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #18 from jakub at redhat dot com 2007-08-23 14:49 ---
> Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
> in loop
>
> On Thu, Aug 23, 2007 at 01:45:11PM -, dberlin at dberlin dot org wrote:
> > > If you take address of the whole struct rather than some specific field
> > > and
> > > that address doesn't escape the CU, then that still doesn't explain how
> > > could a pointer var with first field's type point to the struct.
> >
> > > Say for
> > > struct A { int i; float f; } you still need (int *) ptrA
> >
> > Uh, no.
> >
> > &ptrA will do just fine. You can clobber all fields through it if it
> > escapes.
>
> See "that address doesn't escape the CU" above I wrote. But if so,
> it will be in global_types_full_escape and so
> ipa_type_escape_field_does_not_clobber_p will return false.
>
> > > If ipa_type_escape_star_count_of_interesting_type (var_type) > 0 (i.e.
> > > var is
> > > a pointer to struct/union rather than struct/union itself, how is the
> > > fact that
> > > something took address of fields within the struct itself relevant to
> > > whether
> > > some pointer may point to the pointer var or not?
> >
> > If the address was never taken anywhere, it can't be pointed to.
> > Type-escape tries to go a little further, and see if, when the address
> > of a field is taken, if that address is ever cast'd,
> > incremented/decremented, or escapes. If not, then only that field is
> > clobbbered, not the entire structure. Otherwise, it is equivalent to
> > calculating TREE_ADDRESSABLE.
>
> I was talking about say
> struct S { int i; float f; struct S **s1; struct S ***s2; struct S s3; };
> struct S ***var;
> struct S ptr;
>
> If we are asking whether
> may_alias (ptr, get_alias_set (TREE_TYPE (TREE_TYPE (ptr))), var,
> get_alias_set
> (var), false)
> then we are only interested in whether var is TREE_ADDRESSABLE,
> and this is IMHO exactly the same as asking in case of:
> void ***var;
> void ptr;
>
> But in the former case ipa_type_escape_star_count_of_interesting_type
> (var_type) == 3 and so we will call
> ipa_type_escape_field_does_not_clobber_p, in the latter case
> not. How are these two different?
They aren't.
>
> In the c#8 testcase this is similar,
> ipa_type_escape_star_count_of_interesting_type (var_type) == 1,
> we have
> struct S *var;
> struct S **ptr;
> again, why does it matter if *var is a struct or not? What matters
> is if var is TREE_ADDRESSABLE, if there is no &var, then it can't
> point to it, otherwise it can. The same as for
> void *var;
> void **ptr;
>
> But if var isn't TREE_ADDRESSABLE, I'd bet nothing ever calls
> may_alias_p with it as third argument.
I'm not sure I believe that. We probably still ask for globals anyway.
>
> So, do you agree the only case may_alias_p should handle with
> ipa_type_escape_field_does_not_clobber_p is
> ipa_type_escape_star_count_of_interesting_type (var_type) == 0 ?
Yes
It does look, however, that we should be using
field_does_not_clobber_p during call clobbering computation to avoid
clobbering entire structures when fields are clobbered (if possible).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug c/33163] New: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:700
/usr/local/gcc-4.0.4/bin/h8300-elf-gcc -S -O3 -Wall -msx -fshort-enums -fomit-frame-pointer -finline-functions -funroll-loops -I/home/fgiovagnini/acts/bendia/test/include -I/home/fgiovagnini/acts/bendia/system/include /home/fgiovagnini/acts/bendia/test/source/library.c /home/fgiovagnini/acts/bendia/test/source/library.c: In function ‘ul_to_8_cifre’: /home/fgiovagnini/acts/bendia/test/source/library.c:36: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:700 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: internal compiler error: in gen_rtx_SUBREG, at emit- rtl.c:700 Product: gcc Version: 4.0.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fabio dot giovagnini at aurion-tech dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: h8300-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33163
[Bug c/33163] internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:700
--- Comment #1 from fabio dot giovagnini at aurion-tech dot com 2007-08-23
17:20 ---
const unsigned char Nib_to_Hex[16] =
{0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x41,0x42,0x43,0x44,0x45,0x46};
void ul_to_8_cifre(unsigned char vett[8],unsigned long a1)
{
/* LOCAL VARIABLES */
union _ul {
unsigned long ul;
unsigned char uc[4];
} t;
/* RETURN VALUE */
/* BODY FUNCTION */
t.ul = a1;
vett[0] = Nib_to_Hex[((t.uc[0] & 0xF0) >> 4)];
vett[1] = Nib_to_Hex[((t.uc[0] & 0x0F))];
vett[2] = Nib_to_Hex[((t.uc[1] & 0xF0) >> 4)];
vett[3] = Nib_to_Hex[((t.uc[1] & 0x0F))];
vett[4] = Nib_to_Hex[((t.uc[2] & 0xF0) >> 4)];
vett[5] = Nib_to_Hex[((t.uc[2] & 0x0F))];
vett[6] = Nib_to_Hex[((t.uc[3] & 0xF0) >> 4)];
vett[7] = Nib_to_Hex[((t.uc[3] & 0x0F))];
/* END BODY */
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33163
[Bug fortran/33090] Unable to build on AIX 4.3.3
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2007-08-23 17:24 --- (In reply to comment #1) > Huh? The warnings should be ok. What exact error are you getting because I > don't see -Werror on the command line so the warnings should not be stoping > the > build? Oops. I'll rebuild and post the error. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33090
[Bug c++/33156] preprocessor precedence of string concatenation backwards?
--- Comment #2 from igodard at pacbell dot net 2007-08-23 17:50 --- Whether # is before or after string concatenation, string concatenation should happen *sometime* and doesn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
[Bug target/33164] New: Texinfo markup problems in tm.texi
While writing a script to extract data from tm.texi, found the following markup
bugs:
TARGET_ASM_RELOC_RW_MASK needs return type
TARGET_CC_MODES_COMPATIBLE needs {} around return type
TARGET_CHECK_PCH_TARGET_FLAGS needs {} around return type
TARGET_DEFAULT_TARGET_FLAGS should be @deftypevr
TARGET_GET_PCH_VALIDITY needs {} around return type
TARGET_HAVE_SRODATA_SECTION should be @deftypevr
TARGET_HAVE_TLS should be @deftypevr
TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN needs {} around return type
TARGET_INVALID_WITHIN_DOLOOP needs {} around return type
TARGET_MAX_ANCHOR_OFFSET should be @deftypevr
TARGET_MIN_ANCHOR_OFFSET should be @deftypevr
TARGET_PCH_VALID_P needs {} around return type
TARGET_STRIP_NAME_ENCODING needs {} around return type
TARGET_TERMINATE_DW2_EH_FRAME_INFO should be @deftypevr
TARGET_UNWIND_TABLES_DEFAULT should be @deftypevr
--
Summary: Texinfo markup problems in tm.texi
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kai-gcc-bugs at khms dot westfalen dot de
GCC build triplet: n/a
GCC host triplet: n/a
GCC target triplet: n/a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33164
[Bug c++/33156] preprocessor precedence of string concatenation backwards?
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-23 18:27 ---
(In reply to comment #2)
> Whether # is before or after string concatenation, string concatenation should
> happen *sometime* and doesn't.
Huh? Stringification happens and turns #("a " "b") into "\"a \" \"b\"" so
there is no string concatenation happening after stringification.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
[Bug c/30428] vector float | vector float is accepted
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-23 18:31 --- (In reply to comment #6) > Please fix the extension documentation accordingly. The documentation already says: The operations behave like C++ valarrays. Addition is defined as the addition of the corresponding elements of the operands. So what is "float | float"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30428
[Bug c/30428] vector float | vector float is accepted
--- Comment #8 from tbptbp at gmail dot com 2007-08-23 18:45 --- Subject: Re: vector float | vector float is accepted On 23 Aug 2007 18:31:25 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > --- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-23 18:31 > --- > (In reply to comment #6) > > Please fix the extension documentation accordingly. > > The documentation already says: > The operations behave like C++ valarrays. Addition is defined as the addition > of the corresponding elements of the operands. "All the basic integer types can be used as base types, both as signed and as unsigned: char, short, int, long, long long. In addition, float and double can be used to build floating-point vector types." "Currently, GCC will allow using the following operators on these types: +, -, *, /, unary minus, ^, |, &, ~." Your patch and documentation conflict . Fix either, at your convenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30428
[Bug c/30428] vector float | vector float is accepted
--- Comment #9 from pinskia at gmail dot com 2007-08-23 18:49 --- Subject: Re: vector float | vector float is accepted On 23 Aug 2007 18:45:47 -, tbptbp at gmail dot com <[EMAIL PROTECTED]> wrote: > Your patch and documentation conflict . Fix either, at your convenience. Read the next line. That is where my quote is from. Please read the whole section before commenting. Because in fact before my patch, the documentation did not match the implementation. Now I am going to say this documentation needs help but that is a different issue. Right after my patch, the documentation now follows the implementation. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30428
[Bug c++/33165] New: method name lookup failure in inheritance tree
/*
PROBLEM: name lookup failure in inheritance tree
PLATFORM: HP nx8220 Fedora Core 6
PACKAGES: gcc-4.1.2-13.fc6
PACKAGES: gcc-c++-4.1.2-13.fc6
PACKAGES: libgcc-4.1.2-13.fc6
OUTPUT: g++ -v -o a a.cc
---
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
/usr/libexec/gcc/i386-redhat-linux/4.1.2/cc1plus -quiet -v -D_GNU_SOURCE a.cc
-quiet -dumpbase a.cc -mtune=generic -auxbase a -version -o
/tmp/ccq59QI3.s
ignoring nonexistent directory
"/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/i386-redhat-linux
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/backward
/usr/local/include
/usr/lib/gcc/i386-redhat-linux/4.1.2/include
/usr/include
End of search list.
GNU C++ version 4.1.2 20070626 (Red Hat 4.1.2-13) (i386-redhat-linux)
compiled by GNU C version 4.1.2 20070626 (Red Hat 4.1.2-13).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3a456da196cbee4c75d3822886d8cc8c
- the error message --
a.cc: In function ‘int main(int, char**)’:
a.cc:73: error: no matching function for call to ‘B::f(int)’
a.cc:61: note: candidates are: void B::f(int, int)
*/
// = the source code
#include
// This combination of functions works fine ...
voidg( int x ){ printf("::g(i)\n"); }
voidg( int x, int y ) { printf("::g(i,i)\n"); }
// but ...
class A // A baseclass
{
public:
void f(int x) { printf("A::f(i)\n"); }
};
classB : public A
{
public:
void f(int x, int y) { printf("B::f(i,i)\n"); }
// This method has the same name (f) as the one inherited
// from A, but a different parameter list, so it should be
// distinct (like the global g's above).
};
int main( int argc, char * argv[] )
{
g( 1 ); // expect ::g(i)oke
g( 1, 2 ); // expect ::g(i,i) oke
B b;
b.f( 1 ); // expect A::f(i) oops
// but apparently the compiler can now
// only recognize B::f(i,i)
b.f( 1, 2 );// expect B::f(i,i) oke
return 0;
}
/* expected ouput =
If you rename B::f to B::h you'll get the expected output
::g(i)
::g(i,i)
A::f(i)
B::f(i,i)
To summarize the problem in general:
When a derived class defines a (or more) method(s)
with the same name as a method inherited from a baseclass,
all inherited methods with that name get 'shadowed', even when
they have totally different parameterlists.
*/
--
Summary: method name lookup failure in inheritance tree
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot a dot akkersdijk at saxion dot nl
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33165
[Bug target/33151] Invalid insn with pre_inc
--- Comment #4 from zadeck at naturalbridge dot com 2007-08-23 18:59 --- Subject: Re: Invalid insn with pre_inc pinskia at gcc dot gnu dot org wrote: > --- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-22 22:41 > --- > I think we need a new predicate for this rtl instruction, currently we just > have: >(clobber (match_operand:DF 4 "memory_operand" "=o")) > > > After thinking about this last night, i believe that this problem should be solved at the machine description level, not by changing auto-inc-dec.c. Auto-inc-dec.c uses all of the standard interfaces to keep from generating invalid rtl. So it seems proper to have the md level not allow the creation of this insn. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33151
[Bug c++/33165] method name lookup failure in inheritance tree
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-23 19:00 --- No, this is correct, f in B hides all of f's in A, no matter what argument types of f are in A. You have to add "using A::f;" inside B to get the behavior you want. -- 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=33165
[Bug bootstrap/32272] make exit because build/genmodes.exe doesn't exist
--- Comment #2 from mwheeler at pittstate dot edu 2007-08-23 19:06 --- I'm having this exact same problem. I'm building on AIX 5.3. My output looks almost exactly the same as the other posters. My only configure option was: --prefix=/usr/local Here is the output: make[3]: Entering directory `/scratch/gcc-4.2.1/gcc-obj/gcc' TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="USE_COLLECT2" \ /bin/sh ../../gcc-4.2.1/gcc/mkconfig.sh config.h TARGET_CPU_DEFAULT="" \ HEADERS="options.h config/rs6000/rs6000.h config/rs6000/aix.h config/rs6000/aix52.h config/rs6000/xcoff.h defaults.h" DEFINES="" \ /bin/sh ../../gcc-4.2.1/gcc/mkconfig.sh tm.h nawk -f ../../gcc-4.2.1/gcc/opt-gather.awk ../../gcc-4.2.1/gcc/ada/lang.opt ../../gcc-4.2.1/gcc/fortran/lang.opt ../../gcc-4.2.1/gcc/java/lang.opt ../../gcc-4.2.1/gcc/treelang/lang.opt ../../gcc-4.2.1/gcc/c.opt ../../gcc-4.2.1/gcc/common.opt ../../gcc-4.2.1/gcc/config/rs6000/rs6000.opt ../../gcc-4.2.1/gcc/config/rs6000/aix64.opt > tmp-optionlist /bin/sh ../../gcc-4.2.1/gcc/../move-if-change tmp-optionlist optionlist echo timestamp > s-options nawk -f ../../gcc-4.2.1/gcc/opt-functions.awk -f ../../gcc-4.2.1/gcc/opth-gen.awk \ < optionlist > tmp-options.h /bin/sh ../../gcc-4.2.1/gcc/../move-if-change tmp-options.h options.h echo timestamp > s-options-h TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/sh ../../gcc-4.2.1/gcc/mkconfig.sh bconfig.h gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.2.1/gcc -I../../gcc-4.2.1/gcc/build -I../../gcc-4.2.1/gcc/../include -I./../intl -I../../gcc-4.2.1/gcc/../libcpp/include -I../../gcc-4.2.1/gcc/../libdecnumber -I../libdecnumber-o build/errors.o ../../gcc-4.2.1/gcc/errors.c build/genmodes -h > tmp-modes.h /bin/sh: build/genmodes: not found. make[3]: *** [s-modes-h] Error 127 make[3]: Leaving directory `/scratch/gcc-4.2.1/gcc-obj/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/scratch/gcc-4.2.1/gcc-obj' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/scratch/gcc-4.2.1/gcc-obj' make: *** [all] Error 2 -- mwheeler at pittstate dot edu changed: What|Removed |Added CC||mwheeler at pittstate dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32272
[Bug c++/33156] preprocessor precedence of string concatenation backwards?
--- Comment #4 from igodard at pacbell dot net 2007-08-23 19:30 --- Ah! I see. So if string cat is after there's only one string, which does contain embedded quotes as printed. And if string cat were before you couldn't compose a string out of a sequence of macro calls and literals. Makes sense, sorry to bother you. -- igodard at pacbell dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33156
[Bug c/30428] vector float | vector float is accepted
--- Comment #10 from tbptbp at gmail dot com 2007-08-23 19:42 --- Subject: Re: vector float | vector float is accepted On 23 Aug 2007 18:49:22 -, pinskia at gmail dot com <[EMAIL PROTECTED]> wrote: > Read the next line. That is where my quote is from. Please read the > whole section before commenting. Because in fact before my patch, the > documentation did not match the implementation. "The operations behave like C++ valarrays. Addition is defined as the addition of the corresponding elements of the operands. For example, in the code below... Subtraction, multiplication, division, and the logical operations operate in a similar manner." It's clearly and explicitly stated that a) float is a legit underlying type b) operators +, -, *, /, unary minus, ^, |, &, ~ are allowed c) all those operators work the same way as the described piecewise addition Do you expect anyone to read into the vague "behave like C++ valarrays" an embargo on "float | float"? I mean, if those vectors are valarrays where is, say, the operator[]? But i understand that under your rather peculiar interpretation everything's fine. I will gladly move along. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30428
[Bug tree-optimization/33166] [4.3 Regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1698
--- Comment #1 from tbm at cyrius dot com 2007-08-23 19:55 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
void ConvertAddr (char *saddr, void **addr)
{
*addr = (void *) &saddr;
}
void DefineSelf (char *addr)
{
int i;
for (i = 0; i < 20; i += 4) {
ConvertAddr (addr, (void **) &addr);
if (addr[0] == 127 && addr[1] == 0 && addr[2] == 0 && addr[3] == 1)
continue;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33166
[Bug tree-optimization/33166] [4.3 Regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1698
--- Comment #2 from tbm at cyrius dot com 2007-08-23 19:58 --- This also happens with 20070720 but not with 20070616. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33166
[Bug tree-optimization/33166] New: [4.3 Regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1698
I get the following ICE with current trunk: (sid)28159:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O3 tightvnc-access.c tightvnc-access.c: In function 'DefineSelf': tightvnc-access.c:8: internal compiler error: in get_indirect_ref_operands, at tree-ssa-operands.c:1698 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: [4.3 Regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1698 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33166
[Bug rtl-optimization/3507] appalling optimisation with sub/cmp on multiple targets
--- Comment #7 from eweddington at cso dot atmel dot com 2007-08-23 20:10 --- Confirmed for AVR. GCC 4.2.1 for avr generates this: foo: /* prologue: frame size=0 */ push r14 push r15 push r16 push r17 /* prologue end (size=4) */ movw r14,r22 movw r16,r24 sub r14,r18 sbc r15,r19 sbc r16,r20 sbc r17,r21 cp r22,r18 cpc r23,r19 cpc r24,r20 cpc r25,r21 brsh .L2 ldi r24,lo8(100) ldi r25,hi8(100) ldi r26,hlo8(100) ldi r27,hhi8(100) add r14,r24 adc r15,r25 adc r16,r26 adc r17,r27 .L2: movw r24,r16 movw r22,r14 /* epilogue: frame size=0 */ pop r17 pop r16 pop r15 pop r14 ret Ideally it should be something like: foo: /* prologue: frame size=0 */ sub r22,r18 sbc r23,r19 sbc r24,r20 sbc r25,r21 brcc .L2 ldi r18,lo8(100) ldi r19,hi8(100) ldi r20,hlo8(100) ldi r21,hhi8(100) add r22,r18 adc r23,r19 adc r24,r20 adc r25,r21 .L2: /* epilogue: frame size=0 */ ret Which is less than half the number of instructions. Changing summary and target fields -- eweddington at cso dot atmel dot com changed: What|Removed |Added GCC target triplet|i386-linux, powerpc-*-* |i386-linux, powerpc-*-*, ||avr-*-* Last reconfirmed|2006-03-05 03:13:08 |2007-08-23 20:10:25 date|| Summary|appalling optimisation with |appalling optimisation with |sub/cmp on i386 |sub/cmp on multiple targets http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507
[Bug target/19684] avr wrong size in asm comment (peephole)
-- eweddington at cso dot atmel dot com changed: What|Removed |Added Severity|normal |minor Priority|P2 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19684
[Bug middle-end/31150] [4.1/4.2/4.3 Regression] Not promoting an whole array to be static const
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-23 20:36 ---
It is unfortunate that gimple can only initialize the whole array, unless
__builtin_memcpy is used. Unfortunately __builtin_memcpy has a different
drawback - the var will be forced to be TREE_ADDRESSABLE even when it otherwise
wouldn't have to be.
So, we have the option to add some flag to count_type_elements etc., so that
they will behave one way for expr.c etc. and one way for the gimplifier - there
it would need to count whole arrays as units if they are initialized from
string
literals, etc.
The other option is IMHO to hint during expansion expand_assignment that
the memory is already cleared by previous var = {} and so it can avoid storing
zeros. Or teach some RTL pass to remove the redundant zero stores. If
the big clear_storage is done through clearing by pieces, DSE will already
handle this to some extent (will remove redundant stores from the big
clear_storage), but if it is done through a special insn (like rep stosb) or
through memset call, nothing will remove it.
While looking at this, I have noticed that a simple
struct A { char c[10]; };
void
foo (void)
{
struct A a = { "abcdefghi" };
baz (&a);
}
void
bar (void)
{
struct A a;
__builtin_strcpy (&a.c[0], "abcdefghi");
baz (&a);
}
is not as efficient as it ought to be in the foo function - while strcpy/memcpy
can and in this case will use store_by_pieces, store_expr will always emit the
string literal to memory and then emit a block move from it to target followed
optionally by clear_storage of the rest of the memory.
I'm testing a patch to improve this ATM.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Comment #15 from eweddington at cso dot atmel dot com 2007-08-23 20:39 --- Closing bug as WORKSFORME based on Bjoern's observations in comment #13. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug tree-optimization/33166] [4.3 Regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1698
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-23 20:59 ---
# VUSE { saddr SMT.6 }
D.2252_6 = *&saddr
This happens in forwprop.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2007-08-23 20:59:20
date||
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33166
[Bug c/33167] New: Hex constant characters with \x escape not parsing correctly
There seems to be a problem with how gcc parses the \x escape sequences. It
doesn't look at just the first 2 hex digits, but will take the right most 2 hex
digits in a string of hex digits.
[Recreate]
---[ SNIP ]-
// test.c
#include
#include
int main() {
char *string = "\x01\x02\x03Bob";
printf("len: %d\n", strlen(string) );
return 1;
}
---[ SNIP ]-
[Compilation options]
gcc -Wall test.c -o test
[Expected Results]
You would expect this to print out "len: 6", but it actually prints out "len:
5" It seems that its parsing the last \x escape as the hex value 0x3B instead
of 2 characters, 0x03 and 'B'.
[Platforms]
I've noticed this problem in gcc 4.1.0 and 4.0.1 (on a mac). Heres more info
on one of the systems I've experiences this on:
gcc (GCC) 4.1.0 (SUSE Linux)
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,java,ada --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp
--enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-multilib
--with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --without-system-libunwind --with-cpu=generic
--host=i586-suse-linux
Thread model: posix
gcc version 4.1.0 (SUSE Linux)
$ uname -a
linux haldol 2.6.16.13-4-default #1 Wed May 3 04:53:23 UTC 2006 i686 athlon
i386 GNU/Linux
--
Summary: Hex constant characters with \x escape not parsing
correctly
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: weston at computer dot org
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33167
[Bug c/33167] Hex constant characters with \x escape not parsing correctly
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-23 21:59 --- No GCC is correct. The standard says: Each octal or hexadecimal escape sequence is the longest sequence of characters that can constitute the escape sequence. So that means the B is going to be taken and be used for the hexadecimal escape sequence. -- 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=33167
[Bug libstdc++/33168] New: GCC Boot failure, building libstc++
This time __please__ follow standard procedures instead of doing it like PR33125/PR33126 where the earlier submission was made a duplicate of a later one . Which then was left unconfirmed for a lengthy period (6+ hours) and never formally closed as resolved leaving the parties hanging. Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix --enable-shared --enable-clocale=gnu --enable-bootstrap --enable-languages=c,c++,fortran --enable-altivec --disable-libssp --disable-decimal-float --disable-libmudflap --disable-nls --disable-werror --disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu --with-system-zlib Thread model: posix gcc version 4.3.0 20070823 (experimental) (GCC) /usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1plus -E -quiet -nostdinc++ -v -I/var/tmp/43/build-140/powerpc-unknown-linux-gnu/libstdc++-v3/include/powerpc-unknown-linux-gnu -I/var/tmp/43/build-140/powerpc-unknown-linux-gnu/libstdc++-v3/include -I/var/tmp/43/gcc-4.3.0/libstdc++-v3/libsupc++ -iprefix /var/tmp/43/build-140/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/ -D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -D_GNU_SOURCE -isystem /usr/powerpc-unknown-linux-gnu/include -isystem /usr/powerpc-unknown-linux-gnu/sys-include ../gcc-4.3.0/libstdc++-v3/src/system_error.cc -mcpu=G4 -std=gnu++0x -Wall -Wextra -Wwrite-strings -Wcast-qual -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -fworking-directory -O2 -fpch-preprocess -o system_error.ii ignoring nonexistent directory "/usr/powerpc-unknown-linux-gnu/include" ignoring nonexistent directory "/usr/powerpc-unknown-linux-gnu/sys-include" ignoring nonexistent directory "/var/tmp/43/build-140/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include" ignoring nonexistent directory "/var/tmp/43/build-140/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed" ignoring nonexistent directory "/var/tmp/43/build-140/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include" ignoring nonexistent directory "/var/tmp/43/build-140/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include" ignoring nonexistent directory "/var/tmp/43/build-140/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed" ignoring nonexistent directory "/var/tmp/43/build-140/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /var/tmp/43/build-140/powerpc-unknown-linux-gnu/libstdc++-v3/include/powerpc-unknown-linux-gnu /var/tmp/43/build-140/powerpc-unknown-linux-gnu/libstdc++-v3/include /var/tmp/43/gcc-4.3.0/libstdc++-v3/libsupc++ /usr/include/libffi /usr/local/include /usr/include End of search list. /usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1plus -fpreprocessed system_error.ii -quiet -dumpbase system_error.cc -mcpu=G4 -auxbase-strip system_error.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -std=gnu++0x -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o system_error.s GNU C++ (GCC) version 4.3.0 20070823 (experimental) (powerpc-unknown-linux-gnu) compiled by GNU C version 4.3.0 20070823 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 91efee225a5243299b9fb0dada305fe7 ../gcc-4.3.0/libstdc++-v3/src/system_error.cc:67: error: std::system_category causes a section type conflict -- Summary: GCC Boot failure, building libstc++ Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michelin60 at gmail dot com GCC build triplet: rs600 GCC host triplet: rs6000 GCC target triplet: rs6000 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
[Bug target/12017] ICE: in spill_failure, at reload1.c:1862 with builtin_apply/builtin_return
--- Comment #12 from eweddington at cso dot atmel dot com 2007-08-23 22:26 --- Seems to be fixed in 4.3 20070817 snapshot. An additional minor patch is needed, not for this bug, but to allow Objective-C to build for the AVR. (It's unknown if Objective-C will actually *work* on the AVR...) --- gcc/config/avr/avr.h.old2007-08-23 15:18:31.015625000 -0600 +++ gcc/config/avr/avr.h2007-08-23 15:19:17.68750 -0600 @@ -53,7 +53,7 @@ extern int avr_mega_p; extern int avr_have_mul_p; extern int avr_asm_only_p; extern int avr_have_movw_lpmx_p; -#ifndef IN_LIBGCC2 +#if !defined(IN_LIBGCC2) && !defined(IN_TARGET_LIBS) extern GTY(()) section *progmem_section; #endif -- eweddington at cso dot atmel dot com changed: What|Removed |Added Known to work||4.3.0 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12017
[Bug libstdc++/33168] GCC Boot failure, building libstc++
--- Comment #1 from michelin60 at gmail dot com 2007-08-23 22:28 --- Created an attachment (id=14097) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14097&action=view) preprocessed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
[Bug c++/33169] New: Compiler generates two different relocs for the same symbol
The compiler generates two different relocs for the same function call, which
causes the linker to get confused.
- Input -
#include "pthread.h"
#include
#include
typedef __gnu_cxx::__pool_alloc > myalloc;
int main() {
std::map, myalloc> y;
pthread_mutex_lock(0);
}
-
build with:
mipsel-linux-g++ -Os -fno-inline -c foo.cc
(No command line flags are required; they don't appear to make a difference,
but the examples here will reflect those above.)
In this code chunk, pthread_mutex_lock is called from two places. The first is
from inside the allocator, the second is directly in main. From the allocator,
a R_MIPS_GOT16/R_MIPS_LO16 reloc is generated. From main(), a R_MIPS_CALL16
reloc is generated.
001c <__gthread_mutex_lock(pthread_mutex_t*)>:
1c: 3c1clui gp,0x0
1c: R_MIPS_HI16 _gp_disp
20: 279caddiu gp,gp,0
20: R_MIPS_LO16 _gp_disp
24: 0399e021addugp,gp,t9
28: 27bdffe0addiu sp,sp,-32
2c: afbf001csw ra,28(sp)
30: afb00018sw s0,24(sp)
34: afbc0010sw gp,16(sp)
38: 8f99lw t9,0(gp)
38: R_MIPS_GOT16.text
3c: 2739addiu t9,t9,0
3c: R_MIPS_LO16 .text
40: 0320f809jalrt9
44: 00808021moves0,a0
48: 1048beqzv0,6c
<__gthread_mutex_lock(pthread_mutex_t*)+0x
50>
4c: 8fbc0010lw gp,16(sp)
50: 8f99lw t9,0(gp)
50: R_MIPS_GOT16pthread_mutex_lock
54: 02002021movea0,s0
58: 8fbf001clw ra,28(sp)
5c: 8fb00018lw s0,24(sp)
60: 2739addiu t9,t9,0
60: R_MIPS_LO16 pthread_mutex_lock
64: 0328jr t9
68: 27bd0020addiu sp,sp,32
6c: 8fbf001clw ra,28(sp)
70: 8fb00018lw s0,24(sp)
74: 03e8jr ra
78: 27bd0020addiu sp,sp,32
00dc :
dc: 3c1clui gp,0x0
dc: R_MIPS_HI16 _gp_disp
e0: 279caddiu gp,gp,0
e0: R_MIPS_LO16 _gp_disp
e4: 0399e021addugp,gp,t9
e8: 27bdffc8addiu sp,sp,-56
ec: afbf0034sw ra,52(sp)
f0: afb00030sw s0,48(sp)
f4: afbc0010sw gp,16(sp)
f8: 8f99lw t9,0(gp)
f8: R_MIPS_CALL16 std::map, __gnu_cxx::__pool_alloc > >::map()
fc: 27b00018addiu s0,sp,24
100: 0320f809jalrt9
104: 02002021movea0,s0
108: 8fbc0010lw gp,16(sp)
10c: 8f99lw t9,0(gp)
10c: R_MIPS_CALL16 pthread_mutex_lock
110: 0320f809jalrt9
114: 2021movea0,zero
118: 8fbc0010lw gp,16(sp)
11c: 8f99lw t9,0(gp)
11c: R_MIPS_CALL16 std::map, __gnu_cxx::__pool_alloc > >::~map()
120: 0320f809jalrt9
124: 02002021movea0,s0
128: 8fbc0010lw gp,16(sp)
12c: 8fbf0034lw ra,52(sp)
130: 8fb00030lw s0,48(sp)
134: 1021movev0,zero
138: 03e8jr ra
13c: 27bd0038addiu sp,sp,56
When the linker sees the R_MIPS_CALL16, it decides that a PLT entry should be
generated for the symbol, and thusly changes its object-modification behavior
for *all* invocations of the function. The R_MIPS_CALL16 relocs are then
linked correctly, but the R_MIPS_GOT16 are linked incorrectly.
This is just as likely a bug in the linker as it is in the compiler, but gcc
4.0.0 (the only other version I have tested) doesn't have this problem. It is
more consistent and generates R_MIPS_CALL16 in both cases. If this is not a
bug in the compiler, I'll report to binutils.
--
Summary: Compiler generates two different relocs for the same
symbol
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: atgraham at gmail dot com
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mipsel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
[Bug c++/31941] [4.1/4.2/4.3 Regression] "confused by earlier errors" message without earlier error message
--- Comment #4 from jakub at gcc dot gnu dot org 2007-08-23 23:23 --- Subject: Bug 31941 Author: jakub Date: Thu Aug 23 23:23:26 2007 New Revision: 127747 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127747 Log: PR c++/31941 * error.c (resolve_virtual_fun_from_obj_type_ref): Handle TARGET_VTABLE_USES_DESCRIPTORS targets properly. * g++.dg/parse/crash37.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/crash37.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31941
[Bug c++/32898] [4.2/4.3 regression] Definition of variable N::i outside namespace N not rejected
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-23 23:27 --- Subject: Bug 32898 Author: jakub Date: Thu Aug 23 23:27:34 2007 New Revision: 127749 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127749 Log: PR c++/32898 * name-lookup.c (set_decl_namespace): lookup_qualified_name failure is error_mark_node rather than NULL_TREE. * pt.c (check_explicit_specialization): Likewise. * g++.dg/lookup/ns3.C: New test. Added: trunk/gcc/testsuite/g++.dg/lookup/ns3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32898
[Bug middle-end/32946] [4.3 Regression] ICE with -fpredictive-commoning in build_classic_dist_vector_1
--- Comment #7 from jakub at gcc dot gnu dot org 2007-08-23 23:30 --- Subject: Bug 32946 Author: jakub Date: Thu Aug 23 23:29:57 2007 New Revision: 127750 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127750 Log: PR tree-optimization/32573 PR middle-end/32946 * tree-data-ref.c (initialize_data_dependence_relation): Clear DDR_SUBSCRIPTS, DDR_DIR_VECTS and DDR_DIST_VECTS at the beginning. (finalize_ddr_dependent): Clear DDR_SUBSCRIPTS after freeing it. (build_classic_dist_vector): Return false rather than true if DDR_ARE_DEPENDENT is non-NULL at the beginning. Return false if either subscript_dependence_tester_1 or build_classic_dist_vector_1 returned false. Don't call save_dist_v before calling build_classic_dist_vector_1. (free_dependence_relation): Don't guard freeing DDR_SUBSCRIPTS with NULL DDR_ARE_DEPENDENT. Also free DDR_DIST_VECTS and/or DDR_DIR_VECTS vectors. * gcc.dg/pr32573.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr32573.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32946
[Bug tree-optimization/32573] [4.3 Regression] ice for legal code with -O3
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-23 23:30 --- Subject: Bug 32573 Author: jakub Date: Thu Aug 23 23:29:57 2007 New Revision: 127750 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127750 Log: PR tree-optimization/32573 PR middle-end/32946 * tree-data-ref.c (initialize_data_dependence_relation): Clear DDR_SUBSCRIPTS, DDR_DIR_VECTS and DDR_DIST_VECTS at the beginning. (finalize_ddr_dependent): Clear DDR_SUBSCRIPTS after freeing it. (build_classic_dist_vector): Return false rather than true if DDR_ARE_DEPENDENT is non-NULL at the beginning. Return false if either subscript_dependence_tester_1 or build_classic_dist_vector_1 returned false. Don't call save_dist_v before calling build_classic_dist_vector_1. (free_dependence_relation): Don't guard freeing DDR_SUBSCRIPTS with NULL DDR_ARE_DEPENDENT. Also free DDR_DIST_VECTS and/or DDR_DIR_VECTS vectors. * gcc.dg/pr32573.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr32573.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32573
[Bug c++/28358] ICE on valide template code using -O1 or -O2, but *not* with -O0 or -O3
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-24 00:24 --- Yes this is a dup of PR 28116. *** This bug has been marked as a duplicate of 28116 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28358
[Bug middle-end/28116] [4.1 Regression] ICE when building konverter with gcc-4.1 with -O3 [RSO]
--- Comment #20 from pinskia at gcc dot gnu dot org 2007-08-24 00:24 --- *** Bug 28358 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||peter dot soetens at fmtc ||dot be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28116
[Bug c++/33169] Compiler generates two different relocs for the same symbol
--- Comment #1 from atgraham at gmail dot com 2007-08-24 00:40 --- This problem is due to the fact that GTHREAD_USE_WEAK is incorrectly defined for this architecture. -- atgraham at gmail dot com changed: What|Removed |Added Component|target |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
[Bug middle-end/33170] New: [4.3 Regression] revision 123223 causes gcc.target/i386/cmov4.c
This patch http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01634.html causes gcc.target/i386/cmov4.c regression. -- Summary: [4.3 Regression] revision 123223 causes gcc.target/i386/cmov4.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33170
[Bug inline-asm/33171] GCC outputs invalid assembly when using -O2
--- Comment #1 from ianw at gelato dot unsw dot edu dot au 2007-08-24 05:04 --- Created an attachment (id=14098) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14098&action=view) -S output with no optimisation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33171
[Bug inline-asm/33171] GCC outputs invalid assembly when using -O2
--- Comment #2 from ianw at gelato dot unsw dot edu dot au 2007-08-24 05:04 --- Created an attachment (id=14099) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14099&action=view) -S output with -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33171
[Bug middle-end/33157] [4.3 Regression] cmov4.c fails on i686
--- Comment #1 from bonzini at gnu dot org 2007-08-24 05:17 --- *** Bug 33170 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
[Bug middle-end/33170] [4.3 Regression] revision 123223 causes gcc.target/i386/cmov4.c
--- Comment #1 from bonzini at gnu dot org 2007-08-24 05:17 --- *** This bug has been marked as a duplicate of 33157 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|[4.3 Regression] revision |[4.3 Regression] revision |123223 causes |123223 causes |gcc.target/i386/cmov4.c |gcc.target/i386/cmov4.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33170
[Bug inline-asm/33171] New: GCC outputs invalid assembly when using -O2
Hi,
The following example, when built with -O2, results in
~$ .gcc -O2 -o test2 ~/test2.c
/tmp/cc6SGh7Z.s: Assembler messages:
/tmp/cc6SGh7Z.s:16: Error: syntax error; found `,' but expected `('
/tmp/cc6SGh7Z.s:16: Error: junk at end of line: `,0'
This code is extracted from libatomic-ops (see http://bugs.debian.org/432654)
and is causing build failures for some powerpc packages.
4.2.1 and SVN don't fully build on my powerpc64 system (fails comparing objects
between stage2->3) but using the partially built stage3 xgcc the same problem
happens.
Thanks!
--- testcase ---
static inline unsigned long
load_acquire(volatile unsigned long *addr)
{
unsigned long result;
__asm__ __volatile__ (
"lwz %0,%1\n"
"cmpw cr7,%0,%0\n"
"bne- cr7,1f\n"
"1: isync\n"
: "=r" (result)
: "m"(*addr) : "memory", "cc");
return result;
}
int
main(int argc, char **argv) {
unsigned long *value, i, res;
res = load_acquire(value + i);
return 0;
}
--- end ---
--
Summary: GCC outputs invalid assembly when using -O2
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ianw at gelato dot unsw dot edu dot au
GCC host triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33171
[Bug middle-end/33157] [4.3 Regression] cmov4.c fails on i686
--- Comment #2 from ubizjak at gmail dot com 2007-08-24 06:04 --- This patch http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01634.html causes gcc.target/i386/cmov4.c regression. -- ubizjak at gmail dot com changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org Keywords|missed-optimization | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
[Bug c++/32567] [4.3 regression] ICE on invalid use of parameter pack
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-24 06:55 --- Subject: Bug 32567 Author: jakub Date: Fri Aug 24 06:54:49 2007 New Revision: 127760 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127760 Log: PR c++/32567 * typeck.c (build_unary_op) : Return error_mark_node right away if build_expr_type_conversion returned it. * g++.dg/parse/crash36.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/crash36.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32567
[Bug middle-end/33157] [4.3 Regression] cmov4.c fails on i686
--- Comment #3 from steven at gcc dot gnu dot org 2007-08-24 06:36 ---
It's not even supposed to pass on i686:
/* { dg-options "-O2 -march=k8" } */
(see
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.target/i386/cmov4.c?revision=127731&view=markup)
Note I'm not even going to look at this. If anyone has a problem with that,
feel free to propose reverting my patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
[Bug middle-end/33157] [4.3 Regression] cmov4.c fails on i686
--- Comment #4 from bonzini at gnu dot org 2007-08-24 06:50 --- It's supposed to pass on K8 in 32-bit mode. It did, and it does not. However, I think reverting the patch is not the right thing to do. Anyway, given Steven's highly constructive remark, I think we can only wait for it to be fixed on the tree level (PR33158). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
[Bug middle-end/33157] [4.3 Regression] cmov4.c fails on i686
--- Comment #5 from bonzini at gnu dot org 2007-08-24 06:57 --- Anyway, it fails on 64-bit mode too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
