[Bug inline-asm/38815] Taking the address of a __thread variable prevents the r0 register from being loaded
--- Comment #3 from steven at gcc dot gnu dot org 2009-03-17 07:20 --- Copying a pseudo to the required register before an __asm__ is not so easy, because at expand time the data flow engine doesn't know anything, it's not even initialized. What you could do, I suppose in cfgexpand.c * before expand_used_vars(), scan the cfun->local_decl list and make a separate list of local register values, say a VEC(tree,heap) local_reg_var_decls * expand local register vars as usual, assigning pseudos to the local var * every time before expanding __asm__, walk the local_reg_var_decls list and shink-wrap the __asm__ with moves from/to the location where the var lives (must be a pseudo, I suppose) to/from the required register -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38815
[Bug c++/39478] New: please improve recursive template instantiation diagnostics
When a template is instantiated and the instantiation requires access to the
instantiated template, the error message is not as helpful as it could/should
be. Consider:
f...@viasko:~/work/test/recursive_instantiation$ cat t.cc
template< typename T >
struct foo
{
typename T::type dummy();
};
template< typename T >
struct bar
{
typedef void type;
foo< bar > p;
};
foo< bar< int > > x;
f...@viasko:~/work/test/recursive_instantiation$ g++ t.cc
t.cc: In instantiation of 'bar':
t.cc:4: instantiated from 'foo >'
t.cc:14: instantiated from here
t.cc:11: error: 'bar::p' has incomplete type
t.cc:3: error: declaration of 'struct foo >'
f...@viasko:~/work/test/recursive_instantiation$
The problem is t.cc:11: error: 'bar::p' has incomplete type - at that point
I hoped for a more helpful message.
--
Summary: please improve recursive template instantiation
diagnostics
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39478
[Bug c++/39475] c++0x type-traits should error out in case of incompleteness
--- Comment #5 from d dot frey at gmx dot de 2009-03-17 07:30 --- (In reply to comment #4) > Maybe Daniel, but this is a completely separate issue. That's why I asked if I should open yet another PR for it :) I've done that now: PR c++/39478 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 07:46 --- Created an attachment (id=17471) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17471&action=view) gcc44-pr39471.patch So this patch instead? C++ will never need non-NULL DECL_NAME on IMPORTED_DECL, as it doesn't have the ability to rename imports like Fortran does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #4 from dodji at gcc dot gnu dot org 2009-03-17 07:54 --- Subject: Re: DW_TAG_imported_module should be used (not DW_TAG_imported_declaration) jakub at gcc dot gnu dot org a écrit : > --- Comment #1 from jakub at gcc dot gnu dot org 2009-03-16 20:55 --- > Created an attachment (id=17469) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17469&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17469&action=view) > gcc44-pr39471.patch > > Untested patch. Dodji, any reason why you started emitting > DW_TAG_imported_declaration for this instead of DW_TAG_imported_module? I think this was just a confusion on my part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #5 from dodji at gcc dot gnu dot org 2009-03-17 07:59 ---
Subject: Re: DW_TAG_imported_module should be used (not
DW_TAG_imported_declaration)
jakub at gcc dot gnu dot org a écrit :
> So this patch instead? C++ will never need non-NULL DECL_NAME on
> IMPORTED_DECL,
> as it doesn't have the ability to rename imports like Fortran does.
Hmmh, I think the non null name there is useful for namespace aliases in
C++, e.g.
namespace A {
int foo;
}
void
f ()
{
namespace B = A;
}
That namespace alias will be represented by a
DW_TAG_imported_declaration which DW_AT_name set to "B" and which
DW_AT_import is set to a reference to namespace A.
FWIW, the DWARF3 spec says at 3.2.3:
"A C++ namespace alias may be represented by an imported declaration
entry with a name attribute whose value is a null-terminated string
containing the alias name as it appears in the source program and an
import attribute whose value is a reference to the applicable original
namespace or namespace extension entry."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #6 from dodji at gcc dot gnu dot org 2009-03-17 08:08 --- Subject: Re: DW_TAG_imported_module should be used (not DW_TAG_imported_declaration) dodji at redhat dot com a écrit : > Hmmh, I think the non null name there is useful for namespace aliases in > C++ Ah, no. We won't be going through the USING_STMT code path in case of namespace aliases, sorry. My last comment was irrelevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
--- Comment #3 from basile at starynkevitch dot net 2009-03-17 08:18 --- I replaced lrand48_r by lrand48... Regarding fopencookie, it could be fixed 1. by using next PPL (0.11) version or 2. by linking some specific PPL file (ppl/interfaces/C/tests/print_to_buffer.cc) Regards -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug fortran/36091] false positive in bounds checking with forall
--- Comment #7 from pault at gcc dot gnu dot org 2009-03-17 08:31 ---
This fixes the PR:
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c(revision 144197)
+++ gcc/fortran/trans-stmt.c(working copy)
@@ -1713,6 +1719,7 @@
/* Use the temporary as the backend_decl. */
new_sym->backend_decl = tse.expr;
+ DECL_ARTIFICIAL (new_sym->backend_decl) = 1;
/* Create a fake symtree for it. */
root = NULL;
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 144197)
+++ gcc/fortran/trans-array.c (working copy)
@@ -2469,7 +2469,7 @@
gfc_conv_expr_type (&indexse, ar->start[n], gfc_array_index_type);
gfc_add_block_to_block (&se->pre, &indexse.pre);
- if (flag_bounds_check)
+ if (flag_bounds_check && !DECL_ARTIFICIAL (se->expr))
{
/* Check array bounds. */
tree cond;
I am sure that this will cause regressions with array dummy arguments but this
is not intended to do anything other than demonstrate the need to mark the
temporaries produced in FORALL blocks. These masquerade as symbols. I suspect
that they should gain a temporary attribute or, alternatively, the condition
above should be a bit more complex.
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|NEW |ASSIGNED
Last reconfirmed|2008-08-08 21:48:30 |2009-03-17 08:31:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-17 08:52 ---
Created an attachment (id=17472)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17472&action=view)
gcc44-local-imported-decl.patch
Incremental patch to emit DW_TAG_imported_declaration DIEs (other than
namespace aliases) in the right lexical blocks.
Possible testcase for gdb:
namespace A
{
int i = 1;
int j = 2;
}
namespace B
{
int k = 3;
}
int k = 13;
void
foo ()
{
using namespace A;
i++;
j++;
k++;
{
using B::k;
k++;
}
}
template
void
bar ()
{
using namespace A;
i++;
j++;
k++;
{
using B::k;
k++;
}
}
int
main ()
{
foo ();
bar<0> ();
bar<6> ();
}
Concerning:
"We won't be going through the USING_STMT code path in case of We won't be
going through the USING_STMT code path in case of namespace aliases, sorry. My
last comment was irrelevant."
we really should be going through USING_STMT or something similar for namespace
aliases as well, see PR37890. Given that namespace aliases are just emitted
using gen_namespace_die, perhaps just adding the NAMESPACE_DECL to BLOCK_VARS
would be sufficient.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug target/39472] Add -mabi=[ms|sysv]
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-03-17 09:43 --- This feature would be fine. But at the moment we are in Stage 4. So it can be implemented on 4.5 and then after 4.4 is reopened merged back. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39472
[Bug debug/39474] DW_AT_location missing for unused variables even at -O0
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-17 09:36 --- Created an attachment (id=17474) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17474&action=view) gcc44-pr39474.patch I disagree. IMHO there is no reason why we should optimize these out at -O0. We don't optimize out already unused global decls at -O0, I think we should treat the local ones the same way. -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39474
[Bug c/39479] strlen() strange behaviour in for()
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-17 09:45 --- Just learn C. strlen return type is size_t, unsigned type, so in the third case you have (assuming size_t is say unsigned long) i <= 0UL - 1, unsigned long comparison, which is evaluated as (unsigned long) i <= -1UL, so it loops forever. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39479
[Bug c/39479] New: strlen() strange behaviour in for()
I've found an strange behaviour with stdio.strlen() function.
Please, see following self-explaining code:
/*
$ gcc --version
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
$ uname -a
Linux alumne-desktop 2.6.24-23-generic #1 SMP Mon Jan 26 00:13:11 UTC 2009 i686
GNU/Linux
*/
#include
#include
#define MAX_PARAULA (10)
int main() {
char paraula[MAX_PARAULA];
int i;
paraula[0]='\0';
int m = strlen(paraula);
for (i = 0; i <= m - 1; i++) {
printf("(option I) should not enter i=%i\n", i);
}
for (i = 0; i < strlen(paraula); i++) {
printf("(option II) should not enter i=%i\n", i);
}
for (i = 0; i <= strlen(paraula) - 1; i++) {
printf("(option III) should not enter i=%i but it does!\n", i);
}
return 0;
}
--
Summary: strlen() strange behaviour in for()
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iesmoises at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39479
[Bug target/39476] Typo in ix86_function_regparm in i386.c
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-03-17 09:39 ---
(In reply to comment #1)
> It is
> if (TARGET_64BIT)
> {
> if (ix86_function_type_abi (type) == DEFAULT_ABI)
> return regparm;
> return DEFAULT_ABI != SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
> }
> Shouldn't it be
> return DEFAULT_ABI == SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
No, it shouldn't. The old test checks first if the calling abi specified via
type is the default one. As you noticed, regparm is never changed for 64-bit.
The second check is for *foreign* abi and has to return in inverse logic.
The patch in comment #2 is ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39476
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #9 from jan dot kratochvil at redhat dot com 2009-03-17 10:05 --- I no longer see any DWARF problem there but Archer C++ still does not work with g++-4.4. Assuming an Archer bug due to the new DW_TAG_lexical_block block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
--- Comment #28 from jakub at gcc dot gnu dot org 2009-03-17 10:42 --- Better just do that with the latest trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #8 from dodji at gcc dot gnu dot org 2009-03-17 10:02 --- Subject: Re: DW_TAG_imported_module should be used (not DW_TAG_imported_declaration) jakub at gcc dot gnu dot org a écrit : > --- Comment #7 from jakub at gcc dot gnu dot org 2009-03-17 08:52 --- > Created an attachment (id=17472) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17472&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17472&action=view) > gcc44-local-imported-decl.patch > > Incremental patch to emit DW_TAG_imported_declaration DIEs (other than > namespace aliases) in the right lexical blocks. > I am wondering what happens when cp_emit_debug_info_for_using is called for a using declaration that appears at global scope. Once we are in the USING_STMT case of cp_gimplify_expr, will there be an enclosing GIMPLE_BIND for the USING_STMT generated for the global using declaration ? For the record, cp_parser_using_declaration calls either do_local_using_decl or do_toplevel_using_decl, depending on if we are at local or global scope. Both do_local_using_decl and do_toplevel_using_decl end up calling cp_parser_using_declaration. > > Concerning: > "We won't be going through the USING_STMT code path in case of We won't be > going through the USING_STMT code path in case of namespace aliases, sorry. My > last comment was irrelevant." > we really should be going through USING_STMT or something similar for > namespace > aliases as well, see PR37890. Given that namespace aliases are just emitted > using gen_namespace_die, perhaps just adding the NAMESPACE_DECL to BLOCK_VARS Yeah I should try something like that in cp_gimplify_expr whenever we are handed BIND_EXPR. In that case, I can wall the BIND_EXPR_VARS of the of the BIND_EXPR and add any NAMESPACE_DECL to the BLOCK_VARS of the matching block. Would that make sense ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39474] DW_AT_location missing for unused variables even at -O0
--- Comment #3 from jan dot kratochvil at redhat dot com 2009-03-17 10:03 --- It works for the gdb.python/python-template.exp test, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39474
[Bug debug/37890] Incorrect nesting for DW_TAG_imported_declaration
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-17 09:19 ---
Created an attachment (id=17473)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17473&action=view)
gcc44-pr37890.patch
Ah, it actually is emitted in the correct lexical block, but in addition to
that it is emitted at global scope as well, perhaps multiple times.
Perhaps more complete testcase for gdb purposes:
namespace A
{
int x = 1;
}
namespace B = A;
void
foo ()
{
namespace C = A;
B::x++;
C::x++;
{
namespace D = A;
D::x++;
}
}
template
void
bar ()
{
namespace C = A;
B::x++;
C::x++;
{
namespace D = A;
D::x++;
}
}
int
main ()
{
foo ();
bar<0> ();
bar<6> ();
}
--
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37890
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-17 10:59 --- calling memcpy with exactly overlapping operands is safe (obviously). Thus this is a bug in valgrind. -- 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=39480
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #3 from fpbeekhof at gmail dot com 2009-03-17 11:13 --- Subject: Re: generated memcpy causes trouble in assignment rguenth at gcc dot gnu dot org wrote: > --- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-17 10:59 > --- > calling memcpy with exactly overlapping operands is safe (obviously). Thus > this is a bug in valgrind. > > It's not so obvious actually, I find the following text in different places: "If the source and destination overlap, the behavior of memcpy is undefined." I guess this is a line from the standard, so when calling memcpy with exactly overlapping operands, it is not officially safe. Thus, if it is safe in libstd++ then that's nice, but it's not a bug in valgrind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #4 from fpbeekhof at gmail dot com 2009-03-17 11:15 --- Subject: Re: generated memcpy causes trouble in assignment paolo dot carlini at oracle dot com wrote: > --- Comment #2 from paolo dot carlini at oracle dot com 2009-03-17 11:04 > --- > by the way, I cannot reproduce it with valgrind 3.3.1 and either mainline or > current 4_3-branch or 4_2-branch. > > If it's any help, this is Ubuntu 8.04 $ valgrind --version valgrind-3.3.0-Debian $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #5 from paolo dot carlini at oracle dot com 2009-03-17 11:28 --- By the way, I don't see what could be possibly wrong in libstdc++: can you please tell us which specific line of code you are suspecting? Certainly, not the entire swap implementation, which is definitely the correct one, no other options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug middle-end/11831] [ARM] Logical expression evaluation with condition fields
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-03-17 11:41 --- This isn't something that should be fixed in the back-end, but most likely an enhancement to a pass such as ifcvt. To handle this case we would have to teach ifcvt about dominated conditions and conditional comparisons -- at present it can only handle conditional insns that do not modify the predicating condition. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11831
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #2 from paolo dot carlini at oracle dot com 2009-03-17 11:04 --- by the way, I cannot reproduce it with valgrind 3.3.1 and either mainline or current 4_3-branch or 4_2-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-03-17 11:05 --- Created an attachment (id=17476) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17476&action=view) the other testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug target/10242] [ARM] subsequent use of plus and minus operators could be improved
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-03-17 11:02 --- Created an attachment (id=17475) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17475&action=view) Proposed fix -- will commit after trunk reopens -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10242
[Bug libstdc++/39480] New: generated memcpy causes trouble in assignment
The following code is unsafe, and I think it's not my fault.
$ g++ -Wall -g testIterSwap.cc ; valgrind -q ./a.out
==1674== Source and destination overlap in memcpy(0x7FF000500, 0x7FF000500, 20)
==1674==at 0x4C2508B: memcpy (mc_replace_strmem.c:402)
==1674==by 0x4008D2: void swap_from_glibcxx
>(HarrisPoint&, HarrisPoint&) (testIterSwap.cc:22)
==1674==by 0x400793: main (testIterSwap.cc:68)
It would appear that the auto-generated operator=() uses a memcpy() which is
not safe. The operator=() that is provided below solves the problem.
cut here
#include
// #include
/**
* @brief Swaps two values.
* @param a A thing of arbitrary type.
* @param b Another thing of arbitrary type.
* @return Nothing.
*
* This is the simple classic generic implementation. It will work on
* any type which has a copy constructor and an assignment operator.
*/
template
inline void
swap_from_glibcxx(_Tp& __a, _Tp& __b)
{
// concept requirements
// __glibcxx_function_requires(_SGIAssignableConcept<_Tp>)
_Tp __tmp = __a;
__a = __b;
__b = __tmp;
}
template
struct Point2D : public std::tr1::array
{
template
Point2D(const U x, const V y)
{
(*this)[0] = x;
(*this)[1] = y;
}
};
template
class FeaturePoint : public Point2D
{
public:
typedef T data_type;
FeaturePoint(const U h, const U w) : Point2D(h,w) {}
};
template
class HarrisPoint : public FeaturePoint
{
public:
typedef T data_type;
HarrisPoint(const U h, const U w, const T value) :
FeaturePoint(h, w), value_(value) { }
/*
// THIS FIXES IT.
HarrisPoint &operator=(const HarrisPoint &rhs)
{
std::memmove(this, &rhs, sizeof(HarrisPoint));
return *this;
}
*/
private:
T value_;
};
int main()
{
HarrisPoint a(1, 2, 3.0f);
// std::tr1::array a; a[0] = 3; a[1] = 5; // fine
a = a; // fine
// std::swap(a, a);
swap_from_glibcxx(a, a);
return 0;
}
--
Summary: generated memcpy causes trouble in assignment
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fpbeekhof at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug rtl-optimization/11826] [ARM] Minor register allocation problem before function return
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-03-17 11:19 --- (In reply to comment #6) > foo: > mov r3, r0 > cmn r1, r0 > rsbeq r0, r1, r0 > rsbne r0, r3, r1 > bx lr This appears to be the code generated at -O1 and although the return is fixed, the redundant insn has now moved to the prologue... Fortunately at -Os and -O2 the output is sensible: foo: cmn r1, r0 rsbeq r0, r1, r0 rsbne r0, r0, r1 bx lr -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11826
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #6 from falk at debian dot org 2009-03-17 12:10 --- (In reply to comment #1) > calling memcpy with exactly overlapping operands is safe (obviously). It's not safe at all. A memcpy implementation might use a "prefetch with write intent" instruction that allocates a cache line to a memory location without actually fetching it, such as wh64 on Alpha, which is actually being used by glibc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #7 from fpbeekhof at gmail dot com 2009-03-17 12:21 --- Subject: Re: generated memcpy causes trouble in assignment paolo dot carlini at oracle dot com wrote: > --- Comment #5 from paolo dot carlini at oracle dot com 2009-03-17 11:28 > --- > By the way, I don't see what could be possibly wrong in libstdc++: can you > please tell us which specific line of code you are suspecting? Certainly, not > the entire swap implementation, which is definitely the correct one, no other > options. > > Well, a specific line of code I cannot give, because this bug is in the operator=() that is generated by the compiler. Given comment #6 by Falk, I think we can safely say that there is an actual bug here. Perhaps libstdc++ is wrong place to submit this bug, but I originally encountered it whilst using iter_swap() from and assumed that to be the cause of the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #10 from jan dot kratochvil at redhat dot com 2009-03-17 12:24
---
ICE: Comment 7 patch (applied together with the Comment 3 patch) on:
namespace A
{
class B
{
};
};
extern void g ();
void
f ()
{
using A::B;
g ();
}
1.C: In function âvoid f()â:
1.C:16: internal compiler error: in force_decl_die, at dwarf2out.c:15092
g++ (GCC) 4.4.0 20090316 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-17 12:28 --- Created an attachment (id=17477) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17477&action=view) gcc44-local-imported-decl.patch Yeah, I know, found that out already during my regtest. Here is what I'm bootstrapping/regtesting instead. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #17472|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #8 from paolo dot carlini at oracle dot com 2009-03-17 12:33 --- Yes, if there is a bug, certainly it is not in libstdc++. Also, please find somebody able to reproduce it, I can't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug libgcj/39481] New: StringTokenizer.hasMoreTokens() can screw up tokens
Test program:
*import java.util.StringTokenizer;
public class gcjbug {
public static void main(String[] args) {
StringTokenizer t = new StringTokenizer("#a=1 #b=2");
for (int i = 0; i < 2; i++) {
if (t.hasMoreTokens())
System.out.println(t.nextToken("=") + t.nextToken("#"));
}
}
}
Expected output:
#a=1
#b=2
Actual output:
#a=1
b=2
Reproduced with 2009/03/16 snapshot of gcc 4.4. After commenting out line "if
(t.hasMoreTokens())" output becomes correct.
--
Summary: StringTokenizer.hasMoreTokens() can screw up tokens
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: receive-spam at yandex dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39481
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-03-17 12:42 --- Vlad, for the second testcase I see -O0: expand: 0.78 (19%) usr 0.04 ( 5%) sys 0.83 (16%) wall 44335 kB (49%) ggc integrated RA : 1.05 (25%) usr 0.03 ( 4%) sys 1.13 (22%) wall 1036 kB ( 1%) ggc reload: 0.55 (13%) usr 0.02 ( 3%) sys 0.59 (12%) wall 3585 kB ( 4%) ggc -O1: integrated RA : 73.95 (77%) usr 1.18 (50%) sys 76.20 (76%) wall 2898 kB ( 3%) ggc (on alias improvements branch I see combiner : 24.89 (17%) usr 0.51 (28%) sys 25.41 (17%) wall 448053 kB (82%) ggc integrated RA : 69.81 (47%) usr 0.36 (20%) sys 70.22 (46%) wall 3212 kB ( 1%) ggc as tree loop invariant motion does lots of stuff there) -O2: PRE : 25.49 (26%) usr 0.03 ( 3%) sys 25.52 (26%) wall 3513 kB ( 3%) ggc integrated RA : 36.98 (38%) usr 0.24 (21%) sys 37.31 (38%) wall 2158 kB ( 2%) ggc -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug libgcj/39481] StringTokenizer.hasMoreTokens() can screw up tokens
--- Comment #1 from receive-spam at yandex dot ru 2009-03-17 12:42 --- Oops, asterisk before "import" should be removed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39481
[Bug target/39473] Typo in untyped_call in i386.md
--- Comment #6 from hjl at gcc dot gnu dot org 2009-03-17 12:51 --- Subject: Bug 39473 Author: hjl Date: Tue Mar 17 12:50:52 2009 New Revision: 144901 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144901 Log: 2009-03-16 H.J. Lu PR target/39473 * config/i386/i386.c (ix86_expand_call): Check extra clobbers for ms->sysv ABI calls only in 64bit mode. * config/i386/i386.md (untyped_call): Support 32bit. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39473
[Bug target/39473] Typo in untyped_call in i386.md
--- Comment #7 from hjl dot tools at gmail dot com 2009-03-17 12:52 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39473
[Bug c++/39413] static_assert and SFINAE
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-17 12:55 --- Jason, are you willing to help triaging this one? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
[Bug target/39476] Typo in ix86_function_regparm in i386.c
--- Comment #5 from hjl at gcc dot gnu dot org 2009-03-17 12:55 --- Subject: Bug 39476 Author: hjl Date: Tue Mar 17 12:55:18 2009 New Revision: 144902 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144902 Log: 2009-03-17 H.J. Lu PR target/39476 * config/i386/i386.c (ix86_function_regparm): Rewrite for 64bit. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39476
[Bug c++/39413] static_assert and SFINAE
--- Comment #5 from paolo dot carlini at oracle dot com 2009-03-17 12:55 --- Sorry, CC-ed Jakub instead of Jason ;) -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|jakub at redhat dot com |jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
[Bug target/39476] Typo in ix86_function_regparm in i386.c
--- Comment #6 from hjl dot tools at gmail dot com 2009-03-17 12:57 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39476
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-03-17 12:58 --- For trunk -O1 I see CPU: AMD64 processors, speed 1000 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10 samples %symbol name 368029 19.8218 allocno_spill_priority_compare 244104 13.1473 color_pass 205725 11.0802 build_allocno_conflicts 1415097.6216 push_allocno_to_stack 1067505.7495 assign_hard_reg 95558 5.1467 bitmap_bit_p 88785 4.7819 add_to_allocno_conflicts 51962 2.7986 splay_tree_splay 42764 2.3032 ira_build_conflicts 40718 2.1930 ira_flattening 27977 1.5068 canon_true_dependence 25608 1.3792 ira_allocno_live_ranges_intersect_p 20403 1.0989 nonoverlapping_memrefs_p 20005 1.0775 ira_add_allocno_conflict -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug target/39477] Incorrect document for regparm attribute
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-17 12:59 --- The patch is at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00759.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/bugzilla/|http://gcc.gnu.org/ml/gcc- |show_bug.cgi?id=39477 |patches/2009- ||03/msg00759.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39477
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-03-17 13:09 --- Btw, it looks like internal IRA data-structures can be shrinked on 64bit platforms by avoiding padding between pointer and integer members a lot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug target/39477] Incorrect document for regparm attribute
--- Comment #3 from hjl at gcc dot gnu dot org 2009-03-17 13:10 --- Subject: Bug 39477 Author: hjl Date: Tue Mar 17 13:10:24 2009 New Revision: 144903 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144903 Log: 2009-03-17 H.J. Lu PR target/39477 * doc/extend.texi: Correct register behavior for regparm on Intel 386. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39477
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #9 from fpbeekhof at gmail dot com 2009-03-17 13:11 --- Subject: Re: generated memcpy causes trouble in assignment paolo dot carlini at oracle dot com wrote: > --- Comment #8 from paolo dot carlini at oracle dot com 2009-03-17 12:33 > --- > Yes, if there is a bug, certainly it is not in libstdc++. Also, please find > somebody able to reproduce it, I can't. Someone should check whether the part that generates operator=() generates a memcpy(), in which case there is a bug because that cannot handle assignment to self, which implies overlapping memory areas, which in turn, as stated by the standard and confirmed by the existence of certain pre-fetch instructions, leads to undefined behavior. This reasoning is valid even if anyone, at any particular time, is able not to see the symptoms. If that bug is there, a possible fix would be to replace memcpy by memmove, as I have suggested. I don't know in what component gcc generates its operator=(), so if someone can tell me I'll assign it to that. Second thing to do is to re-open the bug because it is very real unless it has been fixed already in a later version. Third thing is to increase the priority, because this is likely to affect probably almost all C++ programs, and make all of their behavior undefined. I'm not familiar with gcc policies, and maybe someone can check if this has already been fixed, so I'll wait a few moments before doing these 3 things, to see if there are any reactions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug target/39477] Incorrect document for regparm attribute
--- Comment #4 from hjl at gcc dot gnu dot org 2009-03-17 13:12 --- Subject: Bug 39477 Author: hjl Date: Tue Mar 17 13:11:58 2009 New Revision: 144904 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144904 Log: 2009-03-17 H.J. Lu Backport from mainline: 2009-03-17 H.J. Lu PR target/39477 * doc/extend.texi: Correct register behavior for regparm on Intel 386. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/doc/extend.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39477
[Bug target/39477] Incorrect document for regparm attribute
--- Comment #5 from hjl dot tools at gmail dot com 2009-03-17 13:12 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39477
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #11 from fpbeekhof at gmail dot com 2009-03-17 13:19 --- Subject: Re: generated memcpy causes trouble in assignment paolo dot carlini at oracle dot com wrote: > --- Comment #10 from paolo dot carlini at oracle dot com 2009-03-17 > 13:15 --- > The component would be c++, because that is a C++ thing. > > Ok, that's good to know. Any suggestion what sort of priority I should give to this ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #10 from paolo dot carlini at oracle dot com 2009-03-17 13:15 --- The component would be c++, because that is a C++ thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #12 from paolo dot carlini at oracle dot com 2009-03-17 13:25 --- Apparently, mainline and 4_3-branch do not call memcpy, expand the operator inline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #13 from paolo dot carlini at oracle dot com 2009-03-17 13:26 --- If it affects only 4_2-branch would be zero, because it's no longer maintained ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #14 from fpbeekhof at gmail dot com 2009-03-17 13:28 --- Subject: Re: generated memcpy causes trouble in assignment paolo dot carlini at oracle dot com wrote: > --- Comment #13 from paolo dot carlini at oracle dot com 2009-03-17 > 13:26 --- > If it affects only 4_2-branch would be zero, because it's no longer maintained > ;) Well, then I'd better contact the ubuntu guys, because 4.2.4 is still the main compiler on their latest LTS release. Thanks for the help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #15 from paolo dot carlini at oracle dot com 2009-03-17 13:32 --- To be clear, I'm not sure this is invalid, I agree with you that we should understand the issue in better detail. I'll make sure we do the additional investigation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug tree-optimization/35229] Vectorizer doesn't support dependence created by predictive commoning
--- Comment #3 from irar at il dot ibm dot com 2009-03-17 13:33 ---
(In reply to comment #2)
> Or like the following, which is just a bunch of reductions of two elements
> float data[1024];
> void foo(void)
> {
> int i;
> for (i = 1; i < 1024; ++i)
> data[i] = data[i] + data[i-1];
> }
Actually, this loop is not vectorizable. res and data have to be different
arrays, otherwise we get read after write dependence with distance 1.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35229
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #16 from paolo dot carlini at oracle dot com 2009-03-17 13:34 --- Correction: technically 4_2-branch is still open, but no further releases are expected and will be definitely closed as soon as the 4_4-branch is created (very soon) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug c++/39480] generated memcpy causes trouble in assignment
--- Comment #17 from paolo dot carlini at oracle dot com 2009-03-17 13:35 --- Jason, could you maybe double check this one too? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug target/15061] [arm] c++ complex arguments
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-03-17 13:46 --- Cold case analysis time. Have you seen this problem in recent releases of GCC? -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15061
[Bug target/35180] built-in-setjmp.x2
--- Comment #2 from joel at gcc dot gnu dot org 2009-03-17 14:02 --- Yes. See http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00362.html. We also cross post them to an RTEMS tool list and apparently the run on 12 March resulted in a log that was too large for gcc-testresults. http://www.rtems.org/pipermail/rtems-tooltestresults/2009-March/000232.html Is there anything I can do to help with this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #7 from js-gcc at webkeks dot org 2009-03-17 14:05 --- > Since I wasn't able to get a cross tool chain running (and www.mingw.org > doesn't seem to support that with the current gcc versions) Please have a look at the Portfiles I gave you a link to, they include all the stuff you need to know to build mingw32 with gccc 4.3 as a crosscompiler ;). > "It's a good idea to remove the libobjc.a and libobjc.la and > include/objc headers that come with gcc (gcc -v for location) so that > they are not accidentally found instead of the libobjc DLL that you > will compile below. ..." Yeah, that's exactly what Nicola Pero told me. The default is that there's only a libobjc.a on Win32, but that doesn't work. So GNUstep lets you compile a libobjc.dll and if you use that instead, it works. > Well except that > GNUstep is using a shared libobjc. Yeah, that should already do the trick. > I'm going to throw in the towel here, but I don't believe your issue has to do > with libobjc. I think your missing some flag or extra processing that > gnustep-make might do for you dll or the program. That's what I thought first, too. But after talking to several GNUstep developers on FOSDEM, none of them was aware of any extra flags. They said all they did was recompile libobjc as a DLL and then it would work. I haven't seen any DllMain() in libobjc yet (though I have to admit I haven't really looked for it, only had a few libobjc sources open in the editor for various reasons, but never to look for DllMain), but it might be possible that there is some initialization code in DllMain() of libobjc.dll that does some initializing stuff that fixes it. > But I also believe that statically linking (potentially different versions) of > libobjc into different modules is error prone. I guess it would be OK, if you > only have a single executable, but the constellation of the dll linking one > version and the executable potentially linking another scares me... even if > that itself is most likely not your issue either. I think the DLLs don't link to the static version of libobjc - at least, I hope so, as that'd be useless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #18 from ramana dot r at gmail dot com 2009-03-17 14:27 --- This commit here http://gcc.gnu.org/viewcvs?view=rev&revision=143942 which is essentially a backport of the patch http://gcc.gnu.org/viewcvs?view=rev&revision=137235 . If this fixes the problem, then the bug can be closed out. -- ramana dot r at gmail dot com changed: What|Removed |Added CC||ramana dot r at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug ada/39446] Can not resolve PUT between String and Character versions.
--- Comment #3 from sam at gcc dot gnu dot org 2009-03-17 14:28 --- This is not a bug. The compiler really has no way to distinguish between the following two interpretations for "Put (Get_Name (7))": 1- Get_Name (7) is a call to Get_Name with argument 7, which returns a String 2- Get_Name (7) is a call to Get_Name without argument, which returns a String, and you attempt to take the 7th character of this string, which is a Character Hence the ambiguity. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39446
[Bug middle-end/34109] Incorrect code for tail calls with a structure as 4th argument
--- Comment #2 from ramana dot r at gmail dot com 2009-03-17 14:40 --- This appears to be fixed on mainline on gcc version 4.4.0 20090317 (experimental) (GCC). output obtained 42 69 105 42 69 105 -- ramana dot r at gmail dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34109
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #12 from swagiaal at redhat dot com 2009-03-17 15:17 --- (In reply to comment #9) > I no longer see any DWARF problem there but Archer C++ still does not work > with > g++-4.4. Assuming an Archer bug due to the new DW_TAG_lexical_block block. > Yes there are a couple I am looking at them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug target/39482] New: [4.3/4.4 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478
extern double log (double __x);
double foo(unsigned long int m_liOutputBufferLen)
{
return log((double)m_liOutputBufferLen);
}
ICEs with -mno-sse2
./cc1 -quiet t.i -mno-sse2
t.i: In function 'foo':
t.i:5: internal compiler error: in inline_secondary_memory_needed, at
config/i386/i386.c:25478
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
while it is impossible to compile the call given ABI constraints we should
sorry() here, not ICE.
GCC 4.2 and before simply ignored -mno-sse2 it seems.
--
Summary: [4.3/4.4 Regression] ICE in
inline_secondary_memory_needed, at
config/i386/i386.c:25478
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
[Bug target/39482] [4.3/4.4 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.3 4.4.0 Known to work||4.2.4 Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
[Bug target/39482] [4.3/4.4 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-17 15:26 --- Actually it seems the problem is the combination of int -> float conversion and a call. Either alone doesn't trigger the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
[Bug bootstrap/39483] New: [melt] - revision 144904 - Configuring with "--with-gc=zone" fails in ggc-zone.c
This is a "blocker" but I only set the "Severity" to "major" since I used a non-default configure option, _and_ I have the patch included. Configuring with "--with-gc=zone" fails due to a coding error in ggc-zone.c . Apply the patch to fix this. If the patch is OK, remove comment lines "/* */". Thanks, Rob -- Summary: [melt] - revision 144904 - Configuring with "--with- gc=zone" fails in ggc-zone.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-unknown-linux-gnu GCC host triplet: i686-unknown-linux-gnu GCC target triplet: i686-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39483
[Bug target/39482] [4.3/4.4 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478
--- Comment #2 from ubizjak at gmail dot com 2009-03-17 15:43 --- See the third paragraph of the preceding comment to inline_secondary_memory_needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
[Bug bootstrap/39483] [melt] - revision 144904 - Configuring with "--with-gc=zone" fails in ggc-zone.c
--- Comment #1 from rob1weld at aol dot com 2009-03-17 15:45 --- Created an attachment (id=17478) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17478&action=view) Patch ggc-zone.c to support ggc_collect_1()'s call to ggc_mark_roots_extra_marking() -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39483
[Bug target/39482] [4.3/4.4 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478
--- Comment #3 from ubizjak at gmail dot com 2009-03-17 15:51 --- (In reply to comment #2) > See the third paragraph of the preceding comment to > inline_secondary_memory_needed. Oh, well. trunc* patterns violate this rule. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
[Bug bootstrap/39483] [melt] - revision 144904 - Configuring with "--with-gc=zone" fails in ggc-zone.c
--- Comment #2 from basile at starynkevitch dot net 2009-03-17 15:57 --- Thanks. Patch commited as rev 144905 of MELT branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39483
[Bug target/39482] [4.3/4.4 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478
-- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-17 16:01:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
[Bug bootstrap/39484] New: [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c -> SIGSEGV
Compiling melt-branch revision 144904 with gcc 4.4.0 (Trunk),
4.3, or 4.1 results in a Segmentation fault in the modded 'cc1'
basilys_extra_marking() function.
Here is the "regular output" of where it fails:
Compiling ../../melt-branch/gcc/warmelt-outobj-0.c with -g
-fkeep-inline-functions -DIN_GCC -DHAVE_CONFIG_H -DMELTGCC_DYNAMIC_OBJSTRUCT
real0m9.599s
user0m8.321s
sys 0m0.924s
-rwxr-xr-x 1 root root 1448978 2009-03-16 20:42 warmelt-outobj-0-d.so
-rw-r--r-- 1 root root 2309220 2009-03-16 10:05
../../melt-branch/gcc/warmelt-outobj-0.c
done ./built-melt-cc-script ../../melt-branch/gcc/warmelt-outobj-0.c
warmelt-outobj-0-d.so
date +"#warmelt0.modlis generated %c" > warmelt0.modlis-tmp
for f in warmelt-first-0 warmelt-macro-0 warmelt-normal-0
warmelt-normatch-0 warmelt-genobj-0 warmelt-outobj-0; do echo $f >>
warmelt0.modlis-tmp; done
/bin/sh ../../melt-branch/gcc/../move-if-change warmelt0.modlis-tmp
warmelt0.modlis
rm -f warmelt-first-1.c
generating warmelt-first using warmelt-first-0 warmelt-macro-0 warmelt-normal-0
warmelt-normatch-0 warmelt-genobj-0 warmelt-outobj-0
WARMELT_BASE0= warmelt-first-0 warmelt-macro-0 warmelt-normal-0
warmelt-normatch-0 warmelt-genobj-0 warmelt-outobj-0 WARMELT_BASE0ROW=
warmelt-first-0-d:warmelt-macro-0-d:warmelt-normal-0-d:warmelt-normatch-0-d:warmelt-genobj-0-d:warmelt-outobj-0-d
time ./cc1 -Wno-shadow -fbasilys=translateinit -fbasilys-dynlibdir=.
-fbasilys-compile-script=/mnt/drive2/melt-branch_build/gcc/built-melt-cc-script
-fbasilys-gensrcdir=. -fbasilys-tempdir=_tempmeltdir_$$
-fbasilys-init=warmelt-first-0-d:warmelt-macro-0-d:warmelt-normal-0-d:warmelt-normatch-0-d:warmelt-genobj-0-d:warmelt-outobj-0-d
\
-fbasilys-arg=../../melt-branch/gcc/melt/warmelt-first.bysl \
-fbasilys-secondarg=warmelt-first-1.c
** warmelt generated 105 routines into warmelt-first-1.c
** from Mon 16 Mar 2009 08:41:53 PM PDT
../../melt-branch/gcc/warmelt-outobj-0.c
** of checksum d154a02b37d0b56f8a7a08c5368fded8
../../melt-branch/gcc/warmelt-outobj-0.c
cc1: note: BASILYS INFORM [#198595]: warmelt generated module -
warmelt-first-1.c
{GC 12538k -> cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
real0m1.788s
user0m1.104s
sys 0m0.292s
make[4]: *** [warmelt-first-1.c] Error 4
make[4]: Leaving directory `/mnt/drive2/melt-branch_build/gcc'
make[3]: *** [melt.encap] Error 2
In order to discover the "hidden processing" and intermediate
files (along with giving some more debugging tips) I changed
"melt-cc-script.proto" (as is suggested at the wiki's URL:
http://gcc.gnu.org/wiki/MiddleEndLispTranslator) to use "-O0"
and "--save-temps" (plus other commands) like this:
echo Compiling $csource with $melt_cflags
# time $melt_cc -O0 -v -fmem-report -ftime-report -dn -Wall -fPIC
$melt_cflags -I "$melt_headerdir" $csource -c -o $nakedynstuff.o
#$melt_cc -O0 -v -fmem-report -ftime-report -dn -Wall -fPIC -shared
$melt_cflags -I "$melt_headerdir" $datf.c $nakedynstuff.o -o $nakedynstuff.so
time $melt_cc -O0 -v -ftime-report --save-temps -Wall -fPIC
$melt_cflags -I "$melt_headerdir" $csource -c -o $nakedynstuff.o
$melt_cc -O0 -v -ftime-report --save-temps -Wall -fPIC -shared
$melt_cflags -I "$melt_headerdir" $datf.c $nakedynstuff.o -o $nakedynstuff.so
echo
After doing that I was able to run "./cc1" on the intermediate file
using 'gdb' with this result:
# cd /mnt/drive2/melt-branch_build/gcc
# file ./cc1
./cc1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
# gdb --args ./cc1 -Wno-shadow -fbasilys=translateinit -fbasilys-dynlibdir=.
-fbasilys-compile-script=/mnt/drive2/melt-branch_build/gcc/built-melt-cc-script
-fbasilys-gensrcdir=. -fbasilys-tempdir=_tempmeltdir_$$
-fbasilys-init=warmelt-first-0-d:warmelt-macro-0-d:warmelt-normal-0-d:warmelt-normatch-0-d:warmelt-genobj-0-d:warmelt-outobj-0-d
-fbasilys-arg=../../melt-branch/gcc/melt/warmelt-first.bysl
-fbasilys-secondarg=warmelt-first-1.c -v
GNU gdb 6.8-debian
...
(gdb) r
Starting program: /mnt/drive2/melt-branch_build/gcc/cc1 -Wno-shadow
-fbasilys=translateinit -fbasilys-dynlibdir=.
-fbasilys-compile-script=/mnt/drive2/melt-branch_build/gcc/built-melt-cc-script
-fbasilys-gensrcdir=. -fbasilys-tempdir=_tempmeltdir_2871
-fbasilys-init=warmelt-first-0-d:warmelt-macro-0-d:warmelt-normal-0-d:warmelt-normatch-0-d:warmelt-genobj-0-d:warmelt-outobj-0-d
-fbasilys-arg=../../melt-branch/gcc/melt/warmelt-first.bysl
-fbasilys-secondarg=warmelt-first-1.c -v
{Main zone GC 27k -> 27k} {Tree identifier zone GC 1k -> 1k} {Tree zone GC 0k
-> 0k} {RTL zone GC 0k -> 0k}** warmelt generated 105 routines into
warmelt-first-1.c
** from Tue 17 Mar 2009 09:04:44 AM PDT warmelt-outobj-0-d.c
** of checksum d154a02b37d0b56f8a7a08c5368f
[Bug bootstrap/39484] [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c -> SIGSEGV
--- Comment #1 from basile at starynkevitch dot net 2009-03-17 16:39 --- Bug confirmed. The bug seems to appear on x86 (not amd64) when configure-ing with --prefix=/usr/ A very temporary workaround could be to configure with --prefix=/usr/local/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
[Bug target/32838] gcc generates incorrect trampoline code in thumb mode
--- Comment #4 from leo at marco dot de 2009-03-17 16:47 ---
Subject: Re: gcc generates incorrect trampoline code in
thumb mode
laurent at guerby dot net wrote:
> --- Comment #3 from laurent at guerby dot net 2009-01-02 12:29 ---
> This needs a testcase
>
>
Testcase:
void
f(int aa, int bb, int cc, int dd, int ee, int ff)
{
extern int x(int (*)(void));
int
q(void)
{
extern int a(int);
return(a(ff)*55);
}
x(&q);
}
"arm-elf-gcc -mthumb -S -O tst.c" results in:
.code 16
.file "tst.c"
.section.rodata
.align 2
.LTRAMP0:
.code 32
.Ltrampoline_start:
XX
ldr r9, [pc, #8]
XX
ldr ip, [pc, #8]
orr ip, ip, #1
bx ip
.word 0
.word 0
.code 16
.global __clear_cache
.text
.align 2
.global f
.code 16
.thumb_func
.type f, %function
f:
push{r4, r5, lr}
sub sp, sp, #28
ldr r0, [sp, #44]
str r0, [sp]
add r4, sp, #4
ldr r3, .L3
mov r2, r4
ldmia r3!, {r0, r1, r5}
stmia r2!, {r0, r1, r5}
ldmia r3!, {r0, r1, r5}
stmia r2!, {r0, r1, r5}
mov r3, sp
str r3, [sp, #20]
ldr r3, .L3+4
str r3, [sp, #24]
mov r0, r4
add r1, sp, #28
bl __clear_cache
mov r0, r4
bl x
add sp, sp, #28
@ sp needed for prologue
pop {r4, r5, pc}
.L4:
.align 2
.L3:
.word .LTRAMP0
.word q.1472
.size f, .-f
.align 2
.code 16
.thumb_func
.type q.1472, %function
q.1472:
mov r2, r9
push{r2, lr}
mov r3, r9
ldr r0, [r3]
bl a
mov r3, r0
lsl r0, r0, #3
sub r0, r0, r3
lsl r0, r0, #3
sub r0, r0, r3
@ sp needed for prologue
pop {r2}
mov r9, r2
pop {pc}
.size q.1472, .-q.1472
.ident "GCC: (GNU) 4.2.3"
Notice the line marked with "XX"
r9 is unconditionally destroyed when the trampoline code is called.
Regards, Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32838
[Bug target/35180] built-in-setjmp.x2
--- Comment #3 from hp at gcc dot gnu dot org 2009-03-17 17:13 --- (In reply to comment #2) > Is there anything I can do to help with this? If you could bisect the behaviour to a svn revision range, that might give a clue. See the description of the aforementioned bug (where it's unfortunately also evident that it's not a silver bullet...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/35180] built-in-setjmp.x2
--- Comment #4 from joel at gcc dot gnu dot org 2009-03-17 17:32 --- Going back through the old run logs. Is this how it shows up? FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O0 FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O1 FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O2 FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -g FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -Os So far I see those in logs back to May 2008 (revision 135528): http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01876.html And apparently it failed in 4.3.0: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg00535.html And 4.2.3 http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00645.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/39472] Add -mabi=[ms|sysv]
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-17 17:35 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00797.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||03/msg00797.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39472
[Bug testsuite/38526] WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator
--- Comment #6 from janis at gcc dot gnu dot org 2009-03-17 17:36 --- Subject: Bug 38526 Author: janis Date: Tue Mar 17 17:35:55 2009 New Revision: 144908 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144908 Log: gcc/ PR testsuite/38526 * Makefile.in (site.exp): Rename TEST_GCC_EXEC_PREFIX and comment its use. (check-%): Don't set GCC_EXEC_PREFIX when invoking runtest. (check-parallel-%): Ditto. (check-consistency): Ditto. testsuite/ PR testsuite/38526 * lib/target-libpath.exp (set_ld_library_path_env_vars): Save existing GCC_EXEC_PREFIX, set to TEST_GCC_EXEC_PREFIX if that is defined. (restore_ld_library_path_env_vars): Restore GCC_EXEC_PREFIX to its original value, or unset if it was not defined. * gcc.dg/compat/struct-layout-1.exp: Use set/restore library path procs around use of HOSTCC. * g++.dg/compat/struct-layout-1.exp: Ditto. * objc.dg/gnu-encoding/gnu-encoding.exp: Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/compat/struct-layout-1.exp trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp trunk/gcc/testsuite/lib/target-libpath.exp trunk/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38526
[Bug target/39472] Add -mabi=[ms|sysv]
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 17:42 --- Is it really so hard to change UEFI apps? The thing is that by adding the -mabi= option you pessimize x86_64 gcc even more than the attribute patches have done. Now at least DEFAULT_ABI == SYSV_ABI or DEFAULT_ABI != SYSV_ABI can be optimized into a constant at compile time, with your patch it can't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39472
[Bug debug/39412] [4.2/4.3/4.4 Regression] ICE in gen_tagged_type_instantiation_die
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-17 17:44 --- Subject: Bug 39412 Author: jakub Date: Tue Mar 17 17:43:52 2009 New Revision: 144909 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144909 Log: PR debug/39412 * dwarf2out.c (gen_inlined_enumeration_type_die, gen_inlined_structure_type_die, gen_inlined_union_type_die, gen_tagged_type_instantiation_die): Removed. (gen_decl_die): For TYPE_DECL_IS_STUB with non-NULL decl_origin do nothing. * gcc.dg/debug/pr39412.c: New test. Added: trunk/gcc/testsuite/gcc.dg/debug/pr39412.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
[Bug middle-end/39443] [4.4 Regression] Builtin redirection no longer working for memcmp
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-17 17:46 --- Subject: Bug 39443 Author: jakub Date: Tue Mar 17 17:46:23 2009 New Revision: 144910 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144910 Log: PR middle-end/39443 * optabs.c (set_user_assembler_libfunc): New function. * expr.h (set_user_assembler_libfunc): New prototype. * c-common.c: Include libfuncs.h. (set_builtin_user_assembler_name): Call set_user_assembler_libfunc for memcmp, memset, memcpy, memmove and abort. * Makefile.in (c-common.o): Depend on libfuncs.h. * gcc.dg/pr39443.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr39443.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/c-common.c trunk/gcc/expr.h trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39443
[Bug bootstrap/39484] [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c -> SIGSEGV
--- Comment #2 from rob1weld at aol dot com 2009-03-17 17:48 --- Created an attachment (id=17479) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17479&action=view) A patch to ignore NULL "*mi->iniframp" from VEC_iterate() - shortcuts the issue I am very unfamiliar with this branch and offer this very naive patch which seems to work thus far. I'm not checking the "Patch" checkbox nor suggesting it is OK. # ../melt-branch_build/gcc/xgcc -v Using built-in specs. Target: i686-unknown-linux-gnu Configured with: ../melt-branch/configure --build=i686-unknown-linux-gnu --prefix=/usr/local/melt-gcc --enable-languages=c --enable-shared --disable-static --disable-multilib --enable-stage1-checking=all --enable-checking=release --with-arch=k8 --with-gc=zone --with-gnu-as --with-as=/usr/bin/as --with-gnu-ld --with-ld=/usr/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --with-ltdl=/usr/local --with-gdbm=/usr/local --with-ppl=/usr --enable-maintainer-mode --enable-compile-probe --enable-basilysmelt --enable-gather-detailed-memory-stats Thread model: posix gcc version 4.4.0 20090313 (experimental) [melt-branch revision 144904] (GCC) Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #13 from jakub at gcc dot gnu dot org 2009-03-17 17:49 --- Subject: Bug 39471 Author: jakub Date: Tue Mar 17 17:49:28 2009 New Revision: 144911 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144911 Log: PR debug/39471 * dwarf2out.c (dwarf2out_imported_module_or_decl_1): Emit DW_TAG_imported_module even if decl is IMPORTED_DECL with NAMESPACE_DECL in its DECL_INITIAL. * cp-gimplify.c (cp_gimplify_expr): Don't set DECL_NAME on IMPORTED_DECL. * g++.dg/debug/dwarf2/imported-module-2.C: Expect DW_TAG_imported_module, not just any DW_TAG_imported prefixed tag. * g++.dg/debug/dwarf2/imported-module-3.C: Likewise. * g++.dg/debug/dwarf2/imported-module-4.C: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-2.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-3.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-4.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/37890] Incorrect nesting for DW_TAG_imported_declaration
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 17:52 --- Subject: Bug 37890 Author: jakub Date: Tue Mar 17 17:52:08 2009 New Revision: 144913 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144913 Log: PR debug/37890 * name-lookup.c (do_namespace_alias): Don't call global_decl debug hook at function scope. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37890
[Bug debug/39474] DW_AT_location missing for unused variables even at -O0
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-17 17:53 --- Subject: Bug 39474 Author: jakub Date: Tue Mar 17 17:53:01 2009 New Revision: 144914 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144914 Log: PR debug/39474 * tree-ssa-live.c (remove_unused_locals): Don't remove local unused non-artificial variables when not optimizing. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-live.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39474
[Bug debug/39412] [4.2/4.3 Regression] ICE in gen_tagged_type_instantiation_die
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-17 17:55 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 4.3.3 4.4.0 |4.2.0 4.3.3 Known to work|4.1.2 |4.1.2 4.4.0 Summary|[4.2/4.3/4.4 Regression] ICE|[4.2/4.3 Regression] ICE in |in |gen_tagged_type_instantiatio |gen_tagged_type_instantiatio|n_die |n_die | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
[Bug middle-end/39443] [4.4 Regression] Builtin redirection no longer working for memcmp
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 17:55 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39443
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #14 from jakub at gcc dot gnu dot org 2009-03-17 17:56 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/37890] Incorrect nesting for DW_TAG_imported_declaration
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-17 17:56 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37890
[Bug debug/39474] DW_AT_location missing for unused variables even at -O0
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-17 17:57 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39474
[Bug target/39482] [4.3/4.4 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478
--- Comment #4 from uros at gcc dot gnu dot org 2009-03-17 18:55 --- Subject: Bug 39482 Author: uros Date: Tue Mar 17 18:55:40 2009 New Revision: 144915 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144915 Log: PR target/39482 * config/i386/i386.md (*truncdfsf_mixed): Avoid combining registers from different units in a single alternative. (*truncdfsf_i387): Ditto. (*truncxfsf2_mixed): Ditto. (*truncxfdf2_mixed): Ditto. testsuite/ChangeLog: PR target/39482 * gcc.target/i386/pr39482.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr39482.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
[Bug target/39482] [4.3 Regression] ICE in inline_secondary_memory_needed, at config/i386/i386.c:25478
--- Comment #5 from ubizjak at gmail dot com 2009-03-17 18:58 --- Fixed in trunk. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||03/msg00813.html GCC target triplet|x86-*-* |x86_64-*-* Summary|[4.3/4.4 Regression] ICE in |[4.3 Regression] ICE in |inline_secondary_memory_need|inline_secondary_memory_need |ed, at |ed, at |config/i386/i386.c:25478|config/i386/i386.c:25478 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
[Bug bootstrap/39484] [melt] - revision 144904 - BASILYS INFORM [#198595]: warmelt-first-1.c -> SIGSEGV
--- Comment #3 from basile at starynkevitch dot net 2009-03-17 19:07 --- I applied a slightly simplified variant of melt-patch-2.patch above as rev144917 Thanks Rob. It probably works! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
[Bug target/39472] Add -mabi=[ms|sysv]
--- Comment #4 from hjl dot tools at gmail dot com 2009-03-17 19:17 ---
(In reply to comment #3)
> Is it really so hard to change UEFI apps?
You can take a look at testcases in gcc.target/x86_64/abi/callabi.
They have to use macros, like
---
static
void CALLABI_CROSS do_cpy (char *s, ...)
{
CROSS_VA_LIST argp;
CROSS_VA_START (argp, s);
vdo_cpy (s, argp);
CROSS_VA_END (argp);
}
---
With -mabi=, we can have normal C codes, like
void
do_cpy (char *s, ...)
{
va_list argp;
va_start (argp, s);
vdo_cpy (s, argp);
va_end (argp);
}
> The thing is that by adding the -mabi= option you pessimize x86_64 gcc even
> more than the attribute patches have done. Now at least DEFAULT_ABI ==
> SYSV_ABI
> or DEFAULT_ABI != SYSV_ABI can be optimized into a constant at compile time,
> with your patch it can't.
On Fedora 9/Intel Core i7, before my change, I got
5336.28user 431.05system 19:46.59elapsed 486%CPU (0avgtext+0avgdata
0maxresident)k
for bootstrap and
8133.98user 2054.99system 43:25.49elapsed 391%CPU (0avgtext+0avgdata
0maxresident)k
for "make check" for both 32bit and 64bit with all default languages.
After my change, I got
5090.92user 411.23system 18:40.23elapsed 491%CPU (0avgtext+0avgdata
0maxresident)k
for "make check" for both 32bit and 64bit with all default languages.
8140.67user 2074.77system 43:25.89elapsed 392%CPU (0avgtext+0avgdata
0maxresident)k
I don't see a big difference in compiler performance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39472
[Bug target/39472] Add -mabi=[ms|sysv]
--- Comment #5 from hjl dot tools at gmail dot com 2009-03-17 19:46 --- The updated patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00815.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2009- |patches/2009- |03/msg00797.html|03/msg00815.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39472
