Re: bitfields: types vs modes?
DJ Delorie wrote:
I think the ARM specification is pretty sensible, and would make a
good cross-platform approach.
Could you distill it for us?
The relevant bits are from AAPCS \S 7.1.7.5, and quoted below.
The term container here means the declared type of the bit-field.
(There's a corner-case for C++ bit-fields that are bigger than their
declared type, but don't worry about that.) So int i:6 has a 32-bit
container, whereas char c:6 has an 8-bit container.
(In the ARM ABI, a bit-field never crosses a container boundary; struct
{ char c1:6; char c2:3} puts c2 completely into the second byte, not
straddling the first two bytes. But, if those were int bit-fields, then
the second bit-field would straddle the two bytes. Packed structures
are outside the scope of the ABI.)
When a volatile bit-field is read, its container must be read exactly
once using the access width appropriate to the type of the container.
When a volatile bit-field is written, its container must be read
exactly once and written exactly once using the access width
appropriate to the type of the container. The two accesses are not
atomic.
Multiple accesses to the same volatile bit-field, or to additional
volatile bit-fields within the same container may not be merged. For
example, an increment of a volatile bit-field must always be
implemented as two reads and a write.
Note the volatile access rules apply even when the width and
alignment of the bit-field imply that the access could be achieved
more efficiently using a narrower type. For a write operation the
read must always occur even if the entire contents of the container
will be replaced.
If the containers of two volatile bit-fields overlap then access to
one bit-field will cause an access to the other. For example, in
struct S {volatile int a:8; volatile char b:2}; an access to a will
also cause an access to b, but not vice-versa.
If the container of a non-volatile bit-field overlaps a volatile
bit-field then it is undefined whether access to the non-volatile
field will cause the volatile field to be accessed.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Re: GCC4.3.3: Bootstrap comparison failure!
Thanks, Ian, These kinds of issues are always difficult to debug. There have been a couple of patches to stabilize different sorts which I don't think are in 4.3.3. That could conceivably cause differences if address space randomization is turned on. I don't know of any specific bug reports, though. In any case, try turning off address space randomization (/proc/sys/kernel/randomize_va_space). There is no /proc/sys/kernel/randomize_va_space in my system. Maybe it is a little too old: 2.6.5-7.97-smp #1 SMP Fri Jul 2 14:21:59 UTC 2004 finally, I compared langhooks1.o langhooks2.o cmp -i 16 langhooks1.o langhooks2.o langhooks1.o langhooks2.o differ: byte 76626, line 514 Try running your commands with the --save-temps options and compare the resulting .s files. Also, try running the commands with the -fdump-tree-all -fdump-rtl-all options and see where the dump files first differ. I tried --save-temps and the resulting .s files were identical. I found that the problem was introduced by as. I ran as twice with the same arguments. The two resulting .o files were different. I upgraded the binutils to the latest version: 2.19. The problem hasn't gone away. Do you have any ideas?
Re: -Wcast-qual and casting away
On Thu, May 21, 2009 at 7:10 AM, Ian Lance Taylor i...@google.com wrote:
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts away
qualifiers
If I compile this program with gcc -Wcast-qual, I do not get any
warning.
Let's overlook the fact that the text of the g++ warning does not make
any sense--I am certainly not casting anything away. The warning is
conceptually plausible for the same reason that you can't assign a
char** variable to a const char** variable without a cast. At least, I
think one could make a argument that that is so. But it's not a *very*
strong argument, as -Wcast-qual is documented to warn about cases where
a type qualifier is removed, and that is manifestly not happening here.
-Wcast-qual is useful to catch certain programming errors; I don't think
anybody adding a const qualifier is actually making a mistake.
All that aside, I can't think of any reason that the C and C++ frontends
should be different in this regard. Does anybody want to make an
argument for which of these choices we should adopt?
1) Keep things the same: the C++ frontend warns, the C frontend doesn't.
Consistency is overrated.
2) Change the C frontend to also warn about this case, albeit with a
better message.
3) Change the C++ frontend to not warn about this case.
Of course in all cases the frontends should continue to warn about a
cast from const void** to void**.
As the C++ warning doesn't make any sense I vote for 3).
Richard.
Ian
Re: -Wcast-qual and casting away
Ian Lance Taylor i...@google.com writes:
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts away
qualifiers
In a sense this warning is actually correct: this is storing a const
char * into a void * object, which is where the qualifier is lost. IMHO
having a warning for this questionable operation is a good thing.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
GCC 4.4.1 Status Report (2009-05-21)
Status == The 4.4 branch is open under the usual release branch rules, a 4.4.1 release planned around June 21st. The branch seems to be in good shape and new bugs still get fixed quickly. There are a few bugs that I would block the 4.4.1 release for, including the reported ICE building SPEC on i?86. All seem to have patches though. The 4.4.1 release is a good opportunity for all the non-primary and secondary target maintainers to verify the 4.4 release builds ok and the testsuite results are reasonable. Quality Data Priority # Change from Last Report --- --- P12 P2 82 + 2 P30 --- --- Total84 + 2 Previous Report === http://gcc.gnu.org/ml/gcc/2009-04/msg00564.html The next report for 4.4 will be sent by Jakub. -- Richard Guenther rguent...@suse.de Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Re: -Wcast-qual and casting away
On Wed, 20 May 2009, Ian Lance Taylor wrote: All that aside, I can't think of any reason that the C and C++ frontends should be different in this regard. Does anybody want to make an There's the fairly obvious reason that C and C++ have different rules on implicit conversions involving const, so const at higher levels of indirection is irrelevant in C in a way that it is not in C++. (Adoption of the C++ rules was considered and rejected for C99.) -- Joseph S. Myers jos...@codesourcery.com
Re: -Wcast-qual and casting away
On Thu, May 21, 2009 at 1:50 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Ian Lance Taylor i...@google.com writes:
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts
away qualifiers
In a sense this warning is actually correct: this is storing a const
char * into a void * object, which is where the qualifier is lost. IMHO
having a warning for this questionable operation is a good thing.
I don't think so.
extern char **f1();
void f(char *p)
{
*(const char **)f1() = p;
}
warns the same. typeof(*(const char **)) should still be const char *.
For
extern const char **f1();
void f(char *p)
{
*(char **)f1() = p;
}
it warns with
t.C: In function ‘void f(char*)’:
t.C:4: warning: cast from type ‘const char**’ to type ‘char**’ casts
away constness
which makes sense.
Richard.
Re: -Wcast-qual and casting away
Richard Guenther richard.guent...@gmail.com writes:
For
extern const char **f1();
void f(char *p)
{
*(char **)f1() = p;
}
it warns with
t.C: In function ‘void f(char*)’:
t.C:4: warning: cast from type ‘const char**’ to type ‘char**’ casts
away constness
which makes sense.
This is actually a safe operation, you can even store safely into
**(char **)f1() afterwards.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: -Wcast-qual and casting away
Richard Guenther wrote:
On Thu, May 21, 2009 at 1:50 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Ian Lance Taylor i...@google.com writes:
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts
away qualifiers
In a sense this warning is actually correct: this is storing a const
char * into a void * object, which is where the qualifier is lost. IMHO
having a warning for this questionable operation is a good thing.
I don't think so.
extern char **f1();
void f(char *p)
{
*(const char **)f1() = p;
}
warns the same. typeof(*(const char **)) should still be const char *.
It seems the rules for the warning follow the same rules for whether
such qualifier changes are allowed in implicit conversions (or named
casts other than const_cast).
Let's say char** - const char** is allowed silently. Then the program
below is silently violating const correctness:
char* pc;
char** ppc = pc;
const char** cppc = ppc; // Silently allowed?
const char cc = 0;
*ppc = cc; // Silently allowed, pc now points to cc
*pc = 1; // Silently allowed, but changes cc
The conversion T** - const T** is unsafe. That's all there is to it.
The warning is correct.
Cast to T const* const* instead.
Sebastian
Re: -Wcast-qual and casting away
Ian Lance Taylor wrote:
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts away
qualifiers
If I compile this program with gcc -Wcast-qual, I do not get any
warning.
2) Change the C frontend to also warn about this case, albeit with a
better message.
Of course in all cases the frontends should continue to warn about a
cast from const void** to void**.
Well, they should warn about this case also then.
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
void *x;
void **f1()
{
return x
}
void f2(char *foo, int n)
{
memcpy (x, foo, n); // BOOM!
}
This looks like a disguised way of casting a const char* to a (non-const)
void* to me, isn't it? Sure, the warning is being tripped by the cast rather
than the conversion that the cast is hiding, it needs to be improved, but I'm
glad we got at least some noise from such a dubious construction.
cheers,
DaveK
Re: Object file for Module is too large
Thanks for your advice.
Andy Vaught wrote on May 19:
I've got this fixed, your test code now compiles to 428 bytes. It's a
very osx-specific deal...
Thanks to Dominique Dhumieres for letting me know that
new versions were posted to ftp.g95.org:
-rw-r--r--2 2055 2055 3229447 May 20 00:19
g95-powerpc-osx.tgz
-rw-r--r--2 2055 2055 6430824 May 20 00:18 g95-x86-osx.tgz
These fix the problem that I had reported.
On the mac, the new version of g95 identifies itself as
gcc version 4.0.3 (g95 0.92!) May 20 2009
i386-apple-darwin9.7.0-g95
-- Alison
On Tue, 12 May 2009 14:03:28 +0200, FX fxcoud...@gmail.com said:
Hi Alison,
This issue is not specific to Fortran, but it's specific to Darwin
(you say that the large object files have been observed on many other
platforms, but could you give a list of such platforms?):
$ cat a.c
int x[999] = { 0 };
$ gcc -c a.c ls -lh a.o
-rw-r--r-- 1 fx wheel38M May 12 13:43 a.o
$ size a.o
__TEXT__DATA __OBJC others dec hex
0 39960 0 399626259fc
while on x86_64-linux, I get:
$ cat a.c
int x[999] = { 0 };
$ gcc -c a.c ls -lh a.o
-rw-r--r-- 1 fx fx 959 May 12 13:44 a.o
$ size a.o
text data bss dec hex filename
00 3996399626259fc a.o
The different between the two is between .bss (x86_64-linux) and .data
(darwin). I don't know enough about Mach-O to tell if it's a bug or a
feature :)
FX
--
Alison Boeckmann
alisonboeckm...@fastmail.fm
Re: nops
- Original Message From: Ian Lance Taylor i...@google.com To: Jamie Prescott jpre...@yahoo.com Cc: gcc@gcc.gnu.org Sent: Wednesday, May 20, 2009 9:50:50 PM Subject: Re: nops Jamie Prescott writes: Under which conditions GCC generates nops? It depends entirely on the target. For many targets, gcc will never generate a nop instruction, except as a byproduct of alignment. My target does not have anything special WRT alignment. I even set the function alignment to 8, and it still issues gen_nop(). This seem to happen only with -O0, or at least I noticed it only under such condition so far. I noticed that with 4.4.0, gen_nop() is required, thing that wasn't with 4.3.3. Can I just define an empty insn for nop, of GCC requires a one-byte insn for its own alignment purposes? Normally gcc does alignment by issuing an assembler directive, and the assembler is responsible for generating nop instructions when necessary. Did a quick grep and the one you mention (ASM_OUTPUT_ALIGN_WITH_NOP) is not defined in my backend. And such directive does not even have a default. So, in theory, I should not see any nops. The problem is different. The error is at link-time, if gen_nop() is not defined, so it means that the insn is generated programmatically. Grepping the source, I noticed a few files that issue gen_nop() directly, thing that was not happening with 4.3.3. So my questions are. Is there a way to disable it? If not, can I define an empty-issue instruction for 'nop'? - Jamie
Re: nops
On Thu, May 21, 2009 at 8:13 AM, Jamie Prescott jpre...@yahoo.com wrote: My target does not have anything special WRT alignment. I even set the function alignment to 8, and it still issues gen_nop(). This seem to happen only with -O0, or at least I noticed it only under such condition so far. so it happens at -O0 so that the debugger is able to place a breakpoint at some gotos. Thanks, Andrew Pinski
Re: nops
From: Andrew Pinski pins...@gmail.com To: Jamie Prescott jpre...@yahoo.com Cc: Ian Lance Taylor i...@google.com; gcc@gcc.gnu.org Sent: Thursday, May 21, 2009 8:22:00 AM Subject: Re: nops On Thu, May 21, 2009 at 8:13 AM, Jamie Prescott wrote: My target does not have anything special WRT alignment. I even set the function alignment to 8, and it still issues gen_nop(). This seem to happen only with -O0, or at least I noticed it only under such condition so far. so it happens at -O0 so that the debugger is able to place a breakpoint at some gotos. Thanks! Makes sense, and it means that I can define to an empty insn for the version of the VM that does not have 'nop'. - Jamie
Re: GCC4.3.3: Bootstrap comparison failure!
chenyang chenyang...@gmail.com writes: Try running your commands with the --save-temps options and compare the resulting .s files. Also, try running the commands with the -fdump-tree-all -fdump-rtl-all options and see where the dump files first differ. I tried --save-temps and the resulting .s files were identical. I found that the problem was introduced by as. I ran as twice with the same arguments. The two resulting .o files were different. I upgraded the binutils to the latest version: 2.19. The problem hasn't gone away. That is very unusual and certainly indicates a bug in the assembler. Please file a bug against the GNU binutils at http://sourceware.org/bugzilla/ . Attach your assembler file to the bug. Thanks. Ian
Re: -Wcast-qual and casting away
Joseph S. Myers jos...@codesourcery.com writes: On Wed, 20 May 2009, Ian Lance Taylor wrote: All that aside, I can't think of any reason that the C and C++ frontends should be different in this regard. Does anybody want to make an There's the fairly obvious reason that C and C++ have different rules on implicit conversions involving const, so const at higher levels of indirection is irrelevant in C in a way that it is not in C++. (Adoption of the C++ rules was considered and rejected for C99.) Fair enough, but I don't see any particular reason these rather esoteric rules should affect the -Wcast-qual option. Ian
Re: -Wcast-qual and casting away
Richard Guenther richard.guent...@gmail.com writes:
On Thu, May 21, 2009 at 1:50 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Ian Lance Taylor i...@google.com writes:
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts
away qualifiers
In a sense this warning is actually correct: this is storing a const
char * into a void * object, which is where the qualifier is lost. IMHO
having a warning for this questionable operation is a good thing.
I don't think so.
extern char **f1();
void f(char *p)
{
*(const char **)f1() = p;
}
warns the same. typeof(*(const char **)) should still be const char *.
For
extern const char **f1();
void f(char *p)
{
*(char **)f1() = p;
}
it warns with
t.C: In function ‘void f(char*)’:
t.C:4: warning: cast from type ‘const char**’ to type ‘char**’ casts
away constness
which makes sense.
Let's not focus too much on the operation (the indirection and the
assignment). The warning is about the cast itself. Should we issue
that warning or not? Others have explained the cases where the cast can
lead to unsafe code.
The indirection + assignment operation is easy to do in all cases by
moving the cast to the other side.
Ian
Re: -Wcast-qual and casting away
On Thu, May 21, 2009 at 12:10 AM, Ian Lance Taylor i...@google.com wrote:
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts away
qualifiers
If I compile this program with gcc -Wcast-qual, I do not get any
warning.
Let's overlook the fact that the text of the g++ warning does not make
any sense--I am certainly not casting anything away. The warning is
conceptually plausible for the same reason that you can't assign a
char** variable to a const char** variable without a cast. At least, I
think one could make a argument that that is so. But it's not a *very*
strong argument, as -Wcast-qual is documented to warn about cases where
a type qualifier is removed, and that is manifestly not happening here.
-Wcast-qual is useful to catch certain programming errors; I don't think
anybody adding a const qualifier is actually making a mistake.
In fact, the contrary is true. The warning speaks the truth.
The implicit conversion is unsafe and the cast is explicitly
by-passing that const-safety built into the type system.
-- Gaby
Re: -Wcast-qual and casting away
On Thu, May 21, 2009 at 5:20 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, May 21, 2009 at 7:10 AM, Ian Lance Taylor i...@google.com wrote:
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts
away qualifiers
If I compile this program with gcc -Wcast-qual, I do not get any
warning.
Let's overlook the fact that the text of the g++ warning does not make
any sense--I am certainly not casting anything away. The warning is
conceptually plausible for the same reason that you can't assign a
char** variable to a const char** variable without a cast. At least, I
think one could make a argument that that is so. But it's not a *very*
strong argument, as -Wcast-qual is documented to warn about cases where
a type qualifier is removed, and that is manifestly not happening here.
-Wcast-qual is useful to catch certain programming errors; I don't think
anybody adding a const qualifier is actually making a mistake.
All that aside, I can't think of any reason that the C and C++ frontends
should be different in this regard. Does anybody want to make an
argument for which of these choices we should adopt?
1) Keep things the same: the C++ frontend warns, the C frontend doesn't.
Consistency is overrated.
2) Change the C frontend to also warn about this case, albeit with a
better message.
3) Change the C++ frontend to not warn about this case.
Of course in all cases the frontends should continue to warn about a
cast from const void** to void**.
As the C++ warning doesn't make any sense I vote for 3).
Why do you think it the warning does not make sense?
The only you can go from void** to const void** is that you actually
remove the const in the middle of const void* const *. That is
precisely what the cast is doing -- so the warning is legitimate.
-- Gaby
Re: -Wcast-qual and casting away
On Thu, May 21, 2009 at 11:11 AM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
On Thu, May 21, 2009 at 1:50 PM, Andreas Schwab sch...@linux-m68k.org
wrote:
Ian Lance Taylor i...@google.com writes:
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts
away qualifiers
In a sense this warning is actually correct: this is storing a const
char * into a void * object, which is where the qualifier is lost. IMHO
having a warning for this questionable operation is a good thing.
I don't think so.
extern char **f1();
void f(char *p)
{
*(const char **)f1() = p;
}
warns the same. typeof(*(const char **)) should still be const char *.
For
extern const char **f1();
void f(char *p)
{
*(char **)f1() = p;
}
it warns with
t.C: In function ‘void f(char*)’:
t.C:4: warning: cast from type ‘const char**’ to type ‘char**’ casts
away constness
which makes sense.
Let's not focus too much on the operation (the indirection and the
assignment). The warning is about the cast itself. Should we issue
that warning or not? Others have explained the cases where the cast can
lead to unsafe code.
The particular cast in question is not a safe operation. Should we warn
about it when -Wcast-qual, I think so -- that is one of the purposes of
the switch.
-- Gaby
gcc-4.5-20090521 is now available
Snapshot gcc-4.5-20090521 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090521/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 147778 You'll find: gcc-4.5-20090521.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20090521.tar.bz2 C front end and core compiler gcc-ada-4.5-20090521.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20090521.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20090521.tar.bz2 C++ front end and runtime gcc-java-4.5-20090521.tar.bz2 Java front end and runtime gcc-objc-4.5-20090521.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20090521.tar.bz2The GCC testsuite Diffs from 4.5-20090514 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Accumulator based machines
Hi there. The machine I'm working is part accumulator based, part register based. I'm having trouble figuring out how best to tell the compiler how ACC is affected and when. For example, the add instruction is two operand with the destination being a general register: ADD, R11 is equivalent to R11 = R11 + ACC This works fine using a rule like (define_insn addsi3_insn [(set (match_operand:SI 0 register_operand =r) (plus:SI (match_operand:SI 1 register_operand 0) (match_operand:SI 2 register_operand b)))] (b is the constraint that the register comes from the ACC_REGS class) The logical right shift instruction only works on the accumulator: LSR1 is equivalent to ACC = ACC 1 This works fine using: (define_insn lshrsi3_const [(set (match_operand:SI 0 register_operand =b) (lshiftrt:SI (match_operand:SI 1 register_operand 0) (match_operand:SI 2 immediate_operand )))] The problem is when I have to clobber ACC such as when moving between registers. The output should be: LOADACC, R10; STOREACC, R11 (equivalent to ACC = R10; R11 = ACC) I've tried a parallel clobber like: (define_insn movsi [(set (match_operand:SI 0 nonimmediate_operand =b, dam,dam) (match_operand:SI 1 general_operand dami,b, dam)) (clobber (reg:SI TREG_ACC)) but this causes trouble when setting up ACC for the likes of the add above. The compiler runs but the code is incorrect I've tried a parallel with a match_scratch like: (define_insn movsi [(set (match_operand:SI 0 nonimmediate_operand =b, rm,rm) (match_operand:SI 1 general_operand rmi,b, rm)) (clobber (match_scratch:SI 2 =X,X,b)) ] @ LOADACC, %1 STOREACC, %0 LOADACC, %1\;STOREACC, %0 This uses a 'b' constraint to put the scratch into ACC when moving between registers and a 'X' constraint to ignore the scratch when moving to or from ACC directly. This basically works but fails when mixed with other instructions. For example, the code: return left + right fails with a 'movsi does not meet constraints' as ACC was already allocated to one of the operands of the addsi, was not available for the scratch register, and as such something else was given to the movsi which didn't match the 'b' constraint. All of the other instructions are OK as I can clobber or mark ACC as an output reload to mark it as dirty. Even the 68hc11 is better off as it can directly move between any two registers :) Any ideas? Am I going about this the wrong way? My first port treated ACC as a fixed register which avoided all of this but generated too many loads and stores. Is there a way of using a register only if a chain of instructions use it? Can I peephole it in someway instead? -- Michael
Votre publicit� sur le Portail SaguenayLac.com
Bonjour, Faites votre publicité sur: http://www.saguenaylac.com pour juste 20$/an ou 50$/3ans sur le portail du Saguenay - Lac-Saint-Jean. Nous concevons aussi des sites web à 200$ en moyenne. Voir aussi nos modèles sur: http://www.flashblogg.com . Merci beaucoup. SaguenayLac.com
Re: Accumulator based machines
Michael Hope wrote: but this causes trouble when setting up ACC for the likes of the add above. The compiler runs but the code is incorrect Incorrect how? If you don't give us precise descriptions of the problem, then we can't give you precise answers. A precise description would be RTL excerpts from -da dumps, showing exactly when (which RTL pass) and exactly how (good and bad RTL) it breaks. Taking a guess, I would say it breaks when the reload pass emits instructions to resolve reloads, because these instructions will clobber ACC, which generates wrong code if ACC already has a live value in it. To avoid this problem, I think you would have to hide ACC from the compiler before reload. So instead of having an addsi3 pattern that does R11 = R11 + ACC. You write an addsi3 pattern that does R11 = R11 + R12, and which emits two assembly language instructions to achieve this. Then you write a post-reload splitter which splits it into two RTL instructions, one to do the add and one to do the move. You have a post-reload only pattern to accept R11 = R11 + ACC. Then you hope that CSE, peephole, and other post-reload optimizations can eliminate most of the redundant instructions. If need be, you might add a machine dependent reorg pass that cleans up the code even more. You can have post-reload patterns by checking for reload_completed in the condition. There have been some ports to small accumulator based machines, but mostly they have used tricks like a page-zero register file. You just assume that you have 16 registers in page-zero memory, and you don't bother telling gcc about the actual hardware registers, taking advantage of the fact that you have fast page-zero addressing modes. This of course gives horrible code, as every operation involves two loads an ACC operation and a store. However, it does give a working compiler, for those desperate enough to need one. Jim
[Bug c++/40217] New: gcc-4.3.1 fails to produce an error message for out of memory condition
I accidentally ran my FreeBSD-71 system with 3GB RAM without the swap space and
compiled a large module with high degree of optimization.
I was getting this error:
{standard input}: Assembler messages:
{standard input}:68321: Warning: end of file not at end of a line; newline
inserted
{standard input}:69363: Error: undefined symbol `.LLSDACSE3986' in operation
{standard input}:69427: Error: undefined symbol `.LFB398' in operation
g++: Internal error: Killed: 9 (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
This happened 100% of time, and error message stayed the same.
So gcc was getting memory allocation failure but instead of failing with the
relevant message it was passing wrong assembly to 'as'.
Adding swap cured the situation.
gcc-4.3.3 was failing in a similar way but with a bit different error message.
This should be fixed to make gcc more reliable in the random user environments.
Today by googling the above error messages you can get a lot of references of
similar situations happening to various people.
--
Summary: gcc-4.3.1 fails to produce an error message for out of
memory condition
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40217
[Bug c++/40217] gcc-4.3.1 fails to produce an error message for out of memory condition
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-21 06:25 --- g++: Internal error: Killed: 9 (program cc1plus) The kernel killed cc1plus because of being out of memory. So yes it did already say what happened. Also since -pipe was being used, it is hard to tell the assembler that it ran out of memory and to abort assembling too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40217
[Bug fortran/30374] unpacking intent(IN) arguments
--- Comment #4 from jv244 at cam dot ac dot uk 2009-05-21 08:34 --- Paul, 2 years ago you had a (one liner?) patch for this one, but gfortran still seem to unpack for intent(IN) data: MODULE M1 CONTAINS SUBROUTINE S1(I) INTEGER, DIMENSION(3), INTENT(IN) :: I END SUBROUTINE END MODULE USE M1 INTEGER, TARGET, DIMENSION(9) :: I INTEGER, DIMENSION(:), POINTER :: IP IP=I(1:9:3) CALL S1(IP) END -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail||4.5.0 Last reconfirmed|2007-10-26 07:25:36 |2009-05-21 08:34:53 date|| Summary|aliasing amoung dummy |unpacking intent(IN) |arguments: possibly missing |arguments |optimization| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30374
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #6 from bmei at broadcom dot com 2009-05-21 08:38 --- I only submitted small patch before. To add a pass (may need new command-line option, disabling the old rtl-level unrolling) seems to be a big issue to me. Don't know what's procedure. My code also contains my own implementation of #pragma unroll. I need to clean it up for the public patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug fortran/40218] New: incorrect location for error message
note the dot instead of the comma after target cat test.f90 INTEGER, TARGET. DIMENSION(9) :: I END gfortran test.f90 test.f90:1.8: INTEGER, TARGET. DIMENSION(9) :: I 1 Error: Invalid character in name at (1) -- Summary: incorrect location for error message Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40218
[Bug fortran/30374] unpacking intent(IN) arguments
--- Comment #5 from jv244 at cam dot ac dot uk 2009-05-21 08:40 --- (In reply to comment #4) Paul, 2 years ago you had a (one liner?) patch for this one, but gfortran still seem to unpack for intent(IN) data: ugh... no. I tested with 4.3 instead of 4.5. Instead we can close this, as this seems solved. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail|4.5.0 | Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30374
[Bug fortran/30374] unpacking intent(IN) arguments
--- Comment #6 from jv244 at cam dot ac dot uk 2009-05-21 08:45 --- fixed -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30374
[Bug c/40216] Optimization error when compiling bfd/ecofflink.c on x86_64
--- Comment #2 from schwab at linux-m68k dot org 2009-05-21 09:00 --- This is violating the C strict aliasing rule: if (! ecoff_add_bytes ((char **) debug-external_ext, (char **) debug-external_ext_end, (symhdr-iextMax + 1) * (size_t) external_ext_size)) which has already been fixed in binutils more than 3 years ago. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40216
[Bug fortran/40195] ICE when compiling a file located in another directory
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-05-21 09:12 --- It works for me. This sounds like the issue you'd have if you didn't have write permission to the current directory. What are the permissions and ownership of the bin and source directories? What user is trying to compile? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40195
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #5 from paolo dot carlini at oracle dot com 2009-05-21 09:15 --- So, you should compare it to the previous delete, which normally should be the *only* one involving basic_string. To be clear, the expected sequence is the following, as you can check on any other linux target: operator new is called operator new is called operator delete is called 1 allocations to be released operator delete is called All memory released that is, the additional delete / new pair that you are seeing at the end is completely bogus. Of course, I would suggest also checking what happens vs optimization level (also for the *.so, thus rebuilding the library CXXFLAGS=-OX -g). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug pch/40215] Generated GCH fails to honor include guards with -no-integrated-cpp
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 09:41 --- Works as designed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
[Bug middle-end/40141] [4.3 Regression] accessing aliased __m128 miscompiles
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-21 10:27 --- Patch was posted and rejected as too invasive for 4.3. Distributors can apply the referenced patch. Thus, WONTFIX for 4.3, fixed for 4.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||05/msg00925.html Status|ASSIGNED|RESOLVED Known to fail||4.3.3 Known to work||4.4.0 Resolution||FIXED Target Milestone|4.3.4 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40141
[Bug middle-end/40026] [4.5 Regression] ICE during gimplify_init_constructor
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-21 10:29 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40026
[Bug libgcj/40182] [4.4/4.5 regression] regressions in libjava testsuite on sparc-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40182
[Bug libgcj/40180] [4.4/4.5 regression] regressions in libjava testsuite on ia64-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40180
[Bug middle-end/40095] [4.5 Regression] Revision 147342/147343 caused extra failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40095
[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
[Bug c++/40085] [4.5 Regression] ICE compiling libmudflap.c++/fail24-frag.cxx
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40085
[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40027
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug c++/40007] [4.5 regression] specialization causes access problem in primary template
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug other/37515] [meta-bug] GCC 4.5 pending patches
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37515
[Bug middle-end/39509] [4.3/4.4/4.5 Regression] bad optimization(?) pure virtual function call with -O2
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-05-21 10:35 --- Which means it should work with -fno-tree-sink. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||39604 Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
[Bug target/39715] [4.5 Regression][cond-optab] extra sign extensions on Thumb
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||arm Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39715
[Bug target/39716] [4.5 Regression][cond-optab] worse MAX_EXPR expansion for Thumb
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||arm Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
[Bug target/39725] [4.5 Regression][cond-optab] MIPS pessimizations on floating-point
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||mips-linux-gnu Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39725
[Bug target/39726] [4.5 Regression][cond-optab] ColdFire pessimizations on QImode/HImode tests
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39726
[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug c++/40007] [4.5 regression] specialization causes access problem in primary template
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||powerpc Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40027
[Bug middle-end/40029] [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40029
[Bug c/40033] [4.5 regression] ICE with invalid statement expression
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40033
[Bug middle-end/40060] [4.5 Regression] casts loose alignment info
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40060
[Bug target/39715] [4.5 Regression][cond-optab] extra sign extensions on Thumb
--- Comment #1 from rearnsha at gcc dot gnu dot org 2009-05-21 10:49
---
Another case, compile with -mcpu=arm1136jf-s -mthumb -O2
void f(unsigned a, unsigned b, unsigned c, unsigned d)
{
if (a = b || c d)
foo();
else
bar();
}
f:
push{r4, lr}
cmp r3, r2
sbc r2, r2, r2 @ r2 = 0 or -1
neg r2, r2 @ r2 = 0 or 1
cmp r2, #0
beq .L7
.L5:
bl foo
.L1:
@ sp needed for prologue
pop {r4, pc}
.L7:
cmp r1, r0 @ r2 = 0 (by flow control)
adc r2, r2, r2 @ r2 = 0 / 1
uxtbr2, r2 @ so this is redundant
cmp r2, #0
bne .L5
bl bar
b .L1
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-05-21 10:49:12
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39715
[Bug middle-end/40079] [4.5 Regression] Revision 147294 caused extra failures
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 10:49 --- Only FAIL: /export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/testsuite/TestLeak.exe execution - /export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/testsuite/TestLeak.exe is still present. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40079
[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
[Bug middle-end/40091] [4.5 Regression] FAIL: g++.dg/opt/thunk3.C (test for excess errors)
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 10:52 --- Is this still failing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40091
[Bug middle-end/40095] [4.5 Regression] Revision 147342/147343 caused extra failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40095
[Bug rtl-optimization/40101] [4.5 Regression] 200.sixtrack ICEs in get_seqno_by_preds, at sel-sched-ir.c:3752
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40101
[Bug middle-end/40102] [4.5 Regression] Revision 147294 caused ICE: verify_cgraph_node
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 11:01 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2009-05-21 11:01:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40102
[Bug rtl-optimization/40107] [4.5 Regression] gcc.c-torture/execute/builtins/memmove.c and gcc.c-torture/execute/builtins/memmove-chk.c fail at -O1 on spu-elf
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40107
[Bug debug/40126] [4.5 Regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-debug Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
[Bug c++/40138] [4.5 Regression] ICE with invalid va_arg
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40138
[Bug tree-optimization/40140] [4.5 Regression] ICE with -ftree-parallelize-loops
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40140
[Bug middle-end/40161] [4.5 Regression] Revision 147566 may cause many regressions
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 11:04 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40161
[Bug middle-end/40163] [4.5 Regression] null pointer in remove_unreachable_regions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40163
[Bug c/40172] [4.5 Regression] Revision 147596 breaks bootstrap
--- Comment #30 from rguenth at gcc dot gnu dot org 2009-05-21 11:05 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40172
[Bug libgcj/40180] [4.4/4.5 regression] regressions in libjava testsuite on ia64-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40180
[Bug libgcj/40182] [4.4/4.5 regression] regressions in libjava testsuite on sparc-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40182
[Bug fortran/40197] [4.5 Regression] Spu fortran does not build
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40197
[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
--- Comment #12 from billingd at gcc dot gnu dot org 2009-05-21 11:31 --- Subject: Bug 36211 Author: billingd Date: Thu May 21 11:30:55 2009 New Revision: 147762 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147762 Log: 2009-05-21 David Billinghurst billi...@gcc.gnu.org Backport from mainline: PR libstdc++/36211 * testsuite/lib/libstdc++.exp(v3_target_compile): Add cxxldflags to additional_flags rather than cxx_final. Modified: branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/testsuite/lib/libstdc++.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
--- Comment #13 from billingd at gcc dot gnu dot org 2009-05-21 11:32 --- Fixed in 4.4 and trunk. -- billingd at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
-- billingd at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug tree-optimization/40087] [4.3/4.4 Regression] Number of iterations analysis wrong
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-05-21 11:37 --- Let's backport this before 4.4.1 goes out. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug tree-optimization/38747] [4.4/4.5 Regression] Wrong code due to VIEW_CONVERT_EXPR
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 Summary|[4.4 Regression] Wrong code |[4.4/4.5 Regression] Wrong |due to VIEW_CONVERT_EXPR|code due to ||VIEW_CONVERT_EXPR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38747
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #1 from dje at gcc dot gnu dot org 2009-05-21 12:40 --- Confirmed -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org GCC target triplet|i586-pc-mingw32 |i586-pc-mingw32,powerpc-ibm- ||aix Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #2 from jakub at gcc dot gnu dot org 2009-05-21 12:53 --- See http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00248.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug tree-optimization/40219] New: iterative_hash_expr in tree.c has an out of bound reference for machine specific builtins
The function iterative_hash_expr uses built_in_decls to a map a builtin function to the __builtin_ form. It uses DECL_FUNCTION_CODE as the index. For machine specific builtins, the DECL_FUNCTION_CODE is defined by the backend, instead of being the builtin number. This means that the builtin_in_decls reference can point to random memory. In the power7 branch, I added quite a few more builtins, and this code causes crashes when it looks at memory beyond the bound of builtin_in_decls. Even if it doesn't overflow the bounds of the array, the builtin hash might pick up the wrong declaration. -- Summary: iterative_hash_expr in tree.c has an out of bound reference for machine specific builtins Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40219
[Bug tree-optimization/40219] iterative_hash_expr in tree.c has an out of bound reference for machine specific builtins
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-21 13:14 --- Created an attachment (id=17898) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17898action=view) Patch to avoid de-referencing outside array bounds This patch fixes the particular problem I saw on the power7-branch for the testsuite and building the SPEC2006 gobmk and wrf benchmarks. I will do the usual bootstrap shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40219
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #51 from jakub at gcc dot gnu dot org 2009-05-21 13:21 --- Subject: Bug 39942 Author: jakub Date: Thu May 21 13:21:30 2009 New Revision: 147765 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147765 Log: PR target/39942 * config/i386/x86-64.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Don't emit second .p2align 3 if MAX_SKIP is smaller than 7. * config/i386/linux.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/linux.h branches/gcc-4_4-branch/gcc/config/i386/x86-64.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #52 from jakub at gcc dot gnu dot org 2009-05-21 13:26 --- Subject: Bug 39942 Author: jakub Date: Thu May 21 13:26:13 2009 New Revision: 147766 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147766 Log: PR target/39942 * config/i386/x86-64.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Don't emit second .p2align 3 if MAX_SKIP is smaller than 7. * config/i386/linux.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/linux.h branches/gcc-4_3-branch/gcc/config/i386/x86-64.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug pch/40215] Generated GCH fails to honor include guards with -no-integrated-cpp
--- Comment #3 from sacolcor at provide dot net 2009-05-21 13:56 --- Reopening, because if this is by design, the doc page at http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html should elaborate; it does not currently mention anything about incompatibility or other difficulties with -no-integrated-cpp or -save-temps. The supplied code compiles fine if the -no-integrated-cpp flag is removed, and it seems reasonable for a user to expect that those flags would not cause an otherwise working build to break. Are precompiled headers simply incompatible with those flags? If not, then what's needed to make them work? -- sacolcor at provide dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
[Bug middle-end/40029] [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-21 14:04 --- That's DO 100 J=1,N DO 100 I=1,M CU(I+1,J) = .5D0*(P(I+1,J)+P(I,J))*U(I+1,J) CV(I,J+1) = .5D0*(P(I,J+1)+P(I,J))*V(I,J+1) Z(I+1,J+1) = (FSDX*(V(I+1,J+1)-V(I,J+1))-FSDY*(U(I+1,J+1) 1 -U(I+1,J)))/(P(I,J)+P(I+1,J)+P(I+1,J+1)+P(I,J+1)) H(I,J) = P(I,J)+.25D0*(U(I+1,J)*U(I+1,J)+U(I,J)*U(I,J) 1 +V(I,J+1)*V(I,J+1)+V(I,J)*V(I,J)) 100 CONTINUE right? 4.4 can do predictive commoning on it while trunk can't - this also unrolls the loop twice. On trunk we are likely confused by PRE that already partially performs what predictive commoning would do. Disabling PRE makes predictive commoning work but doesn't unroll the loop (same as with disabling PRE in 4.4). It is likely the full redundancies PRE discovers that cause the unrolling. That said - this looks like yet another unfortunate pass ordering problem to me. -- 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 |2009-05-21 14:04:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40029
[Bug target/39856] [4.4/4.5 Regression] ICE in subst_stack_regs_pat, at reg-stack.c:1386
--- Comment #8 from jakub at gcc dot gnu dot org 2009-05-21 14:07 --- Patch has been posted almost a month ago: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01926.html Vlad, could you please ping it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856
[Bug middle-end/40029] [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-21 14:10 --- Testcase: SUBROUTINE CALC1 IMPLICIT REAL*8 (A-H, O-Z) PARAMETER (N1=1335, N2=1335) COMMON U(N1,N2), V(N1,N2), P(N1,N2), 2CU(N1,N2), CV(N1,N2), *Z(N1,N2), H(N1,N2) COMMON /CONS/ DX,DY FSDX = 4.D0/DX FSDY = 4.D0/DY DO 100 J=1,N DO 100 I=1,M CU(I+1,J) = .5D0*(P(I+1,J)+P(I,J))*U(I+1,J) CV(I,J+1) = .5D0*(P(I,J+1)+P(I,J))*V(I,J+1) Z(I+1,J+1) = (FSDX*(V(I+1,J+1)-V(I,J+1))-FSDY*(U(I+1,J+1) 1 -U(I+1,J)))/(P(I,J)+P(I+1,J)+P(I+1,J+1)+P(I,J+1)) H(I,J) = P(I,J)+.25D0*(U(I+1,J)*U(I+1,J)+U(I,J)*U(I,J) 1 +V(I,J+1)*V(I,J+1)+V(I,J)*V(I,J)) 100 CONTINUE RETURN END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40029
[Bug target/40220] New: Compile error after r147534
In r147534, Paolo (probably unintendedly) broke the VAX backend with a small change not appearing in the ChangeLog entry. The declaration of some functions were changed (probably for no reason) and the definitions were left as-is. -- Summary: Compile error after r147534 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbglaw at lug-owl dot de GCC target triplet: vax-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40220
[Bug target/40220] Compile error after r147534
--- Comment #1 from jbglaw at lug-owl dot de 2009-05-21 14:30 --- Created an attachment (id=17899) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17899action=view) This patch fixes the error by reverting the problem-causing change. See http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01043.html and http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01356.html . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40220
[Bug middle-end/40091] [4.5 Regression] FAIL: g++.dg/opt/thunk3.C (test for excess errors)
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-21 14:59 --- Subject: Re: [4.5 Regression] FAIL: g++.dg/opt/thunk3.C (test for excess errors) Is this still failing? It is no longer failing on hppa64-hp-hpux11.11. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40091
[Bug middle-end/40122] missed optimization when using union of __m128i and int[4]
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-05-21 16:02 ---
With he new SRA, the optimized dump looks like:
D.6886_10 = {1, 1, 1, 1};
D.6887_11 = VIEW_CONVERT_EXPRvector long long int(D.6886_10);
D.6893_12 = VIEW_CONVERT_EXPRvector int(D.6887_11);
D.6891_14 = __builtin_ia32_pcmpeqd128 (D.6893_12, D.6893_12);
D.6890_15 = VIEW_CONVERT_EXPRvector long long int(D.6891_14);
D.6897_16 = VIEW_CONVERT_EXPRvector char(D.6890_15);
D.6896_17 = __builtin_ia32_pmovmskb128 (D.6897_16);
D.6933_21 = D.6896_17 != 65535;
return D.6933_21;
x is completely gone.
The (relevant) assembly output is
main:
movdqa .LC0, %xmm0
pcmpeqd %xmm0, %xmm0
pmovmskb%xmm0, %eax
cmpl$65535, %eax
pushl %ebp
setne %al
movl%esp, %ebp
movzbl %al, %eax
popl%ebp
ret
So even though I don't really understand the SSE instructions I
believe the new SRA does indeed help. I'll add a testcase checking
that x vanishes to the patch series as I am finalizing the final patch
set now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40122
[Bug libfortran/40212] Failure on building libgfortran
--- Comment #4 from ksong at lbl dot gov 2009-05-21 16:14 --- Thank you very much! I successively compiled. -- ksong at lbl dot gov changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40212
[Bug c/37985] [4.3/4.4/4.5 Regression] unsigned char shift lacks statement with no effect warning
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-05-21 16:31 ---
Works with 3.4:
$ cat tmp.c
unsigned char foo(unsigned char a)
{
a 2;
return a;
}
$ gcc-3.4 -S -O3 -Wall tmp.c
tmp.c: In function `foo':
tmp.c:3: warning: statement with no effect
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0 4.5.0 4.3.3
Summary|unsigned char shift lacks |[4.3/4.4/4.5 Regression]
|statement with no effect |unsigned char shift lacks
|warning |statement with no effect
||warning
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37985
[Bug c/37985] [4.3/4.4/4.5 Regression] unsigned char shift lacks statement with no effect warning
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.5 |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37985
[Bug pch/40215] Generated GCH fails to honor include guards with -no-integrated-cpp
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-21 16:56 --- How can the PCH contain information that is lost by using an external preprocessor? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40215
