Hello, gcc team.
At my work I would like to have recent gcc installed but i have no sudo
rights to update the current gcc (its 4.4.7, and OS is redhat linux).
So I checked out latest version of gcc via svn, and following guidelines given
at gcc webpage, tried to download prerequisites, config
On 2015.09.09 at 08:36 +, Michael Mishourovsky wrote:
> At my work I would like to have recent gcc installed but i have no
> sudo rights to update the current gcc (its 4.4.7, and OS is redhat
> linux).
>
> So I checked out latest version of gcc via svn, and following
> guidelines given at
Hi,
The GCC 5.2 installation was successful on an HP Pavilion x360. The
outputs required are:
Output of config.guess:
x86_64-unknown-linux-gnu
Output of gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x
Hi,
http://mirrors-ru.go-parts.com/gcc - Online Shop
ftp://mirrors-ru.go-parts.com/gcc - bad
rsync://mirrors-ru.go-parts.com/gcc - bad
http://mirrors-uk.go-parts.com/gcc/ - Online Shop
ftp://mirrors-uk.go-parts.com/gcc - bad
rsync://mirrors-uk.go-parts.com/gcc - bad
Over the past couple months I have been working on adding a function to
glibc for erasure of sensitive data after it's used. This function
already exists in various other libraries under various names --
explicit_bzero, explicit_memset, SecureZeroMemory, memset_s,
OPENSSL_cleanse, etc -- and the pr
[Sorry for the double-post, but I got the LLVM mailing list address wrong,
and I want to make sure that everyone sees the entire conversation.]
Over the past couple months I have been working on adding a function to
glibc for erasure of sensitive data after it's used. This function
already exists
Gerald, I think we've had similar issues with these mirrors in the
past as well, shall we just remove them from the list?
On 9 September 2015 at 17:28, niXman wrote:
>
> Hi,
>
> http://mirrors-ru.go-parts.com/gcc - Online Shop
> ftp://mirrors-ru.go-parts.com/gcc - bad
> rsync://mirrors-ru.go-part
OK, I have now failed to find the LLVM development list twice in a
row. Could some kind soul please forward the message to whereever the
heck the proper address is?
zw
On Wed, Sep 09, 2015 at 12:36:01PM -0400, Zack Weinberg wrote:
> The first, simpler problem is strictly optimization. explicit_bzero
> can be optimized to memset followed by a vacuous use of the memory
> region (generating no machine instructions, but preventing the stores
> from being deleted as
On 09/09/2015 10:41 AM, Jonathan Wakely wrote:
Gerald, I think we've had similar issues with these mirrors in the
past as well, shall we just remove them from the list?
Please do.
jeff
On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
> You're making this harder than it needs to be. The "m" constraint is
> the wrong thing to use here. Simply use:
>
> __asm__(""::"r"(ptr):"memory");
Please review my earlier conversation with Adhemerval on exactly this point.
zw
> On Sep 9, 2015, at 12:36 PM, Zack Weinberg wrote:
>
> ...
> I think the ideal feature addition to address this would be
>
>void safe(void)
>{
>struct key __attribute__((sensitive)) k = get_key();
>use_key(k);
>}
That certainly is a cleaner answer. What is attract
On Wed, 9 Sep 2015, Jonathan Wakely wrote:
> Gerald, I think we've had similar issues with these mirrors in the
> past as well, shall we just remove them from the list?
>
>> http://mirrors-ru.go-parts.com/gcc - Online Shop
>> ftp://mirrors-ru.go-parts.com/gcc - bad
>> rsync://mirrors-ru.go-parts.c
On 09/09/2015 12:52 PM, paul_kon...@dell.com wrote:
> Then again, suppose all you had is explicit_bzero, and an annotation
> on the data saying it's sensitive. Can static code analyzers take
> care of the rest? If so, this sort of thing doesn't need to be in
> the compiler.
The thing that absolu
Hi Gerald,
It definitely was not. If it was, then we wouldn't keep the servers up
for a year+ (for some other mirrors, 2+ years)We just discontinued
our mirrors project a week or two ago, and haven't had time to contact
everyone yet to take the links down. We will not be returning. Tha
But we will keep the USA mirror up indefinitely.
On 9/9/15 10:00 AM, Dan Derebenskiy wrote:
Hi Gerald,
It definitely was not. If it was, then we wouldn't keep the servers
up for a year+ (for some other mirrors, 2+ years)We just
discontinued our mirrors project a week or two ago, and hav
On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote:
> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
> > You're making this harder than it needs to be. The "m" constraint is
> > the wrong thing to use here. Simply use:
> >
> > __asm__(""::"r"(ptr):"memory");
>
> Please rev
On Wed, Sep 09, 2015 at 12:58:36PM -0400, Zack Weinberg wrote:
> On 09/09/2015 12:52 PM, paul_kon...@dell.com wrote:
> > Then again, suppose all you had is explicit_bzero, and an annotation
> > on the data saying it's sensitive. Can static code analyzers take
> > care of the rest? If so, this sor
On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg wrote:
> The ABI dictates basically everything you see. The call to
> explicit_bzero has forced the compiler to *create* a second copy of
> the variable `k` on the stack, just so it can be erased -- and the
> copy in registers survives (at least for
> On Sep 9, 2015, at 1:54 PM, David Edelsohn wrote:
>
> On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg wrote:
>
>> The ABI dictates basically everything you see. The call to
>> explicit_bzero has forced the compiler to *create* a second copy of
>> the variable `k` on the stack, just so it can
On Wed, Sep 9, 2015 at 2:02 PM, wrote:
>
>> On Sep 9, 2015, at 1:54 PM, David Edelsohn wrote:
>>
>> On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg wrote:
>>
>>> The ABI dictates basically everything you see. The call to
>>> explicit_bzero has forced the compiler to *create* a second copy of
>>
See:
https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00699.html
Full error message:
/home/toon/compilers/trunk/gcc/cp/search.c: In function 'int
accessible_p(tree, tree, bool)':
/home/toon/compilers/trunk/gcc/cp/search.c:1011:41: error: 'otype' may
be used uninitialized in this function [-W
On 09/09/2015 01:13 PM, Rich Felker wrote:
> On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote:
>> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
>>> You're making this harder than it needs to be. The "m" constraint is
>>> the wrong thing to use here. Simply use:
>>>
>>> _
On 09/09/2015 02:02 PM, paul_kon...@dell.com wrote:
>> On Sep 9, 2015, at 1:54 PM, David Edelsohn
>> wrote:
>>
>> What level of erasure of sensitive data are you trying to ensure?
>> Assuming that overwriting values in the ISA registers actually
>> completely clears and destroys the values is d
On 09/09/2015 12:36 PM, Toon Moene wrote:
See:
https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00699.html
Full error message:
/home/toon/compilers/trunk/gcc/cp/search.c: In function 'int
accessible_p(tree, tree, bool)':
/home/toon/compilers/trunk/gcc/cp/search.c:1011:41: error: 'otype' may
b
On 09/09/2015 01:17 PM, Martin Sebor wrote:
On 09/09/2015 12:36 PM, Toon Moene wrote:
See:
https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00699.html
Full error message:
/home/toon/compilers/trunk/gcc/cp/search.c: In function 'int
accessible_p(tree, tree, bool)':
/home/toon/compilers/trunk/
On Wed, Sep 09, 2015 at 02:48:22PM -0400, Zack Weinberg wrote:
> On 09/09/2015 01:13 PM, Rich Felker wrote:
> > On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote:
> >> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
> >>> You're making this harder than it needs to be. The "m" const
* Zack Weinberg [2015-09-09 15:03:50 -0400]:
> On 09/09/2015 02:02 PM, paul_kon...@dell.com wrote:
> >> On Sep 9, 2015, at 1:54 PM, David Edelsohn
> >> wrote:
> >>
> >> What level of erasure of sensitive data are you trying to ensure?
> >> Assuming that overwriting values in the ISA registers a
On 09/07/2015 06:56 PM, David Wohlferd wrote:
In order for the doc maintainers to approve this patch, I need to have
someone sign off on the technical accuracy. Now that I have included
the points we have discussed (attached), hopefully we are there.
Original text: https://gcc.gnu.org/onlinedoc
Snapshot gcc-4.9-20150909 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150909/
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
30 matches
Mail list logo
