On 10/17/24 12:09 PM, Alejandro Colomar via Gcc wrote:
CC += JeanHeyd
CC += Robert, Joseph, gcc@
CC += Doug, as the author of the original malloc(3).
Please don't CC random people (and mailing lists) on a glibc bug report.
See https://sourceware.org/glibc/wiki/FilingBugs for bug reporting
i
at 04:23:29PM GMT, Alejandro Colomar wrote:
> > > > > CC += Doug, as the author of the original malloc(3).
> > > > >
> > > > > On Thu, Oct 17, 2024 at 04:21:22PM GMT, Alejandro Colomar wrote:
> > > > > > Hi!
> > > > > >
Oct 17, 2024 at 04:23:29PM GMT, Alejandro Colomar wrote:
> > > > CC += Doug, as the author of the original malloc(3).
> > > >
> > > > On Thu, Oct 17, 2024 at 04:21:22PM GMT, Alejandro Colomar wrote:
> > > > > Hi!
> > > > >
> >
> >
> > > > On Thu, Oct 17, 2024 at 04:21:22PM GMT, Alejandro Colomar wrote:
> > > > > Hi!
> > > > >
> > > > > наб and I have been researching about malloc(0) and realloc(p,0),
> and
> > > > > have written our findings he
of the original malloc(3).
> > >
> > > On Thu, Oct 17, 2024 at 04:21:22PM GMT, Alejandro Colomar wrote:
> > > > Hi!
> > > >
> > > > наб and I have been researching about malloc(0) and realloc(p,0), and
> > > > have written our finding
ejandro Colomar wrote:
> > > Hi!
> > >
> > > наб and I have been researching about malloc(0) and realloc(p,0), and
> > > have written our findings here:
> > >
> > > <https://github.com/shadow-maint/shadow/pull/1095>
> > > <https://nab
Sent from my iPhone
Hello guys!
I've an idea of new frontend for GCC.
An Objective-D# language! But say "Objective-D Sharp" is quite long, so
I call it the P language (shouldn't be confused with the P language of
Amaya) because of the BCPL : we have the B and the C, so now that's the P.
Th
On 11/14/2012 01:32 PM, Ian Lance Taylor wrote:
On Wed, Nov 14, 2012 at 12:04 PM, Jeff Law wrote:
On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
Given that nobody has stepped forward to test it, let's just remove
the code and see if anybody complains. I'll approve the patch unless
somebody
On Wed, Nov 14, 2012 at 12:04 PM, Jeff Law wrote:
> On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
>>
>> Given that nobody has stepped forward to test it, let's just remove
>> the code and see if anybody complains. I'll approve the patch unless
>> somebody objects in the next 24 hours.
>
> I thi
On 11/14/2012 01:00 PM, Ian Lance Taylor wrote:
Given that nobody has stepped forward to test it, let's just remove
the code and see if anybody complains. I'll approve the patch unless
somebody objects in the next 24 hours.
I think the target to check would be 32 bit HPUX.
-ffunction-sections
On Wed, Nov 14, 2012 at 10:58 AM, Sriraman Tallam wrote:
> On Sun, Nov 4, 2012 at 9:03 PM, Ian Lance Taylor wrote:
>> On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam wrote:
>>>
>>>Currently, using -ffunction-sections and -p together results in a
>>> w
On Sun, Nov 4, 2012 at 9:03 PM, Ian Lance Taylor wrote:
> On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam wrote:
>>
>>Currently, using -ffunction-sections and -p together results in a
>> warning. I ran into this problem when compiling the kernel. This is
>&g
On Sun, Nov 4, 2012 at 8:04 PM, Sriraman Tallam wrote:
>
>Currently, using -ffunction-sections and -p together results in a
> warning. I ran into this problem when compiling the kernel. This is
> discussed in this thread:
>
> http://gcc.gnu.org/ml/gcc-help/2008-11/msg00
Hi,
Currently, using -ffunction-sections and -p together results in a
warning. I ran into this problem when compiling the kernel. This is
discussed in this thread:
http://gcc.gnu.org/ml/gcc-help/2008-11/msg00128.html
Ian's reply suggests this warning is no longer necessary and can be
re
es to overlap but be unequal.
> >
> > Another alternative is that instead of using memcpy, a specialized
> > function could be used that has the required property (the glibc
> > memcpy does).
>
> Note that language semantics come in here as well. The middle-end
> ass
operty (the glibc
> memcpy does).
Note that language semantics come in here as well. The middle-end
assumes that when an assignment is not BLKmode that the RHS
will be read before the lhs will be written. It does not assume so
otherwise and the behavior is undefined for overlapping *p and *q
if you d
On Fri, Apr 30, 2010 at 07:30:33AM -0700, Mark Mielke wrote:
> Just a quick comment than Jan-Benedict's opinion is widely shared by the
> specification and by the Linux glibc manpage:
>
> DESCRIPTION
> The memcpy() function copies n bytes from memory area src to
> memory
> ar
t: Friday, April 30, 2010 10:15 AM
> To: Jan-Benedict Glaw
> Cc: gcc@gcc.gnu.org
> Subject: Re: memcpy(p,p,len)
>
> Jan-Benedict Glaw wrote on 2010/04/30 16:10:42:
> >
> > On Fri, 2010-04-30 16:08:15 +0200, Joakim Tjernlund
> > wrote:
> > > Is memcpy
Glaw wrote on 2010/04/30 16:10:42:
On Fri, 2010-04-30 16:08:15 +0200, Joakim Tjernlund
wrote:
Is memcpy supposed to work when the src and dest are the same:
memcpy(p, p, 100);
It may work, but you cannot rely on it. Use memmove() alternatively.
My view too, but g
On Fri, 2010-04-30 16:14:36 +0200, Joakim Tjernlund
wrote:
> Jan-Benedict Glaw wrote on 2010/04/30 16:10:42:
> > On Fri, 2010-04-30 16:08:15 +0200, Joakim Tjernlund
> > wrote:
> > > Is memcpy supposed to work when the src and dest are the same:
> > > memcpy(p,
Jan-Benedict Glaw wrote on 2010/04/30 16:10:42:
>
> On Fri, 2010-04-30 16:08:15 +0200, Joakim Tjernlund
> wrote:
> > Is memcpy supposed to work when the src and dest are the same:
> > memcpy(p, p, 100);
>
> It may work, but you cannot rely on it. Use memmove() alter
On Fri, 2010-04-30 16:08:15 +0200, Joakim Tjernlund
wrote:
> Is memcpy supposed to work when the src and dest are the same:
> memcpy(p, p, 100);
It may work, but you cannot rely on it. Use memmove() alternatively.
MfG, JBG
--
Jan-Benedict Glaw jbg...@lug-owl.de
Is memcpy supposed to work when the src and dest are the same:
memcpy(p, p, 100);
Jocke
le.
For now I have applied the patch below to our web site; if there are
further improvements you can think of -- don't be shy! :-)
Gerald
Index: lists.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v
retrieving re
On Sun, 5 Apr 2009, Laurent GUERBY wrote:
> I'm thinking of changing my auto tester to report a broken bootstrap
> (the first time a bootstrap fails), is there a normalized way to
> report such failures to gcc-testresults@ or g...@?
The "regression" component in Bugzilla exists for automatic repo
On Sun, 2009-04-05 at 08:25 -0700, H.J. Lu wrote:
> On Sun, Apr 5, 2009 at 2:25 AM, Laurent GUERBY wrote:
> > I'm thinking of changing my auto tester to report a broken bootstrap
> > (the first time a bootstrap fails), is there a normalized way to
> > report such failures to gcc-testresults@ or g
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-p\
> rototypes -Wcast-qual -Wold-style-definition -Wc++-compat
> -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
> -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FI\
> LE -I. -Ibuild -I
Hi,
On sparc-linux gcc54 I get at rev 145425:
/home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/
-B/n/54/guerby/install-trunk/sparc64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-p\
rototypes -Wcast-qual -Wold-style
On Sun, 2007-01-28 at 15:41 -0800, Ray Hurst wrote:
> Shouldn't the compiler error out here.
> The statement: p = "" should have been p = '\0';
> Or does the compiler treat them as equivalent.
>
> It seems that only characters should be assigned to char&
Shouldn't the compiler error out here.
The statement: p = "" should have been p = '\0';
Or does the compiler treat them as equivalent.
It seems that only characters should be assigned to char's and strings
are illegal
Ray
Richard Guenther wrote:
On 1/28/07, De
On 1/28/07, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
char p;
int main() {
p = "";
return 0;
}
Don't you think that "" should end up in rw data?
Why? It's not writable after all.
Richard.
char p;
int main() {
p = "";
return 0;
}
Don't you think that "" should end up in rw data?
/*
.file "t.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string ""
.text
.globl m
ninitialized -Werror ../../srcw/gdb/p-valprint.c
cc1: warnings being treated as errors
../../srcw/gdb/p-valprint.c: In function ‘pascal_object_print_value_fields’:
../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.alloc_failed’ may
be used uninitialized in this function
../../srcw/gdb/p-val
34 matches
Mail list logo
