Correct me if I am wrote, but shouldn't sys_externlist be only declared in one .c file? Its declared like this in s_stuff.h:
(line 24) extern t_namelist *sys_externlist;
Then like this is s_path.c:
(line 33) t_namelist *sys_externlist;
And a duplicate in s_main.c:
(line 48) t_namelist *sys_externlist;
Both s_path.c and s_main.c include s_stuff.h and they are ultimately linked into the same binary, so that means that they are duplicates. I am surprised that the linker only sometimes complains about this.
.hc
------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
It's a mistake... I think the one in s_main.c should go. C code since the 70s (at least) has allowed duplicate definitions of uninitialzed data, but everyone knows it's wrong :)
M
On Sun, Dec 17, 2006 at 07:39:48PM -0500, Hans-Christoph Steiner wrote:
Correct me if I am wrote, but shouldn't sys_externlist be only declared in one .c file? Its declared like this in s_stuff.h:
(line 24) extern t_namelist *sys_externlist;
Then like this is s_path.c:
(line 33) t_namelist *sys_externlist;
And a duplicate in s_main.c:
(line 48) t_namelist *sys_externlist;
Both s_path.c and s_main.c include s_stuff.h and they are ultimately linked into the same binary, so that means that they are duplicates. I am surprised that the linker only sometimes complains about this.
.hc
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Sun, 17 Dec 2006, Miller Puckette wrote:
It's a mistake... I think the one in s_main.c should go. C code since the 70s (at least) has allowed duplicate definitions of uninitialzed data, but everyone knows it's wrong :)
It's not C that allows it, it's the linker and the concept of separate compilation. It's a feature that comes from assembly language. I can't see that feature really going away with any new standard of the C language because it's just not something specified by that spec.
(ok, I'm not 100% sure on that)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 18, 2006, at 8:09 AM, Mathieu Bouchard wrote:
On Sun, 17 Dec 2006, Miller Puckette wrote:
It's a mistake... I think the one in s_main.c should go. C code since the 70s (at least) has allowed duplicate definitions of uninitialzed data, but everyone knows it's wrong :)
It's not C that allows it, it's the linker and the concept of separate compilation. It's a feature that comes from assembly language. I can't see that feature really going away with any new standard of the C language because it's just not something specified by that spec.
(ok, I'm not 100% sure on that)
I think that -fstrict-aliasing disallows that. Or at least something that is enabled when turning on all the optimization options.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 18, 2006, at 8:09 AM, Mathieu Bouchard wrote:
It's not C that allows it, it's the linker and the concept of separate compilation. It's a feature that comes from assembly language. I can't see that feature really going away with any new standard of the C language because it's just not something specified by that spec.
I think that -fstrict-aliasing disallows that. Or at least something that is enabled when turning on all the optimization options.
I think that it doesn't disallow it, and it's because I've just tried it, and I don't even get a warning, with every possible combination of -fstrict-aliasing -Wall at every compilation step.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 18, 2006, at 3:42 PM, Mathieu Bouchard wrote:
On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 18, 2006, at 8:09 AM, Mathieu Bouchard wrote:
It's not C that allows it, it's the linker and the concept of separate compilation. It's a feature that comes from assembly language. I can't see that feature really going away with any new standard of the C language because it's just not something specified by that spec.
I think that -fstrict-aliasing disallows that. Or at least something that is enabled when turning on all the optimization options.
I think that it doesn't disallow it, and it's because I've just tried it, and I don't even get a warning, with every possible combination of -fstrict-aliasing -Wall at every compilation step.
FWIW, using these flags, the linker complains:
-ftree-vectorize -ftree-vectorizer-verbose=3 -fast -fPIC -mcpu=7450 - mtune=7450
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 18, 2006, at 3:42 PM, Mathieu Bouchard wrote:
I think that it doesn't disallow it, and it's because I've just tried it,
and I don't even get a warning, with every possible combination of -fstrict-aliasing -Wall at every compilation step.
FWIW, using these flags, the linker complains: -ftree-vectorize -ftree-vectorizer-verbose=3 -fast -fPIC -mcpu=7450 -mtune=7450
neither -fast nor the 7450 cpu are supported in the GCC I have, an Ubuntu i386 that comes with GCC 4.0.3. With the rest of the options, it doesn't complain.
But then, if you're on OSX... OSX doesn't use ELF. It can very well be not the same as Linux in that situation.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 18, 2006, at 6:43 PM, Mathieu Bouchard wrote:
On Mon, 18 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 18, 2006, at 3:42 PM, Mathieu Bouchard wrote:
I think that it doesn't disallow it, and it's because I've just tried it,
and I don't even get a warning, with every possible combination of -fstrict-aliasing -Wall at every compilation step.
FWIW, using these flags, the linker complains: -ftree-vectorize -ftree-vectorizer-verbose=3 -fast -fPIC - mcpu=7450 -mtune=7450
neither -fast nor the 7450 cpu are supported in the GCC I have, an Ubuntu i386 that comes with GCC 4.0.3. With the rest of the options, it doesn't complain.
But then, if you're on OSX... OSX doesn't use ELF. It can very well be not the same as Linux in that situation.
-fast is a shortcut for:
-O3 -falign-loops-max-skip=15 -falign-jumps-max-skip=15 -falign-loops=16 -falign-jumps=16 -falign-functions=16 - malign-nat- ural (except when -fastf is specified) -ffast-math - funroll-loops -ftree-loop-linear -ftree-loop-memset -mcpu=G5 -mpowerpc- gpopt -mtune=G5 (unless -mtune=G4 is specified). -fsched- interblock -fgcse-sm -mpowerpc64 .hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
-
Hans-Christoph Steiner -
Mathieu Bouchard -
Miller Puckette