gmane.comp.gcc.help

Re: Unexpected behaviour printing twice the same variable

Ian Lance Taylor — 2012-05-16T21:59:16



You didn't say, but you are presumably using an x86 in 32-bit mode.

In C, the float type is promoted to double when making a function call.
Your first call to printf takes the 80-bit 387 register, stores it to
the stack as a 64-bit double, and calls printf.  But before calling
printf the 80-bit register is stored on the stack as a 32-bit float,
since that is the variable's type.  For the second call to printf the
32-bit float is loaded from the stack into a 80-bit register, then
stored to the stack as a 64-bit double to pass to printf.

So the problem is the value is rounded one way when stored as a 64-bit
value and rounded a different way when stored as a 32-bit value.  That
is what you are seeing.

The fix is, as you discovered, to use -ffloat-store.  Or, if using GCC
4.5 or newer, to use -fexcess-precision=standard.  Or use -mfpmath=sse
to avoid the 80-bit registers entirely.

Ian

Adding a conditional statement in GCC

Sam K — 2012-05-16T21:55:11

Hello experts,
I have added a pass in GCC.
Here I am adding a conditional statement
Initially my code had both operands of the conditional statement as
local variables and it worked fine.
Then I replaced the local variable with a global variable and I get the error:
Internal compiler error in gimple_set_vuse: gimple.h 1504

Am using gcc4.7.0

My code is as follows:

tree var_decl = NULL;

static unsigned int gccwk_main(void)
{

   basic_block true_bb, join_bb;

   //COND WITH TEMP VAR
   tree tmp1, tmpv;
   gimple cond_stmt;
   tree int_assign;
   gimple assign;
   gimple cond_assign;
   edge e_cd, e_di, e_ci;

   basic_block bb_start = ENTRY_BLOCK_PTR->next_bb;
   gimple_stmt_iterator gsi = gsi_start_bb(bb_start);


   if (!var_decl) {
       var_decl = build_decl(input_location, VAR_DECL,
get_identifier("aa_glob"),integer_type_node);
  }
   TREE_STATIC(var_decl) = 1;
   rest_of_decl_compilation(var_decl,1,0);
   DECL_INITIAL(var_decl) = build_int_cst(integer_type_node, 1);

Unexpected behaviour printing twice the same variable

RobertoCesco — 2012-05-16T15:38:09

Hello all,

This program has a strange behaviour, probably due to FP optimizations using
the -O1 or -O2 or -O3 (I can resolve it with the GCC compilation flag
-ffloat-store).
It should produce the same output twice (because it prints the same variable
in 2 consecutive lines), but it does not; there are some errors on the last
digits. Someone can explain me what happen?

Source:

http://old.nabble.com/file/p33858981/bug.c bug.c 


Compile:

gcc -O3 -o bug bug.c  

Output:

132.316432 132.316437
108.085940 108.085938
134.695360 134.695358
123.992232 123.992233


I tested it with the following systems:

Intel i5, Ubuntu Linaro, kernel 3.0.0-19-generic, GCC 4.6.1-9ubuntu3 
Intel i7, Ubuntu Linaro, kernel 2.6.38-15-generic, GCC 4.5.2-8ubuntu4

Re: Complexity of gcc compiler

Ian Lance Taylor — 2012-05-16T13:52:58


Most of the compiler is linear in the size of the input.  Some specific
optimization passes have a larger complexity.  Some optimization passes
are linear in the number of basic blocks or in the number of
pseudo-registers.  Register allocation is O(n^2) in the number of
pseudo-registers.

Ian

Complexity of gcc compiler

vikram_sp — 2012-05-16T11:28:47

I am wondering what may be the COMPLEXITY of GCC compiler in big Oh 
notation or other notation. 
I have some intuition that lexical analyzer's complexity is O(n) and that of
parser is O(n^3). Optimization is NPC. Code generator might have some 
log(n) factor. 
Taking these things in accounts what is the time complexity of compilers
in general and GCC in particular.
Likewise space complexity may also be given thought?

-----
Vikram

Re: GCC 4.6.2 C++ thread cancellation issue

Jonathan Wakely — 2012-05-15T21:58:37

What evolving C++ standard?

The forced-unwind stuff was designed and implemented years ago, before
ISO C++ talked about threads, and even in the current C++ standard
there is no support for thread cancellation (because there was no
consensus how it should work.)  The forced-unwind behaviour was an
attempt to give sane semantics (for some value of sane) to something
not covered by any standard (at the time, and still not covered now.)


Which are?

It's hard to implement semantics that may or may not be publicly documented.

There was a POSIX-C++ working group which discussed thread
cancellation, but no consensus was reached and the working group
stalled.


On 15 May 2012 20:40, Mike Dalpee wrote:

Understood. But pthreads is a C API, so by using it with C++ you're
already writing non-portable code (it works well, almost invisibly, in
most cases, unfortunately thread-cancellation is one of the places the
non-portability show up.)


Indeed, which is why the GNU implementation uses an exception, as that
alrea

Re: Help with strange error

Jonathan Wakely — 2012-05-15T21:33:59

FWIW, if they sent an HTML email (or multipart mime email with an HTML
part) it would get rejected by the gcc-help list software and not show
up in the archives.

Re: How do I disable warnings across versions?

Vincent Lefevre — 2012-05-15T20:52:25

GCC doesn't need to fix anything. ICC also defines its own macros
(but not in a consistent way), so that the user can test if they
are defined (if __ICC and/or __INTEL_COMPILER are defined, this
is ICC). The user just needs to know that.

RE: GCC 4.6.2 C++ thread cancellation issue

Mike Dalpee — 2012-05-15T19:40:44

Just to be clear, I am using pthread's synchronous cancellation feature - i.e., cancellation can only occur at known "cancellation points", which are places at which the thread is waiting to be rescheduled.  So the cancellation is not asynchrounous with respect to thread execution.

Stack unwinding/destructor excecution does occur in the Solaris C++ implementation from the scope enclosing the cancellation point. In my view, this behavior is required to compose a correctly running program.  A very common approach to resource management in C++ programs is to use a constructor to "acquire" a resource and the destructor to "release" it.  Since a thread is just one part of a running program, being able to cancel a thread without running destructors would be (and for me, is) very bad, as it would hang acquired resources out to dry (such as a mutex lock, for instance) with disastrous results (deadlocks).  

Again in my view, the use of catch(...) is an undesireable practice; if you need something to happen no matte

Re: Help with strange error

SteveSchow — 2012-05-15T18:56:01

someone responded already thank you, I don't know why his response does not
show up here.  In any case, the problem is in the code where ELF assembler
code is being injected into it.  Unfortunately its beyond my pay grade to
fix it, but here it is in case anyone is looking for help on this in the
future or if someone knows how to fix it, please let me know.

--------------

#define __ASM_DEFINE_FUNC(name,suffix,code) asm(".text\n\t.align 4\n\t.globl
" #name suffix "\n\t.type " #name suffix ",< at >function\n" #name suffix
":\n\t.cfi_startproc\n\t" code "\n\t.cfi_endproc\n\t.previous");
#define __ASM_GLOBAL_FUNC(name,code) __ASM_DEFINE_FUNC(name,"",code)
#define __ASM_NAME(name) name
#define __ASM_STDCALL(args) ""

/* From wine source */
#ifdef __i386__  /* thiscall functions are i386-specific */

#define THISCALL(func) __thiscall_ ## func
#define THISCALL_NAME(func) __ASM_NAME("__thiscall_" #func)
#define __thiscall __stdcall
#define DEFINE_THISCALL_WRAPPER(func,args) \
    extern void THISCALL(func)(void); \

Re: Help with strange error

SteveSchow — 2012-05-15T18:55:25

someone responded already thank you, I don't know why his response does not
show up here.  In any case, the problem is in the code where ELF assembler
code is being injected into it.  Unfortunately its beyond my pay grade to
fix it, but here it is in case anyone is looking for help on this in the
future or if someone knows how to fix it, please let me know.

--------------

#define __ASM_DEFINE_FUNC(name,suffix,code) asm(".text\n\t.align 4\n\t.globl
" #name suffix "\n\t.type " #name suffix ",< at >function\n" #name suffix
":\n\t.cfi_startproc\n\t" code "\n\t.cfi_endproc\n\t.previous");
#define __ASM_GLOBAL_FUNC(name,code) __ASM_DEFINE_FUNC(name,"",code)
#define __ASM_NAME(name) name
#define __ASM_STDCALL(args) ""

/* From wine source */
#ifdef __i386__  /* thiscall functions are i386-specific */

#define THISCALL(func) __thiscall_ ## func
#define THISCALL_NAME(func) __ASM_NAME("__thiscall_" #func)
#define __thiscall __stdcall
#define DEFINE_THISCALL_WRAPPER(func,args) \
    extern void THISCALL(func)(void); \

Re: Help with strange error

Ian Lance Taylor — 2012-05-15T18:22:42


Your compiler is generating code that your assembler does not expect.
Or, your source code has asm statements that have pseudo-ops that your
assembler does not expect.  The errors suggest that you are passing ELF
assembler pseudo-ops to a non-ELF assembler.  The Darwin assembler is,
of course, not an ELF assembler.  You need to find out why either GCC or
your source code is expecting an ELF assembler.

Ian

Help with strange error

SteveSchow — 2012-05-15T18:15:37

I have never seen this kind of error before and I'm not at all sure what I
can do to correct it.  If anyone has any ideas what would cause this error
so that I can dig deeper I would appreciate insights.

I'm using i686-apple-darwin10-gcc-4.2.1 on OSX 10.6.8

---------------------

gcc -c -I. -I/usr/include -I/Users/sjs/wine/wine-1.5.4/include
-I/Users/sjs/wine/wine-1.5.4/include/wine
-I/Users/sjs/wine/wine-1.5.4/include/wine/windows    -m32 -g -O2
-D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
-Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -o asio.o
asio.c
{standard input}:36:Unknown pseudo-op: .type
{standard input}:36:Rest of line ignored. 1st junk character valued 95 (_).
{standard input}:38:Unknown pseudo-op: .cfi_startproc
{standard input}:43:Unknown pseudo-op: .cfi_endproc
{standard input}:44:Unknown pseudo-op: .previous
{standard input}:48:Unknown pseudo-op: .type
{standard input}:48:Rest of line ignored. 1st junk character valued 95 (_).
{standard input}:50:Unknown

Re: How do I disable warnings across versions?

Ian Lance Taylor — 2012-05-15T15:06:57


Unfortunately there is nothing GCC can do to fix that problem.  If we
introduce __GNUC_THIS_IS_THE_REAL_GCC__ then other compilers will define
that as well.


Historical.

Ian

Re: GCC 4.6.2 C++ thread cancellation issue

Ian Lance Taylor — 2012-05-15T15:00:11


I agree that this is a real bug.  On the other hand I've always
considered asynchronous thread cancellation to be a rather shaky
proposition.  Apparently Solaris has managed to do a good implementation
of it, but it's never going to be portable.

The root issue here is that glibc implements thread cancellation as an
exception, using the language independent exception mechanisms.  Those
mechanisms are designed to let one language catch an exception thrown by
another language, which is not what you want to have happen here.  In
fact this exception should not be caught at all.

Glibc does this because it lets it rely on the existing exception
mechanisms to efficiently implement pthread_cleanup_push.  It also lets
pthread_cancel run C++ destructors; I don't know if that is a good idea
or not.  Does that happen on Solaris?  I don't know if this is covered
by any OS or language standards.  C++ did not discuss threads at all
before C++11, and as far as I know C++11 has no asynchronous thread
cancellation facility

Re: How do I disable warnings across versions?

Vincent Lefevre — 2012-05-15T14:17:56

Hmm, yes, these macros are actually used by MPFR. Note that these
macros are also by Intel's compiler ICC, which tries to emulate
some GCC features, but doesn't behave exactly like GCC. :( This
is a problem for portable code.

For those interested, we currently have the following:

#define MPFR_VERSION_NUM(a,b,c) (((a) << 16L) | ((b) << 8) | (c))

#if defined(_WIN32)
/* Under MS Windows (e.g. with VS2008 or VS2010), Intel's compiler doesn't
   support/enable extensions like the ones seen under GNU/Linux.
   https://sympa.inria.fr/sympa/arc/mpfr/2011-02/msg00032.html */
# define __MPFR_ICC(a,b,c) 0
#elif defined(__ICC)
# define __MPFR_ICC(a,b,c) (__ICC >= (a)*100+(b)*10+(c))
#elif defined(__INTEL_COMPILER)
# define __MPFR_ICC(a,b,c) (__INTEL_COMPILER >= (a)*100+(b)*10+(c))
#else
# define __MPFR_ICC(a,b,c) 0
#endif

#if defined(__GNUC__) && defined(__GNUC_MINOR__) && ! __MPFR_ICC(0,0,0)
# define __MPFR_GNUC(a,i) \
 (MPFR_VERSION_NUM(__GNUC__,__GNUC_MINOR__,0) >= MPFR_VERSION_NUM(a,i,0))
#else
# define __MPFR_

RE: GCC 4.6.2 C++ thread cancellation issue

Mike Dalpee — 2012-05-15T13:48:25

Ian,

Thanks very much for taking the time to explain the situation, however dissapointing it might be :)

But here's the thing.  With Solaris C++, thread cancellation just worked - when a thread is cancelled, the stack is unwound, destructors run, and there is no visibility outside the runtime of the mechanism used to accomplish that.  I guess I don't see why the g++ runtime could not do the same thing, and rather than exposing the "foreign" thread cancellation exception abi::__forced_unwind to the outside world, thereby requiring special handling for it to even have a chance of  working properly, instead keep it hidden and treat it as a one-of-a-kind, special "foreign" exception that just causes stack unwinding/destructor execution.  

Of course, I realize this is likely the topic of much debate, and gcc's implemention is probably an attempt to be compliant with the evolving c++ standard.  But clearly, g++'s approach is highly flawed, so perhaps the standard needs to be driven in a way such that g++ can ul

Re: How do I disable warnings across versions?

Segher Boessenkool — 2012-05-15T13:05:02

#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 7)

(there is also __GNUC_PATCHLEVEL__ for the third component).


That's probably why it was added then, in prehistoric times already :-)


Segher

Re: How do I disable warnings across versions?

Vincent Lefevre — 2012-05-15T12:50:41

I suppose that this is intentional, as
http://gcc.gnu.org/gcc-4.4/changes.html says:

  Unknown -Wno-* options are now silently ignored by GCC if no other
  diagnostics are issued. If other diagnostics are issued, then GCC
  warns about the unknown options.


They don't exist.

$ gcc-4.7 -dM -E -xc /dev/null | grep GCC
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __GCC_HAVE_DWARF2_CFI_ASM 1
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
#define __GCC_ATOMIC_SHORT_LOCK_FREE 2

GMP and MPFR have such macros. It would be a

Re: How do I disable warnings across versions?

Manuel López-Ibáñez — 2012-05-15T10:29:35

And I think that in the same way we ignore -Wno-foo if no warnings are
given, we should ignore:


Please open a PR.

Note that you can test for the exact version of GCC with #ifdef
GCC_MAJOR >= 4 && GCC_MINOR >= 7.

Cheers,

Manuel.

Re: How do I disable warnings across versions?

Vincent Lefevre — 2012-05-15T10:22:22

I think that

#pragma GCC diagnostic ignored "-Wpragmas"

is exactly what you want. For instance,

#pragma GCC diagnostic ignored "-Wpragmas"
#pragma GCC diagnostic ignored "-Wuninitialized"
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
#pragma GCC diagnostic ignored "-Wfoo"
#pragma GCC diagnostic warning "-Wpragmas"
#pragma GCC diagnostic ignored "-Wbar"

will just give a warning concerning -Wbar.