>> (define_insn "loadsf"
>> [(set (match_operand:SF 0 "register_operand" "=r")
>>(mem:SF (match_operand:SI 1 "immediate_operand" "m")))]
>This makes no sense, because the constraint means that the mem's
operand is >an immediate before reload (and you want it to be a
register), and a mem
You still have not demonstrated that this is a real problem. If someone
is having a real problem, then we can offer them a simple sed script to
fix it.
If I am recalling the original posting correctly, the fact that
gcc behaves differently to "most other compilers" is the actual
problem. Issues
> which has the desited effect of disabling unit-at-a-time, but
> runs aground in cgraph_expand_function() with a segfault,
> when it attempts to call lang_hooks.callgraph.expand_function().
>
> It seems that GCC is handling lang_hooks.callgraph.expand_function
> in an inconsistent fashion. Is a n
Turner, Keith S <[EMAIL PROTECTED]> wrote:
> The man page information for the gcc c++98 option says that the
> compiler will be compliant with "The 1998 ISO C++ standard plus
> amendments." Are the amendments referring to the changes to the C++
> standard that is now "ISO/IEC 14882:2003". I need
I managed to build gcc-4.0.2 using MinGW 5.0.0 candidate gcc 3.4.4 with command
`make bootstrap' and configured with flag --enable-languages=c,c++ in MSys
together with msysDTK 1.0.1 and upgraded autoconf(2.59), automake(1.82) and
libtool(1.5) on a WinXP system. Since lack of test tools, testing
Hi,
i just built GCC 4.0.2 on AIX 5.1 using the following commands:
../gcc-4.0.1/configure --with-libiconv-prefix=/usr --disable-nls
--disable-multilib
make bootstrap-lean
make install
$ config.guess
powerpc-ibm-aix5.1.0.0
$ gcc -v
Using built-in specs.
Target: powerpc
I am trying to cross compile GCC for an AMCC 440SP
platform (powerpc-linux). Binutils and bootstrap GCC
compile fine, but when I make glibc it errors out with
the following:
snippet
if test -r
/opt/luan2/toolchain/build/glibc/csu/abi-tag.h.new;
then mv -f
/opt/luan2/toolchain/build/gli
Jeff Stevens wrote:
>I am trying to cross compile GCC for an AMCC 440SP
>platform (powerpc-linux). Binutils and bootstrap GCC
>compile fine, but when I make glibc it errors out with
>the following:
>
To be sure, are you using a gcc3.4.x compiler together with glibc2.3.5,
as required:
http://
Ah, but which is the real one ?
[TXT] md5sums.txt 26-Oct-2005 03:41 389
[TXT] sha1sums.txt26-Oct-2005 03:41 491
[ ] subversion-1.3.0-rc1..> 26-Oct-2005 03:42 4.7M
[TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:42 189
[CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:43 6.1
On Wed, 2005-10-26 at 11:32 +, Toon Moene wrote:
> Ah, but which is the real one ?
>
> [TXT] md5sums.txt 26-Oct-2005 03:41 389
> [TXT] sha1sums.txt26-Oct-2005 03:41 491
> [ ] subversion-1.3.0-rc1..> 26-Oct-2005 03:42 4.7M
> [TXT] subversion-1.3.0-rc1..> 26-Oct-2005
> Writing sed scripts that change source code is likely to be very
> unpalletable to some users. If you're working in an ISO9000
> environment where every single source line change is tracked
> by a rather burdensome process, the last thing you want to do
> is invoke that process for some source ba
Thanks. It seems work now. But... when I define the like insn for QImode,
(define_insn "loadqi_men"
[(set (match_operand:QI 0 "register_operand" "=r")
(mem:QI (match_operand:SI 1 "general_operand" "r")))]
""
"lbu.u\t%0,0(%1)"
)
The compiler comes out such error,
error: insn do
On Oct 25, 2005, at 9:33 PM, Joe Buck wrote:
Be interesting to see the results of a grep on a large software
base. Does anyone have ready access to, say a linux distro handy?
Of all the hits I know about, none of them were an accident.
You're forgetting something: GNU/Linux distros are built
On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:
Are you really saying that someone is using ASCII line art in comments
that tweaks this behavior?
Yes, I'm sorry if previous message didn't make this clear.
What are the plans for it?
Often, I find it very useful, will be renamed to gcc-svn and kept alive?
Thanks,
Paolo.
Mike Stump wrote:
On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:
Are you really saying that someone is using ASCII line art in comments
that tweaks this behavior?
Yes, I'm sorry if previous message didn't make this clear.
Why would line art ever tweak this problem, why would lines
in such ar
On Wed, Oct 26, 2005 at 08:16:31AM +0200, Steven Bosscher wrote:
> On Oct 26, 2005 02:30 AM, Joe Buck <[EMAIL PROTECTED]> wrote:
> > I'm still waiting for an explanation as to why this is an important
> > issue, other than that someone has a customer who says that it is.
> > Why is it important to
On Oct 25, 2005, at 11:05 PM, Andrew Pinski wrote:
Why did Apple revert that patch, well because there was push back from
internal developers who did not want to fix their code. Why should
this case be any difference?
I'm sorry you don't understand the differences. In one, we have
every exp
On Oct 26, 2005, at 12:18 PM, Robert Dewar wrote:
Mike Stump wrote:
On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:
Are you really saying that someone is using ASCII line art in
comments
that tweaks this behavior?
Yes, I'm sorry if previous message didn't make this clear.
Why would line
On Wednesday 26 October 2005 18:28, Joe Buck wrote:
> That's what we have standards for: so that compilers work the same way
> for standard-conformant code.
And we have de facto standards that you just want to ignore.
Gr.
Steven
>
> On Oct 26, 2005, at 12:18 PM, Robert Dewar wrote:
>
> > Mike Stump wrote:
> >
> >> On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:
> >>
> >>> Are you really saying that someone is using ASCII line art in
> >>> comments
> >>> that tweaks this behavior?
> >>>
> >> Yes, I'm sorry if previous mess
On Oct 26, 2005, at 9:28 AM, Joe Buck wrote:
This is a case of unspecified behavior.
?
That's what we have standards for: so that compilers work the same way
for standard-conformant code.
But in this case, we are talking about the behavior when the
compiler is
given code with *unspecified
Paolo Carlini <[EMAIL PROTECTED]> wrote:
> What are the plans for it?
> Often, I find it very useful, will be renamed to gcc-svn and kept alive?
It'll stay alive, but it'll get less and less useful, since it doesn't give
any information you can't find with "svn log".
--
Giovanni Bajo
Howard Hinnant wrote:
Some programmers purposefully put trailing whitespace on their art in
order to prevent translation phase 2 line splicing. And it actually
works everywhere but gcc. Mind you I'm not defending this practice.
I'm just reporting what happens in the field, and giving the
Steven Bosscher wrote:
On Wednesday 26 October 2005 18:28, Joe Buck wrote:
That's what we have standards for: so that compilers work the same way
for standard-conformant code.
And we have de facto standards that you just want to ignore.
No, conflicting "de facto" behaviors (certainly not s
On Oct 26, 2005, at 9:39 AM, Andrew Pinski wrote:
I still am trying to figure out why this was even brought up if it
was only due to ASCII art, that seems silly.
sorry ("I find ascii line art silly"); ;-)
We could do that!
If we didn't have any customers or if we expected they wouldn't brin
On Oct 26, 2005, at 9:58 AM, Robert Dewar wrote:
No, conflicting "de facto" behaviors (certainly not standards), that
cannot all be resolved. In this case, we have to worry about past
gcc behavior and behavior of foreign compilers.
Yes. I've asked, how many lines exist that rely upon this, the
On Oct 25, 2005, at 5:40 PM, Joe Buck wrote:
The problem, I think, is that the behavior of both GCC *and* the
other compilers does not serve the users.
The reason is that there simply isn't any reason why a user would
use a backslash to continue a C++ comment on purpose, and plenty of
reason wh
>
> On Oct 26, 2005, at 9:39 AM, Andrew Pinski wrote:
> > I still am trying to figure out why this was even brought up if it
> > was only due to ASCII art, that seems silly.
>
> sorry ("I find ascii line art silly"); ;-)
>
> We could do that!
That is just stupid, that is infact would be inva
>
> On Oct 26, 2005, at 9:58 AM, Robert Dewar wrote:
> > No, conflicting "de facto" behaviors (certainly not standards), that
> > cannot all be resolved. In this case, we have to worry about past
> > gcc behavior and behavior of foreign compilers.
>
> Yes. I've asked, how many lines exist that r
worrying about other compilers in my opinion. Having gcc compile
non-portable code accepted by other compilers is a useful goal, but
one of low priority compared to maintaining compatibility as far as
possible between gcc versions.
You mean like the change between 2.95 that worked the way Howard
Mike Stump wrote:
Yes. I've asked, how many lines exist that rely upon this, the answer
was zero. We can have someone that has ready access to sourceforge or
the google cache to count there (Hi Matt), to improve the answer, but
my guess is that it would remain fairly low.
of course that
Dale Johannesen wrote:
Yes. From the user's point of view, the best thing appears to be
treating backslashes in C++ comments as part of the comment,
regardless of what follows them; that seems to follow the principle
of least surprise. That's not standard conforming, and therefore I'm
not advoc
On Wednesday 26 October 2005 18:58, Robert Dewar wrote:
> Steven Bosscher wrote:
> > On Wednesday 26 October 2005 18:28, Joe Buck wrote:
> >>That's what we have standards for: so that compilers work the same way
> >>for standard-conformant code.
> >
> > And we have de facto standards that you just
> It'll stay alive, but it'll get less and less useful, since it
> doesn't give any information you can't find with "svn log".
That's not the purpose of that list. That list is to notify people of
commits that they might not have been aware of. It needs to give
enough information to let the rea
Robert Dewar wrote:
Seems a weak argument to me. Changing gcc would create incompatibilities
with previous behavior of gcc, and that is FAR more significant than
worrying about other compilers in my opinion. Having gcc compile
non-portable code accepted by other compilers is a useful goal, but
on
DJ Delorie wrote:
>>It'll stay alive, but it'll get less and less useful, since it
>>doesn't give any information you can't find with "svn log".
>>
>>
>That's not the purpose of that list. That list is to notify people of
>commits that they might not have been aware of. It needs to give
>eno
On Wed, 2005-10-26 at 18:18 +0200, Paolo Carlini wrote:
> What are the plans for it?
It will stay alive, and svn log messages will be sent there.
>
> Often, I find it very useful, will be renamed to gcc-svn and kept alive?
I have no care in the world as to whether we rename it or not. It's a
DJ Delorie <[EMAIL PROTECTED]> writes:
| The fact that you can manually obtain the information elsewhere is
| irrelevant.
Fully agreed. I've found that list very useful for notifying me of
commits I've not been following closely.
-- Gaby
Hi,
I have my own pass that is trying to insert some statements in the code; the
statements would be of the form var_name = constant_value;
This is gcc-4.0.0, on debian testing 2.6.8, on an Intel Pentium 4.
I am obviously missing something, but I am not sure what. I don't exactly
know how (or i
Is there a HowTo out there on how to cross compile GCC
to run on another platform? I have an x86 host
running linux, and an embedded PowerPC 440SP target
running linux. I would like to compile GCC to run on
the target but am having some difficulties. I have
compiled the cross compiler fine, but
Scott Robert Ladd wrote:
Wouldn't it be possible to implement a compile-time option to enable the
desired behavior only for those poor folk who have this problem?
Of course this is possible, but it is only worth it if
a) there are a substantial number of such poor folk
b) it is not easy for
I don't see either is true here.
Actually, I agree. While I'd like the change to the compiler, I don't
want it to be a switch. Either we do it, or we don't.
-eric
Scott Robert Ladd wrote:
> Robert Dewar wrote:
>> Seems a weak argument to me. Changing gcc would create incompatibilities
>> with previous behavior of gcc, and that is FAR more significant than
>> worrying about other compilers in my opinion. Having gcc compile
>> non-portable code accepted by oth
Jeff Stevens wrote:
> Is there a HowTo out there on how to cross compile GCC
> to run on another platform? I have an x86 host
> running linux, and an embedded PowerPC 440SP target
> running linux. I would like to compile GCC to run on
> the target but am having some difficulties. I have
> compil
Dave Korn wrote:
> Jeff Stevens wrote:
>> Is there a HowTo out there on how to cross compile GCC
>> to run on another platform? I have an x86 host
>> running linux, and an embedded PowerPC 440SP target
>> running linux. I would like to compile GCC to run on
>> the target but am having some diffic
On 10/26/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> Jeff Stevens wrote:
> > Is there a HowTo out there on how to cross compile GCC
> > to run on another platform? I have an x86 host
> > running linux, and an embedded PowerPC 440SP target
> > running linux. I would like to compile GCC to run on
>
http://gcc.gelato.org/PortoAlegreMeeting
We had excellent sessions and extended time to discuss improving GCC
on Itanium. Please refer to the discussion notes for additional
information. Many thanks to the presenters and to Shin-ming Liu (HP)
for leading the discussion.
Yes I added the cross-compiler to the path and created
a separate build directory (ppc_gcc).
Thanks,
Jeff Stevens
--- Dave Korn <[EMAIL PROTECTED]> wrote:
> Dave Korn wrote:
> > Jeff Stevens wrote:
> >> Is there a HowTo out there on how to cross
> compile GCC
> >> to run on another platform
On Oct 26, 2005, at 1:16 PM, Andrew Pinski wrote:
What I am trying to say is that
the only reason why this was brought up was because of some little
ASCII art (ASCII art does have its place in comments, see rs6000.c for
an example of where ASCII art actually helps). If there was another
reason,
Joe Buck wrote:
On Tue, Oct 25, 2005 at 08:22:15PM -0400, Howard Hinnant wrote:
And it is not my assertion that gcc's behavior is better or worse
than other compilers. Only that gcc's behavior is unique in the
industry (I actually haven't tried all other modern compilers) and
that unique
Jeff Stevens <[EMAIL PROTECTED]> writes:
> Here is the configuration I ran:
>
> ../../source/gcc-3.4.4/configure
> --target=powerpc-linux --host=powerpc-linux
> --prefix=/opt/luan2/toolchain/bin --enable-shared
> --enable-threads --enable-languages=c
You need to specify --build, otherwise it defa
On Wednesday 26 October 2005 14:34, Mihai Burcea wrote:
> I have my own pass that is trying to insert some statements in the code;
> the statements would be of the form var_name = constant_value;
>
After you create the variables with create_tmp_var, you mark them to be
rewritten by adding them to
Take the following C program, and try to compile the resulting
code it outputs:
#include
int main(void)
{
printf("// \\\r\n a\n int i;\n");
printf("// \\\r a\r int i1;\n");
printf("int f(void) { return i1;}\n");
}
Here is the results:
GCC accepts it as \r is consider a newline
ICC rejects i
> This seems inconstaint for ICC as it considers \r\n as a newline but
> \r as a white space.
Note that on Windows/DOS/CPM based platforms, \r\n *is* a newline. It
is not defined what happens if you see those characters separately in
a text file, and different applications do different things up
On Oct 26, 2005, at 4:58 PM, DJ Delorie wrote:
To add to that, Mac text files use a bare \r as a newline.
Just a nit: 5 years ago that was true. Now \n is "native" but most
Mac software is pretty tolerant of newline representation due to its
history.
-Howard
> Just a nit: 5 years ago that was true. Now \n is "native"
Was that part of the OS/X migration, or otherwise? Just curious.
> but most Mac software is pretty tolerant of newline representation
> due to its history.
Of course, that only makes it *more* of a mess, and *less* likely that
gcc i
On Oct 26, 2005, at 5:17 PM, DJ Delorie wrote:
Just a nit: 5 years ago that was true. Now \n is "native"
Was that part of the OS/X migration, or otherwise? Just curious.
Part of the migration. OS X /is/ unix. Ok, I'm sure that's an
inaccurate statement and I trust the more experi
Howard Hinnant wrote:
If end-of-line white space is stripped in phase 1, do_thing2() is
called. If end-of-line white space is not stripped, do_thing1() is
called.
SO this is truly appallingly bad code, given its behavior depends
so radically on an implementation defined feature!
Probably
Stan Shebs wrote:
Again, I think this could be easily addressed in Apple's GCC only,
but that will mean that the software in question will compile on Macs,
but not on GNU/Linux. Of course, having apps on OS X that can't
be ported to Linux is not necessarily a bad thing from Apple's
point of view
Don't you think it is reasonable to fix horrible coding
errors like this, you are just asking for maintenance
problems. In the short term, kludging may make sense,
in the long term it sounds a bad idea to keep such
non-portable code around.
The problem is that it's portable to every other compi
>
> >
> > Don't you think it is reasonable to fix horrible coding
> > errors like this, you are just asking for maintenance
> > problems. In the short term, kludging may make sense,
> > in the long term it sounds a bad idea to keep such
> > non-portable code around.
>
> The problem is that it's p
Eric Christopher wrote:
Don't you think it is reasonable to fix horrible coding
errors like this, you are just asking for maintenance
problems. In the short term, kludging may make sense,
in the long term it sounds a bad idea to keep such
non-portable code around.
The problem is that it's por
Gary Funck wrote:
While working with GCC's language hooks, we found that
certain places in GCC test for a null value of
lang_hooks.callgraph.expand_function, but
cgraph_expand_function() calls the hook directly:
When cgraph was first added, it was optional, and could be disabled if
-fno-unit-a
Dueway Qi wrote:
I have found another similar case.
lang_hooks.callgraph.analyze_expr in gcc/gcc/cgraphunit.c
490 if (lang_hooks.callgraph.analyze_expr)
491 return lang_hooks.callgraph.analyze_expr (tp, walk_subtrees,
492
Jim Wilson wrote:-
> Gary Funck wrote:
> >While working with GCC's language hooks, we found that
> >certain places in GCC test for a null value of
> >lang_hooks.callgraph.expand_function, but
> >cgraph_expand_function() calls the hook directly:
>
> When cgraph was first added, it was optional, an
On 2005-10-26 12:39:31 -0400, Andrew Pinski wrote:
> But in a way you are defending it as you want GCC to change. If there
> was any other reason besides ASCII art, some people would be more willing
> to change but there is a simple fix person's code to get around this issue.
> And that is by not
On 2005-10-25 21:25:03 -0700, Joe Buck wrote:
> Code that depends on invisible whitespace to function correctly is
> already broken. At some point, someone will do the equivalent of
^^^
> delete-trailing-whitespace and break it.
or some software. I've already
On Oct 26, 2005, at 6:50 PM, Robert Dewar wrote:
The problem is that it's portable to every other compiler we've
tested. I am curious what icc and xlc do, but those are the only
two not tested.
Sorry, I have a different meaning of portable, for me the term is
related to the standard, meaning
i am currently working on a project of building M16C programs. i have an IRA
M16C/I8C C/C++ compiler on hand, but it is for Windows and i just can not live
w/o my Linux box. another reason i have to use GCC is that i must use some unit
test tools which ask for gcc.
i heard that gcc is also a cros
On Thu, Oct 27, 2005 at 01:48:57AM +0200, Vincent Lefevre wrote:
> On 2005-10-26 12:39:31 -0400, Andrew Pinski wrote:
> > But in a way you are defending it as you want GCC to change. If there
> > was any other reason besides ASCII art, some people would be more willing
> > to change but there is a
> i heard that gcc is also a cross-compiler, so i want to get know if
> it can be used as an M16C compiler?
Yes. The target you want to use to build gcc et al is "m32c-elf".
To compile for the m16c specifically, use "m32c-elf-gcc -mcpu=m16c ..."
> in GCC's home page, there is one item:
>
> 'Ju
On Oct 26, 2005, at 5:55 PM, Joe Buck wrote:
On Thu, Oct 27, 2005 at 01:48:57AM +0200, Vincent Lefevre wrote:
On 2005-10-26 12:39:31 -0400, Andrew Pinski wrote:
But in a way you are defending it as you want GCC to change. If
there
was any other reason besides ASCII art, some people would be
> i am currently working on a project of building M16C programs. i have an IRA
> M16C/I8C C/C++ compiler on hand, but it is for Windows and i just can not live
> w/o my Linux box.
Could you perhaps run the compiler under Wine?
74 matches
Mail list logo
