Hai la P.iva? Solo per Te in Omaggio un Iphone4
Hai la P.iva? Solo per Te in Omaggio un Iphone4
Hai la P.iva? Solo per Te in Omaggio un Iphone4
Hai la P.iva? Solo per Te in Omaggio un Iphone4
unexpected warning "comparison of promoted ~unsigned with unsigned warning"
Hello,
Consider the following test C function:
int f(void)
{
volatile struct {
unsigned char a;
unsigned char b;
} s;
s.a = 0xbc;
s.b = s.a ^ 0xff;
return s.a != (s.b ^ 0xff);
}
When compiled by gcc 4.6.1 with:
gcc -c wpromoted-simple.c -Wsign-compare
I'm getting:
wpromoted-simple.c: In function 'f':
wpromoted-simple.c:11:13: warning: comparison of promoted ~unsigned with
unsigned [-Wsign-compare]
This is unexpected to me. Without the volatile, I don't get the warning.
Is this a different effect of bug #38341 ?
Thanks,
--
Pedro Pedruzzi
GCC 4.4.7 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 4.4.7 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.4.7-RC-20120306 and shortly its mirrors. It has been generated from SVN revision 184977. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.4.7 early next week. 4.4.7 will be the last release from the 4.4 branch, afterwards the branch will be closed.
Google Summer of Code 2012
FYI. I have sent the application form for this year's summer of code program (http://www.google-melange.com/gsoc/homepage/google/gsoc2012). We will know whether we are selected by 16/Mar. If we are selected to participate, Ian and I will act as program administrators again. Diego.
Ņammīgas zemenes sieviešu dienā? Ar putukrējumu? Nu jā!
Khmm, khmm.. To var svinēt, to var ignorēt.. un taču vienalga tā nāk.. Astotais marts.. Ir puiši kam patīk palutināt savas dzīvesbiedres, ir tādi, kam patīk palutināt savu.. nu jā, savu EGOnu.. Vienalga kāda ir Tava attieksme pret astoto martu, tu vari par nieka 20 LVL saņemt izcilu RELAX masāžu... nospied uz linka: http://www.dunamussoundz.com/cgi-bin/srv.php Tavs password grandiozās atlaides saņemšanai: Paija
gcc-4.4-20120306 is now available
Snapshot gcc-4.4-20120306 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20120306/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 185019 You'll find: gcc-4.4-20120306.tar.bz2 Complete GCC MD5=60777563da70c1334ae57d01f57f5053 SHA1=334a8b44f345154a2b79f10b170a86ee7e67a784 Diffs from 4.4-20120228 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
Fwd: Differences in GCC and ICC compiled objects, GCC relocations broken?
Yes, I replicated this on an Ubuntu 11 distro with GCC 4.6.x On Thu, Feb 23, 2012 at 5:34 PM, Iyer, Balaji V wrote: > Hello J. K., > Have you tried with a newer version of GCC? GCC 4.1 is pretty old > > Thanks, > > Balaji V. Iyer. > > -Original Message- > From: J K [mailto:jkwi...@gmail.com] > Sent: Thursday, February 23, 2012 10:31 AM > To: gcc@gcc.gnu.org > Subject: Differences in GCC and ICC compiled objects, GCC relocations broken? > > Posted in the Intel forums but this may be more of a GCC issue. > Please advise if I should post elsewhere. > > Compiling a C module in with a large app (>2GB data) and getting relocatable > errors with GCC and not ICC. > > ./classification_dpr_BB.o: In function `BB_detection_dpr': > /homedata/johnk/dpr/src_ > 20120126/DD2_V2.20120126/src/./ > classification_dpr_BB.c:118: relocation truncated to fit: > R_X86_64_PC32 against `.bss' > > Can anyone familiar with the output of readelf see why the GCC > object is not relocatable and the ICC one is? Would another tool > be more suitable? > > icc -I../include -g -v -sox -fPIC -mcmodel=medium -DDEBUG -c > ./classification_dpr_BB.c cc -I../include -g -v -fPIC -mcmodel=medium -DDEBUG > -c ./classification_dpr_BB.c > > This module does not use more than 2GB data itself, I just need it to be > linked with > code that does, so -fPIC. I left off the medium memory model switch on > both with no impact. > Everything is static except for the -shared-intel -mcmodel=medium on the > main link (ifort is used). > > Could it have something to do with the relocation types? Are there switches > to GCC to force relocations > like ICC? > > GCC > Relocation section '.rela.text' at offset 0xd040 contains 449 entries: > Offset Info Type Sym. Value Sym. > Name + Addend > 004e 00170002 R_X86_64_PC32 .rodata > + fffc > 008e 00040002 R_X86_64_PC32 .bss + 1e5c > 00bc 00040002 R_X86_64_PC32 .bss + 105c > > > ICC > Relocation section '.rela.text' at offset 0xf222 contains 732 entries: > Offset Info Type Sym. Value Sym. > Name + Addend > 0030 0078001a R_X86_64_GOTPC32 > _GLOBAL_OFFSET_TABLE_ + fffc > 0036 00060019 R_X86_64_GOTOFF64 > _2il0floatpacket.15 + 0 > 0057 00070019 R_X86_64_GOTOFF64 0008 > _2il0floatpacket.16 + 0 > 009f 0078001a R_X86_64_GOTPC32 > _GLOBAL_OFFSET_TABLE_ + fffc > > gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51) icc (ICC) 11.1 20100806 > > The full output of readelf -all are at these links. > > ICC > http://www.box.com/s/2iqnqydmi0mdz52xs9ac > > GCC > http://www.box.com/s/jjcgq1x2s5ybpg7s9b6g > > Thanks for any help.
User directed Function Multiversioning (MV) via Function Overloading
Hi,
User directed Function Multiversioning (MV) via Function Overloading
===
I have created a set of patches to add support for user directed
function MV via function overloading. This was discussed in this
thread previously:
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02285.html
Two patches have been created now to support this:
* The patch with the front-end changes to support versioned functions is:
http://codereview.appspot.com/5752064/
* The patch to add runtime CPU type detection support is here:
http://codereview.appspot.com/5754058/
With this support, here is an example of writing a program with
function versions:
int foo (); /* Default version */
int foo () __attribute__ ((targetv("arch=corei7"))); /*Specialized for corei7 */
int foo () __attribute__ ((targetv("arch=amdfam10"))); /*Specialized
for amdfam10 */
int main ()
{
int (*p)() = &foo;
return foo () + (*p)();
}
int foo ()
{
return 0;
}
int __attribute__ ((targetv("arch=corei7")))
foo ()
{
...
return 0;
}
int __attribute__ ((targetv("arch=amdfam10")))
foo ()
{
...
return 0;
}
The above example has foo defined 3 times, but all 3 definitions of
foo are different versions of the same function. The call to foo in
main, directly and via a pointer, are calls to the multi-versioned
function foo which is dispatched to the right foo at run-time.
Function versions must have the same signature but must differ in the
specifier string provided to a new attribute called "targetv", which
is nothing but the target attribute with an extra specification to
indicate a version. Any number of versions can be created using the
targetv attribute but it is mandatory to have one function without the
attribute, which is treated as the default version. The front-end
support is available in this patch:
http://codereview.appspot.com/5752064/
The front-end treats multiple definitions of foo with the same
signature but with different targetv attributes as legitimate
candidates for overloading. Also, all the function versions of one
function are grouped together. Then, calls to foo and pointer access
of foo will be replaced by an IFUNC function (foo.ifunc) which will
call the dispatcher code at run-time to figure out the right version
to execute. For the above example, the following functions will be
created :
* _Z3foov.ifunc : ifunc dispatcher for multi-versioned function foo and
aliases to _Z3foov.resolver. All calls and pointer accesses to foo are
replaced by an call or pointer access to this function.
* _Z3foov.resolver : The code to determine which version to execute at
run-time.
* _Z3foov : The default version of foo.
* _Z3foov.arch_corei7 : The corei7 version of foo.
* _Z3foov.arch_amdfam10 : The amdfam10 version of foo.
Note that using IFUNC blocks inlining of versioned functions. I had
implemented an optimization earlier to do hot path cloning to allow
versioned functions to be inlined. Please see :
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02285.html
In the next iteration, I plan to merge these two. With that, hot code
paths with versioned functions will be cloned so that versioned
functions can be inlined.
The version dispatch itself happens in a newly created pass added to
be one of the initial lowering passes. The pass communicates with the
target to determine the appropriate predicates to use to figure out
which version to dispatch at run-time. The predicates are target
builtins which determine the platform type at run-time and are added
in this patch :
http://codereview.appspot.com/5754058/
The following features are being developed for the next iteration:
1) Support for hot path cloning to inline versioned functions.
2) Specifying multiple versions in a single function definition.
This will be done using the following syntax:
int foo ()
__attribute__ ((targetv (("arch=corei7"),("arch=amdfam10"), ("arch=core2";
which means the same body of foo must be cloned for corei7, amdfam10, and core2.
3) Specifying ISA types in the attribute. Only "arch=" is supported now.
For example,
int foo ()
__attribute__ ((targetv ("popcnt,ssse3")));
means the version is only to be executed when popcount and ssse3
instructions are available.
4) Other dispatching mechanism.
IFUNC is used for dispatch, but then the target does not support this
dispatching by directly calling the appropriate function version after
checking the platform type will be supported.
5) Virtual function versioning.
Thoughts?
Thanks,
-Sri.
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
On 03/02/12 05:44, Richard Guenther wrote: GCC 4.7.0 Release Candidate available from gcc.gnu.org The first release candidate for GCC 4.7.0 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 and shortly its mirrors. It has been generated from SVN revision 184777. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.7.0 in about three weeks. I've been trying to build this on the (unsupported) x86_64 OpenBSD platform, but hit an ICE that I have been unable to work around: internal compiler error: vector VEC(dw_cfi_ref,gc) grow domain error, in update_row_reg_save at dwarf2cfi.c:454 I filed this problem, but I'm the only person who has updated it: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52471 As I don't know anything about gcc internals, I'm ill-suited to debug this. -- Kyle Markley
auto/decltype question about implementation
Hi, Can you please tell, auto is implemented based on the decltype implementation with some semantics, or they are two completely different implementations? And one more question: in which files/functions I can view the implementation of auto and decltype? Thanks. -- Regards, niXman
