On Tue, Oct 15, 2024 at 11:15 AM Kyrylo Tkachov via Gcc
wrote:
>
>
> > On 15 Oct 2024, at 18:09, Bryon Quackenbush via Gcc
> wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Does anyone know where in the GCC hierarchy that I can find
> implementation
> > code f
> On 15 Oct 2024, at 18:09, Bryon Quackenbush via Gcc wrote:
>
> External email: Use caution opening links or attachments
>
>
> Does anyone know where in the GCC hierarchy that I can find implementation
> code for standard C library functions like fgetc / fputs, etc, or would
> that be outsi
Does anyone know where in the GCC hierarchy that I can find implementation
code for standard C library functions like fgetc / fputs, etc, or would
that be outside the scope of GCC? I've been hunting around on the source
tree for the last few days and found the headers, but not the
implementation.
On 10/19/22 04:40, Jakub Jelinek wrote:
Hi!
The screw-up on my side with libstdc++ testing (tested normally rather
than in C++23 mode) makes me wonder if we couldn't tweak the default
testing.
Dunno what libstdc++ testing normally does (just C++17?), make check-g++
tests by default { 98, 14, 17,
On Wed, 19 Oct 2022 at 09:40, Jakub Jelinek wrote:
>
> Hi!
>
> The screw-up on my side with libstdc++ testing (tested normally rather
> than in C++23 mode) makes me wonder if we couldn't tweak the default
> testing.
> Dunno what libstdc++ testing normally does (just C++17?),
That's the default un
Hi!
The screw-up on my side with libstdc++ testing (tested normally rather
than in C++23 mode) makes me wonder if we couldn't tweak the default
testing.
Dunno what libstdc++ testing normally does (just C++17?), make check-g++
tests by default { 98, 14, 17, 20 } (and I regularly use
GXX_TESTSUITE_S
On 1/23/2015 10:59 AM, Jonathan Wakely wrote:
> On 23/01/15 10:53 -0600, Joel Sherrill wrote:
>> Is there a better way to automate a signature compliance? To tweak
>> what they have done?
> Testing member function signatures for compliance is inherently
> flawed, they just shouldn't do it.
>
> I w
On 23/01/15 10:53 -0600, Joel Sherrill wrote:
Is there a better way to automate a signature compliance? To tweak
what they have done?
Testing member function signatures for compliance is inherently
flawed, they just shouldn't do it.
I would say they should be testing that the function can be c
from the test code.
>> I don't know how long it has been deprecated since even with
>> -std=c++03, the warning is present.
> Those types were deprecated even in the first C++ standard in 1998.
> They were born deprecated, and have remained so ever since.
I don't mind the
++/ and they have their own ML.
Thank you.
That's deprecated, isn't it?
Yes. There is also a warning about that coming from the test code.
I don't know how long it has been deprecated since even with
-std=c++03, the warning is present.
Those types were deprecated even in the first
nsensus?
> The exact signature of member functions is not mandated by the standard,
> implementations are allowed to make the function const if that works (or
> provide both a const and a non-const version). Your code is not guaranteed
> to work. Lambdas usually provide a fine wo
On Thu, 22 Jan 2015, Joel Sherrill wrote:
I think this is a glibc issue but since this method is defined in the C++
standards, I thought there were plenty of language lawyers here. :)
s/glibc/libstdc++/ and they have their own ML.
That's deprecated, isn't it?
class strstreambuf : publ
Hi
I think this is a glibc issue but since this method is defined in the C++
standards, I thought there were plenty of language lawyers here. :)
class strstreambuf : public basic_streambuf >
ISSUE > int pcount() const; <= ISSUE
My reading of the C++03 and draft C++14 says that t
David Livshin <[EMAIL PROTECTED]> writes:
> I thought that "gcc" mailing list is appropriate as I need this
> information in order to implement auto-parallelizer for the
> gcc-generated code. How the gcc-supported parallelizer (
> "-ftree-parallelize-loops=n" ) treats the calls to library routines
Ian Lance Taylor wrote:
David Livshin <[EMAIL PROTECTED]> writes:
What functions from the GNU's C standard library ( libc ) are thread
safe? Of a particular interest are transcendental functions ( like
exp', 'sin' etc. ) - are they thread safe?
Are there a
David Livshin <[EMAIL PROTECTED]> writes:
> What functions from the GNU's C standard library ( libc ) are thread
> safe? Of a particular interest are transcendental functions ( like
> exp', 'sin' etc. ) - are they thread safe?
>
> Are there any requiremen
Hi,
What functions from the GNU's C standard library ( libc ) are thread
safe? Of a particular interest are transcendental functions ( like
'exp', 'sin' etc. ) - are they thread safe?
Are there any requirements/guidelines/assurances regarding thread safety
of func
On Wed, Nov 12, 2008 at 2:10 PM, Lawrence Crowl <[EMAIL PROTECTED]> wrote:
>
> Now would be a good time to mention Google's bit_cast<>.
And here is a simple portable implementation (still implementation
defined really) of that:
#include
template to bit_cast(from a)
{
int notthesamesize[sizeof(fr
On 11/12/08, James Dennett <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 12, 2008 at 11:29 AM, Joe Buck <[EMAIL PROTECTED]> wrote:
> > On Tue, Nov 11, 2008 at 08:43:40PM -0800, James Dennett wrote:
> >> (There are secondary uses of unions for type punning. Most such uses
> >> are not valid portable
On Wed, Nov 12, 2008 at 11:29 AM, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 11, 2008 at 08:43:40PM -0800, James Dennett wrote:
>> (There are secondary uses of unions for type punning. Most such uses
>> are not valid portable C++, but g++ supports them because they're so
>> common in real c
On Tue, Nov 11, 2008 at 08:43:40PM -0800, James Dennett wrote:
> (There are secondary uses of unions for type punning. Most such uses
> are not valid portable C++, but g++ supports them because they're so
> common in real code.)
On the contrary: the uses of unions for type-punning, while not port
On Wed, Nov 12, 2008 at 12:53:54PM +1000, Mark Tall wrote:
> Hello,
>
> I've come across an oddity in C++, involving anonymous unions and
> const variables. Neither of the two classes below will compile using
> gcc 4.3.0. Is this a bug in gcc or the C++ standard itself ?
&
On 11/12/08, René Bürgel <[EMAIL PROTECTED]> wrote:
> Mark Tall schrieb:
> > On 12/11/2008, René Bürgel <[EMAIL PROTECTED]> wrote:
> > > If all members of the union are const, why don't you just
> > > make the union itself const?
> >
> > The const for the union seems to be ignored
>
> I'd say, that
Mark Tall schrieb:
On 12/11/2008, René Bürgel <[EMAIL PROTECTED]> wrote:
If all members of the union are const, why don't you just make the union
itself const?
The const for the union seems to be ignored
I'd say, that's the real bug, at least from my point of view. I don't
know, if t
On 12/11/2008, René Bürgel <[EMAIL PROTECTED]> wrote:
> If all members of the union are const, why don't you just make the union
> itself const?
The const for the union seems to be ignored (code below). The
original reason behind the union shenanigans was to provide a
compile-time alias to anothe
If all members of the union are const, why don't you just make the union
itself const?
class my_class_2
{
const union
{
int x;
int y;
};
my_class_2() : x(0) {}
};
--
René Bürgel
Software Engineer
Unicontrol Systemtechnik GmbH
OT Dittersbach
Sachsenburger Weg 34
09669 Frankenbe
On 11/11/08, James Dennett <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 11, 2008 at 8:04 PM, Mark Tall <[EMAIL PROTECTED]> wrote:
> > On 12/11/2008, James Dennett <[EMAIL PROTECTED]> wrote:
> > > In a union only one field can be active at one time, hence
> > > initializing more than one makes no sense
On Tue, Nov 11, 2008 at 8:04 PM, Mark Tall <[EMAIL PROTECTED]> wrote:
> On 12/11/2008, James Dennett <[EMAIL PROTECTED]> wrote:
>> In a union only one field can be active at one time, hence
>> initializing more than one makes no sense
>> ...
>> However, const items need to be initialized, hence pot
On 12/11/2008, James Dennett <[EMAIL PROTECTED]> wrote:
> In a union only one field can be active at one time, hence
> initializing more than one makes no sense
> ...
> However, const items need to be initialized, hence potting two in a
> union makes no sense.
Conceptually there is nothing wrong w
On Tue, Nov 11, 2008 at 6:53 PM, Mark Tall <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've come across an oddity in C++, involving anonymous unions and
> const variables. Neither of the two classes below will compile using
> gcc 4.3.0. Is this a bug in gcc or the
Hello,
I've come across an oddity in C++, involving anonymous unions and
const variables. Neither of the two classes below will compile using
gcc 4.3.0. Is this a bug in gcc or the C++ standard itself ?
class my_class_1
{
union
{
const int x;
const int y;
};
my_cl
Elmar Krieger writes:
>
> I searched hard, but couldn't determine conclusively if the C standard
> allows to alias a void* pointer with a char* pointer.
>
> If that's not undefined behavior, then the following may be a glitch in
> GCC 4.1.0 when compiled with
On 7/1/06, Elmar Krieger <[EMAIL PROTECTED]> wrote:
I searched hard, but couldn't determine conclusively if the C standard
allows to alias a void* pointer with a char* pointer.
Search in the GCC documentation, under -fstrict-aliasing:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/g
Hi GCClers,
I searched hard, but couldn't determine conclusively if the C standard
allows to alias a void* pointer with a char* pointer.
If that's not undefined behavior, then the following may be a glitch in
GCC 4.1.0 when compiled with -O2.
Here's the ugly minima
On Wed, Apr 26, 2006 at 12:19:29PM +0100, Lee Millward wrote:
> To answer the first part of your question here's an extract from
> http://gcc.gnu.org/bugs.html#known
>
> "The export keyword is not implemented."
> ...
> As for other unimplemented features I'll have to leave that to someone
> else
To answer the first part of your question here's an extract from
http://gcc.gnu.org/bugs.html#known
"The export keyword is not implemented.
Most C++ compilers (G++ included) do not yet implement export, which
is necessary for separate compilation of template declarations and
definitions. Without
Hi
I was trying to find out if gcc implements 'export' for templates (I don't
think so). The obvious page to look would be
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Standards.html#Standards
but that doesn't mention c++ at all (only C, Objective C and a link about
fortran).
Is such documentatio
On 2/6/06, Ryan Mansfield <[EMAIL PROTECTED]> wrote:
>
> > Couldn't find anything on it in bugzilla, and I don't think it's worth
> > the effort. IIRC, Herb Sutter and another guy spent 6 months to get it
> > right in the EDG front end (and Herb originally wanted to throw export
> > for templates o
Ryan Mansfield <[EMAIL PROTECTED]> writes:
| > and that paper was debunked when it was presented at the ISO C++
| > committee in April 2003 at Oxford, UK. EDG is very willing to give
| > advice (based on their experience) to anyone interested in
| > implementing export in, say GCC. (They want to
> and that paper was debunked when it was presented at the ISO C++
> committee in April 2003 at Oxford, UK. EDG is very willing to give
> advice (based on their experience) to anyone interested in
> implementing export in, say GCC. (They want to see the best
> implementation of export for C++.)
>
Ryan Mansfield <[EMAIL PROTECTED]> writes:
| > Couldn't find anything on it in bugzilla, and I don't think it's worth
| > the effort. IIRC, Herb Sutter and another guy spent 6 months to get it
| > right in the EDG front end (and Herb originally wanted to throw export
| > for templates out of the s
> Couldn't find anything on it in bugzilla, and I don't think it's worth
> the effort. IIRC, Herb Sutter and another guy spent 6 months to get it
> right in the EDG front end (and Herb originally wanted to throw export
> for templates out of the standard alltogether).
>
> --
> Tarjei
The impleme
; >> couldn't find any other.
> >> In the manual pages I couldn't find the information whether GCC
> >> supports
> >> the ISO C++ standard as described in ISO/IEC 14882.
> >> E. g. does it support export templates?
> >
> > GCC
the ISO C++ standard as described in ISO/IEC 14882.
E. g. does it support export templates?
GCC attempts to support the ISO C++ standard; however, one major
feature
is missing, namely export templates.
Otherwise, support is fairly complete, though there are known bugs.
Are these limitations (o
On Fri, Feb 03, 2006 at 07:56:23PM +0100, andrzej wrote:
> Hello,
>
> I am sorry if this is the wrong address for tihis question, but I
> couldn't find any other.
> In the manual pages I couldn't find the information whether GCC supports
> the ISO C++ standard as des
Hello,
I am sorry if this is the wrong address for tihis question, but I
couldn't find any other.
In the manual pages I couldn't find the information whether GCC supports
the ISO C++ standard as described in ISO/IEC 14882.
E. g. does it support export templates?
Regards,
Andrzej K
> From: Georg Bauhaus <[EMAIL PROTECTED]>
> 2) if putting local variables in registers becomes impossible
> there will be a significant cost. I wanted to get an impression
> of the cost. That's the reason for writing volatile in the
> declaration lines. Just for demo.)
I believe that was jus
Paul Schlie wrote:
From: Georg Bauhaus <[EMAIL PROTECTED]>
Paul Schlie wrote:
From: Robert Dewar <[EMAIL PROTECTED]>
this would mean you could not put local variables in
registers. the effect on code quality woul be awful!
Why would anyone care about the perform
Dave Korn wrote:
You can have both, correctness and uninitialised local
variables. For an impression of the difference in performance,
and for a way to ensure correctness, I tried this
(switch register/volatile in the declaration lines in comp
and r to see the effects).
I didn't get that
> From: Georg Bauhaus <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>>> From: Robert Dewar <[EMAIL PROTECTED]>
Paul Schlie wrote:
I don't contest that it may, I simply don't believe it should.
>>> you can't seriously mean that with respect to uninitialized
>>> variables. this would mean you c
Original Message
>From: Georg Bauhaus
>Sent: 15 July 2005 14:21
> You can have both, correctness and uninitialised local
> variables. For an impression of the difference in performance,
> and for a way to ensure correctness, I tried this
> (switch register/volatile in the declaration lines
Georg Bauhaus wrote:
(There are at least two bugs in this :-/ but corrections
won't change the picture. Neither will initialisation.)
#define BUFFER_SIZE 1000 // must be > 0
#define ITERATIONS 10 // must be > 0
assert(hi > 0);
for (size_t c=0; c < hi + 2; ++c) {
if (a[c]) {
Paul Schlie wrote:
From: Robert Dewar <[EMAIL PROTECTED]>
Paul Schlie wrote:
I don't contest that it may, I simply don't believe it should.
you can't seriously mean that with respect to uninitialized
variables. this would mean you could not put local variables in
registers. the effect on c
Paul Schlie wrote:
In that case you may want to stick with -O0. There are *lots* of
things GCC does that alter undefined cases. How about the undefined
behavior when aliasing rules are violated? Would you want to make
-fno-strict-aliasing be the only supported setting?
- Isn't the purp
> From: Paul Koning <[EMAIL PROTECTED]>
>> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes:
>>> From: Robert Dewar <[EMAIL PROTECTED]>
Paul Schlie wrote:
> What about optimising x*2/2 to x?
Given that "C" requires the above be evaluated as (x*2)/2, as the
language specifies
> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes:
>> From: Robert Dewar <[EMAIL PROTECTED]>
>>> Paul Schlie wrote:
What about optimising x*2/2 to x?
>>> Given that "C" requires the above be evaluated as (x*2)/2, as the
>>> language specifies that the syntax defines the precedence o
> From: Robert Dewar <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>
>> I don't contest that it may, I simply don't believe it should.
>
> you can't seriously mean that with respect to uninitialized
> variables. this would mean you could not put local variables in
> registers. the effect on code qual
Paul Schlie wrote:
I don't contest that it may, I simply don't believe it should.
you can't seriously mean that with respect to uninitialized
variables. this would mean you could not put local variables in registers.
the effect on code quality woul be awful!
> From: Robert Dewar <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>>> What about optimising x*2/2 to x?
>>
>> Given that "C" requires the above be evaluated as (x*2)/2, as the language
>> specifies that the syntax defines the precedence of the operations, and that
>> no optimization should alter the
Paul Schlie wrote:
What about optimising x*2/2 to x?
Given that "C" requires the above be evaluated as (x*2)/2, as the language
specifies that the syntax defines the precedence of the operations, and that
no optimization should alter the behavior as specified by the program; I'd
say that unle
> Matthew Woodcraft writes:
>> Paul Schlie wrote:
>>As optimization seems to be a non-argument, as by analogy all
>>optimizations which are available for unsigned arithmetic are
>>correspondingly available for signed integer operations; as any signed
>>value may then be thought of as being unsigned
> "Matthew" == Matthew Woodcraft <[EMAIL PROTECTED]> writes:
Matthew> Paul Schlie wrote:
>> As optimization seems to be a non-argument, as by analogy all
>> optimizations which are available for unsigned arithmetic are
>> correspondingly available for signed integer operations; as any
>>
Paul Schlie wrote:
>As optimization seems to be a non-argument, as by analogy all
>optimizations which are available for unsigned arithmetic are
>correspondingly available for signed integer operations; as any signed
>value may then be thought of as being unsigned for the purposes of
>computation a
> From: Robert Dewar <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>> Although I don't intend to extend the debate; doesn't anyone find it curious
>> that given this hard requirement, combined with the fact that all current
>> machine architectures rely on 2's complement signed integer representation
>
Paul Schlie wrote:
Although I don't intend to extend the debate; doesn't anyone find it curious
that given this hard requirement, combined with the fact that all current
machine architectures rely on 2's complement signed integer representation
to eliminate the otherwise necessity for distinct s
> " ... A computation involving unsigned operands can never overflow, because
> a result that cannot be represented by the resulting unsigned integer type
> is reduced modulo the number that is one greater than the largest value that
> can be represented by the resulting type."
Although I don't i
On Mon, Jul 11, 2005 at 09:58:36AM -0500, Nicholas Nethercote wrote:
> Hi,
>
> There was recently a very long thread about the overflow behaviour of
> signed integers in C. Apparently this is undefined according to the C
> standard. I searched the standard on this matter, and w
Original Message
>From: Nicholas Nethercote
>Sent: 11 July 2005 17:08
> On Mon, 11 Jul 2005, Dave Korn wrote:
>
>>> There was recently a very long thread about the overflow behaviour of
>>> signed integers in C. Apparently this is undefined according to t
On Mon, 11 Jul 2005, Dave Korn wrote:
There was recently a very long thread about the overflow behaviour of
signed integers in C. Apparently this is undefined according to the C
standard. I searched the standard on this matter, and while I did find
some paragraphs that described how unsigned
Original Message
>From: Nathan Sidwell
>Sent: 11 July 2005 16:15
> c99 6.5 para 5 (overflow is undefined)
Have I got an old draft or something, or is that the paragraph that begins
"If an _exceptional_ _condition_ occurs ..." ?
> I cannot find, in c99, a statement that all unsigned ar
On Monday 11 July 2005 15:58, Nicholas Nethercote wrote:
> Also, does anyone know what the required behaviour for Fortran integers is
> on overflow?
Section 7.1.7 "Evaluation of operation"
"The evaluation of any numeric operation whose result is not defined by the
arithmetic used by the processo
Nicholas Nethercote wrote:
Hi,
There was recently a very long thread about the overflow behaviour of
signed integers in C. Apparently this is undefined according to the C
standard. I searched the standard on this matter, and while I did find
some paragraphs that described how unsigned
Original Message
>From: Nicholas Nethercote
>Sent: 11 July 2005 15:59
> Hi,
>
> There was recently a very long thread about the overflow behaviour of
> signed integers in C. Apparently this is undefined according to the C
> standard. I searched the standard on thi
Hi,
There was recently a very long thread about the overflow behaviour of
signed integers in C. Apparently this is undefined according to the C
standard. I searched the standard on this matter, and while I did find
some paragraphs that described how unsigned integers must wrap around upon
74 matches
Mail list logo
