Re: unsatisfied link error
Mark Polo wrote: > hi im newbie to Linux platform . > This mailing list is for those who write and maintain gcc, not for those asking questions about how to *use* it. Please ask either on [EMAIL PROTECTED] or perhaps in a forum for java related questions. Also indicating the actual error you are experiencing might be useful. Thanks, David Daney
Simple way to write almost same pattern?
Hi, I am writing instruction patterns for vector modes (V4Si, V8HI, V16QI, etc). Since these modes have the same length, the underlying instructions may also be the same (load/store instrucitons, AND/OR instructions, etc). Is there any simple way to combines patterns for different modes instead of writing the following code? A simple form should be more maintainable. (define_expand "andv4si3" [(set (match_operand:V4SI 0 "register_operand" "=r") (and:SI (match_operand:V4SI 1 "register_operand" "r") (match_operand:V4SI 2 "general_operand" "ri")))] "" "andl %0, %1, %2" (define_expand "andv8hi3" [(set (match_operand:V8HI 0 "register_operand" "=r") (and:SI (match_operand:V8HI 1 "register_operand" "r") (match_operand:V8HI 2 "nonmemory_operand" "ri")))] "" "andl %0, %1, %2" (define_expand "andv16qi3" [(set (match_operand:V16QI 0 "register_operand" "=r") (and:SI (match_operand:V16QI 1 "register_operand" "r") (match_operand:V16QI 2 "nonmemory_operand" "ri")))] "" "andl %0, %1, %2" ... Thanks, Bingfeng Mei Broadcom UK
-Wconversion bug in g++-4.3?
Consider the following code:
f.cc ==>
void f(const unsigned char b)
{
unsigned char c = static_cast(b & 0xff);
}
<== f.cc
Compile with g++ 4.1.2:
$ g++-4.3-20071109 -c f.cc -Wconversion
$
Note no warnings.
Compile with g++ 4.3-20071109:
$ g++-4.3-20071109 -c f.cc -Wconversion
f.cc: In function 'void f(unsigned char)':
f.cc:3: warning: conversion to 'unsigned char' from 'int' may alter its value
Is this a legitimate warning or a bug? If so, is there anything to be
done to eliminate the warning while retaining "-Wconversion"?
Thanks.
-Tom
Tom Browder
Niceville, Florida
USA
RE: Simple way to write almost same pattern?
On 22 November 2007 14:30, Bingfeng Mei wrote: > Hi, > > I am writing instruction patterns for vector modes (V4Si, V8HI, V16QI, > etc). Since these modes have the same length, the underlying > instructions may also be the same (load/store instrucitons, AND/OR > instructions, etc). Is there any simple way to combines patterns for > different modes instead of writing the following code? A simple form > should be more maintainable. Absolutely: see http://gcc.gnu.org/onlinedocs/gccint/Iterators.html#Iterators cheers, DaveK -- Can't think of a witty .sigline today
RE: Simple way to write almost same pattern?
Dave, Is is only for 4.3+? Define_mode_iterator is not recognized in 4.2.1 I am working on. And I didn't find anything in GCC4.2.1 internal manual either. Cheer. Bingfeng -Original Message- From: Dave Korn [mailto:[EMAIL PROTECTED] Sent: 22 November 2007 15:00 To: Bingfeng Mei; gcc@gcc.gnu.org Subject: RE: Simple way to write almost same pattern? On 22 November 2007 14:30, Bingfeng Mei wrote: > Hi, > > I am writing instruction patterns for vector modes (V4Si, V8HI, V16QI, > etc). Since these modes have the same length, the underlying > instructions may also be the same (load/store instrucitons, AND/OR > instructions, etc). Is there any simple way to combines patterns for > different modes instead of writing the following code? A simple form > should be more maintainable. Absolutely: see http://gcc.gnu.org/onlinedocs/gccint/Iterators.html#Iterators cheers, DaveK -- Can't think of a witty .sigline today
RE: Simple way to write almost same pattern?
On 22 November 2007 15:30, Bingfeng Mei wrote: > Dave, > Is is only for 4.3+? Define_mode_iterator is not recognized in 4.2.1 I > am working on. And I didn't find anything in GCC4.2.1 internal manual > either. Sorry, I don't know when they were first introduced, but if you can't find them in the 4.2.1 internals manual then it's a good guess that they were more recent than that. cheers, DaveK -- Can't think of a witty .sigline today
Re: -Wconversion bug in g++-4.3?
On 22/11/2007, Tom Browder <[EMAIL PROTECTED]> wrote:
> Compile with g++ 4.3-20071109:
>
> $ g++-4.3-20071109 -c f.cc -Wconversion
> f.cc: In function 'void f(unsigned char)':
> f.cc:3: warning: conversion to 'unsigned char' from 'int' may alter its
> value
>
> Is this a legitimate warning or a bug? If so, is there anything to be
> done to eliminate the warning while retaining "-Wconversion"?
>
void f(const unsigned char b)
{
unsigned char c = b & (unsigned char) 0xff;
}
[EMAIL PROTECTED]:~/personal/gcc/objdir$ gcc/cc1plus -Wconversion test.C
void f(unsigned char)
test.C:3: warning: conversion to 'unsigned char' from 'int' may alter its value
test.C:3: warning: conversion to 'unsigned char' from 'int' may alter its value
There is something odd going on, so please open a bug report and add
[EMAIL PROTECTED] to the CC list.
Thanks,
Manuel.
Re: Designs for better debug info in GCC
Mark Mitchell <[EMAIL PROTECTED]> writes: > [...] >> Who is "we"? What better debugging are GCC users demanding? What >> debugging difficulties are they experiencing? Who is that set of users? >> What functional changes would improve those cases? What is the cost of >> those improvements in complexity, maintainability, compile time, object >> file size, GDB start-up time, etc.? > > That's what I'm asking. First and foremost, I want to know what, > concretely, Alexandre is trying to achieve, beyond "better debugging > info for optimized code". Until we understand that, I don't see how we > can sensibly debate any methods of implementation, possible costs, etc. It may be asking to belabour the obvious. GCC users do not want to have to compile with "-O0 -g" just to debug during development (or during crash analysis *after deployment*!). Developers would like to be able to place breakpoints anywhere by reference to the source code, and would like to access any variables logically present there. Developers will accept that optimized code will by its nature make some of these fuzzy, but incorrect data must be and incomplete data should be minimized. That they put up with the status quo at all is a historical artifact of being told so long not to expect any better. - FChE
Re: Progress on GCC plugins ?
Benjamin Smedberg <[EMAIL PROTECTED]> writes: > Diego Novillo wrote: >> Before plug-ins: put your gimple-to-myIR converter in passes.c >> After plug-ins: dlopen gimple-to-myIR.so >> >> Both represent the same effort. Both require your converter to be kept >> up-to-date with GCC's ever shifting ABI/API. > > They represent the same effort for somebody writing a plugin pass. They do > *not* represent the same effort for a Mozilla hacker who just wants to > compile Mozilla with the extra static-checking pass enabled. [...] There may be a subtle connection between this and the debugging information correctness thread by Alex Oliva a few weeks ago. It may be that if only gcc's debuginfo for deployed (-O2 -g) code were more complete & more correct, that some such analysis code could work by on-the-fly probing-based instrumentation rather than compiled-in stuff. At least, this applies to the kinds of assertions expressible by something like the old GNU Nana tool. - FChE
Does gcc support compiling for windows x86-64?
I can't seem to find a concrete answer anywhere to this: does the current version of gcc support building executables for the 64 bit version of Windows? I am using gcc through MinGW and using the -m64 option results in a "sorry, unimplemented: 64-bit mode not compiled in" message. Thanks, Ali.
Re: Designs for better debug info in GCC
On Nov 22, 2007 8:22 PM, Frank Ch. Eigler <[EMAIL PROTECTED]> wrote: > > Mark Mitchell <[EMAIL PROTECTED]> writes: > > > [...] > >> Who is "we"? What better debugging are GCC users demanding? What > >> debugging difficulties are they experiencing? Who is that set of users? > >> What functional changes would improve those cases? What is the cost of > >> those improvements in complexity, maintainability, compile time, object > >> file size, GDB start-up time, etc.? > > > > That's what I'm asking. First and foremost, I want to know what, > > concretely, Alexandre is trying to achieve, beyond "better debugging > > info for optimized code". Until we understand that, I don't see how we > > can sensibly debate any methods of implementation, possible costs, etc. > > It may be asking to belabour the obvious. GCC users do not want to > have to compile with "-O0 -g" just to debug during development (or > during crash analysis *after deployment*!). Developers would like to > be able to place breakpoints anywhere by reference to the source code, > and would like to access any variables logically present there. > Developers will accept that optimized code will by its nature make > some of these fuzzy, but incorrect data must be and incomplete data > should be minimized. > > That they put up with the status quo at all is a historical artifact > of being told so long not to expect any better. As it is (without serious overhead) impossible to do both, you either have to live with possibly incorrect but elaborate or incomplete but correct debug information for optimized code. Choose one ;) What we (Matz and myself) are trying to do is provide elaborate debug information with the chance of wrong (I'd call it superflous, or extra) debug information. Alexandre seems to aim at the world-domination solution (with the serious overhead in terms of implementation and verboseness). Richard.
Re: -Wconversion bug in g++-4.3?
On Nov 22, 2007 10:46 AM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > On 22/11/2007, Tom Browder <[EMAIL PROTECTED]> wrote: > > Compile with g++ 4.3-20071109: ... > There is something odd going on, so please open a bug report and add > [EMAIL PROTECTED] to the CC list. Done as requested, see bug #34198. -Tom Tom Browder Niceville, Florida USA
Re: -Wconversion bug in g++-4.3?
For this testcase:
void g(const unsigned char b)
{
unsigned short c = b & 0xff;
}
we get:
wconversion-3.c:3: warning: conversion to 'unsigned char' from 'int'
may alter its value
wconversion-3.c:3: warning: conversion to 'short unsigned int' from
'int' may alter its value
Really weird... It is the same in both C and C++.
Manu.
Re: Simple way to write almost same pattern?
On Thu, Nov 22, 2007 at 07:30:08AM -0800, Bingfeng Mei wrote: > Dave, > Is is only for 4.3+? Define_mode_iterator is not recognized in 4.2.1 I > am working on. And I didn't find anything in GCC4.2.1 internal manual > either. They used to be called "define_mode_macro" and "define_code_macro". -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Re: -Wconversion bug in g++-4.3?
On Fri, Nov 23, 2007 at 12:02:31AM +0100, Manuel López-Ibáñez wrote:
> For this testcase:
>
> void g(const unsigned char b)
> {
> unsigned short c = b & 0xff;
> }
>
> we get:
>
> wconversion-3.c:3: warning: conversion to 'unsigned char' from 'int'
> may alter its value
> wconversion-3.c:3: warning: conversion to 'short unsigned int' from
> 'int' may alter its value
The type of (b & 0xff) is int. However, the value is bounded, and must be
in 0x00 to 0xff, so the conversion will not alter the value. I don't know
if the warning code is structured to take the value range into account.
In any case, the double warning is odd.
Re: -Wconversion bug in g++-4.3?
On Nov 22, 2007 8:30 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > On Fri, Nov 23, 2007 at 12:02:31AM +0100, Manuel López-Ibáñez wrote: > > For this testcase: ... > > unsigned short c = b & 0xff; > The type of (b & 0xff) is int. However, the value is bounded, and must be In a similar case with unsigned char, adding static_cast
Re: Does gcc support compiling for windows x86-64?
On Nov 22, 2007 2:55 PM, Ali, Muhammad <[EMAIL PROTECTED]> wrote: > I can't seem to find a concrete answer anywhere to this: does the > current version of gcc support building executables for the 64 bit > version of Windows? > > I am using gcc through MinGW and using the -m64 option results in a > "sorry, unimplemented: 64-bit mode not compiled in" message. > > Thanks, > Ali. gcc and binutils can build a compiler toolchain that can target x86_64-pc-mingw32, but it requires a 64-bit runtime. Go here: http://sourceforge.net/projects/mingw-w64/
Re: -Wconversion bug in g++-4.3?
On 23/11/2007, Joe Buck <[EMAIL PROTECTED]> wrote: > > > > wconversion-3.c:3: warning: conversion to 'unsigned char' from 'int' > > may alter its value > > wconversion-3.c:3: warning: conversion to 'short unsigned int' from > > 'int' may alter its value > > The type of (b & 0xff) is int. However, the value is bounded, and must be > in 0x00 to 0xff, so the conversion will not alter the value. I don't know > if the warning code is structured to take the value range into account. No, since guessing the value of b seems a middle-end thing, doesn't it? Nevertheless, that doesn't really matter here since the code is warning for "(int)b" being converted to 'unsigned char'. (The warning occurs even when there is no assignment.) This has to do with how c-typeck.c's build_binary_op builds this operation. If I correctly understand the code there, it basically builds something like int(unsigned char(int(b)) & unsigned char(0xff)) The conversion from int to unsigned char happens at a point where no user-provided cast can reach. Luckily, Jakub seems to have a a fix to work around this in the warning code by using get_narrower to see if the expression being converted is zero or sign extended of some smaller type. If the conversion from this type to the target type can't alter its value, nor change sign, then we shouldn't warn. Cheers, Manuel.
Re: Does gcc support compiling for windows x86-64?
Ali, Muhammad wrote: > I can't seem to find a concrete answer anywhere to this: does the > current version of gcc support building executables for the 64 bit > version of Windows? > > I am using gcc through MinGW and using the -m64 option results in a > "sorry, unimplemented: 64-bit mode not compiled in" message. Why not read the archives of more relevant lists before posting here? I don't know what you are driving at, nor do I think anyone here cares, but the preliminary gcc/gfortran for mingw 64-bit mode which FX Coudert supplied was a version of gcc-4.3.
