On 3/4/08, Elazar Leibovich <[EMAIL PROTECTED]> wrote:
> I'm trying to compile the following piece of code:
> static const int ln = 10;
> static int ar[ln];
> I'm getting:
> storage size of 'ar' isn't constant
> size of variable 'ar' is too large
> Is the code legal? Can you provide me with
Thank you Ian. I did the modification you mentioned...now I am running
into more problems.
Now it is failing somewhere in libiberty.. here is the exact message (I
just simply typed "make all install") (I get same messae when I just do
"make")
Configuring in fixincludes
configure: loading cache ./
I'm trying to compile the following piece of code:
static const int ln = 10;
static int ar[ln];
I'm getting:
storage size of 'ar' isn't constant
size of variable 'ar' is too large
Is the code legal? Can you provide me with references to its legality
or a discussion about it? it seems to be compila
"Balaji V. Iyer" <[EMAIL PROTECTED]> writes:
> I am trying to do some development on the C Compiler in Cygwin and I
> am doing the following to build it:
gcc@gcc.gnu.org is the wrong mailing list. Please send any further
e-mail to [EMAIL PROTECTED] Thanks.
> $ ../gcc-4.0.2/gcc/configure
R
Hello Everyone,
I am trying to do some development on the C Compiler in Cygwin and I
am doing the following to build it:
$ ../gcc-4.0.2/gcc/configure
--prefix=/home/Balaji/Software_Tools/install --enable-languages="c"
The problem i am getting is this:
$ make all install
TARGET_CPU_DEFAULT
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> This is OK for mainline. I will defer to an RM for 4.3, though my
> recommendation is that it should go into 4.3 if possible.
Sorry, the thread broke, and I didn't see that this had already been
approved.
Ian
"H.J. Lu" <[EMAIL PROTECTED]> writes:
> Here is the patch for both gcc 4.3 and 4.4. OK for 4.3/4.4? Tested on
> Linux/ia32
> and Linux/ia64 with gcc 4.3/4.4.
> gcc/
>
> 2008-03-03 H.J. Lu <[EMAIL PROTECTED]>
>
> PR target/35453
> * config/i386/smmintrin.h (SIDD_XXX): Renamed to .
"Doug Gregor" <[EMAIL PROTECTED]> writes:
> I see that it is time to submit applications to be a mentor
> organization for the Google Summer of Code. I've updated the GSoC wiki
> page at:
>
> http://gcc.gnu.org/wiki/SummerOfCode
>
> with a class of projects I'm interested in; others should do
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> Here is a patch that give us caret diagnostics in C/C++. There a lot
> of things that can be improved but because I wanted to get some
> feedback with my current approach.
>
> Basically, I store a pointer linebuf in the line_map structure to a
>
Segher Boessenkool writes:
>... People are relying on this undocumented GCC behaviour already,
>and when things break, chaos ensues.
GCC has introduced many changes over the years that have broken many
programs that have relied on undocumented or unspecified behaviour.
You won't find much sympathy
> AFAIK the only reason we don't break this rule is that doing so would
> be grossly inefficient; there's nothing to stop any gcc back-end with
> (say) seriously slow DImode writes from using two SImode writes instead.
I'm fairly sure ARM already breaks this "rule".
Currently it probably only eff
> "Segher" == Segher Boessenkool <[EMAIL PROTECTED]> writes:
>> As I said before, I think any words of this form SHOULD NOT be
>> added. All it does is add words to the documentation that provide
>> NO guarantee of anything -- but in a way that will confuse those
>> who don't read it care
Segher Boessenkool wrote:
As I said before, I think any words of this form SHOULD NOT be added.
All it does is add words to the documentation that provide NO
guarantee of anything -- but in a way that will confuse those who
don't read it carefully enough into thinking that they DID get some
sort
As I said before, I think any words of this form SHOULD NOT be added.
All it does is add words to the documentation that provide NO
guarantee of anything -- but in a way that will confuse those who
don't read it carefully enough into thinking that they DID get some
sort of guarantee.
The idea is
On 3/4/08 4:06 PM, Jan Hubicka wrote:
The names are equivalent to UD pointers: Either you can have version
names or just coinsider the destination of UD pointer to be the
destination. Or am I still missing a point?
Nope, that's exactly right. Versioned names are useful for some things
(mos
> > I think that at this point, i have been convinced to:
> >
> > 1) use fud's rather than birthpoints because these do keep a slot for
> > the value along each in edge.
> > 2) keep the info on the side (see rsandifors diverging thread).
> >
> > I am not there on keeping extra names on the side.
> I think that at this point, i have been convinced to:
>
> 1) use fud's rather than birthpoints because these do keep a slot for
> the value along each in edge.
> 2) keep the info on the side (see rsandifors diverging thread).
>
> I am not there on keeping extra names on the side. The advantag
On Tue, Mar 4, 2008 at 9:46 PM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
> I don't see why hard registers are special as far as FUD chains go.
> We have DU chains for hard regs, so why not FUDs too?
We have them, but does anyone use them? Does anyone actually even
compute them? (Apparently
> "Segher" == Segher Boessenkool <[EMAIL PROTECTED]> writes:
Segher> Good point. Suggestions for better wording? How does
Segher> "any access to a naturally aligned scalar object in memory
Segher> that is not a bit-field and fits in a general purpose integer
Segher> machine register, wi
* Basile STARYNKEVITCH wrote on Thu, Feb 28, 2008 at 06:56:35PM CET:
> Ralf Wildenhues wrote:
>> * Basile STARYNKEVITCH wrote on Thu, Feb 28, 2008 at 05:39:47PM CET:
run-basilys.d: run-basilys.h \
$(CONFIG_H) $(SYSTEM_H) $(TIMEVAR_H) $(TM_H) $(TREE_H) $(GGC_H) \
tree-pass.h
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> On Tue, Mar 4, 2008 at 8:47 PM, Richard Sandiford
> <[EMAIL PROTECTED]> wrote:
>> "Steven Bosscher" <[EMAIL PROTECTED]> writes:
>> Going back to something discussed upthread: would you expect to use this
>> for hard regs as well as pseudos? No-op m
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction
On Mon, Mar 03, 2008 at 08:11:30AM -0500, Hans-Peter Nilsson wrote:
> On Sun, 2 Mar 2008, Greg Schafer wrote:
> > Hi Carlos and Mark,
> >
> > Your "Relocated compiler should not look in $prefix" patch here:
> >
> > http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
> >
> > appears to have caused a reg
Jan Hubicka wrote:
> Hi,
>
>> 1) In ssa, the operands of the phis and the renaming contain
>> information. The operands are paired with the cfg edges that the
>> values come in on. In fud/birthpoints there is no such pairing or
>> renaming. For some problems, like conditional constant, thi
Hi,
>
> 1) In ssa, the operands of the phis and the renaming contain
> information. The operands are paired with the cfg edges that the
> values come in on. In fud/birthpoints there is no such pairing or
> renaming. For some problems, like conditional constant, this pairing
> and renaming is
On Tue, Mar 4, 2008 at 8:47 PM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
> "Steven Bosscher" <[EMAIL PROTECTED]> writes:
> Going back to something discussed upthread: would you expect to use this
> for hard regs as well as pseudos? No-op moves aren't necessarily supported
> for all hard reg
On 3/4/08 2:38 PM, Kenneth Zadeck wrote:
Steven Bosscher wrote:
On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
Both PHIs and birthpoints are merely factoring devices that let you cut
down the number of UD links. They don't need to be part of the IL, much
like no
Richard Sandiford wrote:
> "Steven Bosscher" <[EMAIL PROTECTED]> writes:
>
>> For the location of the extra instructions, I would *not* keep them on
>> the side. If you have something special going on, my motto is: "Make
>> it explicit".
>>
>
> Going back to something discussed upthread: w
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> For the location of the extra instructions, I would *not* keep them on
> the side. If you have something special going on, my motto is: "Make
> it explicit".
Going back to something discussed upthread: would you expect to use this
for hard regs as w
Steven Bosscher wrote:
> On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
>> Both PHIs and birthpoints are merely factoring devices that let you cut
>> down the number of UD links. They don't need to be part of the IL, much
>> like none of the DF objects are part of
J.C. Pizarro wrote:
> p7zip-4.57
> [...]
> 1. 1m50s compile, 1630164 file, 1618639 text, 6120 data, 27168 bss, 5m50s run.
> 2. 1m53s compile, 1665952 file, 1649829 text, 4668 data, 29160 bss, 6m04s run.
> 3. 2m08s compile, 1629088 file, 1613313 text, 4672 data, 29
On 3/4/08 2:12 PM, Steven Bosscher wrote:
That code is IMHO just awfully ugly. And slow too, last I checked.
Yeah, there's quite a bit of bookkeeping needed to do incremental SSA
updates.
should not want that on RTL. I don't think we should allow
transformations on RTL that are too hard t
On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Both PHIs and birthpoints are merely factoring devices that let you cut
> down the number of UD links. They don't need to be part of the IL, much
> like none of the DF objects are part of the RTL IL.
Maybe they don't ne
On Sat, Mar 1, 2008 at 11:13 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > Diego,
> >
> > I am leaning to just adding noop moves at the birthpoints (dominance
> > frontiers) as real noop move insns in the streams in the passes that use
> > ud or du chains. The back end is tolerant of noop mo
On 3/4/08 1:53 PM, Steven Bosscher wrote:
So, from an implementation, would we make PHI-like UD-chains to nop
insns that represent the birth points, or would we actually add PHI
functions and let the "normal" UD-chains point to the PHI function
arguments?
Why put them in the IL stream at all?
On Sat, Mar 1, 2008 at 2:46 PM, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > By the way, I still don't understand how birth points would work. Can
> > someone give an example of what the insn stream would look like with
> > birth points, and what the DU/UD chains would look like?
>
> With a
Richard Guenther wrote:
On Tue, Mar 4, 2008 at 7:31 PM, David Daney <[EMAIL PROTECTED]> wrote:
Perhaps anything declared volatile should have these semantics.
Although mentioning 'volatile' on the lkml is probably not a good idea.
Certainly not. volatile has nothing to do with atomic acce
On Tue, Mar 4, 2008 at 7:31 PM, David Daney <[EMAIL PROTECTED]> wrote:
> Jakub Jelinek wrote:
> > On Tue, Mar 04, 2008 at 04:37:29PM +, Andrew Haley wrote:
> >>> Typically those would be found in asm statements.
> >>> I suspect it would be valuable to have standardized primitives for
> >>>
Jakub Jelinek wrote:
On Tue, Mar 04, 2008 at 04:37:29PM +, Andrew Haley wrote:
Typically those would be found in asm statements.
I suspect it would be valuable to have standardized primitives for
atomic actions (semaphores, spinlocks, test-and-set primitives,
circular buffers, pick one).
We
Hi,
Here is the patch for both gcc 4.3 and 4.4. OK for 4.3/4.4? Tested on Linux/ia32
and Linux/ia64 with gcc 4.3/4.4.
Thanks.
H.J.
On Tue, Mar 4, 2008 at 1:19 AM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Mar 2008, H.J. Lu wrote:
>
> > Hi,
> >
> > I'd like to fix
> >
> > http
On Tue, Mar 04, 2008 at 09:02:34AM +, Martin Guy wrote:
> Is there a clause in regressions for "takes longer to compile and
> produces worse code"?
Worse code is a regression, so is slower compile time. Both are
judgement calls; some of them are not going to be changed, but safe
patches chang
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>> We don't have atomic read or atomic write builtins (ok, you could
>> abuse __sync_fetch_and_add (&x, 0) for atomic read and a loop with
>> __sync_compare_and_swap_val for atomic store, but that's a
>> horrible overkill. Being able
On Tue, 4 Mar 2008, Andrew Pinski wrote:
> On 3/4/08, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > I suggest to make sure that bit position and size are constants, the
> > object referenced is of integral type (BIT_FIELD_REF should not be
> > used as a way to circumvent aliasing) and the res
Jakub Jelinek wrote:
On Tue, Mar 04, 2008 at 04:37:29PM +, Andrew Haley wrote:
Typically those would be found in asm statements.
I suspect it would be valuable to have standardized primitives for
atomic actions (semaphores, spinlocks, test-and-set primitives,
circular buffers, pick one).
We
On 3/4/08, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I suggest to make sure that bit position and size are constants, the
> object referenced is of integral type (BIT_FIELD_REF should not be
> used as a way to circumvent aliasing) and the result type is of the
> same type as the operand zer
On Tue, Mar 04, 2008 at 04:37:29PM +, Andrew Haley wrote:
> >Typically those would be found in asm statements.
>
> >I suspect it would be valuable to have standardized primitives for
> >atomic actions (semaphores, spinlocks, test-and-set primitives,
> >circular buffers, pick one).
>
> We alre
On Tue, 4 Mar 2008, Jakub Jelinek wrote:
> On Tue, Mar 04, 2008 at 11:15:00AM -0500, Diego Novillo wrote:
> > >fold currently optimizes a.b.c == 0 to BIT_FIELD_REF & 1
> > >for bit field field-decls c. IMHO this is bad because it pessimizes
> > >TBAA (needs to use a's alias set, not the underlyi
On Tue, Mar 04, 2008 at 11:15:00AM -0500, Diego Novillo wrote:
> >fold currently optimizes a.b.c == 0 to BIT_FIELD_REF & 1
> >for bit field field-decls c. IMHO this is bad because it pessimizes
> >TBAA (needs to use a's alias set, not the underlying integral type
> >alias set) and it "breaks" typ
Paul Koning wrote:
I'm really wondering why this is being considered.
A documented property of the form "GCC will use a single instruction
to do X when possible" means exactly nothing. In particular, to call
such a statement a "guarantee" is seriously misleading.
I agree.
If Linux needs the
I'm really wondering why this is being considered.
A documented property of the form "GCC will use a single instruction
to do X when possible" means exactly nothing. In particular, to call
such a statement a "guarantee" is seriously misleading.
If Linux needs the single-instruction property for
On 3/4/08 10:55 AM, Richard Guenther wrote:
I suggest to make sure that bit position and size are constants, the
object referenced is of integral type (BIT_FIELD_REF should not be
used as a way to circumvent aliasing) and the result type is of the
same type as the operand zero type (and not a bi
> Well if they do require more than one instruction, the rule has
> no effect ("whenever possible"). If they can be done in one
> instruction (as on the x86), then why not require this, why
> make a special case?
We don't even guarantee consistent behavior for volatile bitfields, so I
really dou
BIT_FIELD_REF is currently only generated by the middle-end (fold, SRA
and parts of the vectorizer). At the moment the bit position and size
of the extract can be non-constant and the type of the result is
unspecified.
I suggest to make sure that bit position and size are constants, the
object r
On Mon, Mar 03, 2008 at 11:08:24PM -0500, Robert Dewar wrote:
> Segher Boessenkool wrote:
> >>>The Linux kernel, and probably some user-space applications and
> >>>libraries
> >>>as well, depend on GCC guaranteeing (a variant of) the following:
> >>> "any access to a naturally aligned scalar obj
On Mon, 3 Mar 2008, [EMAIL PROTECTED] wrote:
I have a stand-alone, non-Web-based app. that I'd like to
distribute as a .exe with some database files, to a layman
audience, and I'd like to avoid issues of JRE distribution and
compatibility, etc. So I'm hoping someone, somewhere, has
written a rep
But the remaining question is: can we
support type introperability from Fortran array to C vector?
I think this is more a middle-end issue that a Fortran issue, so I'm
following there: can the middle-end VIEW_CONVERT_EXPR between and
ARRAY_REF of, say, INTEGER_TYPE (which is what the Fortran
Raghukrishna Hegde wrote:
Hello all,
I am encountering a strange problem. I have a code
Snippet that contains a while loop.
The snippet is as follows:
While( (expr1) && (expr2) );
Initially the value of both expr1 and expr2 are
Set to 1.
Next, only the value of expr1 is set to 0
Hello all,
I am encountering a strange problem. I have a code
Snippet that contains a while loop.
The snippet is as follows:
While( (expr1) && (expr2) );
Initially the value of both expr1 and expr2 are
Set to 1.
Next, only the value of expr1 is set to 0 within a
SIGINT handler.
I
Segher Boessenkool wrote:
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
"any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single m
Hi,
Sure hope I've come to the right place...
I need to somehow persuade GCC (on x86) to always treat vtables as if
they were dllimport'ed. For linking to work on my target platform (a
custom X86 OS) it's important that constructors reference vtables
indirectly (i.e. through pointers in idata).
On Mon, 3 Mar 2008, H.J. Lu wrote:
> Hi,
>
> I'd like to fix
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35453
>
> for gcc 4.3. Defines SIDD_XXX in SSE4 header file is a bad idea. SSE 4
> header file
> in icc will also be fixed.
Works for me.
Richard.
2008/2/29, J.C. Pizarro <[EMAIL PROTECTED]>:
> Here are the results of benchmarks of 3 compressors: 7z, bzip2 and gzip, and
> GCCs 3.4.6, 4.1.3-20080225, 4.2.4-20080227, 4.3.0-20080228 & 4.4.0-20080222.
Thanks, that's very interesting. I had noticed 4.2 producing 10%
larger and 10% slower code fo
Somehow this got stuck in the spam filter.
- Forwarded message from [EMAIL PROTECTED] -
Date: Sat, 01 Mar 2008 09:21:21 -0500
From: Joern Rennecke <[EMAIL PROTECTED]>
Reply-To: Joern Rennecke <[EMAIL PROTECTED]>
Subject: Re: [PATCH][4.3] Deprecate -ftrapv
To: gcc@gcc.gnu.or
63 matches
Mail list logo
