On Wed, Sep 9, 2015 at 6:36 PM, 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 dead); th
On Wed, Sep 9, 2015 at 10:26 PM, Szabolcs Nagy wrote:
> * 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?
On Friday 23 April 2010 21:10, Richard Kenner wrote:
> I've happened to be looking at a number of other free-software projects
> recently (having nothing to do with compilers) and find the quality of the
> code ABSOLUTELY APALLING.
That's because you didn't look at non-open code. It's no better.
On Thursday 31 July 2008 11:36, Dave Korn wrote:
> Agner Fog wrote on 31 July 2008 07:14:
>
> > Denys Vlasenko wrote:
> >> I tend to doubt that odd-byte aligned large memcpys are anywhere
> >> near typical. malloc and mmap both return well-aligned buffers
> >&g
On Wednesday 30 July 2008 19:14, Agner Fog wrote:
> I agree that the OpenSolaris memcpy is bigger than necessary. However,
> it is necessary to have 16 branches for covering all possible alignments
> modulo 16. This is because, unfortunately, there is no XMM shift
> instruction with a variable c
On Wed, Jul 30, 2008 at 5:57 PM, Denys Vlasenko
<[EMAIL PROTECTED]> wrote:
> On Fri, Jul 25, 2008 at 9:08 AM, Agner Fog <[EMAIL PROTECTED]> wrote:
>> Raksit Ashok wrote:
>>>There is a more optimized version for 64-bit:
>>>http://src.opensolaris.org/source/xre
On Fri, Jul 25, 2008 at 9:08 AM, Agner Fog <[EMAIL PROTECTED]> wrote:
> Raksit Ashok wrote:
>>There is a more optimized version for 64-bit:
>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s
>>I think this looks similar to your implementation, Agner.
>
> Yes
On Tuesday 01 July 2008 09:24, Sajish V wrote:
> Thanks for the reply, Denys.
> My question was, why doesn't gcc catch it during compilation? It is clear
> that we are trying to free a variable from stack. Shouldn't gcc flag an error
> for this during compilation?
How gcc can know that free() is
On Tuesday 01 July 2008 07:33, x z wrote:
>
> I would like to see that GCC define a macro in the case it is being used to
> compile a program. Currently there is a __GNUC__ macro defined by the GNU C
> preprocessor CPP. That does not suit the need. As the CPP Manual says:
> __GNUC__ is "defin
On Tuesday 01 July 2008 08:38, Sajish V wrote:
> Hi All,
> Can you please let me know why GCC does not crib when we try to free a static
> array?
> main ()
> {
> char array[100];
> free (array);
> }
> The above code compiles without any hitch.
> Thanks,
> Sajish.
# ./a.out
*** glibc
On Sunday 08 June 2008 22:41, Paolo Bonzini wrote:
>
> > Then, running "make all-target-libgcc" built them, but I finally settled
> > for just "make" - it didn't error out.
>
> Yes, the advantage of Paul's suggested process are not only that the
> installations are reproducible and always use th
Accudentally noticed this in my freshly built 4.3.1 tree
in climits C++ header file:
#ifndef LLONG_MIN
#define LLONG_MIN -__LONG_LONG_MAX__ - 1
#endif
#ifndef LLONG_MAX
#define LLONG_MAX __LONG_LONG_MAX__
#endif
#ifndef ULLONG_MAX
#define ULLONG_MAX __LONG_LONG_MAX__ * 2ULL + 1
#endif
Think wh
On Sunday 08 June 2008 16:27, Paul Brook wrote:
> > As far as I know, toolchain is built in this order:
> >
> > 1. binutils
> > 2. C compiler
> > 3. libc
>
> No.
>
> That usually only works if you already have the toolchain installed. In which
> case ordering is irelevant, you can just build whi
On Sunday 08 June 2008 13:50, Joseph S. Myers wrote:
> On Sun, 8 Jun 2008, Denys Vlasenko wrote:
>
> > ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:52:18: error:
> > fenv.h: No such file or directory
>
> Decimal floating point requires . The DP
On Sunday 08 June 2008 04:52, Daniel Jacobowitz wrote:
> On Sat, Jun 07, 2008 at 11:26:05AM +0200, Denys Vlasenko wrote:
> > Seen that 4.3.1 has been released, I tried to build
> > i486-linux-uclibc cross-compiler.
>
> You probably forgot to build libgcc. Are you usi
Seen that 4.3.1 has been released, I tried to build
i486-linux-uclibc cross-compiler.
It went fine except for the detail that none of crt.o files
are found in installation directory after "make install"
For comparison, gcc 4.2.1's directory has them:
# find -name 'crt*.o'
./lib/gcc/i486-linu
On Thursday 17 April 2008 05:26, Brian Dessent wrote:
> Denys Vlasenko wrote:
>
> > Only in my case, $prefix contain neither as nor ld. gcc lives in
>
> Okay, so prepend /usr/app/binutils-2.18-x86_64-linux-uclibc/bin to PATH
> and gcc will find and use x86_64-linux-uclibc-{
On Thursday 17 April 2008 04:04, Brian Dessent wrote:
> > What happened to the good old concept of looking up executables'
> > location in $PATH if they have no slashes on the name?
> >
> > (Oh well)^2. Recompiling with --with-as="/usr/bin/$CROSS-as"...
>
> Why do you think it's necessary to spec
On Thursday 17 April 2008 03:35, Denys Vlasenko wrote:
> On Thursday 17 April 2008 02:40, Denys Vlasenko wrote:
> > I believe I solved it with --with-sysroot...
> > Will try again and let you know.
I got over the problem of includes not being found using --with-sysroot,
and re
On Thursday 17 April 2008 02:40, Denys Vlasenko wrote:
> I believe I solved it with --with-sysroot...
> Will try again and let you know.
So far I only discovered that --with-as="$CROSS-as" is not going to work.
Fixing configure is not enough:
23651 access("x86_64-linux-u
On Thursday 17 April 2008 00:42, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 10:24:35PM +0200, Denys Vlasenko wrote:
> > It seems that 4.2.1 was testing "/usr/lib/../x86_64-linux-uclibc/include",
> > i.e. "$libdir/../x86_64-linux-uclibc/include". From the
On Wednesday 16 April 2008 21:59, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 09:55:09PM +0200, Denys Vlasenko wrote:
> > #include "..." search starts here:
> > #include <...> search starts here:
> > include
> > libbb
> >
> > /.sha
On Wednesday 16 April 2008 21:17, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 09:01:44PM +0200, Denys Vlasenko wrote:
> > As I mentined in the first mail, it's not the end of a story.
> > Next issue: can't find header files. This used to work with 4.2.1:
>
On Wednesday 16 April 2008 17:21, Denys Vlasenko wrote:
> I do it not not only for gcc but for almost everything.
>
> I discovered that a lot of packages will "remember" patchs given
> to configure and use those at runtime. I want them to use
> /ust/bin/something rat
On Wednesday 16 April 2008 17:43, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 05:21:55PM +0200, Denys Vlasenko wrote:
> > Maybe gcc can use paths relative to executable's location?
> > readlink("/proc/self/exe") and all that.
> > It will make gcc ins
On Wednesday 16 April 2008 16:23, Daniel Jacobowitz wrote:
> On Tue, Apr 15, 2008 at 05:34:17AM +0200, Denys Vlasenko wrote:
> > --bindir=/usr/bin \
>
> > bindir=$STATIC/bin \
>
> Why are you configuring for one set of paths w
Ok, I give up.
I killed many hours trying to build a cross-compiling
x86_64-linux-uclibc-gcc, version 4.3.0.
After many "WTF?" moments I decided to go back and try
to build a cross-compiler which I already have,
just older version: I decided to build i486 one,
not x86_64.
Because I already have
Hi,
INSTALL/configure.html mentions ${gcc_tooldir}, just once. Here:
Cross-Compiler-Specific Options
The following options only apply to building cross compilers.
--with-sysroot
--with-sysroot=dir
Tells GCC to consider dir as the root of a tree that contains
a (subset of) the root files
On Saturday 29 March 2008 01:46, Andrew Pinski wrote:
> On Fri, Mar 28, 2008 at 5:16 PM, Denys Vlasenko
> <[EMAIL PROTECTED]> wrote:
> > See:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
>
> And I can tell you now that bug is on purpose and real
On Saturday 29 March 2008 00:56, Alexandra (Sasha) Fedorova wrote:
> I was wondering anyone knows any details of the gcc port for Solaris/x86.
> I am wondering, if I have an executable compiled with gcc for Linux and an
> executable compiled with the same gcc (same version, same options) for
> S
On Friday 29 February 2008 02:09, Joe Perches wrote:
> But the function place_entity doesn't use it directly or indirectly.
> If the lines above are removed, the generated code for place_entity changes.
I see it all the time. Whenever I add/remove/change something
to a header, some functions grow
On Saturday 22 March 2008 11:14, Basile STARYNKEVITCH wrote:
> Actually you ask an interesting & difficult question. Some thoughts from
> somebody who works on GCC for more than a year but still considers
> himself a newbie:
>
> * my impression is that nobody understands fully the GCC compiler.
On Monday 15 October 2007 13:18, Darryl Miles wrote:
> Yes maybe there is a restriction in the ELF format on the maximum
> executable size but linking has little to do with the issue of improving
> performance via better linkage ABI rules. Passing function arguments by
> registers [64bit] verse
On Tuesday 09 October 2007 20:48, Heikki Linnakangas wrote:
> The new linux code is slightly but not much faster than the old one
> (3.04s vs 3.16s),
Test on my machine (three runs)
$ time ./sprintf-linux
./sprintf-linux 10-70-110
user0m2.018s
user0m2.024s
user0m1.997s
$ time ./sprin
On Monday 08 October 2007 16:08, Heikki Linnakangas wrote:
> Denys Vlasenko wrote:
> > On Monday 08 October 2007 13:50, Heikki Linnakangas wrote:
> >> While profiling a test case of exporting data from PostgreSQL, I noticed
> >> that a lot of CPU time was spent in spr
On Monday 08 October 2007 13:50, Heikki Linnakangas wrote:
> While profiling a test case of exporting data from PostgreSQL, I noticed
> that a lot of CPU time was spent in sprintf, formatting timestamps like
> "2007-10-01 12:34". I could speed that up by an order of magnitude by
> replacing the spr
36 matches
Mail list logo
