gcc-4.6-20120907 is now available
Snapshot gcc-4.6-20120907 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120907/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 191083 You'll find: gcc-4.6-20120907.tar.bz2 Complete GCC MD5=2dce1cb8d08eb17fc4668552d58a3ffb SHA1=0bda06e3d15a9b8340571a731f7a11e02e787605 Diffs from 4.6-20120831 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Bug in bitfield handling?
On Sep 7, 2012, at 2:02 PM, Andrew Pinski wrote:
> On Fri, Sep 7, 2012 at 10:57 AM, wrote:
>> This seems to be a bug:
>>
>> struct bug
>> {
>>int f1:1;
>>unsigned long long f2:31;
>> };
>>
>> struct bug test = { 1, 0x8000ULL };
>>
>> int main (int c, char **v)
>> {
>>unsigned long long tf2;
>>
>>tf2 = test.f2 << 16;
>>if (tf2 == 0x8000ULL)
>>return 0;
>>return 1;
>> }
>>
>> Since the underlying type of field f2 is unsigned long long, I would not
>> expect the expression "test.f2 << 16" to do sign extending of a 32 bit
>> intermediate result. But that is in fact what GCC produces, for
>> x86_64-linux (gcc 4.7.0).
>>
>> If I explicitly cast test.f2 to unsigned long long before the shift, the
>> expected result appears. But I shouldn't have to do that cast, given that
>> the type of f2 is already unsigned long long, correct?
>
> The type of "test.f2" is a 31 bit unsigned integer (the declared type
> is used for alignment) and that fits in a 32bit signed integer so when
> doing test.f2 << 16, it is promoted to only an 32bit signed integer.
>
> Thanks,
> Andrew
Ok, thanks.
GDB doesn't do things this way, so I guess I have to tell them.
paul
Re: Bug in bitfield handling?
On Fri, Sep 7, 2012 at 10:57 AM, wrote:
> This seems to be a bug:
>
> struct bug
> {
> int f1:1;
> unsigned long long f2:31;
> };
>
> struct bug test = { 1, 0x8000ULL };
>
> int main (int c, char **v)
> {
> unsigned long long tf2;
>
> tf2 = test.f2 << 16;
> if (tf2 == 0x8000ULL)
> return 0;
> return 1;
> }
>
> Since the underlying type of field f2 is unsigned long long, I would not
> expect the expression "test.f2 << 16" to do sign extending of a 32 bit
> intermediate result. But that is in fact what GCC produces, for x86_64-linux
> (gcc 4.7.0).
>
> If I explicitly cast test.f2 to unsigned long long before the shift, the
> expected result appears. But I shouldn't have to do that cast, given that
> the type of f2 is already unsigned long long, correct?
The type of "test.f2" is a 31 bit unsigned integer (the declared type
is used for alignment) and that fits in a 32bit signed integer so when
doing test.f2 << 16, it is promoted to only an 32bit signed integer.
Thanks,
Andrew
>
> paul
>
Bug in bitfield handling?
This seems to be a bug:
struct bug
{
int f1:1;
unsigned long long f2:31;
};
struct bug test = { 1, 0x8000ULL };
int main (int c, char **v)
{
unsigned long long tf2;
tf2 = test.f2 << 16;
if (tf2 == 0x8000ULL)
return 0;
return 1;
}
Since the underlying type of field f2 is unsigned long long, I would not expect
the expression "test.f2 << 16" to do sign extending of a 32 bit intermediate
result. But that is in fact what GCC produces, for x86_64-linux (gcc 4.7.0).
If I explicitly cast test.f2 to unsigned long long before the shift, the
expected result appears. But I shouldn't have to do that cast, given that the
type of f2 is already unsigned long long, correct?
paul
gcc-c-api
After a hiatus, I've restarted work on an API for GCC plugins - specifically, a C API (given that my plugin is written in C, I have more interest in that than a C++ API). BTW, how many other GCC plugins are written in C? It's still a work-in-progress, but can be seen here: http://git.fedorahosted.org/cgit/gcc-python-plugin.git/tree/gcc-c-api?h=proposed-plugin-api i.e. within the "proposed-plugin-api" branch of the gcc-python-plugin, within the "gcc-c-api" subdirectory. I've been gradually porting the python plugin to use the proposed API, rather than poking at GCC's insides itself. I've also tried to follow the GNU coding conventions within that directory (the plugin itself follows the Python coding conventions). I haven't done the copyright assignment paperwork yet. There are no explicit test cases yet, though the python plugin's test suite passes, exercising the code indirectly. The API has a build-time dependency on Python (parts of it are autogenerated, and Python is my natural choice for this work). There isn't a runtime dep though. I started thinking about trying to create a patch to merge the API into the GCC source tree, but I'm running into some high-level issues: how is a plugin meant to actually use this API without requiring the use of an in-development version of GCC? Similarly, as a plugin author, I want my plugin to be usable against GCC 4.6 onwards, but GCC's internal APIs are gradually changing. I see a lot of #ifs in my future, and it makes sense to try to isolate the compatibility shims in one place, rather than having every plugin author maintain them. Given that, it's most useful, I think, if the API code can somehow be used independently of GCC: perhaps it's more of a compatibility shim that hides the differences between GCC versions (e.g. C vs C++ name mangling, C++ internals in 4.8 onwards etc) and provides a stable ABI (that way you only have to recompile the API implementation when recompilng GCC: all plugins built against the API should remain compatible - that's the goal, after all). I'm not sure exactly how this is to be structured: external project vs internal to gcc's source tree, but given that this is a non-trivial amount of code and that I want it to support gcc 4.6, perhaps external to the gcc source tree is the way to go. Thoughts? Hope this is helpful Dave
Re: Cgraph Modification Plan
> Sorry to interrupt here, but please finish the existing partial C++ > transitions > instead of starting to work on new ones. Current stage1 will not last forever > (stage1 is usually 6 months, so its natural end would be end of September). > I'd rather have the current transition to a symbol table finished than having > that half-way done and half-way done in C++. Please. I am focusing on getting the transition finished for 4.8. Some discussion about C++ transition (I would like to see done for 4.8 at least in the basic and obvious way) and problems people have with the current design seems good to me. We do not need to implement everything discussed in this thread immediately, but it is good to have the discussion. > > Btw, I also think the current symtab hierarchy is somewhat flawed. At > the core a symtab entry should just be the symbol name and a list > of entities associated with it (much similar to the LTO symtab stuff). We do have that. There is list of symtab entries sharing the same symtab hash entry (assembler name). I have WIP patch to make lto-symtab to use these instead of its own hashes. They need more testing and bit of cleanup though. > Entities then are callgraph nodes, varpool nodes or alias nodes (or other Having alias nodes separate from callgrap/varpool is difficult thing. The problem is that one realy wants to handle function aliases as functions and variable aliases as variables (i.e. one want to have call to function alias, or read from variable alias but not other ways around). Thus we currently have aliases inherited from functions/variables both on tree declaration level and symbol table level. I have patches to commonize more the alias handling that is now duplicated over former cgraph/vaprool in queue though. > stuff). Thus, the current symtab_node_base is too "fat", and decls, > instead of having DECL_ASSEMBLER_NAME should have a pointer > to the (new) symtab node they are associated with. Yes, it is the longer term goal (or rather getting rid of assembler name in favor of real symbol name + flags that are currently encoded in assembler name) At the moment it does seem to make sense though when everything is tied to declarations and eclarations have their own assembler name. I will slowly work on this, but after 4.8. Honza > > Thanks, > Richard.
Re: print operand modifiers in the manual
Ian Lance Taylor wrote: Mike Stump wrote: Where in the manual are the machine specific print operand modifiers documented? I've looked around, and just can seem to find them; surely, I can't be the first to document such a modifier. To the best of my knowledge they are not documented in the manual. The machine-specific asm constraint characters are documented in the manual, but I don't think the print operand modifiers are. Often, when I consult the user manual for target specific buts, I get the impression that the organization of these information is suboptimal because it is scattered all over the user manual: - target specific function attributes (even merged up with each other) - target specific data attributes - target specific type attributes - target specific named address spaces - target specific command options - target specific built-in defines - target specific buitt-in functions - target specific built-in types like __int24 or __int128 - target specific inline assembler constraints - target specific inline assembler print modififers - target specific #pragma - target specific built-in sections - target specific extension support like ISO/IEC TR 18037 - target specific implementation (int, void*, double, accum, fract, ...) - target specific restrictions and caveats (like .text > 128KiB on avr) - target specific ABI, at least an outline like register usage, might help (inline) assembler programmers to write code that cooperates with code from GCC - target specific defaults: debug-info, frame layout, exception model, asm clobbers, SFR usage, ... All is scattered over the manual. There is no central place to read about "target specific" features and caveats. If you start with GCC and/or with a specific target architecture, it is *very* likely you miss some of these sections and get frustrated by non-functional code. Some of the above bits I just dropped in the "Target Options" section because there is no other canonical place, and the "Target Options" is likely to be read by the user, cf. [1] for example. Johann -- [1] http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html
Re: print operand modifiers in the manual
David Daney wrote: Mike Stump wrote: David Daney wrote: Ian Lance Taylor wrote: Mike Stump wrote: Where in the manual are the machine specific print operand modifiers documented? I've looked around, and just can seem to find them; surely, I can't be the first to document such a modifier. To the best of my knowledge they are not documented in the manual. The machine-specific asm constraint characters are documented in the manual, but I don't think the print operand modifiers are. Perhaps they should be added to the internals manual. Only if you move extended asms to the internals manual. :-( I got the idea from the Constraints documentation, and for those I always looked in the Internals Manual. But now I see that there is similar, but not identical, Constraints documentation in both the GCC manual and the Internals Manual. I am not so fluent in texinfo that I would attempt it, but it seems that these sections should be factored into separate files so that the same information can appear in both manuals and not have the current divergence of content. I am not sure if that is a good idea. For example, the "X" constraint is useful/needed in machine description but not at all in inline assembler. It is a bug to use "X" as inline assembler constraint, and it is confusing to inline assembler authors if it is documented. Other constraint might be "p" that is useful in md but not at all in inline assembler. Similar applies to the asm print modifiers. Any yes, the common ans useful print modifiers should be documented in the user manual, IMHO. Johann
