Snapshot gcc-4.9-20160727 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160727/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Wed, Jul 27, 2016 at 09:14:27PM +0200, Georg-Johann Lay wrote:
> >diff --git a/gcc/combine.c b/gcc/combine.c
> >index 77e0d2b..dec6226 100644
> >--- a/gcc/combine.c
> >+++ b/gcc/combine.c
> >@@ -9977,6 +9977,9 @@ reg_num_sign_bit_copies_for_combine (const_rtx x,
> >machine_mode mode,
> >
Segher Boessenkool schrieb:
On Tue, Jul 26, 2016 at 03:38:18PM +0200, Georg-Johann Lay wrote:
@@ -13206,6 +13206,13 @@ get_last_value (const_rtx x)
&& DF_INSN_LUID (rsp->last_set) >= subst_low_luid)
return 0;
+ /* If the lookup is for a hard register make sure that value contains
at
2016-07-27 20:25 GMT+02:00 Jonathan Wakely :
> I propose that we remove the following non-standard traits in GCC 7:
>
> /// has_trivial_default_constructor (temporary legacy)
> template
>struct has_trivial_default_constructor
>: public integral_constant
>{ } _GLIBCXX_DEPRECATED;
>
>
I propose that we remove the following non-standard traits in GCC 7:
/// has_trivial_default_constructor (temporary legacy)
template
struct has_trivial_default_constructor
: public integral_constant
{ } _GLIBCXX_DEPRECATED;
/// has_trivial_copy_constructor (temporary legacy)
templat
On Tue, Jul 26, 2016 at 03:38:18PM +0200, Georg-Johann Lay wrote:
> >>@@ -13206,6 +13206,13 @@ get_last_value (const_rtx x)
> >> && DF_INSN_LUID (rsp->last_set) >= subst_low_luid)
> >> return 0;
> >>
> >>+ /* If the lookup is for a hard register make sure that value contains
> >>at
> >>
Resend in plain text mode.
On Wed, Jul 27, 2016 at 9:07 AM, Xinliang David Li wrote:
> Our experience is that non-atomic counter update (the current
> implementation) rarely result in corrupted profile (in heavily threaded
> environment) -- it usually results in some profile insanity which can be
(apologies for the double post, GMane had a hiccup. The latter,
which this is a reply to, has one discussion item more, so please
ignore the other)
Hi,
(tl;dr: skip to “questions from me to the GCC developers”)
I’ve recently spotted the following in some code I inherited:
struct foo {
char name[4];
uint8_t len;
uint8_t type;
};
static const struct foo fooinfo[] = {
/* list of 43 members */
};
I’ve seen the
Hi,
(tl;dr: skip to “questions from me to the GCC developers”)
I’ve recently spotted the following in some code I inherited:
struct foo {
char name[4];
uint8_t len;
uint8_t type;
};
static const struct foo fooinfo[] = {
/* list of 43 members */
};
I’ve seen the
On Wed, Jul 27, 2016 at 4:03 PM, Paul Smith wrote:
> Hi all. Don't want to be a noodge but is there any info on a timeline
> for the 6.2 release?
>
> I'm planning a major tools upgrade (from GCC 4.9.2) and I've been kind
> of putting it off until 6.2 is out so I can jump to that... but the
> nati
Hi all. Don't want to be a noodge but is there any info on a timeline
for the 6.2 release?
I'm planning a major tools upgrade (from GCC 4.9.2) and I've been kind
of putting it off until 6.2 is out so I can jump to that... but the
natives are getting restless as they want some C++ features that ar
On 07/26/2016 01:15 AM, Andi Kleen wrote:
> You definitely need a new flag: atomic or per thread instrumentation
> will almost certainly have significant overhead (either at run time
> or in memory). Just making an existing facility a lot of slower
> without a way around it is not a good idea.
Hi
On Tue, Jul 26, 2016 at 11:38 PM, Prathamesh Kulkarni
wrote:
> On 27 July 2016 at 00:20, Prasad Ghangal wrote:
>> On 20 July 2016 at 18:28, Richard Biener wrote:
>>> On Wed, Jul 20, 2016 at 1:46 PM, Prathamesh Kulkarni
>>> wrote:
On 20 July 2016 at 11:34, Richard Biener
wrote:
>
On 26/07/16 21:06, Warren D Smith wrote:
> OK, you just said you've used packed nybble arrays a couple of times.
Yes, a couple of times in 20+ years. And I work with the kind of
programming where something like nibble arrays could conceivably be
useful. For most C programmers, "int" is the only
Citerar Warren D Smith :
Also, I'm somewhat amazed how it is argued to me that a 9-bit machine
the PDP-10 is
covered by C fine, but yet, C insists on having everything a multiple
of 8 bits with padding bits disallowed, and that too is fine, and both
these facts refute me.
Wrong.
The C languag
16 matches
Mail list logo
