Re: [graphite] Weekly phone call notes
On Wed, Apr 29, 2009 at 17:15, Richard Guenther wrote: > I don't see how SSA form makes anything more complicated ;) > One of the difficulties was regenerating the phi nodes after code hoisting: CLooG optimizes for (i) if (invariant of i) s += A[i]; into if (invariant of i) for (i) s += A[i]; In the transformed code you have no place to put the phi nodes that you had after the condition. Add to this the problem of code duplication that CLooG does sometimes: if (invariant of i) for (i in domain1) s += A[i]; for (i in domain2) s += A[i]; ... Maintaining the SSA form for s is difficult after such transforms. If you figure out a good way to maintain the SSA form, I'm very interested to hear about. Thanks, Sebastian
Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)
Hi Ho!
Sorry, if I sort of hijack this thread.
On Wed, 2009-04-29 at 15:43 +, Joseph S. Myers wrote:
> > > "int i;" is not the same as "extern int i;".
> >
> > Sorry for my ignorance but I have been reading and searching for the
> > answer and I cannot tell what is the difference between "int i = 1"
> > and "extern int i = 1" at file-scope in C.
>
> I did not say those were different, I said the uninitialized case was
> different, so "extern is implicit if missing" is not a general C rule.
I think the difference between "int i;" and "extern int i;" at
file-scope in C is that "int i;" will only be treated as a definition if
it is not defined in another place in the same file/TU. IOW, its linkage
is internal within the TU itself. But, "extern int i" is definitely
treated as a declaration only that can later be defined either in the
same TU or in another one.
Is that true?
Finally, is there any difference in declaring a non-inline function
prototype with and without "extern" in C? That is, is there any
difference between:
extern int foo (int *bar);
and
int foo (int *bar);
?
I think they are completely identical. Is that correct?
Also, is there any difference in defining a non-inline function with and
without "extern" in C? That is, is there any difference between:
extern int foo (int *bar)
{
return *bar + 5;
}
and
int foo (int *bar)
{
return *bar + 5;
}
?
I think they are also identical. Am I right? Who knows the one with
"extern" can be overridden in another TU defining its own definition
without "extern".
Thank you for your help :-)
> --
> Joseph S. Myers
> jos...@codesourcery.com
--
Best regards,
Eus (FSF member #4445)
In this digital era, where computing technology is pervasive, your
freedom depends on the software controlling those computing devices.
Join free software movement today! It is free as in freedom, not as in
free beer!
Join: http://www.fsf.org/jf?referrer=4445
Re: Reserving a number of consecutive registers
Ok, now in the easy case it seems to be working. I've handled most cases but I was wondering about one problem that I don't seem to be able to handle. Let's say I want to rename register r6 to r15. I can safely do that in the block if I know that r15 is not used in that basic block and that r6 is not a live-out of the basic block. However, how to handle the case where r6 is a live-out ? Then, I would have to make sure that r15 is not defined in another basic block, thus destroying my new live-out value? It seems to be a cat-mouse game: - I could copy back r15 to r6 in that case though I would like to try to not have to do that because that requires an extra copy at the end of the block - I could go through all the blocks and rename all the r6s into r15s and vice-versa. As long as they are regular registers (and not the return register for example), it should work. I don't see how to do to handle this case neatly, any ideas? Thanks in advance, Jc On Tue, Apr 21, 2009 at 5:23 PM, Jean Christophe Beyler wrote: > Ok, I've been working at this and have actually made a bit of progress. > > - I now have a framework that finds the group of loads (let's assume > they stay together). > > - With the DF framework, I'm able to figure out which registers are > being used and which are free to be used. > > - I've pretty much got it to change the registers to the ones I want > but there are still some corner cases where it seems to be badly > handling that and actually changing the semantics of the program. > > I'll look into that, thanks, > Jc > > On Mon, Apr 20, 2009 at 3:01 PM, Eric Botcazou wrote: >>> Ok, I'll try to look at that. Is there an area where I can see how to >>> initialize the framework and get information about which registers are >>> free? >> >> The API is in df.h, see for example ifcvt.c. >> >> -- >> Eric Botcazou >> >
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
On Wed, Apr 29, 2009 at 18:28, Janis Johnson wrote: ... > The preferred way to post test results is by running the script > $SRC/contrib/test_summary from within the build directory. It > produces a summary in the form of a script which will mail that > summary to gcc-testresu...@gcc.gnu.org, where it will be archived Is there an alternative for systems without mail access? -Tom
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
On Thu, Apr 30, 2009 at 7:30 AM, Tom Browder wrote: > On Wed, Apr 29, 2009 at 18:28, Janis Johnson wrote: > ... >> The preferred way to post test results is by running the script >> $SRC/contrib/test_summary from within the build directory. It >> produces a summary in the form of a script which will mail that >> summary to gcc-testresu...@gcc.gnu.org, where it will be archived > > Is there an alternative for systems without mail access? It will not execute the commands unless you pipe the script output to sh so you can copy and paste the output from the script into an email that you author by hand. -- Pinski
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
On Thu, Apr 30, 2009 at 7:30 AM, Tom Browder wrote: On Wed, Apr 29, 2009 at 18:28, Janis Johnson wrote: ... The preferred way to post test results is by running the script $SRC/contrib/test_summary from within the build directory. It produces a summary in the form of a script which will mail that summary to gcc-testresu...@gcc.gnu.org, where it will be archived Is there an alternative for systems without mail access? It will not execute the commands unless you pipe the script output to sh so you can copy and paste the output from the script into an email that you author by hand. Also, the end of the generated script attempts to move a bunch of files in the test area, so if you ship the script to another machine, you can skip that part. Fang David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
On Thu, 2009-04-30 at 11:56 -0400, David Fang wrote: > > On Thu, Apr 30, 2009 at 7:30 AM, Tom Browder wrote: > >> On Wed, Apr 29, 2009 at 18:28, Janis Johnson wrote: > >> ... > >>> The preferred way to post test results is by running the script > >>> $SRC/contrib/test_summary from within the build directory. It > >>> produces a summary in the form of a script which will mail that > >>> summary to gcc-testresu...@gcc.gnu.org, where it will be archived > >> > >> Is there an alternative for systems without mail access? > > > > It will not execute the commands unless you pipe the script output to > > sh so you can copy and paste the output from the script into an email > > that you author by hand. > > Also, the end of the generated script attempts to move a bunch of files in > the test area, so if you ship the script to another machine, you can skip > that part. Or you can use "test_summary -t", which omits the file moves. Janis
Re: [lambda] Segmentation fault in simple lambda program
Esben Mose Hansen writes:
> this program SEGFAULTs
>
> #include
>
> int main() {
> int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
> const std::size_t nn = sizeof(numbers)/sizeof(int);
> int sum = 0;
> int f = 5;
> std::for_each(&numbers[0], &numbers[nn], [&] (int n) {
> sum += n * f;
> });
>
> }
>
> Now, my assembly days are some 15 years past, but the disassembly is
>
> 0x08048424 <_ZZ4mainENK9__lambda0clEiz+0>: push %ebp
> 0x08048425 <_ZZ4mainENK9__lambda0clEiz+1>: mov%esp,%ebp
> 0x08048427 <_ZZ4mainENK9__lambda0clEiz+3>: mov0x8(%ebp),%eax
> 0x0804842a <_ZZ4mainENK9__lambda0clEiz+6>: mov0x4(%eax),%eax
> 0x0804842d <_ZZ4mainENK9__lambda0clEiz+9>: mov0x8(%ebp),%edx
> 0x08048430 <_ZZ4mainENK9__lambda0clEiz+12>: mov0x4(%edx),%edx
> 0x08048433 <_ZZ4mainENK9__lambda0clEiz+15>: mov(%edx),%ecx
> 0x08048435 <_ZZ4mainENK9__lambda0clEiz+17>: mov0x8(%ebp),%edx
> 0x08048438 <_ZZ4mainENK9__lambda0clEiz+20>: mov(%edx),%edx
> 0x0804843a <_ZZ4mainENK9__lambda0clEiz+22>: mov(%edx),%edx
> 0x0804843c <_ZZ4mainENK9__lambda0clEiz+24>: imul 0xc(%ebp),%edx
> 0x08048440 <_ZZ4mainENK9__lambda0clEiz+28>: lea(%ecx,%edx,1),%edx
> => SEGFAULT 0x08048443 <_ZZ4mainENK9__lambda0clEiz+31>: mov%edx,(%eax)
> 0x08048445 <_ZZ4mainENK9__lambda0clEiz+33>: pop%ebp
> 0x08048446 <_ZZ4mainENK9__lambda0clEiz+34>: ret
>
> I have marked the segfault spot. I also find 0x0804843a suspicious, but then
> I
> don't even know how to print register values in gcc.
>
> Any pointers to where I should dig? I am completely new to gcc hacking, just
> dying to get lambda into gcc 4.5 :)
>
> P.S: Shouldn't gcc show the actual lambda function code ( sum+= f*c; )
> instead
> of the assembly code in any case?
When I try to specify the capture it works ((&sum, &f) works too but f is
const):
#include
int
main(void)
{
int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
const std::size_t nn = sizeof(numbers)/sizeof(int);
int sum = 0;
int f = 5;
//std::for_each(&numbers[0], &numbers[nn], [&](int n) { sum += n * f; });
std::for_each(&numbers[0], &numbers[nn], [&sum, f](int n) { sum += n * f; });
return 0;
}
Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)
Eus writes:
> I think the difference between "int i;" and "extern int i;" at
> file-scope in C is that "int i;" will only be treated as a definition if
> it is not defined in another place in the same file/TU. IOW, its linkage
> is internal within the TU itself. But, "extern int i" is definitely
> treated as a declaration only that can later be defined either in the
> same TU or in another one.
>
> Is that true?
What you are describing is a common and traditional implementation of C,
but it is not strictly standard conformant. The ISO C standard says
that "int i;" is always a definition, and "extern int i;" is always a
declaration. What you decribe is listed as a common extension (at least
in C90--I didn't bother to check C99).
> Finally, is there any difference in declaring a non-inline function
> prototype with and without "extern" in C? That is, is there any
> difference between:
>
> extern int foo (int *bar);
>
> and
>
> int foo (int *bar);
>
> ?
>
> I think they are completely identical. Is that correct?
Yes. In a function (not variable) declaration, the "extern" is
optional. This is true in both C and C++.
> Also, is there any difference in defining a non-inline function with and
> without "extern" in C? That is, is there any difference between:
>
> extern int foo (int *bar)
> {
> return *bar + 5;
> }
>
> and
>
> int foo (int *bar)
> {
> return *bar + 5;
> }
>
> ?
>
> I think they are also identical. Am I right? Who knows the one with
> "extern" can be overridden in another TU defining its own definition
> without "extern".
These are not identical, but the meaning in C is complex because it
changes depending on which standard you are using. Look at the docs for
the -fgnu89-inline option and the gnu_inline function attribute.
Ian
Re: Reserving a number of consecutive registers
> Let's say I want to rename register r6 to r15. I can safely do that in > the block if I know that r15 is not used in that basic block and that > r6 is not a live-out of the basic block. > > However, how to handle the case where r6 is a live-out ? Then, I would > have to make sure that r15 is not defined in another basic block, thus > destroying my new live-out value? > > It seems to be a cat-mouse game: > > - I could copy back r15 to r6 in that case though I would like to try > to not have to do that because that requires an extra copy at the end > of the block Yes, you need to make a copy in this case but its cost could be offsetted by the gain from the load_multiple. Or it could be eliminated by running a new instance of cprop_hardreg. You need to experiment and tune the pass. -- Eric Botcazou
Re: [lambda] Segmentation fault in simple lambda program
On Thursday 30 April 2009 19:19:31 you wrote:
> When I try to specify the capture it works ((&sum, &f) works too but f is
> const):
>
> #include
>
> int
> main(void)
> {
> int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
> const std::size_t nn = sizeof(numbers)/sizeof(int);
> int sum = 0;
> int f = 5;
>
> //std::for_each(&numbers[0], &numbers[nn], [&](int n) { sum += n * f; });
>
> std::for_each(&numbers[0], &numbers[nn], [&sum, f](int n) { sum += n * f;
> });
>
> return 0;
> }
Yup. In fact, almost any other capture block than the [&] works :) I will try
to look at those tree options when I get sober again.
--
Kind regards, Esben
Is this valid c++ ?
I have the following code snippet:
typedef volatile struct {
} mystruct;
void mytest(mystruct* x) {};
As a C program (gcc) this compiles fine, but with g++ I get the
following error:
test.cpp:4: error: non-local function ‘void mytest(volatile mystruct*)’
uses anonymous type
test.cpp:2: error: ‘typedef volatile struct mystruct’ does
not refer to the unqualified type, so it is not used for linkage
So my question is: is g++ reporting the error incorrectly, or is it not
valid c++ and if so why?
Thanks in advance.
Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)
On Thu, Apr 30, 2009 at 11:57 AM, Ian Lance Taylor wrote: > Eus writes: > >> I think the difference between "int i;" and "extern int i;" at >> file-scope in C is that "int i;" will only be treated as a definition if >> it is not defined in another place in the same file/TU. IOW, its linkage >> is internal within the TU itself. But, "extern int i" is definitely >> treated as a declaration only that can later be defined either in the >> same TU or in another one. >> >> Is that true? > > What you are describing is a common and traditional implementation of C, > but it is not strictly standard conformant. The ISO C standard says > that "int i;" is always a definition, and "extern int i;" is always a > declaration. What you decribe is listed as a common extension (at least > in C90--I didn't bother to check C99). [I imagine Ian is aware of this anywyay, but to try to clarify...] At file scope, "int i;" with no initializer is a "tentative definition" in C, see 6.9.2/2; a tentative definition is an odd beast that works in some ways rather unlike other definitions (e.g., it's perfectly valid to have multiple tentative definitions for the same variable in the same file). Informally (only) it seems fair to say that a tentative definition is "treated as a declaration only". If you want precision though, such fudging isn't helpful. C++ does not have the concept of a tentative declaration: int i; int i; // legal in C99, invalid as a duplicate definition in C++03 To me that's amusing when compared to: typedef int j; typedef int j; // legal in C++03, invalid as a duplication definition in C99 -- James
Re: [graphite] Weekly phone call notes
Sebastian Pop wrote: On Wed, Apr 29, 2009 at 17:15, Richard Guenther wrote: I don't see how SSA form makes anything more complicated ;) One of the difficulties was regenerating the phi nodes after code hoisting: CLooG optimizes for (i) if (invariant of i) s += A[i]; into if (invariant of i) for (i) s += A[i]; In the transformed code you have no place to put the phi nodes that you had after the condition. Add to this the problem of code duplication that CLooG does sometimes: if (invariant of i) for (i in domain1) s += A[i]; for (i in domain2) s += A[i]; ... Maintaining the SSA form for s is difficult after such transforms. If you figure out a good way to maintain the SSA form, I'm very interested to hear about. I believe the short-cut proposed by Sebastian makes sense. We never go out of SSA, just the hard-to-maintain-in-SSA induction variables are converted temporarily into single-element arrays. This of course is only a quick fix, and it does handle all cases. It will not complicate a future rewrite of this into a nice in-SSA induction variable reconstruction (an unexpected problem, worth investigating indeed, and maybe a future deeper research result is hiding). Albert
Re: Is this valid c++ ?
Albert Hopkins writes:
> I have the following code snippet:
>
> typedef volatile struct {
> } mystruct;
>
> void mytest(mystruct* x) {};
>
> As a C program (gcc) this compiles fine, but with g++ I get the
> following error:
>
> test.cpp:4: error: non-local function ‘void mytest(volatile mystruct*)’
> uses anonymous type
> test.cpp:2: error: ‘typedef volatile struct mystruct’ does
> not refer to the unqualified type, so it is not used for linkage
>
> So my question is: is g++ reporting the error incorrectly, or is it not
> valid c++ and if so why?
This question would be more appropriate for the gcc-h...@gcc.gnu.org
mailing list. Please take any followups to that mailing list.
In C++, an externally visible function can not refer to a local type.
The reason is that there is no way for a function defined in another
file to call it, because that function can not create an instance of the
local type. In this case, the local type is the anonymous struct.
It may seems that a function in another file could use the type
mystruct. That would be permitted if you wrote "typedef struct {}
mystruct", because that would effectively mean that mystruct was the
name of the struct. However, you used the volatile qualifier, and that
applies to the typedef, not to the struct. That is, mystruct is a
volatile version of a struct which can not be named. No function in
another file is going to be able to create an instance of that struct,
so the function mytest is not permitted to have external linkage.
Ian
Re: [graphite] Weekly phone call notes
On Thu, Apr 30, 2009 at 2:53 PM, Albert Cohen wrote: > I believe the short-cut proposed by Sebastian makes sense. We never go out > of SSA, just the hard-to-maintain-in-SSA induction variables are converted > temporarily into single-element arrays. This of course is only a quick fix, > and it does handle all cases. It will not complicate a future rewrite of > this into a nice in-SSA induction variable reconstruction (an unexpected > problem, worth investigating indeed, and maybe a future deeper research > result is hiding). Actually I think it might be better not to create arrays but instead just extend DECL_GIMPLE_REG_P to types besides vector and complex ones. This way the only pass that needs to run afterwards is pass_update_address_taken and that automatically converts back non renamable variables to renamed ones without worrying about running SRA (or a special case of SRA) again. Thanks, Andrew Pinski
Please help me test the power7-meissner branch before I submit the changes
The power7 stuff should be fairly stable at this point, and I feel it is time to submit it to the mainline GCC. If other powerpc users can try out the branch to see if there are regressions, it would be helpful. Note with the recent gimple type validation errors, the mainline now has more failures than it had previously, so be sure to compare it to the mainline branch of the same vintage (the branch is currently syned to svn version 147021). I have fixed some of the vectorizer failures in this branch, but there are still failures for both mainline and this branch. In particular, I would like to know if I caused any regressions in the embedded powerpc (spe, e500, etc.). Some of the E500/SPE stuff would fit in with the abstractions I put in for distinguishing between altivec and vsx. The branch is at: svn+ssh://@gcc.gnu.org/svn/gcc/branches/ibm/power7-meissner Thanks in advance. -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA meiss...@linux.vnet.ibm.com
gcc-4.5-20090430 is now available
Snapshot gcc-4.5-20090430 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090430/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 147022 You'll find: gcc-4.5-20090430.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20090430.tar.bz2 C front end and core compiler gcc-ada-4.5-20090430.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20090430.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20090430.tar.bz2 C++ front end and runtime gcc-java-4.5-20090430.tar.bz2 Java front end and runtime gcc-objc-4.5-20090430.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20090430.tar.bz2The GCC testsuite Diffs from 4.5-20090423 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)
Hi Ho!
On Thu, 2009-04-30 at 11:57 -0700, Ian Lance Taylor wrote:
> What you are describing is a common and traditional implementation of C,
> but it is not strictly standard conformant. The ISO C standard says
> that "int i;" is always a definition, and "extern int i;" is always a
> declaration. What you decribe is listed as a common extension (at least
> in C90--I didn't bother to check C99).
Thank you for clarifying further in light of the standard.
> Yes. In a function (not variable) declaration, the "extern" is
> optional. This is true in both C and C++.
Thanks for the answer. I had been pondering upon this point for about a
year or so since I hacked the Linux kernel for the very last time. It is
because in some header files, some prototypes use "extern" and some
don't. So, I was curious as to whether they have a different semantic.
> > Also, is there any difference in defining a non-inline function with
> and
> > without "extern" in C? That is, is there any difference between:
> >
> > extern int foo (int *bar)
> > {
> > return *bar + 5;
> > }
> >
> > and
> >
> > int foo (int *bar)
> > {
> > return *bar + 5;
> > }
> >
> > ?
> >
> > I think they are also identical. Am I right? Who knows the one with
> > "extern" can be overridden in another TU defining its own definition
> > without "extern".
>
> These are not identical, but the meaning in C is complex because it
> changes depending on which standard you are using. Look at the docs
> for
> the -fgnu89-inline option and the gnu_inline function attribute.
Ah, I get it.
Yes, I am aware of the different semantic when inline is involved like
what you have specified here:
http://gcc.gnu.org/ml/gcc/2006-11/msg6.html
> Ian
Thanks for your answers :-)
--
Best regards,
Eus (FSF member #4445)
In this digital era, where computing technology is pervasive, your
freedom depends on the software controlling those computing devices.
Join free software movement today! It is free as in freedom, not as in
free beer!
Join: http://www.fsf.org/jf?referrer=4445
Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)
Hi Ho! On Thu, 2009-04-30 at 12:40 -0700, James Dennett wrote: > [I imagine Ian is aware of this anywyay, but to try to clarify...] > > At file scope, "int i;" with no initializer is a "tentative > definition" in C, see 6.9.2/2; a tentative definition is an odd beast > that works in some ways rather unlike other definitions (e.g., it's > perfectly valid to have multiple tentative definitions for the same > variable in the same file). Informally (only) it seems fair to say > that a tentative definition is "treated as a declaration only". If > you want precision though, such fudging isn't helpful. Yup, I am aware of this. > C++ does not have the concept of a tentative declaration: > int i; > int i; // legal in C99, invalid as a duplicate definition in C++03 > > To me that's amusing when compared to: > typedef int j; > typedef int j; // legal in C++03, invalid as a duplication definition in C99 Heh, that's strange ;-) Thanks for your further clarification :-) > -- James -- Best regards, Eus (FSF member #4445) In this digital era, where computing technology is pervasive, your freedom depends on the software controlling those computing devices. Join free software movement today! It is free as in freedom, not as in free beer! Join: http://www.fsf.org/jf?referrer=4445
Re: gcc-in-cxx update
On Wed, Apr 29, 2009 at 7:13 AM, Manuel López-Ibáñez wrote: >>> * In C a const variable which is neither "extern" nor "static" is >>> visible outside of the current translation unit. In C++ it is not, >>> without an explicit "extern" declaration. I'm not sure how best to >>> handle this with -Wc++-compat, since C does not permit initializing an >>> "extern const" variable. >> >> C does permit it; there's a warning, not a pedwarn. Add an option to >> disable this warning (at least where "const" is used)? > > In any case, -Wc++-compat should warn about the difference in > behaviour, shouldn't it? > > I see the current code already handles this somehow: > > /* It is fine to have 'extern const' when compiling at C > and C++ intersection. */ > if (!(warn_cxx_compat && constp)) > warning (0, "%qs initialized and declared %", name); > > BTW, why is this warned about? I believe I'm the author of that code. We had had this debate a couple of years back, when I had more resources to work on GCC. At the time, I was doing an incremental version of the amazing job Ian just accomplished and the CPP component had the construct that declared a variable as const but did not initialize it, and did not contain the `extern' specifier. That in C++ meant that the variable has an internal linkage -- but in C, the variable would have an external linkage. So, to write the code that meant the same thing in C and in C++, an 'extern' specifier is needed. The C people (I bellieve) at the time felt strongly that if not -Wc++-compat it probably should be warned about (because it is not "typical" C). -- Gaby
Re: gcc-in-cxx update
On Wed, Apr 29, 2009 at 8:42 AM, Manuel López-Ibáñez wrote: >>> >>> BTW, why is this warned about? >> >> I imagine because in C it is not conventional to use "extern" when >> defining something, only on a declaration that is not a definition. > > But may it lead to some confusion or subtle error? It seems overly > pedantic to me if it is just a matter of style, because extern is > implicit if missing, > > If one wants to use the same code in C and C++, then it is definitely > a spurious warning in my opinion. I do not understand your reasoning. -- Gaby
Re: gcc-in-cxx update
On Wed, Apr 29, 2009 at 10:19 AM, Manuel López-Ibáñez wrote: > 2009/4/29 Joseph S. Myers : >> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: >> >>> >> BTW, why is this warned about? >>> > >>> > I imagine because in C it is not conventional to use "extern" when >>> > defining something, only on a declaration that is not a definition. >>> >>> But may it lead to some confusion or subtle error? It seems overly >>> pedantic to me if it is just a matter of style, because extern is >>> implicit if missing, >> >> "int i;" is not the same as "extern int i;". > > Sorry for my ignorance but I have been reading and searching for the > answer and I cannot tell what is the difference between "int i = 1" > and "extern int i = 1" at file-scope in C. > > Would you or someone else mind to point me out to the answer? Thanks in > advance. I suspect you wanted to know the difference between const int i; and extern const int; at file scope. > > Manuel. >
Re: gcc-in-cxx update
On Wed, Apr 29, 2009 at 10:54 AM, Manuel López-Ibáñez wrote: > 2009/4/29 Joseph S. Myers : >> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: >> >>> 2009/4/29 Joseph S. Myers : >>> > On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote: >>> > >>> >> >> BTW, why is this warned about? >>> >> > >>> >> > I imagine because in C it is not conventional to use "extern" when >>> >> > defining something, only on a declaration that is not a definition. >>> >> >>> >> But may it lead to some confusion or subtle error? It seems overly >>> >> pedantic to me if it is just a matter of style, because extern is >>> >> implicit if missing, >>> > >>> > "int i;" is not the same as "extern int i;". >>> >>> Sorry for my ignorance but I have been reading and searching for the >>> answer and I cannot tell what is the difference between "int i = 1" >>> and "extern int i = 1" at file-scope in C. >> >> I did not say those were different, I said the uninitialized case was >> different, so "extern is implicit if missing" is not a general C rule. > > OK, then. I assumed that we were discussing about the initialized > case, which is the origin of this thread. Hence, my suggestion stands: > get rid of the warning. I do not follow your reasoning here. BTW, I already the history of the warning. -- Gaby
Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)
On Thu, Apr 30, 2009 at 6:54 AM, Eus wrote: > Hi Ho! > > Sorry, if I sort of hijack this thread. > > On Wed, 2009-04-29 at 15:43 +, Joseph S. Myers wrote: > >> > > "int i;" is not the same as "extern int i;". >> > >> > Sorry for my ignorance but I have been reading and searching for the >> > answer and I cannot tell what is the difference between "int i = 1" >> > and "extern int i = 1" at file-scope in C. >> >> I did not say those were different, I said the uninitialized case was >> different, so "extern is implicit if missing" is not a general C rule. > > I think the difference between "int i;" and "extern int i;" at > file-scope in C is that "int i;" will only be treated as a definition if > it is not defined in another place in the same file/TU. IOW, its linkage > is internal within the TU itself. But, "extern int i" is definitely > treated as a declaration only that can later be defined either in the > same TU or in another one. > > Is that true? Yes. C has the notion of tentative definition and C++ does not. I.e. in C, int i; is a tentative definition of 'i'; in C++ it is a definition -- so cannot be repeated.
