../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
`' for `mode' attribute
../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
`' for `mode' attribute
Sorry,these errors were just my mistake.I mistakenly comminted out the
following line in ABC.md file
(define_mode_attr UNITMODE [(SF
"kernel coder" <[EMAIL PROTECTED]> writes:
> > ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
> > `' for `mode' attribute
> > ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
> > `' for `mode' attribute
>
> Sorry,these errors were just my mistake.I mistakenly comminted out the
>
According to your proposal, I hereby send my comments referring to your web
pages about downloading gcc. To me, your instructions are absolutely
impossible to understand, they could not be more impossible to understand if
they were written in Hebroe or Mandarin.
I will not recommend you t
Gunnar Sjoo wrote:
Better to learn something easier, like solving Einstein's general field
equations.
If that is *really* the case, then probably you should now waste time on
gcc and instead try yourself on quantum gravity or string theory ;) ;)
Paolo.
Gunnar Sjoo wrote:
According to your proposal, I hereby send my comments referring to your web
pages about downloading gcc. To me, your instructions are absolutely
impossible to understand, they could not be more impossible to understand if
they were written in Hebroe or Mandarin.
I will
http://gcc.gnu.org/regtest/HEAD/ has a link to logfile "showing the
state of the tree since October, 2002". However, the current logfile
starts in July, 2005. Do you have the old data and can you add it to
the file or should the description for the link be updated? This page
doesn't appear to be
On 20 June 2006 10:08, Gunnar Sjoo wrote:
> According to your proposal, I hereby send my comments referring to your web
> pages about downloading gcc. To me, your instructions are absolutely
> impossible to understand, they could not be more impossible to understand if
> they were written in Hebro
Steven Bosscher wrote:
I don't see how I could do the same with the new scheme from the projects
page, which goes like this (quoted from that page):
-
For arithmetic, each hash table elt has the following slots:
* Operation. This is an rtx code.
* Mode.
* Operands 0,
(I am new in the list, so I understand that my opinion should not be
taken as seriously as others.)
Three persons have already given witty replies. I think most of us got
the point with the first one. Is it necessary to spend more time
reading emails about this? If you want to give some reply or
Hello Manuel,
three people may have given witty replies... isn't a smile worth that?
I'm also new to the list, and I respect it as a place for meaningful
discussions. At the same time, I'm not against any genuine and
spontaneous humour that may arise from time to time among such serious
matters
On 20/06/06, Roberto COSTA <[EMAIL PROTECTED]> wrote:
Hello Manuel,
three people may have given witty replies... isn't a smile worth that?
I'm also new to the list, and I respect it as a place for meaningful
discussions. At the same time, I'm not against any genuine and
spontaneous humour that ma
Does using fields of auto variables of union type generate code that
is less efficient than it would be using scalars?
That is, if in C++ I declare my variables as
foo()
{
union
{
int n;
};
...
}
as opposed to simply
foo()
{
int n;
...
}
would gcc generate inferior code? Or,
On Jun 20, 2006, at 7:20 AM, Andrew Haley wrote:
Does using fields of auto variables of union type generate code that
is less efficient than it would be using scalars?
If it is only one used field at a time (and the address is not taken),
then FRE will resolve them.
Take:
int f(int t, int t1
Andrew Haley wrote:
> Does using fields of auto variables of union type generate code that
> is less efficient than it would be using scalars?
>
> That is, if in C++ I declare my variables as
>
> foo()
> {
> union
> {
> int n;
> };
>
> ...
> }
>
> as opposed to simply
>
> foo()
> {
Andrew Pinski writes:
>
> On Jun 20, 2006, at 7:20 AM, Andrew Haley wrote:
>
> > Does using fields of auto variables of union type generate code that
> > is less efficient than it would be using scalars?
>
> If it is only one used field at a time (and the address is not taken),
> then FR
On 19 Jun 2006 16:45:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> I tried recreating this, but I couldn't. I get this:
...
> This of course is not ideal, since it unconditionally executes the
> rdhwr instruction. But it is not the same as what the OP reported.
I used stock gcc 4.1.1 t
Atsushi Nemoto <[EMAIL PROTECTED]> writes:
> On 19 Jun 2006 16:45:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > I tried recreating this, but I couldn't. I get this:
> ...
> > This of course is not ideal, since it unconditionally executes the
> > rdhwr instruction. But it is not the s
Hi,
I checked gcc's C99 status page today and noticed that C99 conformance
seems to evolve rather slowly. Most importantly for me, support for
complex data types is marked as broken for several years now.
Is there any hope that this might change in the foreseeable future?
Thanks,
Martin
--
Hi my name is Gyle Yearsley. I am a design engineer at ZiLOG. We are in the
process of releasing a new CPU. I have generated a gcc backend for this
processor. I have read your contributions page and was wondering what the
steps are and how to get permission to add this to the gcc distribution.
Tha
Gyle Yearsley <[EMAIL PROTECTED]> writes:
> Hi my name is Gyle Yearsley. I am a design engineer at ZiLOG. We are in the
> process of releasing a new CPU. I have generated a gcc backend for this
> processor. I have read your contributions page and was wondering what the
> steps are and how to get p
Support in GCC 4.2 for decimal floating types is based on drafts of
ISO/IEC WDTR 23732, which continues to change. There are some
differences between the most recent draft N1176 and what GCC implements,
and some other things that should probably change or at least be
documented. I'd appreciate so
Based purely on context, in the following documentation from:
http://gcc.gnu.org/onlinedocs/gccint/Code-Macros.html#Code-Macros
13.22.2 Code Macros
Code macros operate in a similar way to mode macros. See Mode Macros.
The construct:
(define_code_macro name [(code1 "cond1") ... (coden "
>
> Based purely on context, in the following documentation from:
>
> http://gcc.gnu.org/onlinedocs/gccint/Code-Macros.html#Code-Macros
>
>
>
> 13.22.2 Code Macros
>
> Code macros operate in a similar way to mode macros. See Mode Macros.
>
> The construct:
>
> (define_code_macro name
On 14/06/2006, at 10:47 AM, Mike Stump wrote:
Any suggestions? Does the -isysroot compiler flag fix this sort
of issue? It does not seem to be used in the gcc build.
I'd expect it might. Run with -v and see if isysroot is given to
ld. If not, add -Wl,-isysroot=... to pass it down to ld.
24 matches
Mail list logo