Re: What version of binutils is required
On Tue, Feb 23, 2021 at 1:12 AM Gary Oblock via Gcc wrote: > > I'm having a "linker" error (according to Martin Liška) when > compiling a SPEC test (x264_r) with a vendor branch under development (my > optimization is done at LTO time.) > > The binutils on my development machine is the version > that came with Ubuntu 18.02. Do I need to install a more > current version of binutils? Just try? Or at least tell us which version ships with Ubuntu 18.02 ... > Thanks, > > Gary Oblock > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and contains information that > is confidential and proprietary to Ampere Computing or its subsidiaries. It > is to be used solely for the purpose of furthering the parties' business > relationship. Any unauthorized review, copying, or distribution of this email > (or any attachments thereto) is strictly prohibited. If you are not the > intended recipient, please contact the sender immediately and permanently > delete the original and any copies of this email and any attachments thereto.
Re: What version of binutils is required
On 2/23/21 9:41 AM, Richard Biener via Gcc wrote: On Tue, Feb 23, 2021 at 1:12 AM Gary Oblock via Gcc wrote: I'm having a "linker" error (according to Martin Liška) when compiling a SPEC test (x264_r) with a vendor branch under development (my optimization is done at LTO time.) The binutils on my development machine is the version that came with Ubuntu 18.02. Do I need to install a more current version of binutils? Just try? Or at least tell us which version ships with Ubuntu 18.02 ... You likely have version 2.30 (3 years old). Anyway I would test the latest binutils release. Moreover, you can also experiment with ld.gold. Cheers, Martin Thanks, Gary Oblock CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any unauthorized review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
Request for copyright assignment form
Hi, I would like to get a copyright assignment form for GCC. I believe that https://gcc.gnu.org/contribute.html states that the right place to get such a form is here. Thanks, Theo
RE: problems with memory allocation and the alignment check
> > > I just wrote this little program to demonstrate a possible flaw in both > > > malloc and calloc. > > > > > > If I allocate a the simplest memory region from main(), one out of three > > > optimization flags fail. > > > If I allocate the same region from a function, three out of three > > > optimization flags fail. > > > > > > Does someone know if this really is a flaw, and if so, is it a gcc or a > > > kernel flaw? > > > > There is no flaw. GCC (kernel, glibc) all assume unaligned accesses > > on x86 will not cause an exception. > > Is this just an assumption or more like a fact? I agree with you that byte > aligned is more or less the > same as unaligned. They require that such accesses don't cause an exception. While the misaligned accesses are slightly slower (apart from locked accesses that cross page boundaries) the cost of avoiding them is typically higher. This is particularly true for functions like strlen() which are often called for short strings. Care does have to be taken to stop strlen() reading across a page boundary. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: Request for copyright assignment form
See off list. Thanks, David On Tue, Feb 23, 2021 at 7:08 AM The Other via Gcc wrote: > > Hi, > > I would like to get a copyright assignment form for GCC. I believe that > https://gcc.gnu.org/contribute.html states that the right place to get such a > form is here. > > Thanks, > Theo
Re: GSoC project
Thanks, I'll check it out. On Mon, Feb 22, 2021 at 12:23 PM Ankur Saini wrote: > I think this is what you are looking for > > https://gcc.gnu.org/wiki/SummerOfCode > > > On 22-Feb-2021, at 12:08 PM, Utkarsh singh via Gcc > wrote: > > > > Greeting to the team, > > I am Utkarsh Singh. I was going through various projects in the > > archive section of GSoC. I searched for some specific projects in > > Mathematics and C programming as I am most used with this field. I feel I > > can contribute to the organisation which is in turn contributing to the > > world. I wanted to know if the organisation has registered for GSoC 2021 > > and how I should start my contribution journey in GNU Compiler > Collection. > > Thanks and Regards. > >
Re: Constraints and branching in -fanalyzer
I can post it to the patches list with an explanation that it is not a full solution to the PR. I actually put the logic directly into constraint_manager::eval_condition when I was experimenting but I think I will make a new subroutine for you for "folding" constraints. It is not overly complicated, but there are a lot of cases based on whether the binop_svalue is on the right or left of the eval operator, and whether the value we recur on is on the left or right in the binop. A new subroutine can be a place for folding other svalues, such as unaryop or widening. As of now, for example, if we have a constraint on an svalue s, and ask about the same constraint on a unaryop svalue u_s with operator NOP, there is no reason to expect the right answer from the constraint manager. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, February 22, 2021 5:57 PM, David Malcolm wrote: > On Sun, 2021-02-21 at 05:27 +, brian.sobulefsky wrote: > > > To be clear, I only solved the lesser problem > > if(idx-- > 0) > > __analyzer_eval(idx >= 0); > > which is a stepping stone problem. I correctly surmised that this was > > failing > > (with the prefix operator and -= operator working as expected) > > because the > > condition that is constrainted in the postfix problem is the old > > value for idx > > while the condition being evaluated is the new value. I can send you > > a patch, > > but the short version is the initial value of idx is constrained, > > then a binop_svalue > > is stored and eventually ends up in __analyzer_eval. Adding a case in > > constraint_manager::eval_condition to take apart binop svalues and > > recur > > the way you are imagining would be necessary is basically all that is > > needed > > to solve that one. Currently, the constraint_manager is just looking > > at > > that binop_svalue and determining it does not know any rules for it, > > because > > the rule it knows about is actually for one of its arguments. > > I was hoping this would be it for the original loop problem, but like > > I said, > > it goes from saying "UNKNOWN" twice to saying "TRUE UNKNOWN" which I > > found out happens for the other operators in a for loop as well. The > > first > > true is my binop_svalue handler, but the second UNKNOWN is the > > merging of > > the bottom of the loop back with the entry point. > > Since that is fairly abstract, when I found the case I told you > > about, > > I decided to see if I could fix it, because merging >0 with =0 into > > > > > =0 > > > for a linear CFG should not be too hard. > > I think it's probably best if you post the patch that you have so far > (which as I understand it fixes the non-looping case), since it sounds > like a useful base to work from. > > Thanks > Dave > > > ‐‐‐ Original Message ‐‐‐ > > On Saturday, February 20, 2021 12:42 PM, David Malcolm < > > dmalc...@redhat.com> wrote: > > > > > [Moving this discussion from offlist to the GCC mailing list (with > > > permission) and tweaking the subject] > > > On Sat, 2021-02-20 at 02:57 +, brian.sobulefsky wrote: > > > > > > > Yeah, its a lot to take in. For the last one, it was just about > > > > storing and retrieving data and I ignored everything else about > > > > the > > > > analyzer, and that was hard enough. > > > > > > Well done on making it this far; I'm impressed that you're diving > > > into > > > some of the more difficult aspects of this code, and seem to be > > > coping. > > > > > > > I am working on PR94362, which originates from a false positive > > > > found > > > > compiling openssl. It effectivly amounted to not knowing that idx > > > > > > > > > = > > > > > 0 within the loop for(; idx-- >0 ;). > > > > > It turns out there are two problems here. One has to do with the > > > > > postfix operator, and yes, the analyzer currently does not know > > > > > that > > > > > i >= 0 within an if block like if(idx-- > 0). That problem was > > > > > easy > > > > > and I got it to work within a few days with a relatively simple > > > > > patch. I thought I was going to be submitting again. > > > > > The second part is hard. It has to do with state merging and has > > > > > nothing to do with the postfix operator. It fails for all sorts > > > > > of > > > > > operators when looping. In fact, the following fails: > > > > > if(idx < 0) > > > > > idx = 0; > > > > > __analyzer_eval(idx >= 0); > > > > > which is devastating if you are hoping the analyzer can > > > > > "understand" > > > > > a loop. Even with my first fix (which gives one TRUE when run on > > > > > a > > > > > for loop), there is the second "iterated" pass, which ends up > > > > > with a > > > > > widening_svalue (I'm still trying to wrap my head around that one > > > > > too), that gives an UNKNOWN > > > > > > FWIW "widening" in this context is taken from abstract > > > interpretation; > > > see e.g. the early papers by Patrick and Radhia Cousot; the idea is > > > to > > > jump ahead of an infinitely descen
Re: What version of binutils is required
Fair enough... $ ld -V GNU ld (GNU Binutils for Ubuntu) 2.30 From: Richard Biener Sent: Tuesday, February 23, 2021 12:41 AM To: Gary Oblock Cc: gcc@gcc.gnu.org Subject: Re: What version of binutils is required [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.] On Tue, Feb 23, 2021 at 1:12 AM Gary Oblock via Gcc wrote: > > I'm having a "linker" error (according to Martin Liška) when > compiling a SPEC test (x264_r) with a vendor branch under development (my > optimization is done at LTO time.) > > The binutils on my development machine is the version > that came with Ubuntu 18.02. Do I need to install a more > current version of binutils? Just try? Or at least tell us which version ships with Ubuntu 18.02 ... > Thanks, > > Gary Oblock > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and contains information that > is confidential and proprietary to Ampere Computing or its subsidiaries. It > is to be used solely for the purpose of furthering the parties' business > relationship. Any unauthorized review, copying, or distribution of this email > (or any attachments thereto) is strictly prohibited. If you are not the > intended recipient, please contact the sender immediately and permanently > delete the original and any copies of this email and any attachments thereto.
Re: problems with memory allocation and the alignment check
On Mon, 2021-02-22 at 01:41 -0800, Andrew Pinski wrote:
> On Mon, Feb 22, 2021 at 1:37 AM Michael J. Baars
> wrote:
> > On Mon, 2021-02-22 at 01:29 -0800, Andrew Pinski wrote:
> > > On Mon, Feb 22, 2021 at 1:17 AM Michael J. Baars
> > > wrote:
> > > > Hi,
> > > >
> > > > I just wrote this little program to demonstrate a possible flaw in both
> > > > malloc and calloc.
> > > >
> > > > If I allocate a the simplest memory region from main(), one out of
> > > > three optimization flags fail.
> > > > If I allocate the same region from a function, three out of three
> > > > optimization flags fail.
> > > >
> > > > Does someone know if this really is a flaw, and if so, is it a gcc or a
> > > > kernel flaw?
> > >
> > > There is no flaw. GCC (kernel, glibc) all assume unaligned accesses
> > > on x86 will not cause an exception.
> >
> > Is this just an assumption or more like a fact? I agree with you that byte
> > aligned is more or less the same as unaligned.
>
> It is an assumption that is even made inside GCC. You can modify GCC
> not to assume that but you need to recompile all libraries and even
> check the assembly code that is included with most programs.
> Why are you enabling the alignment access check anyways? What are you
> trying to do?
> If you are looking into a performance issue with unaligned accesses,
> may I suggest you look into perf to see if you can see unaligned
> accesses?
Next to performance and correctness, I always try to keep in mind that every
clock cycle will eventually end up on the energy bill, to avoid that computers
cost
ten times more on the energy bill then they do in the store.
If you look at the power consumption of the Playstation 1 vs that of the
Playstation 3 for example, you will see that the Playstation 1 uses (10 W / 240
V
= 0.04167 A max, while the Playstation 3 consumes 240 V * 1.7 A = 408 W.
More than 40 times as much energy!!!
Code and style always go hand in hand. Try to keep you code as sleek as
possible and you will see that even an old computer can do a lot more than you
ever
thought possible :)
Thanks,
Mischa.
> Thanks,
> Andrew
>
> > > Thanks,
> > > Andrew
> > >
> > > > Regards,
> > > > Mischa.
#include
#include "compression.h"
uint8_t data_s[256] = {
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F,
0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F,
0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x5A, 0x5B, 0x5C, 0x5D, 0x5E, 0x5F,
0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6A, 0x6B, 0x6C, 0x6D, 0x6E, 0x6F, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7A, 0x7B, 0x7C, 0x7D, 0x7E, 0x7F,
0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8A, 0x8B, 0x8C, 0x8D, 0x8E, 0x8F, 0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 0x99, 0x9A, 0x9B, 0x9C, 0x9D, 0x9E, 0x9F,
0xA0, 0xA1, 0xA2, 0xA3, 0xA4, 0xA5, 0xA6, 0xA7, 0xA8, 0xA9, 0xAA, 0xAB, 0xAC, 0xAD, 0xAE, 0xAF, 0xB0, 0xB1, 0xB2, 0xB3, 0xB4, 0xB5, 0xB6, 0xB7, 0xB8, 0xB9, 0xBA, 0xBB, 0xBC, 0xBD, 0xBE, 0xBF,
0xC0, 0xC1, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7, 0xC8, 0xC9, 0xCA, 0xCB, 0xCC, 0xCD, 0xCE, 0xCF, 0xD0, 0xD1, 0xD2, 0xD3, 0xD4, 0xD5, 0xD6, 0xD7, 0xD8, 0xD9, 0xDA, 0xDB, 0xDC, 0xDD, 0xDE, 0xDF,
0xE0, 0xE1, 0xE2, 0xE3, 0xE4, 0xE5, 0xE6, 0xE7, 0xE8, 0xE9, 0xEA, 0xEB, 0xEC, 0xED, 0xEE, 0xEF, 0xF0, 0xF1, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6, 0xF7, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE, 0xFF
};
/*
:
0: 48 89 f9 mov%rdi,%rcx
3: 31 d2 xor%edx,%edx
5: b8 00 00 00 01 mov$0x100,%eax
a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
10: 48 83 e8 01 sub$0x1,%rax
14: 75 fa jne10
16: 88 11 mov%dl,(%rcx)
18: 48 83 c2 01 add$0x1,%rdx
1c: 48 83 c1 01 add$0x1,%rcx
20: 48 81 fa 00 01 00 00 cmp$0x100,%rdx
27: 75 dc jne5
29: c3 retq
2a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
*/
void compression_encode_prepare1 (struct compression* c)
{
for (uint64_t j = 0; j < (1 << 24); j++)
for (uint64_t i = 0; i < 256; i++)
{
c->data_t[i]= i;
}
}
void compression_encode_prepare2 (struct compression* c)
{
for (uint64_t j = 0; j < (1 << 24); j++)
asm volatile \
( \
" lea %0 , %%rdi \n" \
" lea %1 , %%rsi \n" \
" mov $0x20, %%rcx \n" \
" rep movsq \n" \
: "=m" (c->data_t) \
: "m" ( data_s) \
: "%rcx", "%rsi", "%rdi" \
);
}
#ifndef __COMPRESSION_H__
#define __COMPRESSION_H__
