Re: Does TYPE_MAX_VALUE (size_type_node) overflow?
On Wed, Jan 19, 2011 at 10:53 PM, Florian Weimer wrote:
> I get strange warnings when I do arithmetic involving TYPE_MAX_VALUE
> (size_type_node), in particular this code:
>
> /* Multiplies MUL1 with MUL2, and adds ADD. Returns (size_t)-1 if the
> result cannot be be represented as a size_t value. If ADD is
> null_tree, treat it as a zero constant.
> */
> tree
> build_size_mult_saturated (tree mul1, tree mul2, tree add)
> {
> tree max_mul1, result;
> max_mul1 = TYPE_MAX_VALUE (size_type_node);
> if (add != NULL_TREE)
> max_mul1 = size_binop(MINUS_EXPR, max_mul1, add);
> max_mul1 = size_binop(TRUNC_DIV_EXPR, max_mul1, mul2);
> result = size_binop (MULT_EXPR, mul1, mul2);
> if (add != NULL_TREE)
> result = size_binop (PLUS_EXPR, result, add);
> return build3 (COND_EXPR, sizetype,
> build2 (EQ_EXPR, sizetype, mul2, size_zero_node),
> add == NULL_TREE ? size_zero_node : add,
> build3 (COND_EXPR, sizetype,
> build2 (LE_EXPR, sizetype, mul1, max_mul1),
> result, TYPE_MAX_VALUE (size_type_node)));
> }
>
> Is size_type_node really signed, and does TYPE_MAX_VALUE
> (size_type_node) lie outside the representable range? Is there an
> easy way to get a GCC type closely matching size_t in C++?
The size_* functions are supposed to be used with sizetype,
not with size_type ;) sizetypes are strange beast.
Richard.
[Patch] [C++0x] Support decltype as base-specifier (Bug 42603)
Hi there, Attached is a tentative patch to support using decltype as a base-type-specifier (Re: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42603). It should handle also the case where decltype is used as the start of a nested-name-specifier when this is supported in the future. Any feedback welcome -- I have done only basic testing -- it appears to work okay for what I want (so far at least). Regards, Adam PS. I already have sorted copyright assignment a while ago so you can go ahead and apply this at your convenience if it is any good (subject to review of course). 0001-C-0x-Support-decltype-as-base-specifier.patch Description: Binary data
Re: [Patch] [C++0x] Support decltype as base-specifier (Bug 42603)
On 20 January 2011 14:26, Adam Butcher wrote: > Hi there, > > Attached is a tentative patch to support using decltype as a > base-type-specifier (Re: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42603). > > It should handle also the case where decltype is used as the start of a > nested-name-specifier when this is supported in the future. > > Any feedback welcome -- I have done only basic testing -- it appears to > work okay for what I want (so far at least). > > Regards, > Adam > > PS. I already have sorted copyright assignment a while ago so you can go > ahead and apply this at your convenience if it is any good (subject to > review of course). Hi, thanks for working on this. Patches should be sent to the gcc-patches list for review, you could then add the URL of the archived email to the bugzilla report. Thanks, Jonathan
Re: [Patch] [C++0x] Support decltype as base-specifier (Bug 42603)
On Thu, January 20, 2011 4:43 pm, Jonathan Wakely wrote: > On 20 January 2011 14:26, Adam Butcher wrote: > > Hi there, > > > > Attached is a tentative patch ... > > [snip] > > thanks for working on this. Patches should be sent to the gcc-patches > list for review, you could then add the URL of the archived email to > the bugzilla report. > Thanks Jonathan, Paolo had already mailed me off list about this. I have posted the original mail and a further patch to handle decltype in nested-name-specifiers to gcc-patches. I will update the related bugzilla issues 42603 and 6709 also. Cheers Adam
[trans-mem] optimization problem with ITM functions
Hello,
Attached the cpp example.
While I was trying to understand the problem (segfault), I found this:
In special_function_p function (calls.c), ECF_TM_OPS flag is returned for
all TM builtin call except BUILT_IN_TM_START.
Question: is it really intentional or missing?
Moreover since BUILT_IN_TM_START is doing a setjmp, I suppose it should
add also the flag ECS_RETURNS_TWICE. If I add this, the generated code is
a bit different (more things happen in the stack, which I suppose right).
BUILT_IN_TM_ABORT is kind of longjmp, it should then add ECF_NORETURN,
right?.
Otherwise I have a strange bug with the attached cpp file when
_ITM_commitTransaction is the last call of a function with optimization
level>=2. This call is optimized as a tail call thus the epilogue is
before the jmp. But in this specific case, if the _ITM_commitTransaction
aborts and roll backs, it seems it creates a problem (corrupted stack) but
I didn't figure out the real reason.
To avoid this problem I have added ECF_RETURNS_TWICE for the transaction
commit which avoid this tail call optimization but I am sure this is not
the way to fix this.
Attached the patch for these problems.
Thanks for any help.
Patrick Marlier.#include
namespace bench
{
class LLNode
{
LLNode* next;
int data;
public:
__attribute__((transaction_safe))
LLNode(int val, LLNode* m_next)
{
data = val;
next = m_next;
}
__attribute__((transaction_safe))
~LLNode(){}
__attribute__((transaction_safe))
int get_val() {return data;}
__attribute__((transaction_safe))
LLNode* get_next() {return next;}
__attribute__((transaction_safe))
void set_val(int val) {data = val;}
__attribute__((transaction_safe))
void set_next(LLNode* n) {next = n;}
__attribute__((transaction_safe))
void *operator new(size_t size);
};
class LinkedList
{
LLNode* head;
public:
LinkedList();
void insert(int val);
};
}
using bench::LinkedList;
using bench::LLNode;
__attribute__((transaction_safe))
void* LLNode::operator new(size_t size)
{
return malloc(size);
}
LinkedList::LinkedList() : head(new LLNode(-1, NULL)) { }
void LinkedList::insert(int val)
{
__transaction [[atomic]] {
LLNode* prev = head;
LLNode* curr = head->get_next();
while (curr != NULL) {
if (curr->get_val() >= val)
break;
prev = curr;
curr = prev->get_next();
}
if (!curr || (curr->get_val() > val)){
LLNode* tmp = new LLNode(val,curr);
prev->set_next(tmp);
}
}
// asm volatile("nop");
}
Index: calls.c
===
--- calls.c (revision 168989)
+++ calls.c (working copy)
@@ -473,9 +473,17 @@
{
switch (DECL_FUNCTION_CODE (fndecl))
{
+
+ case BUILT_IN_TM_START:
+ flags |= ECF_RETURNS_TWICE | ECF_TM_OPS;
+ break;
+ case BUILT_IN_TM_ABORT:
+ flags |= ECF_NORETURN | ECF_TM_OPS;
+ break;
case BUILT_IN_TM_COMMIT:
case BUILT_IN_TM_COMMIT_EH:
- case BUILT_IN_TM_ABORT:
+ flags |= ECF_RETURNS_TWICE | ECF_TM_OPS;
+ break;
case BUILT_IN_TM_IRREVOCABLE:
case BUILT_IN_TM_GETTMCLONE_IRR:
case BUILT_IN_TM_MEMCPY:
Strangeness with SSE(1)
I'm seeing the oddest thing with a function compiled like:
mpicc -std=gnu99 -O1 -g -m32 -pthread -msse -mno-sse2 -DHAVE_CONFIG_H
-I../../easel -I../../easel -I. -I.. -I. -I../../src -o fwdback.o -c
fwdback.c
using both gcc versions
gcc (GCC) 4.4.1 (on a 64 bit linux)
gcc (GCC) 4.2.3 (4.2.3-6mnb1) (on a 32 bit linux)
on OMPI 1.4.3.
The compilers are on Opterons, the worker node where it fails is
an Athlon MP. (Shouldn't be any differene with -mno-sse2 off, right?)
Basically it comes down to (many lines of code omitted)
register __m128 xEv;
fprintf(stderr,"DEBUG0 xEV %lld\n",xEv);fflush(stderr);
xEv = _mm_setzero_ps();
fprintf(stderr,"DEBUGB xEV %lld\n",xEv);fflush(stderr); /* problem */
throwing an error when run in Valgrind in a particular program at the
second printf.
==13053== Conditional jump or move depends on uninitialised value(s)
==13053==at 0x4BE50BC: vfprintf (in /lib/libc-2.10.1.so)
==13053==by 0x4BE9411: ??? (in /lib/libc-2.10.1.so)
==13053==by 0x4BE4492: vfprintf (in /lib/libc-2.10.1.so)
==13053==by 0x4BEE7CE: fprintf (in /lib/libc-2.10.1.so)
==13053==by 0x807FC19: forward_engine (fwdback.c:305) <
==13053==by 0x8080289: p7_ForwardParser (fwdback.c:143)
==13053==by 0x8075B08: p7_Tau (evalues.c:442)
==13053==by 0x8076554: p7_Calibrate (evalues.c:109)
==13053==by 0x8061815: calibrate (p7_builder.c:629)
==13053==by 0x80618D6: p7_SingleBuilder (p7_builder.c:393)
==13053==by 0x80570C9: main (jackhmmer.c:1068)
How can xEv possibly be uninitialized in that position? Note the
problem initially manifested much further down in the code here
_mm_store_ss(&xE, xEv);
As far as Valgrind is concerned it starts right after the _mm_setzero_ps().
After my signature is that function from the start down to the DEBUGB
line with all lines present - sorry about the wrap:
David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
-
static int
forward_engine(int do_full, const ESL_DSQ *dsq, int L, const P7_OPROFILE
*om, P7_OMX *ox, float *opt_sc)
{
register __m128 mpv, dpv, ipv; /* previous row values
*/
register __m128 sv; /* temp storage of 1 curr row value in
progress */
register __m128 dcv; /* delayed storage of D(i,q+1)
*/
register __m128 xEv; /* E state: keeps max for Mk->E as we go
*/
register __m128 xBv; /* B state: splatted vector of B[i-1] for
B->Mk calculations */
__m128 zerov; /* splatted 0.0's in a vector
*/
floatxN, xE, xB, xC, xJ; /* special states' scores
*/
int i; /* counter over sequence positions 1..L
*/
int q; /* counter over quads 0..nq-1
*/
int j; /* counter over DD iterations (4 is full
serialization)
*/
int Q = p7O_NQF(om->M);/* segment length: # of vectors
*/
__m128 *dpc = ox->dpf[0];/* current row, for use in
{MDI}MO(dpp,q) access macro */
__m128 *dpp; /* previous row, for use in
{MDI}MO(dpp,q) access macro */
__m128 *rp; /* will point at om->rfv[x] for residue x[i]
*/
__m128 *tp; /* will point into (and step thru) om->tfv
*/
/* Initialization. */
ox->M = om->M;
ox->L = L;
ox->has_own_scales = TRUE;/* all forward matrices control their own
scalefactors */
zerov = _mm_setzero_ps();
for (q = 0; q < Q; q++)
MMO(dpc,q) = IMO(dpc,q) = DMO(dpc,q) = zerov;
xE= ox->xmx[p7X_E] = 0.;
xN= ox->xmx[p7X_N] = 1.;
xJ= ox->xmx[p7X_J] = 0.;
xB= ox->xmx[p7X_B] = om->xf[p7O_N][p7O_MOVE];
xC= ox->xmx[p7X_C] = 0.;
ox->xmx[p7X_SCALE] = 1.0;
ox->totscale = 0.0;
#if p7_DEBUGGING
if (ox->debugging) p7_omx_DumpFBRow(ox, TRUE, 0, 9, 5, xE, xN, xJ,
xB, xC);/* logify=TRUE, =0, width=8, precision=5*/
#endif
for (i = 1; i <= L; i++)
{
fprintf(stderr,"DEBUGA i %d\n",i);fflush(stderr);
dpp = dpc;
dpc = ox->dpf[do_full * i]; /* avoid conditional, use
do_full as kronecker delta */
rp= om->rfv[dsq[i]];
tp= om->tfv;
dcv = _mm_setzero_ps();
xEv = _mm_setzero_ps();
fprintf(stderr,"DEBUGB xEV %lld\n",xEv);fflush(stderr);
Re: Does TYPE_MAX_VALUE (size_type_node) overflow?
* Richard Guenther:
> On Wed, Jan 19, 2011 at 10:53 PM, Florian Weimer wrote:
>> I get strange warnings when I do arithmetic involving TYPE_MAX_VALUE
>> (size_type_node), in particular this code:
>>
>> /* Multiplies MUL1 with MUL2, and adds ADD. Returns (size_t)-1 if the
>> result cannot be be represented as a size_t value. If ADD is
>> null_tree, treat it as a zero constant.
>> */
>> tree
>> build_size_mult_saturated (tree mul1, tree mul2, tree add)
>> {
>> tree max_mul1, result;
>> max_mul1 = TYPE_MAX_VALUE (size_type_node);
>> if (add != NULL_TREE)
>> max_mul1 = size_binop(MINUS_EXPR, max_mul1, add);
>> max_mul1 = size_binop(TRUNC_DIV_EXPR, max_mul1, mul2);
>> result = size_binop (MULT_EXPR, mul1, mul2);
>> if (add != NULL_TREE)
>> result = size_binop (PLUS_EXPR, result, add);
>> return build3 (COND_EXPR, sizetype,
>> build2 (EQ_EXPR, sizetype, mul2, size_zero_node),
>> add == NULL_TREE ? size_zero_node : add,
>> build3 (COND_EXPR, sizetype,
>> build2 (LE_EXPR, sizetype, mul1, max_mul1),
>> result, TYPE_MAX_VALUE (size_type_node)));
>> }
>>
>> Is size_type_node really signed, and does TYPE_MAX_VALUE
>> (size_type_node) lie outside the representable range? Is there an
>> easy way to get a GCC type closely matching size_t in C++?
>
> The size_* functions are supposed to be used with sizetype,
> not with size_type ;) sizetypes are strange beast.
Thanks for the suggestion. TYPE_MAX_VALUE (sizetype) appears to be
-1, as the result of this code in stor-layout.c:
/* sizetype is unsigned but we need to fix TYPE_MAX_VALUE so that it is
sign-extended in a way consistent with force_fit_type. */
max = TYPE_MAX_VALUE (sizetype);
TYPE_MAX_VALUE (sizetype)
= double_int_to_tree (sizetype, tree_to_double_int (max));
Is there a way to obtain the actual maximum value?
Re: IA64: short data segment overflowed issue
On Thu, 06 Jan 2011 09:47:49 -0800 Richard Henderson wrote: > On 01/06/2011 01:17 AM, Karel Gardas wrote: > > BTW: This is on GCC Compile Farm IA64 machine. Now my question is: how > > to solve this issue? Does GCC already support something Intel > > discusses in 2008 here: > > http://software.intel.com/en-us/articles/short-data-segment-overflow-error-on-linux-64-on-itaniumr-architecture/ > > -- i.e. using huge memory model for static data? > > No, we don't. > > I thought for a moment that you might be able to use one of the > standalone (aka kernel/rom) modes, such as -mno-pic or -mauto-pic, > which would certainly solve the got-overflow problem above, but > unfortunately they also change the function calling convention. > You'd not be able to link with libc. > > It should not be hard to add such support to gcc, if you have an > interest. All the appropriate relocations are already defined > in the spec and accepted by the assembler. Hello Richard! GHC (haskell compiler) generates very large C sources with lots of relocations (-G0 does not help) when GHC builds itself. So I would like to have "large data segment" feature! Can you elaborate what exactly needs to be implemented? From what I see: 0. We need additional flag for gcc: let's call it -mhuge-pic 1. We need to force GCC to generate any GP (r1) offsets. Seems, we need to emit some kind of LX instruction to compute absolute data offset in a separate register. What kind of relocation should be that to have ability to mix them with stock ones? 2. We need to fix binutils to be able to relax sections with usual and "huge" types of access to GP. Am I Right? Thank you! -- Sergei signature.asc Description: PGP signature
sucessful make profiledboostrap of gcc-4.6-20110115 on i686-{any}-linux
Hi.
I would like to tell that profiledboostrap does compile on 32 bit intel for
current 4.6 tree snapshot
and therefore 4.6 branch is not affected by this problem -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085
evironment:
AFLAGS="-O2 -march=pentium4 -msse2"
export CXXFLAGS_FOR_BUILD=${AFLAGS}
export CFLAGS_FOR_BUILD=${AFLAGS}
export BOOT_CFLAGS=${AFLAGS}
export LIBCFLAGS=${AFLAGS}
export LIBCXXFLAGS=${AFLAGS}
export CXXFLAGS_FOR_TARGET=${AFLAGS}
export CFLAGS_FOR_TARGET=${AFLAGS}
export CFLAGS=${AFLAGS}
export CXXFLAGS=${CFLAGS}
export JCFLAGS="-O2"
export FCFLAGS="-O2"
configure arguments:
--host=i686-pc-linux --build=i686-pc-linux --disable-nls --with-cpu=core2
--with-arch=pentium4 --enable-languages=c,c++,fortran,go
--disable-stage1-checking --enable-checking=release --enable-threads
--enable-tls --enable-lto --with-fpmath=sse
~ cheers.
gcc-4.5-20110120 is now available
Snapshot gcc-4.5-20110120 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110120/ 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 169071 You'll find: gcc-4.5-20110120.tar.bz2 Complete GCC (includes all of below) MD5=fa882f9f6297f9465474d498de5b5927 SHA1=adb77661e82a3bca1b89bde34cb452d37de07221 gcc-core-4.5-20110120.tar.bz2C front end and core compiler MD5=614ad7e9bc82c61e6089829069b456c9 SHA1=3573cdf1ff30f0e507fb31de0da4deb7dabc902d gcc-ada-4.5-20110120.tar.bz2 Ada front end and runtime MD5=0ac6b21c2776283b4b179ae0476039ae SHA1=67193d8cec8c62491e1a4a8985e98a820e61291e gcc-fortran-4.5-20110120.tar.bz2 Fortran front end and runtime MD5=0a9c05b2968d382b5cb00d231b5da4ca SHA1=e5bcbd46694a9091746f95a3da8b5ad4b15cb30e gcc-g++-4.5-20110120.tar.bz2 C++ front end and runtime MD5=e00d58ddf84386fc4179d03142749870 SHA1=90a5ee27545aa8f7632f91713782c625a5e25ad6 gcc-go-4.5-20110120.tar.bz2 Go front end and runtime MD5=dd2c497a749bdd034ad55fd5222b5ebe SHA1=b8f95e5bfcc514f216a7547f4e889cd11521a237 gcc-java-4.5-20110120.tar.bz2Java front end and runtime MD5=6c134563586b3e6f3438a8914dac01fe SHA1=ee3d2f642a6747f0a4cd38ba5c07387fa986e36c gcc-objc-4.5-20110120.tar.bz2Objective-C front end and runtime MD5=699894f0a783dad8660bca0bcc58519c SHA1=f39d5188434b91d9a63b2f083e2d19454bae09d2 gcc-testsuite-4.5-20110120.tar.bz2 The GCC testsuite MD5=20b7a13bde1ab2d81758b61011185090 SHA1=c1d4b1858ab38040a9a76be40755be14875a72c7 Diffs from 4.5-20110113 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.
Re: IA64: short data segment overflowed issue
On 01/20/2011 01:26 PM, Sergei Trofimovich wrote: > So I would like to have "large data segment" feature! > Can you elaborate what exactly needs to be implemented? > > From what I see: > 0. We need additional flag for gcc: let's call it -mhuge-pic > > 1. We need to force GCC to generate any GP (r1) offsets. >Seems, we need to emit some kind of LX instruction to >compute absolute data offset in a separate register. >What kind of relocation should be that to have ability >to mix them with stock ones? > > 2. We need to fix binutils to be able to relax sections with > usual and "huge" types of access to GP. Depending on how Haskell programs are built, it may be better to avoid the GOT entirely. E.g. -mcmodel=large a-la the x86_64 port. This generates full 64-bit absolute relocations. For ia64 code this would look like movlr32 = foo# Offset Info Type Sym. ValueSym. Name + Addend 0002 00040023 R_IA64_IMM64 foo + 0 Of course, you wouldn't put this code into a shared library. For that you really would want a 64-bit GPREL offset. E.g. movlr32 = @gprel(foo) add r32 = r32, r1 Offset Info Type Sym. ValueSym. Name + Addend 0002 0004002b R_IA64_GPREL64I foo + 0 Since both of these assemble now, really doubt there's any binutils work that needs to be done. What you'd have to do is add some command-line switches (and perhaps clean up the ones that are there wrt code models), and adjust the code in ia64_expand_load_address to handle your new options. It really shouldn't be very difficult. r~
Re: Ping: PR 35998 - DWARF output bug w/ Ada
This bogus size of -1 is causing an informational warning from VMS Debug on IA64 VMS. It would be useful to us if approved and merged. --Douglas Rupp AdaCore
