> There is a wikibook that describes the internals of GCC and GEM, an
> extensibility framework.
Your internals documentation looks pretty good, so I have made a link
to it from gcc.gnu.org/readings.html. Thanks,
Ben
Hello,
I downloaded the latest snapshot, and it looks like there's a packaging
problem. Downloaded and unpacked gcc-core, created an obj build tree,
run bootstrap and this is what happens:
make[3]: Entering directory
`/home/sfilippo/COMPILERS/GFORTRAN/TEMP/obj/gcc'
gcc -c -g -DIN_GCC -W -Wall
So I'm basically asking for people who want to play around with some
cool new technology to help make source code better. If this interests
you, please feel free to reach out to me directly. And of course, if
there are other packages you care about that aren't currently on the
list, I want
I reproduced this with just gcc-core, I normally also build g++ and
gfortran as well. The problem goes away if I unpack the sources for
objc, which I am not really interested in.
Any takers? How/against what do I report this?
The problem is that now configure is processing config-lang.in fil
Hello,
I cannot compile a code that seems correct to me. I have tried with
gcc 3.3 and gcc 4.0.1 on MacOS X-ppc, and gcc 4.0.1 on Linux i686.
Here is the code, that uses pure virtual functions and simple
inheritance.
//-
struct a
{
virtual int foo() =
On Mar 6, 2006, at 8:12 AM, Pierre Chatelier wrote:
Hello,
I cannot compile a code that seems correct to me. I have tried with
gcc 3.3 and gcc 4.0.1 on MacOS X-ppc, and gcc 4.0.1 on Linux i686.
Here is the code, that uses pure virtual functions and simple
inheritance.
//-
Thanks for the quick answer.
This is ok to fix the source, but I do not understand why it is
normal behaviour that the foo() in b hides the one from a. They have
different prototypes.
Regards,
Pierre Chatelier
This is not a bug in gcc. foo in b hides the one from a.
You can "fix" the so
There is a wikibook that describes the internals of GCC and GEM, an
extensibility framework.
Your internals documentation looks pretty good, so I have made a link
to it from gcc.gnu.org/readings.html. Thanks,
It describes AST part of GCC source code. We would like to ask developers to
work o
On Mon, 6 Mar 2006, Paolo Bonzini wrote:
> It is a bit weird that objcp is included in the gcc-core download. It could
> be included in the gcc-objc download (or in a separate objcp download). But
It should go in an objcp download. sourcebuild.texi includes updating the
release script as one
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> GCC 4.0.3 RC1 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.3-20060303
>
> Please download and test!
There are failures on sh4-*-linux-gnu during libjava build and 65
unusual regressions for C++ testsuite. I don't file PRs for them
be
Paolo Bonzini's patch appears to work.
What the best solution is long term, is not really my province.
Regards
Salvatore
Hello,
Le lundi 06 mars 2006 à 13:39 +, Colm O' Flaherty a écrit :
> Francois,
>
> I'm really interested in getting a gcc port (gcc backend) for the Microchip
> PIC16F family (14 bit instruction, 8 bit word) up and running. I've seen
> various mails to the gcc list that refer to this, the
Hi,
I was trying to feed the "reload" phase with a different hardware
register assignment to pseudo registers (using reg_renumber array)
than the ones produced by local-alloc or global-alloc. However, I get
problems with the following instruction in post-reload.c:391 in
"reload_cse_simplify_operan
The architecture for which I generate code is Intel x86.
On 3/6/06, Rajkishore Barik <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was trying to feed the "reload" phase with a different hardware
> register assignment to pseudo registers (using reg_renumber array)
> than the ones produced by local-alloc o
I noticed that some testsuite regressions were not getting fixed.
There are 3 failures in the gcc.dg/tree-ssa (PR 26344).
And 5 in g++.dg (PR 26115 and PR 26114).
All of these testsuite regressions have been there for almost
three weeks (the C++ have been there over a month now). The
patch which c
On Mon, 2006-03-06 at 12:34 -0500, Andrew Pinski wrote:
> I noticed that some testsuite regressions were not getting fixed.
> There are 3 failures in the gcc.dg/tree-ssa (PR 26344).
> And 5 in g++.dg (PR 26115 and PR 26114).
> All of these testsuite regressions have been there for almost
> three we
> You're really not helping here. I'm dealing with things as
> quickly as I can and prioritizing the incorrect code issues
> over minor performance issues.
If you noticed I pointed out other testsuite regressions than
just yours. If I had posted the patch (not being a global write
maintainer) an
On Sunday 05 March 2006 17:47, Mark Mitchell wrote:
> GCC 4.0.3 RC1 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.3-20060303
OK on SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00347.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00346.html
http://gcc.gnu
On Mon, 2006-03-06 at 00:31 +0100, Eric Botcazou wrote:
>
>
> cxa4025 and cxa4033 are very likely yours, originating in a miscompilation of
> the runtime (a-stwifi.adb) at -O2. They succeed if the aforementioned unit
> is compiled at -O2 -fno-tree-vrp. You can pass -a to gnatmake to cause the
On Mon, 2006-03-06 at 00:31 +0100, Eric Botcazou wrote:
> cxa4025 and cxa4033 are very likely yours, originating in a miscompilation of
> the runtime (a-stwifi.adb) at -O2. They succeed if the aforementioned unit
> is compiled at -O2 -fno-tree-vrp. You ca
> Like you, I'm still studying the internals of gcc, but I'm close to
> being confident enough to start making some changes.
Nice !
Le lundi 06 mars 2006 à 17:17 +, Colm O' Flaherty a écrit :
> Francois,
>
> There are only 35 instructions in the 14 bit instruction set, and given
> that, in
On Mar 6, 2006, at 1:39 PM, Jeffrey A Law wrote:
I think it's time to hand this one to the Ada guys :-0
I bet this is actually a fold issue rather than an Ada front-end issue.
-- Pinski
On Mon, Mar 06, 2006 at 12:34:42PM -0500, Andrew Pinski wrote:
> What is the policy for testsuite regressions that have been
> there for over 48 hours and effect all targets and have not
> been fixed yet?
In this case, wouldn't removing the patch just move breakage from C++
to Ada? Or do I misund
On Mar 6, 2006, at 2:21 PM, Joe Buck wrote:
On Mon, Mar 06, 2006 at 12:34:42PM -0500, Andrew Pinski wrote:
What is the policy for testsuite regressions that have been
there for over 48 hours and effect all targets and have not
been fixed yet?
In this case, wouldn't removing the patch just mo
Kaz Kojima wrote:
> It seems that the recent changes on 4.0 branch reveal these target
> problems which are latent on 4.0. There are patches for these PRs,
> though the patch for 23706 touches the middle end file. I'm unsure
> whether to backport it to 4.0.3 is appropriate or not at this last
>
I have run into a couple of linking problems trying to test/use -fopenmp
and libgomp and I was hoping for some help on where to look and how to
fix these problems.
Test failures:
I get a lot of test failures with:
| FAIL: libgomp.c/appendix-a/a.15.1.c (test for excess errors)
| Excess errors:
|
On Mon, 2006-03-06 at 14:26 -0500, Andrew Pinski wrote:
> On Mar 6, 2006, at 2:21 PM, Joe Buck wrote:
>
> > On Mon, Mar 06, 2006 at 12:34:42PM -0500, Andrew Pinski wrote:
> >> What is the policy for testsuite regressions that have been
> >> there for over 48 hours and effect all targets and have n
On Mar 6, 2006, at 2:36 PM, Jeffrey A Law wrote:
Reverting the patch is just a (*&@#$ waste of time at this point.
Really, it's a waste of time/energy, much like this conversation.
This is a policy conversation which needs to be done as right now
from the looks of it, the testsuite is not som
Looks OK for xtensa-elf:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00356.html
--Bob
On Mar 6, 2006, at 5:21 AM, Pierre Chatelier wrote:
This is ok to fix the source, but I do not understand why it is
normal behaviour that the foo() in b hides the one from a. They
have different prototypes.
That's just how C++ is designed/defined, any book on C++ should be
able to explain
That's just how C++ is designed/defined, any book on C++ should be
able to explain this in more detail.
Since it was not a bug, I have posted related questions on the gcc-
help list, and I have had valuable answers.
http://gcc.gnu.org/ml/gcc-help/2006-03/msg00026.html
Now I have understood :-)
The pre-Berlin WG14 mailing, and the updated C99 DR logs, are now
available from the WG14 website. There's an updated decimal float draft
TR in there, among other items.
http://www.open-std.org/JTC1/SC22/WG14/www/docs/pre-berlin.htm
http://www.open-std.org/JTC1/SC22/WG14/www/docs/pre-berlin.tar
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> If these patches show an improvement on SH4, please go ahead and check
> them in. Please inform me of the status ASAP.
I've checked it in as 111792. Sorry for the delay.
Regards,
kaz
Here's the relevant bits from the .original dump
if (side - 1 <= 1)
Of particular interest is the (side - 1 <= 1) conditional which is
implementing this hunk of code from the Trim function:
if Side = Right or else Side = Both then
I think it's time to hand this one to th
When trying to submit further information for gcc bug 15020 I get
Not allowed
You tried to change the Assignee field from [EMAIL PROTECTED] to
__UNKNOWN__, but only the assignee of the bug, or a sufficiently empowered
user may change that field.
I can not figure which field of the form is c
35 matches
Mail list logo
