Hi Zdenek,
You removed the -floop-optimize2 option on 2006-02-10. Could you
please submit a patch for http://gcc.gnu.org/gcc-4.2/changes.html
documenting that and why this option was removed.
Thanks.
--
Martin Michlmayr
http://www.cyrius.com/
Hi Kazu,
You removed the -fdump-rtl-loop option on 2006-03-13. Could you
please submit a patch for http://gcc.gnu.org/gcc-4.2/changes.html (and
possibly 4.1 too) documenting that and why this option was removed.
Thanks.
--
Martin Michlmayr
http://www.cyrius.com/
On 16 August 2006 03:13, Gabriel Dos Reis wrote:
> [EMAIL PROTECTED] writes:
>
>> Is this version for windows or linux?
>
> this is not a binary release; it is source release.
>
> -- Gaby
And that was an old message. There's been another version, 3.4.6, released
since. Basically the same
On 16/08/06, Mahafuzur Rahaman <[EMAIL PROTECTED]> wrote:
Hi,
Welcome!
I guess will refer me to read the web site. While I am
doing that, I am not clear about my issue. It goes..
Well, it is not only the website. The wiki and the internal
documentation contains a lot of information (more th
On 16/08/06, DJ Delorie <[EMAIL PROTECTED]> wrote:
> 1) Any advise on selecting Linux distro?
Any one will do. Or Windows, MS-DOS, AIX, IRIX, Solaris, Mac OS/X, or
any other platform GCC runs on. Use whatever you're comfortable with.
Although, I guess the FSF and RedHat would encourage you
On 16/08/06, Mahafuzur Rahaman <[EMAIL PROTECTED]> wrote:
I will try to setup a web location to dump the task
items so that we can accumulate and list them.
You may use the GCC Wiki http://gcc.gnu.org/wiki/ for that. Just go
there and create a new page.
Having said my plan, I want to add that
On 8/16/06, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
As far as I know, there is no list of projects for beginners. I guess
that you should think about something you would like to learn or work.
On the other hand, setting up a list of projects for beginners and
making easier for them to cont
Bootstrap of GCC 4.1.1, c and c++ only, for an AMD k6-2
config.guess:
i586-pc-linux-gnu
gcc -v
Using built-in specs.
Target: i586-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure --with-arch=k6-2
--enable-languages=c,c++
Thread model: posix
gcc version 4.1.1
(only core, gcc and g++ files dow
On Tue, 15 Aug 2006, Asher Langton wrote:
> On 8/15/06, Tim Schmielau <[EMAIL PROTECTED]> wrote:
> > On Tue, 15 Aug 2006, Asher Langton wrote:
> > > Are you using a lot of threadprivate variables? Try setting the
> > > GOMP_STACKSIZE environment variable to a large value (in kB) and see
> > > if
DJ Delorie wrote:
> I strongly request we continue supporting the use of attribute((mode))
> to create pointers of different sizes, at least for copying and
> passing. The m32c reset vector and interrupt table really want to be
> set up like this example:
>
> typedef void (*ifunc)() __attribute__(
> Although, I guess the FSF and RedHat would encourage you to use a
> free operating system instead of any of the propietary ones
> mentioned above. Isn't it? ;-)
Although this is straying off-topic, I'll answer this one time - the
FSF would prefer that everyone use nothing but free software, but
> > typedef void (*ifunc)() __attribute__((mode(SI)));
> > ifunc __attribute__((section(".resetvec"))) reset_vector = start;
>
> Maybe it is just me, but it seems more natural to have:
> typedef void (*long ifunc)();
You can use #defines to make it pretty:
#define far __attribute__((mode(SI)))
On 16/08/06, DJ Delorie <[EMAIL PROTECTED]> wrote:
When I first ported gcc to MS-DOS (DJGPP), RMS didn't like the idea of
supporting a MS system. That changed when they started shipping DJGPP
binaries on CD-ROM; in the first month DJGPP sales exceeded 50% of
their total gross sales.
Actually
On Mon, Aug 14, 2006 at 09:35:34PM +0200, Rask Ingemann Lambertsen wrote:
> On Sun, Aug 13, 2006 at 10:16:02PM +0200, Rask Ingemann Lambertsen wrote:
>
> > Note that right after expand, we have:
> >
> > (note 91 90 0 NOTE_INSN_BASIC_BLOCK)
> >
> > ;; size = size - 1
> > (insn 93 91 96 (set (reg:
Pat Haugen <[EMAIL PROTECTED]> wrote on 08/08/2006 11:07:58 AM:
> Jan Hubicka <[EMAIL PROTECTED]> wrote on 08/08/2006 01:04:33 AM:
>
> > The code there is basically avoiding loops with many exists to be
> > predicted to not loop at all (ie if you have 10 exits, having every
exit
> > with 10% pro
Hello,
>
> Apologies for the previous incomplete reply. Here's the rest of the
> comments I had for this patch.
here is the updated patch. Daniel, did you write something regarding
the lambda framework, or should I do it?
Zdenek
Index: doc/loop.texi
==
DJ Delorie wrote:
> The problem seems to revolve around casts. How about if I turn the
> abort into a useful message about casting between pointer sizes, and
> require the user to use a builtin to convert pointers?
That's a good start -- but, at the very least, you still have to say
what happen
> I'll again point out that in your reset-vector example you don't
> actually need any pointer operations.
I'm not trying to dereference any of these nonstandard pointers. I
just need to do all the other things - assignment, copy, storage, cast
to/from integers, etc. Rarely, calling a function
> vects[A0_VEC] = __builtin_pointer32 (timer_a0_handler);
Note that the builtin would be needed for run-time conversion between
pointers of different sizes, i.e. casts. Why? Well, gcc doesn't
"just know" how to do such conversions. For example, TPF has a 31 bit
address. To convert it to 64,
DJ Delorie wrote:
>> I'll again point out that in your reset-vector example you don't
>> actually need any pointer operations.
>
> I'm not trying to dereference any of these nonstandard pointers.
Good! In that case, you don't need them to be pointers at all. :-)
I think you should just declare
DJ Delorie wrote:
> But a compile-time assigment of a symbol to a pointer should "just
> work" as long as the assembler supports it (I fixed that bug some
> months ago).
There's no reason you can't make the built-in automatically folded by
the front-end so that you still get a constant expression
> Good! In that case, you don't need them to be pointers at all. :-)
>
> I think you should just declare them as integer types.
That makes initializing function pointers messy.
Besides, they're not integers. They're pointers. I'd *like* to be
able to dereference them in some simple ways in t
> but I think you're much more likely to actually get the built-in
> approach to work correctly in C++.
But... initializing function pointers already works, without builtins.
Initializing an N bit pointer from an N bit integer now works with a
cast.
Copying an N bit pointer to another N bit poi
DJ Delorie wrote:
>> Good! In that case, you don't need them to be pointers at all. :-)
>>
>> I think you should just declare them as integer types.
>
> That makes initializing function pointers messy.
>
> Besides, they're not integers. They're pointers. I'd *like* to be
> able to dereference
We have accumulated five XPASS instances in the libstdc++ testsuite on
MacOS X...
XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test
XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc execution test
XPASS: 23_containers/vector/resize/1.cc execution test
XPA
25 matches
Mail list logo