--- Comment #9 from hp at gcc dot gnu dot org 2009-03-17 05:35 ---
(In reply to comment #8)
> Guess it probably won't be TARGET_BUILTIN_SETJMP_FRAME_VALUE then.
At any rate, changing it to hard_frame_pointer_rtx doesn't help by itself.
(Resulting diffs in RTL dumps are gone after 132r.u
--- Comment #1 from hp at gcc dot gnu dot org 2009-03-17 04:18 ---
Does this still happen? See also PR38609.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39473
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-17 01:24 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00761.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-17 00:45 ---
A patch is posted at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39477
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-17 00:34
---
Maybe Daniel, but this is a completely separate issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
GCC target triplet||i686-pc-linux-gnu
Target Milestone|--- |4.4
extend.texi has
---
@item regparm (@var{number})
@cindex @code{regparm} attribute
@cindex functions that are passed arguments in registers on the 386
On the Intel 386, the @code{regparm} attribute causes the compiler to
pass arguments number one to @var{number} if they are of integral type
in regi
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-03-17 00:15
---
This is a case where early splitting (before register allocation) of a constant
in a plus expression leads to poor code. We should try disabling the split of
a plus when combined with the internal frame pointer.
--- Comment #10 from ramana dot r at gmail dot com 2009-03-17 00:11 ---
This should be a target bug. Also with mainline the testcase empty described in
comment #9 appears fixed.
--
ramana dot r at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ramana dot r at gmail dot com 2009-03-17 00:05 ---
Still present with 4.4 mainline as on 20090312 revision. It looks like some
sort of relic left behind with the calculations of the soft frame pointer.
Maybe a peephole will help.
--
ramana dot r at gmail dot com c
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-17 00:03
---
Confirmed, this is a nasty bug that might silently bite users after a long
period of apparently correct operation.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #6 from ayers at gcc dot gnu dot org 2009-03-16 23:51 ---
I've played a bit with creating a trivial static library and linking into an
dynamic library and into an executable. After tweaking back and forth it seems
that at least on GNU/Linux the static version linked into the
--- Comment #3 from d dot frey at gmx dot de 2009-03-16 23:49 ---
One more thought on the diagnostics: There are two cases: Incomplete types
(like in the initial example in the description of this PR) and recursive
template instantiations (see attachment). I think the latter produces a
d
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
http
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 23:38
---
Confirmed. We need a way to represent an early-clobber between a register and
a memory-address with side-effects.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 23:27
---
I believe this is a bug in the way we expand local reg vars. The manual says:
Local register variables in specific registers do not reserve the
registers, except at the point where they are used as input or outpu
--- Comment #6 from sebpop at gmail dot com 2009-03-16 23:18 ---
Subject: Re: ICE in create_data_ref with -O1
-floop-interchange
Hi,
I don't know who coded the overly complicated exclude_component_ref.
In the graphite branch we already cleaned up all this code, but in
trunk w
Hi,
I don't know who coded the overly complicated exclude_component_ref.
In the graphite branch we already cleaned up all this code, but in
trunk we still have it.
Attached is a patch that fixes the problem by looking at whether the
operand contains COMPONENT_REFs before calling the data referenc
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
http
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-03-16 22:53
---
Confirmed. This is a bug in the arith_adjacent_mem pattern that only triggers
when the offset to the memory from the base pointer exceeds the range of a
simple add instruction (ie more than 1024 bytes). In that c
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-16 22:59 ---
Well, it doesn't even have a value assigned. So I consider this a valid
"optimization" for -O0. Does the variable have a location once you inintialize
it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39474
--- Comment #5 from sebpop at gmail dot com 2009-03-16 22:34 ---
Subject: Re: ICE in create_data_ref with -O1
-floop-interchange
Thanks for the reduced testcase, it completely went out of my radar
(by now my delta script should have finished reducing it as well on
the gcc-farm
Thanks for the reduced testcase, it completely went out of my radar
(by now my delta script should have finished reducing it as well on
the gcc-farm, but I won't even look at it).
Thanks again for the reduced case. I will look at the bug now.
Sebastian
--- Comment #4 from il dot basso dot buffo at gmail dot com 2009-03-16
22:24 ---
Bah, here's an even smaller example:
struct Point
{
int line, col;
Point( int l = -1, int c = 0 ) throw() : line( l ), col( c ) {}
bool operator==( const Point & p ) const throw()
{ return ( l
--- Comment #3 from il dot basso dot buffo at gmail dot com 2009-03-16
22:21 ---
Here's a further reduction:
struct Point
{
int line, col;
Point( int l = -1, int c = 0 ) throw() : line( l ), col( c ) {}
bool operator==( const Point & p ) const throw()
{ return ( line == p.
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-16 22:09 ---
We never change regparm for 64bit. Does this patch
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 144817)
+++ gcc/config/i
--- Comment #2 from rob1weld at aol dot com 2009-03-16 22:08 ---
My next difficulty (on OpenSolaris) is the lack of a "fopencookie()"
function (and the related support in "FILE"). I'm now building melt
on "i686-pc-linux-gnu" and running into a few other errors; thus melt
does need some f
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-16 21:59 ---
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
ret
ix86_function_regparm in i386.c has
if (TARGET_64BIT)
{
if (ix86_function_type_abi (type) == ix86_abi)
return regparm;
return ix86_abi != SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM_MAX;
}
Shouldn't it be
return ix86_abi == SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPARM
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-03-16 21:37
---
Thanks although there is still excessive DW_AT_name:
<3><422>: Abbrev Number: 12 (DW_TAG_imported_module)
<425> DW_AT_name: A
<427> DW_AT_import : <0x113> [Abbrev Number: 2 (DW_TAG_na
--- Comment #6 from pluto at agmk dot net 2009-03-16 21:24 ---
i've tested u-dw2.exe on wine and got more info.
$ ./u-dw2.exe
err:process:start_wineboot failed to start wineboot, err 2
err:process:__wine_kernel_init boot event wait timed out
fixme:msvcrt:__lconv_init stub
foo:enter
bar
--- Comment #3 from janis at gcc dot gnu dot org 2009-03-16 21:12 ---
Subject: Bug 37630
Author: janis
Date: Mon Mar 16 21:11:57 2009
New Revision: 144893
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144893
Log:
Revert patch for PR testsuite/37630.
Modified:
trunk
--- Comment #5 from hjl dot tools at gmail dot com 2009-03-16 21:00 ---
An updated patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00754.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- 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)
gcc44-pr39471.patch
Untested patch. Dodji, any reason why you started emitting
DW_TAG_imported_declaration for t
--- Comment #10 from janis at gcc dot gnu dot org 2009-03-16 20:01 ---
Subject: Bug 37960
Author: janis
Date: Mon Mar 16 20:01:15 2009
New Revision: 144892
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144892
Log:
PR testsuite/37960
* gcc.dg/pr11492.c: Replace c
--- Comment #2 from janis at gcc dot gnu dot org 2009-03-16 19:59 ---
Subject: Bug 37630
Author: janis
Date: Mon Mar 16 19:59:37 2009
New Revision: 144891
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144891
Log:
PR testsuite/37630
* lib/target-supports.exp (che
--- Comment #1 from janis at gcc dot gnu dot org 2009-03-16 19:58 ---
Subject: Bug 37628
Author: janis
Date: Mon Mar 16 19:58:32 2009
New Revision: 144890
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144890
Log:
PR testsuite/37628
* gcc.c-torture/execute/pr3545
--- Comment #4 from hjl dot tools at gmail dot com 2009-03-16 19:21 ---
A patch is posed at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00749.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-03-16 19:20
---
Indeed, ICC errors out.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #27 from d dot frey at gmx dot de 2009-03-16 19:08 ---
Thanks Paolo. I've opened PR c++/39475 for the type traits intrinsics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
--- Comment #6 from wilson at codesourcery dot com 2009-03-16 19:07 ---
Subject: Re: Branch registers loaded too late
on ia64
steven at gcc dot gnu dot org wrote:
> --- Comment #5 from steven at gcc dot gnu dot org 2009-03-16 08:46
> ---
> Can someone point me to the IA64 op
--- Comment #1 from d dot frey at gmx dot de 2009-03-16 19:05 ---
Created an attachment (id=17468)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17468&action=view)
show inconsistency for is_abstract
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
The current implementation returns misleading results if used the wrong way. A
simple example is:
#include
struct X;
int main()
{
std::cout << __is_abstract(X) << std::endl;
}
compiles and prints "0". Things get worse when templates are involved. PR
libstdc++/39405 shows why this can be a real
It is a regression since gcc-4.3 but it was found only at artificial (GDB)
testcase. Also at -O2 such behavior is even expected.
The variable is considered as optimized-out which should not happen on -O0.
Testcase:
--
in
--- Comment #3 from hjl dot tools at gmail dot com 2009-03-16 18:47 ---
(In reply to comment #0)
> untyped_call in i386.md has
>
> ix86_expand_call ((TARGET_FLOAT_RETURNS_IN_80387
> ? gen_rtx_REG (XCmode, FIRST_FLOAT_REG) : NULL),
> operands[0]
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-16 18:40 ---
(In reply to comment #1)
> Also
>
> void
> ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
> rtx callarg2,
> rtx pop, int sibcall)
> {
> rtx use = NULL, call;
> enum
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-16 18:26 ---
Also
void
ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
rtx callarg2,
rtx pop, int sibcall)
{
rtx use = NULL, call;
enum calling_abi function_call_abi;
if (calla
untyped_call in i386.md has
ix86_expand_call ((TARGET_FLOAT_RETURNS_IN_80387
? gen_rtx_REG (XCmode, FIRST_FLOAT_REG) : NULL),
operands[0], const0_rtx,
GEN_INT ((DEFAULT_ABI == SYSV_ABI ? X86_64_SSE_REGPARM_MAX
--- Comment #27 from hjl dot tools at gmail dot com 2009-03-16 17:26
---
(In reply to comment #26)
>
> Probably, I should rebuild 144529 and try Jakub's suggestions.
You need the fix for PR 39345 on top of revision 144529.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
--- Comment #26 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-16
17:20 ---
Subject: Re: [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
> Since revision 144529:
>
> http://gcc.gnu.org/ml/gcc-patches/2009-03/msg0.html
>
> is the cause and it is inline related, I
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-03-16 17:02 ---
(In reply to comment #4)
> Reopening because
> int params; __asm__ ("xxx" : "=X" (params));
> and
> int params[1]; __asm__ ("xxx" : "=X" (params[0]));
> still produce different output in a way that is undocumented.
--- Comment #4 from balrogg at gmail dot com 2009-03-16 16:53 ---
Reopening because
int params; __asm__ ("xxx" : "=X" (params));
and
int params[1]; __asm__ ("xxx" : "=X" (params[0]));
still produce different output in a way that is undocumented.
--
balrogg at gmail dot com changed:
UEFI uses MS x64 calling convention. It will be nice to
support -mabi=ms on Linux so that we can use gcc 4.4
to build UEFI applications on Linux.
--
Summary: Add -mabi=[ms|sysv]
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhan
--- Comment #12 from jakub at gcc dot gnu dot org 2009-03-16 16:27 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-16 16:07 ---
Subject: Bug 39455
Author: jakub
Date: Mon Mar 16 16:07:07 2009
New Revision: 144885
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144885
Log:
PR tree-optimization/39455
* tree-ssa-loop-niter
Regression from g++-4.3 for GNU C++ 4.4.0 20090315 (experimental)
(+also for 4.4.0 20090313 (Red Hat 4.4.0-0.26))
For full namespace import one should use DW_TAG_imported_module.
1:namespace A
2:{
3: int i = 1;
4:}
5:
6:int
7:main ()
8:{
9: using namespace A;
10: i = 2;
11: return 0;
12:}
Usi
--- Comment #1 from jan dot kratochvil at redhat dot com 2009-03-16 14:24
---
Verified as the problem exists on GNU C++ 4.4.0 20090315 (experimental).
Tried also non-main function and slightly complicated function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37890
--- Comment #5 from js-gcc at webkeks dot org 2009-03-16 11:46 ---
It would be hard to link to that discussion as that was IRL on FOSDEM in the
GNUstep Dev Room :).
I reported that bug once on the mingw32 list, but they wouldn't really care
about it. After speaking to Nicola Pero on FOSD
--- Comment #4 from ayers at gcc dot gnu dot org 2009-03-16 11:41 ---
Well, consider me a "GNUstep guy" yet I'm definitely not a "GNUstep on MinGW32
guy". (Or anything on MinGW32... which is why this a bit difficult, yet I'm
trying to help maintain libobjc so I'll see what I can do.)
Co
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2009-03-16 11:35
---
Would you please attach a preprocessed testcase so one can reproduce the
problem.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from js-gcc at webkeks dot org 2009-03-16 11:24 ---
When the target is mingw32, it seems that libobjc is only built as a static
library. This isn't a bad idea after all, because I guess no win32 user has a
libobjc.so installed somewhere, so you would need to ship that file
--- Comment #19 from falk at debian dot org 2009-03-16 10:24 ---
(In reply to comment #18)
> Well, I've got bad news for you anyway:
> it seems that the problem affects gcc-4.3.2 too:
> it seems it's reproducible in another app,
> however one potentially much harder to debug.
> Please re
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-16 09:43 ---
Seems tree-ssa-loop-niter.c has a lot of p+ issues. The following untested
patch fixes just the number_of_iterations_lt_to_ne bugs and fixes this
testcase:
--- gcc/tree-ssa-loop-niter.c.jj2009-03-04 20:06:31
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.3
Known to work|4.2.4 |4.2.4 4.4.0
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-03-16 09:15 ---
(In reply to comment #8)
> (In reply to comment #7)
> > The following patch solves this problem and prevents the name collision for
> > 32
> > and 64 bits win32 systems.
> >
> > ChangeLog
> >
> > * config/i
--- Comment #9 from jakub at gcc dot gnu dot org 2009-03-16 08:49 ---
No, this seems to be aprefetch's pass fault, at least in quick skim
*.cunroll seems to be ok typewise, while *.aprefetch has:
D.1649_44 = &c + 1024;
D.1650_43 = (long unsigned int) D.1649_44;
if (&c[2] <= D.1650_
--- Comment #5 from steven at gcc dot gnu dot org 2009-03-16 08:46 ---
Can someone point me to the IA64 optimiation manuals mentioned in comment #0?
I'm looking for some answers, for example:
* Which branch registers can I use? bt-load can actually perform register
renaming. It has
--- Comment #8 from pinskia at gmail dot com 2009-03-16 08:28 ---
Subject: Re: [4.3/4.4 Regression] ICE : in compare_values_warnv, at
tree-vrp.c:1073
Sent from my iPhone
On Mar 16, 2009, at 1:15 AM, "jakub at gcc dot gnu dot org"
wrote:
>
>
> --- Comment #7 from jakub at gcc d
Sent from my iPhone
On Mar 16, 2009, at 1:15 AM, "jakub at gcc dot gnu dot org" > wrote:
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-16
08:15 ---
Reduced testcase:
/* { dg-do compile } */
/* { dg-options "-O2 -fprefetch-loop-arrays" } */
void
foo (char *x, unsign
--- Comment #5 from mt at debian dot org 2009-03-16 08:27 ---
Indeed, seems to be fixed in 4.4.0 (tested using Debian's gcc-snapshot, g++
(Debian 20090224-1) 4.4.0 20090224 (experimental)). Sorry for not testing using
a fresh build from 4.4 sources, but I hope that is helpful nevertheles
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-16 08:15 ---
Reduced testcase:
/* { dg-do compile } */
/* { dg-options "-O2 -fprefetch-loop-arrays" } */
void
foo (char *x, unsigned long y, unsigned char *z)
{
unsigned int c[256], *d;
for (d = c + 1; d < c + 256; ++d)
--- Comment #25 from jakub at gcc dot gnu dot org 2009-03-16 07:52 ---
I'd say first try to add noinline attribute on all callers of num_positive, if
it fails even with those, add also __attribute__((__optimize__(0))) to them one
by one. If the noinline attribute to those makes the misc
--- Comment #2 from ayers at gcc dot gnu dot org 2009-03-16 07:27 ---
So the situation seems to be:
- libobjc is a static library.
- libfoo is a dll statically linked against libobjc.
- test is program which is linked both against libfoo and libobjc.
I'm guessing here since I have no ex
74 matches
Mail list logo
