[Bug middle-end/35308] Straight line strength reduction
--- Comment #2 from xinliangli at gmail dot com 2008-02-23 06:55 ---
(In reply to comment #1)
> Sometimes doing the strength reduction actually increases the code size.
> Think
> on targets which have auto increments.
>
> *** This bug has been marked as a duplicate of 22586 ***
>
Itanium supports address post increment. The postInc synthesis phase should
not be affected by the strengh reduced address computation code.
When this is fixed by the PRE framework, make sure the conditional increment
case is also covered:
a[i] = i*g;
if (...)
{
i++;
}
a[i] += ...
... = i*g;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35308
[Bug middle-end/35292] Missing Const Prop -- union fields
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 05:50 --- More than just constant prop, see PR 25972 for more info on what else it can be done with union in the same way. Actually I think MEM_REF will make it worse and will not help. In fact I still think MEM_REF is a bad idea and will cause worse aliasing issues with unions than that are already done. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35292
[Bug tree-optimization/25553] Missed removal of load
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-02-23 05:39 --- *** Bug 35304 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||xinliangli at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25553
[Bug middle-end/35304] Missing store sinking (code size optimization) at tree level
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 05:39 --- > should be (at least with -Os) And normal -O2. This is a dup of bug 25553 for the reasons why this should be done even at -O2. *** This bug has been marked as a duplicate of 25553 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35304
[Bug rtl-optimization/35309] Late struct expansion leads to missing PRE
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 05:34 --- GCSE should take care of this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement Component|middle-end |rtl-optimization Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35309
[Bug middle-end/35286] Missing PRE for globals
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 05:29 --- I think this is a dup of bug 23455. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35286
[Bug tree-optimization/22586] GVN-PRE could do strength reduction
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 05:27 --- *** Bug 35308 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||xinliangli at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22586
[Bug middle-end/35308] Straight line strength reduction
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 05:27 --- Sometimes doing the strength reduction actually increases the code size. Think on targets which have auto increments. *** This bug has been marked as a duplicate of 22586 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35308
[Bug middle-end/35310] New: Late struct expansion -- missing PRE (2)
union U {
struct A {
int a;
int b;
}aa;
long long ll;
};
struct B{
union U u1;
union U u2;
} bg;
struct B bg;
struct B bar();
int foo (int n)
{
if (n)
{
bg = bar();
}
return bg.u1.ll + bg.u2.ll;
};
// Two union fields loads are partially redundant.
gcc genearted code at -O2:
foo:
.LFB2:
subq$24, %rsp
.LCFI0:
testl %edi, %edi
je .L2
xorl%eax, %eax
callbar
movq%rax, bg(%rip)
movq%rdx, bg+8(%rip)
.L2:
movqbg(%rip), %rax
addlbg+8(%rip), %eax
addq$24, %rsp
ret
--
Summary: Late struct expansion -- missing PRE (2)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35310
[Bug middle-end/35309] New: Late struct expansion leads to missing PRE
// Example: the load of structs at return is partially redundant
struct A {
int a;
int b;
int c;
int d;
} ag, ag2,ag3;
struct A foo(int n)
{
if (n)
{
ag2 = ag;
}
return ag;
}
// Gcc generated assembly code:
foo:
.LFB2:
testl %edi, %edi
je .L2
movqag(%rip), %rax
movq%rax, ag2(%rip)
movqag+8(%rip), %rax
movq%rax, ag2+8(%rip)
.L2:
movqag+8(%rip), %rdx
movqag(%rip), %rax
ret
.LFE2:
--
Summary: Late struct expansion leads to missing PRE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35309
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-02-23 05:22 --- *** Bug 35303 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||xinliangli at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug middle-end/35303] Code hoisting optimization at tree level
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 05:22 --- *** This bug has been marked as a duplicate of 23286 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35303
[Bug middle-end/35308] New: Straight line strength reduction
Seems to be a missing functionality
int a[100];
int g;
void foo(int i)
{
a[i] = i*g;
i++;
a[i] = i*g;
i++;
a[i] = i*g;
}
Both array address computation and RHS mpy operations can be strength reduced.
--
Summary: Straight line strength reduction
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35308
[Bug middle-end/35307] New: Missing Simplication for div op
The following rule is good to have: int i, i, k; i/j/k ===> i/(j*k) -- Summary: Missing Simplication for div op Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: xinliangli at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35307
[Bug middle-end/35306] New: Missing expression simplication for conditional OR
The following rule is not handled by GCC (a & x) || (a & y) ===> a & (x | y) -- Summary: Missing expression simplication for conditional OR Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: xinliangli at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35306
[Bug middle-end/35305] New: Speculative PRE support missing
// File this bug to track the problem
int g1, g2;
void foo(int a, int b, int k,int m)
{
if (k)
{
#pragma execution_frequency(very_high)
g1 = a + b;
}
if (m)
{
#pragma execution_frequency(very_high)
g2 = a + b;
}
}
--
Summary: Speculative PRE support missing
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35305
[Bug middle-end/35304] New: Missing store sinking (code size optimization) at tree level
int* g;
void foo(int m)
{
if (m)
*g = 1;
else
*g = 2;
}
should be (at least with -Os)
void foo(int m)
{
if (m)
t = 1;
else
t = 2;
*g = t;
}
--
Summary: Missing store sinking (code size optimization) at tree
level
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35304
[Bug middle-end/35303] New: Code hoisting optimization at tree level
Missing code size optimization at tree level -- which is more flexible than RTL
level (allow hoisting memory operations).
int g1,g2;
int foo(int a, int b)
{
if (a)
g1 = a + b;
else if (b)
g2 = a+ b;
else
g3 = a + b
return g1 + g2;
}
With hoisting, it should be transformed into:
int g1, g2, g3;
int foo(int a, int b)
{
t = a+b;
if (a)
g1 = t;
else if (b)
g2 = t;
else
g3 = t;
return g1 + g2;
}
--
Summary: Code hoisting optimization at tree level
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35303
[Bug middle-end/35302] New: Missing partial dead store elimination
This is a known problem -- file it to keep track of it.
In the following example, stores at (1) -- the array initializers are partially
dead -- not sinked.
struct A{
int a[100];
};
const struct A aa = {1,1,1};
int foo(int i)
{
int s = 0;
struct A a = {1,1,1}; // (1)
if (i)
{
a = aa;
s += a.a[i];
}
s += a.a[i];
return s;
}
--
Summary: Missing partial dead store elimination
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35302
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
--- Comment #6 from kkylheku at gmail dot com 2008-02-23 05:06 --- (In reply to comment #5) > (In reply to comment #4) > > [crti.o is] found through multilib os-directory suffixes. > Actually, I'm even more confused, because the breakage I'm seeing is simply > arising from mips64-linux-ld being called on a bunch of object files, one of > which is crti.o. It's specified just like that. The linker won't search for > it; > it's expected to just be there. In fact if you run an strace -f job on the whole thing, you can see that the linker just tries to open "crti.o", gets an error and that's that. > --disable-multilib \ Oops, just noticed that. I don't think we want to be disabling multilib. I can't remember why that option was put in there. It hasn't caused any problems, though. The toolchain targets only one ABI, when we build it for MIPS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
--- Comment #5 from kkylheku at gmail dot com 2008-02-23 04:58 ---
(In reply to comment #4)
> [crti.o is] found through multilib os-directory suffixes.
Actually, I'm even more confused, because the breakage I'm seeing is simply
arising from mips64-linux-ld being called on a bunch of object files, one of
which is crti.o. It's specified just like that. The linker won't search for it;
it's expected to just be there. I will pop off these patches and see how the
link job was being done before.
> How did you configure GCC?
Binutils:
$SRC_ROOT/packages/unpacked/binutils-2.17/configure \
--target=$TARGET_ARCH \
--prefix=$CROSS_ROOT \
--disable-nls \
${TARGET_ABI:+--with-abi=$TARGET_ABI} \
${BUILD64+--enable-64-bit-bfd} \
--with-sysroot=$TARGET_ROOT
TARGET_ARCH is, e.g. mips64-linux. CROSS_ROOT is the root of a cross toolchain
and TARGET_ROOT is derived from that elsewhere (a subdirectory thereof).
TARGET_ABI is like "n32" for MIPS, for instance. Or unset for i686, in which
case the option isn't passed.
Final shared library GCC:
$SRC_ROOT/packages/unpacked/gcc-$VERSION/configure \
--host=$BUILD_ARCH-none-linux \
--build=$BUILD_ARCH-none-linux \
--target=$TARGET_ARCH \
--prefix=$CROSS_ROOT \
--with-sysroot=$TARGET_ROOT \
--with-gnu-ld \
--with-gnu-as \
--disable-libmudflap \
--disable-libada \
--disable-libssp \
--disable-multilib \
--enable-__cxa_atexit \
--enable-c99 \
--enable-long-long \
${TARGET_ABI:+--with-abi=$TARGET_ABI} \
--enable-languages=c,c++ \
--enable-threads=posix
> The standard_exec_prefix_1, et cetera patch is not necessary on HEAD and will
> conflict. In fact that's another of Carlos's patches.
I should pop those patches off and rework my stuff.
> I don't know about the
> update_path patch, but CodeSourcery's been building relocatable sysrooted
> compilers since before 4.1.1 and never encountered this problem. I think we
> avoid the code in prefix.c entirely.
In 4.1.1, update_path is called many tiems, since it's used by add_prefix. If
you load gcc under gdb and put a breakpoint on update_path, and then just run
even with no arguments you can see.
I've been building and relocating this toolchain also, apparently successfully.
It was the users who discovered these bad paths. They were looking at running
compiles with "ps" and noticed that collect2 was being called with -L options
specifying paths on the machine where the toolchain (and Linux distro) is
built. Our configuration manager is concerned that this may create problems. We
produce versioned, binary builds of the toolchain, and have Makefiles
referencing specific versions of a toolchain by pathname. If you check out last
week's build of some software, you get last week's Makefile which points to the
toolchain which was current then. If that toolchain uses some bad paths to pick
up executables or libraries outside of itself, this nice little scheme might in
fact not be so bullet-proof.
Thanks for any discussion. I will continue with this until it's solved. Sorry
about opening a bug, I just thought I had something, but it's a little bit more
elusive than I thought.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
--- Comment #4 from drow at gcc dot gnu dot org 2008-02-23 04:38 --- It's found through multilib os-directory suffixes. How did you configure GCC? The standard_exec_prefix_1, et cetera patch is not necessary on HEAD and will conflict. In fact that's another of Carlos's patches. I don't know about the update_path patch, but CodeSourcery's been building relocatable sysrooted compilers since before 4.1.1 and never encountered this problem. I think we avoid the code in prefix.c entirely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug preprocessor/35301] Function macro nesting depth appears to be uncomfortably limited.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 03:45 ---
I think this is correct CPP behavior.
it only evaluates one level of _ .
Think of:
#define a b
#define b a
b
a
What does that do?
it just does:
b
a
Instead of causing an infinite loop.
Once we try to revaluate _ again after evaluating it once from the macro
expansion, CPP no longer evaluates it again.
So the first time we expand xmallocq, we get _( progn ... , _(exssert_nexpr,
...) ) and then
we expand the two _(, we get:
progn(..., exssert_nexpr(...) ) and new expands progn and exssert_nexpr, we
get:
({void *gensym = malloc(20); _(exssert_with_epilogue_nexpr,
gensym == ((void *)0), (), "malloc returned NULL at: %s:%s, line %d","t.c",
__FUNCTION__, 27); gensym;});
And then since we already used _(x, ...), CPP can no longer expand anything so
it stops.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35301
[Bug preprocessor/35301] New: Function macro nesting depth appears to be uncomfortably limited.
It appears that CPP decides to stop expansion at some point.
Re-feeding the output to cpp iteratively peels macro levels.
#include
#include
#define _(op, ...) op(__VA_ARGS__)
#define _if(expr, then, els) if (expr) { then; } else { els; }
#define progn(...) ({__VA_ARGS__;})
#define when(expr, ...) _(_if, expr, \
_(progn, ## __VA_ARGS__), )
#define unless(expr, ...) _(_if, !(expr), \
_(progn, ## __VA_ARGS__), )
#define warn(format, ...) _(fprintf, stderr, format "\n", ## __VA_ARGS__)
#define when_warn(expr, tail, format, ...) _(when, expr, \
_(warn, format, ## __VA_ARGS__),
\
tail)
#define exssert_with_epilogue_nexpr(expr, epilogue, format, ...) _(when_warn,
expr, _(exit, 1), format, ## __VA_ARGS__)
#define exssert_nexpr(expr, format, ...) _(exssert_with_epilogue_nexpr, expr,
(), format, ## __VA_ARGS__)
#define xmallocq(size) _(progn, \
void *gensym = malloc(size); \
_(exssert_nexpr, gensym == NULL, \
"malloc returned NULL at: %s:%s, line %d",
__FILE__, __FUNCTION__, __LINE__); gensym)
int main()
{
xmallocq(20);
exit(0);
}
==>
int main()
{
({void *gensym = malloc(20); _(exssert_with_epilogue_nexpr,
gensym == ((void *)0), (), "malloc returned NULL at: %s:%s, line %d","",
__FUNCTION__, 88); gensym;});
exit(0);
}
--
Summary: Function macro nesting depth appears to be uncomfortably
limited.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: _deepfire at feelingofgreen dot ru
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35301
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
--- Comment #3 from kkylheku at gmail dot com 2008-02-23 02:18 --- Oops, I spoke to soon. The no-prefix-search path breaks my final gcc build, with shared libraries and glibc. When making libgcc_s.so, it can't find the crti.o module. What's happening is two problems. Firstly, it appears as if xgcc thinks it's already sysrooted; like it has already been installed and must look for the target libraries relative to itself as if its build directory was the sysroot. But of course, the real sysroot with glibc material is somewhere else entirely, and during this stage of the build, it must be referenced absolutely. Secondly, the crti.o module is actually in a /lib32 directory, because I'm building for the n32 ABI. xgcc has nothing ending in /lib32 in any of its search paths. *Head scratch*. How did this link step ever find crti.o before? -- kkylheku at gmail dot com changed: What|Removed |Added CC||kkylheku at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
--- Comment #2 from kkylheku at gmail dot com 2008-02-23 01:40 --- Created an attachment (id=15211) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15211&action=view) Hack to not have /lib and /usr/ paths in cross-compiler. I don't know whether this path is right in general, but it gets rid of questionable search paths in my cross toolchain. Should gcc ever (i.e. in any configuration) be unconditionally be looking in /usr/libexec/gcc and /usr/lib/gcc for executables and libraries? It doesn't seem right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
--- Comment #1 from kkylheku at gmail dot com 2008-02-23 01:35 --- Created an attachment (id=15210) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15210&action=view) Patch to gcc/prefix.c for path relocation. At some point gcc/gcc.c calls the function set_std_prefix in gcc/prefix.c to install a different prefix, overriding the original one which comes from the PREFIX variable at compile time (passed in via -DPREFIX when the file is compiled). The problem is that there is only one variable! The std_prefix variable is used to determine whether the path is inside the toolchain. However, the default substitution logic is that the key lookup for @GCC, @BINUTILS, et cetera will produce that same path. I.e. std_prefix is both the match and the default substitution, if the key doesn't resolve. And so the update_path function doesn't translate the path from the prefix to the relocated location. When the add_prefix function is called in various places in gcc.c to install search paths, in sometimes passes down paths from the original $prefix, which are recorded as string literals during compilation of gcc. These paths don't match the new prefix set up by the call to set_std_prefix, and so are entered into the list untranslated. The update_path function should use the original prefix to match against input paths, but then substitute the new path (if the @ translation doesn't produce any match). E.g. the path /original/libexec/bin should become (for example, if the key is "GCC") @GCC/libexec/bin. Then the @GCC substituion finds that the environment variable GCC_ROOT is not defined, and so substitutes /new to make /new/libexec/bin. Don't know if the current GCC has the problem, but a superficial skim through gcc/prefix.c tells me that nothing has changed there. So either the problem is not solved, or it's addressed by other logic elsewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug driver/35300] New: References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
I am seeing the following two problems problem in gcc 4.1.1.
The front-end driver contains paths from the --prefix where the toolchain was
built, when it is installed at a different location. It was built using
--with-sysroot.
I am aware of bug 17621, and have applied all of Carlos's patches to gcc 4.1.1.
They do not fix the behavior that I am seeing.
Secondly, some of the search paths are /usr/lib/.. and /lib/... which is
inappropriate for a cross compiler.
I have not tried a newer compiler, but I fixed these issues for myself in
4.1.1. (Which I have to do, since upgrading our toolchain is not in my
organization's near-term schedule, and fixing problems in our current toolchain
falls on me!)
Patches and discussion follow.
--
Summary: References to original ${prefix} paths in relocated
toolchain and /lib and /usr/lib search paths appear in
cross toolchain.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkylheku at gmail dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: mips64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #9 from matz at gcc dot gnu dot org 2008-02-23 00:40 --- Mine, have patch. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|WAITING |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|2008-02-22 23:41:03 |2008-02-23 00:40:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #8 from matz at gcc dot gnu dot org 2008-02-22 23:40 ---
I can confirm this, the code in foo is definitely wrong. When I compile
the (standard compliant, unlike the example from comment #4) with 4.2 or
4.3 on x86-64, with -O or -O2 it breaks:
% cat foo.c
long align;
int foo (int flag)
{
int variable;
if (flag == 0)
return 42;
align = (long)&variable;
return foo (flag - 1);
}
The asm code for foo():
foo:
subq$16, %rsp
testl %edi, %edi
movl$42, %eax
je .L4
leaq12(%rsp), %rax
subl$1, %edi
movq%rax, align(%rip)
callfoo
.L4:
addq$16, %rsp
ret
It's clear that this misaligns the stack for the next calls. On entry it's
8 mod 16, after the rsp adjustment it's still 8 mod 16, so in front of the
call it's also 8 mod 16, and boom. Just before calls %rsp needs to be
0 mod 16.
It seems to be important that this is a recursive call. This body does a
'sub $24', i.e. is correct:
int bar(int);
int foo (int flag)
{
int variable;
if (flag == 0)
return 42;
align = (long)&variable;
return bar (flag - 1);
}
The same is true, when I instead add a second call in the body (to bar()),
then the incoming argument is stored in %rbx, which needs saving, so there's
a push, and still a 'sub $16', i.e. again adjusting correctly.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
CC||jh at suse dot cz, matz at
||gcc dot gnu dot org
GCC target triplet|i386-apple-darwin8.11.1 |x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug fortran/35299] scope of variables in statement function do not acquire rank from host
-- kargl at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.3 4.4.0 Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35299
[Bug fortran/35299] New: scope of variables in statement function do not acquire rank from host
In a statement function, only the type and kind are determined from the host. gfortran fails to compile troutmask:kargl[205] cat n.f SUBROUTINE PHTOD(E,N,I,H) DIMENSION E(N) HSTAR(E,B)=B**.4*((1.25*FUN(-E/40)+.18)) ! Doesn't work. C HSTAR(X,Y)=Y**.4*((1.25*FUN(-X/40)+.18)) ! Works. A = 1. H = HSTAR(E(I-1), A) END troutmask:kargl[207] ftnchek n.f FTNCHEK Version 3.3 November 2004 File n.f: 0 syntax errors detected in file n.f No main program found Warning: Subprogram FUN never defined Invoked in module PHTOD line 3 file n.f (possibly it is an array which was not declared) troutmask:kargl[208] gfc -c n.f n.f:1.24: SUBROUTINE PHTOD(E,N,I,H) 1 Error: Argument 'e' of statement function at (1) must be scalar If the reference to FUN in statement function is changed to an elemental function, then one gets an additional error. Changing FUN to SIN yields troutmask:kargl[210] gfc -c n.f n.f:1.24: SUBROUTINE PHTOD(E,N,I,H) 1 Error: Argument 'e' of statement function at (1) must be scalar n.f:3.11: HSTAR(E,B)=B**.4*((1.25*SIN(-E/40)+.18)) ! Doesn't work. 1 Error: Incompatible ranks 0 and 1 in assignment at (1) Because statement functions are obselscent in Fortran 95, this should be considered a very low priority bug. -- Summary: scope of variables in statement function do not acquire rank from host Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35299
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #47 from fxcoudert at gcc dot gnu dot org 2008-02-22 23:12 --- (In reply to comment #18) > the list of functions to fix by Mike > (where non-builtins have been removed, and variadic functions are fixed > conditionaly on macos_version_min, as per Geoff's advice... Modifying patch and restarting regtesting, because I just discovered that with -m64, the variadic functions should not be fixed at all (whatever the macos_version_min). I note it here for completeness of our records :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #18 from joel at gcc dot gnu dot org 2008-02-22 22:35 --- (In reply to comment #17) > If you have it on CFARM let me know where and what command to launch to gdb > your testcase. I have been building and running it on my laptop but there is now enough on CFARM to run it. qemu -M isapc -m 8 -boot a -fda /home/joel/qemu/pc386_fda \ -hda fat:/home/joel/qemu/hd -serial stdio will run the program without a debugger. It pops up an xterm-ish thing and shows a srub menu before the output switches to the serial port which is redirected to stdio. Just copy /home/joel/qemu from gcc12 and change paths as appropriate. Add "-s" on the end of the qemu command line and it has a gdb server. Start qemu and quickly in another window do this: gdb --command g t.exe g has a "target remote" command in it which attaches to the qemu. qemu has some debug trace which is interesting and how I got started. Add "-d in_asm,cpu" and will dump a lot of info on assembly instructions and cpu state into /tmp/qemu.log. For your convenience, there is a pr35284-a/ subdirectory under ~/qemu which is a copy of my current build directory. > What does RTEMS ada_pthread_minimum_stack_size returns in both case (under > gdb)? > 16K. Just like a good one line routine should. :-D I will email you from my gmail account so if you need to ping me this weekend you can. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #17 from laurent at guerby dot net 2008-02-22 22:02 --- If you have it on CFARM let me know where and what command to launch to gdb your testcase. What does RTEMS ada_pthread_minimum_stack_size returns in both case (under gdb)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #16 from joel at gcc dot gnu dot org 2008-02-22 22:01 --- I can add mips/jmr3904 to the list that runs t.adb correctly. So we have this as a summary: sparc/sis, powerpc/psim, mips/jmr3904, arm/edb7312 - t.adb runs OK i386/pc386 fails bfin/exkit533 - GNAT bug bo I doublechecked the RTEMS target specific files used on each configuration from the build log. They are the same. Is there anything specific to the x86 the target entry in the Makefile.in might be missing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #15 from joel at gcc dot gnu dot org 2008-02-22 21:56 ---
(In reply to comment #14)
> Default values come from ada/s-parame-rtems.adb, for the stack it ends up in
> RTEMS ada_pthread_minimum_stack_size:
>
> package body System.Parameters is
>
>function ada_pthread_minimum_stack_size return Interfaces.C.size_t;
>pragma Import (C, ada_pthread_minimum_stack_size,
> "_ada_pthread_minimum_stack_size");
This is called twice on powerpc and i386 and both appear to be from the
same backtrace. The first is where the rtems_init.c creates the ada_main
thread. The second back traces to here:
#0 _ada_pthread_minimum_stack_size ()
at ../../../../../../../423/rtems/c/src/../../cpukit/libgnat/adasupp.c:24
#1 0x001040a7 in system.tasking.initialize_atcb (self_id=0x1dda08,
task_entry_point=0x1752ce, task_arg=1528516, parent=0x1dda08,
elaborated=0x1752cd, base_priority=0, task_info=2, stack_size=-2147483648,
t=0x1de1f4) at s-taskin.adb:136
#2 0x0010577e in system.tasking.stages.create_task (priority=-1,
size=-2147483648, task_info=2, num_entries=0, master=4, state=0x1752ce,
discriminants=1528516, elaborated=0x1752cd, [EMAIL PROTECTED], task_image=
{P_ARRAY = 0x138948, P_BOUNDS = 0x138954}, created_task=0x0)
at s-tassta.adb:605
#3 0x001005d7 in t () at t.adb:3
>
>
>-- Default_Stack_Size --
>
>
>function Default_Stack_Size return Size_Type is
>begin
> return Size_Type (ada_pthread_minimum_stack_size);
>end Default_Stack_Size;
> ...
>
> In ada/s-tassta.adb above line 333 you should be able to trace where Priority
> and Stack_Size come from, compare between the two targets:
>
> -- Activate all the tasks in the chain. Creation of the thread of
> -- control was deferred until activation. So create it now.
>
> C := Chain_Access.T_ID;
> while C /= null loop
> if C.Common.State /= Terminated then
> pragma Assert (C.Common.State = Unactivated);
>
> P := C.Common.Parent;
> Write_Lock (P);
> Write_Lock (C);
>
> if C.Common.Base_Priority < Get_Priority (Self_ID) then
>Activate_Prio := Get_Priority (Self_ID);
> else
>Activate_Prio := C.Common.Base_Priority;
> end if;
Both powerpc and i386 take the else path.
Breakpoint 1, system.tasking.stages.activate_tasks (chain_access=0x1752c8)
at s-tassta.adb:332
332 if C.Common.Base_Priority < Get_Priority (Self_ID) then
(gdb) n
335Activate_Prio := C.Common.Base_Priority;
(gdb)
338 System.Task_Primitives.Operations.Create_Task
> System.Task_Primitives.Operations.Create_Task
> (C, Task_Wrapper'Address,
>Parameters.Size_Type
> (C.Common.Compiler_Data.Pri_Stack_Info.Size),
>Activate_Prio, Success);
> ...
>
I haven't had much luck dereferencing the C.Common stuff or figuring out where
it is.
FWIW this is pretty easy to debug with qemu, a 1.44 MB floppy file, and the
executable. I double checked and you can even use the native Fedora 8 gdb.
qemu speaks gdb remote protocol.
Sorry for not having more information. I checked and at the end of the
run, each RTEMS thread control block shows an RTEMS native priority of
253 (255 being lowest natively). On the PowerPC the threads have a native
priority of 133 which is in the middle of the 1-254 range. I have no idea
why it is pulling a 0 out of the air. :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug c++/34715] [4.3 Regression] always_inline with templates and not declared as always_inline but definition has it
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-02-22 21:52 --- Subject: Bug 34715 Author: pinskia Date: Fri Feb 22 21:51:19 2008 New Revision: 132560 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132560 Log: 2008-02-22 Andrew Pinski <[EMAIL PROTECTED]> PR C++/34715 * decl.c (duplicate_decls): Merge DECL_DISREGARD_INLINE_LIMITS for template decls' function decl. 2008-02-22 Andrew Pinski <[EMAIL PROTECTED]> PR C++/34715 * g++.dg/ext/always_inline-1.C: New test. * g++.dg/ext/always_inline-2.C: New test. * g++.dg/ext/always_inline-3.C: New test. * g++.dg/ext/always_inline-4.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/always_inline-1.C - copied unchanged from r132558, trunk/gcc/testsuite/g++.dg/ext/always_inline-1.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/always_inline-2.C - copied unchanged from r132558, trunk/gcc/testsuite/g++.dg/ext/always_inline-2.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/always_inline-3.C - copied unchanged from r132558, trunk/gcc/testsuite/g++.dg/ext/always_inline-3.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/always_inline-4.C - copied unchanged from r132558, trunk/gcc/testsuite/g++.dg/ext/always_inline-4.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/decl.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34715
[Bug c++/34715] [4.3 Regression] always_inline with templates and not declared as always_inline but definition has it
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-02-22 21:50 --- Fixed, thanks for your bug report. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34715
[Bug c++/34715] [4.3/4.4 Regression] always_inline with templates and not declared as always_inline but definition has it
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-02-22 21:21 --- Subject: Bug 34715 Author: pinskia Date: Fri Feb 22 21:21:11 2008 New Revision: 132558 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132558 Log: 2008-02-22 Andrew Pinski <[EMAIL PROTECTED]> PR C++/34715 * decl.c (duplicate_decls): Merge DECL_DISREGARD_INLINE_LIMITS for template decls' function decl. 2008-02-22 Andrew Pinski <[EMAIL PROTECTED]> PR C++/34715 * g++.dg/ext/always_inline-1.C: New test. * g++.dg/ext/always_inline-2.C: New test. * g++.dg/ext/always_inline-3.C: New test. * g++.dg/ext/always_inline-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/always_inline-1.C trunk/gcc/testsuite/g++.dg/ext/always_inline-2.C trunk/gcc/testsuite/g++.dg/ext/always_inline-3.C trunk/gcc/testsuite/g++.dg/ext/always_inline-4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34715
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #14 from laurent at guerby dot net 2008-02-22 21:12 --- Default values come from ada/s-parame-rtems.adb, for the stack it ends up in RTEMS ada_pthread_minimum_stack_size: package body System.Parameters is function ada_pthread_minimum_stack_size return Interfaces.C.size_t; pragma Import (C, ada_pthread_minimum_stack_size, "_ada_pthread_minimum_stack_size"); -- Default_Stack_Size -- function Default_Stack_Size return Size_Type is begin return Size_Type (ada_pthread_minimum_stack_size); end Default_Stack_Size; ... In ada/s-tassta.adb above line 333 you should be able to trace where Priority and Stack_Size come from, compare between the two targets: -- Activate all the tasks in the chain. Creation of the thread of -- control was deferred until activation. So create it now. C := Chain_Access.T_ID; while C /= null loop if C.Common.State /= Terminated then pragma Assert (C.Common.State = Unactivated); P := C.Common.Parent; Write_Lock (P); Write_Lock (C); if C.Common.Base_Priority < Get_Priority (Self_ID) then Activate_Prio := Get_Priority (Self_ID); else Activate_Prio := C.Common.Base_Priority; end if; System.Task_Primitives.Operations.Create_Task (C, Task_Wrapper'Address, Parameters.Size_Type (C.Common.Compiler_Data.Pri_Stack_Info.Size), Activate_Prio, Success); ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #13 from joel at gcc dot gnu dot org 2008-02-22 20:53 --- Laurent's t.adb works on arm/edb7312. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35298] GNAT Bug Box
--- Comment #1 from joel at gcc dot gnu dot org 2008-02-22 20:35 --- Created an attachment (id=15209) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15209&action=view) Source file which triggers error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35298
[Bug ada/35298] New: GNAT Bug Box
I decided to see what other targets did with Laurent's t.adb program (see PR35284). My first attempt was bfin which died with this error. bfin-rtems4.9-gcc -c -g -I/home/joel/work-gnat/svn/bsp-install/bfin-rtems4.9/eZKit533//lib/include/adainclude -O -gnata -gnatE -gnato -g t.adb +===GNAT BUG DETECTED==+ | 4.4.0 20080220 (experimental) [trunk revision 132490] (bfin-unknown-rtems4.9) GCC error:| | in int_mode_for_mode, at stor-layout.c:258 | | Error detected around t.adb:2| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. t.adb raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:398 End of compilation bfin-rtems4.9-gnatmake: "t.adb" compilation error -- Summary: GNAT Bug Box Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: bfin-rtems4.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35298
[Bug libgomp/33131] [4.2 regression] libgomp/env.c:60: warning: implicit declaration of function 'strncasecmp'
--- Comment #3 from bugzilla-gcc at thewrittenword dot com 2008-02-22 20:23 --- Created an attachment (id=15208) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15208&action=view) patch to include string.h and strings.h (stolen from libcpp) Patch does not include generated files (configure, config.h.in) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33131
[Bug tree-optimization/32328] [4.2 Regression] -fstrict-aliasing causes skipped code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug ada/34289] Systematic recompilation of up-to-date object files when using the "-s" gnatmake option GNAT 4.3.0 on x86-*-Darwin8
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2008-02-22 18:28 --- Taking care of it. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-02-22 18:27:40 |2008-02-22 18:28:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
[Bug ada/34289] Systematic recompilation of up-to-date object files when using the "-s" gnatmake option GNAT 4.3.0 on x86-*-Darwin8
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-02-22 18:27 --- Thanks for the report, analysis and patch. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-22 18:27:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
[Bug tree-optimization/32328] [4.2 Regression] -fstrict-aliasing causes skipped code
--- Comment #30 from tdragon at tdragon dot net 2008-02-22 18:14 --- Are there sufficient motivation and resources to fix this bug in 4.2? Since 4.3 is soon-to-be, an update on this would be sincerely appreciated -- even if it's just forgetting about 4.2 and resolving as FIXED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug c++/34094] [4.2/4.3 Regression] Undefined static data member in anonymous namespace can acquire a definition anyway
--- Comment #19 from jason at gcc dot gnu dot org 2008-02-22 18:03 --- Seems Darwin doesn't track the source position of undefined symbol references. Feel free to improve the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug middle-end/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-22 17:58 --- As when you say bigger do you mean the assembly is different sizes? Or do you mean the actually text/data sections are bigger in the object file? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug c++/34094] [4.2/4.3 Regression] Undefined static data member in anonymous namespace can acquire a definition anyway
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-02-22 17:50 --- g++.dg/other/anon5.C fails on i386-darwin: /var/tmp//ccpes1Oj.s:20:non-relocatable subtraction expression, "__ZN12_GLOBAL__N_11c1tE" minus "L001$pb"^M /var/tmp//ccpes1Oj.s:20:symbol: "__ZN12_GLOBAL__N_11c1tE" can't be undefined in a subtraction expression^M compiler exited with status 1 output is: /var/tmp//ccpes1Oj.s:20:non-relocatable subtraction expression, "__ZN12_GLOBAL__N_11c1tE" minus "L001$pb"^M /var/tmp//ccpes1Oj.s:20:symbol: "__ZN12_GLOBAL__N_11c1tE" can't be undefined in a subtraction expression^M -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug c++/35297] New: Compiling error with variadic template with fixed parameter with default type.
Hi,
the following code fails to compile with gcc-4.3-20080215
template
struct test {};
int main()
{
test<> a;
return 0;
}
According to N2242 section 3.6, page 7:
If a template-parameter of a class template has a default template-argument,
each subsequent template-parameter shall either have a default
template-argument supplied or be a template parameter pack. If a
template-parameter of a class template is a template parameter pack, it must be
the last template-parameter.
The compiler issues the following error: no default argument for ‘ARGS’ at
line 1 above.
--
Summary: Compiling error with variadic template with fixed
parameter with default type.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rodolfo at rodsoft dot org
GCC build triplet: *-*-*-*
GCC host triplet: *-*-*-*
GCC target triplet: *-*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35297
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #12 from joel at gcc dot gnu dot org 2008-02-22 16:43 --- I just noticed that the stack size passed to system.task_primitives.operations.create_task is also 0 in the back trace on the i386. It is 32724 on the PowerPC. So two parameters are bad. The 0 just indicates that the pthread code should use the default stack size so it happens to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug fortran/35285] Failures in the NIST test suite FM827 with -m64
--- Comment #4 from dominiq at lps dot ens dot fr 2008-02-22 16:21 --- Forgot to give the result: avd= -1.00 should be:0.00 fails -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35285
[Bug fortran/35285] Failures in the NIST test suite FM827 with -m64
--- Comment #3 from dominiq at lps dot ens dot fr 2008-02-22 16:17 --- Sorry, I have been too fast. The test in comment #1 fails with -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35285
[Bug fortran/35285] Failures in the NIST test suite FM827 with -m64
--- Comment #2 from dominiq at lps dot ens dot fr 2008-02-22 16:01 --- Subject: Re: Failures in the NIST test suite FM827 with -m64 The test in comment #1 pass. I have forgotten to say that the arithmetic IF is needed for the failure and that removing any one of the four left test cases make the test to pass. What would be helpful that people having a mac intel with 10.5.2 confirm the failure and people with earlier OSX check if the test fails or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35285
[Bug fortran/35285] Failures in the NIST test suite FM827 with -m64
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-02-22 15:45 --- Works for me. Can you try this test case: program fm827 double precision avd, bvd, cvd, dvd, dvcorr ct010* test 10 tanh(x) = 1 - 2/(exp(2x)+1) bvd = 5.0d0 cvd = 2.0d0 dvd = dlog10(bvd * cvd) - dsqrt(4.0d0) / 1 (dexp(2.0d0 * (bvd - cvd)) + dcos(0.0d0)) avd = dvd - dtanh(3.0d0) print *, "avd=",avd," should be: ", 0.0_8 if (abs(avd) > 0.50d-09) then print *, "fails" else print *, "passes" end if end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35285
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #11 from joel at gcc dot gnu dot org 2008-02-22 15:34 ---
Good Morning! By setting a breakpoint on _CPU_Context_switch in RTEMS, I can
see where things went wrong. On both SPARC and PowerPC, we dispatched out of
this backtrace:
(gdb) bt
#0 pthread_setschedparam (thread=184614915, policy=0, param=0x175000)
at ../../cpukit/../../../pc386/lib/include/rtems/score/thread.inl:209
#1 0x0010118f in system.task_primitives.operations.set_priority (t=0x1de1f4,
prio=0, loss_of_inheritance=0) at s-taprop.adb:777
#2 0x0010121d in system.task_primitives.operations.create_task (t=0x1de1f4,
wrapper=1072820, stack_size=0, priority=0) at s-taprop.adb:1016
#3 0x00105a99 in system.tasking.stages.activate_tasks (chain_access=0x1752c8)
at s-tassta.adb:338
#4 0x001005ea in t () at t.adb:2
At this point, the Ada run-time is setting the priority of the POSIX
thread it just created.
On the PowerPC (and I assume SPARC since it works there also), the
contents of the scheduling parameter structure is:
(gdb) p *param
$1 = {sched_priority = 122, ss_low_priority = 7462340, ss_replenish_period = {
tv_sec = 0, tv_nsec = 0}, ss_initial_budget = {tv_sec = 1,
tv_nsec = 32724}}
On the i386, this same structure at the same point in RTEMS has this:
$1 = {sched_priority = 0, ss_low_priority = 2, ss_replenish_period = {
tv_sec = 0, tv_nsec = 0}, ss_initial_budget = {tv_sec = 0, tv_nsec = 0}}
The sched_priority field is NOT a valid priority and RTEMS returns EINVAL.
There is a pragma assert after this call in the Ada
system.task_primitives.operations.set_priority so I assume assertions
are disabled. FWIW sys/sched.h is the same file with no CPU ifdefs
on all RTEMS targets.
Since this is the first field in the structure, we are not dealing with
an alignment problem. All of the Ada run-time target specific files
for RTEMS are shared across the architectures so I doubt that is a problem.
I noticed that in the good backtrace, I see this:
#0 pthread_setschedparam (thread=184614915, policy=0, param=0x744c30)
at
../../../../../../../423/rtems/c/src/../../cpukit/posix/src/pthreadsetschedparam.c:47
#1 0x1954 in system.task_primitives.operations.set_priority (t=0x5e868,
prio=122, loss_of_inheritance=) at s-taprop.adb:777
#2 0x1a38 in system.task_primitives.operations.create_task (t=0x5e868,
wrapper=32724, stack_size=32768, priority=122) at s-taprop.adb:1016
#3 0x7bb4 in system.tasking.stages.activate_tasks (chain_access=0x744d34)
at s-tassta.adb:338
#4 0x07ec in t () at t.adb:2
In the bad backtrace, I see this:
#0 0x0010118f in system.task_primitives.operations.set_priority (t=0x1de1f4,
prio=0, loss_of_inheritance=0) at s-taprop.adb:777
#1 0x0010121d in system.task_primitives.operations.create_task (t=0x1de1f4,
wrapper=1072820, stack_size=0, priority=0) at s-taprop.adb:1016
#2 0x00105a99 in system.tasking.stages.activate_tasks (chain_access=0x1752c8)
at s-tassta.adb:338
#3 0x001005ea in t () at t.adb:2
Notice that create.task is passed a 0 for priority on the i386 and a 122 on the
good backtrace.
What to look at next? That bad priority value has to come from somewhere.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-02-22 15:34:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug target/35296] New: init_expr_once suboptimal for Thumb
init_expr_once sets direct_load and direct_store arrays, which are indexed by mode. These are supposed to indicate "can we load a value of this mode from memory" and similar for store. It does this by passing a bunch of (set (reg) (mem)) instructions to recog. At the top of the function: /* Try indexing by frame ptr and try by stack ptr. It is known that on the Convex the stack ptr isn't a valid index. With luck, one or the other is valid on any machine. */ mem = gen_rtx_MEM (VOIDmode, stack_pointer_rtx); mem1 = gen_rtx_MEM (VOIDmode, frame_pointer_rtx); That's actually base, not index, in current GCC parlance. And the assumption isn't true for Thumb. You can load SImode using [sp], but not QImode. And frame_pointer_rtx is a pseudo that isn't valid to index off of anyway. The hard frame pointer is r7 for Thumb, and that would be a valid index. Possibilities: also check hard_frame_pointer_rtx, also check a target-specified register, find a valid register for each mode using ok_for_base_1. The last seems best except it would be the earliest call to REGNO_OK_FOR_BASE_P et cetera in the compiler. The ARM version will crash if reg_renumber isn't allocated. This isn't a big problem because we'll go on to handle QImode loads as bitfield accesses and bitfield optimizations will more or less sort things out. Fixing it might enable some other RTL optimizations though. -- Summary: init_expr_once suboptimal for Thumb Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org GCC target triplet: arm*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35296
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #46 from bonzini at gnu dot org 2008-02-22 15:20 --- Subject: Re: builtin functions should use $LDBL128 suffix on darwin when appropriate [off bugzilla] I think FX is going to submit a patch soon. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2008-02-22
15:11 ---
I believe the code that assigns the function names in fortran is
#define DO_DEFINE_MATH_BUILTIN(code, name, argtype, tbase) \
gfc_define_builtin ("__builtin_" name "l", tbase##longdouble[argtype], \
BUILT_IN_ ## code ## L, name "l", true); \
gfc_define_builtin ("__builtin_" name, tbase##double[argtype], \
BUILT_IN_ ## code, name, true); \
gfc_define_builtin ("__builtin_" name "f", tbase##float[argtype], \
BUILT_IN_ ## code ## F, name "f", true);
#define DEFINE_MATH_BUILTIN(code, name, argtype) \
DO_DEFINE_MATH_BUILTIN (code, name, argtype, mfunc_)
#define DEFINE_MATH_BUILTIN_C(code, name, argtype) \
DO_DEFINE_MATH_BUILTIN (code, name, argtype, mfunc_) \
DO_DEFINE_MATH_BUILTIN (C##code, "c" name, argtype, mfunc_c)
in gcc/fortran/f95-lang.c. The last time looked at Andrews proposed
patch, it setting all of the assembler names in a call to
darwin_patch_builtin but none of these are used by the final
assignment of DO_DEFINE_MATH_BUILTIN() in 95-lang.c. Also it
is possible that Andrew's original patch is regressed relative
to gcc trunk...
http://gcc.gnu.org/ml/fortran/2007-05/msg00499.html
http://gcc.gnu.org/ml/fortran/2007-05/msg00501.html
http://gcc.gnu.org/ml/fortran/2007-05/msg00505.html
http://gcc.gnu.org/ml/fortran/2007-05/msg00511.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #44 from fxcoudert at gcc dot gnu dot org 2008-02-22 15:09
---
(In reply to comment #42)
> (There is one exception: calls to cpowl generated by the Fortran front-end
> seem
> not to work, but it is a front-end issue: we don't treat cpow?() functions as
> builtins, probably a left-over from an earlier cleanup of that part of the
> front-end.)
With the trivial fix to the front-end, it now works fine. Well, the testcase
still doesn't pass, because Apple has a crazy erfl() implementation:
$ cat erf.c
#include
#include
int main(void)
{
long double x = 1.45123231;
double y = x;
printf ("%g %g\n", (float) erfl(x), (float) erf(y));
return 0;
}
$ gcc erf.c && ./a.out
-2.12115 0.959865
But at least, that's not my problem!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #43 from bonzini at gnu dot org 2008-02-22 15:08 --- I don't think you have to be afraid. Note that with your patch there wouldn't even be need to patch math.h -- in other words, your patch DTRT and it should have been done this way ever since the feature was introduced in the compiler. Pity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #42 from fxcoudert at gcc dot gnu dot org 2008-02-22 14:59 --- (In reply to comment #39) > Actually, I think we're almost there. You have to prepend an > underscore. You're right, and it works. I'm a bit afraid of doing so (if it's handled everywhere else, why isn't it handled for us?), but it does work. (There is one exception: calls to cpowl generated by the Fortran front-end seem not to work, but it is a front-end issue: we don't treat cpow?() functions as builtins, probably a left-over from an earlier cleanup of that part of the front-end.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #41 from bonzini at gnu dot org 2008-02-22 14:53 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
ubizjak at gmail dot com wrote:
> --- Comment #40 from ubizjak at gmail dot com 2008-02-22 14:49 ---
> This simple proof-of-concept patch works as expected:
I would very much prefer to see set_user_assembler_name first...
This excerpt from my math.h confirms that you need an underscore:
#if ( __WANT_LONG_DOUBLE_FORMAT__ - 0L == 128L )
#define __LIBMLDBL_COMPAT(sym) __asm("_" __STRING(sym) "$LDBL128")
#elif ( __WANT_LONG_DOUBLE_FORMAT__ - 0L == 64L )
#define __LIBMLDBL_COMPAT(sym) /* NOTHING */
#else
#define __LIBMLDBL_COMPAT(sym) /* NOTHING */
#endif
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #40 from ubizjak at gmail dot com 2008-02-22 14:49 ---
This simple proof-of-concept patch works as expected:
--cut here--
Index: langhooks.c
===
--- langhooks.c (revision 132541)
+++ langhooks.c (working copy)
@@ -557,6 +557,9 @@ add_builtin_function (const char *name,
gcc_assert (DECL_FUNCTION_CODE (decl) >= function_code);
DECL_FUNCTION_CODE (decl) = function_code;
+ if (function_code == BUILT_IN_SINL)
+library_name = "sinl$LDBL128";
+
if (library_name)
{
tree libname = get_identifier (library_name);
--cut here--
test_:
jmp sinl$LDBL128
test:
jmp sinl$LDBL128
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug c/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 14:38 --- Do you have a testcase? The constants should be printed according to their mode, which is target dependent. The host representation should not matter apart for the biggest supported mode. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #39 from bonzini at gnu dot org 2008-02-22 14:36 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
>> I think you should use set_user_assembler_name instead of
>> SET_DECL_ASSEMBLER_NAME.
>
> Nope. Doing this gives, for you C testcase with test and test_:
>
> Undefined symbols:
> "sinl$LDBL128", referenced from:
> _test_ in ccYtxtFH.o
And for Fortran?
Actually, I think we're almost there. You have to prepend an
underscore. Symbols in my
/System/Library/Frameworks/System.framework/Versions/Current/System look
like this:
90175020 T _cosl$LDBL128
901751c0 T _sinl$LDBL128
90175350 T _tanl$LDBL128
90176140 T _cbrtl$LDBL128
901764d0 T _sqrtl$LDBL128
90176c00 T _nanl$LDBL128
90176e70 T _nanl$LDBL64
You have to use set_user_assembler_name because: 1) that's what the
__asm__ ("_sinl$LDBL128") directives do; 2) the assembler name is right,
but the DECL_RTL is wrong in your dumps, and set_user_assembler_name
resets the DECL_RTL so that it is recomputed.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug libfortran/35293] [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-02-22 14:19 --- oops, the file name is foo.txt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293
[Bug c/35295] New: 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
We are cross-compiling to a 32-bit ARM target from both 32-bit and 64-bit PCs. The gcc cross-compiler toolchain (3.4.6) generates valid code in both cases, but the generated code is larger when a 64-bit host is used. We have tracked this down to the following: 1) The RTL is using 64-bit (on the 64-bit host) to represent constants that is calculated as part of the code-generation. Perhaps because print-rtl.c is using HOST_WIDE_INT_xxx in some places. Surely any kind of constant number even in high level RTL should be using the *target* int size and not the host? 2) The 64-bit constants are treated as such and thus generates more assembler instructions to deal with the 64-bit number on the 32-bit target. We have fixed the toolchain with a workaround where "-m32" is used to compile the entire toolchain as 32-bit, but I think the correct solution would be to ensure that constants used in the RTL are represented using the target format in stead of the host. As far as I can see from the code (print-rtl.c) the problem is still there in gcc 4.2.3. -- Summary: 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: benny at ammitzboell-consult dot dk GCC build triplet: i686-pc-linux-gnu / x86_64-unknown-linux-gnu GCC host triplet: i686-pc-linux-gnu / x86_64-unknown-linux-gnu GCC target triplet: arm-uclinux-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug c/35294] New: iwmmxt intrinsics, internal compiler error
Compiling this simple function:
#include
void foo()
{
_mm_srli_pi16(_mm_setzero_si64(), 8);
}
with the command line arm-angstrom-linux-gnueabi-gcc -c -O2 iwmmxt.cpp, results
in:
/home/qt/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/gcc-cross-4.1.2-r10/image/home/qt/gumstix/gumstix-oe/tmp/cross/bin/../lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/include/mmintrin.h:
In function 'void foo()':
/home/qt/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/gcc-cross-4.1.2-r10/image/home/qt/gumstix/gumstix-oe/tmp/cross/bin/../lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/include/mmintrin.h:529:
internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:12551
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
/home/qt/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/gcc-cross-4.1.2-r10/image/home/qt/gumstix/gumstix-oe/tmp/cross/bin/../lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/include/mmintrin.h:
In function 'foo':
/home/qt/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/gcc-cross-4.1.2-r10/image/home/qt/gumstix/gumstix-oe/tmp/cross/bin/../lib/gcc/arm-angstrom-linux-gnueabi/4.1.2/include/mmintrin.h:529:
internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:12551
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ arm-angstrom-linux-gnueabi-gcc -v
Using built-in specs.
Target: arm-angstrom-linux-gnueabi
Configured with:
/home/qt/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/gcc-cross-4.1.2-r10/gcc-4.1.2/configure
--build=x86_64-linux --host=x86_64-linux --target=arm-angstrom-linux-gnueabi
--prefix=/home/qt/gumstix/gumstix-oe/tmp/cross
--exec_prefix=/home/qt/gumstix/gumstix-oe/tmp/cross
--bindir=/home/qt/gumstix/gumstix-oe/tmp/cross/bin
--sbindir=/home/qt/gumstix/gumstix-oe/tmp/cross/bin
--libexecdir=/home/qt/gumstix/gumstix-oe/tmp/cross/libexec
--datadir=/home/qt/gumstix/gumstix-oe/tmp/cross/share
--sysconfdir=/home/qt/gumstix/gumstix-oe/tmp/cross/etc
--sharedstatedir=/home/qt/gumstix/gumstix-oe/tmp/cross/com
--localstatedir=/home/qt/gumstix/gumstix-oe/tmp/cross/var
--libdir=/home/qt/gumstix/gumstix-oe/tmp/cross/lib
--includedir=/home/qt/gumstix/gumstix-oe/tmp/cross/include
--oldincludedir=/home/qt/gumstix/gumstix-oe/tmp/cross/include
--infodir=/home/qt/gumstix/gumstix-oe/tmp/cross/share/info
--mandir=/home/qt/gumstix/gumstix-oe/tmp/cross/share/man --with-gnu-ld
--enable-shared --enable-target-optspace --enable-languages=c,c++
--enable-threads=posix --enable-multilib --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=arm-angstrom-linux-gnueabi-
--with-local-prefix=/home/qt/gumstix/gumstix-oe/tmp/staging/arm-angstrom-linux-gnueabi
--with-gxx-include-dir=/home/qt/gumstix/gumstix-oe/tmp/staging/arm-angstrom-linux-gnueabi/include/c++
--enable-__cxa_atexit --with-float=soft --disable-libssp
--disable-libunwind-exceptions
--with-mpfr=/home/qt/gumstix/gumstix-oe/tmp/staging/x86_64-linux
Thread model: posix
gcc version 4.1.2
--
Summary: iwmmxt intrinsics, internal compiler error
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: haavardw at ifi dot uio dot no
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #38 from fxcoudert at gcc dot gnu dot org 2008-02-22 14:11
---
(In reply to comment #34)
> long double test(long double x) { return sinl(x); }
> long double test_(long double x) { return __builtin_sinl(x); }
>
> test_:
> jmp sinl$LDBL128
> test:
> jmp sinl
I get the same thing with my patch. Isn't that just because sinl, without
prototype, is seen as an extern function? (I don't know much about this)
I get a warning, though:
t.c:1: warning: incompatible implicit declaration of built-in function 'sinl'
Anyway, Fortran uses the function decls for BUILT_IN_SINL, which is the builtin
one, so it shouldn't matter, should it?
(In reply to comment #36)
> I think you should use set_user_assembler_name instead of
> SET_DECL_ASSEMBLER_NAME.
Nope. Doing this gives, for you C testcase with test and test_:
Undefined symbols:
"sinl$LDBL128", referenced from:
_test_ in ccYtxtFH.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug libfortran/35293] [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-02-22 14:10 --- Created an attachment (id=15207) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15207&action=view) Modified streamio_15.f90 test case hp, can you try this test case and post the output and also a hex dump of the content of the file "fort.20". The problem is on cris-elf? Are you testing with a simulator on x86_64-unknown-linux-gnu? I am trying to understand the environment. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #37 from bonzini at gnu dot org 2008-02-22 14:03 --- (Not that I knew that this morning, of course). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #36 from bonzini at gnu dot org 2008-02-22 14:02 --- I think you should use set_user_assembler_name instead of SET_DECL_ASSEMBLER_NAME. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #35 from ubizjak at gmail dot com 2008-02-22 13:49 --- Hm... /* Worker for DEF_BUILTIN. Possibly define a builtin function with one or two names. Does not declare a non-__builtin_ function if flag_no_builtin, or if nonansi_p and flag_no_nonansi_builtin. */ static void def_builtin_1 (enum built_in_function fncode, const char *name, enum built_in_class fnclass, tree fntype, tree libtype, bool both_p, bool fallback_p, bool nonansi_p, tree fnattrs, bool implicit_p) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #34 from ubizjak at gmail dot com 2008-02-22 13:41 ---
Perhaps patch from comment #24 can give some clue, because with this patch I
get:
long double test(long double x) { return sinl(x); }
long double test_(long double x) { return __builtin_sinl(x); }
test_:
jmp sinl$LDBL128
test:
jmp sinl
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #33 from fxcoudert at gcc dot gnu dot org 2008-02-22 13:22
---
(In reply to comment #26)
>> but the Fortran front-end apparently doesn't benefit from it:
>
> The weird thing is that we go through the code of the patch, so I'm not sure
> why it still fails.
Here is the fndecl that is given to build_call_array() when emitting code for
the call to __builtin_asinl:
* debug_tree (DECL_ASSEMBLER_NAME (fndecl)) gives ""
* debug_tree (addr) gives (where addr is equal to build_addr (fndecl,
current_function_decl)):
SI
size
unit size
align 32 symtab 0 alias set -1 canonical type 0x40f1ec40
arg-types
chain >>
pointer_to_this >
unsigned SI size unit size
align 32 symtab 0 alias set -1 canonical type 0x40f48540>
readonly constant invariant
arg 0
readonly addressable public external built-in SI file (null) line 0 col
0
align 32 built-in BUILT_IN_NORMAL:BUILT_IN_ASINL
(mem:SI (symbol_ref:SI ("asinl") [flags 0x41] ) [0 S4 A8])
chain
readonly public external built-in SI file (null) line 0 col 0
align 32 built-in BUILT_IN_NORMAL:BUILT_IN_ACOSHF
(mem:SI (symbol_ref:SI ("acoshf") [flags 0x41] ) [0 S4 A8]) chain >>>
So, the assembler name is set up correctly, and I don't see anything wrong in
how we handle things. Question is: why do we still end up calling asinl and not
asinl$LDBL128? In other terms, why aren't we using the assembler name of the
function decl?
PS: a simple testcase such as
real function foo(x)
real(16) :: x
foo = asin(x)
end
generates assembly that has "bl _asinl" instead of the expected "bl
_asinl$LDB128".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #32 from dominiq at lps dot ens dot fr 2008-02-22 13:12 --- > Lack of interest for the platform. After all, PowerBooks have been > discontinued for 3 years... :-) This PR is more than two year old and is present on all the ppc machines (including G5). Note also that Apple has fixed at least one bug with long double on ppc in Darwin9. My point was that, if the problem has a trivial fix, as claimed by the Darwin maintainers, they should at least provide the hint to those trying to fix the problem (what they never did). If such a trivial fix does not exist, they should acknowledge it. >From my failed attempts to find a solution, I got the impression that the simplest solution could be to add the suffix when generating the assembly, but I never found the time to check it (other than doing it by hand, reported somewhere on the lists). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #31 from bonzini at gnu dot org 2008-02-22 12:08 --- Subject: Re: builtin functions should use $LDBL128 suffix on darwin when appropriate > Where the problem becomes serious is for languages such as fortran which has > no > direct way to access math.h. So far all the attempts I have seen have failed > to > yield a satisfactory solution. So either it is not as trivial as said by the > Apple's guys, or if it is really why don't they give the hint? Lack of interest for the platform. After all, PowerBooks have been discontinued for 3 years... :-) Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #30 from bonzini at gnu dot org 2008-02-22 12:05 --- Subject: Re: builtin functions should use $LDBL128 suffix on darwin when appropriate > (As a sidenote, there is one minor thing for which recompiling libgfortran is > needed, and that's specific functions; I'm not using them here. Specific > functions are Fortran wrappers to math builtins that are compiled into > libgfortran and used when a Fortran intrinsic math function is passed as an > argument to another function.) Yes, that's what I was thinking of. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug c++/28743] [4.1/4.2/4.3/4.4 regression] ICE with invalid specialization
--- Comment #13 from pcarlini at suse dot de 2008-02-22 11:07 --- Unfortunately, back to a 4.3 (and 4.4) regression. -- pcarlini at suse dot de changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE|[4.1/4.2/4.3/4.4 regression] |with invalid specialization |ICE with invalid ||specialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28743
[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected
--- Comment #10 from pcarlini at suse dot de 2008-02-22 11:05 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
[Bug c++/28743] [4.1/4.2 regression] ICE with invalid specialization
--- Comment #12 from paolo at gcc dot gnu dot org 2008-02-22 11:04 --- Subject: Bug 28743 Author: paolo Date: Fri Feb 22 11:03:17 2008 New Revision: 132545 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132545 Log: /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 * g++.dg/template/nontype17.C: Add. /cp 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * pt.c (determine_specialization): In case of function templates, when the type of DECL does not match FN there is no match. /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * g++.dg/template/nontype17.C: New. * g++.dg/template/nontype16.C: Add error. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28743
[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected
--- Comment #9 from paolo at gcc dot gnu dot org 2008-02-22 11:04 --- Subject: Bug 35282 Author: paolo Date: Fri Feb 22 11:03:17 2008 New Revision: 132545 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132545 Log: /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 * g++.dg/template/nontype17.C: Add. /cp 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * pt.c (determine_specialization): In case of function templates, when the type of DECL does not match FN there is no match. /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * g++.dg/template/nontype17.C: New. * g++.dg/template/nontype16.C: Add error. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected
--- Comment #8 from paolo at gcc dot gnu dot org 2008-02-22 11:03 --- Subject: Bug 35282 Author: paolo Date: Fri Feb 22 11:02:31 2008 New Revision: 132544 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132544 Log: /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 * g++.dg/template/nontype17.C: Add. /cp 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * pt.c (determine_specialization): In case of function templates, when the type of DECL does not match FN there is no match. /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * g++.dg/template/nontype17.C: New. * g++.dg/template/nontype16.C: Add error. Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/pt.c branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/nontype16.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/nontype17.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
[Bug c++/28743] [4.1/4.2 regression] ICE with invalid specialization
--- Comment #11 from paolo at gcc dot gnu dot org 2008-02-22 11:03 --- Subject: Bug 28743 Author: paolo Date: Fri Feb 22 11:02:31 2008 New Revision: 132544 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132544 Log: /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 * g++.dg/template/nontype17.C: Add. /cp 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * pt.c (determine_specialization): In case of function templates, when the type of DECL does not match FN there is no match. /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * g++.dg/template/nontype17.C: New. * g++.dg/template/nontype16.C: Add error. Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/pt.c branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/nontype16.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/nontype17.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28743
[Bug c++/28743] [4.1/4.2 regression] ICE with invalid specialization
--- Comment #10 from paolo at gcc dot gnu dot org 2008-02-22 11:02 --- Subject: Bug 28743 Author: paolo Date: Fri Feb 22 11:02:00 2008 New Revision: 132543 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132543 Log: /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 * g++.dg/template/nontype17.C: Add. /cp 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * pt.c (determine_specialization): In case of function templates, when the type of DECL does not match FN there is no match. /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * g++.dg/template/nontype17.C: New. * g++.dg/template/nontype16.C: Add error. Added: trunk/gcc/testsuite/g++.dg/template/nontype17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/nontype16.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28743
[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected
--- Comment #7 from paolo at gcc dot gnu dot org 2008-02-22 11:02 --- Subject: Bug 35282 Author: paolo Date: Fri Feb 22 11:02:00 2008 New Revision: 132543 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132543 Log: /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 * g++.dg/template/nontype17.C: Add. /cp 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * pt.c (determine_specialization): In case of function templates, when the type of DECL does not match FN there is no match. /testsuite 2008-02-22 Paolo Carlini <[EMAIL PROTECTED]> PR c++/35282 Revert: 2008-02-14 Paolo Carlini <[EMAIL PROTECTED]> PR c++/28743 * g++.dg/template/nontype17.C: New. * g++.dg/template/nontype16.C: Add error. Added: trunk/gcc/testsuite/g++.dg/template/nontype17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/nontype16.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #29 from fxcoudert at gcc dot gnu dot org 2008-02-22 11:00 --- >> but the Fortran front-end apparently doesn't benefit from it: > > From what I understand, you have to rebuild libgfortran. Did you do so? It doesn't need to, the calls are emitted directly by the front-end (otherwise, we'd be OK, as the library is in C and we do include ). (As a sidenote, there is one minor thing for which recompiling libgfortran is needed, and that's specific functions; I'm not using them here. Specific functions are Fortran wrappers to math builtins that are compiled into libgfortran and used when a Fortran intrinsic math function is passed as an argument to another function.) > No, only variadic functions like fprintf should be affected by > -mmacosx-version-min. Of course, you're right, I got confused. It works: $ ./bin/gcc -c s.c -mmacosx-version-min=10.3.9 $ nm s.o | grep printf U _printf$LDBL128 $ ./bin/gcc -c s.c -mmacosx-version-min=10.3.8 $ nm s.o | grep printf U _printf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug middle-end/35286] Missing PRE for globals
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:58 --- Confirmed. This also blocks removal of store_ccp. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-02-22 10:58:32 date|| Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35286
[Bug middle-end/35287] Missing PRE for indirect load
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:57 --- Confirmed. I think this is the same issue as PRE of globals. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-02-22 10:57:57 date|| Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35287
[Bug middle-end/35288] Expression reassociation problem
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:55 --- Confirmed. Re-association generates D.1548_3 = a1_4(D) + a1_4(D); b1_5 = D.1548_3 + a2_2(D); b2_6 = b1_5 + a2_2(D); D.1549_7 = b2_6 + a3_1(D); but that does not expose SSA_NAMEs with the same value. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-22 10:55:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35288
[Bug middle-end/35289] missing CSE of division (lack of reassociation)
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:52 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-02-22 10:52:09 date|| Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35289
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #28 from dominiq at lps dot ens dot fr 2008-02-22 10:51 --- First thanks for looking to the problem. Second, all the machinery for adding $LDBL128 is provided by math.h (or in fixincludes/tests/base/architecture/ppc/math.h). So the problem for languages accepting to include math.h can be solved by adding the include in the code. Indeed for these languages it would be nice to do the include silently, but it's not vital to use long double. Where the problem becomes serious is for languages such as fortran which has no direct way to access math.h. So far all the attempts I have seen have failed to yield a satisfactory solution. So either it is not as trivial as said by the Apple's guys, or if it is really why don't they give the hint? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug middle-end/35290] Missing dead store elimination
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:48 --- Confirmed. DSE is too dumb for this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-02-22 10:48:57 date|| Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35290
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #27 from bonzini at gnu dot org 2008-02-22 10:47 --- Subject: Re: builtin functions should use $LDBL128 suffix on darwin when appropriate > but the Fortran front-end apparently doesn't benefit from it: From what I understand, you have to rebuild libgfortran. Did you do so? > $ ./bin/gcc s.c -mmacosx-version-min=10.2.8 && ./a.out > -0.242366 -0.242366 -8.82009e-18 > $ nm a.out | grep asinl > U _asinl$LDBL128 > > If I understand correctly, this should give _asinl and not the $LDBL128 > variant. No, only variadic functions like fprintf should be affected by -mmacosx-version-min. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug middle-end/35291] Missing DCE for union fields
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:47 --- Confirmed. A re-written DSE and introduction of MEM_REF will fix this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-02-22 10:47:17 date|| Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35291
[Bug middle-end/35292] Missing Const Prop -- union fields
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-22 10:46 --- This is related to PR34043 and will be fixed by tweaking SCCVN and the introduction of MEM_REF. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-22 10:46:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35292
