Snapshot gcc-5-20160726 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160726/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
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 Tue, Jul 19, 2016 at 10:09 PM, Prasad Ghangal
wrote:
> On 19
>> But it failed to fully correct the error
>> because, at least with gcc's implementation of stdint.h, only 8,16,32,
>> and 64 are provided.
>These cover the needs of virtually everyone in virtually all cases.
--a bold claim, made with zero evidence presented. But
since we know that even 40 yea
> And hell, GCC already includes a lot of really really obscure
> builtin functions which are one hell of a lot less common & useful
> than multiply-hi&lo.
Which exactly proves the point that people are making: whether
something is "common & useful" is rarely the criteria that's used in
deciding w
> It *isn't* "putting every possible feature into every language."
> Did I ever advocate that?
Yes. When you say "X is a useful feature, therefore we should put it
into language Y", you are indeed implicitly advocating that. Because
if that were *not* the case, then saying that X is *useful* say
And hell, GCC already includes a lot of really really obscure builtin
functions which
are one hell of a lot less common & useful than multiply-hi&lo.
I merely cited div(a,b) because it was one of the least obscure among them.
How about freaking "isgraph" and "_mm_set1_epi32"?
I mean how can you ju
It *isn't* "putting every possible feature into every language."
Did I ever advocate that?
It's "putting a feature that you already put there, into the language,
just no longer
arbitrarily selecting certain integer sizes and excluding others."
Am I making syntax more complicated? No. I am if anyth
> OK, you just said you've used packed nybble arrays a couple of times.
> Multiplying you by 100,000 that proves if you put it in GCC,
> you'd save 200,000 programmer hours, which is equivalent to saving
> over 2 lives.
I would suggest that you spend time learning basic principles about
language d
Ok, I'm not affiliated with gcc, nor a committer, I just
happen to work on a port to a local architecture.
Your first posts were funny to read, and you ignored the answers,
and now it's getting old.
Not talking for the gcc community, I suggest that you go
away and come back when you have code to
OK, you just said you've used packed nybble arrays a couple of times.
Multiplying you by 100,000 that proves if you put it in GCC,
you'd save 200,000 programmer hours, which is equivalent to saving
over 2 lives.
You just said you've written your own double-length multiply.
Same proof.
Thank you f
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 Tue, Jul 19, 2016 at 10:09 PM, Prasad Ghangal
>>> wrote:
On 19 July 2016 at 11:04, Richard Biener
wrote:
> On
I am assuming you intended to post this on the mailing list, so I have
restored the addresses.
On 26/07/16 19:55, Warren D Smith wrote:
> To the guy who falsely claimed MIPS fails to provide an add with carry
> instruction,
> a google search in 1 minute finds this:
>
> stackoverflow.com/questions
> On Jul 26, 2016, at 2:07 PM, Warren D Smith wrote:
>
> To the guy who falsely claimed MIPS fails to provide an add with carry
> instruction,
> a google search in 1 minute finds this:
>
> stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly
>
> I defy you to find any proc
To the guy who falsely claimed MIPS fails to provide an add with carry
instruction,
a google search in 1 minute finds this:
stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly
I defy you to find any processor not providing add with carry,
(And I'm not talking about semantic
> On Jul 26, 2016, at 12:50 PM, Warren D Smith wrote:
>
> ...
> Sigh. It's really hard to get compiler and language guys to do anything.
I find it puzzling that you appear to think that insulting your audience is the
best way to influence them.
> ...
> There is absolutely no good reason why
On 26/07/16 16:37, Warren D Smith wrote:
You would get on far better here if you tried a little politeness and
respect, rather than anger, accusations and confrontation.
The C standards were written by a group of very smart and experienced
people, refined over a long time based on real-world issu
On 26/07/16 16:55, Warren D Smith wrote:
> On 7/26/16, Joseph Myers wrote:
>> On Tue, 26 Jul 2016, Warren D Smith wrote:
>>
>>> (And in the case of uint4_t, it actually would not even BE an
>>> "extension" since as I said,
>>> the standard already allows providing other sizes.)
>>
>> Only sizes wh
On Tue, 26 Jul 2016, Warren D Smith wrote:
> --mind-boggling.
> So they actually intentionally made the language worse
> in the C11 TC3 revision versus the C99 standard.
There is no such thing as C11 TC3. All the relevant requirements about
being integer numbers of bytes are present in the orig
--mind-boggling.
So they actually intentionally made the language worse
in the C11 TC3 revision versus the C99 standard.
Sigh. It's really hard to get compiler and language guys to do anything.
I suggest the most stunningly obvious idea, they tell me I am an
idiot. Then years and years later, the
On Tue, 26 Jul 2016, Warren D Smith wrote:
> > Only sizes which are an integer number of bytes with no padding bits.
>
> wikipedia:
Wikipedia is not the standard (and, to be clear, C99 before TC3 had
various defects in the specification as well, so you should not
refer to pre-TC3 versions for
On Tue, 2016-07-26 at 10:37 -0400, Warren D Smith wrote:
> Also, I know on some machines to access a byte you have to get a word
> (larger than 8 bits)
> from memory, do shifts and masks. So clearly you already do that
> inside gcc.
> It therefore is trivial for you to do uint4_t also, because it
On 07/26/16 16:55, Warren D Smith wrote:
And they said "only if available in implementation" which gcc chose to
interpret as
"we're not going to make other sizes available, hahahaha."
"if available in implementation" probably means "if supported by the
underlying hardware".
So, if your hardw
On 7/26/16, Joseph Myers wrote:
> On Tue, 26 Jul 2016, Warren D Smith wrote:
>
>> (And in the case of uint4_t, it actually would not even BE an
>> "extension" since as I said,
>> the standard already allows providing other sizes.)
>
> Only sizes which are an integer number of bytes with no padding
On 26/07/16 15:37, Warren D Smith wrote:
> --the reason I am suggesting this to this forum, is I probably am not capable
> of
> recoding GCC myself.
> Why not learn from your own history, and do that again, with these two
> extensions?
> (And in the case of uint4_t, it actually would not even BE
On Tue, 26 Jul 2016, Warren D Smith wrote:
> However, why not provide access to double-precision multiply and
> add-with-carry (subtract with borrow? shift-left?) in the same fashion?
>twofer x = mul(a,b); would cause x.hi and x.lo to be computed.
>twofer x = addwithcarry(a,b) ditto
A release candidate for the last release from the GCC 4.9 branch,
GCC 4.9.4, is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9.4-RC-20160726/
and shortly its mirrors.
I have sofar bootstrapped and tested the release candidate on
x86_64-unknown-linux-gnu. Please test it and report
On Tue, 26 Jul 2016, Warren D Smith wrote:
> (And in the case of uint4_t, it actually would not even BE an
> "extension" since as I said,
> the standard already allows providing other sizes.)
Only sizes which are an integer number of bytes with no padding bits.
--
Joseph S. Myers
jos...@codesou
On 7/26/16, Jonathan Wakely wrote:
> On 26 July 2016 at 14:31, Warren D Smith wrote:
>> 1. Gcc with stdint.h already
>> provides such nice predefined types as uint8_t.
>> Sizes provided are 8,16,32, and 64.
>> In some sense uint1_t is available too (stdbool.h)
>> but at least on my machine stdbool
On 26 July 2016 at 14:31, Warren D Smith wrote:
> 1. Gcc with stdint.h already
> provides such nice predefined types as uint8_t.
> Sizes provided are 8,16,32, and 64.
> In some sense uint1_t is available too (stdbool.h)
> but at least on my machine stdbool uses 8-bits to store a bool,
Because that
On 26/07/16 14:31, Warren D Smith wrote:
> However, why not provide access to double-precision multiply and
> add-with-carry (subtract with borrow? shift-left?) in the same fashion?
>twofer x = mul(a,b); would cause x.hi and x.lo to be computed.
>twofer x = addwithcarry(a,b) ditto.
On 26.07.2016 14:51, Segher Boessenkool wrote:
On Tue, Jul 26, 2016 at 02:14:49PM +0200, Georg-Johann Lay wrote:
which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx.
Total outcome is that the right shift of reg:DI 18 is transformed to a
no-op move and cancelled out in the rem
1. Gcc with stdint.h already
provides such nice predefined types as uint8_t.
Sizes provided are 8,16,32, and 64.
In some sense uint1_t is available too (stdbool.h)
but at least on my machine stdbool uses 8-bits to store a bool,
e.g. an array of 1000 bools takes 8000 bits,
which is asinine and kind
On Tue, Jul 26, 2016 at 02:14:49PM +0200, Georg-Johann Lay wrote:
> >>which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx.
> >>Total outcome is that the right shift of reg:DI 18 is transformed to a
> >>no-op move and cancelled out in the remainder.
> >
> >Why does num_sign_bit_c
The 4.9 branch is now frozen for the final GCC 4.9.4 release, I will
announce GCC 4.9.4 RC1 once it has built.
Richard.
On 25.07.2016 23:05, Segher Boessenkool wrote:
On Mon, Jul 25, 2016 at 02:28:28PM +0200, Georg-Johann Lay wrote:
(insn 43 31 44 2 (set (reg:QI 18 r18)
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 51 50 52 2 (set (reg:QI 16 r16)
(const_int 40 [0x28])) bu
35 matches
Mail list logo
