--- 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
--- 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
--- 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)
*d
--- 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
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment
--- 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 #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] =
--- 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/i386/i386.md
--
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 #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
--- 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 read
--- 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
--- 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 #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.)
Could
--- 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
--- 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
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:}
--- 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=gccview=revrev=144885
Log:
PR tree-optimization/39455
*
--- 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
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:
--- 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:
--- 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.
How so? =X
--- 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 #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
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 #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
--- 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 #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],
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:
--
The current implementation returns misleading results if used the wrong way. A
simple example is:
#include iostream
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
--- 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=17468action=view)
show inconsistency for is_abstract
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39475
--- 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
--- 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 #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 #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 #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=gccview=revrev=144890
Log:
PR testsuite/37628
*
--- 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=gccview=revrev=144891
Log:
PR testsuite/37630
* lib/target-supports.exp
--- 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=gccview=revrev=144892
Log:
PR testsuite/37960
* gcc.dg/pr11492.c: Replace
--- 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=17469action=view)
gcc44-pr39471.patch
Untested patch. Dodji, any reason why you started emitting
DW_TAG_imported_declaration for
--- 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 #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=gccview=revrev=144893
Log:
Revert patch for PR testsuite/37630.
Modified:
--- 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
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-03-16 21:37
---
Thanks although there is still excessive DW_AT_name:
3422: Abbrev Number: 12 (DW_TAG_imported_module)
425 DW_AT_name: A
427 DW_AT_import : 0x113 [Abbrev Number: 2 (DW_TAG_namespace)]
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 :
--- 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
--- 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
--- 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)
+++
--- 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 ==
--- 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 (
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 #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
--- 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 #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
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
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
--- 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
--- 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
--- 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
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
--- 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
--- 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
--- 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
--- 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
--- 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 #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.
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
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
GCC target triplet||i686-pc-linux-gnu
Target Milestone|---
--- 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
--- 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 #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
--
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 #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
--- 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
72 matches
Mail list logo
