Rask Ingemann Lambertsen wrote:
Today, I had a look at the code I get for __gcc_bcmp() from libgcc2.c. I saw
a regression from
decw%ax
je .L2
to
movw%ax,%cx ; register allocation
decw%cx
movw%cx,%ax ; register allocat
Laurynas Biveinis wrote:
> Hi,
>
> For typed GC allocation I've to add GTY markers for a few datatypes.
> An example from value-prof.h:
>
> Before:
>
> struct histogram_value_t
> {
> struct
> { /* <--- line 48, error below occurs here */
> tree value; /*
Today, I had a look at the code I get for __gcc_bcmp() from libgcc2.c. I saw
a regression from
decw%ax
je .L2
to
movw%ax,%cx ; register allocation
decw%cx
movw%cx,%ax ; register allocation
andw%cx,%cx
On Sun, 2006-08-13 at 10:53 -0700, Mark Mitchell wrote:
> I think this is a question of priorities. It's relatively
> straightforward to fix the compiler to generate type-consistent GIMPLE:
> you write consistency-checking routines and then you just fix all the
> problems that arise, by inserting
On Sun, 2006-08-13 at 12:55 -0600, Jeffrey Law wrote:
> Thus the existence of some implicit type conversions. IIRC the
> places where these occur or occurred at one time or we pondered
> allowing are:
>
> 1. MODIFY_EXPRs where the RHS can be implicitly converted to the
> type of the LHS
On Sun, 2006-08-13 at 10:53 -0700, Mark Mitchell wrote:
> (In my opinion, it doesn't really matter if MODIFY_EXPR is treated as
> doing an implicit conversion; the important thing is that the set of
> places where implicit conversions are performed be both limited and
> documented. If we save ton
Hi,
For typed GC allocation I've to add GTY markers for a few datatypes.
An example from value-prof.h:
Before:
struct histogram_value_t
{
struct
{ /* <--- line 48, error below occurs here */
tree value;/* The value to profile. */
tree stmt;
Kenneth Zadeck wrote:
> I have had some discussions with Honza and Diego about the type
> consistency at the gimple level. They told me that Andrew was in the
> process of making gimple properly type consistent.
I think that there is widespread consensus that GIMPLE should ideally be
On Sun, 2006-08-13 at 19:48 +0300, Drgt wrote:
> Hi.
>
> It seems, that "#pragma once" isn't in ISO, and will never be, especially
> because it is Microsoft (am I right ?) C extension.
> (http://gcc.gnu.org/ml/gcc/2004-06/msg01887.html)
#pragma once has not been removed and in fact the opposite h
Drgt wrote:
Hi.
It seems, that "#pragma once" isn't in ISO, and will never be, especially
because it is Microsoft (am I right ?) C extension.
Why not implement it yourself and propose a patch.
Hi.
It seems, that "#pragma once" isn't in ISO, and will never be, especially
because it is Microsoft (am I right ?) C extension.
(http://gcc.gnu.org/ml/gcc/2004-06/msg01887.html)
But I still asking GCC developers, that this simple-in-use thing would be
in GCC, and you not "play football" with it
>
> When compiling the following the code with gcc 4.1.1 without
> optimization, the output is wrong.
>
> gcc -v is
>
> Using built-in specs.
> Target: i686-pc-linux-gnu
> Configured with: ./configure --prefix=/home/jb/local
> Thread model: posix
> gcc version 4.1.1
>
> <=code=>
>
> #
When compiling the following the code with gcc 4.1.1 without
optimization, the output is wrong.
gcc -v is
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/jb/local
Thread model: posix
gcc version 4.1.1
<=code=>
#include
int main()
{
On Fri, Aug 04, 2006 at 11:21:05AM +0200, Bernd Schmidt wrote:
> Probably the compiler doesn't in general like a paradoxical subreg that
> can take more hard regs than its SUBREG_REG. I think this is probably
> something that can be worked around with a proper combination of
> MODES_TIEABLE_P,
On 8/13/06, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> bits/atomicity.h has volatile qualifiers on the _Atomic_word*
> arguments to
> the __*_single and __*_dispatch variants of the atomic operations. This
> huts especially the single-threaded optimization variants which
Richard Guenther wrote:
bits/atomicity.h has volatile qualifiers on the _Atomic_word*
arguments to
the __*_single and __*_dispatch variants of the atomic operations. This
huts especially the single-threaded optimization variants which are
usually
inlined. Removing those qualifiers allows to
bits/atomicity.h has volatile qualifiers on the _Atomic_word* arguments to
the __*_single and __*_dispatch variants of the atomic operations. This
huts especially the single-threaded optimization variants which are usually
inlined. Removing those qualifiers allows to reduce code size significant
17 matches
Mail list logo
