Re: gengtype installation in trunk?

[Romain Geissler]

Hi,

I don't understand, you supported my patch when i contributed it, which 
performs exactly what you want ! Gengtype and gtype.state get installed in the 
trunk for more than a month !

Romain.


Le 24 sept. 2011 à 17:09, Basile Starynkevitch a écrit :

> Hello All,
> 
> As you probably know, gengtype is useful for plugins, and they also need the 
> gtype.state
> file.
> 
> However, the current GCC trunk still don't seem to install it.
> 
> [several distributions, including Mandriva & Debian, are patching GCC for 
> that purpose]
> 
> And GCC installation procedure and gcc/Makefile.in really give me a headache, 
> and I don't
> understand enough of it to be able to propose an acceptable patch.
> 
> Could any knowledgable person help in that. I'm sure that for people really 
> understanding
> GCC building procedure (which I am not), proposing a patch to install 
> gengtype is even
> simpler than explaining how it should be done.
> 
> 
> I was told that for reasons I don't understand, gengtype would have to be 
> compiled twice
> (once in build and once in "host" mode, whatever that means exactly).
> 
> trunk is coming out of stage 1, and I am afraid that even gcc-4.7 won't have 
> gengtype
> installed.
> 
> Regards.
> 
> PS. I really cannot write a patch for that, I don't understand the makefile & 
> configure
> tricks enough. 
> 
> -- 
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***

Re: C99 Status - inttypes.h

[Joern Rennecke]

Quoting Gerald Pfeifer :


On Fri, 22 Jul 2011, Joern Rennecke wrote:

I agree that trying to track every library there would be a maintenance
burden, but giving one example of a library that works is meaningful.
And, since GCC is still a GNU project, mentioning the status of GNU libc
doesn't seem that arbitrary.


Can you propose a change along these lines?  I think it does make
sense, both to be more clear on what may be a (non-)issue and to
refer to GNU libc as a reference implementation where that makes
sense.


Attached.

Index: c99status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/c99status.html,v
retrieving revision 1.57
diff -p -r1.57 c99status.html
*** c99status.html  18 Mar 2011 17:47:35 -  1.57
--- c99status.html  25 Sep 2011 12:15:59 -
*** href="http://www.open-std.org/jtc1/sc22/
*** 13,19 
  (E), ISO/IEC 9899:1999/Cor.2:2004 (E) and ISO/IEC 9899:1999/Cor.3:2007
  (E)).
  
! Where "Library Issue" is listed in conjunction with some other
  status, this means that some compiler support is needed for the
  library support, or desirable in conjunction with it.  Note that the
  headers required of conforming freestanding implementations (clause 4
--- 13,23 
  (E), ISO/IEC 9899:1999/Cor.2:2004 (E) and ISO/IEC 9899:1999/Cor.3:2007
  (E)).
  
! "Library Issue" means that support may or may not be available depending
! on the C library used; for example, the GNU C library supports all C99
! features, provided _ISOC99_SOURCE and/or _GNU_SOURCE is defined in the
! source code or with a -D preprocessor flag.
! Where "Library Issue" is listed in conjunction with some other
  status, this means that some compiler support is needed for the
  library support, or desirable in conjunction with it.  Note that the
  headers required of conforming freestanding implementations (clause 4

Re: Volatile qualification on pointer and data

[David Brown]

On 24/09/2011 18:25, John Regehr wrote:

it. And while I think the compiler should be allowed to generate the
optimised code of 4.6 (i.e., the change is not a bug IMHO), I fully
understand the idea of generating the older, slower, but definitely
correct code of 4.5.


My understanding is that the standard mandates the old behavior, so 4.6
is in error.


I am still trying to imagine a real-world use-case for declaring an
object "static const" and later accessing it as "volatile".


Yeah, it would seem far clearer to declare it as static const volatile
in the first place.



I still can't think why one would ever want such a thing.

There is a big difference between defining an object as "const", and 
merely declaring it as const or accessing it as const.  When you access 
it as const, you are saying "/I/ won't change the object with this 
access".  When you declare an object as const (such as an extern 
object), you are saying "/I/ won't change this object".  When you 
/define/ an object as const, as you do with a "static const", you are 
saying "this object is constant.  It will never change value - you (the 
toolchain) can safely place it in read-only memory that cannot ever 
change value".


And then you make it volatile, telling the compiler "this object might 
change unexpectedly, or use values written to it unexpectedly".


If someone could explain to me how this could have real-world usage, I 
think it would be easier for me (and others) to be sure of what it 
really means.



I've done a bunch of automated testing of GCC's implementation of
volatile. None of that testing would have exposed this bug because we
only count acceses to objects declared as volatile.

I've come to the conclusion that "volatile" is a language design error.
It complicates the compiler implementation and has confusing,
underspecified semantics. If you want to force a load or store, an
explicit function call is a clearer way to do it.



I agree on that, as I think do many - "volatile" is not defined clearly 
enough.  It is also not flexible enough for optimal code generation in 
many cases when it is used regularly, such as for embedded programming. 
 There it is not uncommon to want something that has volatile write 
accesses, but does not need volatile read accesses.  It gets seriously 
messy when you combine "volatile" with bitfields - the standards are 
(AFAIK) unclear, and implementations of volatile bitfields vary wildly. 
 And since "volatile" does not have any interaction with things like 
cpu instruction re-ordering, speculative accesses, write buffering and 
combining, caches, etc., or with any operating system specific 
interactions, it often doesn't do what the user thinks it will do.


However, it is currently the only tool we have in C.

Re: gengtype installation in trunk?

[Basile Starynkevitch]

On Sun, 25 Sep 2011 14:00:03 +0200
Romain Geissler  wrote:

> Hi,
> 
> I don't understand, you supported my patch when i contributed it, which 
> performs exactly what you want ! Gengtype and gtype.state get installed in 
> the trunk for more than a month !


Sorry for the noise. Yes, gengtype is installed now. I looked too quickly in the
gcc/Makefile.in.

Cheers.


-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Volatile qualification on pointer and data

[Andreas Schwab]

David Brown  writes:

> There is a big difference between defining an object as "const", and
> merely declaring it as const or accessing it as const.  When you access it
> as const, you are saying "/I/ won't change the object with this access".
> When you declare an object as const (such as an extern object), you are
> saying "/I/ won't change this object".  When you /define/ an object as
> const, as you do with a "static const", you are saying "this object is
> constant.  It will never change value - you (the toolchain) can safely
> place it in read-only memory that cannot ever change value".

You are interpreting too much into const here.  The C standard says in
footnote 112: "The implementation may place a const object that is not
volatile in a read-only region of storage."  Note the use of "not
volatile".  But in any case this is not part of the C standard: it's
only a footnote.

> And then you make it volatile, telling the compiler "this object might
> change unexpectedly, or use values written to it unexpectedly".
>
> If someone could explain to me how this could have real-world usage, I
> think it would be easier for me (and others) to be sure of what it really
> means.

It's an object that is never written to, but may change unexpectedly.

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: Volatile qualification on pointer and data

[Dave Korn]

On 25/09/2011 13:56, David Brown wrote:

> There is a big difference between defining an object as "const", and
> merely declaring it as const or accessing it as const.  When you access
> it as const, you are saying "/I/ won't change the object with this
> access".  When you declare an object as const (such as an extern
> object), you are saying "/I/ won't change this object".  When you
> /define/ an object as const, as you do with a "static const", you are
> saying "this object is constant.  It will never change value - you (the
> toolchain) can safely place it in read-only memory that cannot ever
> change value".
> 
> And then you make it volatile, telling the compiler "this object might
> change unexpectedly, or use values written to it unexpectedly".
> 
> If someone could explain to me how this could have real-world usage, I
> think it would be easier for me (and others) to be sure of what it
> really means.

  Just because it's static doesn't mean the address can't escape:

/* May read or write to dest, according to direction flag.  */
extern void start_dma_xfer (void *dest, unsigned int size, bool direction,
uint64_t bus_addr);

/* We don't want to change this ourselves, and nor do we want the symbol
   to be externally visible.  */
static const volatile char *dma_buffer[BUFFERSIZE];

[ ... later, in a function ... ]

  start_dma_transfer (&dma_buffer[0], size, DIRECTION_DMA_TO_MEMORY, devaddr);


  A bit contrived perhaps, but start_dma_transfer (or some similar function)
might be part of the OS or written in assembly and so necessarily C-type-safe.

cheers,
  DaveK

Re: Volatile qualification on pointer and data

[David Brown]

On 25/09/11 16:16, Andreas Schwab wrote:

David Brown  writes:


There is a big difference between defining an object as "const", and
merely declaring it as const or accessing it as const.  When you access it
as const, you are saying "/I/ won't change the object with this access".
When you declare an object as const (such as an extern object), you are
saying "/I/ won't change this object".  When you /define/ an object as
const, as you do with a "static const", you are saying "this object is
constant.  It will never change value - you (the toolchain) can safely
place it in read-only memory that cannot ever change value".


You are interpreting too much into const here.  The C standard says in
footnote 112: "The implementation may place a const object that is not
volatile in a read-only region of storage."  Note the use of "not
volatile".  But in any case this is not part of the C standard: it's
only a footnote.



I stand corrected on that point - thanks.


And then you make it volatile, telling the compiler "this object might
change unexpectedly, or use values written to it unexpectedly".

If someone could explain to me how this could have real-world usage, I
think it would be easier for me (and others) to be sure of what it really
means.


It's an object that is never written to, but may change unexpectedly.



Again, I can see that "volatile const" is useful for declaring external 
objects (or accesses to objects), but not when the address of the object 
is allocated by the toolchain (as is the case here with a "static const 
volatile".


The only scenario I have heard where this might be useful is for 
debugging - making what is normally a "static const" volatile so that 
it's value can be changed with a debugger.  Personally, I think that in 
such cases you would be better removing the "const" when you add the 
"volatile".

Re: Volatile qualification on pointer and data

[David Brown]

On 25/09/11 17:15, Dave Korn wrote:

On 25/09/2011 13:56, David Brown wrote:


There is a big difference between defining an object as "const", and
merely declaring it as const or accessing it as const.  When you access
it as const, you are saying "/I/ won't change the object with this
access".  When you declare an object as const (such as an extern
object), you are saying "/I/ won't change this object".  When you
/define/ an object as const, as you do with a "static const", you are
saying "this object is constant.  It will never change value - you (the
toolchain) can safely place it in read-only memory that cannot ever
change value".

And then you make it volatile, telling the compiler "this object might
change unexpectedly, or use values written to it unexpectedly".

If someone could explain to me how this could have real-world usage, I
think it would be easier for me (and others) to be sure of what it
really means.


   Just because it's static doesn't mean the address can't escape:

/* May read or write to dest, according to direction flag.  */
extern void start_dma_xfer (void *dest, unsigned int size, bool direction,
 uint64_t bus_addr);

/* We don't want to change this ourselves, and nor do we want the symbol
to be externally visible.  */
static const volatile char *dma_buffer[BUFFERSIZE];

[ ... later, in a function ... ]

   start_dma_transfer (&dma_buffer[0], size, DIRECTION_DMA_TO_MEMORY, devaddr);


   A bit contrived perhaps, but start_dma_transfer (or some similar function)
might be part of the OS or written in assembly and so necessarily C-type-safe.

 cheers,
   DaveK




I can see that as a possibility, though to me it reads as bad style. 
I'm aware that taking the address of a static object can let it 
"escape", and mentioned that possibility in other posts - it will 
certainly force the object to be created in memory.  However, I just 
don't see why a buffer like this would be defined "const" - it's not 
constant, so what are you trying to achieve by saying "const"?


To answer that, you have to first say /why/ anyone would use the "const" 
qualifier in the first place.  There are five reasons I can think of. 
First, you have compatibility with other code and types.  Then you have 
error-checking - if you know you will not change an object, you make it 
"const" to let the compiler check that you haven't changed it by 
mistake.  Then there is optimisation - by telling the compiler that the 
object won't change value, you let it generate better code (such as 
using "static const" instead of old-fashioned "#define" or enum 
constants).  Next, you define objects as "const" to let the toolchain 
place the object in read-only memory - this is very important for small 
embedded systems running from flash memory.  Finally, you use "const" as 
documentation - you use it when it makes it clearer what the code is 
doing, why it is doing it, or how it is doing it.


So what advantages would there be in declaring a volatile buffer like 
this to be "const"?  At best, you are helping the compiler check that 
you don't accidentally write to it in your own code.  It is dangerous 
regarding optimisation - you definitely don't want the compiler to 
optimise the buffer, yet this whole discussion started because some 
compilers /do/ optimise such code (rightly or wrongly).  You don't want 
the toolchain to put it read-only memory (as noted by another poster, 
doing so would be against the standards - but toolchain writers are not 
infallible, and weird corner-cases like this are where mistakes are less 
likely to be spotted and fixed).  So does the "const" make the program 
clearer to the code writer, and other readers?  I would say it has the 
opposite effect, and leaves a reader wondering what it is supposed to 
mean - the buffer is clearly not meant to be constant, so why is it 
declared "const"?


When I write code, I almost always define objects as "const" when 
possible.  But in this case there would be no doubt in my mind - that 
buffer is /not/ constant, and should not be defined as "const" even if 
it happened to compile and run correctly.


I am aware that this is a stylistic choice.  But I don't see it as good 
programming to push boundaries with "risky" code that might or might not 
work depending on how the compiler writers interpreted the standards - 
especially when it makes the code less clear to human readers.

Re: C99 Status - inttypes.h

[Joseph S. Myers]

On Sun, 25 Sep 2011, Joern Rennecke wrote:

> ! "Library Issue" means that support may or may not be available depending
> ! on the C library used; for example, the GNU C library supports all C99
> ! features, provided _ISOC99_SOURCE and/or _GNU_SOURCE is defined in the
> ! source code or with a -D preprocessor flag.

Referring to these feature test macros is not a good idea, the normal way 
for them to be defined is internally by libc in response to 
__STDC_VERSION__ defined by the compiler.

(There are various miscellaneous conformance issues in glibc as well.  
Apart from what's mentioned in libc's CONFORMANCE file:

* Macros that should be usable in #if defined as enums.

*  and  do not declare long double functions when same 
  representation as double (fixed in EGLIBC by a patch of Jakub's that was 
  ignored for FSF glibc).

* Mathematical function error handling generally a mess: GLIBC bugs
  3866 3868 5680 6759 6776-6788 6792-6799 6801-6810 6814 (this list of bug 
  numbers may be out of date).

* Mathematical functions broken in non-default rounding modes: GLIBC
  bugs 3976 6869.

* Headers redirect functions to standard versions in some cases where C 
  requires this to work without explicitly including headers (might be 
  fixable with pragma redefine_extname in implicitly included header).

* wmemcmp/wcscmp handling of some wchar_t values (see recent libc-alpha 
  discussion; clearly a C94 and C1X conformance bug, less clearly a C99 
  bug).

* Power Architecture malloc alignment 
   (see more 
  recent discussion of this patch in the x32 context).

* Fixes to fenv.h fallback functions were rejected 2011-01-08.

* ARM, MIPS wrongly save/restore fp state in setjmp/longjmp.

I'd welcome details of any other issues people think are C standards 
conformance bugs in glibc.  (I also have some notes of possible issues in 
the soft-fp code and architecture-specific issues in some mathematical 
functions.))

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: C99 Status - inttypes.h

[Gerald Pfeifer]

On Sun, 25 Sep 2011, Joern Rennecke wrote:
> Attached.

Thanks, Jörn!

! "Library Issue" means that support may or may not be available depending
! on the C library used; for example, the GNU C library supports all C99

I suggest a full stop isntead of ";" before "for example" and to just
say "defined" without going into the how.

Joseph, how do you suggest to rephrase the note on activation?  
Just -std=c99 as an option to GCC which then triggers the appropriate
#defines?

Gerald

No pointer conversion warning for "bool" in C/C++

[Jon Grant]

Hello

Currently gcc, and g++ don't give a warning when a pointer was converted 
to a bool, in the same way it is for other types.


Could I ask for opinion on this, and if I should create a bug ticket.

Please find below output from compilation, and attachments showing the 
two tests.


gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

$ gcc -Wconversion -Wall -o t bool_conversion.c
bool_conversion.c: In function ‘main’:
bool_conversion.c:14:8: warning: assignment makes integer from pointer 
without a cast
bool_conversion.c:15:9: warning: assignment makes integer from pointer 
without a cast


^ I expected to see a warning on line 13.



$ g++ -Wconversion -o t bool_conversion.cpp
bool_conversion.cpp: In constructor ‘A::A()’:
bool_conversion.cpp:16:41: warning: converting to non-pointer type ‘int’ 
from NULL
bool_conversion.cpp:16:41: warning: converting to non-pointer type 
‘unsigned int’ from NULL


^ I expected to see a bool warning on line 16.


I tested assigning NULL in these tests (Note, I also confirmed that 
assigning a pointer variable produced the same lack of warning output.)


Please include my email address in any replies

Best regards, Jon
// g++ -Wconversion -o t main.cpp
// Should this not give a warning for the bool conversion
// include to get definition of NULL
#include 


void * g_glob = NULL;
class A
{
public:
	A();
	bool m_bool;
	int m_int;
	unsigned int m_uint;
};

A::A()
: m_bool(g_glob), m_int(NULL), m_uint(NULL)
{
}

int main()
{
	return 0;   
}

// gcc -Wconversion -o t bool_conversion.c
// Should this not give a warning for the bool conversion
// include to get definition of NULL
#include 
#include 

int main(void)
{
	bool m_bool;
	int m_int;
	unsigned int m_uint;

	m_bool = NULL;
	m_int = NULL;
	m_uint = NULL;

	return 0;
}

Trying to find a gcc warning to detect different parameter names

[Jon Grant]

Hello

I am looking for a gcc option to give a warning when parameter names 
don't match between the prototype in C, and the definition. Could 
someone point me to the option if there is one please.


Example provided below, where "offset" miss-spelt "offest".  (I found 
-Wstrict-prototypes, but that only warns if types are not specified.). 
Would be quite handy to have this ability to check parameter names are 
consistent.


Please include my email address in any replies.

Best regards, Jon




gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2


// gcc -Wall -o main main.c

#include 

void test_func(int offest);


void test_func(int offset)
{
printf("%d\n", offset);
}

int main(void)
{
test_func(1);

return 0;
}

Re: Trying to find a gcc warning to detect different parameter names

[Jonathan Wakely]

On 25 September 2011 23:49, Jon Grant wrote:
>
> I am looking for a gcc option to give a warning when parameter names don't
> match between the prototype in C, and the definition. Could someone point me
> to the option if there is one please.

This question is off-topic on this list which is about development of
GCC itself, please use the gcc-help list for help using or building
GCC.

I don't think there is an option that does what you want.

Re: C99 Status - inttypes.h

[Joseph S. Myers]

On Mon, 26 Sep 2011, Gerald Pfeifer wrote:

> Joseph, how do you suggest to rephrase the note on activation?  
> Just -std=c99 as an option to GCC which then triggers the appropriate
> #defines?

Yes.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Volatile qualification on pointer and data

[Miles Bader]

David Brown  writes:
> So what advantages would there be in declaring a volatile buffer like
> this to be "const"?  At best, you are helping the compiler check that
> you don't accidentally write to it in your own code.

That's actually pretty handy tho...

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: No pointer conversion warning for "bool" in C/C++

[Ian Lance Taylor]

Jon Grant  writes:

> Currently gcc, and g++ don't give a warning when a pointer was
> converted to a bool, in the same way it is for other types.

There is a lot of code which uses
if (p)
where p is a pointer to test whether p is not NULL.  I don't think we
could reasonably have gcc warn about such a case.

We might be able to separate out conversion to bool on assignment from
conversion to bool in a test, though.

Ian