Hi everyone,
I got a "Bootstrap comparison failure!" error when building gcc 4.3.3:
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
Bootstrap comparison failure!
./tree-cfg.o differs
./double-int.o differs
./gimple-low.o differs
./tree-into-ssa.o
On Tue, 19 May 2009, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> >> - The tree alias oracle got similar functionality, refs_anti_dependent
> >>and refs_output_dependent and the tree level data dependence
> >>analysis code makes use of these.
>
> Do we still use TBAA for the origi
On Wed, May 20, 2009 at 12:47 AM, Gary Funck wrote:
> On 05/19/09 12:10:43, Andrew Pinski wrote:
>> Gary wrote:
>> > Is the __thread feature now more universally/portably
>> > supported?
>>
>> Yes, see emutls.c and the VAR_DECL case in expand_expr_addr_expr_1 and
>> expand_expr_real_1 in expr.c.
>
On Tue, 19 May 2009, Gary Funck wrote:
> That aside, I wonder if it is an error to drop the qualifiers
> as shown above? In the case of UPC, for example, dropping qualifiers
Please read the code (and comment) immediately above that you quoted,
which saves the qualifiers combined with those spec
hi,
While working on some Linux kernel code, I've found that functions that
are declared as 'static inline' are having their arguments evaluated
well before they are used. For example I have a function:
static inline void trace(arg1, arg2)
{
if (unlikely(enabled)) {
chenyang writes:
> I got a "Bootstrap comparison failure!" error when building gcc 4.3.3:
These kinds of issues are always difficult to debug. There have been a
couple of patches to stabilize different sorts which I don't think are
in 4.3.3. That could conceivably cause differences if address
Jason Baron writes:
> While working on some Linux kernel code, I've found that functions that
> are declared as 'static inline' are having their arguments evaluated
> well before they are used. For example I have a function:
>
> static inline void trace(arg1, arg2)
> {
> if (unlikely(enable
Hi folks.
Before I merge the diagnostics branch I'd like to enable it on the
testsuite to get us all in the habit of at least being aware of columns.
Joseph Myers suggested enabling it in the compiler instead of the
testsuite. Are there any big objections to this?
Aldy
2009/5/20 Aldy Hernandez :
> Hi folks.
>
> Before I merge the diagnostics branch I'd like to enable it on the
> testsuite to get us all in the habit of at least being aware of columns.
>
> Joseph Myers suggested enabling it in the compiler instead of the
> testsuite. Are there any big objections t
Aldy Hernandez writes:
> Before I merge the diagnostics branch I'd like to enable it on the
> testsuite to get us all in the habit of at least being aware of columns.
>
> Joseph Myers suggested enabling it in the compiler instead of the
> testsuite. Are there any big objections to this?
I agree
2009/5/20 Ian Lance Taylor :
> When we have good caret diagnostics it would also be nice to enable them
> by default. However, that is a much bigger change. Does anybody have
> an opinion on that?
Why don't have that discussion when (and if) caret diagnostics are
available? I don't think anyone
On Wed, 20 May 2009, Ian Lance Taylor wrote:
> When we have good caret diagnostics it would also be nice to enable them
> by default. However, that is a much bigger change. Does anybody have
> an opinion on that?
Yes, that tripling the size of output in a cascade of diagnostics is a bad
idea.
> "Ian" == Ian Lance Taylor writes:
Ian> If you haven't already done so, please check that the emacs next-error
Ian> function is not affected by this.
This definitely works.
Tom
On Wed, 20 May 2009, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> >> void f(float *f, int *n) {
> >> for (int i = 0; i < *n; ++i) {
> >> f[i] *= 2;
> >> }
> >> }
>
> > The difference is if you want to sink a load from *n beyond the
> > store to f[i] - in which case you as
On Wed, May 20, 2009 at 04:39:00PM +0200, Manuel L?pez-Ib??ez wrote:
> 2009/5/20 Aldy Hernandez :
> > Hi folks.
> >
> > Before I merge the diagnostics branch I'd like to enable it on the
> > testsuite to get us all in the habit of at least being aware of columns.
> >
> > Joseph Myers suggested enab
Richard Guenther wrote:
>> void f(float *f, int *n) {
>> for (int i = 0; i < *n; ++i) {
>> f[i] *= 2;
>> }
>> }
> The difference is if you want to sink a load from *n beyond the
> store to f[i] - in which case you ask if there is an anti-dependence
> which we cannot exclude in t
On 05/20/09 09:45:11, Joseph S. Myers wrote:
> On Tue, 19 May 2009, Gary Funck wrote:
>
> > That aside, I wonder if it is an error to drop the qualifiers
> > as shown above? In the case of UPC, for example, dropping qualifiers
>
> Please read the code (and comment) immediately above that you quo
alphapca56-unknown-linux-gnu
Using built-in specs.
Target: alphapca56-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/GCC4
AR_FOR_TARGET=ar AS_FOR_TARGET=as 'CC_FOR_TARGET=
/root/gcc-4.4.0/host-alphapca56-unknown-linux-gnu/gcc/xgcc
-B/root/gcc-4.4.0/host-alphapca56-unknown-linu
On 05/20/09 10:40:02, Richard Guenther wrote:
> Gary wrote:
> > Above, __emutls_get_address() is called twice, with
> > the same argument. I was surprised to see that the optimizer
> > (GCC 4.3.2) didn't notice this and use CSE to avoid the second
> > redundant call, because emultls_get_address is
We seem to have dropped this discussion. I now have *two* customers
asking for this functionality. Can we pick it up again? We need to
decide:
1. If the functionality will be allowed in gcc at all
2. What info the target needs to be provided to make the choices it wants
3. What, if any, comm
DJ Delorie writes:
> We seem to have dropped this discussion. I now have *two* customers
> asking for this functionality. Can we pick it up again? We need to
> decide:
>
> 1. If the functionality will be allowed in gcc at all
>
> 2. What info the target needs to be provided to make the choices
Ian Lance Taylor wrote:
>> 1. If the functionality will be allowed in gcc at all
>>
>> 2. What info the target needs to be provided to make the choices it wants
>>
>> 3. What, if any, common code can be shared between the CPUs
>
> Since the ARM ABI apparently specifies something about volatile
>
g95 sets DECL_COMMON on these variable decls (only for Darwin
targets). This seems like a hack to me (see below). The problem is
darwin-specific, not related to the front-end. On darwin:
$ cat a.c int x[999] = { 0 }; $ gcc -c a.c && ls -lh a.o -rw-r--
r-- 1 fx wheel 38M May 12 13:43 a.o $
> I think the ARM specification is pretty sensible, and would make a
> good cross-platform approach.
Could you distill it for us? If it's acceptable to my two customers,
it would be a good starting point to define an API for the targets.
I have a question about the use of sed by fixincl and mkheaders
and a change that was made between 4.3.* and 4.4.0.
It involves this patch:
2008-09-06 Bruce Korb
* fixincl.tpl (sed): make the program executable configurable.
Some platforms have some rather oddball defaults.
On Wed, May 20, 2009 at 2:47 PM, Steve Ellcey wrote:
> I have a question about the use of sed by fixincl and mkheaders
> and a change that was made between 4.3.* and 4.4.0.
> After this patch, the sed used when building GCC is saved in a config
> file and that path to sed is used when you run mkh
Gary Funck writes:
> Do you/others happen to know who is the maintainer of the
> TLS emulation? I tried a simple test case that works
> with the native TLS support, but it SEGV's when using
> TLS emulation. Perhaps a cockpit error on my part, but
> I'd like to see if I can use the TLS emulation
On 05/20/09 17:13:23, Ian Lance Taylor wrote:
> Gary Funck writes:
>
> > Do you/others happen to know who is the maintainer of the
> > TLS emulation?
>
> [...] If you have found a bug, the fastest
> way to address is probably to file a bug report.
Doing a bit of research, it seems that the bug
Under which conditions GCC generates nops?
I noticed that with 4.4.0, gen_nop() is required, thing that wasn't with 4.3.3.
Can I just define an empty insn for nop, of GCC requires a one-byte insn for its
own alignment purposes?
- Jamie
Richard Guenther wrote:
> int i;
> float f;
> void foo()
> {
> int *p = (int *)malloc(sizeof(int));
> *p = 1;
> i = *p;
> float *q = (float *)p;
> *q = 2.0;
> f = *q;
> }
Yes, I think that's a valid program too. I'm OK with giving up this
optimization; clearly we need to be correct f
Hi,
I'm running my C program on a Solaris machine with the following gcc version
installed.
>>gcc version 3.4.6
>>Thread model 3.4.6
>>/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.6/spec
Issue:
The same code seems to compile and execute fine on
mingw running on Windows with gcc version 3.4
Jamie Prescott writes:
> Under which conditions GCC generates nops?
It depends entirely on the target. For many targets, gcc will never
generate a nop instruction, except as a byproduct of alignment.
> I noticed that with 4.4.0, gen_nop() is required, thing that wasn't with
> 4.3.3.
> Can I
santosh k writes:
> I'm running my C program on a Solaris machine with the following gcc version
> installed.
>
>>>gcc version 3.4.6
>>>Thread model 3.4.6
>>>/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.6/spec
>
> Issue:
> The same code seems to compile and execute fine on
> mingw running on
Consider this C/C++ program:
extern void **f1();
void f2(const char *p) { *(const void **)f1() = p; }
If I compile this program with g++ -Wcast-qual, I get this:
foo2.cc:2: warning: cast from type ‘void**’ to type ‘const void**’ casts away
qualifiers
If I compile this program with gcc -Wcast-q
DJ Delorie wrote:
>> I think the ARM specification is pretty sensible, and would make a
>> good cross-platform approach.
>
> Could you distill it for us?
The relevant bits are from AAPCS \S 7.1.7.5, and quoted below.
The term "container" here means the declared type of the bit-field.
(There's
35 matches
Mail list logo
