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
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
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
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
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 :-)
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
Looks OK for xtensa-elf:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00356.html
--Bob
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
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
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:
|
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
>
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
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 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
> 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 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
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 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
> 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 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
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
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
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
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
Paolo Bonzini's patch appears to work.
What the best solution is long term, is not really my province.
Regards
Salvatore
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
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
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
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
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.
//-
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() =
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
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
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
> 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
35 matches
Mail list logo
