Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Andreas Jaeger <[EMAIL PROTECTED]> writes:
>
>> make proto on gcc trunk fails on Linux/x86_64 with:
>
> Do you actually need protoize and unprotoize? I think it would be
> nice to deprecate them. Prototypes have been available for at least
> 15 year
Andreas Jaeger <[EMAIL PROTECTED]> writes:
> make proto on gcc trunk fails on Linux/x86_64 with:
Do you actually need protoize and unprotoize? I think it would be
nice to deprecate them. Prototypes have been available for at least
15 years now.
> The trivial workaround is to add to gcc/Makefil
On Tue, Jun 27, 2006 at 03:48:30AM -0400, Paul Hilfinger wrote:
>
> I guess that I'm simply suggesting that it might be nice if the sort
> of modification suggested by Albert Chin's response to my question
> could be installed automatically under control of a configuration
> option (e.g.), or as a
Jivin Shaun Jackman lays it down ...
> On 6/27/06, David McCullough <[EMAIL PROTECTED]>
> wrote:
> >Are you using the ld-elf2flt/elf2flt.ld combo ?
> >
> >It lays things out in a known way and has a '-move-rodata' option which
> >will put the rodata in with the .text if it contains no relocation
On 6/27/06, David McCullough <[EMAIL PROTECTED]> wrote:
Are you using the ld-elf2flt/elf2flt.ld combo ?
It lays things out in a known way and has a '-move-rodata' option which
will put the rodata in with the .text if it contains no relocation info
needed at runtime.
Something like this on the l
Jivin Shaun Jackman lays it down ...
> On 6/27/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> >I'm attempting to build an XIP "Hello, world!" application for the ARM
> >processor. I'm compiling with -fPIC -msingle-pic-base with the default
> >-mpic-register=r10. The layout of the memory map is suc
I'm looking at the H8/300 frame debugging info, and it seems to me
that gdb needs to have at least *some* information about where the
return address is in order to unwind the stack using dwarf2 call frame
information, perhaps because H8/300 saves the RA on the stack, not in
a register. However, w
Manuel López-Ibáñez wrote:
On 27/06/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
Manuel López-Ibáñez wrote:
> Apart from its main
> purpose, I believed that the use of 'const' helps the compiler to
> optimise the code.
It generally doesn't, unless you apply const to the underlying type, and
no
On 27/06/06, Andrew Haley <[EMAIL PROTECTED]> wrote:
OK, now you're getting the idea, you need to think about the
difference between
const union tree_node *
union tree_node *const
const union tree_node *const
My fault then, I was erroneously assuming that if "tree" is equal to
"union
Andreas Jaeger <[EMAIL PROTECTED]> writes:
> /cvs/gcc-svn/trunk/gcc/protoize.c: In function ‘edit_fn_definition’:
> /cvs/gcc-svn/trunk/gcc/protoize.c:3506: warning: argument ‘clean_text_p’
> might be clobbered by ‘longjmp’ or ‘vfork’
That's probably the same bug as PR21059.
Andreas.
--
Andrea
make proto on gcc trunk fails on Linux/x86_64 with:
/abuild/builds/gcc/./prev-gcc/xgcc -B/abuild/builds/gcc/./prev-gcc/
-B/opt/gcc/4.2-devel/x86_64-suse-linux-gnu/bin/ -c -DUNPROTOIZE -g -O2
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedantic -Wno-long-long
On 27/06/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
Manuel López-Ibáñez wrote:
> Apart from its main
> purpose, I believed that the use of 'const' helps the compiler to
> optimise the code.
It generally doesn't, unless you apply const to the underlying type, and
not just the pointer.
IE you
Manuel López-Ibáñez wrote:
> Dear all,
>
> from comments in the #gcc irc channel, I understood that it is not
> advisable for gcc patches to use the const qualifier in function
> prototypes. I would like to understand why. Apart from its main
> purpose, I believed that the use of 'const' helps the
On 6/27/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
I'm attempting to build an XIP "Hello, world!" application for the ARM
processor. I'm compiling with -fPIC -msingle-pic-base with the default
-mpic-register=r10. The layout of the memory map is such that the
.text and .rodata are in flash memor
On 6/27/06, Erwin Authried <[EMAIL PROTECTED]> wrote:
Hi,
which compiler/binutil version did you use? Could you post the source
that you used?
One other thing (although that doesn't seem to have to do with your
problem): It is important that you use -fpic (not -fPIC) so that the
correct multilib
On 6/27/06, Minh D. Nguyen <[EMAIL PROTECTED]> wrote:
I though the problem is that the delayed branch scheduling pass changes the
some instructions for the delayed branch, but it does not change the control
flow graph data.
It does not change the control flow graph. It destroys it. It doesn't
I'm attempting to build an XIP "Hello, world!" application for the ARM
processor. I'm compiling with -fPIC -msingle-pic-base with the default
-mpic-register=r10. The layout of the memory map is such that the
.text and .rodata are in flash memory, and the .got, .data and so
forth are loaded into RA
Dear all,
I am trying to embed the control flow graph information into the assembly code
generated in the final pass of gcc.
While doing that, I found a very strange situation which the control flow
graph does not comply with the gcc internal document. In the internal
document, it is stated
Andrew Pinski wrote:
>"Stupid" example where a const argument can change:
>tree a;
>int f(const tree b)
>{
> TREE_CODE(a) = TREE_CODE (b) + 1;
> return TREE_CODE (b);
>}
You're not changing the constant argument "b", just what "b" might point
to. I don't think there are any optimizing opportuni
I already sent a patch for that to the java-patches list...
Andreas Tobler wrote:
Andrew Pinski wrote:
On Jun 26, 2006, at 10:02 PM, Andrew Pinski wrote:
On Jun 26, 2006, at 9:01 AM, Bryce McKinlay wrote:
Otherwise, this is fine.
No it is not, it broke bootstrap on powerpc-darwin:
Di
On Tue, 2006-06-27 at 13:51 +0100, Manuel López-Ibáñez wrote:
> from comments in the #gcc irc channel, I understood that it is not
> advisable for gcc patches to use the const qualifier in function
> prototypes. I would like to understand why. Apart from its main
> purpose, I believed that the use
On Tue, Jun 27, 2006 at 11:53:52AM +0200, Roland Persson wrote:
> I've been trying patterns like this one:
>
> (define_insn "*pip_add_di_sesi"
> [(set (match_operand:DI 0 "register_operand" "=r")
> (plus:DI (match_operand:DI 1 "register_operand" "r")
> (sign_extend:DI (
On Jun 27, 2006, at 7:58 AM, Gabriel Dos Reis wrote:
We we do have numbers that support that claim for real programs, then
we have a bug in the optimizers :-)
Huh?
"Stupid" example where a const argument can change:
tree a;
int f(const tree b)
{
TREE_CODE(a) = TREE_CODE (b) + 1;
return T
On Jun 27, 2006, at 6:29 AM, Manuel López-Ibáñez wrote:
On 27/06/06, Andrew Haley <[EMAIL PROTECTED]> wrote:
Well, const functions are nonstandard, and gcc itself is written in
Standard C so they can't be used. But As for const args, I can't see
any good reason not to use them, and there are
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| Dear all,
|
| from comments in the #gcc irc channel, I understood that it is not
| advisable for gcc patches to use the const qualifier in function
| prototypes. I would like to understand why. Apart from its main
| purpose, I believed that the
On 27/06/06, Andrew Haley <[EMAIL PROTECTED]> wrote:
Well, const functions are nonstandard, and gcc itself is written in
Standard C so they can't be used. But As for const args, I can't see
any good reason not to use them, and there are 400 uses in gcc.
I meant const arguments, sorry for the c
thanks,There is a macro LEGITIMIZE_RELOAD_ADDRESS.Accroding to gcc internals
"It is a C compound statement that attempts to replace x, which is an
address that needs
reloading, with a valid memory address for an operand of mode mode.
win will be a
C statement label elsewhere in the code".
I'm not
Dear all,
from comments in the #gcc irc channel, I understood that it is not
advisable for gcc patches to use the const qualifier in function
prototypes. I would like to understand why. Apart from its main
purpose, I believed that the use of 'const' helps the compiler to
optimise the code. Of cou
> > > On the other hand, as far as I can
> > > see, __float80 is undocumented and unused for the i386. Why does it
> > > exist?
> >
> > Jan added it with __float128 also:
> > 2003-10-30 Jan Hubicka <[EMAIL PROTECTED]>
> >
> > (ix86_init_mmx_sse_builtins): Add __float80, __float128.
>
On Mon, 26 Jun 2006, H. J. Lu wrote:
> I have no strong opinion on the support for __float80. But the current
> behavior seems odd to me. Also, we have incomplete support for
> __float128. There is no runtime support for __float128 at all on
> x86-64.
Feel free to add such support using soft-fp a
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Rask Ingemann Lambertsen
> Sent: Monday, June 26, 2006 19:25
> To: Roland Persson
> Cc: gcc@gcc.gnu.org
> Subject: Re: Matching of non-standard instructions
>
>
> In a similiar case, only with 8 and
> > 2. Remember to include the appropriate -W,l-R option or whatever in
> >[each] and every compilation.
>
> I don't think it's a good idea to compile in rpaths to non-standard
> (user-specific) directories by default. This can lead to trapdoor
> rpaths and generally makes the binaries less
32 matches
Mail list logo
