On 17/11/2013 06:03, Alec Teal wrote:
> Who isn't compiling with -Wall and -Wextra?
>
Plenty of users ...
> I do hope Clang ('though I don't use it) doesn't make it an error
> because not all functions have to return in C iirc.
It does.
It makes 120 packages fail to build from source in Debian (on
On 11/16/2013 04:25 AM, Tim Prince wrote:
Many decisions on compiler defaults still are based on an unscientific
choice of benchmarks, with gcc evidently more responsive to input from
the community.
I'm also quite convinced that we are hampered by the fact that there is
no IPA on alignment in
On Sun, 17 Nov 2013, Sylvestre Ledru wrote:
On 17/11/2013 06:03, Alec Teal wrote:
I do hope Clang ('though I don't use it) doesn't make it an error
because not all functions have to return in C iirc.
It does.
It makes 120 packages fail to build from source in Debian (on 18854
packages):
http:/
> On Nov 16, 2013, at 11:22 PM, Jeff Law wrote:
>
>> On 11/16/13 21:58, Alec Teal wrote:
>> Now while great, is this true!? Nvidia (IIRC, this was like a year ago
>> though) don't even give out the instruction set for their GPUs, can we
>> have GCC targeting closed things? Also there (must be and
On 11/17/13 07:32, Jeff Hammond wrote:
On Nov 16, 2013, at 11:22 PM, Jeff Law wrote:
On 11/16/13 21:58, Alec Teal wrote:
Now while great, is this true!? Nvidia (IIRC, this was like a year ago
though) don't even give out the instruction set for their GPUs, can we
have GCC targeting closed thing
On Sun, 17 Nov 2013, Marc Glisse wrote:
> On Sun, 17 Nov 2013, Sylvestre Ledru wrote:
>
> > On 17/11/2013 06:03, Alec Teal wrote:
> > > I do hope Clang ('though I don't use it) doesn't make it an error
> > > because not all functions have to return in C iirc.
> > It does.
> > It makes 120 package
On 14/11/2013 12:48, Jonathan Wakely wrote:
> On 14 November 2013 11:31, Dodji Seketeli wrote:
>> For C, I am not sure about, but I'd find it useful to have that warning
>> enabled there too, so I guess I'd like to hear why the warning wasn't
>> enabled there by default there as well.
> A return st
"Ondřej Bílka" wrote:
>On Sat, Nov 16, 2013 at 11:37:36AM +0100, Richard Biener wrote:
>> "Ondřej Bílka" wrote:
>> >On Fri, Nov 15, 2013 at 09:17:14AM -0800, Hendrik Greving wrote:
>>
>> IIRC what can still be seen is store-buffer related slowdowns when
>you have a big unaligned store load in yo
On 17 November 2013 15:40, Sylvestre Ledru wrote:
> For "control reaches end of non-void function", I haven't activated by
> default and I called the option -Wfalloff-nonvoid-function
> Of course, that is just a proposal! :) Better names are welcome.
It was nearly called -Wmissing-return a decade
Hi,
This binutils adds R_X86_64_PC32_BND and R_X86_64_PLT32_BND as specified
in
https://groups.google.com/forum/?hl=en#!topic/x86-64-abi/Cmukf_krWl4
These 2 relocations only appear in relocatable files. They have no
impact on glibc nor gcc. I am checking it into master and 2.24 branch.
Thanks
On Sun, Nov 17, 2013 at 04:42:18PM +0100, Richard Biener wrote:
> "Ondřej Bílka" wrote:
> >On Sat, Nov 16, 2013 at 11:37:36AM +0100, Richard Biener wrote:
> >> "Ondřej Bílka" wrote:
> >> >On Fri, Nov 15, 2013 at 09:17:14AM -0800, Hendrik Greving wrote:
> >>
> >> IIRC what can still be seen is st
In the following code (from xorg-server)
if (a == 0)
addr = 0;
(...)
memset(addr, '\0', a);
the path for a==0 is turned into a trap by -fisolate-erroneous-paths. (Is
calling memset like this undefined behaviour?)
Is it intentional that essentially a noop is turned into a trap?
On 17 November 2013 18:25, Dominic News wrote:
> In the following code (from xorg-server)
>
> if (a == 0)
> addr = 0;
> (...)
> memset(addr, '\0', a);
>
> the path for a==0 is turned into a trap by -fisolate-erroneous-paths. (Is
> calling memset like this undefined behaviour?)
Hello All,
I strongly believe that plugins should be able to be notified of
included headers. Notice that end-users already can be notified with the
-H option of gcc.
This is useful e.g. for plugins which are interfacing to some IDE (like
Eclispe, Geany, ...), because the editor really wants to k
On 11/16/13 22:22, Jeff Law wrote:
On 11/16/13 21:58, Alec Teal wrote:
Now while great, is this true!? Nvidia (IIRC, this was like a year ago
though) don't even give out the instruction set for their GPUs, can we
have GCC targeting closed things? Also there (must be and is) a Cuda
runtime, would
* Jonathan Wakely:
> On 17 November 2013 18:25, Dominic News wrote:
>> In the following code (from xorg-server)
>>
>> if (a == 0)
>> addr = 0;
>> (...)
>> memset(addr, '\0', a);
>>
>> the path for a==0 is turned into a trap by -fisolate-erroneous-paths. (Is
>> calling memset li
On Sun, 17 Nov 2013, Florian Weimer wrote:
* Jonathan Wakely:
On 17 November 2013 18:25, Dominic News wrote:
In the following code (from xorg-server)
if (a == 0)
addr = 0;
(...)
memset(addr, '\0', a);
the path for a==0 is turned into a trap by -fisolate-erroneous-paths.
On 11/17/13 15:02, Florian Weimer wrote:
* Jonathan Wakely:
On 17 November 2013 18:25, Dominic News wrote:
In the following code (from xorg-server)
if (a == 0)
addr = 0;
(...)
memset(addr, '\0', a);
the path for a==0 is turned into a trap by -fisolate-erroneous-paths.
* Jeff Law:
>> Is this new in C11? Does it apply to functions such as strnlen as well?
> No, it's C99 I think. There was a clarification which came in after
> C99 which clarified that even if the length is zero, the pointers must
> still be valid.
Okay, I found the language in sections 7.1.4 a
19 matches
Mail list logo
