> Am 31.01.2015 um 02:57 schrieb Jonathan Wakely :
>
> On 30 January 2015 at 22:24, Kevin Ingwersen (Ingwie Phoenix) wrote:
>> Apple’s HFS is, on a default OS X install, case insensitive.
>
> Which doesn't matter, see my previous reply.
That is true; though its good to keep an eye out for it.
>
On 30 January 2015 at 22:24, Kevin Ingwersen (Ingwie Phoenix) wrote:
> Apple’s HFS is, on a default OS X install, case insensitive.
Which doesn't matter, see my previous reply.
> But .c++ is valid. .cxx sounds pretty straight forward to me, since people
> also use the $CXX variable.
We already
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 Window
> Am 30.01.2015 um 22:39 schrieb 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 ("+" is not a valid file
> name character on
> Am 30.01.2015 um 21:30 schrieb Jonny Grant :
>
>
>
> On 30/01/15 17:09, pins...@gmail.com wrote:
>>
>>
>>
>>
>>> On Jan 30, 2015, at 4:22 AM, Jonny Grant wrote:
>>>
>>> Hello
>>>
>>> When I checked out from the trunk I saw that various files had .C
>>> capital extension. Its not a big
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++).
On 30/01/15 17:09, pins...@gmail.com wrote:
On Jan 30, 2015, at 4:22 AM, Jonny Grant wrote:
Hello
When I checked out from the trunk I saw that various files had .C
capital extension. Its not a big issue.. but I wondered if they should
be .c like regular source files?
No because they a
> On Jan 30, 2015, at 4:22 AM, Jonny Grant wrote:
>
> Hello
>
> When I checked out from the trunk I saw that various files had .C
> capital extension. Its not a big issue.. but I wondered if they should
> be .c like regular source files?
No because they are c++ code so capital C is correct.
Hi,
On Fri, 30 Jan 2015, Tom de Vries wrote:
> > Maybe you want to pick up the work?
>
> In principle yes, depending on the amount of work (at this point I have no
> idea what remains to be done and how long that would take me).
>
> Michael, are your patches posted somewhere?
I don't think I e
Hello All
(sorry for the self-promotion)
I'm giving tomorrow january 31st 2015, at FOSDEM2015 (Lisp Dev Room) an
hour talk about GCC MELT
MELT is a Lispy domain specific language (implemented as a
GPLv3+licensed, FSF copyrighted, meta-plugin for GCC) to extend and
customize the GCC compiler
Hello
When I checked out from the trunk I saw that various files had .C
capital extension. Its not a big issue.. but I wondered if they should
be .c like regular source files?
libitm\testsuite\libitm.c++\static_ctor.C
libitm\testsuite\libitm.c++\dropref.C
libitm\testsuite\libitm.c++\eh-1.C
libit
On 30/01/15 12:50, Jakub Jelinek wrote:
On Fri, Jan 30, 2015 at 12:14:26PM +0100, Sebastian Huber wrote:
>Hello,
>
>I would like to add support for libgomp for the RTEMS operating system. I
>likely cannot use the standard Pthread API for this in some places since I
>have to account for RTEMS spe
On Fri, Jan 30, 2015 at 12:14:26PM +0100, Sebastian Huber wrote:
> Hello,
>
> I would like to add support for libgomp for the RTEMS operating system. I
> likely cannot use the standard Pthread API for this in some places since I
> have to account for RTEMS specifics related to partitioned/clustere
Hello,
I would like to add support for libgomp for the RTEMS operating system.
I likely cannot use the standard Pthread API for this in some places
since I have to account for RTEMS specifics related to
partitioned/clustered scheduling and the priority based scheduler. If I
implement for exam
On 30-01-15 09:41, Richard Biener wrote:
I don't like adding more hacks to aid the stdarg pass.
It's not required
for GCC 5 anyway and for GCC 6 we should push the lowering change.
Richard,
I agree that that's the best solution (the posted patch is just a solution that
helps me along for now)
On 30 January 2015 at 07:23, Conrad S wrote:
> On 30 January 2015 at 16:58, James Dennett wrote:
>> It's hardly just a loophole: C++ doesn't specify the order of evaluation,
>> so the code is wrong (i.e., non-portable, as you've found).
>>
>> Arguably this is a design problem with IOStreams, given
On Thu, Jan 29, 2015 at 11:20 PM, Tom de Vries wrote:
> On 29-01-15 18:25, Jakub Jelinek wrote:
>>
>> The stdarg pass can't grok too heavy optimizations, so if at all possible,
>> don't schedule such passes early, and if you for some reason do, avoid
>> optimizing in there the va_list related acce
Yury Gribov writes:
> On 01/29/2015 08:32 PM, Richard Henderson wrote:
> > On 01/29/2015 02:08 AM, Paul Shortis wrote:
> >> I've ported GCC to a small 16 bit CPU that has single bit shifts. So
> >> I've handled variable / multi-bit shifts using a mix of inline shifts
> >> and calls to assembler su
18 matches
Mail list logo
