hi,
I'm having some trouble while understanding the following pic
code in function prologue of cris architecture.
if (current_function_uses_pic_offset_table)
{
/* A reference may have been optimized out (like the abort () in
fde_split in unwind-dw2-fde.c, at least 3.2.1) so ch
On Jun 30, 2006, at 12:40 AM, Mike Stump wrote:
On Jun 29, 2006, at 8:27 PM, Rajkishore Barik wrote:
I am trying to complie GCC 4.1 on an AIX 5.3 machine having 2 power5
processors.
Then this is the wrong list... You'd want gcc-help.
They also might want to read: http://gcc.gnu.org/insta
On Jun 29, 2006, at 8:27 PM, Rajkishore Barik wrote:
I am trying to complie GCC 4.1 on an AIX 5.3 machine having 2 power5
processors.
Then this is the wrong list... You'd want gcc-help.
Hi All,
I am trying to complie GCC 4.1 on an AIX 5.3 machine having 2 power5
processors.
I get the following error while trying to compile. Can someone help? "cc"
is IBM's xlC compiler.
cc -c -g-DHAVE_CONFIG_H -I.
-I../../gcc-4.1-20060310/fixincludes -I../include
-I../../gcc-4.1-2
Andreas Jaeger wrote:
Andreas Schwab <[EMAIL PROTECTED]> writes:
That's probably the same bug as PR21059.
That report even has a patch - but no action since december. Jim,
will you handle this one?
It isn't exactly the same problem, as there is no auto-inc address here.
So my patch in the
"kernel coder" <[EMAIL PROTECTED]> writes:
> 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
Snapshot gcc-4.0-20060629 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060629/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
This patch forces the use of GOT relocations instead of GOTOFF when
compiling execute-in-place (XIP) code. I've defined XIP as the
combination of -fpic and -msingle-pic-base.
There is room for improvement in using GOTOFF relocations for symbols
that will be in the same addressing space as the GOT
Vous leur manquez !
Pres de 1000 internautes utilisent quotidiennement ristrette.com.
Ils y trouvent de quoi se distraire, se cultiver, de quoi passer un
bon moment autour de Geneve, en Suisse, en Haute Savoie et dans
l'Ain.
Ristrette est ouvert gratuitement a tous.
Deja de nombreux interve
Vous leur manquez !
Pres de 1000 internautes utilisent quotidiennement ristrette.com.
Ils y trouvent de quoi se distraire, se cultiver, de quoi passer un
bon moment autour de Geneve, en Suisse, en Haute Savoie et dans
l'Ain.
Ristrette est ouvert gratuitement a tous.
Deja de nombreux interve
Joe Buck wrote:
> On Thu, Jun 22, 2006 at 09:06:28PM -0400, Daniel Berlin wrote:
>> As Joe Buck, a Steering Committee member said, you need to talk to RMS
>> directly and get him to accept the idea, before we can do anything about it.
>
> I already asked RMS directly, and he has approved. Again,
On Thu, 29 Jun 2006, Andreas Jaeger wrote:
> Current svn does not build, it fails for me with:
> build/genpreds: Internal error: RTL check: expected elt 0 type 'e' or 'u',
> have 's' (rtx match_code) in write_match_code_switch, at genpreds.c:546
>
> Roger, is this is a result of your changes?
Grr
Andreas Schwab writes:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
> > But it's really legal to cast away const?
>
> All that matters is the effective type of the accessed object, see 6.5#7.
It's not clear to me that it's legal to convert (const int*) to
(int*). 6.3.2.3, Pointers, says
2
On Thursday 29 June 2006 08:30, Beyond.Luo wrote:
> > Hi, all
> >When I compile FreeBSD6.0 using gcc4.1 instead of gcc3, lots of
> > errors are reported.
> > I knowes that gcc4.1 checks syntax more strictly, then how can I do now?
> > any command-line options?
On Thu, Jun 29, 2006 at 02:51:
On 6/29/06, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
No, it was PhilB, but it must have been two or three years ago now.
Thanks, Richard. I suspect svn r71881 is responsible. I'll start
testing and hopefully put a patch together. I would suspect r49871,
but this patch is in 4.0.3, which does
On 6/28/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
It was probably me. But why can't you do this yourself? Look at the
assembly. See what the output string is. Search for it in
config/arm/. Use svn blame, as already suggested.
I did search the assembler text and found the constant an
On Jun 29, 2006, at 9:20 AM, Paolo Bonzini wrote:
Well, G is known to escape anyway here. Even worse is this:
...
where there is not even the possibility to optimize *P1 in foo.
While compiling f1.c, the compiler does not even know that G
escapes and must assume the worse.
It's a diffe
Current svn does not build, it fails for me with:
build/genpreds /cvs/gcc-svn/trunk/gcc/config/i386/i386.md > tmp-preds.c
/bin/sh /cvs/gcc-svn/trunk/gcc/../move-if-change tmp-constrs.h tm-constrs.h
build/genpreds: Internal error: RTL check: expected elt 0 type 'e' or 'u', have
's' (rtx match_cod
int G;
void foo(const int *P1) {
G = *P1 + 1;
}
int bar() {
int tmp = G;
foo(&G);
return G-tmp;
}
bar returns 1, not 0, and there is no pointer casting happening.
Well, G is known to escape anyway here. Even worse is this:
-- f1.c --
extern int G;
void foo(const int *P1) {
"Dave Korn" <[EMAIL PROTECTED]> writes:
| On 29 June 2006 14:44, Richard Guenther wrote:
|
| > But with C language constructs you cannot assume that an object
| > passed to a function via a const pointer is not modified. So, there
| > is no real "const" regarding to objects pointed to. Consider
On Jun 29, 2006, at 6:51 AM, Dave Korn wrote:
That's cheating! You casted away const, it's a blatant aliasing
violation,
you deserve everything you get. The compiler is specifically
*allowed* to
assume you don't pull stunts like this *in order to* make const-
optimisation
possible and
On 29 June 2006 16:15, Kaveh R. Ghazi wrote:
> > On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
> >
> > That's cheating! You casted away const, it's a blatant aliasing
> > violation, you deserve everything you get.
> >
> > No it is not, in fact it is legal C and there is no aliasing violation
> On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
>
> That's cheating! You casted away const, it's a blatant aliasing
> violation, you deserve everything you get.
>
> No it is not, in fact it is legal C and there is no aliasing violation
> as you are still accessing the memory as an "int".
"Hongbo Li" <[EMAIL PROTECTED]> writes:
> Thanks for the information. I will take a look at the manual. When you
> talk about the attribute, does that mean I need to change my source
> code?
Yes.
> Do you think the new option -fvisibility=hidden in gcc 4.0.0 would
> solve this issue?
It would c
On 29 June 2006 15:12, Andreas Schwab wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> But it's really legal to cast away const?
>
> All that matters is the effective type of the accessed object, see 6.5#7.
>
> Andreas.
Ah yes, now I remember... we had a long thread on this sometime la
Hmm, I'm starting to be convinced that ignoring #pragma visibility for
all template instantiations and specializations will be a simpler rule
for users to understand. So the #pragma affects namespace-scope
declarations, but not declarations that in any sense "belong" to another
namespace-scope
On Tue, Jun 27, 2006 at 11:18:13AM +, Joseph S. Myers wrote:
> 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 __
On 6/29/06, Dave Korn <[EMAIL PROTECTED]> wrote:
On 29 June 2006 14:55, Andrew Pinski wrote:
> On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
>
>>That's cheating! You casted away const, it's a blatant aliasing
>> violation, you deserve everything you get.
>
> No it is not, in fact it is lega
"Dave Korn" <[EMAIL PROTECTED]> writes:
> But it's really legal to cast away const?
All that matters is the effective type of the accessed object, see 6.5#7.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fing
On 29 June 2006 14:55, Andrew Pinski wrote:
> On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
>
>>That's cheating! You casted away const, it's a blatant aliasing
>> violation, you deserve everything you get.
>
> No it is not, in fact it is legal C and there is no aliasing
> violation as you
>
On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
That's cheating! You casted away const, it's a blatant aliasing
violation,
you deserve everything you get.
No it is not, in fact it is legal C and there is no aliasing
violation as you
are still accessing the memory as an "int".
-- Pin
On 29 June 2006 14:44, Richard Guenther wrote:
> But with C language constructs you cannot assume that an object
> passed to a function via a const pointer is not modified. So, there
> is no real "const" regarding to objects pointed to. Consider
>
> void foo(const int *i)
> {
> int *k = (int
On 6/29/06, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:
> Notice that the value of the parameter "b" is never changed in the
> function body. Consequently, if the current optimizers cannot figure
> that simple cases out (where "b" is not annotated const), then the
> optimizers in deficient in
Hi Ian,
Thanks for the information. I will take a look at the manual. When you
talk about the attribute, does that mean I need to change my source
code? Do you think the new option -fvisibility=hidden in gcc 4.0.0 would
solve this issue? I am using gcc 3.3.2.
Once again, thank you,
Hongbo.
--
On Thursday 29 June 2006 08:30, Beyond.Luo wrote:
> Hi, all
>When I compile FreeBSD6.0 using gcc4.1 instead of gcc3, lots of
> errors are reported.
> I knowes that gcc4.1 checks syntax more strictly, then how can I do now?
> any command-line options?
Fix the code?
--
René Rebe - Rubensstr.
On Wed, 2006-06-28 at 16:51, Shaun Jackman wrote:
> On 6/27/06, David McCullough <[EMAIL PROTECTED]> wrote:
> > AFAIK, you need to drop the -FPIC in favour of -fpic everywhere.
>
> >From the GCC manual, -fpic vs. -fPIC `makes a difference on the m68k,
> PowerPC and SPARC.' For my purposes, it mak
On Thu, 2006-06-29 at 03:47, Daniel Jacobowitz wrote:
> On Wed, Jun 28, 2006 at 03:54:29PM -0600, Shaun Jackman wrote:
> > On 6/28/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> > >On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote:
> > >> I'm not terribly familiar with the GCC sourc
37 matches
Mail list logo
