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
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
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
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
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
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
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
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
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 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
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.
> 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.
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 $
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
>
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
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
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 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
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
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 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
> "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, 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.
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
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 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
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
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
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
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)) {
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
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, 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
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
35 matches
Mail list logo
