Re: Rename C files to .c in GCC source

[John Marino]

On 1/31/2015 02:55, Jonathan Wakely wrote:
> On 30 January 2015 at 21:39, DJ Delorie wrote:
>>
>> pins...@gmail.com writes:
>>> No because they are c++ code so capital C is correct.
>>
>> However, we should avoid relying on case-sensitive file systems
>> (Windows) and use .cc or .cxx for C++ files ("+" is not a valid file
>> name character on Windows, so we can't use .c++).
> 
> These files are only compiled by GCC's own build system, with GCC's
> own makefiles, so we know we invoke the C++ compiler and so the
> language isn't inferred from the file extension, and so we aren't
> relying on case-sensitive file systems.

To give a counter-perspective, having files that need to be compiled
with c++ driver having the extension ".c" gives external build systems
fits.  Case in point, I'm working on bringing gcc5 into DragonFly as a
next base compiler and the make's base scripts all immediately use the c
driver for c files -- I had to apply hacks everywhere and even create
new local equivalents of "bsd.*.mk" files in some cases.  (vendor
makefiles are never used by policy, new "bmake" ones have to be created
and imported -- this seems to be common to all BSD)

Even if this issue is normally hidden due to gcc's makefiles accounting
for it, having misleading file names can only cause problems.I'll
add a "+1" to the suggestion to go rename everything consistently and
accurately.

Sorry about butting in, but I thought that my recent experience with
this might be relevant to the topic.

John

Re: Rename C files to .c in GCC source

[Andreas Schwab]

John Marino  writes:

> Even if this issue is normally hidden due to gcc's makefiles

There are no makefiles involved.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Rename C files to .c in GCC source

[Florian Weimer]

* DJ Delorie:

> pins...@gmail.com writes:
>> No because they are c++ code so capital C is correct. 
>
> However, we should avoid relying on case-sensitive file systems
> (Windows) and use .cc or .cxx for C++ files

Aren't current Windows file systems case-preserving?  Then they
shouldn't have no problems with .C files.

Re: Rename C files to .c in GCC source

[Mikhail Maltsev]

31.01.2015 14:10, Florian Weimer writes:
> Aren't current Windows file systems case-preserving?  Then they 
> shouldn't have no problems with .C files.

They are, but with some limitations: you can't create two files with
names differing only by case. I didn't try API functions, but here is
how it looks like in command line.

Linux:
$ touch a
$ touch A
$ touch B
$ ls
a  A  B

Cygwin (Windows 8.1, x64, NTFS):
$ touch a
$ touch A
$ touch B
$ ls
a  B

Windows command prompt (on same system):
>echo 1 > a
>echo 1 > A
>echo 1 > B
>dir
(several non-relevant lines omitted)
31.01.2015  14:58 4 a
31.01.2015  14:58 4 B

Renaming does work:

Cygwin:
$ mv ./a ./A
$ ls
A  B

Native:
>rename a A
>dir
(...)
31.01.2015  14:58 4 A
31.01.2015  14:58 4 B

-- 
Regards,
Mikhail Maltsev

Re: Rename C files to .c in GCC source

[DJ Delorie]

> Aren't current Windows file systems case-preserving?  Then they
> shouldn't have no problems with .C files.

They are case preserving, but not case sensitive.  A wildcard search
for *.c will match foo.C and bar.c, and foo.c can be opened as FOO.C.

Re: Rename C files to .c in GCC source

[Kevin Ingwersen (Ingwie Phoenix)]

> Am 31.01.2015 um 21:21 schrieb DJ Delorie :
> 
> 
>> Aren't current Windows file systems case-preserving?  Then they
>> shouldn't have no problems with .C files.
> 
> They are case preserving, but not case sensitive.  A wildcard search
> for *.c will match foo.C and bar.c, and foo.c can be opened as FOO.C.
That also applies to OS X:

$ head -n 1 build.it
/**
$ head -n 1 BUILD.IT
/**
$ head -n 1 BuIlD.iT
/**

gcc rodata regression

[Simon Glass]

Hi,

I have been fighting with a strange problem on ARM where gcc puts all
the .rodata from a number of files lumped into a single .rodata
section even when -fdata-sections is used.

I searched and found a bug report here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303

which exactly describes the problem I see.

According to the bug report this does not happen on x86_64, and there
is a test case provided.

Does anyone have any clues as to how to fix this bug? I am willing to
give it a try with a few pointers. I currently have to add loads of
#ifdefs in the C code to work around this bug and remove the unwanted
and unreferenced data.

Thanks,
Simon