Andreas Schwab wrote:
It looks like the master branch of git://gcc.gnu.org/git/gcc hasn't been
updated since 3 weeks (trunk is still ok).
Same here. I now use trunk instead.
Jie
Hello,
I've run into this strange warning when compiling w/ optimization:
gcc-4.3 -O2 -Werror -Wall -c -o t.o t.c
cc1: warnings being treated as errors
t.c: In function ‘foo’:
t.c:25: error: array subscript is below array bounds
gcc-4.4 gives the same warning/error, however, gcc 4.1 and 4.2 comp
Peter A. Felvegi wrote:
Hello,
>8>8>8>8>8>8>8>8>8>8
#define ASSERT(x)if (x) { } else { __asm__("int $0x03"); }
With the trunk, that is future 4.5, I would suggest
#define ASSERT(x) if (x) {} else {__builtin_unreachable ();}
or at least, if the int
Therefore, the i370_branch_dest routine needs to handle
those as well. Probably something along the following lines:
if (GET_CODE (dest) == IF_THEN_ELSE)
{
if (GET_CODE (XEXP (dest, 1) == LABEL_REF)
dest = XEXP (dest, 1);
else
dest = XEXP (dest, 2);
}
gcc_assert (GET_CODE (des
Hi all, and Ping! Alex :)
Since the recent vta changes, libgomp build seems to be broken on at least
some platforms that rely on tls emulation. All references to tls variables in
the generated source are prefixed with "__emutls_v" by the action of
get_emutls_object_name() in varasm.c, but
Hi,
I just was curious to know if closures in apple gcc(called blocks from
what I read) is
also in mainline.
What is the status about this extension ?
Thanks
On Tue, Sep 15, 2009 at 3:28 PM, Vincent R. wrote:
> Hi,
>
> I just was curious to know if closures in apple gcc(called blocks from
> what I read) is
> also in mainline.
> What is the status about this extension ?
Hi,
The status is that there is no status, unfortunately (it's an
interesting exte
Paul Edwards wrote:
> Hi Ulrich. Thanks for the reply. I didn't use gcc_assert because I
> didn't see it defined anywhere, but the rest of the fix worked fine.
Ah, I see this macro was only added in 4.x. In 3.x you should just
use abort () directly, like so:
if (GET_CODE (dest) != LABEL_REF
Steven Bosscher wrote:
> Is there even a formal spec for the language extension?
I think it's http://clang.llvm.org/docs/BlockLanguageSpec.txt as that's the
one they've referred to in their white paper (wg14/n1370). It's not written
in your typical standardese as yet, though, from what I could
On Sep 15, 2009, at 3:46 PM, Steven Bosscher wrote:
Hi,
The status is that there is no status, unfortunately (it's an
interesting extension...).
This extension is not presently implemented in the FSF GCC.
AFAIU there is no reason to believe Apple will contribute patches to
implement it.
I t
On Tue, 15 Sep 2009 16:03:35 +0200, Tristan Gingold
wrote:
> On Sep 15, 2009, at 3:46 PM, Steven Bosscher wrote:
>>
>> Hi,
>>
>> The status is that there is no status, unfortunately (it's an
>> interesting extension...).
>>
>> This extension is not presently implemented in the FSF GCC.
>> AFAIU th
"Peter A. Felvegi" writes:
> I've run into this strange warning when compiling w/ optimization:
> gcc-4.3 -O2 -Werror -Wall -c -o t.o t.c
> cc1: warnings being treated as errors
> t.c: In function ‘foo’:
> t.c:25: error: array subscript is below array bounds
This question is appropriate for gcc-
Hello,
I'm rewriting std::rotate in the C++ standard library: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
. The other contributors suggest I register as a contributor and check
in my changes, and in particular submit a copyright assignment form.
May I have that, and any other necessary
On 09/15/2009 08:28 AM, Vincent R. wrote:
I just was curious to know if closures in apple gcc(called blocks from
what I read) is
also in mainline.
What is the status about this extension ?
It is unlikely that this will ever be brought into GCC, since
it appears to be largely identical to the C+
I added some debugging printfs, and ...
> cc1: warnings being treated as errors
> /gnu/gcc/gcc/gcc/dwarf2out.c: In function
> 'add_location_or_const_value_attribute
> ':
> /gnu/gcc/gcc/gcc/dwarf2out.c:13532:1: error: format '%p' expects type 'void
> *',
> but argument 3 has type 'struct var_l
On 09/15/2009 09:56 AM, Ian Lance Taylor wrote:
void assert_failure () __attribute__ ((noreturn, always_inline));
void assert_failure() { __asm__ ("int $0x03"); }
#define ASSERT(x) if (x) { } else { assert_failure(); }
Incidentally, there's a __builtin_trap() that you may wish to use. It
won'
Richard Henderson wrote:
On 09/15/2009 08:28 AM, Vincent R. wrote:
I just was curious to know if closures in apple gcc(called blocks from
what I read) is
also in mainline.
What is the status about this extension ?
It is unlikely that this will ever be brought into GCC, since
it appears to be l
Dave Korn wrote:
> Hi all, and Ping! Alex :)
>
> Since the recent vta changes, libgomp build seems to be broken on at least
> some platforms that rely on tls emulation. All references to tls variables in
> the generated source are prefixed with "__emutls_v" by the action of
> get_emutls_obj
On Sep 15, 2009, at 9:04 AM, Richard Henderson wrote:
On 09/15/2009 08:28 AM, Vincent R. wrote:
I just was curious to know if closures in apple gcc(called blocks
from
what I read) is
also in mainline.
What is the status about this extension ?
It is unlikely that this will ever be brought i
David Krauss writes:
> I'm rewriting std::rotate in the C++ standard library:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351 . The other
> contributors suggest I register as a contributor and check in my
> changes, and in particular submit a copyright assignment form. May I
> have that, an
Ed Smith-Rowland <3dw...@verizon.net> writes:
> In general, and this has come up before, there are other things in
> Objective-C 2.0 that we don't have. IIRC the Apple trees left behind
> are a little old and not in good shape. What are the licensing issues
> for borrowing from LLVM leaving asid
On Tue, Sep 15, 2009 at 05:20:06PM +0100, Dave Korn wrote:
>
> I added some debugging printfs, and ...
>
> > cc1: warnings being treated as errors
> > /gnu/gcc/gcc/gcc/dwarf2out.c: In function
> > 'add_location_or_const_value_attribute
> > ':
> > /gnu/gcc/gcc/gcc/dwarf2out.c:13532:1: error: fo
On Tue, Sep 15, 2009 at 04:03:35PM +0200, Tristan Gingold wrote:
>
> On Sep 15, 2009, at 3:46 PM, Steven Bosscher wrote:
> >
> >Hi,
> >
> >The status is that there is no status, unfortunately (it's an
> >interesting extension...).
> >
> >This extension is not presently implemented in the FSF GCC.
Michael Meissner wrote:
> On Tue, Sep 15, 2009 at 05:20:06PM +0100, Dave Korn wrote:
>> I added some debugging printfs, and ...
>>
>>> cc1: warnings being treated as errors
>>> /gnu/gcc/gcc/gcc/dwarf2out.c: In function
>>> 'add_location_or_const_value_attribute
>>> ':
>>> /gnu/gcc/gcc/gcc/dwarf2
On Tue, Sep 15, 2009 at 8:17 PM, Mark Zweers wrote:
>
> Hello,
>
> While experimenting with "Defaulted and deleting functions" on my brand-newly
> downloaded gcc-4.5 compiler, I've noticed the following: the order of
> '=default' and '=delete' matters with template member functions.
>
> template
Hello, Jason.
Sunday, September 13, 2009 at 4:11:03 AM you wrote:
>> 1. Lambda and template type deduction.
JM> A patch I've been holding off on committing happens to fix this bug.
JM> This is surprising, as I thought it was just a code cleanup. I guess
JM> I'll go ahead and commit it soon.
On 9/15/09, Mark Zweers wrote:
> While experimenting with "Defaulted and deleting functions" on my
> brand-newly downloaded gcc-4.5 compiler, I've noticed the following: the
> order of '=default' and '=delete' matters with template member functions.
>
> template
> class NonCopyable {
> public:
>
Hi,
Looking at ggc-page.c:175ff.,
static const size_t extra_order_size_table[] = {
sizeof (struct var_ann_d),
sizeof (struct tree_decl_non_common),
sizeof (struct tree_field_decl),
sizeof (struct tree_parm_decl),
sizeof (struct tree_var_decl),
sizeof (struct tree_list),
sizeof (stru
Snapshot gcc-4.4-20090915 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090915/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
29 matches
Mail list logo
