> I meant when using GCC with the Sun assembler/linker, it shows up on
> sparc. But it doesn't show up on sparc when using Sun cc with Sun
> assembler/linker, and thus Sun doesn't document it as a sparc problem.
OK, I misinterpreted "tools", thanks for the clarification. Yes, that is a
very pla
On Wed, 11 May 2005, H. J. Lu wrote:
> On Thu, May 12, 2005 at 12:48:46AM +0200, Peter S. Mazinger wrote:
> > Hello!
> >
> > I have gotten under peculiar circumstances following:
> > (sysvinit) init.o: relocation R_386_GOTOFF against protected function
> > `main' can not be used when making a sh
On May 11, 2005, at 1:41 PM, Ian Lance Taylor wrote:
I actually have a vague recollection that gcc used to implement
something along these lines, but I couldn't find it in five minutes of
searching.
I think you're thinking of the old xref code in the C++ frontend or
the old typeinfo. One could g
Snapshot gcc-3.3-20050511 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050511/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050511
You'll
Joern.
My combined tree is acting up, so I haven't tested a full build of
ppc-eabi*, but this fixes the -mlittle problem.
Let me know how it goes.
Aldy
* config/rs6000/sysv4.opt (mlittle): Handle.
* config/rs6000/rs6000.c (rs6000_handle_option): Set
target_flags_explici
On Sat, 2005-05-07 at 10:22, Eric Botcazou wrote:
> > Apparently this problem only shows up for x86 when using Sun tools, but
> > when using GNU tools, it also shows up for sparc.
> Do you have a testcase? AFAIK the problem only shows up with the Sun tools.
I meant when using GCC with the Sun ass
On Thu, May 12, 2005 at 12:48:46AM +0200, Peter S. Mazinger wrote:
> Hello!
>
> I have gotten under peculiar circumstances following:
> (sysvinit) init.o: relocation R_386_GOTOFF against protected function
> `main' can not be used when making a shared object
>
> libc.so does not provide a weak '
Wolfgang Bangerth wrote:
Mark,
it occurred to me that asking the question you pose may use language that is
more unfamiliar than necessary. How about this question instead -- assume
struct S { int s; };
struct X {
int i;
struct S s;
};
void g(struct S*);
void f() {
X x;
The attribute might well be unnecessary, and once it's in it's in forever.
And I suspect supporting
different semantics for different calls will create problems down the line,
somehow or other
(although I confess I don't think of any offhand).
Attributes and flags have more or less the same effec
Our proposed approach is to -- by default -- assume that "g" may access all
of "b". However, in the event that the corresponding parameter to "g" has an
attribute (name TBD, possibly the same as the one that appears in Danny's
recent patch), then we may assume that "g" (and its callees) do not
Paul Koning <[EMAIL PROTECTED]> writes:
> Still, never mind what the C spec appears to say, optimizing away the
> cast cannot possibly what the user intended.
The user might have written a routine which takes a 'volatile int *',
with the intent that routine would be used on both regular and
volat
Mark,
it occurred to me that asking the question you pose may use language that is
more unfamiliar than necessary. How about this question instead -- assume
struct S { int s; };
struct X {
int i;
struct S s;
};
void g(struct S*);
void f() {
X x;
g(&x.s);
}
Would the
Bernd Jendrissek wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 11, 2005 at 11:42:05AM -0700, Mark Mitchell wrote:
no obvious answer.
May I bash my head against the wall? :)
Sure, it's a free world!
The struct declaration places an obligation on the compiler to provide
an *extern
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 11, 2005 at 11:42:05AM -0700, Mark Mitchell wrote:
> no obvious answer.
May I bash my head against the wall? :)
> In short, the issue is, when given the following code:
>
> struct A {...};
> struct B { ...; struct A a; ...; };
Telli
On Tue, 2005-05-10 at 23:35 -0700, Mark Mitchell wrote:
> GCC 3.4.4 RC1 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050510/
>
> As usual, please test -- by using exactly those tarballs, so that we can
> detect packging errors. Put problems into Bugzilla, and Cc: me. At
On May 11, 2005, at 2:42 PM, Mark Mitchell wrote:
Our proposed approach is to -- by default -- assume that "g" may
access all of "b". However, in the event that the corresponding
parameter to "g" has an attribute (name TBD, possibly the same as the
one that appears in Danny's recent patch), the
Giovanni Bajo wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote:
Our proposed approach is to -- by default -- assume that "g" may
access all of "b". However, in the event that the corresponding parameter to
"g" has an attribute (name TBD, possibly the same as the one that
appears in Danny's recent p
On May 11, 2005, at 11:42 AM, Mark Mitchell wrote:
Kenny and I had a long conversation about the aliasing issue, and
reached the following proposed solution.
In short, the issue is, when given the following code:
struct A {...};
struct B { ...; struct A a; ...; };
void f() {
B b;
g(
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Our proposed approach is to -- by default -- assume that "g" may
> access all of "b". However, in the event that the corresponding parameter to
> "g" has an attribute (name TBD, possibly the same as the one that
> appears in Danny's recent patch), then w
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
> > Are there any objections to exporting structure layout from GCC, in a
> > format which can be parsed in a straightforward manner? Such a patch
> > could be used as a GPL circumvention device, but I'm not sure how
> > relevant this is in practice
* Ian Lance Taylor:
> I actually have a vague recollection that gcc used to implement
> something along these lines, but I couldn't find it in five minutes of
> searching.
There are several patches for (or forks of) GCC which implement
similar functionality.
Florian Weimer <[EMAIL PROTECTED]> writes:
> Are there any objections to exporting structure layout from GCC, in a
> format which can be parsed in a straightforward manner? Such a patch
> could be used as a GPL circumvention device, but I'm not sure how
> relevant this is in practice because GCC
On Wed, 11 May 2005, Roman Kennke wrote:
>>> Is the pkgconfig directory at the correct location when put under lib/,
>>> or shouldn't this be libdata/ instead?
>> What system has $(prefix)/libdata? None I'm familiar with.
> The BSDs for example use libdata dirs. I suppose the patch is from a BSD
Am Mittwoch, den 11.05.2005, 16:20 -0400 schrieb Daniel Jacobowitz:
> On Wed, May 11, 2005 at 10:18:01PM +0200, Gerald Pfeifer wrote:
> > Is the pkgconfig directory at the correct location when put under lib/,
> > or shouldn't this be libdata/ instead?
> >
> > I've seen the following patch in use,
Daniel Jacobowitz wrote:
On Wed, May 11, 2005 at 10:18:01PM +0200, Gerald Pfeifer wrote:
Is the pkgconfig directory at the correct location when put under lib/,
or shouldn't this be libdata/ instead?
I've seen the following patch in use, that's why I'm wondering.
What system has $(prefix)/libdata?
On Wed, May 11, 2005 at 10:18:01PM +0200, Gerald Pfeifer wrote:
> Is the pkgconfig directory at the correct location when put under lib/,
> or shouldn't this be libdata/ instead?
>
> I've seen the following patch in use, that's why I'm wondering.
What system has $(prefix)/libdata? None I'm famil
Is the pkgconfig directory at the correct location when put under lib/,
or shouldn't this be libdata/ instead?
I've seen the following patch in use, that's why I'm wondering.
Gerald
--- libjava/Makefile.in.origTue Aug 31 09:39:04 2004
+++ libjava/Makefile.in Tue Aug 31 09:39:46 2004
@@ -180,
* Paolo Bonzini:
>> Additional members are permitted, and the fields can be order. In
>> order to create a portable Ada interface, I have to write a short C
>> program which uses sizeof and offsetof to extract the structure
>> layout. In theory, it is possible to create compile-time-only tests
>
Wolfgang Bangerth wrote:
I understand that you are talking about ISO C, but one relevant case (in C++)
to look out for that is similar is this one, which certainly constitutes
legitimate and widespread use of language features:
class A {...};
class B : public A { ... };
void f() {
B b;
On Wed, May 11, 2005 at 11:58:39AM -0700, Greg McGary wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
> > ... Or you could try telling the entire compiler to treat them as
> > registers, instead of just reload. That's likely to work as well or
> > better.
>
> So, I define these as a sep
> In short, the issue is, when given the following code:
>
>
> struct A {...};
> struct B { ...; struct A a; ...; };
>
>
> void f() {
>B b;
>g(&b.a);
> }
>
> does the compiler have to assume that "g" may access the parts of "b"
> outside of "a".
I understand that you are talking
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> ... Or you could try telling the entire compiler to treat them as
> registers, instead of just reload. That's likely to work as well or
> better.
So, I define these as a separate register class, and only the movM
insn patterns get constraints that
Kenny and I had a long conversation about the aliasing issue, and
reached the following proposed solution.
In short, the issue is, when given the following code:
struct A {...};
struct B { ...; struct A a; ...; };
void f() {
B b;
g(&b.a);
}
does the compiler have to assume that "g
On Wed, May 11, 2005 at 11:31:51AM -0700, Greg McGary wrote:
> I have a port for a multi-processor with high-latency memory accesses,
> even for cache hits. Each CPU core has a small private scratchpad RAM
> with 1 cycle access. I'd like to persuade GCC to use the scratchpad
> (I'll probably allo
I have a port for a multi-processor with high-latency memory accesses,
even for cache hits. Each CPU core has a small private scratchpad RAM
with 1 cycle access. I'd like to persuade GCC to use the scratchpad
(I'll probably allocate somewhere between 8 and 32 words) for reload,
rather than stack
Additional members are permitted, and the fields can be order. In
order to create a portable Ada interface, I have to write a short C
program which uses sizeof and offsetof to extract the structure
layout. In theory, it is possible to create compile-time-only tests
suitable for cross-compilation
> size -f tmp.o
>textdata bss dec hex filename
> 322 0 0 322 142 tst.o
>
> Looking at the debugging dump shows that the there's a lot of
> variables generate by SRA, indeed after adding
>
> -fno-tree-sra
>
> textdata bss dec hex fi
"Etienne Lorrain" <[EMAIL PROTECTED]> writes:
> > Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> >
> >> Some of those problem may also exist in GCC-4.0 because this
> >> version (and the 4.1 I tested) gives me an increase of 60% of the
> >> code size compared to 3.4.3.
> >
> >
>
>
> I'm getting these errors:
>
> Bootstrap comparison failure!
> ./bt-load.o differs
> ./expmed.o differs
> build/gengtype-lex.o differs
>
> I've picked bt-load.o for a closer look because it was the smallest
> of the affected files. I've found that the register allocation order
> for branch_t
> Some experimentation shows that the assembler from the two dates behaves
> the same,
> and eabi.S is identical, but the preprocessed source files differ. cc1
> used to define
> _RELOCATABLE, but it does not any more.
The problem is that target_flags_explicit was not being set on the
options t
When interfacing with C with other languages, it is often necessary to
write wrapper functions to access C structs because there are no
general (and free) tools available which can generate structure layout
information from C sources.
For example, suppose that I want to write Ada code which uses t
Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> If I compile that with GCC-3.4, I get:
>
> $ size tmp.o
> textdata bss dec hex filename
> 243 0 0 243 f3 tmp.o
>
> With GCC-4.0:
>
> $ size tmp.o
> textdata bss dec hex filename
> 387 0
> Etienne Lorrain <[EMAIL PROTECTED]> wrote:
>
>> Some of those problem may also exist in GCC-4.0 because this
>> version (and the 4.1 I tested) gives me an increase of 60% of the
>> code size compared to 3.4.3.
>
>
> This is a serious regression which should be submitted in Bugzilla. Would
> y
I'm getting these errors:
Bootstrap comparison failure!
./bt-load.o differs
./expmed.o differs
build/gengtype-lex.o differs
I've picked bt-load.o for a closer look because it was the smallest
of the affected files. I've found that the register allocation order
for branch_target_load_optimize diffe
Hi,
Since you asked on your website for build confirmations, I'm sending this
note.
output config.guess : i386-unknown-netbsdelf2.0.2
output gcc -v :
Using built-in specs.
Target: i386-unknown-netbsdelf2.0.2
Configured with: gcc-4.0.0/configure --enable-languages=c,c++
Thread model: posix
Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> Some of those problem may also exist in GCC-4.0 because this
> version (and the 4.1 I tested) gives me an increase of 60% of the
> code size compared to 3.4.3.
This is a serious regression which should be submitted in Bugzilla. Would
you please ta
> GCC 3.4.4 RC1 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050510/
I downloaded and rebuild for ia32 with latest pre binutils on
my project and noticed an increase of size. I am compiling with -Os
because size is very important in my case - so I invertigated by
lookin
Florian Weimer wrote:
* Ranjit Mathew:
Without looking at the patent, I would hazard the guess
that it is about Win32 Structured Exception Handling (SEH):
http://www.microsoft.com/msj/0197/exception/exception.aspx
(The linked-to mail from the GCC mailing list seems to
confirm this.)
Indeed. Expli
Hi!
tree_ssa_useless_type_conversion_1 is stripping away
the cast from
const char *a = "Foo";
*((char *)&a[2]) = 0;
because
/* Pointers and references are equivalent once we get to GENERIC,
so strip conversions that just switch between them. */
else if (POINTER_TYPE_P (inner_type)
* Paul Koning:
>> "Florian" == Florian Weimer <[EMAIL PROTECTED]> writes:
>
> Florian> Indeed. Explicitly pushing an exception frame pointer on
> Florian> the main stack is covered by the patent.
>
> Oh, like VMS has done since V1.0, in 1978?
I fail to see the inventive step in that patent
> "Florian" == Florian Weimer <[EMAIL PROTECTED]> writes:
Florian> Indeed. Explicitly pushing an exception frame pointer on
Florian> the main stack is covered by the patent.
Oh, like VMS has done since V1.0, in 1978?
paul
Is there any patch within GCC that supports SEH, or is this external
patch
the only one?
Thanks
Ingrid
-Original Message-
From: Steven Bosscher [mailto:[EMAIL PROTECTED]
Sent: 11 May 2005 13:20
To: gcc@gcc.gnu.org
Cc: Paolo Bonzini; Ingrid Marson
Subject: Re: Borland software patent res
Mark Mitchell wrote:
> GCC 3.4.4 RC1 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050510/
>
> As usual, please test -- by using exactly those tarballs, so that we can
> detect packging errors. Put problems into Bugzilla, and Cc: me. At
> this point, the only problems th
* Ranjit Mathew:
> Without looking at the patent, I would hazard the guess
> that it is about Win32 Structured Exception Handling (SEH):
>
> http://www.microsoft.com/msj/0197/exception/exception.aspx
>
> (The linked-to mail from the GCC mailing list seems to
> confirm this.)
Indeed. Explicitly
Florian Weimer wrote:
> * Ingrid Marson:
>
>
>>The Borland patent is a patent for standard exception handling
>>http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL
>>&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,628,016.WKU.&OS=PN/5,628,
>>016&RS=PN/5,628,016
>
>
> At leas
On Wednesday 11 May 2005 13:40, Paolo Bonzini wrote:
> > The Borland patent is a patent for standard exception handling
> > http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL
> > &p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,628,016.WKU.&OS=PN/5,628,
> > 016&RS=PN/5,628,016
>
* Ingrid Marson:
> The Borland patent is a patent for standard exception handling
> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL
> &p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,628,016.WKU.&OS=PN/5,628,
> 016&RS=PN/5,628,016
At least on Linux, GCC implements a differe
The Borland patent is a patent for standard exception handling
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL
&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,628,016.WKU.&OS=PN/5,628,
016&RS=PN/5,628,016
http://snipurl.com/et1w
Paolo
I'm writing an article today following Dimitri O. Paun's talk at the
Wine Developer conference in Stuttgart. He said that Wine development is
restricted due to a Borland software patent, which prevents an important
feature from being added to GCC.
The Borland patent is a patent for standard except
On Tue, 2005-05-10 at 17:32, Sami Khawam wrote:
> Hi Gary,
>
> Thanks a lot for the tip.
>
> After debugging, the problem seem to be coming from 'emit_conditional_move'
> which is called by 'expand_sdiv_pow2' when converting division-by-constants
> into
> shifting.
> The problem is that the arc
Hi,
OK, I guess the latest compilers from Sun ship with a better "as".
Unfortunately I'm stuck with Sun Studio One 7 for now. Maybe it should
be documented that a recent version of "as" is needed by gcc.
A version not affected by the bug. 4.0.0 bootstraps on Solaris 2.5.1 with
as: WorkShop Compil
61 matches
Mail list logo
