On 21/01/18 08:12, Jay K wrote:
> extern const int foo = 123;
>
>
>
> Why does this warn?
> This is a valid portable form, with the same meaning
> across all compilers, and, importantly, portably
> to C and C++.
>
> I explicitly do not want to say:
>
> const int foo = 123
>
> because I want
A second release candidate for GCC 7.3 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/7.3.0-RC-20180122/
and shortly its mirrors. It has been generated from SVN revision 256937.
I have so far bootstrapped and tested the release candidate on
x86_64-unknown-linux-gnu. Please test it and
By this argument there is a missing warning for the equivalent:
const int foo = 123;
with no previous extern declaration.
As well, there is no warning in C++.
All three constructs are equivalent, yet only one gets a warning.
Interesting point, that I had not realized, and with an often accep
Also the warning did not include a link explaining the desired workaround.
Since you advocate for static...and I know it has big value..
There are the following reasons against static:
- It is prohibited in some coding conventions.
They instead hide symbols by omitting them from any header
Am 2018-01-21 um 13:08 schrieb Georg-Johann Lay:
Jay K schrieb:
extern const int foo = 123;
Why does this warn?
This is a valid portable form, with the same meaning
across all compilers, and, importantly, portably
to C and C++.
I also wondered about this.
In C99 §6.9.2 "External object defin
Hello,
I'll be contributing to GCC by working on OpenCoarrays as my PhD programme's
broadening project. I'd like to request the necessary forms to do so. As far as
I'm aware, those are the copyright assignment form of all future changes and
the employer disclaimer form.
Best wishes,
Daniel
On 22/01/2018 10:31, Jay K wrote:
By this argument there is a missing warning for the equivalent:
const int foo = 123;
with no previous extern declaration.
I would like to see such a warning. There is "-Wmissing-declarations",
but that applies only to functions and not to objects.
(
Hi,
On Fri, Jan 19 2018, Sandra Loosemore wrote:
> On 01/19/2018 10:14 AM, Jeff Law wrote:
>
>> cc0 needs to die. That doesn't mean that any particular target needs to
>> be dropped -- it just means that someone has to step forward to do the
>> conversion.
>
> Unifying two parallel threads: mig
Hi,
I made some points in my other reply. But for completeness, I'll tackle
these too.
On 22/01/2018 10:38, Jay K wrote:
Also the warning did not include a link explaining the desired workaround.
Since you advocate for static...and I know it has big value..
There are the following reasons
On Mon, Jan 22, 2018 at 10:57:35AM +0100, Martin Jambor wrote:
> Hi,
>
> On Fri, Jan 19 2018, Sandra Loosemore wrote:
> > On 01/19/2018 10:14 AM, Jeff Law wrote:
> >
> >> cc0 needs to die. That doesn't mean that any particular target needs to
> >> be dropped -- it just means that someone has to
> I find the "scoping" too hard to pass it, and if I need to make
> the symbol extern in future, I can afford a rename to do it.
I mean, I actually like like the ability to shorten file level static symbols.
As you point out, true, you can have it both ways, static does not force
shortenin
On 22/01/2018 11:14, Jay K wrote:
I meant:
extern const foo = 123;
does not warn in C++, but by these arguments, should.
Yes, I think it should. But I am a compiler user, not a compiler
author, so my bias is strongly towards /my/ code rather than a wider
audience.
I understand t
> If you put static (non-const)
> variables in your header files, you have misunderstood how to use header
> files in C programming.
Not me, and usually const, but people do it, both.
Even the consts can get duplicated.
Even the simple C++
const int one = 1;
I can take the address of.
I tried this:
struct C {
virtual ~C();
virtual void f();
};
void
f (C *p)
{
p->f();
p->f();
}
with r256939 and -mindirect-branch=thunk -O2 on x86-64 GNU/Linux, and
got this:
_Z1fP1C:
.LFB0:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset
Hi,
I think we are getting quite a bit off-topic for the gcc list here. We
should probably take the discussion to somewhere like comp.lang.c. So I
shall limit things to just a couple of points to round off.
On 22/01/2018 12:27, Jay K wrote:
> If you put static (non-const)
> variables i
On 01/19/2018 03:13 PM, Martin Jambor wrote:
> On Fri, Jan 19 2018, Martin Jambor wrote:
>> Hi,
>>
>> On Thu, Jan 18 2018, Martin Liška wrote:
>>> On 01/17/2018 06:54 PM, Martin Jambor wrote:
>>>
>> ...
2) Martin Liška is willing to mentor either:
2a) -fsanitize=type (He provided
On 21 January 2018 at 07:12, Jay K wrote:
> extern const int foo = 123;
>
>
>
> Why does this warn?
> This is a valid portable form, with the same meaning
> across all compilers, and, importantly, portably
> to C and C++.
>
> I explicitly do not want to say:
>
> const int foo = 123
>
> because I
On 21 January 2018 at 12:08, Georg-Johann Lay wrote:
> Jay K schrieb:
>>
>> extern const int foo = 123;
>>
>> Why does this warn?
>> This is a valid portable form, with the same meaning
>> across all compilers, and, importantly, portably
>> to C and C++.
>
>
> I also wondered about this.
>
> In C99
On 01/19/2018 03:09 PM, Martin Jambor wrote:
> Hi,
>
> On Thu, Jan 18 2018, Martin Liška wrote:
>> On 01/17/2018 06:54 PM, Martin Jambor wrote:
>>
> ...
>>>
>>> 2) Martin Liška is willing to mentor either:
>>>2a) -fsanitize=type (He provided URL https://reviews.llvm.org/D32197
>>>but i
Hi everyone,
As part of my research, we have been analyzing the usage of GCC builtins
in 5,000 C GitHub projects. One of our findings is that many of these
builtins are unused, even though they are described in the documentation
(see https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html#C-Extension
On 22/01/18 16:46, Manuel Rigger wrote:
> Hi everyone,
>
> As part of my research, we have been analyzing the usage of GCC builtins
> in 5,000 C GitHub projects. One of our findings is that many of these
> builtins are unused, even though they are described in the documentation
> (see https://gcc.
On 1/22/2018 9:55 AM, David Brown wrote:
On 22/01/18 16:46, Manuel Rigger wrote:
Hi everyone,
As part of my research, we have been analyzing the usage of GCC builtins
in 5,000 C GitHub projects. One of our findings is that many of these
builtins are unused, even though they are described in t
On Mon, Jan 22, 2018 at 04:55:42PM +0100, David Brown wrote:
> Many of these are going to be used automatically by the compiler. You
> write "strdup" in your code, and the compiler treats it as
> "__builtin_strdup". I don't know that such functions need to be
> documented as extensions, but they
On Mon, Jan 22, 2018 at 7:55 AM, David Brown wrote:
> On 22/01/18 16:46, Manuel Rigger wrote:
>> Hi everyone,
>>
>> As part of my research, we have been analyzing the usage of GCC builtins
>> in 5,000 C GitHub projects. One of our findings is that many of these
>> builtins are unused, even though
On 2018-01-22 10:53:55 +0100, David Brown wrote:
> On 22/01/2018 10:31, Jay K wrote:
> >
> > By this argument there is a missing warning for the equivalent:
> >
> > const int foo = 123;
> >
> > with no previous extern declaration.
>
> I would like to see such a warning. There is "-Wmissing-
> On Jan 22, 2018, at 5:17 AM, Trevor Saunders wrote:
>
> On Mon, Jan 22, 2018 at 10:57:35AM +0100, Martin Jambor wrote:
>> Hi,
>>
>> On Fri, Jan 19 2018, Sandra Loosemore wrote:
>>> On 01/19/2018 10:14 AM, Jeff Law wrote:
>>>
cc0 needs to die. That doesn't mean that any particular targ
Hi -
> Problems are still occurring for me; Bugzilla gives me 504 Gateway
> Time-outs when I try to access it tonight...
OK, we reworked some of the database routine maintenance workload,
e.g., a nightly cleanup pass that was quite likely excessive, and
will keep monitoring.
- FChE
* Manuel Rigger:
> Details: We downloaded all C projects from GitHub that had more than 80
> GitHub stars, which yielded almost 5,000 projects with a total of more
> than one billion lines of C code. We filtered GCC, forks of GCC, and
> other compilers as we did not want to incorporate internal us
Hi,
On Fri, 12 Jan 2018, Joseph Myers wrote:
> On Fri, 12 Jan 2018, Alexander Monakov wrote:
>
> > No. The qsort_chk effort was limited to catching instances where comparators
> > are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or
> > transitivity property (may indicate A < B
Hi!
On Mon, Jan 22, 2018 at 10:57:35AM +0100, Martin Jambor wrote:
> On Fri, Jan 19 2018, Sandra Loosemore wrote:
> > On 01/19/2018 10:14 AM, Jeff Law wrote:
> >
> >> cc0 needs to die. That doesn't mean that any particular target needs to
> >> be dropped -- it just means that someone has to step
Sent from my iPhone
33 matches
Mail list logo
