[Bug target/34115] atomic builtins not supported on i686?
--- Comment #2 from pcarlini at suse dot de 2007-11-15 22:30 --- I think this is essentially invalid. Note that now we also have the various __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros: http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
possible bug in 4.2-20071107 snapshot
Hi I've just built the 4.2-20071107 snapshot and got the folowing warning that I think you will want to know about. ../../../libjava/classpath/gnu/java/security/util/Base64.java: In class 'gnu.java.security.util.Base64': ../../../libjava/classpath/gnu/java/security/util/Base64.java: In method 'gnu.java.security.util.Base64.decode(byte[],int,int)': ../../../libjava/classpath/gnu/java/security/util/Base64.java:200: warning: Unreachable statement. for (i = off; i < off + len; i++) ^ 1 warning Thanks, Chris -- Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination
--- Comment #1 from steven at gcc dot gnu dot org 2007-11-15 23:31 --- We may be able to propagate somehow that rnd_to_2 is always even. I doubt it is worth the trouble, to be honest... Zdenek may have some thought on this. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-15 23:31:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
[Bug c++/34111] new overload resolution error
--- Comment #2 from mueller at gcc dot gnu dot org 2007-11-15 23:17 ---
reduced testcase:
class QChar
{
};
struct QString
{
QString(QChar);
};
struct QPainter
{
void drawText (int x, int y, const QString &);
};
class KHEChar:public QChar
{
public:KHEChar (QChar C);
};
void
drawByte (QPainter * P, char, KHEChar B)
{
P->drawText (0, 0, B);
}
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-11-15 23:17:52
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34111
[Bug target/34115] atomic builtins not supported on i686?
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-15 22:19 --- Because the default arch for i686-linux-gnu is i386. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
[Bug target/34115] atomic builtins not supported on i686?
--- Comment #3 from joseph at codesourcery dot com 2007-11-15 23:53 --- Subject: Re: atomic builtins not supported on i686? On Thu, 15 Nov 2007, pinskia at gcc dot gnu dot org wrote: > Because the default arch for i686-linux-gnu is i386. Which is a stupid inconsistency and arguably a bug. sparcv9-linux-gnu defaults to -mcpu=v9 (where -mcpu means -march for SPARC), likewise various other architectures; i686-linux-gnu should be consistent with those other targets and default to -march=i686. libstdc++ will use i486-specific code if you configure GCC for i[456]86, even when GCC itself restricts itself to i386 code, making this default to i386 even less useful; likewise glibc will use i486/i586/i686 code when configured for those processors (and no longer supports i386). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
[Bug target/34115] atomic builtins not supported on i686?
--- Comment #5 from scovich at gmail dot com 2007-11-16 01:00 --- Subject: Re: atomic builtins not supported on i686? On 15 Nov 2007 23:53:06 -, joseph at codesourcery dot com <[EMAIL PROTECTED]> wrote: > > Because the default arch for i686-linux-gnu is i386. > Which is a stupid inconsistency and arguably a bug. ++ BTW, -march=i686 works beautifully. Close the bug? or rename it as a RFE to have i686-* default to -march=i686? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination
--- Comment #2 from lloyd at randombit dot net 2007-11-16 00:50 ---
Is there be any way to modify the code such that GCC would have an easier time
seeing this? I tried using 'assert(rnd_to_2 % 2 == 0)' (since glibc's
__assert_fail is marked with noreturn I thought it might help), but that didn't
seem to have an effect.
Short background that might be relevant: the code this is derived from is doing
partial loop unrolling (8 iterations in the actual code) with a block of inline
asm inserted, and then another loop following that handles any slop. Would
rewriting the loop as
while(in >= 2)
{
in -= 2;
i += 2;
}
be likely to help? I see that it does with one particular version (4.1.2), but
I have no intuition if that is because the optimizer understands such loops
better or if it is just random luck.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
[Bug target/34115] atomic builtins not supported on i686?
--- Comment #4 from pcarlini at suse dot de 2007-11-16 00:07 --- Yeah, the wind is changing! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
[Bug target/34115] atomic builtins not supported on i686?
--- Comment #6 from scovich at gmail dot com 2007-11-16 01:04 --- (In reply to comment #5) > Subject: Re: atomic builtins not supported on i686? > > On 15 Nov 2007 23:53:06 -, joseph at codesourcery dot com > <[EMAIL PROTECTED]> wrote: > > > Because the default arch for i686-linux-gnu is i386. > > Which is a stupid inconsistency and arguably a bug. > > ++ > > BTW, -march=i686 works beautifully. Close the bug? or rename it as a > RFE to have i686-* default to -march=i686? > Oh, and is there supposed to be a warning about unsupported atomic ops or not? If not the docs should say to expect a linker error instead (and also mention/link those macros Paolo pointed out). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
--- Comment #6 from j at uriah dot heep dot sax dot de 2007-11-15 21:21
---
I'm not sure whether this is related or not... but from the description, it
looks so.
avr-libc contains a macro that helps the users declaring a flash-ROM string,
lacking any real support in GCC for different memory sections (as proposed
by the Embedded C draft). This works by using the GCC extension that a
block can return a value: a block is openened, and a block-scope static
variable is allocated, using the string literal passed in by the user. Then,
that block returns the address of this variable to the caller. By giving
the block-scope variable the "progmem" attribute, it will eventually be
allocated in ROM rather than RAM.
Now, if that macro is called with identical string literals within one
translation unit, the strings are allocated separately rather than merged
into a single location.
This behaviour is reproducable as well on the i386 target, so it looks like
not really related to the avr backend.
Here's a simple test case. For simplicity, the original PSTR() macro is
just reproduced in the file rather than including the entire original
header(s).
#if defined(__AVR__)
# define PROGMEM __attribute__((__progmem__))
#else
# define PROGMEM /* nothing */
#endif
#define PSTR(x) \
(__extension__({static const char __c[] PROGMEM = (x); &__c[0];}))
extern void puts_P(const char *);
void
dosomething(void)
{
puts_P(PSTR("Hello world!"));
puts_P(PSTR("Hello world!"));
}
Compiling for the avr target yields:
.file "foo.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__tmp_reg__ = 0
__zero_reg__ = 1
.global __do_copy_data
.global __do_clear_bss
.text
.global dosomething
.type dosomething, @function
dosomething:
/* prologue: frame size=0 */
/* prologue end (size=0) */
ldi r24,lo8(__c.1471)
ldi r25,hi8(__c.1471)
rcall puts_P
ldi r24,lo8(__c.1473)
ldi r25,hi8(__c.1473)
rcall puts_P
/* epilogue: frame size=0 */
ret
/* epilogue end (size=1) */
/* function dosomething size 7 (6) */
.size dosomething, .-dosomething
.section.progmem.data,"a",@progbits
.type __c.1473, @object
.size __c.1473, 13
__c.1473:
.string "Hello world!"
.type __c.1471, @object
.size __c.1471, 13
__c.1471:
.string "Hello world!"
/* File "foo.c": code7 = 0x0007 ( 6), prologues 0, epilogues 1 */
Compiling the same file for the i386 target also shows two copies of the
string literal:
.file "foo.c"
.section.rodata
.type __c.0, @object
.size __c.0, 13
__c.0:
.string "Hello world!"
.type __c.1, @object
.size __c.1, 13
__c.1:
.string "Hello world!"
.text
.globl dosomething
.type dosomething, @function
dosomething:
pushl %ebp
movl%esp, %ebp
pushl $__c.0
callputs_P
movl$__c.1, (%esp)
callputs_P
leave
ret
.size dosomething, .-dosomething
.ident "GCC: (GNU) 3.4.4 [FreeBSD] 20050518"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
--- Comment #9 from schlie at comcast dot net 2007-11-16 02:35 --- Subject: Re: Small targets without 64 bit long long support are can't bootstrap GCC. submitted, a long while ago; but honestly haven't been tracking things lately. > From: manu at gcc dot gnu dot org <[EMAIL PROTECTED]> > Reply-To: <[EMAIL PROTECTED]> > Date: 15 Nov 2007 15:39:19 - > To: <[EMAIL PROTECTED]> > Subject: [Bug middle-end/20675] Small targets without 64 bit long long support > are can't bootstrap GCC. > > > > --- Comment #8 from manu at gcc dot gnu dot org 2007-11-15 15:39 --- > What happened to this patch? > > > -- > > manu at gcc dot gnu dot org changed: > >What|Removed |Added > > CC||manu at gcc dot gnu dot org > Status|UNCONFIRMED |WAITING > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-16 01:52 --- (In reply to comment #3) > Here's another example, which I think may represent a different case (and > which > I found much more surprising than the first): > no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops No this is correct, try having n as UINT_MAX. The conditional will always be true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination
--- Comment #5 from lloyd at randombit dot net 2007-11-16 02:00 --- Argh, you are correct. The original code has unsigned int n = an_input / 160; so this could never occur there, but GCC's inability to tell that this assignment means that n cannot be UINT_MAX (in that code) is clearly much like the original example. And then I simplified it enough that the loop actually could be infinite... Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination
--- Comment #3 from lloyd at randombit dot net 2007-11-16 01:49 ---
Here's another example, which I think may represent a different case (and which
I found much more surprising than the first):
$ cat no_loop_opt2.c
void g(unsigned int n)
{
unsigned int k;
for(k = 0; k <= n; ++k)
;
}
(motoko ~)$ g++-4.1.2 -O2 -Wunsafe-loop-optimizations -c no_loop_opt2.c
no_loop_opt2.c: In function 'void g(unsigned int)':
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops
(same output with 4.2.0)
However if <= is changed to <, no problem.
Version info:
$ g++-4.1.2 -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-libunwind-exceptions
--enable-multilib --enable-libmudflap --disable-libssp --disable-libgcj
--enable-languages=c,c++,objc,obj-c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2)
$ g++-4.2.0 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.2.0/configure --enable-languages=c,c++,objc,obj-c++
--program-suffix=-4.2.0
Thread model: posix
gcc version 4.2.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-11-16 02:38 --- (In reply to comment #2) > Is there be any way to modify the code such that GCC would have an easier time > seeing this? I tried using 'assert(rnd_to_2 % 2 == 0)' (since glibc's > __assert_fail is marked with noreturn I thought it might help), but that > didn't > seem to have an effect. As a workaround, you may change the type of i and rnd_to_2 to signed (signed arithmetics in C is guaranteed not to overflow, and loop optimizer will use this to prove that the loop is finite). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
--- Comment #7 from schlie at comcast dot net 2007-11-16 02:35 --- Subject: Re: Initializing string literal data improperly marked frame-relative?, should be readonly static const. I believe so. > From: manu at gcc dot gnu dot org <[EMAIL PROTECTED]> > Reply-To: <[EMAIL PROTECTED]> > Date: 15 Nov 2007 16:19:49 - > To: <[EMAIL PROTECTED]> > Subject: [Bug middle-end/21018] Initializing string literal data improperly > marked frame-relative?, should be readonly static const. > > > > --- Comment #5 from manu at gcc dot gnu dot org 2007-11-15 16:19 --- > Is this still a valid bug? > > > -- > > manu at gcc dot gnu dot org changed: > >What|Removed |Added > > CC||manu at gcc dot gnu dot org > Status|UNCONFIRMED |WAITING > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug target/34001] Incorrect x86 fastcall behavior
--- Comment #5 from hjl at lucon dot org 2007-11-16 04:52 --- The correct patch is at http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00885.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
[Bug tree-optimization/31081] [4.3 Regression] Inliner messes up SSA for abnormals
--- Comment #8 from kuba at et dot pl 2007-11-16 01:19 --- i've tried to understand it but i can't. Can anyone explain me.. Why does coalesce_partitions (tree-ssa-coalesce.c) fail after unsuccessful attempt_coalesce? what is the difference if it is abnormal edge, or not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31081
[Bug c/34116] New: GCC for CELL processor does NOT relocate properly with Optimization Turned on.,
Please see the following thread in IBM's CELL BE Forum for more details: http://www-128.ibm.com/developerworks/forums/thread.jspa?threadID=182669 -- Summary: GCC for CELL processor does NOT relocate properly with Optimization Turned on., Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sparc64 at rediffmail dot com GCC build triplet: 4.1.1 GCC host triplet: ??? GCC target triplet: CELL BE Host running Linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34116
[Bug fortran/33317] CSHIFT/EOSHIFT: Rejects optional dummy for DIM=
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-11-16 06:23
---
program test
implicit none
call sub(1)
call sub()
contains
subroutine sub(dimmy)
integer, optional :: dimmy
logical :: lotto(4)
lotto = .false.
lotto = cshift((/.true.,.true.,.true.,.true./),1,dimmy)
print *, lotto
end subroutine
end program test
After enabling the optional argument with -m32 -fdump-tree-original we get:
sub (dimmy)
{
logical4 lotto[4];
(void) __builtin_memset ((void *) &lotto, 0, 16);
{
int4 * D.515;
static int4 C.514 = 1;
struct array1_logical4 parm.2;
static logical4 A.1[4] = {1, 1, 1, 1};
struct array1_logical4 parm.0;
parm.0.dtype = 273;
parm.0.dim[0].lbound = 1;
parm.0.dim[0].ubound = 4;
parm.0.dim[0].stride = 1;
parm.0.data = (void *) &lotto[0];
parm.0.offset = -1;
parm.2.dtype = 273;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = 4;
parm.2.dim[0].stride = 1;
parm.2.data = (void *) &A.1[0];
parm.2.offset = 0;
D.515 = dimmy != 0B ? dimmy : 0B;
_gfortran_cshift0_4 (&parm.0, &parm.2, &C.514, D.515);
}
and it works as expected.
With -m64 it obviously fails with the following:
sub (dimmy)
{
logical4 lotto[4];
(void) __builtin_memset ((void *) &lotto, 0, 16);
{
int4 D.874;
static int4 C.873 = 1;
struct array1_logical4 parm.2;
static logical4 A.1[4] = {1, 1, 1, 1};
struct array1_logical4 parm.0;
parm.0.dtype = 273;
parm.0.dim[0].lbound = 1;
parm.0.dim[0].ubound = 4;
parm.0.dim[0].stride = 1;
parm.0.data = (void *) &lotto[0];
parm.0.offset = -1;
parm.2.dtype = 273;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = 4;
parm.2.dim[0].stride = 1;
parm.2.data = (void *) &A.1[0];
parm.2.offset = 0;
D.874 = *dimmy;
_gfortran_cshift0_4 (&parm.0, &parm.2, &C.873, &D.874);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33317
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #12 from eres at il dot ibm dot com 2007-11-16 06:48 --- Created an attachment (id=14562) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14562&action=view) gcda file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug c++/34100] [4.3 regression] ICE with vector attribute
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-16 07:06 --- Subject: Bug 34100 Author: jakub Date: Fri Nov 16 07:06:25 2007 New Revision: 130220 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130220 Log: PR c++/34100 * pt.c (apply_late_template_attributes): Do nothing if decl's type is error_mark_node. * g++.dg/template/crash73.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/crash73.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34100
[Bug driver/30460] [4.0/4.1/4.2/4.3 Regression] asm_debug is not initialized in gcc.c when using a "default" specs file
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-16 07:03 --- Subject: Bug 30460 Author: jakub Date: Fri Nov 16 07:02:49 2007 New Revision: 130219 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130219 Log: PR driver/30460 * gcc.c (init_spec): Don't initialize asm_debug here... (main): ... but here. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30460
[Bug driver/30460] [4.0/4.1/4.2 Regression] asm_debug is not initialized in gcc.c when using a "default" specs file
--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-16 07:10 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |asm_debug is not initialized|asm_debug is not initialized |in gcc.c when using a |in gcc.c when using a |"default" specs file|"default" specs file http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30460
[Bug c++/34100] [4.3 regression] ICE with vector attribute
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-16 07:11 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34100
