-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Tromey wrote:
>
> In particular we would like to import a copy of the ecj sources into
> the GCC source tree, so that we can continue to deliver a complete
> compiler system in a single download.
>
> So, could the SC please discuss the ecj plan a
This is something I should have announced several weeks ago; to make up
for this delay, I went ahead and took care of the patch to the MAINTAINERS
file right away.
I guess it's not a real surprise for those on this list, but let's thank
Richard for contributing and agreeing to maintain libgomp!
Roberto Bagnara <[EMAIL PROTECTED]> writes:
> Hi there,
>
> I have read the files darwin-ldouble* in GCC 4.1.0.
> What I would like do know is whether I can expect
> long doubles on Darwin to comply with ISO C99 7.6
> (Floating-point environment).
They can be made compliant with that section, b
Joe Buck wrote:
Let's be careful to distinguish code optimizations, and optimizations that
avoid the generation of unnecessary debug information. It used to be that
every once in a while, in response to a bug report, a GCC developer would
make a change that doubles or triples the size of a debu
On Mon, Apr 03, 2006 at 08:09:05PM -0400, Robert Dewar wrote:
> In fact I agree that -O0 should not do any optimizations visible to
> the user of the debugger at the source level (I wish it would do a
> bit better job of generating reasonable code, subject to this criterion!)
Let's be careful to d
Nick Roberts wrote:
Its
interesting that a quote on Bugzilla says that debugging is twice as hard as
writing code.
This need not be the case, if you adopt sufficient discipline to write
correct code the first time, debugging can be a minor part of the
development process. Far too many people
On Apr 2, 2006, at 3:20 AM, Steven Bosscher wrote:
The fact is, that the GNU Pascal crew did not want integration with
gcc the last time this was discussed. GCC, the project, can not just
suck in every front end out there if the maintainers of that front end
do not want that.
Actually, it can i
On Apr 3, 2006, at 6:34 AM, Waldek Hebisch wrote:
2) Adjusting gpc development model. In particular, gpc uses rather
short
feedback loop: new features are released (as alphas) when they
are ready.
This is possible because gpc uses stable backend, so that users are
exposed only to fro
On Apr 1, 2006, at 7:26 AM, Ed Smith-Rowland wrote:
3. GPC would get much wider exposure. It would probably eventually
ship
along with the rest of gcc in OS distributions including *ahem*
MacOSX.
The GNU project doesn't set what is or becomes product for Apple.
Or, put another way, we
On Tue, Apr 04, 2006 at 09:05:28AM +1200, Nick Roberts wrote:
> It also causes GDB to generate errors on the output of other commands:
>
> (gdb) info locals
> argc = Cannot access memory at address 0x0
>
> as well as the GDB/MI equivalent -stack-list-locals. This breaks the front
> end that
> They've been optimized away. Not surprising, since they are unused,
> although slightly surprising that it happened with -O0.
The manual says:
`-O0'
Do not optimize. This is the default.
so that seems to be a documentation bug at least. More generally, it seems
odd to force an op
Mark Mitchell wrote:
You also need documentation for this feature, discussing both the new
configure switch, and what you have to do to replace the generic
functions, and what the semantics of those functions are, so that people
know how to replace them.
The semantics of these functions are
On Apr 3, 2006, at 09:34, Waldek Hebisch wrote:
2) Adjusting gpc development model. In particular, gpc uses rather
short
feedback loop: new features are released (as alphas) when they
are ready.
This is possible because gpc uses stable backend, so that users are
exposed only to fron
On Mon, 3 Apr 2006, Richard Guenther wrote:
>
> || (TREE_CODE (type) == INTEGER_TYPE
>&& (TREE_CODE (arg1) == INTEGER_CST
>|| TYPE_UNSIGNED (type)
>|| (flag_wrapv && !flag_trapv)))
>
> Does this sound reasonable?
Yes, this sound
On Mon, 3 Apr 2006, Roger Sayle wrote:
>
> On Mon, 3 Apr 2006, Richard Guenther wrote:
> > negate_expr_p currently contains
> > ...
> > where it looks bogus to simply return true for signed types but
> > unset flag_trapv.
> > ...
> > which is bogus as it should read || (!flag_trapv && flag_wrapv)
On Mon, 3 Apr 2006, Richard Guenther wrote:
> negate_expr_p currently contains
> ...
> where it looks bogus to simply return true for signed types but
> unset flag_trapv.
> ...
> which is bogus as it should read || (!flag_trapv && flag_wrapv) - no?
> I hit this with a patch to fold A +- CST to A -
On 4/3/06, Rafael Espíndola <[EMAIL PROTECTED]> wrote:
> The attached patch duplicates convert_and_check into the c++ front
> end.
*cough* Non-normatively speaking, code duplication sucks :-)
Is there a reason why you can't use c-common.* and c_dialect_cxx() instead?
Gr.
Steven
Hi,
I've run into a piece of code on ppc405 that does the wrong thing when a
function is automatically inlined. I don't really do ppc asm so I
haven't been able to isolate what exactly the problem is, but the code
blatantly takes the wrong branch.
The toolchain I'm using is a cross compiler fro
On Mon, Apr 03, 2006 at 11:21:35PM +1200, Nick Roberts wrote:
>
> I've just upgraded to Fedora Core 5 (kernel 2.6.15-1.2054_FC5) and with the
> program below I get results which didn't occur before (Fedora Core 3). I
> posted them to [EMAIL PROTECTED] but I think something is up with GCC
> 4.1.0.
On 4/3/06, Waldek Hebisch <[EMAIL PROTECTED]> wrote:
> Steven Bosscher wrote:
>
> > The fact is, that the GNU Pascal crew did not want integration with
> > gcc the last time this was discussed. GCC, the project, can not just
> > suck in every front end out there if the maintainers of that front end
Steven Bosscher wrote:
> The fact is, that the GNU Pascal crew did not want integration with
> gcc the last time this was discussed. GCC, the project, can not just
> suck in every front end out there if the maintainers of that front end
> do not want that.
Not "did not want integration". At leat
The attached patch duplicates convert_and_check into the c++ front
end. I would like to include it to be able to remove the convert
callback latter on. Duplicating convert_and_check makes it is easy to
use cxx_convert in the c++ front end and c_convert in the c front end.
Thanks,
Rafael
2006-04-0
I hope I am viewed as an impartial but interested third party. I
would really like to see this happen. I did not know about gpc until
a few weeks ago when I did a google search. I may be mistaken but I
think the TeX community would be very interested in a GNU based Pascal.
I am aware tha
I've just upgraded to Fedora Core 5 (kernel 2.6.15-1.2054_FC5) and with the
program below I get results which didn't occur before (Fedora Core 3). I
posted them to [EMAIL PROTECTED] but I think something is up with GCC
4.1.0. I no longer have Core 3 so I've compared output with Mandrake. These
hi there.
i just enabled -Wextra to catch broken if statements,
i.e. to enable warnings on:
* An empty body occurs in an if or else statement.
however this unfortunately triggers other warnings that i can't
reasonably get rid of. here's a test snippet:
== test.c ===
Rafael Espíndola writes:
> The attached patch removes the convert callback by
> 1) copying the c implementation of convert to convert2
> 2) changing all calls to convert in gcj and gfortran into calls to convert2
> 3) adding a lang prefix to the remaining implementations (cxx_, c_, gnat_)
> 4)
negate_expr_p currently contains
switch (TREE_CODE (t))
{
case INTEGER_CST:
if (TYPE_UNSIGNED (type) || ! flag_trapv)
return true;
/* Check that -CST will not overflow type. */
return may_negate_without_overflow_p (t);
where it looks bogus to simply return
Adriaan van Os writes:
> Steven Bosscher wrote:
>
> > Ed Smith-Rowland <[EMAIL PROTECTED]> wrote:
> >> All,
> >>
> >> FWIW, I would like to add my support for creating a branch for gpc
> >> with
> >> the eventual goal
> >> of integrating Pascal into mainline.
> >
> > While I agree with
28 matches
Mail list logo
