Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?
Richard Henderson wrote: On Thu, Apr 14, 2005 at 05:26:15PM -0700, Mark Mitchell wrote: Richard, what's your level of confidence here? I'd rather not break C++ or Java... I think it's pretty safe. OK, Alexandre, please install the patch. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Heads-up: volatile and C++
On Apr 15, 2005, Marcin Dalecki [EMAIL PROTECTED] wrote: On 2005-04-15, at 01:10, Richard Henderson wrote: templateclassname T T acquire(T *ptr); templateclassname T void release(T *ptr, T val); where the functions do the indirection plus the memory ordering? Templates are a no-go for a well known and well defined subset for C++ for embedded programming known commonly as well embedded C++. It doesn't really have to be templates. Consider static_cast et al. They look like template function calls, but aren't. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Heads-up: volatile and C++
Laurent GUERBY [EMAIL PROTECTED] writes: | I'm including the standard annotations, they have no standard | value but sometimes do help. [...] Thanks! -- Gaby
Re: Heads-up: volatile and C++
Richard Henderson [EMAIL PROTECTED] writes: | On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote: | Consider Double-Checked Locking | (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html). | I used DCL with explicit memory barriers to implement thread-safe | initialization of function-local statics | (libstdc++-v3/libsupc++/guard.cc). The proposed change to volatile | semantics would allow me to write it more simply, by just making the | initialized flag volatile. Yes, volatile would be stronger than is | actually necessary for DCLP, but I don't have to use it if I want | finer-grained control over the synchronization. | | Is there any reason to want to overload volatile for this, rather than | | templateclassname T T acquire(T *ptr); | templateclassname T void release(T *ptr, T val); | | where the functions do the indirection plus the memory ordering? My understanding what that some compilers may do speculative register promotion. (I think the example given by Hans actually involved lock()/unlock() not acquire/release). | The biggest problem that I see is that C and C++ have been around far | too long, and there are far too many existing uses of volatile to be | redefining it now. That is a legitime concern that was raised. I think examples of cases that would be inadvertently affected would be very helpful. -- Gaby
Re: Heads-up: volatile and C++
On Thu, 2005-04-14 at 23:33 +0200, Jason Merrill wrote: On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar [EMAIL PROTECTED] wrote: [Ada standard] Yep, sounds a lot like C/C++: volatile reads and writes are required to have sequential ordering relative to each other, but (outside the current thread) they are not ordered relative to non-volatile reads and writes. Here's an extract from section 9.10 (sequential): 15.a Ramification: If two actions are ``sequential'' it is known that their executions don't overlap in time, but it is not necessarily specified which occurs first. For example, all actions of a single task are sequential, even though the exact order of execution is not fully specified for all constructs. 15.b Discussion: Note that if two assignments to the same variable are sequential, but neither signals the other, then the program is not erroneous, but it is not specified which assignment ultimately prevails. Such a situation usually corresponds to a programming mistake, but in some (rare) cases, the order makes no difference, and for this reason this situation is not considered erroneous nor even a bounded error. In Ada 83, this was considered an ``incorrect order dependence'' if the ``effect'' of the program was affected, but ``effect'' was never fully defined. In Ada 95, this situation represents a potential nonportability, and a friendly compiler might want to warn the programmer about the situation, but it is not considered an error. An example where this would come up would be in gathering statistics as part of referencing some information, where the assignments associated with statistics gathering don't need to be ordered since they are just accumulating aggregate counts, sums, products, etc. Ciao, Duncan.
some problem about cross-compile the gcc-2.95.3
first i download the release the version of gcc-2.95.3, binutils 2.15,
and i use the o32 lib, include of gcc3.3.3 .
1. compile the binutils and install it
mkdir binutils-build;
cd binutils-build;
../../binutils-2.15/configure --prefix=/opt/gcc --target=mipsel-linux -v;
make;make install;
2. cp -r ../../lib /opt/gcc/mipsel-linux/
cp -r ../../include /opt/gcc/mipsel-linux/
3. compile the gcc
mkdir gcc-build;
cd gcc-build;
../../gcc-2.95.3/configure --prefix=/opt/gcc --target=mipsel-linux
--enable-languages=c -enable-shared -disable-checking -v;
make;
then the ERROR happened:
make[1]: Entering directory
`/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc'
(cd intl make all)
make[2]: Entering directory
`/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/intl'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/intl'
if [ -f libgcc2.ready ] ; then \
true; \
else \
touch libgcc2.ready; \
fi
rm -f tmplibgcc2.a
for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _lshrdi3
_ashldi3 _ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2
_floatdidf _floatdisf _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi
_fixunssfdi _fixsfdi _fixxfdi _fixunsxfdi _floatdixf _fixunsxfsi _fixtfdi
_fixunstfdi _floatditf __gcc_bcmp _varargs __dummy _eprintf _bb _shtab
_clear_cache _trampoline __main _exit _ctors _pure; \
do \
echo ${name}; \
/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/xgcc
-B/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/
-B=/opt/gcc-2.95//mipsel-linux/bin/
-I=/opt/gcc-2.95//mipsel-linux/include -DCROSS_COMPILE -DIN_GCC
-I./include -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I/usr/include
-I. -I../../../gcc-2.95.3/gcc -I../../../gcc-2.95.3/gcc/config
-I../../../gcc-2.95.3/gcc/../include -c -DL${name} \
../../../gcc-2.95.3/gcc/libgcc2.c -o ${name}.o; \
if [ $? -eq 0 ] ; then true; else exit 1; fi; \
mipsel-linux-ar rc tmplibgcc2.a ${name}.o; \
rm -f ${name}.o; \
done
_muldi3
as: unrecognized option `-O2'
make[1]: *** [libgcc2.a] Error 1
make[1]: Leaving directory
`/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc'
i am very confused about the error.
is there something wrong with my Makefile?
the as should be mipsel-linux-as
is it?
Re: Processor-specific code
[speaking of an environnement variable used to set IEEE rounding mode] You'll find that globally changing the rounding mode will screw up libm functions. Which is pretty much going to make this useless. Further, when folks need rounding modes other than round-to-nearest, they tend to need to switch rounding modes during the program too. For instance, to perform the same calculation with both round-up and round-down to get error bounds on the calculation. Thus I think an environment variable to do this is doubly useless. Understood. I only tried to write that code because the mechanism for reading these environment variables is already in the source (as well as documentation on what effect they should have). Currently, when the runtime library is loaded, it look at: GFORTRAN_FPU_ROUND: Set floating point rounding. Values are NEAREST, UP, DOWN, ZERO. GFORTRAN_FPU_PRECISION: Precision of intermediate results. Values are 24, 53 and 64. GFORTRAN_FPU_INVALID: Raise a floating point exception on invalid FP operation. GFORTRAN_FPU_DENORMAL: Raise a floating point exception when denormal numbers are encountered. GFORTRAN_FPU_ZERO: Raise a floating point exception when dividing by zero. GFORTRAN_FPU_OVERFLOW: Raise a floating point exception on overflow. GFORTRAN_FPU_UNDERFLOW: Raise a floating point exception on underflow. GFORTRAN_FPU_PRECISION: Raise a floating point exception on precision loss. So, if we all agree that some of those are useless, we should remove them from the code. My humble opinion is: 1. I don't think GFORTRAN_FPU_PRECISION is useful 2. GFORTRAN_FPU_INVALID and all other FPE control options are very useful, and we want to implement those ones (this is really something one could want to turn on at runtime, perhaps just to debug one's code). 3. GFORTRAN_FPU_ROUND: I have no precise idea (in the long term, we will provide subroutines so that the code can control rounding mode). All that said, C99 has fenv.h to control just about anything you could want about the fpu. As the linux manpage for The C99 standard does not define a way to set individual bits in the floating point mask, e.g. to trap on specific flags. So, unless I am mistaken, if you want to raise a FPE on dividing by zero, there is no C99 way to do it. So I guess we will have to write some non-standard C at some point. Linux provide feenableexcept, but on darwin I don't know any way to do that without using assembly code. See Arnaud's link for a compilation of tricks people have used to do this. FX
Re: Heads-up: volatile and C++
On Thu, 14 Apr 2005 15:26:32 -0400, Michael N. Moran [EMAIL PROTECTED] wrote: Again, I understand the need for ordering/synchronization, I simply do not believe that volatile should be overloaded to include these semantics. Part of my point is that there are existing uses of volatile which whose performance would suffer should ordering and/or synchronization instructions be added around each access. For example, device drivers that perform memory mapped I/O on memory spaces which are guarded and thus need no additional ordering/synchronization instructions. You mentioned PowerPC in a previous post; while device memory doesn't need as much explicit ordering as cached memory, http://www-128.ibm.com/developerworks/eserver/articles/powerpc.html says All these rules don't prevent stores to device memory from being issued out of program order with respect to loads from device memory, or vice versa. Instead, the memory-barrier instructions, eieio and sync, must be used when out of order operations could yield incorrect results. you need an eieio between loads and stores, or between two loads, to ensure proper ordering. Yes, the proposed volatile semantics are more than you need. But you do need something. That said, perhaps the current volatile semantics are a useful primitive for building on with more specific explicit ordering, but that's not clear to me. Jason
Re: bootstrap compare failure in ada/targparm.o on i686-pc-linux-gnu?
On Apr 15, 2005, Mark Mitchell [EMAIL PROTECTED] wrote: Richard Henderson wrote: On Thu, Apr 14, 2005 at 05:26:15PM -0700, Mark Mitchell wrote: Richard, what's your level of confidence here? I'd rather not break C++ or Java... I think it's pretty safe. OK, Alexandre, please install the patch. It's in. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: GCC 4.0 RC2
On Thursday 14 April 2005 21:05, Mark Mitchell wrote: Could you add http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01107.html to your list? If the patch is OKed by rth (ping! :-), it would fix a -fPIC ICE regression on IA32 and AMD64. So added. Will you please let me know if the patch is approved for mainline? It was already rejected by rth. Gr. Steven
Re: Patches for coldfire v4e
--- Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Thu, Apr 14, 2005 at 09:36:59AM +0200, Bernardo Innocenti wrote: Daniel Jacobowitz wrote: On Wed, Apr 13, 2005 at 10:10:39AM +0200, Bernardo Innocenti wrote: So it seems adding coldfire-linux is the only way to address this... Why? Adding support (if it isn't already there) for something like --with-arch=coldfire should work just as well. But how do we change behavior in gcc/config/t-linux according to the switch? You probably don't need to. The newly built compiler will default to the right architecture; any assembly routines can be keyed off an appropriate builtin define. Will there be any issues with binutils? Assembler should also default to this architecture (coldfire). These were the additions i had to make to t-linux for coldfire LIB1ASMSRC = m68k/lb1sf68.asm LIB1ASMFUNCS = _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 \ _double _float _floatex \ _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 \ _eqsf2 _nesf2 _gtsf2 _gesf2 _ltsf2 _lesf2 LIB2FUNCS_EXTRA = fpgnulib.c xfgnulib.c fpgnulib.c: $(srcdir)/config/m68k/fpgnulib.c cp $(srcdir)/config/m68k/fpgnulib.c fpgnulib.c xfgnulib.c: $(srcdir)/config/m68k/fpgnulib.c echo '#define EXTFLOAT' xfgnulib.c cat $(srcdir)/config/m68k/fpgnulib.c xfgnulib.c MULTILIB_OPTIONS = mcfv4e EXTRA_MULTILIB_PARTS= crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o EXTRA_MULTILIB_OPTIONS=-mcfv4e LIBGCC = stmp-multilib INSTALL_LIBGCC = install-multilib Can these also be taken care of? LIB2FUNCS_EXTRA? EXTRA_MULTILIB_PARTS? etc Regards, C Jaiprakash __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re: some problem about cross-compile the gcc-2.95.3
On 15 Apr 2005 at 14:56, zouq wrote: first i download the release the version of gcc-2.95.3, binutils 2.15, This message should go to the crossgcc list... But it is nowadays filled with bolsheviks demanding everyone to start from absolute scratch, so wacky advices expected there :-( So maybe this list starts to be the one for those who cannot understand the ideas about starting from scratch, avoiding preinstalling anything from the (usually proprietary/custom) target systems and replacing it with totally self-built (library) stuff... So people who need crosstools for Solaris2, AIX, LynxOS, RedHat, SuSE etc. are adviced to build glibc as the C library, of course the C library being an essential part of GCC just like the binutils and everyone being obliged to build all these GCC components from scratch... People are like chaff in the wind..., these people really believe to their bullshitism/bolshevism and think they are creating a better and perfect world this way, with these ideas... Ok, here we are talking about recycling, re-use and other things some others think the creating a better and perfect world means. Like using existing C libraries for the target instead of being obliged to rebuild them 2. cp -r ../../lib /opt/gcc/mipsel-linux/ cp -r ../../include /opt/gcc/mipsel-linux/ There is a well-known bug in GCC and putting the target headers to the '$prefix/$target/include' is not enough, some of them or maybe them all must also be seen in the '$prefix/$target/sys-include'. At least the 'limits.h', 'stdio.h', 'stdlib.h', 'string.h', 'time.h' and unistd.h' are required with the current GCCs. Seeing them all may work, sometimes the 'fixinc*' stuff makes garbage from the original headers... I don't remember the case with gcc-2.95.3. My advice is to symlink/copy only those six headers into the '.../sys-include'. 3. compile the gcc mkdir gcc-build; cd gcc-build; .../../gcc-2.95.3/configure --prefix=/opt/gcc --target=mipsel-linux Are you simply not telling the truth here or what? Please see later... --enable-languages=c -enable-shared -disable-checking -v; make; /home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/xgcc -B/home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc/gcc/ -B=/opt/gcc-2.95//mipsel-linux/bin/ This '-B' option tells that you used a --prefix=/opt/gcc-2.95, not the --prefix=/opt/gcc you told earlier, when configuring GCC !!! Using JUST THE SAME PREFIX in both configures is the expected thing, otherwise you are asking serious problems... -I=/opt/gcc-2.95//mipsel-linux/include -DCROSS_COMPILE -DIN_GCC -I./include -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I/usr/include Trying to get (native) headers from '/usr/include' is a bug here... Especially when the host isn't a Linux. _muldi3 as: unrecognized option `-O2' An option understood by a MIPS target 'as' was given to the native 'as'... This is one of the serious problems I told about... the as should be mipsel-linux-as When we are talking about FBB (FSF's Bad Boy), an AI being a step forwards from GCC (like IBM - HAL), then this FBB would use those '$target-tool' things... The situation now is that only humans and scripts written by humans use them... GCC uses those seen with the './xgcc -print-search-dirs' with the new GCC driver... (Hmm, when GCC becomes FBB, then GCJ becomes FBI, maybe called like this because cops like coffee :-) Just fix your $prefix and try again after writing 'make distclean' in your build directory: /home/mytask/mywork/WHAT_I_HAVE_DONE/mycompile/gcc-2.95.3-build/gcc Then set the 'sys-include' stuff and use the aimed '--prefix=/opt/gcc' in the GCC configure... Cheers, Kai
ppc32/e500/no float - undefined references in libstdc++ _Unwind_*
Hello! I guess I need some help to verify my toolchain. My host=target=embedded mpc8540 (e500 core) processor which has no fpu. I am working with: [EMAIL PROTECTED]:/$gcc -v Reading specs from /usr/local/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/specs Configured with: ../gcc-3.4-20050408/configure --with-float=soft --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++,objc --enable-nls=yes --enable-clocale=gnu Thread model: posix gcc version 3.4.4 20050408 (prerelease) [EMAIL PROTECTED]:/$gcc -print-multi-lib .;@[EMAIL PROTECTED] nof;@[EMAIL PROTECTED]@mstrict-align [EMAIL PROTECTED]:/usr/lib$ l libstdc++.* -rw-r--r--1 root root 1721590 Apr 6 12:17 libstdc++.a lrwxrwxrwx1 root root 18 Apr 6 12:18 libstdc++.so - libstdc++.so.5.0.5 lrwxrwxrwx1 root root 18 Apr 6 12:18 libstdc++.so.5 - libstdc++.so.5.0.5 -rwxr-xr-x1 root root 857824 Apr 6 12:17 libstdc++.so.5.0.5 [EMAIL PROTECTED]:/usr/lib$ l ../local/lib/nof/libstdc++.* -rw-r--r--1 root root 7298624 Apr 12 20:31 ../local/lib/nof/libstdc++.a -rwxr-xr-x1 root root 1307 Apr 12 20:31 ../local/lib/nof/libstdc++.la lrwxrwxrwx1 root root 18 Apr 12 20:31 ../local/lib/nof/libstdc++.so - libstdc++.so.6.0.3 lrwxrwxrwx1 root root 18 Apr 12 20:31 ../local/lib/nof/libstdc++.so.6 - libstdc++.so.6.0.3 -rwxr-xr-x1 root root 5433010 Apr 12 20:31 ../local/lib/nof/libstdc++.so.6.0.3 [EMAIL PROTECTED]:/usr/lib$ But when I compile X6.7.2 I get undefined references in the nof/libstdc++: make[4]: Entering directory `/share/home/clemens/newbuild/xc/programs/glxinfo' gcc -O2 -fno-strict-aliasing -fsigned-char -I../.. -I../../exports/include -Dlinux -D__powerpc__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DDO_GLU-c -o glxinfo.o glxinfo.c rm -f glxinfo gcc -o glxinfo -O2 -fno-strict-aliasing -fsigned-char -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -lpthread -lm -Wl,-rpath-link,../../exports/lib /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[4]: *** [glxinfo] Error 1 make[4]: Leaving directory `/share/home/clemens/newbuild/xc/programs/glxinfo' make[3]: *** [all] Error 2 make[3]: Leaving directory `/share/home/clemens/newbuild/xc/programs' make[2]: *** [all] Error 2 make[2]: Leaving directory `/share/home/clemens/newbuild/xc' make[1]: *** [World] Error 2 make[1]: Leaving directory `/share/home/clemens/newbuild/xc' make: *** [World] Error 2 So I am concerned if my configuration is correct or is there a problem with the lib? What is _the_ recommended way to build a toolchain for the mpc8540 for the latest mainline? Is the -mfloat-gprs working? Thanks, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
[PATCH] RE: gcc for syntax check only (C): need to read source from stdin
Original Message From: Zack Weinberg Sent: 12 April 2005 18:31 Dave Korn [EMAIL PROTECTED] writes: Then the error message *really* ought to say gcc: -E or -x required when input is from standard input since it is thoroughly obtuse and non-explanatory as it stands. The attached is against 4.0 RC1, but I imagine it'll apply cleanly to HEAD with just a little fuzz, if people feel it's the right thing. Yes, I think this is the right thing. Please test against mainline and apply it there if successful. I don't think it is important enough to put into 4.0.0, but you should put it on the 4.0 branch after the release, and maybe the 3.4 branch as well. zw Tested on HEAD with --enable-languages=c,c++ by running make check-gcc check-libstdc++ check-gcc-c++ (yes I know there's some redundant redundancy in that list of targets) and then diff'ing the before-and-after outputs from test_summary to make sure nothing changed (as well as eyeballing the summary figures); nothing did. Final patch attached (it hasn't changed any). It's a trivial patch, but I have an assign on file and in fact my employer disclaimer is in the post as we speak. (Finally got it signed just the other day, hooray!) No write privs; Zack, would you be so kind? TIA! 2005-12-04 Dave Korn [EMAIL PROTECTED] * gcc.c (default_compilers): Clarify obscure error message when reading from standard input. cheers, DaveK -- Can't think of a witty .sigline today obscure-error-message-patch.diff Description: Binary data
Re: Heads-up: volatile and C++
Jason Merrill wrote: On Thu, 14 Apr 2005 15:26:32 -0400, Michael N. Moran [EMAIL PROTECTED] wrote: For example, device drivers that perform memory mapped I/O on memory spaces which are guarded and thus need no additional ordering/synchronization instructions. You mentioned PowerPC in a previous post; while device memory doesn't need as much explicit ordering as cached memory, http://www-128.ibm.com/developerworks/eserver/articles/powerpc.html says All these rules don't prevent stores to device memory from being issued out of program order with respect to loads from device memory, or vice versa. Instead, the memory-barrier instructions, eieio and sync, must be used when out of order operations could yield incorrect results. you need an eieio between loads and stores, or between two loads, to ensure proper ordering. Yes, the proposed volatile semantics are more than you need. But you do need something. This is not true regarding access to pages of memory marked guarded (e.g.. memory mapped I/O.) Such pages ensure that access are not re-ordered by the processor. See the table under Memory barrier instructions That said, perhaps the current volatile semantics are a useful primitive for building on with more specific explicit ordering, but that's not clear to me. I'm very much in favor of fine grained synchronization primitives in the compiler, but not of changes to volatile semantics. -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144http://mnmoran.org So often times it happens, that we live our lives in chains and we never even know we have the key. The Eagles, Already Gone The Beatles were wrong: 1 1 1 is 1
Stack and Function parameters alignment
Hello All, The CPU ,I am porting GCC to , has PUSH instruction for half-word (byte) and PUSH instruction for word as well. GCC is using them well, until I was told to add a command-line option which allows GCC to align on word. It has been done, however, there samoe problems. GCC generates following code: PUSH AL ; AL is 8-bit reister INC S ; increment stack pointer This is correct code, but it is longer than PUSH A ; where A is 16 bit register And if RAM does not allow access on ODD addresses. I have define following macros as follows / *tm.h */ #define PARM_BOUNDARY (TARGET_STACK_BYTE_ALLIGN?BITS_PER_WORD / 2: BITS_PER_WORD) #define STACK_BOUNDARY ((TARGET_STACK_BYTE_ALLIGN?BITS_PER_WORD / 2: BITS_PER_WORD)) /***/ In .md file have defined (define_expand pushqi [ (set (mem:QI (post_inc (reg:HI S_HREG))) (match_operand:QI 0 general_operand ) ) ] ) (define_insn *pushqi [(set (mem:QI (post_inc (reg:HI S_HREG))) (match_operand:QI 0 general_operand b))] TARGET_STACK_BYTE_ALLIGN push\t%0\t; *pushqi [(set_attr cc none)] ) (define_insn *pushqi_word_aligned [(set (mem:QI (post_inc (reg:HI S_HREG))) (match_operand:QI 0 general_operand b))] !TARGET_STACK_BYTE_ALLIGN # [(set_attr cc none)] ) (define_split [(set (mem:QI (post_inc (reg:HI S_HREG))) (match_operand:QI 0 general_operand b))] !TARGET_STACK_BYTE_ALLIGN [ (set (match_dup 1) (match_dup 0) ) (set (mem:HI (post_inc (reg:HI S_HREG))) (match_dup 1) ) ] operands[1] = gen_rtx(REG, HImode, A_HREG); ) The asm code I expect this RTL to generate is PUSH A BUT instead of that it generates PUSH A ; stack is even INC S ; incorrect (the stack is ODD) What am I doing wrong ? Can somebody tell me how to solve this problem ? Regards Petar Penchev Software engineer
Re: Stack and Function parameters alignment
On Friday 15 April 2005 13:33, Petar Penchev wrote: Hello All, The CPU ,I am porting GCC to , has PUSH instruction for half-word (byte) and PUSH instruction for word as well. GCC is using them well, until I was told to add a command-line option which allows GCC to align on word. It has been done, however, there samoe problems. GCC generates following code: PUSH AL ; AL is 8-bit reister INC S ;increment stack pointer This is correct code, but it is longer than PUSH A ; where A is 16 bit register... Obviously this only works on little-endian targets. ... [(set (mem:QI (post_inc (reg:HI S_HREG))) (match_operand:QI 0 general_operand b))] !TARGET_STACK_BYTE_ALLIGN [ (set (match_dup 1) (match_dup 0) ) (set (mem:HI (post_inc (reg:HI S_HREG))) (match_dup 1) ) ] operands[1] = gen_rtx(REG, HImode, A_HREG); ) A post_inc increments by the size of the memory access. A define_split is supposed to replace one insn by multiple insns that do the same thing. You're replacing a byte increment with a word increment. You could try adding a define_peephole2 that turns push al; inc S into push a. Paul
Re: Heads-up: volatile and C++
Marcin == Marcin Dalecki [EMAIL PROTECTED] writes: Marcin Templates are a no-go for a well known and well defined Marcin subset for C++ for embedded programming known commonly as Marcin well embedded C++. I don't think that's a good argument. If people want to emasculate the language, that's their problem. Especially given that templates work perfectly well in embedded systems -- we use them (and other features of real C++) in embedded systems here all the time. paul
Questions on CC
---BeginMessage--- I am trying to install gcc on RedHat Enterprise Linux 3. I do not have a compiler installed on the system. I see that gcc requires a ISO C90 compiler. Where can I get one? Also, when I try to configure gcc for install, I get an error that states that I need to set cc environmental variable to a working compiler. I think this will be taken care of when I install a ISO C90 compiler. Any help you can give me would be great. Thanks, Tim Bowers smime.p7s Description: S/MIME Cryptographic Signature ---End Message--- smime.p7s Description: S/MIME Cryptographic Signature
Re: Processor-specific code
On Thu, 2005-04-14 at 18:35, Richard Henderson wrote: On Thu, Apr 14, 2005 at 05:27:16PM +0200, François-Xavier Coudert wrote: No, since reading GFORTRAN_FPU_* variables changes the FPU mode when the library is loaded, while TR 15580 commands will be ran afterwards (during execution). You'll find that globally changing the rounding mode will screw up libm functions. Which is pretty much going to make this useless. Further, when folks need rounding modes other than round-to-nearest, they tend to need to switch rounding modes during the program too. For instance, to perform the same calculation with both round-up and round-down to get error bounds on the calculation. Thus I think an environment variable to do this is doubly useless. Not all environments can change the rounding mode dynamically. For example, on the FPA co-processor for ARM, rounding is set by the instruction selected -- so the concept of having an environment variable to control this is meaningless. R.
Re: [m68k]: More trouble with byte moves into Address registers
Peter Barada [EMAIL PROTECTED] writes:
Which debugging dump has the output from local-alloc? If its
pp_pack.c.24.lreg, then that is the output I supplied in the original
message which contains(for all bits regarding register 1420 up until
the compilation fails):
Sorry, guess I missed that.
(insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 1421)
(plus:SI (subreg:SI (reg:QI 1420) 0)
(const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list 5558
(nil))
(nil))
So register 1420 is being assigned to a data register. The
constraints for addsi3_5200 permit the following alternatives:
mem += datareg
addrreg = addrreg + reg|constant
addrreg = reg|constant + addrreg
reg += mem|reg|constant
There is no alternative which permits adding a data register and a
constant and putting the result in an address register. So reload
picks the alternative addrreg = addrreg + reg|constant, and decides
to reload register 1420 into an address register. But that fails
because reload can't find an address register which can accept a
QImode value.
Looking at the dump a little more, it's far from clear why register
1421 is being put into an address register. I see that insn 5560
wants to compare a byte value which it finds there, so it doesn't seem
like a good fit to put 1421 into an address register.
I don't know where else register 1421 is being used, so my tentative
guess would be that gcc is picking an address register based on the
constraints in addsi3_5200. Perhaps you need to change ?a to *a.
After all, you probably don't want to encourage pseudos to go into the
address registers merely because you add values to them.
But it is also possible that register 1421 is being put into an
address register merely because all the data registers are taken and
there is nothing which forces 1421 to be in a data register.
Or, you might permit an alternative a a*r rJK in addsi3_5200. You
can implement that using a two instruction sequence--copy the data
register to the address register, and then add. This is obviously not
ideal, but it's more or less what reload would be doing anyhow.
In general, though, I'm not sure that prohibiting QImode values in
address registers is going to be a useful approach. After all, the
values do fit there, and while we want to discourage it, it's not
obvious that we want to completely prohibit it. The problem in PR
18421 is that reload decided that it had to reload a QImode value from
memory into an address register, but it couldn't. That is more or
less easy to handle by defining SECONDARY_RELOAD_CLASS to indicate
that a data register is required to move QImode values between the
address registers and memory, and by defining reload_inqi and
reload_outqi to do the moves.
Ian
Re: Processor-specific code
Richard Earnshaw wrote: Not all environments can change the rounding mode dynamically. For example, on the FPA co-processor for ARM, rounding is set by the instruction selected -- so the concept of having an environment variable to control this is meaningless. Right, such a feature obviously does not apply to hardware that is this far from the IEEE standard (which requires dynamic control). The Alpha architecture has similar problems.
Re: Questions on CC
Timothy Bowers wrote: I am trying to install gcc on RedHat Enterprise Linux 3. I do not have a compiler installed on the system. I see that gcc requires a ISO C90 compiler. Where can I get one? Also, when I try to configure gcc for install, I get an error that states that I need to set cc environmental variable to a working compiler. I think this will be taken care of when I install a ISO C90 compiler. Any help you can give me would be great. you should install the gcc package from RedHat. Then you can use that directly, or build your own (updated?) version from source. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
struct __attribute((packed));
Hi,
I just tripped over this snipped below in a piece of code, I didn't
write and which I don't understand:
...
struct somestruct {
struct entrystruct *e1 __attribute__ ((packed));
struct entrystruct *e2 __attribute__ ((packed));
};
...
Is this meaningful?
I guess the author wanted e1 and e2 to point to a
packed struct entrystruct, but this doesn't seem to be what GCC
interprets this code.
Ralf
Re: struct __attribute((packed));
Ralf Corsepius wrote:
Hi,
I just tripped over this snipped below in a piece of code, I didn't
write and which I don't understand:
...
struct somestruct {
struct entrystruct *e1 __attribute__ ((packed));
struct entrystruct *e2 __attribute__ ((packed));
};
...
Is this meaningful?
I guess the author wanted e1 and e2 to point to a
packed struct entrystruct, but this doesn't seem to be what GCC
interprets this code.
Take a look at the manual in the section about attributes of variables,
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Variable-Attributes.html#Variable-Attributes
It seems that GCC will interpret the above as e1 and e2 is packed within
the struct somestruct so that e2 immediately follows e1 (according to
the manual). The packed attribute in this case does not refer to what e1
and e2 is pointing to. Though I'm not sure what putting the packed
attribute on e1 will buy you.
HTH
Eric
Successful bootstrap of GCC 3.4.3 on i586-pc-interix3 (with one little problem)
bash-3.00$ ../gcc-3.4.3/config.guess i586-pc-interix3 bash-3.00$ gcc/xgcc -v Using built-in specs. Configured with: ../gcc-3.4.3/configure --verbose --disable-shared --with-stabs --enable-nls --with-gnu-as --with-gnu-ld --enable-targets=i586-pc-interix3 --enable-threads=posix --enable-languages=c,c++ --enable-checking : (reconfigured) ../gcc-3.4.3/configure --verbose --disable-shared --with-stabs --enable-nls --with-gnu-as --with-gnu-ld --enable-targets=i586-pc-interix3 --enable-threads=posix --enable-languages=c,c++,g77,ada,java,objc : (reconfigured) ../gcc-3.4.3/configure --verbose --disable-shared --with-stabs --enable-nls --with-gnu-as --with-gnu-ld --enable-targets=i586-pc-interix3 --enable-threads=posix --enable-languages=ada,c,c++,f77,f95,java,objc,obj-c++ : (reconfigured) ../gcc-3.4.3/configure --verbose --disable-shared --with-stabs --enable-nls --with-gnu-as --with-gnu-ld --enable-targets=i586-pc-interix3 --enable-threads=posix --enable-languages=ada,c,c++,f77,java,objc Thread model: posix gcc version 3.4.3 There was a problem in building libobjc, libtool wouldn't run due to having '#! sh' as its first line. Changing it to '#! /bin/sh' enabled the bootstrap to complete. System: Windows 2000 SP4, Services for Unix 3.5.
Re: struct __attribute((packed));
On Fri, 2005-04-15 at 09:27 -0600, E. Weddington wrote:
Ralf Corsepius wrote:
Hi,
I just tripped over this snipped below in a piece of code, I didn't
write and which I don't understand:
...
struct somestruct {
struct entrystruct *e1 __attribute__ ((packed));
struct entrystruct *e2 __attribute__ ((packed));
};
...
Is this meaningful?
I guess the author wanted e1 and e2 to point to a
packed struct entrystruct, but this doesn't seem to be what GCC
interprets this code.
Take a look at the manual in the section about attributes of variables,
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Variable-Attributes.html#Variable-Attributes
I read this, over and over again, before posting, but ...
It seems that GCC will interpret the above as e1 and e2 is packed within
the struct somestruct so that e2 immediately follows e1 (according to
the manual). The packed attribute in this case does not refer to what e1
and e2 is pointing to.
That's what I found out by experimenting and is the reason why I am
asking. From what I see on i386,
struct entrystruct * entry __attribute__ ((packed));
is interpreted as packed pointer to struct
not as pointer to packed struct,
i.e. this construct is not meaningful.
Though I'm not sure what putting the packed
attribute on e1 will buy you.
You've got the point - I am collecting ammunition to fight a stubborn
original author :-)
Ralf
Re: struct __attribute((packed));
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: Ralf struct entrystruct * entry __attribute__ ((packed)); Ralf is interpreted as packed pointer to struct not as pointer to Ralf packed struct, i.e. this construct is not meaningful. Yes it's meaningful, it may not be what you intended. It sure would be useful, though, if there were a construct that does mean pointer to packed T. In particular, I've often needed pointer to packed int and found no way to produce that. I ended up creating a one-member struct with a packed int inside, which is a syntactic nightmare. (The application was a piece of legacy code that was writing via int pointers, but sometimes things were not aligned. The fix was much more invasive than it should have been because I could find no way to define a pointer to packed int.) If there IS a way to do that, it sure would be nice for the docs to explain it. Right now the documentation of packed is essentially unintellegible. paul
inline-unit-growth trouble
Hi, on S/390 we have currently a plenty of testsuite failures due to inlining effects. ld complains about testcases which try to link two files containing the same function in .gnu.linkonce sections but with different code sizes. The sizes differ due to different inlining decisions. The problem is that inlining maybe prevented by global limits which maybe exceeded for one file but not for the other. The actual problem occurred with the inline-unit-growth limit which may prevent inlining for a function in one file and allow it for the same function in another. I'm not sure how to fix that issue. To my mind the whole concept of per unit limits influencing local inlining decisions seems a bit questionable. Any suggestions? Bye, -Andreas-
Re: [m68k]: More trouble with byte moves into Address registers
For some reason reload has decided that it needs ADDR_REGS for the
register being reloaded, namely (reg:QI 1420). So gcc looks for a
register in ADDR_REGS which can hold QImode. Because of your changes,
it doesn't find one. So it crashes.
The question is why reload thinks that it needs ADDR_REGS for this
register. Look at the local-alloc debugging dump to see where
regclass thinks that the register should go.
Which debugging dump has the output from local-alloc? If its
pp_pack.c.24.lreg, then that is the output I supplied in the original
message which contains(for all bits regarding register 1420 up until
the compilation fails):
Register 1420 costs: DATA_REGS:84 GENERAL_REGS:210 DATA_OR_FP_REGS:294
ALL_REGS:294 MEM:441
Register 1420 pref DATA_REGS
Register 1420 costs: DATA_REGS:84 GENERAL_REGS:210 DATA_OR_FP_REGS:294
ALL_REGS:294 MEM:441
Register 1420 used 3 times across 6 insns; set 1 time; 1 bytes; pref DATA_REGS.
Registers live at end: 14 [%a6] 15 [%sp] 24 [argptr] 31 35 36 37 38 39 43 45 46
47 48 50 52 57 70 1369 1370 1371 1378 1391 1402 1413 1420 1725 1734 1735 1736
1738 1740
Registers live at start: 14 [%a6] 15 [%sp] 24 [argptr] 31 35 36 37 38 39 43 45
46 47 48 50 52 57 70 1369 1370 1371 1378 1391 1402 1413 1420 1725 1734 1735
1736 1738 1740
;; Start of basic block 694, registers live: 14 [%a6] 15 [%sp] 24 [argptr] 31
35 36 37 38 39 43 45 46 47 48 50 52 57 70 1369 1370 1371 1378 1391 1402 1413
1725 1734 1735 1736 1738 1740 1756
(note 6967 5556 5558 694 [bb 694] NOTE_INSN_BASIC_BLOCK)
(insn 5558 6967 5559 694 pp_pack.c:2144 (set (reg:QI 1420)
(mem:QI (reg:SI 1756 [ s ]) [0 S1 A8])) 43 {movqi_cfv4} (nil)
(expr_list:REG_DEAD (reg:SI 1756 [ s ])
(nil)))
(insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 1421)
(plus:SI (subreg:SI (reg:QI 1420) 0)
(const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list 5558
(nil))
(nil))
(insn:QI 5560 5559 5561 694 pp_pack.c:2144 (set (cc0)
(compare (subreg:QI (reg:SI 1421) 3)
(const_int 64 [0x40]))) 15 {cfv4_cmpqi} (insn_list 5559 (nil))
(expr_list:REG_DEAD (reg:SI 1421)
(nil)))
BTW: the patterns mentioned in the dump:
(define_insn movqi_cfv4
[(set (match_operand:QI 0 nonimmediate_operand =dQ,dmU,U,d)
(match_operand:QI 1 general_src_operand dmi,dQ,Ui,di))]
TARGET_CFV4
* return output_move_qimode (operands);)
(define_insn *addsi3_5200
[(set (match_operand:SI 0 nonimmediate_operand =m,?a,?a,r)
(plus:SI (match_operand:SI 1 general_operand %0,a,rJK,0)
(match_operand:SI 2 general_src_operand
dIL,rJK,a,mrIKLi)))]
TARGET_COLDFIRE
* return output_addsi3 (operands);)
(define_insn cfv4_cmpqi
[(set (cc0)
(compare (match_operand:QI 0 nonimmediate_operand mdKs,d)
(match_operand:QI 1 general_operand d,mdKs)))]
TARGET_CFV4
*
{
if (REG_P (operands[1])
|| (!REG_P (operands[0]) GET_CODE (operands[0]) != MEM))
{ cc_status.flags |= CC_REVERSED;
#ifdef SGS_CMP_ORDER
return \cmp%.b %d1,%d0\;
#else
return \cmp%.b %d0,%d1\;
#endif
}
#ifdef SGS_CMP_ORDER
return \cmp%.b %d0,%d1\;
#else
return \cmp%.b %d1,%d0\;
#endif
})
And the function called for HARD_REGNO_MODE_OK is:
/* Value is 1 if hard register REGNO can hold a value of machine-mode MODE.
On the 68000, the cpu registers can hold any mode except bytes in
address registers, but the 68881 registers
can hold only SFmode or DFmode. */
int m68k_hard_regno_mode_ok(int regno, enum machine_mode mode)
{
if (regno 8)
{
/* Data Registers can hold anything if it fits into them */
if (((regno) + GET_MODE_SIZE (mode) / 4) = 8)
return 1;
}
else if (regno 16)
{
/* Address Registers can't hold bytes, can hold aggregate if
it fits into them */
if (GET_MODE_SIZE (mode) == 1)
return 0;
if (((regno) + GET_MODE_SIZE (mode) / 4) = 16)
return 1;
}
else if (regno 24)
{
/* FPU registers, hold float or complex float of long double or smaller */
if ((GET_MODE_CLASS (mode) == MODE_FLOAT
|| GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
(((GET_MODE_UNIT_SIZE (mode) = 12) TARGET_68881)
|| ((GET_MODE_UNIT_SIZE (mode) = 8) TARGET_CFV4E)))
return 1;
}
return 0;
}
Any further insight or suggestions are *really* appreciated!
--
Peter Barada
[EMAIL PROTECTED]
Re: struct __attribute((packed));
Ralf Corsepius wrote: On Fri, 2005-04-15 at 09:27 -0600, E. Weddington wrote: It seems that GCC will interpret the above as e1 and e2 is packed within the struct somestruct so that e2 immediately follows e1 (according to the manual). The packed attribute in this case does not refer to what e1 and e2 is pointing to. That's what I found out by experimenting and is the reason why I am asking. From what I see on i386, struct entrystruct * entry __attribute__ ((packed)); is interpreted as packed pointer to struct not as pointer to packed struct, I would interpret it that way too: packed pointer to struct. The packed attribute is on the variable itself, not the type of the variable (pointer to struct) i.e. this construct is not meaningful. Is it? The manual says The |packed| attribute specifies that a variable or structure field should have the smallest possible alignment. So it sounds like that: struct entrystruct * entry __attribute__ ((packed)); by itself would mean that the variable entry has the smallest possible alignment. I don't know if that is meaningful just by itself or whether it is meaningful in your context. And realise that I'm just postulating from looking at the manual. Somebody with more expertise would have to comment about this. You've got the point - I am collecting ammunition to fight a stubborn original author :-) Yeah, if that author was thinking that the packed attribute applied to what the variable pointed to, then I would think that it is wrong usage of the attribute. I would suggest pointing the author to the description of packed in the section on attributes of types: http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-Attributes HTH Eric
Re: Semi-Latent Bug in tree vectorizer
On Sat, 2005-04-09 at 23:23 -0400, Diego Novillo wrote:
On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
When we vectorize the store we copy the virtual operands from the
original statement to the new vectorized statement via this code:
/* Copy the V_MAY_DEFS representing the aliasing of the original array
element's definition to the vector's definition then update the
defining statement. The original is being deleted so the same
SSA_NAMEs can be used. */
copy_virtual_operands (*vec_stmt, stmt);
v_may_defs = STMT_V_MAY_DEF_OPS (*vec_stmt);
nv_may_defs = NUM_V_MAY_DEFS (v_may_defs);
for (i = 0; i nv_may_defs; i++)
{
tree ssa_name = V_MAY_DEF_RESULT (v_may_defs, i);
SSA_NAME_DEF_STMT (ssa_name) = *vec_stmt;
}
This is safe if and only if the the operand scanning code will compute
the same V_MAY_DEFS for the original scalar statement and the new
vectorized statement. ie, *D.1470 must have the same aliasing
properties as *vect_px.17.
Right. Both the vectorizer and ivopts have the side-effect of
refining aliasing information. Therefore, blindly copying
virtual operands is not correct.
Could you try this patch? It fixes your test case and doesn't
produce new regressions in the vectorizer tests. It's not
bootstrapped nor tested otherwise.
The idea is that we should treat both the vectorized statement
and the old statement separately. The virtual defs from the old
statement are going away and the new one is getting brand new
symbols exposed. That's why we mark them separately.
I went ahead and ran this through the usual bootstrap and regression
test. Installed this morning...
jeff
Re: Heads-up: volatile and C++
Michael N. Moran wrote: I'm very much in favor of fine grained synchronization primitives in the compiler, but not of changes to volatile semantics. I wonder if it would be sufficient (if not preferable) to only extend (modify) the semantics for heap/stack and const volatile variables, as enforcing existing volatile semantics for such variables are at best of questionable existing value. i.e.: volatile vv;// volatile sync primitive, w/normal access semantics. volatile const vc; // universal sync primitive, w/normal access semantics. volatile *vp = some-address; // a true volatile reference. vv; // volatile sync, all pending volatile transactions logically emitted // into the code, but not hard physically synchronized via a HW sync. vc; // universal sync, all pending transactions hard physically sync'ed. *vp = some-value; // volatile access semantics enforced, with ordering // warranted between equivalent references, but not // otherwise (unless synchronized by referencing a // declared or (cast) volatile sync variable). (with the exception of new sync semantics, non-reference volatile variables do not need to have volatile access semantics, as it would seem to serve no useful purpose for stack/heap allocated variables, and should be allowed to be optimized always just as for any other allocated variable; although their sync, semantic actions must be preserved, thereby may still be used as synchronized value semaphores, etc, or as simply sync's when no access would otherwise be required; and/or allow regular variables to be cast as (volatile), thereby enabling a arbitrary expression to insert a sync, i.e.: (volatile)x = y, or x = (const volatile)y; forcing a specified sync prior to, or after the assignment?) Where the above is just expressed as a loose possible alternative to strictly enforcing ordering between all volatile or otherwise transactions without having to necessarily introduce another keyword, for good or bad.
Re: struct __attribute((packed));
Paul Koning wrote: It sure would be useful, though, if there were a construct that does mean pointer to packed T. In particular, I've often needed pointer to packed int and found no way to produce that. I ended up creating a one-member struct with a packed int inside, which is a syntactic nightmare. (The application was a piece of legacy code that was writing via int pointers, but sometimes things were not aligned. The fix was much more invasive than it should have been because I could find no way to define a pointer to packed int.) If there IS a way to do that, it sure would be nice for the docs to explain it. Right now the documentation of packed is essentially unintellegible. According to the docs here: http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-Attributes what about doing something like this?: --- typedef int packed_int __attribute__ ((aligned (1))); packed_int *ppi; --- Eric
RE: struct __attribute((packed));
Original Message From: E. Weddington Sent: 15 April 2005 17:10 Ralf Corsepius wrote: struct entrystruct * entry __attribute__ ((packed)); is interpreted as packed pointer to struct not as pointer to packed struct, I would interpret it that way too: packed pointer to struct. The packed attribute is on the variable itself, not the type of the variable (pointer to struct) [...snip!...] Yeah, if that author was thinking that the packed attribute applied to what the variable pointed to, then I would think that it is wrong usage of the attribute. I've often wished that __attribute__s would behave like CV-quals: char * const ptr; == const pointer to char struct entrystruct * __attribute__ ((packed)) entry; == packed pointer to struct char const * ptr; == pointer to const char struct entrystruct __attribute__ ((packed)) * entry; == pointer to packed struct I haven't done an exhaustive survey of attributes, but I know it doesn't work that way for section attributes, and there have been times when I would have liked it to. cheers, DaveK -- Can't think of a witty .sigline today
Re: Heads-up: volatile and C++
Paul == Paul Schlie [EMAIL PROTECTED] writes: Michael N. Moran wrote: I'm very much in favor of fine grained synchronization primitives in the compiler, but not of changes to volatile semantics. Paul I wonder if it would be sufficient (if not preferable) to only Paul extend (modify) the semantics for heap/stack and const volatile Paul variables, as enforcing existing volatile semantics for such Paul variables are at best of questionable existing value I'm not sure I completely understand, but volatile heap variables are perfectly meaningful today. For example, if I need to define a communication data area for the program to talk to some DMA I/O device, a volatile struct, or a struct some of whose members are volatile, allocated on the heap, makes perfect sense. paul
Re: struct __attribute((packed));
Dave Korn wrote: I've often wished that __attribute__s would behave like CV-quals: char * const ptr; == const pointer to char struct entrystruct * __attribute__ ((packed)) entry; == packed pointer to struct char const * ptr; == pointer to const char struct entrystruct __attribute__ ((packed)) * entry; == pointer to packed struct I haven't done an exhaustive survey of attributes, but I know it doesn't work that way for section attributes, and there have been times when I would have liked it to. That's got my vote! (As if anyone's counting). That would make things so much easier, for example, in the AVR port for dealing with multiple memory spaces. Eric
Re: struct __attribute((packed));
E == E Weddington [EMAIL PROTECTED] writes: E Paul Koning wrote: It sure would be useful, though, if there were a construct that does mean pointer to packed T. In particular, I've often needed pointer to packed int and found no way to produce that. I ended up creating a one-member struct with a packed int inside, which is a syntactic nightmare. (The application was a piece of legacy code that was writing via int pointers, but sometimes things were not aligned. The fix was much more invasive than it should have been because I could find no way to define a pointer to packed int.) If there IS a way to do that, it sure would be nice for the docs to explain it. Right now the documentation of packed is essentially unintellegible. E According to the docs here: E http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-Attributes E what about doing something like this?: E --- typedef int packed_int E __attribute__ ((aligned (1))); E packed_int *ppi; That would make sense, but it has never worked for me. It seems that attributes don't apply to type names, only to variables and members. paul
Re: Processor-specific code
On Fri, 2005-04-15 at 15:50, Robert Dewar wrote: Richard Earnshaw wrote: Not all environments can change the rounding mode dynamically. For example, on the FPA co-processor for ARM, rounding is set by the instruction selected -- so the concept of having an environment variable to control this is meaningless. Right, such a feature obviously does not apply to hardware that is this far from the IEEE standard (which requires dynamic control). The Alpha architecture has similar problems. Precisely which statement in IEEE 754-1985 states this? As far as I can tell this standard is a mathematical abstraction for mapping floating point onto machine types. Chapter 4 describes the required rounding modes but definitely makes no statement saying that this has to be selectable in a dynamic manner. R.
Re: struct __attribute((packed));
E == E Weddington [EMAIL PROTECTED] writes:
E Paul Koning wrote: According to the docs here:
E
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-Attributes
E what about doing something like this?:
E typedef int packed_int __attribute__ ((aligned (1)));
E packed_int *ppi;
That would make sense, but it has never worked for me. It seems
that attributes don't apply to type names, only to variables and
members.
E What?! That whole section in the docs talks about attributes on
E types. If it doesn't work as described, then the docs need some
E serious rework.
I'd rather the compiler got the work than the docs.
Maybe it's better in newer versions; I don't have anything newer than
3.4.1 built right now.
Test program:
typedef int pi __attribute__((packed));
void set(void *p, int v)
{
pi *ppi;
ppi = (pi *) p;
*ppi = v;
}
On 3.3.3, this compiles without any warnings (in spite of -Wall) but
the store is an aligned store (MIPS sw instruction).
With 3.4.1, I get this:
test.c:1: warning: `packed' attribute ignored
Sigh.
And yes, I agree with Dave that having attributes work syntactically
the same as CV-modifiers -- so they can be directly applied to the
pointed-to type in pointer declarations -- would be a Good Thing.
paul
RE: Processor-specific code
Dave == Dave Korn [EMAIL PROTECTED] writes: Dave Doesn't the C language spec require the mode to be switchable Dave at runtime? Dave In any case, the ARM or Alpha isn't prevented from working in Dave such a fashion just because the rounding mode is encoded in the Dave instruction; it just means that fp primitives have to be Dave compiled as intrinsics that test whatever flag controls the Dave rounding mode and then branch to an fp insn of the appropriate Dave form. That only works if the notion of switchable rounding mode exists. It doesn't on VAX, PDP-11, PDP-10, ... paul
RE: struct __attribute((packed));
On Fri, 15 Apr 2005, Dave Korn wrote: I've often wished that __attribute__s would behave like CV-quals: The syntax of attributes is documented in the Attribute Syntax section of the manual. http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html Nested in pointer sequences they do act like cv-quals. In amongst the declaration specifiers on a declaration they act like storage class specifiers, but a particular attribute's handler can make them act like cv-quals there as well if not constrained by compatibility with how previous versions of GCC implemented the attribute. (See how this is done for vector_size attributes.) The __section__ attribute is purely a storage-class-like attribute. If you want DTR18037 address space specifiers, feel free to implement them; they are probably the least problematic part of that TR. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: [m68k]: More trouble with byte moves into Address registers
(insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 1421)
(plus:SI (subreg:SI (reg:QI 1420) 0)
(const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list
5558 (nil))
(nil))
So register 1420 is being assigned to a data register. The
constraints for addsi3_5200 permit the following alternatives:
mem += datareg
addrreg = addrreg + reg|constant
addrreg = reg|constant + addrreg
reg += mem|reg|constant
There is no alternative which permits adding a data register and a
constant and putting the result in an address register. So reload
picks the alternative addrreg = addrreg + reg|constant, and decides
to reload register 1420 into an address register. But that fails
because reload can't find an address register which can accept a
QImode value.
Would it help to rearrange the constraints to have reg +=
mem|reg|constant before the addreg += ... ?
Looking at the dump a little more, it's far from clear why register
1421 is being put into an address register. I see that insn 5560
wants to compare a byte value which it finds there, so it doesn't seem
like a good fit to put 1421 into an address register.
I don't know where else register 1421 is being used, so my tentative
guess would be that gcc is picking an address register based on the
constraints in addsi3_5200. Perhaps you need to change ?a to *a.
After all, you probably don't want to encourage pseudos to go into the
address registers merely because you add values to them.
1421 is only used in 5559 and 5560. from the lreg dump:
Register 1421 used 2 times across 2 insns in block 694; set 1 time; pref
DATA_REGS.
But it is also possible that register 1421 is being put into an
address register merely because all the data registers are taken and
there is nothing which forces 1421 to be in a data register.
In the function S_unpack_rec, there are 190 registers to allocate, so
I'd guess everything will be in use.
Or, you might permit an alternative a a*r rJK in addsi3_5200. You
can implement that using a two instruction sequence--copy the data
register to the address register, and then add. This is obviously not
ideal, but it's more or less what reload would be doing anyhow.
In general, though, I'm not sure that prohibiting QImode values in
address registers is going to be a useful approach. After all, the
values do fit there, and while we want to discourage it, it's not
obvious that we want to completely prohibit it. The problem in PR
18421 is that reload decided that it had to reload a QImode value from
memory into an address register, but it couldn't. That is more or
less easy to handle by defining SECONDARY_RELOAD_CLASS to indicate
that a data register is required to move QImode values between the
address registers and memory, and by defining reload_inqi and
reload_outqi to do the moves.
The problem is that there is no valid QImode instruction that can move
values in/out of an address register
This has been an ongoing problem for more than a year, and each
fix treats the particular bug/problem at hand. rth is the one who
recommended punting QImode out of address registers:
http://gcc.gnu.org/ml/gcc/2003-07/msg00743.html
Looking over the code, I see that PREFERRED_RELOAD_CLASS is:
#define PREFERRED_RELOAD_CLASS(X,CLASS) \
((GET_CODE (X) == CONST_INT \
(unsigned) (INTVAL (X) + 0x80) 0x100 \
(CLASS) != ADDR_REGS)\
? DATA_REGS \
: (GET_MODE (X) == QImode (CLASS) != ADDR_REGS) \
? DATA_REGS \
: (GET_CODE (X) == CONST_DOUBLE \
GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT) \
? ((TARGET_68881|TARGET_CFV4E) (CLASS == FP_REGS || CLASS ==
DATA_OR_FP_REGS) \
? FP_REGS : NO_REGS) \
: (TARGET_PCREL \
(GET_CODE (X) == SYMBOL_REF || GET_CODE (X) == CONST \
|| GET_CODE (X) == LABEL_REF))\
? ADDR_REGS \
: (CLASS))
Which looks like it allows QImode into ADDR_REGS instead
of insisting on DATA_REGS. Do you think this should be:
#define PREFERRED_RELOAD_CLASS(X,CLASS) \
(((GET_CODE (X) == CONST_INT \
(unsigned) (INTVAL (X) + 0x80) 0x100) \
|| GET_MODE(X) == QImode) \
? DATA_REGS \
: (GET_CODE (X) == CONST_DOUBLE \
GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT) \
? ((TARGET_68881|TARGET_CFV4E) (CLASS == FP_REGS || CLASS ==
DATA_OR_FP_REGS) \
? FP_REGS : NO_REGS) \
: (TARGET_PCREL \
(GET_CODE (X) == SYMBOL_REF || GET_CODE (X) == CONST \
|| GET_CODE (X) == LABEL_REF))\
? ADDR_REGS
Re: struct __attribute((packed));
On Apr 15, 2005, at 8:27 AM, E. Weddington wrote:
Ralf Corsepius wrote:
Hi,
I just tripped over this snipped below in a piece of code, I didn't
write and which I don't understand:
...
struct somestruct {
struct entrystruct *e1 __attribute__ ((packed));
struct entrystruct *e2 __attribute__ ((packed));
};
...
Is this meaningful?
I guess the author wanted e1 and e2 to point to a packed struct
entrystruct, but this doesn't seem to be what GCC
interprets this code.
There is no reason a definition of struct entrystruct should even be
visible at
this point, so that doesn't seem like a very reasonable interpretation.
RE: Processor-specific code
On Fri, 2005-04-15 at 17:49, Dave Korn wrote: Original Message From: Richard Earnshaw Sent: 15 April 2005 17:42 On Fri, 2005-04-15 at 15:50, Robert Dewar wrote: Richard Earnshaw wrote: Not all environments can change the rounding mode dynamically. For example, on the FPA co-processor for ARM, rounding is set by the instruction selected -- so the concept of having an environment variable to control this is meaningless. Right, such a feature obviously does not apply to hardware that is this far from the IEEE standard (which requires dynamic control). The Alpha architecture has similar problems. Precisely which statement in IEEE 754-1985 states this? As far as I can tell this standard is a mathematical abstraction for mapping floating point onto machine types. Chapter 4 describes the required rounding modes but definitely makes no statement saying that this has to be selectable in a dynamic manner. R. Doesn't the C language spec require the mode to be switchable at runtime? In any case, the ARM or Alpha isn't prevented from working in such a fashion just because the rounding mode is encoded in the instruction; it just means that fp primitives have to be compiled as intrinsics that test whatever flag controls the rounding mode and then branch to an fp insn of the appropriate form. c90 doesn't require anything; it's all new in c99. C99 has a number of functions and defines a number of macros *iff* the environment supports rounding switching. It certainly doesn't require it. Code that changes the rounding has to be wrapped with certain pragmas to inform the compiler that this might happen: on something like ARM+FPA that might permit dynamic code switching, but I doubt anyone would really want to pay that price. R.
Re: struct __attribute((packed));
Paul Koning wrote:
E == E Weddington [EMAIL PROTECTED] writes:
E typedef int packed_int __attribute__ ((aligned (1)));
I'd rather the compiler got the work than the docs.
Maybe it's better in newer versions; I don't have anything newer than
3.4.1 built right now.
Test program:
typedef int pi __attribute__((packed));
No, look what I wrote above. Can you try using the *aligned* attribute?:
typedef int packed_int __attribute__ ((aligned (1)));
void set(void *p, int v)
{
pi *ppi;
ppi = (pi *) p;
*ppi = v;
}
Eric
RE: Processor-specific code
Original Message From: Richard Earnshaw Sent: 15 April 2005 18:08 In any case, the ARM or Alpha isn't prevented from working in such a fashion just because the rounding mode is encoded in the instruction; it just means that fp primitives have to be compiled as intrinsics that test whatever flag controls the rounding mode and then branch to an fp insn of the appropriate form. Code that changes the rounding has to be wrapped with certain pragmas to inform the compiler that this might happen: on something like ARM+FPA that might permit dynamic code switching, but I doubt anyone would really want to pay that price. It's a very arch-dependent price, though. On an arch where you have conditional execution per-instruction, it could be a very low overhead indeed. cheers, DaveK -- Can't think of a witty .sigline today
Re: make bootstrap for cross builds
On Fri, Apr 15, 2005 at 01:23:39AM -0400, Andrew Pinski wrote: On Apr 15, 2005, at 1:19 AM, Ranjit Mathew wrote: Hi, I think make bootstrap does not make sense for cross builds. We however seem to allow it but fail in a weird way later on (as on mainline). I think this should not be allowed. I discovered this when I mistakenly typed make bootstrap out of habit on a cross build. Huh? there is one case where this does makes sense, take for example: ppc64-linux-gnu, you were running the ppc-linux-gnu compiled GCC and you need a 64bit compatible one. You can compile with --with-cpu=default32 and still have a cross compiler but can still do a native compiling, it is weird case but it does show up. I always set build, host, and target to powerpc64-linux when bootstrapping a biarch compiler, and use --with-cpu=default32 to generate 32-bit binaries by default. I seem to recall running into problems when they weren't all the same for bootstraps. Janis
Re: struct __attribute((packed));
Andrew Haley wrote: gcc.info: The `aligned' attribute can only increase the alignment; but you can decrease it by specifying `packed' as well. See below. Thanks for the correction. Bleah. :-P I'll go back into lurk mode now Eric
Re: [m68k]: More trouble with byte moves into Address registers
Peter Barada [EMAIL PROTECTED] writes: So register 1420 is being assigned to a data register. The constraints for addsi3_5200 permit the following alternatives: mem += datareg addrreg = addrreg + reg|constant addrreg = reg|constant + addrreg reg += mem|reg|constant There is no alternative which permits adding a data register and a constant and putting the result in an address register. So reload picks the alternative addrreg = addrreg + reg|constant, and decides to reload register 1420 into an address register. But that fails because reload can't find an address register which can accept a QImode value. Would it help to rearrange the constraints to have reg += mem|reg|constant before the addreg += ... ? Probably not in this case. You could try it. It is true that when two alternatives have the same cost, reload will pick the first one listed. Looking at the dump a little more, it's far from clear why register 1421 is being put into an address register. I see that insn 5560 wants to compare a byte value which it finds there, so it doesn't seem like a good fit to put 1421 into an address register. I don't know where else register 1421 is being used, so my tentative guess would be that gcc is picking an address register based on the constraints in addsi3_5200. Perhaps you need to change ?a to *a. After all, you probably don't want to encourage pseudos to go into the address registers merely because you add values to them. 1421 is only used in 5559 and 5560. from the lreg dump: Register 1421 used 2 times across 2 insns in block 694; set 1 time; pref DATA_REGS. That is odd. Your earlier e-mail seemed to show that register 1421 was specifically put into an address register, specifically %a0. Why would that happen if it has a preference for DATA_REGS? Was it assigned by local-alloc? In that case you would see a line like ;; Register 2421 in NNN. in the .lreg dump file. In general, though, I'm not sure that prohibiting QImode values in address registers is going to be a useful approach. After all, the values do fit there, and while we want to discourage it, it's not obvious that we want to completely prohibit it. The problem in PR 18421 is that reload decided that it had to reload a QImode value from memory into an address register, but it couldn't. That is more or less easy to handle by defining SECONDARY_RELOAD_CLASS to indicate that a data register is required to move QImode values between the address registers and memory, and by defining reload_inqi and reload_outqi to do the moves. The problem is that there is no valid QImode instruction that can move values in/out of an address register I know. I'm suggesting that QImode values have to move in and out of address registers via data registers, so you just put the QImode value into the data register, and then move it into the address register, or vice-versa. But I see from your reference that Jim Wilson already suggested this, and that RTH advised against it. Hmmm. Looking over the code, I see that PREFERRED_RELOAD_CLASS is: ... Which looks like it allows QImode into ADDR_REGS instead of insisting on DATA_REGS. Do you think this should be: No, that will break reload. If it calls PREFERRED_RELOAD_CLASS with ADDR_REGS, then it has already selected an alternative which requires ADDR_REGS. Returning a register class which does not permit any register in ADDR_REGS will give you a constraint violation later on. You could probably get this to work if you changed ?a to !a in addsi3_5200. But that would probably give you worse code when dealing with SImode value. You could probably get this to work if you wrote the predicate for addsi3_5200 to specifically reject a subreg:SI of a QImode value, and then defined a new insn which specifically accepted it and nothing else, but did not permit address registers in the alternatives. You might have to play similar tricks with some other instructions, but perhaps addsi3 is relatively special here, just to handle cases generated by reload. Ian
Re: Heads-up: volatile and C++
Gabriel Dos Reis wrote: Marcin Dalecki [EMAIL PROTECTED] writes: | Templates are a no-go for a well known and well defined subset for C++ | for embedded programming known commonly as well embedded C++. You'd be surprised to learn that embedded systems people do use templates for various things -- among which, maybe the most paradoxical is to avoid code bloat. Embedded C++ was a mistake, alas a mistake that seems to last. Just in case there is any voting going on here ... agreed :) -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144http://mnmoran.org So often times it happens, that we live our lives in chains and we never even know we have the key. The Eagles, Already Gone The Beatles were wrong: 1 1 1 is 1
Re: Processor-specific code
On 2005-04-14 10:35:06 -0700, Richard Henderson wrote: All that said, C99 has fenv.h to control just about anything you could want about the fpu. It is not possible to change the rounding precision with fenv.h. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: Heads-up: volatile and C++
Paul Schlie wrote: Michael N. Moran wrote: I'm very much in favor of fine grained synchronization primitives in the compiler, but not of changes to volatile semantics. I wonder if it would be sufficient (if not preferable) to only extend (modify) the semantics for heap/stack and const volatile variables, as enforcing existing volatile semantics for such variables are at best of questionable existing value. i.e.: volatile vv;// volatile sync primitive, w/normal access semantics. volatile const vc; // universal sync primitive, w/normal access semantics. volatile *vp = some-address; // a true volatile reference. vv; // volatile sync, all pending volatile transactions logically emitted // into the code, but not hard physically synchronized via a HW sync. vc; // universal sync, all pending transactions hard physically sync'ed. *vp = some-value; // volatile access semantics enforced, with ordering // warranted between equivalent references, but not // otherwise (unless synchronized by referencing a // declared or (cast) volatile sync variable). (with the exception of new sync semantics, non-reference volatile variables do not need to have volatile access semantics, as it would seem to serve no useful purpose for stack/heap allocated variables, and should be allowed to be optimized always just as for any other allocated variable; although their sync, semantic actions must be preserved, thereby may still be used as synchronized value semaphores, etc, or as simply sync's when no access would otherwise be required; and/or allow regular variables to be cast as (volatile), thereby enabling a arbitrary expression to insert a sync, i.e.: (volatile)x = y, or x = (const volatile)y; forcing a specified sync prior to, or after the assignment?) I'm not certain I understand what you are proposing, other than there being some difference connection between how objects are declared (their scope) and the semantics attached with uses of the object. What happens to volatile pointers/references passed through functions? Which semantic would be emitted by the compiler when these are dereferenced? Even without a thorough understanding, on the surface, this seems ... unintuitive. Where the above is just expressed as a loose possible alternative to strictly enforcing ordering between all volatile or otherwise transactions without having to necessarily introduce another keyword, for good or bad. I guess that the reason adding new keywords is a problem is its interaction with existing C++ code? Sorry, I'm not an expert. -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144http://mnmoran.org So often times it happens, that we live our lives in chains and we never even know we have the key. The Eagles, Already Gone The Beatles were wrong: 1 1 1 is 1
Re: Processor-specific code
On Friday 15 April 2005 18:43, Vincent Lefevre wrote: On 2005-04-14 10:35:06 -0700, Richard Henderson wrote: All that said, C99 has fenv.h to control just about anything you could want about the fpu. It is not possible to change the rounding precision with fenv.h. That's because it's an x86/m68k specific implementation detail and the compiler should be setting it for you. gcc doesn't do this because noone cares enough to implement it. Paul
Re: inline-unit-growth trouble
On 4/15/05, Andreas Krebbel [EMAIL PROTECTED] wrote: Hi, on S/390 we have currently a plenty of testsuite failures due to inlining effects. ld complains about testcases which try to link two files containing the same function in .gnu.linkonce sections but with different code sizes. The sizes differ due to different inlining decisions. The problem is that inlining maybe prevented by global limits which maybe exceeded for one file but not for the other. The actual problem occurred with the inline-unit-growth limit which may prevent inlining for a function in one file and allow it for the same function in another. I'm not sure how to fix that issue. To my mind the whole concept of per unit limits influencing local inlining decisions seems a bit questionable. Why does the linker not just pick either of the functions? The size difference should not matter. Richard.
Re: [m68k]: More trouble with byte moves into Address registers
Would it help to rearrange the constraints to have reg +=
mem|reg|constant before the addreg += ... ?
Probably not in this case. You could try it. It is true that when
two alternatives have the same cost, reload will pick the first one
listed.
With my luck that will cause a bigger problem somewhere else. :) I'll
try it once I get past this.
I don't know where else register 1421 is being used, so my tentative
guess would be that gcc is picking an address register based on the
constraints in addsi3_5200. Perhaps you need to change ?a to *a.
After all, you probably don't want to encourage pseudos to go into the
address registers merely because you add values to them.
1421 is only used in 5559 and 5560. from the lreg dump:
Register 1421 used 2 times across 2 insns in block 694; set 1 time; pref
DATA_REGS.
That is odd. Your earlier e-mail seemed to show that register 1421
was specifically put into an address register, specifically %a0. Why
would that happen if it has a preference for DATA_REGS? Was it
assigned by local-alloc? In that case you would see a line like ;;
Register 2421 in NNN. in the .lreg dump file.
Uggh. I've been trying changes currently so I don't have the original
compiler to regenerate the output.
The problem is that there is no valid QImode instruction that can move
values in/out of an address register
I know. I'm suggesting that QImode values have to move in and out of
address registers via data registers, so you just put the QImode value
into the data register, and then move it into the address register, or
vice-versa.
Is there another backend in GCC I can look at for examples of how this
is done?
Which looks like it allows QImode into ADDR_REGS instead
of insisting on DATA_REGS. Do you think this should be:
No, that will break reload. If it calls PREFERRED_RELOAD_CLASS with
ADDR_REGS, then it has already selected an alternative which requires
ADDR_REGS. Returning a register class which does not permit any
register in ADDR_REGS will give you a constraint violation later on.
Well I tried it anyway and was able to build a complete C
toolchain(including glibc-2.3.2), but it blew up at the same point
building perl with a constraint violation of:
pp_pack.c: In function `S_unpack_rec':
pp_pack.c:2220: error: insn does not satisfy its constraints:
(insn 5559 8594 8595 694 pp_pack.c:2144 (set (reg:SI 8 %a0 [1421])
(plus:SI (reg:SI 0 %d0)
(const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list 5558
(nil))
(nil))
pp_pack.c:2220: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:391
This would be easy to fix by adding ?r/r/mi to addsi3_5200 and
emit code that first 'move.l %1,%0', and then add the string from
output_addsi3().
That is assuming that changing PREFERRED_RELOAD_CLASS this way doesn't
severely break reload.
Where in reload would you think it decides that it absolutely has to
have an ADDR_REG for 1421? I'll dig into it with gdb, but there's so
much code in reload that a clue or two would *really* help :)
I'll undo the change to PREFERRED_RELOAD_CLASS, and then change the
'?a' to '*a' in addsi3_5200 to see if that helps reload to not pick
and ADDR_REG for the value. If it still fails, I'll regenerate all
the information as I did in the 2nd email to you.
Thanks!
--
Peter Barada
[EMAIL PROTECTED]
Re: inline-unit-growth trouble
On 4/15/05, Andreas Krebbel [EMAIL PROTECTED] wrote: Hi, on S/390 we have currently a plenty of testsuite failures due to inlining effects. ld complains about testcases which try to link two files containing the same function in .gnu.linkonce sections but with different code sizes. The sizes differ due to different inlining decisions. The problem is that inlining maybe prevented by global limits which maybe exceeded for one file but not for the other. The actual problem occurred with the inline-unit-growth limit which may prevent inlining for a function in one file and allow it for the same function in another. I'm not sure how to fix that issue. To my mind the whole concept of per unit limits influencing local inlining decisions seems a bit questionable. Why does the linker not just pick either of the functions? The size difference should not matter. The linker warns about them being different sizes. Oh well. Someone would need to look into how to fix this. -- Pinski
Re: Semi-Latent Bug in tree vectorizer
On Fri, Apr 15, 2005 at 10:18:35AM -0600, Jeffrey A Law wrote: I went ahead and ran this through the usual bootstrap and regression test. Installed this morning... Excellent. Thanks. Diego.
Re: Processor-specific code
On Friday, April 15, 2005, at 09:55 AM, Paul Koning wrote: That only works if the notion of switchable rounding mode exists. It doesn't on VAX, PDP-11, PDP-10, ... What, you mean VAX isn't turing complete? :-)
Re: Heads-up: volatile and C++
From: Paul Koning [EMAIL PROTECTED] Paul == Paul Schlie [EMAIL PROTECTED] writes: Michael N. Moran wrote: I'm very much in favor of fine grained synchronization primitives in the compiler, but not of changes to volatile semantics. Paul I wonder if it would be sufficient (if not preferable) to only Paul extend (modify) the semantics for heap/stack and const volatile Paul variables, as enforcing existing volatile semantics for such Paul variables are at best of questionable existing value I'm not sure I completely understand, but volatile heap variables are perfectly meaningful today. For example, if I need to define a communication data area for the program to talk to some DMA I/O device, a volatile struct, or a struct some of whose members are volatile, allocated on the heap, makes perfect sense. - yes, but only if through a reference it would seem, as otherwise a volatile object couldn't be modifiable by anything outside of the program itself. But acknowledge that this would require an allocated volatile's semantics be dependant on potential references to it being declared, which is likely too messy to be worthy of any consideration.
Re: Processor-specific code
On 2005-04-15 18:56:23 +0100, Paul Brook wrote: On Friday 15 April 2005 18:43, Vincent Lefevre wrote: It is not possible to change the rounding precision with fenv.h. That's because it's an x86/m68k specific implementation detail and the compiler should be setting it for you. Setting the rounding direction is also processor-specific, but this is standardized. gcc doesn't do this because noone cares enough to implement it. The user could also want to change the rounding precision dynamically. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: inline-unit-growth trouble
Richard Guenther wrote: On 4/15/05, Andreas Krebbel [EMAIL PROTECTED] wrote: Hi, on S/390 we have currently a plenty of testsuite failures due to inlining effects. ld complains about testcases which try to link two files containing the same function in .gnu.linkonce sections but with different code sizes. The sizes differ due to different inlining decisions. The problem is that inlining maybe prevented by global limits which maybe exceeded for one file but not for the other. The actual problem occurred with the inline-unit-growth limit which may prevent inlining for a function in one file and allow it for the same function in another. I'm not sure how to fix that issue. To my mind the whole concept of per unit limits influencing local inlining decisions seems a bit questionable. Why does the linker not just pick either of the functions? The size difference should not matter. Is it really the job of the linker to choose between different implementations of a function? It seems to me that this might lead to very, very difficult to track down bugs
rtx/tree calling function syntax
I am trying to backport how -finstrument-functions is handled from gcc 4.0 to
gcc 3.4.2.
If function instrumentation is enabled, the whole function is wrapped in a try
finally block, where the exit call is done from the finally block.
So I think the whole function is generated in tree_rest_of_compilation() in
tree-optimize.c. I am able to create the try finally node, but I am having
trouble determining the syntax to call the exit method inside the finally block.
Below is the code I am trying to insert after the function is fully created but
before the assembly has been generated. Does anyone have any ideas as to the
correct syntax for building this call?
if (flag_instrument_function_entry_exit
! DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT (fndecl))
{
tree tf, try, finally;
rtx entry;
try = DECL_SAVED_TREE (fndecl);
/** wrap the current function inside the try finally block *.
tf = build (TRY_FINALLY_EXPR, void_type_node, try, NULL);
TREE_SIDE_EFFECTS (tf) = 1;
/** Following is code that does not work to call the exit function
entry = DECL_RTL(tf);
entry = XEXP(entry,0);
emit_library_call (profile_function_exit_libfunc, LCT_NORMAL, VOIDmode,
2, entry, Pmode,
expand_builtin_return_addr
(BUILT_IN_RETURN_ADDRESS,
0,
hard_frame_pointer_rtx),
Pmode);
*/
DECL_SAVED_TREE (fndecl) = tf;
}
- Chris
At 10:08 AM 4/13/2005 -0400, Andrew Pinski wrote:
On Apr 13, 2005, at 10:06 AM, Chris Kirby wrote:
We are trying to use -finstrument-functions to do some custom profiling on
x86 and ppc.
For normal code execution, it works fine, calling our entry and exit methods
as expected.
Unfortunately, we are running into problems related to exceptions. If we
exit a function because of an exception, no exit method is called.
This greatly diminishes the usefulness of the instrumentation since we are no
longer guaranteed to get matching entry and exit calls.
It works the way you want to for the 4.0 release.
Unfortunately our next release will be using gcc 3.4.2.
Looking at the 4.0 code, I can see that the exit instrumentation is done by
wrapping a try finally around the entire function. Backporting this to 3.4.2
isn't as straightforward as I hoped. I think something similar could be done
in tree-optimize.c's tree_rest_of_compilation() but it looks like some of the
tree/RTL methods have changed in 4.0.
Are there any examples of wrapping a method with a try finally clause and
calling a given method compatible with 3.4.2?
- Chris
Re: Objective-C++ Status
On Thursday, April 14, 2005, at 09:50 PM, Douglas Charles wrote: What is the status of Objective-C++ support in mainline GCC? Ziemowit Laski was working on integrating such support late last year, but has Apple since halted such integration efforts? I don't believe anyone is working on it at the moment. It exists, you just have to grab from the apple-local-200502-branch if you want it. If you'd like to work on it, let us know, we'd be happy to have the help.
Re: inline-unit-growth trouble
On Friday, April 15, 2005, at 09:01 AM, Andreas Krebbel wrote: on S/390 we have currently a plenty of testsuite failures due to inlining effects. ld complains about testcases which try to link two files containing the same function in .gnu.linkonce sections but with different code sizes. This is a linker bug, fix it, then come back. If you're confused, try porting GNU ld and using it, or take a look at bfd/elflink.c, under SEC_LINK_DUPLICATES_DISCARD v SEC_LINK_DUPLICATES_SAME_SIZE.
Re: inline-unit-growth trouble
On Friday, April 15, 2005, at 11:50 AM, Christopher Jefferson wrote: Is it really the job of the linker to choose between different implementations of a function? Yes. Why do you ask? It seems to me that this might lead to very, very difficult to track down bugs Nope. All those bugs are trivial to track down, as once you find the translation unit that contained the compiled code with something called a debugger, you submit the -E for it and that flags used to compile it, and because the compiler is deterministic, all such bugs are trivial to track down.
Re: inline-unit-growth trouble
On Fri, Apr 15, 2005 at 12:18:54PM -0700, Mike Stump wrote: On Friday, April 15, 2005, at 09:01 AM, Andreas Krebbel wrote: on S/390 we have currently a plenty of testsuite failures due to inlining effects. ld complains about testcases which try to link two files containing the same function in .gnu.linkonce sections but with different code sizes. This is a linker bug, fix it, then come back. If you're confused, try porting GNU ld and using it, or take a look at bfd/elflink.c, under SEC_LINK_DUPLICATES_DISCARD v SEC_LINK_DUPLICATES_SAME_SIZE. Agreed. At first I was inclined to think otherwise, but then I realized that we could also get different sizes by linking together code produced by different compiler versions, or at different optimization levels, and it certainly must be supported that -00 code can be linked with -O2 code. So yes, the linker should just shut up and pick one version. Consistency of inlining might be an issue, but it's a red herring in this case. There are too many other circumstances that could yield different sizes.
Re: [m68k]: More trouble with byte moves into Address registers
For some reason reload has decided that it needs ADDR_REGS for the
register being reloaded, namely (reg:QI 1420). So gcc looks for a
register in ADDR_REGS which can hold QImode. Because of your changes,
it doesn't find one. So it crashes.
The question is why reload thinks that it needs ADDR_REGS for this
register. Look at the local-alloc debugging dump to see where
regclass thinks that the register should go.
Ok, will do. The previous suggetsion of converting from ?a to *a with
the original version of PREFERRRED_RELOAD_CLASS causes the build of
glibc to crash with:
../sysdeps/generic/printf_fphex.c: In function `__printf_fphex':
../sysdeps/generic/printf_fphex.c:490: error: unable to find a register to
spill in class `ADDR_REGS'
../sysdeps/generic/printf_fphex.c:490: error: this is the insn:
(insn 3081 3080 3075 216 ./_itowa.h:58 (set (subreg:SI (reg/v:QI 49 [ leading
]) 0)
(plus:SI (subreg:SI (reg/v:QI 49 [ leading ]) 0)
(const_int 1 [0x1]))) 121 {*addsi3_5200} (nil)
(nil))
../sysdeps/generic/printf_fphex.c:490: confused by earlier errors, bailing out
I'm rebuilding the toolchain without the ?a change. What in the .lreg
dump am I looking for that will tellm where regclass things that the
register should go? Is it:
;; Register 1421 in 0.
--
Peter Barada
[EMAIL PROTECTED]
Re: inline-unit-growth trouble
Mike Stump wrote: On Friday, April 15, 2005, at 11:50 AM, Christopher Jefferson wrote: Is it really the job of the linker to choose between different implementations of a function? Yes. Why do you ask? Because I'm not an expert on linkers :) It seems to me that this might lead to very, very difficult to track down bugs Nope. All those bugs are trivial to track down, as once you find the translation unit that contained the compiled code with something called a debugger, OK, it was a silly question, but was it necessary to be that insulting? you submit the -E for it and that flags used to compile it, and because the compiler is deterministic, all such bugs are trivial to track down. I was more thinking a situation like: 1) I write slightly buggy file A, which generates some some function in .gnu.linkonce from a library function. I also have good file B (assume A and B have no real connection), which generates the same library function. My program works. 2) I edit and recompile file B which causes some different inlining to occur in the functions in .gnu.linkonce. B's copy of the library function gets chosen, and this happens to break functions in file A. I assume however the bug has to be in file B, as thats what I just changed, and it has no connection to file A I know of. Of course it's been pointed out that of course exactly the same problem occurs if you compile different files at different optimisation levels, so it's unavoidable anywhere perhaps... Chris
Re: struct __attribute((packed));
On Fri, 2005-04-15 at 10:39 -0600, E. Weddington wrote:
What?! That whole section in the docs talks about attributes on types.
If it doesn't work as described, then the docs need some serious rework.
From what I see, the example for packed types doesn't even compile:
(Direct cut'n'paste from
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-
Attributes):
# cat tmp.c
struct my_unpacked_struct
{
char c;
int i;
};
struct my_packed_struct __attribute__ ((__packed__))
{
char c;
int i;
struct my_unpacked_struct s;
};
# gcc -Wall -o tmp.o -c tmp.c
tmp.c:8: error: syntax error before '{' token
tmp.c:12: error: syntax error before '}' token
# gcc --version
gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
Ralf
Re: struct __attribute((packed));
Ralf Corsepius wrote:
On Fri, 2005-04-15 at 10:39 -0600, E. Weddington wrote:
What?! That whole section in the docs talks about attributes on types.
If it doesn't work as described, then the docs need some serious rework.
From what I see, the example for packed types doesn't even compile:
(Direct cut'n'paste from
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-
Attributes):
# cat tmp.c
struct my_unpacked_struct
{
char c;
int i;
};
struct my_packed_struct __attribute__ ((__packed__))
{
char c;
int i;
struct my_unpacked_struct s;
};
# gcc -Wall -o tmp.o -c tmp.c
tmp.c:8: error: syntax error before '{' token
tmp.c:12: error: syntax error before '}' token
# gcc --version
gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
Saved as PR 21052
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21052
Eric
Re: inline-unit-growth trouble
On Friday, April 15, 2005, at 01:49 PM, Christopher Jefferson wrote: Mike Stump wrote: On Friday, April 15, 2005, at 11:50 AM, Christopher Jefferson wrote: Is it really the job of the linker to choose between different implementations of a function? Yes. Why do you ask? Because I'm not an expert on linkers :) That's ok, I'm not either. [honest] OK, it was a silly question, but was it necessary to be that insulting? Sorry, I could have phrased it better. I was more thinking a situation like: Well, let me just say that a debugger will tell you what is wrong, and where it was, and from which translation unit it came from.
Re: Heads-up: volatile and C++
On 2005-04-15, at 20:18, Mike Stump wrote: On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote: Templates are a no-go for a well known and well defined subset for C++ for embedded programming known commonly as well embedded C++. My god, you didn't actually buy into that did you? Hint, it was is, and always will be a joke. You dare to explain what's so funny about it?
Re: Heads-up: volatile and C++
On 2005-04-15, at 19:58, Gabriel Dos Reis wrote: | Templates are a no-go for a well known and well defined subset for C++ | for embedded programming known commonly as well embedded C++. You'd be surprised to learn that embedded systems people do use templates for various things -- among which, maybe the most paradoxical is to avoid code bloat. Embedded C++ was a mistake, alas a mistake that seems to last. The seems to last point is the significant one. Not your superstitions about what I do or don't know about.
Re: Heads-up: volatile and C++
On Friday, April 15, 2005, at 02:52 PM, Marcin Dalecki wrote: My god, you didn't actually buy into that did you? Hint, it was is, and always will be a joke. You dare to explain what's so funny about it? Oh, it wasn't funny. Maybe the English is slightly too idiomatic? I'd need someone that understands the English and German to translate. You can read it as, it was and will always be, just a bad idea.
Vectorizing my loops. Some problems.
Hi,
I just started to work on some loop vectorizing for my project. Some
weeks ago I got a snapshot of GCC-4.1-20050313. It compiled my code but
I was not able to get the auto-vectorization working. (Yes, I understand
why)
I decided to try sse intrinsics (X86 Built-in Functions as the manual
says) instead of auto-vectorization.
I wrote some lines:
typedef int v4sf __attribute__ ((mode(V4SF)));
typedef union _vec4f {
v4sf v;
float f[4];
} vec4f;
Blah bla
for( j = 32; j ; j--, prW += 4, pr += 4 ){
vec0 = __builtin_ia32_loadups(pr);
vec1 = __builtin_ia32_loadups(prW);
vec3 = __builtin_ia32_mulps(vec0, vec1);
sum.v = __builtin_ia32_addps(sum.v, vec3);
}
and this works fine when I compile with GCC 3.4.2
However... If I try to compile this with the GCC 4.1 snapshot I get
errors and warnings:
/msys/1.0/local/bin/gcc.exe -O3 -msse -Wall -DHAVE_CONFIG_H -I. -I..
-c -o neuralnet.o neuralnet.c
neuralnet.c:447: warning: specifying vector types with __attribute__
((mode)) is deprecated
neuralnet.c:447: warning: use __attribute__ ((vector_size)) instead
neuralnet.c:447: error: mode 'V4SF' applied to inappropriate type
neuralnet.c: In function 'Evaluate':
neuralnet.c:510: error: incompatible type for argument 1 of
'__builtin_ia32_xorps'
neuralnet.c:510: error: incompatible type for argument 2 of
'__builtin_ia32_xorps'
neuralnet.c:510: error: incompatible types in assignment
neuralnet.c:512: error: incompatible types in assignment
neuralnet.c:513: error: incompatible types in assignment
neuralnet.c:514: error: incompatible type for argument 1 of
'__builtin_ia32_mulps'
neuralnet.c:514: error: incompatible type for argument 2 of
'__builtin_ia32_mulps'
neuralnet.c:514: error: incompatible types in assignment
neuralnet.c:515: error: incompatible type for argument 1 of
'__builtin_ia32_addps'
neuralnet.c:515: error: incompatible type for argument 2 of
'__builtin_ia32_addps'
neuralnet.c:515: error: incompatible types in assignment
make: *** [neuralnet.o] Error 1
So... from when was __attribute__ ((mode)) deprecated? How do I declear
the v4sf vector type?
Will the right declaration of v4sf type fix the incompatible type in
assignment and argument problems?
Thanks for any help!
-Øystein
Re: Heads-up: volatile and C++
Marcin == Marcin Dalecki [EMAIL PROTECTED] writes: Marcin On 2005-04-15, at 20:18, Mike Stump wrote: On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote: Templates are a no-go for a well known and well defined subset for C++ for embedded programming known commonly as well embedded C++. My god, you didn't actually buy into that did you? Hint, it was is, and always will be a joke. Marcin You dare to explain what's so funny about it? The fact that many of the C++ features omitted from embedded C++ are perfectly valid and useful for embedded systems programming, and cause neither space nor speed problems in the hands of reasonably competent programmers. I looked at it once, prompted by a question from engineering management here. It was immediately obvious that many of the feature deletions were driven by language religion (e.g., design choices made differently in some other object-oriented languages) and had no factual basis in performance or code size. Either that, or the choices were based on the assumption that cfront is a state of the art C++ compiler. So we decided to ignore embedded C++ as irrelevant. Our subsequent system implementation experience confirmed the validity of this analysis. paul
Re: Heads-up: volatile and C++
On Friday, April 15, 2005, at 03:19 PM, Marcin Dalecki wrote: You can read it as, it was and will always be, just a bad idea. When will be a full and standard conforming template implementation in GCC finished then? ? Seriously, what does that have to do with anything? I know, let's not recommend C for device driver programming, because there doesn't exist a C compiler that doesn't have a bug in the world. My claim would be, there is a reasonable portable subset of C, or C++ that one can use in their endeavors. Further, while in 1992, this subset maybe didn't reasonably include templates, that in 2005, it does. If for you, it doesn't, well, ok, fine. Go research why that thing that I refuse to even name, doesn't include templates, report back here, when you have the answer. Don't accept the marketing explanation either. I can then check, and see if your answer matches mine. We can then discuss if, at the time, it made for a good decision for the so named subset, it did not.
gcc-3.4-20050415 is now available
Snapshot gcc-3.4-20050415 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050415/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050415 You'll find: gcc-3.4-20050415.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050415.tar.bz2 C front end and core compiler gcc-ada-3.4-20050415.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050415.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050415.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050415.tar.bz2 Java front end and runtime gcc-objc-3.4-20050415.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050415.tar.bz2The GCC testsuite Diffs from 3.4-20050408 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.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.
Re: Heads-up: volatile and C++
On 2005-04-16, at 00:38, Mike Stump wrote: Seriously, what does that have to do with anything? Well perhaps my view is somehow shed by the project I'm currently sitting on. It's actually kernel programming. And this occurs for me quite to be quite the kind of stuff, which may be very well put this kind of object serialization to good use... I know, let's not recommend C for device driver programming, because there doesn't exist a C compiler that doesn't have a bug in the world. Actually I see you point and agree. However what one really needs for device driver programming is actually a super-set of C. My claim would be, there is a reasonable portable subset of C, or C++ that one can use in their endeavors. Further, while in 1992, this subset maybe didn't reasonably include templates, that in 2005, it does. If for you, it doesn't, well, ok, fine. OK agreed. Go research why that thing that I refuse to even name, doesn't include templates, report back here, when you have the answer. As you already pointed out the reasons stated that long ago are of no particular argumentative interest nowadays. However the conclusions itself may still be valid for other reasons. Well as a side note - my main problems with templates are not the ideas involved here. Or the coding style design paradigmas it permits. However there are serous validation concerns in shed of the seemingly always evolving and very very extensive specification. It looks like there is always a corner case in behavior which has to be plunged in the next standard revision. Template driven code too tends to be somehow immune to even simpler things like independent peer review. There are pragmatical deficiencies in *all* the implementations I had to deal with thus far. There are related maintenance problems over time and when changing compilers. And so on. However I fully agree that those points don't apply universally and there are a lot of valid uses of the whole C++ set. I recognize as well that in the case of GCC itself the implementation of this facility got much much better during recent years. I just don't agree that something specified as a subset guided effectively at the lie of exclusion of all language constructs which can be described as conceptually difficult should be dismissed straight away. It can be useful if only for example for the case where you have some people with truly bad habits on your team to put a stop gap on them. (Most of template driven code out there written in house sure as hell didn't look exactly pretty thus far to me...) Don't accept the marketing explanation either. Agreed. Maybe the idea of a subset of C++ basically coming down what would be a C with inheritance was somehow over-hyped by too much marketing bragging as an excuse for some defective C++ compiler implementation at introduction? Thus you still have grief memories about it? I can then check, and see if your answer matches mine. We can then discuss if, at the time, it made for a good decision for the so named subset, it did not. Well I don't thing it's a question of good or bad. It's more like a question of whatever it's sufficiently usefull.
Re: [m68k]: More trouble with byte moves into Address registers
Peter Barada wrote:
pp_pack.c:2220: error: unable to find a register to spill in class `ADDR_REGS'
pp_pack.c:2220: error: this is the insn:
(insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 8 %a0 [1421])
(plus:SI (subreg:SI (reg:QI 1420) 0)
(const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list 5558
(nil))
You might want to look at CANNOT_CHANGE_MODE_CLASS, which can be used to
change how reload handles (subreg:SI (reg:QI)). That might help avoid
generating QImode ADDR_REG reloads in the first place.
But if they are generated, then you need second reloads to resolve them
as Ian mentioned. There is probably no way to avoid implementing this.
You should also look at MODES_TIEABLE_P, which may also help prevent
getting QImode ADDR_REG reloads.
Even if you fix both of these, you will probably still need the
secondary reload support for this case.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Heads-up: volatile and C++
Marcin Dalecki: Don't accept the marketing explanation either. Agreed. Maybe the idea of a subset of C++ basically coming down what would be a C with inheritance was somehow over-hyped by too much marketing bragging as an excuse for some defective C++ compiler implementation at introduction? Thus you still have grief memories about it? I distinctly remember the Sophia Antipolis meeting (just after the standard was completed, pending ISO official approval) where the issue was brought up vividly with numbers. At the time, the reasons (whether excuses or not) were unconvincing, today they still are unconvincing. One ends up trying to find other reasons or excuses to make the conclusion hold. Ahem. I guess this subthread is diluting the topic advertized by the Subject: of this message. -- Gaby
Re: Template and dynamic dispatching
[ I changed the title so that the main topic -- volatile and C++ -- not be diluted ] Robert Dewar: Paul Koning wrote: Marcin == Marcin Dalecki [EMAIL PROTECTED] writes: Marcin On 2005-04-15, at 20:18, Mike Stump wrote: On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote: Templates are a no-go for a well known and well defined subset for C++ for embedded programming known commonly as well embedded C++. My god, you didn't actually buy into that did you? Hint, it was is, and always will be a joke. Marcin You dare to explain what's so funny about it? The fact that many of the C++ features omitted from embedded C++ are perfectly valid and useful for embedded systems programming, and cause neither space nor speed problems in the hands of reasonably competent programmers. One other driver here is certification issues. For example, there are severe concerns about safety critical certification of dynamic dispatching, and templates (and Ada generics) cause trouble with some certification requirements and formal verification tools. I don't know if these considerations played a part in embedded C++ design, but one would think that this would be a consideration. C++ templates do not involve dynamic dispatching (I would suspect the same to be true for Ada generics) so I do not understand your comment. Maybe there are unsopken assumptions? -- Gaby
Re: Template and dynamic dispatching
Gabriel Dos Reis wrote: C++ templates do not involve dynamic dispatching (I would suspect the same to be true for Ada generics) so I do not understand your comment. Maybe there are unsopken assumptions? As I said, templates and Ada generics cause trouble with certification requirements in two respects. First, they have the potential to intefere with required traceability from source to object. Second, there are a number of formal techniques that are used in certification for which support of generics/templates is an issue. Visit the praxis site (www.praxis-his.com) for more insight into this issue. Praxis is certainly of the opinion that a limited form of generics can be accomodated, but I do not think that anyone would suggest that unlimited use of C++ templates could be easily accomodated by some of these tools.
An old timer returns to the fold
For those of you who I've worked with in the past on various GCC issues, I have returned back to GCC land after a long sojourn in other compilation systems. I will start work at AMD on Monday, April 18th, 2005, but I suspect it will be some time before I'm back up to speed. -- Michael Meissner email: [EMAIL PROTECTED] http://www.the-meissners.org
implicit type cast problem of reference of ponter to const type
the following code can not compile. is it due to the standard?
void testfun(const int *pr)
{
}
main()
{
int *p;
testfun(p);
}
[Bug c++/21038] Poor diagnostic
--- Additional Comments From igodard at pacbell dot net 2005-04-15 06:04 --- Yes, it's a design flaw of C that parens and bracked are so overloaded that the compiler (or the human) can't tell if the problem is too many openers or not enough closers. Still, every little bit helps :-) Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21038
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From nicolas dot girard at nerim dot net 2005-04-15 06:09 --- Sure. Actually the main file is a .F file. The tgz I'm about to attach contain the following files: - main.F : main file - guess.h params.h pinch_complet.h prec.h: included by the preprocessor - routines.h.ok : when renamed to routines.h, the program compiles fine - routines.h.bug: when renamed to routines.h, causes the bug to appear $ diff routines.* gives: 408c408 subroutine solution(n,xf,fg,h1,h2,beta,pas,tolerance,nmax,xav) --- subroutine solution(xf,fg,h1,h2,beta,pas,tolerance,nmax,xav) 438c438 parameter (n1=5,n2=5,ndims=10) --- parameter (n1=5,n2=5,n=1024,ndims=10) All I did was to add n as a new parameter of the solution() subroutine ; here the call to solution() is unchanged but adding a variable corresponding to n in the function call changes nothing, the bug still appears. Thanks again, cheers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From nicolas dot girard at nerim dot net 2005-04-15 06:10 --- Created an attachment (id=8639) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8639action=view) Source files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
[Bug preprocessor/21039] New: libcpp incorrectly handles different headers with same name
This hits when compiling rrdtools, which creates a perl .xs module. It's and autoconf package, and hence has a config.h. perl also has a config.h used from it's headers (by doing a 'include config.h', so the one from the perl include dir is used correctly), which has a multiple include guard. Once the perl config.h is included the source goes on, and tries to include it's own config.h. There is no way anymore due to the bug. It tries to do this with '#include config.h', i.e. just searching the -I paths (which are setup correctly, so it could find it in ../config.h). But this doesn't work anymore (it did with 3.3.x), as somehow it seems that the place of config.h as it first was found is cached (the perl one), and then the ../config.h one isn't even tried. To demonstrate this I've put a tarball below. After unpacking, please do: % cd a % find -type f ./b/header.h ./b/inc-b.h ./c/inc.c ./header.h % cd c % gcc-4 -E -I .. -I ../b inc.c # 1 inc.c # 1 built-in # 1 command line # 1 inc.c # 1 ../b/inc-b.h 1 # 1 ../b/header.h 1 B # 1 ../b/inc-b.h 2 # 2 inc.c 2 Note how the two include directives in inc.c have no effect, _although_ -I .. is before -I ../b in the cmdline. gcc 3 does it correctly: % gcc-3 -E -I .. -I ../b inc.c | grep header.h # 1 inc.c # 1 built-in # 1 command line # 1 inc.c # 1 ../b/inc-b.h 1 # 1 ../b/header.h 1 B # 2 ../b/inc-b.h 2 # 2 inc.c 2 # 1 ../header.h 1 A # 3 inc.c 2 # 1 ../header.h 1 A # 4 inc.c 2 -- Summary: libcpp incorrectly handles different headers with same name Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at suse dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
[Bug preprocessor/21039] libcpp incorrectly handles different headers with same name
--- Additional Comments From matz at suse dot de 2005-04-15 06:21 --- Created an attachment (id=8640) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8640action=view) Tarball with the testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
[Bug c++/21040] New: Segmentation fault on template/typedef typo
g++ reports: gpp_bug.cpp:10: internal compiler error: Segmentation fault, on
both Gentoo Linux (gcc 3.3.5) and Solaris (gcc 3.3.2).
Full output of g++ gpp_bug.cpp:
gpp_bug.cpp: In function `void func()':
gpp_bug.cpp:10: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://bugs.gentoo.org/ for instructions.
Preprocessed source stored into /tmp/ccIkMcGH.out file, please attach this to
your bugreport.
Output of g++ -v on the Linux system:
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs
Configured with: /var/tmp/portage/gcc-3.3.5-r1/work/gcc-3.3.5/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3.5
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5/info
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/include/g++-v3
--host=i686-pc-linux-gnu --disable-altivec --enable-nls
--without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --enable-shared --enable-threads=posix
--disable-multilib --enable-java-awt=gtk --enable-languages=c,c++,f77,java
Thread model: posix
gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)
Offending source code:
//BEGIN SOURCE CODE:
template class T
struct bar {
typedef T INNER_TYPE_DEF;
};
templateclass T
void func(){
typedef typename barT::INNER_TYPE_DEF LOCAL_TYPE_DEF;
LOCAL_TYPE_DEFT b;
}
int main(){ }
//END SOURCE CODE
Obviously LOCAL_TYPE_DEFT is nonsensical, I stumbled on this segfault as a
result of a typo.
--
Summary: Segmentation fault on template/typedef typo
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sjanssen at cse dot unl dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21040
[Bug middle-end/20991] [4.0 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From matz at suse dot de 2005-04-15 06:51 --- Perhaps due to the IPA infrastructure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug middle-end/21032] GCC 3.4.3 wrongly reorders floating-point operations
--- Additional Comments From bagnara at cs dot unipr dot it 2005-04-15 07:01 --- Subject: Re: GCC 3.4.3 wrongly reorders floating-point operations pinskia at gcc dot gnu dot org wrote: Note neg just flips a bit so it is correct anyways and there is no loss of precession. Can you please clarify what do you mean by correct? I believe that: 1) The produced code is incorrect, since operations cannot be reordered that way. Notice that the compiler cannot prove that the result is the same (in fact it is not, in general, as it depends on the rounding direction). 2) A piece of standard C that, when correctly compiled, performs a double to float conversion rounding up, when the rounding mode is downward, or rounding down, when the rounding mode is upward, no longer works when compiled with GCC. So the produced code is incorrect not only from a language-lawyer point of view: I am actually obtaining the wrong results. All the best, Roberto Bagnara -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug c++/20812] contextual overload resolution failure for a member name found in two base classes
--- Additional Comments From SWElef at post dot sk 2005-04-15 07:30 ---
I was wrong. std:10.2/2 (member name lookup) says
[snip] If the resulting set of declarations are not all from sub-objects of
the same type, or the set has a nonstatic member and includes members from
distinct sub-objects, there is an ambiguity and the program is ill-formed.
[snip]
So the deduction may not succeed. On the other hand, IIRC it is also not
supposed to fail since the paragraph 14.8.2/2 that names all reasons for
deduction failure does not contain anything about this specific case. The
only reason that seems a little similar reads
Attempting to use a type in the qualifier portion of a qualified name that
names a type when that type does not contain the specified member, or if the
specified member is not a type where a type is required.
and in this case the named type _contains_ the specified member, it's just
ambiguous.
To expose the problem I wrote this new snippet:
struct B1{ typedef int T; };
struct B2{ typedef int T; };
struct D : B1, B2 { };
template typename X
typename X::T foo() { return X::T(); }
int main(){ fooD(); }
gcc reports error: no matching function for call to `foo()'. Comeau Online
says error: D::T is ambiguous which is very different (and IIRC correct).
May be this PR should be resolved as INVALID and another one should be written
with this snippet and a more appropriate subject.
Regards,
Vladimir Marko
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20812
[Bug tree-optimization/21004] [4.1 Regression] gcc.dg/builtins-53.c fails
--- Additional Comments From uros at kss-loka dot si 2005-04-15 07:42 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21004
[Bug target/21041] New: ICE: output_operand: Cannot decompose address
The below testcase is extracted from smpeg. It's C++. Compile it like
so:
% ./gcc/cc1plus -O2 -fPIC video.ii
video.cpp: In function 'int ParseMacroBlock(VidStream*)':
video.cpp:2205: internal compiler error: output_operand: Cannot decompose
address.
I wasn't able to make the functions much smaller than this (didn't try
reducing the headers, though).
--
Summary: ICE: output_operand: Cannot decompose address
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: uweigand at de dot ibm dot com
ReportedBy: matz at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: {s390,s390x}-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug target/21041] ICE: output_operand: Cannot decompose address
--- Additional Comments From matz at suse dot de 2005-04-15 08:19 --- Created an attachment (id=8641) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8641action=view) Preprocessed source for the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug target/21041] ICE: output_operand: Cannot decompose address
--- Additional Comments From matz at suse dot de 2005-04-15 08:20 --- Forgot to say, the preprocessed file is for s390x. On s390 the same happens, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-15 08:30 --- Reduced testcase is: $ cat pr21034.f subroutine solution(n) implicit none integer n real dte(n) save print *, dte end $ gfortran -c pr21034.f pr21034.f: In function solution: pr21034.f:4: internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036 Please note that if print *,dte is replaced by any other statement using dte (such as dte(:) = 0 or call anothersub(dte)), the bug is the same. Removing this line, removing the save statement or make n a parameter lead to correct compilation. -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-15 08:30:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
