skaller <[EMAIL PROTECTED]> writes:
> On Mon, 2007-11-05 at 14:30 -0500, Ross Ridge wrote:
>
> > One example of where it hurts on just about any platform is something
> > like this:
> >
> > void allocate(int **p, unsigned len);
> >
> > int *foo(unsigned len) {
> > int *p;
>
Hello all,
I have implemented fixed point data types in gcc-4.1.1 by
incorporating the patches sent out in the gcc patches mailing list. To
debug fixed-point types, as per the dwarf manual we may need the
following info as follows.
DW_AT_binary_scale : binary scale factor for fixed-point type.
DW_
On Tue, 2007-11-06 at 00:15 -0800, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
>
> > On Mon, 2007-11-05 at 14:30 -0500, Ross Ridge wrote:
> >
> > > One example of where it hurts on just about any platform is something
> > > like this:
> > >
> > > void allocate(int **p, unsig
Hi,
Working on a private port I am seeing a problem with reload clobbering
a live register and thus causing havoc.
Consider the following snippet of the code dump.
(note:HI 85 84 86 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(note:HI 86 85 89 5 NOTE_INSN_DELETED)
(insn:HI 89 86 87 5 cor_h.c:129 (set (reg:S
Mark Mitchell wrote:
> H.J. Lu wrote:
>
> > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01865.html
> >
> > which involves reload.
>
> I'm not going to try to wade into reload. Ulrich, Eric, Ian -- would
> one of you please review this patch?
@@ -1821,6 +1835,18 @@ find_reg (struct insn_chain
skaller writes:
> Yes but I still don't understand. The claim was that the assignment
> might modify p. This is is contra-indicated since p is a pointer
> to an int, whereas the value being assigned is an int.
The claim was, in the context of the example given, "Without strict
aliasing being enab
skaller <[EMAIL PROTECTED]> writes:
> On Tue, 2007-11-06 at 00:15 -0800, Ian Lance Taylor wrote:
> > skaller <[EMAIL PROTECTED]> writes:
> >
> > > On Mon, 2007-11-05 at 14:30 -0500, Ross Ridge wrote:
> > >
> > > > One example of where it hurts on just about any platform is something
> > > > like
On Tue, 2007-11-06 at 06:29 -0800, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
> I recommend that you just read the standard and see the real aliasing
> rules.
I don't care about that, I'm trying to discover what
-fno-strict-aliasing actually does.
You hinted that it weakens t
On Tue, 2007-11-06 at 09:37 -0500, Ross Ridge wrote:
> skaller writes:
> > Yes but I still don't understand. The claim was that the assignment
> > might modify p. This is is contra-indicated since p is a pointer
> > to an int, whereas the value being assigned is an int.
>
> The claim was, in the
On Wed, Nov 07, 2007 at 02:30:44AM +1100, skaller wrote:
> > The claim was, in the context of the example given, "Without strict
> > aliasing being enabled, the compiler can't assume that that the assignment
> > 'p[i] = 1' won't change 'p'".
>
> In this case I think it can. More precisely, IF the
On Tue, Nov 06, 2007 at 12:15:17AM -0800, Ian Lance Taylor wrote:
> The assignment is indeed of an int, but it uses a pointer. Strict
> aliasing only refers to loads and stores which use pointers. The
> type-based alias analysis is done on the types to which those pointers
> point.
Minor nit: he
skaller <[EMAIL PROTECTED]> writes:
> On Tue, 2007-11-06 at 06:29 -0800, Ian Lance Taylor wrote:
> > skaller <[EMAIL PROTECTED]> writes:
>
> > I recommend that you just read the standard and see the real aliasing
> > rules.
>
> I don't care about that, I'm trying to discover what
> -fno-strict-a
Joe Buck <[EMAIL PROTECTED]> writes:
> On Wed, Nov 07, 2007 at 02:30:44AM +1100, skaller wrote:
> > > The claim was, in the context of the example given, "Without strict
> > > aliasing being enabled, the compiler can't assume that that the assignment
> > > 'p[i] = 1' won't change 'p'".
> >
> > I
On Tue, 2007-11-06 at 07:49 -0800, Joe Buck wrote:
> On Wed, Nov 07, 2007 at 02:30:44AM +1100, skaller wrote:
> Now it appears that you want to make some kind of intermediate assumption
> (semi-strict aliasing?), where pointers of different types are allowed to
> alias while ints can't alias with
On Tue, 2007-11-06 at 07:58 -0800, Ian Lance Taylor wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
> In particular people really do write code like
> int addr = 0x12345678;
> char* p = (char*)&addr;
> *p = 1;
> and
> int f[2] = { 0x8000, 0 };
> double d = *(double*)f;
> Thi
On Tue, Nov 06, 2007 at 03:30:04PM +0100, Ulrich Weigand wrote:
> Mark Mitchell wrote:
> > H.J. Lu wrote:
> >
> > > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01865.html
> > >
> > > which involves reload.
> >
> > I'm not going to try to wade into reload. Ulrich, Eric, Ian -- would
> > one of
Joe Buck writes:
> On Wed, Nov 07, 2007 at 04:06:11AM +1100, skaller wrote:
> > I understand I ask for something gcc may not be doing, I'm not
> > asking for a change, just to understand what it actually does.
>
> You are misusing C++, I'm afraid, and there are no promises that
> some day a
On Wed, Nov 07, 2007 at 04:06:11AM +1100, skaller wrote:
> On Tue, 2007-11-06 at 07:49 -0800, Joe Buck wrote:
> > Now it appears that you want to make some kind of intermediate assumption
> > (semi-strict aliasing?), where pointers of different types are allowed to
> > alias while ints can't alias
On Tue, 2007-11-06 at 09:32 -0800, Joe Buck wrote:
> On Wed, Nov 07, 2007 at 04:06:11AM +1100, skaller wrote:
> > On Tue, 2007-11-06 at 07:49 -0800, Joe Buck wrote:
> > > Now it appears that you want to make some kind of intermediate assumption
> > > (semi-strict aliasing?), where pointers of diff
On Tue, 2007-11-06 at 17:39 +, Andrew Haley wrote:
> Joe Buck writes:
> I agree. This is way off-topic for [EMAIL PROTECTED] We have been
> very patient already, and it is time for it to end.
Thanks for your patience, I'm not meaning to go off topic,
just to discover exactly what gcc does
H.J. Lu wrote:
> Yes, it works for me. I tested it on Linux/ia32, Linux/intel64
> and linux/ia64. There are no regressions.
Thanks for testing!
> gcc/
>
> 2007-11-06 Ulrich Weigand <[EMAIL PROTECTED]>
>
> PR target/30961
> * reload1.c (find_reloads): Also check in_reg when handli
On Tue, Nov 06, 2007 at 07:40:00PM +0100, Ulrich Weigand wrote:
> H.J. Lu wrote:
>
> > Yes, it works for me. I tested it on Linux/ia32, Linux/intel64
> > and linux/ia64. There are no regressions.
>
> Thanks for testing!
>
> > gcc/
> >
> > 2007-11-06 Ulrich Weigand <[EMAIL PROTECTED]>
> >
> >
On Wed, Nov 07, 2007 at 05:22:01AM +1100, skaller wrote:
> > One way to do this in C++ is to derive the different representations that
> > might appear in your "union" from a common base class, and use placement
> > new to lay them out.
>
> I don't understand. You cannot put ANY constructable typ
Hello!
A little background:
Some time ago, Richard Guenther proposed that GCC imports libm math
library from libc sources, but this proposal went nowhere, mostly due to
non-technical reasons. At the time, the idea was that having a local
math library, we could implement high-performance math
On 11/1/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> I haven't followed any developments relating to TR19769 in WG14
> after its publication in detail; has WG14 yet given an answer
> on what should be done with u'C' where C represents a single
> character that requires a surrogate pair to repre
> "Johan" == Johan Bohlin <[EMAIL PROTECTED]> writes:
Johan> Hi I have a question regarding gcc or g++
Johan> -fdump-tree-all-raw-details (.tu file). I want to dump the
Johan> entire C (not C++) AST tree the only way to do this, without
Johan> losing any information, is if I use g++ and
Johan>
On Mon, Nov 05, 2007 at 03:40:52PM -0800, H.J. Lu wrote:
> Hi Paul,
>
> Did you check the wrong ChangeLog entry in gcc/ChangeLog with
>
> http://gcc.gnu.org/viewcvs?view=rev&revision=129904
>
I checked in the following patch as an obvious fix.
H.J.
Index: ChangeLog
==
We have alot of different lists in the medical industry and we don't charge per
thousand like many other companies on the internet.
In fact there are some good deals we are running for this week. Contact me at
topleveldata AT hotmail.com to get additional details.
Hi,
I wonder if any efforts have been made to retarget GCC to VLIW
backend.Is there any project trying to do that? Is it included in the
GCC mainstream? Thanks.
Regards,
Li Wang
This is a part of the code :
--
extern struct dummy temp[];
error: array type has incomplete element type
--
which i compiled without any error on :
$gcc -v
Reading specs f
Li Wang wrote:
Hi,
I wonder if any efforts have been made to retarget GCC to VLIW
backend.Is there any project trying to do that? Is it included in the
GCC mainstream? Thanks.
the ia64 is a VLIW architecture!
Regards,
Li Wang
Hi,
I know that. But I am talking to a more _pure_ VLIW architecture
which totally relies on static scheduling rather than EPIC architecture.
Thanks.
Li Wang wrote:
Hi,
I wonder if any efforts have been made to retarget GCC to VLIW
backend.Is there any project trying to do that? Is it incl
Li Wang <[EMAIL PROTECTED]> writes:
> I wonder if any efforts have been made to retarget GCC to VLIW
> backend.Is there any project trying to do that? Is it included in the
> GCC mainstream? Thanks.
The FRV is an example of a currently supported VLIW backend.
Ian
Hi,
We are implementing attributes to variables. The attribute of the
operand is checked and the respective instructions are emitted based
on the attributes. We have added the attribute to one addressing mode
in which the operand is absolute memory (SYMBOL_REF). This was
implemented by checking t
On Nov 5, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
> On 11/5/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> libgfortran had some vectorization cases that wouldn't be applied in
>> the presence of debug stmts referencing the same variables. Fixed
>> with the patch below, to be insta
On 06 Nov 2007 21:50:09 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Li Wang <[EMAIL PROTECTED]> writes:
>
> > I wonder if any efforts have been made to retarget GCC to VLIW
> > backend.Is there any project trying to do that? Is it included in the
> > GCC mainstream? Thanks.
Dr. Baumgartl,
36 matches
Mail list logo
