Matthias Kretz writes:
> Richard and Jonathan don't like it - or doubt its effectiveness.
>
> Ian supports the idea. Jakub and Nathan mentioned that they already do
> something like it, so can I count that as "like"? :)
>
> Should I write a patch or not? How are the chances that it gets accepted
Hi,
On Thursday 26 May 2011 12:06:18 Matthias Kretz wrote:
> if you like the idea
Richard and Jonathan don't like it - or doubt its effectiveness.
Ian supports the idea. Jakub and Nathan mentioned that they already do
something like it, so can I count that as "like"? :)
Should I write a patch
On Fri, May 27, 2011 at 06:30:21AM -0700, Ian Lance Taylor wrote:
> Jonathan Wakely writes:
> > It's an additional maintenance burden.
>
> It's not a maintenance burden on gcc, though.
>
> I think we should have the gcc configure script provide a way to add a
> preprocessor macro.
FWIW, we decide
On 05/27/2011 11:33 AM, Matthias Kretz wrote:
True. Right now I'm forced to do this. But I know my users... have you seen
the typical physicist developing HPC software? ;)
Sure - I am one. I know what you refer to. That's why *I* install
versions of gcc/gfortran for them.
[ Famous quote o
Jonathan Wakely writes:
> It's an additional maintenance burden.
It's not a maintenance burden on gcc, though.
I think we should have the gcc configure script provide a way to add a
preprocessor macro. That would not be hard for somebody to implement
(perhaps Matthias), it should not pose a si
On Fri, May 27, 2011 at 11:46:27AM +0200, Richard Guenther wrote:
> At SUSE we didn't yet see a need for this kind of macro. Not sure
> what RedHat uses it for.
To make use of new features backported to older compilers.
E.g. our has:
/* GCC 4.3 and above allow passing all anonymous arguments of
On Fri, May 27, 2011 at 11:33 AM, Matthias Kretz
wrote:
> On Friday 27 May 2011 11:14:38 Richard Guenther wrote:
>> I know developing on the edge of what compilers support can be a PITA,
>> but it's more maintainable to have checks and workarounds in terms
>> of actual bugs than compiler versions.
On Friday 27 May 2011 11:14:38 Richard Guenther wrote:
> I know developing on the edge of what compilers support can be a PITA,
> but it's more maintainable to have checks and workarounds in terms
> of actual bugs than compiler versions.
Full ack.
> It should be relatively easy for
> you to provi
On Friday 27 May 2011 11:02:14 Jonathan Wakely wrote:
> It's an additional maintenance burden.
For packagers? They have all required version information in their own
packaging setups already. All they need to implement is a way to automatically
convert that into a configure switch. Once this is
On Fri, May 27, 2011 at 11:02 AM, Jonathan Wakely wrote:
> On 27 May 2011 09:46, Matthias Kretz wrote:
>>>
>>> The cases where you have to work around compiler issues in a
>>> _header_ file should be very rare.
>>
>> And? Because they are rare we shouldn't care? I'm developing a template
>> librar
On 27 May 2011 09:46, Matthias Kretz wrote:
>>
>> The cases where you have to work around compiler issues in a
>> _header_ file should be very rare.
>
> And? Because they are rare we shouldn't care? I'm developing a template
> library for SSE, AVX, LRBni, ... and this stuff is like daily bread for
On Thursday 26 May 2011 12:18:19 Richard Guenther wrote:
> On Thu, May 26, 2011 at 12:06 PM, Matthias Kretz wrote:
> > __GNUC_DISTRIBUTOR___
> > This macro is defined in releases of GCC that are prepared by entities
> > other than the FSF. The actual name of the macro depends on the value
> > set
On Thu, May 26, 2011 at 12:06:18PM +0200, Matthias Kretz wrote:
> suggested solution
> ==
> GCC should provide (an) additional predefined macro(s) to distinguish a
> patched GCC from vanilla GCC. This/These macro(s) should be sufficient to
> uniquely identify every released GCC fr
On Thu, May 26, 2011 at 12:06 PM, Matthias Kretz
wrote:
> Hi,
>
> Abstract :)
> ===
> A means to distinguish a patched GCC release from a vanilla GCC
> release should be added. This would enable developers to work
> around incompatibilities between GCC releases in public hea
Hi,
Abstract :)
===
A means to distinguish a patched GCC release from a vanilla GCC
release should be added. This would enable developers to work
around incompatibilities between GCC releases in public header
files. One macro, defined only by the respective distrib
15 matches
Mail list logo