The debug-early work has been merged into mainline.
There is a known Ada failure which Eric B. knows about and approved, and
for which there is an appropriate FIXME note in the Ada sources:
+FAIL: gnat.dg/specs/debug1.ads scan-assembler-times DW_AT_artificial 17
There is also a known regressi
Hi,
After trying to implement memcmp for big endian I realized that its
exactly whats needed.
As on big endian we could just load them into register and directly
compare them as ordering is same then for little endian we could just
first use bswap for big-endian case.
Following expansion should
On 5 June 2015 at 16:55, Paolo Bonzini wrote:
> The GCC manual says "GCC does not use the latitude given in C99 and C11
> only to treat certain aspects of signed '<<' as undefined, but this is
> subject to change". It would certainly be nice if they removed the
> "this is subject to change" part.
On Fri, 5 Jun 2015, Paolo Bonzini wrote:
> The GCC manual says "GCC does not use the latitude given in C99 and C11
> only to treat certain aspects of signed '<<' as undefined, but this is
> subject to change". It would certainly be nice if they removed the
> "this is subject to change" part.
The
On Fri, 5 Jun 2015, Mikhail Maltsev wrote:
> There are other issues with macros in glibc headers (well, not as
> significant as performance-related concerns, but never the less).
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24016#c3
>
> > #include
> > int foo(void *x) {
> > return strcm
Ondřej Bílka writes:
>
> On ivy bridge I got that Using rep stosq for memset(x,0,4096) is 20%
> slower than libcall for L1 cache resident data while 50% faster for data
> outside cache. How do you teach compiler that?
It would be in theory possible with autofdo. Profile with a cache miss
event. C
Dear GCC developers,
I have just compiled and installed GCC 4.8.4 (see attached files). Any comments
& suggestions are welcome. Thanks!
Yuhang Wang
### Compilation environment
* CentOS 6.6
* x86_64 architecture (Intel(R) Xeon(R) CPU W3550 @ 3.07GHz)
* Compiler: gcc version 4.4.7 20120313 (Red
On 05/06/2015 17:45, Peter Maydell wrote:
>>> ...but things like "(1U << 31)" are entirely valid.
>>
>> They're only valid until someone does a ~ on them. I think it's
>> reasonable to forbid them in our coding standards, if we want to fix
>> ubsan's warning of (1 << 31).
>>
>> I don't think it'
On 06/04/2015 03:40 AM, Richard Earnshaw wrote:
The static chain register is pretty much private to a translation unit...
That was true when the static chain was restricted to trampolines. Since Go
has started using it for cross-translation-unit closures, that makes it part of
the ABI.
I d
On Fri, Jun 05, 2015 at 09:26:33AM +0400, Mikhail Maltsev wrote:
> > The compiler has much more information than the headers.
> > - It can do alias analysis, so to avoid needing to handle overlap
> > and similar.
> > - It can (sometimes) determine alignment, which is important
> > information for t
05.06.2015 13:02, Ondřej Bílka writes:
> Also as I mentioned bugs before gcc now doesn't handle alignment well so
> it doesn't optimize following to zero for aligned code.
>
> align = ((uintptr_t) x) % 16;
>
That is because GCC is conservative and supports some non-ABI-compliant
memory allocator
On Fri, Jun 05, 2015 at 11:23:12AM +0200, Jakub Jelinek wrote:
>
> That is simply not true. E.g.
> struct __attribute__((aligned (16))) S { char b[16]; };
> struct S a;
>
> unsigned long
> foo (void)
> {
> return (((unsigned long) &a) % 16);
> }
> is optimized into 0, many other testcases too,
On Fri, Jun 05, 2015 at 11:02:03AM +0200, Ondřej Bílka wrote:
> On Thu, Jun 04, 2015 at 02:34:40PM -0700, Andi Kleen wrote:
> > The compiler has much more information than the headers.
> >
> > - It can do alias analysis, so to avoid needing to handle overlap
> > and similar.
>
> Could but it coul
On Thu, Jun 04, 2015 at 02:34:40PM -0700, Andi Kleen wrote:
> The compiler has much more information than the headers.
>
> - It can do alias analysis, so to avoid needing to handle overlap
> and similar.
Could but it could also export that information which would benefit
third parties.
> - It ca
On 04-Jun-15 03:54 AM, Jim Wilson wrote:
On 06/02/2015 11:39 PM, shmeel gutl wrote:
find_modifiable_mems was introduced to gcc 4.8 in september 2012. Is
there any documentation as to how it is supposed to help the haifa
scheduler?
The patch was submitted here
https://gcc.gnu.org/ml/gcc-patch
15 matches
Mail list logo
