Hello all -
All the patches from gc-improv merge have been approved. Due to the
scope of the changes, the merge will need trunk freeze. Thus I am
planning to do it next Tuesday, at 7am CEST. The freeze should last
about 2-3 hours.
Alternatively I could also do the merge tomorrow at the same
Basile Starynkevitch bas...@starynkevitch.net writes:
On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
(2) we should prefer standard solution over home-grown hacks, unless
there is a clear demonstration of value. For example, it would be
unwise to prefer our
2010/6/2 Basile Starynkevitch bas...@starynkevitch.net:
I am not entirely convinced of that. VEC is supported not only by
infamous vec.h macros (which we surely want to replace by some template,
possibly std::vec) but also by gengtype (and the Gcc Garbage Collector).
I strongly believe we
Laurynas Biveinis laurynas.bivei...@gmail.com writes:
2010/6/2 Ian Lance Taylor i...@google.com:
As you say, gengtype includes specific support for VEC. Using
std::vector instead will require some work in gengtype, but not too
much. Currently gengtype generates code like this for a VEC:
2010/6/2 Ian Lance Taylor i...@google.com:
Ian, do you have an idea on how to avoid _M_impl dependency in
gengtype or what else to do about it?
Because we can trivially make gengtype mark the vector itself and mark
whatever was put into vector, but not _M_impl.
I don't think I understand
On 06/01/2010 04:11 PM, Ian Lance Taylor wrote:
In the gccgo IR I don't represent everything with a single type.
Instead, I use a separate base class for types, expressions and
statements (in Go there is more of a distinction between expressions
and statements than there is in C/C++). I
On Wed, Jun 02, 2010 at 08:28:53AM +0200, Laurynas Biveinis wrote:
See http://gcc.gnu.org/wiki/gcc-in-cxx , section Major TODO:
work out the details of using STL containers with GC allocated
objects. This means teaching gengtype how to generate code to traverse
STL containers, which would then
On Tue, Jun 1, 2010 at 6:32 PM, Vladimir Makarov vmaka...@redhat.com wrote:
Richard Guenther wrote:
On Tue, Jun 1, 2010 at 12:00 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, May 31, 2010 at 6:22 PM, Diego Novillo dnovi...@google.com
wrote:
Now that the SC and the FSF
On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
Overall the wiki document looks good. I'd like to disallow
* Operators may only be overloaded for types which implement numeric
values, where the overloaded operators
On Tue, Jun 1, 2010 at 6:37 PM, Robert Dewar de...@adacore.com wrote:
Richard Guenther wrote:
On Tue, Jun 1, 2010 at 4:48 PM, Mark Mitchell m...@codesourcery.com
wrote:
Ian Lance Taylor wrote:
I have written a proposed set of C++ coding conventions on the wiki at
On Wed, Jun 2, 2010 at 1:38 AM, Ian Lance Taylor i...@google.com wrote:
DJ Delorie d...@redhat.com writes:
I did mean that all virtual functions should be protected.
This forbids the most useful thing about virtual functions - letting
child classes implement a public ABI defined by the base
I'd like us to stick with C comments only. I defintely do not like
a mix of both styles and I can't see an advantage of C++ comments.
It indeed seems to fall into the buy-us-nothing category.
--
Eric Botcazou
On Wed, Jun 2, 2010 at 2:49 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie d...@redhat.com wrote:
Hargett, Matt matt.harg...@bluecoat.com writes:
As noted earlier I think we do want to use some STL classes.
I agree with Mark's earlier
Converting to C++ is a major change. Does that justify to have a major release
(5.0.0)?
Bingfeng
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
Richard Guenther
Sent: 02 June 2010 10:36
To: Gabriel Dos Reis
Cc: DJ Delorie; Hargett,
Hi,
For the following simple example,
int main(void)
{
int a=0;
switch (a)
{
case 0:
int b=2;
break;
}
}
GCC will complain:
tst.c: In function 'main':
tst.c:7:6: error: a label can only be part of a statement and a declaration is
not a statement
G++ will
On Wed, Jun 2, 2010 at 12:00 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
For the following simple example,
int main(void)
{
int a=0;
switch (a)
{
case 0:
int b=2;
break;
}
}
GCC will complain:
tst.c: In function 'main':
tst.c:7:6: error: a label can only be
On 02/06/2010 00:31, Mark Mitchell wrote:
At this point, RMS has said, answered this question from me:
Can we take comments (not code) from FSF-owned GPL'd code and process
them in some way that results in them being included in a GFDL'd manual?
by saying, in part:
If Texinfo text is
On 02/06/2010 00:38, Ian Lance Taylor wrote:
DJ Delorie d...@redhat.com writes:
* Use C-style comments for multi-line comments, and C++-style comments
for single-line comments.
I'm not sure i agree with this, because I don't see anything wrong
with multi-line C++-style comments.
It
On 02.06.2010 01:31, Mark Mitchell wrote:
I will state explicitly up front a few topics I am not raising, because
I do not think they are either necessary, or likely to be productive:
* Whether or not the GFDL is a free license, or whether it's a good
license, or anything else about its merits
On Wed, Jun 2, 2010 at 2:07 AM, Laurynas Biveinis
laurynas.bivei...@gmail.com wrote:
Hello all -
All the patches from gc-improv merge have been approved. Due to the
scope of the changes, the merge will need trunk freeze. Thus I am
planning to do it next Tuesday, at 7am CEST. The freeze should
Well, on the one hand I agree - but on the other hand I see people
eagerly waiting to be the first to post patches to convert all
VEC uses that allocate from the heap(!) (yes - we can't use STL
for GC allocated stuff!), leaving us with files that use a mix of
stl::vector and VEC. VEC is clearly
On Wed, Jun 2, 2010 at 1:51 PM, David Edelsohn dje@gmail.com wrote:
On Wed, Jun 2, 2010 at 2:07 AM, Laurynas Biveinis
laurynas.bivei...@gmail.com wrote:
Hello all -
All the patches from gc-improv merge have been approved. Due to the
scope of the changes, the merge will need trunk freeze.
Hi,
On Tue, 1 Jun 2010, Ian Lance Taylor wrote:
* Use C-style comments for multi-line comments, and C++-style comments
for single-line comments.
I'm not sure i agree with this, because I don't see anything wrong
with multi-line C++-style comments.
It assumes your editor can do
On Wed, Jun 2, 2010 at 5:00 AM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
For the following simple example,
int main(void)
{
int a=0;
switch (a)
{
case 0:
int b=2;
break;
}
}
GCC will complain:
tst.c: In function 'main':
tst.c:7:6: error: a label can only be
Hi,
On Wed, 2 Jun 2010, Richard Guenther wrote:
Well, on the one hand I agree - but on the other hand I see people
eagerly waiting to be the first to post patches to convert all VEC uses
that allocate from the heap(!) (yes - we can't use STL for GC allocated
stuff!), leaving us with files
On Tue, Jun 1, 2010 at 11:43 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
(2) we should prefer standard solution over home-grown hacks, unless
there is a clear demonstration of value. For example, it would be
On Wed, Jun 2, 2010 at 1:22 AM, Ian Lance Taylor i...@google.com wrote:
Basile Starynkevitch bas...@starynkevitch.net writes:
On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
(2) we should prefer standard solution over home-grown hacks, unless
there is a clear
On Mon, 2010-05-31 at 08:40 -0700, Mark Mitchell wrote:
Eric Botcazou wrote:
We do require long long for 32-64 cross compilers.
Right, only in this case, and I don't see why this should be changed with
the
transition to C++, that's orthogonal.
I agree.
We need it for any
On Wed, Jun 2, 2010 at 2:44 AM, Paolo Bonzini bonz...@gnu.org wrote:
In particular, I wonder if the best use of C++ wouldn't be a set of
functions (including templates, etc.) implementing a kind of RTTI with a
less verbose syntax than what we have now.
Agreed. I don't agree with the
On Wed, Jun 2, 2010 at 4:19 AM, Richard Guenther
richard.guent...@gmail.com wrote:
I'd like us to stick with C comments only. I defintely do not like
a mix of both styles and I can't see an advantage of C++ comments.
It does not have a 'gotcha' for commenting out codes.
On Wed, Jun 2, 2010 at 3:04 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Wed, Jun 2, 2010 at 4:19 AM, Richard Guenther
richard.guent...@gmail.com wrote:
I'd like us to stick with C comments only. I defintely do not like
a mix of both styles and I can't see an advantage of C++
On Wed, Jun 2, 2010 at 4:35 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Jun 2, 2010 at 2:49 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie d...@redhat.com wrote:
Hargett, Matt matt.harg...@bluecoat.com writes:
As noted
Jakub Jelinek ja...@redhat.com writes:
But do we really want to use std::vector? The vec.h, appart from
having ugly syntactic sugar, seems to be more space efficient, has better
aliasing properties (given that it is just one pointer, you can e.g. use
restrict on it easily) and seems to have
Laurynas Biveinis laurynas.bivei...@gmail.com writes:
2010/6/2 Ian Lance Taylor i...@google.com:
Ian, do you have an idea on how to avoid _M_impl dependency in
gengtype or what else to do about it?
Because we can trivially make gengtype mark the vector itself and mark
whatever was put into
Richard Guenther richard.guent...@gmail.com writes:
On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylor i...@google.com wrote:
Richard Guenther richard.guent...@gmail.com writes:
Overall the wiki document looks good. I'd like to disallow
* Operators may only be overloaded for types which
Dave Korn wrote:
If Texinfo text is included the .h files specifically to be copied into
a manual, it is ok to for you copy that text into a manual and release
the manual under the GFDL.
In context, you means the GCC maintainers and the permission would
be limited only to changes
However, if I changed the code, but did not regenerate the docs, and you
then picked up my changes, possibly made more of your own, and then
regenerated the docs, *you* would be in breach. (Because my changes are
only available to you under the GPL; you do not have the right to
relicense my
On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote:
In the guidelines, I would like to include:
(2) if you define a class template used mostly with pointer type arguments,
consider specializing for void* (or const void*) and define all other
pointer specialization in terms of
Richard Kenner wrote:
However, if I changed the code, but did not regenerate the docs, and you
then picked up my changes, possibly made more of your own, and then
regenerated the docs, *you* would be in breach. (Because my changes are
only available to you under the GPL; you do not have the
On 06/02/2010 03:54 PM, Ian Lance Taylor wrote:
Richard Guentherrichard.guent...@gmail.com writes:
On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylori...@google.com wrote:
Richard Guentherrichard.guent...@gmail.com writes:
Overall the wiki document looks good. I'd like to disallow
*
Matthias Klose wrote:
I will state explicitly up front a few topics I am not raising, because
I do not think they are either necessary, or likely to be productive:
* Whether or not the GFDL is a free license, or whether it's a good
license, or anything else about its merits or lack thereof
On Wed, Jun 2, 2010 at 9:05 AM, Paolo Bonzini bonz...@gnu.org wrote:
On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote:
In the guidelines, I would like to include:
(2) if you define a class template used mostly with pointer type
arguments,
consider specializing for void* (or const
Now that we are talking about STL templates: What about boost?
On Wed, Jun 2, 2010 at 11:22 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Wed, Jun 2, 2010 at 9:05 AM, Paolo Bonzini bonz...@gnu.org wrote:
On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote:
In the guidelines, I
On 2 June 2010 15:33, Emílio Wuerges wrote:
Now that we are talking about STL templates: What about boost?
The requirement for a C++98 compiler is a much weaker requirement than
C++98 compiler + working Boost. Boost is not tested on most of the
platforms that GCC targets. Also, Boost APIs are
On 2 June 2010 15:05, Paolo Bonzini wrote:
On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote:
In the guidelines, I would like to include:
(2) if you define a class template used mostly with pointer type
arguments,
consider specializing for void* (or const void*) and define all
other
On Wed, Jun 2, 2010 at 9:33 AM, Emílio Wuerges wuer...@gmail.com wrote:
Now that we are talking about STL templates: What about boost?
My personal inclination it to keep the dependencies strictly to a
C++98 implementation.
When times come that we need more dependencies and the benefits clearly
Ian Lance Taylor wrote:
Richard Guenther richard.guent...@gmail.com writes:
I agree that that is the usual problem with overloaded operators. I
don't really agree that that is a problem in this specific case. We
have to do those operations anyhow. I don't think the ease of writing
the code
A rather global comment. I think trying to do language
design by the flood-of-email method is dubious. I would
create a specific committee to reccommend a C++ coding
standard (preferably based on one of the standard ones
available, such as Google). And then when there is a
completed document, ask
Robert Dewar de...@adacore.com writes:
A rather global comment. I think trying to do language
design by the flood-of-email method is dubious. I would
create a specific committee to reccommend a C++ coding
standard (preferably based on one of the standard ones
available, such as Google). And
On Wed, May 26, 2010 at 7:16 PM, Mark Mitchell m...@codesourcery.com wrote:
Ulrich Weigand wrote:
So the question is: The goal is to have hooks, not macros, right? If
so, can reviewers please take care to reject patches that introduce
new macros?
I don't know to which extent this is a
Basile == Basile Starynkevitch bas...@starynkevitch.net writes:
Basile Still, my concerns on C++ is mostly gengtype related. I believe we need
Basile to keep a garbage collector even with C++, and I believe that changing
Basile gengtype to follow C++ could be quite painful if we follow the usual
On 02/06/2010 15:07, Mark Mitchell wrote:
Richard Kenner wrote:
However, if I changed the code, but did not regenerate the docs, and you
then picked up my changes, possibly made more of your own, and then
regenerated the docs, *you* would be in breach. (Because my changes are
only
On Wed, Jun 2, 2010 at 6:03 PM, Tom Tromey tro...@redhat.com wrote:
Basile == Basile Starynkevitch bas...@starynkevitch.net writes:
Basile Still, my concerns on C++ is mostly gengtype related. I believe we
need
Basile to keep a garbage collector even with C++, and I believe that changing
On 02/06/2010 17:22, Richard Guenther wrote:
templatetypename T
void mark(const T) { gcc_unreachable (); }
we might be safe to not miss implementations for something gengtype
does not handle itself.
Wouldn't
templatetypename T
void mark(const T) { gcc_does_not_exist_causes_link_failure
On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid them in the
initial subset of C++ used in
On Mon, 2010-05-31 at 08:22 -0400, Robert Dewar wrote:
Gcc is very widespread at this point. Yes, there is the issue
of completely new targets, but these can be easily handled by
building cross-compilers.
Provided that the object format for binaries is published and that we
can therefore
Dave Korn wrote:
Just to be clear, I don't believe that regenerating the docs itself would
be a breach since NOTHING you do internally can be a GPL or GFDL breach).
What would be a breach would be *distributing* those regenerated docs.
Indeed; I was too casual in my description. Dave can
Richard Earnshaw wrote:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time. Therefore, I would avoid them in the
initial subset of C++ used in GCC.
We do, of course, have one
On Wed, Jun 02, 2010 at 06:17:25PM +0100, Richard Earnshaw wrote:
On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to data objects and in uninlinable
indirect calls at run-time.
On Wed, 2010-06-02 at 19:50 +0200, Jakub Jelinek wrote:
On Wed, Jun 02, 2010 at 06:17:25PM +0100, Richard Earnshaw wrote:
On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote:
I think virtual functions are on the edge; quite useful, but do result
in the compiler adding a pointer to
Recently on #gcc, I have been conversing with several others on the
topic of patches lost in the tides of the gcc-patches mailing list. I
flagged Jeff Downs' recent message as an example of a patch that has
been waiting since November
(http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00177.html). I
On Wed, Jun 02, 2010 at 06:52:11PM +0100, Richard Earnshaw wrote:
Currently targetm is a struct with function pointers, so calling
targetm.hook_xyz ();
means reading a pointer from targetm + off, then calling it.
If you make it a class with virtual functions and targetm
would be an
On Wed, Jun 2, 2010 at 14:09, NightStrike nightstr...@gmail.com wrote:
threads that haven't been addressed. I offered to Ian to do the same
thing for the whole mailing list if we can make it a policy that
people who commit changes do what Kai is doing so that it's clear that
the thread is
Robert Dewar de...@adacore.com writes:
I would create a specific committee to reccommend a C++ coding
standard (preferably based on one of the standard ones available, such
as Google).
Doing things in secret like that is not the Open Source Way.
On 06/01/2010 05:52 AM, Richard Guenther wrote:
On Thu, Feb 18, 2010 at 1:26 AM, Paolo Bonzini bonz...@gnu.org wrote:
Maybe we can use this in AC_CHECK_DECLS instead of having a new
separate macro. If there is a parenthesis in the name call the new
version, if there is none, call the old one.
Hi,
I am new into the field of coding, and I am wandering if I can get
some help on how to use the GCC? I have a mac version 10.5.8. Should
I just copy one of the image folders to make computer? how can use
it?
Thank you very much
Manal Habib
I'm not sure i agree with this, because I don't see anything wrong
with multi-line C++-style comments.
I'm with Ian on this one. Is there a reason for this, other than
one's
personal tool preference for editing code may make C-style multi-line
comments easier to add/remove?
On 2 June 2010 22:42, manal habib wrote:
Hi,
I am new into the field of coding, and I am wandering if I can get
some help on how to use the GCC? I have a mac version 10.5.8. Should
I just copy one of the image folders to make computer? how can use
it?
This is not the right mailing list
You've already convinced me, but you originally described a problem
where emacs' paragraph formatting would incorrectly rearrange
multi-line C++ comments. Out of personal curiosity, does emacs
actually have a bug in this regard or not?
It happens to work correctly in a well-formed C++ test
As I was about to check in the -mrecip changes for powerpc on GCC 4.6, I
figured to get a start on documentation, and I was going to edit the
gcc-4.6/changes.html file. I realize this is early in the cycle, but did we
want to create the gcc-4.6 directory?
--
Michael Meissner, IBM
Until June 30:
Hi,
I want to exclude XORI from the instruction set of a cpu. I deleted all the
XORI in md file. But when I compiled my program some XORI operation still
exist. how this would be possible?
--
View this message in context:
2010/6/2 Richard Guenther richard.guent...@gmail.com:
On Wed, Jun 2, 2010 at 1:51 PM, David Edelsohn dje@gmail.com wrote:
On Wed, Jun 2, 2010 at 2:07 AM, Laurynas Biveinis
All the patches from gc-improv merge have been approved. Due to the
scope of the changes, the merge will need trunk
--- Comment #5 from burnus at gcc dot gnu dot org 2010-06-02 06:06 ---
Subject: Bug 44360
Author: burnus
Date: Wed Jun 2 06:06:07 2010
New Revision: 160139
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160139
Log:
2010-06-02 Tobias Burnus bur...@net-b.de
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2010-06-02 06:06 ---
Subject: Bug 44360
Author: burnus
Date: Wed Jun 2 06:06:27 2010
New Revision: 160140
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160140
Log:
2010-06-02 Tobias Burnus bur...@net-b.de
PR
--- Comment #7 from burnus at gcc dot gnu dot org 2010-06-02 06:07 ---
FIXED on the trunk (4.6) and the 4.4 and 4.5 branches.
Thanks for the bug report!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from aoliva at gcc dot gnu dot org 2010-06-02 06:28 ---
Andrew, the debug stmts are indeed originally from the loop header's PHI nodes.
Before ch we have:
i_1 = init;
# i = i_1
goto header;
body:
i_3 = whatever(i_2);
# i = i_3
header:
i_2 = PHI i_1, i_3;
# i = i_2
if
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-06-02 06:43 ---
My mid-term vision to address this sort of problem does not involve adding more
debug bind insns (I don't quite see how to get them right), but rather emit a
new kind of debug stmt/insn so as to emit is_stmt notes in
--- Comment #2 from pault at gcc dot gnu dot org 2010-06-02 06:44 ---
The fix regtests fine. I will take the PR and apply the fix on friday, when I
return from a trip.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pzhao at gcc dot gnu dot org 2010-06-02 06:53 ---
*** This bug has been marked as a duplicate of 43126 ***
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pzhao at gcc dot gnu dot org 2010-06-02 06:53 ---
*** Bug 38468 has been marked as a duplicate of this bug. ***
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
Compile the attached test case with options -march=armv7-a -mthumb -Os,
this code snippet
if (native)
dlmalloc_walk_heap(heap_chunk_callback, (void *)ctx);
else
dvmHeapSourceWalk(heap_chunk_callback, (void *)ctx);
is compiled to:
cbz r5, .L2
ldr r0, .L4
--- Comment #1 from carrot at google dot com 2010-06-02 08:20 ---
Created an attachment (id=20805)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20805action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44374
--- Comment #9 from hariharans at picochip dot com 2010-06-02 08:41 ---
Thanks Alexandre. I can confirm that this patch works for this testcase.
Cheers
Hari
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44013
--- Comment #2 from steven at gcc dot gnu dot org 2010-06-02 08:54 ---
HOIST should do this. You will have to check in the RTL dumps that the code is
exposed properly to this optimization.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #32 from dominiq at lps dot ens dot fr 2010-06-02 08:59 ---
4.5-branch (as of r160013) has an error in config.gcc (which I just fixed on
trunk yesterday, with r159979) in which several t-make fragments are included
twice on x86_64-*-darwin*.
I wonder if this could be
--- Comment #2 from steven at gcc dot gnu dot org 2010-06-02 09:02 ---
Alright, this hunk is apparently necessary, although I don't see how. Oh well.
I'll put it back.
Index: gimplify.c
===
--- gimplify.c (revision
--- Comment #3 from steven at gcc dot gnu dot org 2010-06-02 09:13 ---
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00056.html
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #33 from iains at gcc dot gnu dot org 2010-06-02 09:24 ---
(In reply to comment #32)
4.5-branch (as of r160013) has an error in config.gcc (which I just fixed on
trunk yesterday, with r159979) in which several t-make fragments are
included
twice on x86_64-*-darwin*.
--- Comment #34 from dominiq at lps dot ens dot fr 2010-06-02 09:35 ---
can you do me a favor?
(a) copy the config.{log,out} files.
(b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
.. I suspect a configure race condition - and would not be surprised if the
second
--- Comment #35 from iains at gcc dot gnu dot org 2010-06-02 09:44 ---
(In reply to comment #34)
can you do me a favor?
(a) copy the config.{log,out} files.
(b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
.. I suspect a configure race condition - and would not
--- Comment #36 from dominiq at lps dot ens dot fr 2010-06-02 09:53 ---
Since I had a new comparison failure before your answer, I did the following:
(1) delete the various libgomp folders,
(2) resume make.
Indeed the new libgomp were correctly built and I am now building libgfortran.
--- Comment #37 from iains at gcc dot gnu dot org 2010-06-02 10:06 ---
(In reply to comment #36)
Since I had a new comparison failure before your answer, I did the following:
yes, re-running bootstrap will make no difference if the race is in the
configure...
(1) delete the various
--- Comment #38 from dominiq at lps dot ens dot fr 2010-06-02 10:16 ---
make -jN all
or make -jn bootstrap?
make -j2 log_file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-02 10:24 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
As mentioned in
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00115.html
for -O0 we sometimes, e.g. for return without value or for C++ NRV optimized
return don't emit any insns with the location of the return stmt, which results
in worse debug experience.
--
Summary: goto_locus lost
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-02 10:36 ---
Created an attachment (id=20806)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20806action=view)
gcc46-pr44375.patch
One possible fix. Another is to insert GIMPLE_NOP with the location and handle
it during
optimiser generates SSE instructions that add 32 bit quantities when the field
being referenced is actually 21 bits wide. This disables the possibility of
testing the overflow of the additions.
--
Summary: optimiser destroys possibility of detecting overflow
Product: gcc
--- Comment #1 from geoff at dyalog dot com 2010-06-02 11:09 ---
Created an attachment (id=20807)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20807action=view)
example code to demonstrate bug
extract code using cpio -i code.cpio
gcc -m64 -O3 main.c slave.c -lc
./a.out
If in
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-02 11:17 ---
Please specify the GCC version you see this bug. I think it has been fixed
with GCC 4.5.0.
gcc-4.4 -o t main.c slave.c -O3
./t
overflow assigning 12524191771
total returned = 27
gcc-4.5 -o t main.c slave.c -O3
1 - 100 of 247 matches
Mail list logo
