TARGET_SHIFT_TRUNCATION_MASK
Hello!
I was playing a bit with TARGET_SHIFT_TRUNCATION_MASK on x86 in the
hope that redundant masking would get eliminated from:
int test (int a, int c)
{
return a << (c & 0x1f);
}
The macro was defined as:
+/* Implement TARGET_SHIFT_TRUNCATION_MASK. */
+static unsigned HOST_WIDE_INT
+ix86_shift_truncation_mask (enum machine_mode mode)
+{
+ switch (mode)
+{
+case QImode:
+case HImode:
+case SImode:
+ return 31;
+
+case DImode:
+ if (TARGET_64BIT)
+ return 63;
+
+default:
+ return 0;
+}
+}
However, I was not able to get rid of the masking "and".
Uros.
Re: Triplet for ARM Linux HardFP ABI
On 12/07/10 14:25, Andrew Stubbs wrote: This means that we need to choose a name for it. Obviously, it's better if it's an "official" name, so I want to discuss it here. I'm aware that there is some bikeshedding to do here, but it's better it gets done before anybody gets stuck with something else. There are, of course, some real practical reasons why one name might be better than another. So, it seems this issue is not as simple as I thought. :( Opinion seem to be somewhat divided, but in the absence of any sort of consensus, I suppose I'll have to propose that the various projects use the vendor field. The alternative would be to add a configure test that checked the defaults in the existing host compiler, and duplicated the defaults somehow, but that sounds somewhat icky. Andrew
Re: onlinedocs/libstdc++ appears stale
On 15 July 2010 10:54, Gerald Pfeifer wrote: > > How shall we address this for real? Is it really worthwhile to manually > generate those .html.gz files for onlinedocs/libstdc++ or could we simply > omit that step? Not sure it's really worth the hassles? I have no idea why we gzip them, it certainly isn't saving any diskspace if we end up with the .html *and* the .html.gz! Benjamin has already started making some changes so that all the libstdc++ docs can be generated automatically and put under /onlinedocs as is done for the compiler docs.
Re: TARGET_SHIFT_TRUNCATION_MASK
On 07/15/2010 09:57 AM, Uros Bizjak wrote:
Hello!
I was playing a bit with TARGET_SHIFT_TRUNCATION_MASK on x86 in the
hope that redundant masking would get eliminated from:
int test (int a, int c)
{
return a<< (c& 0x1f);
}
The macro was defined as:
+/* Implement TARGET_SHIFT_TRUNCATION_MASK. */
+static unsigned HOST_WIDE_INT
+ix86_shift_truncation_mask (enum machine_mode mode)
+{
+ switch (mode)
+{
+case QImode:
+case HImode:
+case SImode:
+ return 31;
+
+case DImode:
+ if (TARGET_64BIT)
+ return 63;
+
+default:
+ return 0;
+}
+}
However, I was not able to get rid of the masking "and".
FWIW, the reason the hook is not implemented on x86 is that some
variants of bsf/bsr (I think with memory source) do not honor the
truncation.
Paolo
Re: TARGET_SHIFT_TRUNCATION_MASK
On Thu, Jul 15, 2010 at 2:16 PM, Paolo Bonzini wrote:
> On 07/15/2010 09:57 AM, Uros Bizjak wrote:
>>
>> Hello!
>>
>> I was playing a bit with TARGET_SHIFT_TRUNCATION_MASK on x86 in the
>> hope that redundant masking would get eliminated from:
>>
>> int test (int a, int c)
>> {
>> return a<< (c& 0x1f);
>> }
>>
>> The macro was defined as:
>>
>> +/* Implement TARGET_SHIFT_TRUNCATION_MASK. */
>> +static unsigned HOST_WIDE_INT
>> +ix86_shift_truncation_mask (enum machine_mode mode)
>> +{
>> + switch (mode)
>> + {
>> + case QImode:
>> + case HImode:
>> + case SImode:
>> + return 31;
>> +
>> + case DImode:
>> + if (TARGET_64BIT)
>> + return 63;
>> +
>> + default:
>> + return 0;
>> + }
>> +}
>>
>> However, I was not able to get rid of the masking "and".
>
> FWIW, the reason the hook is not implemented on x86 is that some variants of
> bsf/bsr (I think with memory source) do not honor the truncation.
The reason you pointed out is for SHIFT_COUNT_TRUNCATED. Please note,
that we don't use memory_operands, but even in register operand case,
"bt" insn doesn't truncate the bit-count operand, but performs modulo
operation on it. I.E, "bt %reg, 75" will not return 0, but shift insn
with the same operands will.
Uros.
Why is debug_insn built into DDG?
Hello, I started to look at VTA recently and check whether our port passes the -fcompare-debug test. Our port contains some extra passes for our VLIW target. What I have trouble is with our modulo scheduling pass (based on IMS algorithm). I noticed that debug_insns are built into DDG, and has ANTI-dependence edge drawn between other instruction and them. This dependencies will affect calculation of ASAP, ALAP etc, therefore affect ordering algorithm and final scheduling results. Why these debug_insns are needed in the DDG in the first place? They are skipped during scheduling anyway. Isn't it waste of compilation time? Thanks, Bingfeng
gcc-4.5-20100715 is now available
Snapshot gcc-4.5-20100715 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100715/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 162234 You'll find: gcc-4.5-20100715.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100715.tar.bz2 C front end and core compiler gcc-ada-4.5-20100715.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100715.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100715.tar.bz2 C++ front end and runtime gcc-java-4.5-20100715.tar.bz2 Java front end and runtime gcc-objc-4.5-20100715.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100715.tar.bz2The GCC testsuite Diffs from 4.5-20100708 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
GCC 4.5.0 Reports invalid warning
This is the code.
--
#define PointerA struct a *
void f( PointerA );
typedef struct a * PA;
struct a { int x; };
void f( PA a )
{
}
-
This is the output
warning: 'struct a' declared inside parameter list
warning: its scope is only this definition or declaration, which is
probably not what you want
error: conflicting types for 'f'
note: previous declaration of 'f' was here
This is valid C code by every other compiler.
If there is already a thread about this, or a bug about it, I didn't
find it searching this lsit or the bugs database.
If I move even the 'typedef struct a *PA' above the first function,
then 'struct a' is apparently defined, even if it is not.
ICE with GCC-4.5.1-20100708
Testing the mingw64-i686* packages found at
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW (Cygwin cross
compiler, see[*]), I have obtained an ICE:
$ cat ICE_test.cpp
void foo(char const* upattern, int color)
{
static short bitmap_data[8];
for (int i = 0; i < 8; i++)
{
bitmap_data[i] = (unsigned char)~upattern[i];
}
}
$ mingw32-g++ -O3 -c ICE_test.cpp
ICE_test.cpp: In function ‘void foo(const char*, int)’:
ICE_test.cpp:1:6: internal compiler error: in vectorizable_store, at
tree-vect-stmts.c:3157
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Using '-O0/-O1/-O2' in place of '-O3' option, works just fine!
Useful informations
---
I have done a very personal installation of the cited packages: I have
unpacked them in /tmp, renamed usr to mingw-w64 and moved this to
/usr/local. Then I have created the link mingw32-g++ ->
/usr/local/mingw-w64/bin/i686-w64-mingw32-g++.exe. So:
$ mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=mingw32-g++
COLLECT_LTO_WRAPPER=/usr/local/mingw-w64/bin/../lib/gcc/i686-w64-mingw32/4.5.1/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with:
/usr/src/ports/devel/mingw64-i686-gcc/mingw64-i686-gcc-4.5.20100708-1/src/gcc-4.5-20100708/configure
--srcdir=/usr/src/ports/devel/mingw64-i686-gcc/mingw64-i686-gcc-4.5.20100708-1/src/gcc-4.5-20100708
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --datarootdir=/usr/share
--docdir=/usr/share/doc/mingw64-i686-gcc --build=i686-pc-cygwin
--host=i686-pc-cygwin --target=i686-w64-mingw32
--with-sysroot=/usr/i686-w64-mingw32/sys-root --disable-multilib
--enable-libgomp --enable-lto
--enable-languages=c,c++,fortran,objc,obj-c++
--enable-fully-dynamic-strings --enable-sjlj-exceptions
--enable-version-specific-runtime-libs --with-dwarf2
Thread model: win32
gcc version 4.5.1 20100708 (prerelease) (GCC)
The CPU is AMD Athlon 64 DC. The system is Cygwin 1.75 on WinXP 32.
Ciao,
Angelo.
---
[*] http://cygwin.com/ml/cygwin-apps/2010-07/msg00134.html
Re: GCC 4.5.0 Reports invalid warning
On 16/07/2010 00:59, J Decker wrote:
> --
>
> #define PointerA struct a *
>
> void f( PointerA );
>
> typedef struct a * PA;
> struct a { int x; };
>
> void f( PA a )
> {
> }
>
> -
>
> This is the output
>
> warning: 'struct a' declared inside parameter list
> warning: its scope is only this definition or declaration, which is
> probably not what you want
> error: conflicting types for 'f'
> note: previous declaration of 'f' was here
>
>
>
>
> This is valid C code by every other compiler.
Not so, as far as I can tell. Comeau online says:
> Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
> Copyright 1988-2008 Comeau Computing. All rights reserved.
> MODE:strict errors C99
>
> "ComeauTest.c", line 3: warning: declaration is not visible outside of
> function
> void f( PointerA );
> ^
>
> "ComeauTest.c", line 8: error: declaration is incompatible with "void
> f(struct a *)"
> (declared at line 3)
> void f( PA a )
>^
>
> 1 error detected in the compilation of "ComeauTest.c".
As long as "struct a" hasn't been (forward-)declared at the time the
declaration of f() is found, it is a different one from the "struct a" in the
global namespace that the formal parameter on the definition of f() then
subsequently refers to.
cheers,
DaveK
Re: GCC 4.5.0 Reports invalid warning
On Thu, Jul 15, 2010 at 5:32 PM, Dave Korn wrote:
> On 16/07/2010 00:59, J Decker wrote:
>
>> --
>>
>> #define PointerA struct a *
>>
>> void f( PointerA );
>>
>> typedef struct a * PA;
>> struct a { int x; };
>>
>> void f( PA a )
>> {
>> }
>>
>> -
>>
>> This is the output
>>
>> warning: 'struct a' declared inside parameter list
>> warning: its scope is only this definition or declaration, which is
>> probably not what you want
>> error: conflicting types for 'f'
>> note: previous declaration of 'f' was here
>>
>>
>>
>>
>> This is valid C code by every other compiler.
>
> Not so, as far as I can tell. Comeau online says:
>
>> Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
>> Copyright 1988-2008 Comeau Computing. All rights reserved.
>> MODE:strict errors C99
>>
>> "ComeauTest.c", line 3: warning: declaration is not visible outside of
>> function
>> void f( PointerA );
>> ^
>>
>> "ComeauTest.c", line 8: error: declaration is incompatible with "void
>> f(struct a *)"
>> (declared at line 3)
>> void f( PA a )
>> ^
>>
>> 1 error detected in the compilation of "ComeauTest.c".
>
> As long as "struct a" hasn't been (forward-)declared at the time the
> declaration of f() is found, it is a different one from the "struct a" in the
> global namespace that the formal parameter on the definition of f() then
> subsequently refers to.
>
Okay so if I just move the typedef up... (which isn't exactly feasible
in the actual project)
>>
>> #define PointerA struct a *
>>
>> typedef struct a * PA;
>> void f( PointerA );
>>
>> struct a { int x; };
>>
>> void f( PA a )
>> {
>> }
Now it's happy, why can't it just define 'struct a' as an appropriate
name as it used to, the strucutre still isn't defined.
(okay every other compiler I mention is MSVC, OpenWatcom, lcc, and gcc
before now)
> cheers,
> DaveK
>
>
Re: GCC 4.5.0 Reports invalid warning
On 16/07/2010 01:21, J Decker wrote: > Now it's happy, why can't it just define 'struct a' as an appropriate > name as it used to, the strucutre still isn't defined. That's just the way that C works, I'm afraid. > (okay every other compiler I mention is MSVC, OpenWatcom, lcc, and gcc > before now) Nah, gcc-4.3.4 also doesn't like it: > $ gcc -c pa.c -Wall -W > pa.c:3: warning: 'struct a' declared inside parameter list > pa.c:3: warning: its scope is only this definition or declaration, which is > prob > ably not what you want > pa.c:8: error: conflicting types for 'f' > pa.c:3: error: previous declaration of 'f' was here > pa.c:8: warning: unused parameter 'a' Nor does gcc-3.4.4: > $ gcc-3 -c pa.c -Wall -W > pa.c:3: warning: "struct a" declared inside parameter list > pa.c:3: warning: its scope is only this definition or declaration, which is > prob > ably not what you want > pa.c:8: warning: unused parameter 'a' Even MSVC more-or-less spots it, if you turn up the default warning level: > $ cl /c /W4 pa.c > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 > Copyright (C) Microsoft Corp 1984-1998. All rights reserved. > > pa.c > pa.c(3) : warning C4115: 'a' : named type definition in parentheses > pa.c(8) : warning C4100: 'a' : unreferenced formal parameter cheers, DaveK
Re: GCC 4.5.0 Reports invalid warning
Oh not so bad then, I can just add at the beginning...
typedef struct a *NeverUsedDefinition;
and now it's happy? And that makes good coding how? If I never
actually use 'NeverUsedDefinition'? Actually this 'feature' now
causes useless and unused declartions to be created.
On Thu, Jul 15, 2010 at 5:21 PM, J Decker wrote:
> On Thu, Jul 15, 2010 at 5:32 PM, Dave Korn wrote:
>> On 16/07/2010 00:59, J Decker wrote:
>>
>>> --
>>>
>>> #define PointerA struct a *
>>>
>>> void f( PointerA );
>>>
>>> typedef struct a * PA;
>>> struct a { int x; };
>>>
>>> void f( PA a )
>>> {
>>> }
>>>
>>> -
>>>
>>> This is the output
>>>
>>> warning: 'struct a' declared inside parameter list
>>> warning: its scope is only this definition or declaration, which is
>>> probably not what you want
>>> error: conflicting types for 'f'
>>> note: previous declaration of 'f' was here
>>>
>>>
>>>
>>>
>>> This is valid C code by every other compiler.
>>
>> Not so, as far as I can tell. Comeau online says:
>>
>>> Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
>>> Copyright 1988-2008 Comeau Computing. All rights reserved.
>>> MODE:strict errors C99
>>>
>>> "ComeauTest.c", line 3: warning: declaration is not visible outside of
>>> function
>>> void f( PointerA );
>>> ^
>>>
>>> "ComeauTest.c", line 8: error: declaration is incompatible with "void
>>> f(struct a *)"
>>> (declared at line 3)
>>> void f( PA a )
>>> ^
>>>
>>> 1 error detected in the compilation of "ComeauTest.c".
>>
>> As long as "struct a" hasn't been (forward-)declared at the time the
>> declaration of f() is found, it is a different one from the "struct a" in the
>> global namespace that the formal parameter on the definition of f() then
>> subsequently refers to.
>>
>
> Okay so if I just move the typedef up... (which isn't exactly feasible
> in the actual project)
>
>
>>>
>>> #define PointerA struct a *
>>>
>>> typedef struct a * PA;
>>> void f( PointerA );
>>>
>>> struct a { int x; };
>>>
>>> void f( PA a )
>>> {
>>> }
>
> Now it's happy, why can't it just define 'struct a' as an appropriate
> name as it used to, the strucutre still isn't defined.
>
> (okay every other compiler I mention is MSVC, OpenWatcom, lcc, and gcc
> before now)
>
>> cheers,
>> DaveK
>>
>>
>
Re: ICE with GCC-4.5.1-20100708
On Fri, 2010-07-16 at 02:06 +0200, Angelo Graziosi wrote:
> Testing the mingw64-i686* packages found at
> ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW (Cygwin cross
> compiler, see[*]), I have obtained an ICE:
>
> $ cat ICE_test.cpp
> void foo(char const* upattern, int color)
> {
>static short bitmap_data[8];
>for (int i = 0; i < 8; i++)
>{
> bitmap_data[i] = (unsigned char)~upattern[i];
>
>}
> }
>
> $ mingw32-g++ -O3 -c ICE_test.cpp
> ICE_test.cpp: In function ‘void foo(const char*, int)’:
> ICE_test.cpp:1:6: internal compiler error: in vectorizable_store, at
> tree-vect-stmts.c:3157
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See for instructions.
>
>
> Using '-O0/-O1/-O2' in place of '-O3' option, works just fine!
Confirmed. Note that this does not occur with the other cross-targets
compiled from the same snapshot (i686-pc-mingw32, x86_64-w64-mingw32,
i686-pc-linux-gnu), even with -O3.
Yaakov
Cygwin Ports
Re: GCC 4.5.0 Reports invalid warning
On 16/07/2010 01:31, J Decker wrote: > Oh not so bad then, I can just add at the beginning... > > typedef struct a *NeverUsedDefinition; > > and now it's happy? And that makes good coding how? No, that would be bad coding. Just forward-declare the tag: struct a; before you try and use it in a function's formal parameter list. The declarations in a function's formal parameter list are in a more inner scope than file scope, so if there isn't a tag declaration at file scope yet, you're talking about a new tag declaration limited only to the scope in which it is declared - the function declaration (argument list and body, if present; just argument list in the case of a prototype). When you later do declare a "struct a" tag at file scope, the later definition of f() "inherits" that one from the more global scope, just like it would "inherit" the name of a global variable from the enclosing scope. In the C language spec: 6.7.2.3#4: "All declarations of structure, union, or enumerated types that have the same scope and use the same tag declare the same type." 6.7.2.3#5: "Two declarations of structure, union, or enumerated types which are in different scopes or use different tags declare distinct types." cheers, DaveK
Re: GCC 4.5.0 Reports invalid warning
On Thu, Jul 15, 2010 at 5:31 PM, J Decker wrote: > Oh not so bad then, I can just add at the beginning... > > typedef struct a *NeverUsedDefinition; > > and now it's happy? And that makes good coding how? If I never > actually use 'NeverUsedDefinition'? Actually this 'feature' now > causes useless and unused declartions to be created. You don't need to give it a useless name. You can just do struct a; to declare a struct called a. -- James
Re: GCC 4.5.0 Reports invalid warning
On Thu, Jul 15, 2010 at 6:08 PM, Dave Korn wrote: > On 16/07/2010 01:31, J Decker wrote: >> Oh not so bad then, I can just add at the beginning... >> >> typedef struct a *NeverUsedDefinition; >> >> and now it's happy? And that makes good coding how? > > No, that would be bad coding. Just forward-declare the tag: > > struct a; > > before you try and use it in a function's formal parameter list. > > The declarations in a function's formal parameter list are in a more inner > scope than file scope, so if there isn't a tag declaration at file scope yet, > you're talking about a new tag declaration limited only to the scope in which > it is declared - the function declaration (argument list and body, if present; > just argument list in the case of a prototype). > > When you later do declare a "struct a" tag at file scope, the later > definition of f() "inherits" that one from the more global scope, just like it > would "inherit" the name of a global variable from the enclosing scope. In > the C language spec: > > 6.7.2.3#4: "All declarations of structure, union, or enumerated types that > have the same scope and use the same tag declare the same type." > Then how does this result in the warnings even that type 'struct a' does not match target 'struct a'? (or some paraphrase of that, this sample code did not generate exactly the same warnings as the full project. How could two definitions of struct a be defined? > 6.7.2.3#5: "Two declarations of structure, union, or enumerated types which > are in different scopes or use different tags declare distinct types." > Okay, and how is this out of scope? it's a global prototype, and the struct must without question also be defined in said global scope. When would it ever be something other than this? Although I did go back and read the error more appropriately. Okay I'm leaving this list. > > cheers, > DaveK > >
Re: [gengtype] are mark_hook GTY still working? Perhaps not!
2010/7/14 Basile Starynkevitch : > I am quite sure that at some point in the past, the mark_hook did work. > > But I have the impression that with the current gengtype, they don't. [...] > Does any one have a working example of mark_hook GTY? Have you ruled out user errors here? Are there any mark_hook uses in the GCC trunk? Do they work? Other than that, I'd suggest that you fire a debugger and see what's going on inside gengtype. -- Laurynas
