Re: US-CERT Vulnerability Note VU#162289
A theoretical argument for why somebody might write problematic code is http://www.fefe.de/openldap-mail.txt . But that's like "putting the cart before the horses" (and complaining that it does not work). You find a security problem, you find a solution, you find the compiler optimizes away, you blame the compiler. You don't look for an alternative, which would be the most sensible: compare the length with the size, without unnecessary pointer arithmetic. Since the length is unsigned, it's enough to do this: if (len > (size_t) (max - ptr)) /* overflow */ ; Paolo
A question regarding define_split pattern
Hello all, I have the following define_insn and define_splt pattern (define_insn "movhi_const" [(set (match_operand:HI 0 "register_operand" "=r,r,r,r,r") (match_operand:HI 1 "immediate_operand" "L,K,N,O,i"))] ) (define_split [(set (match_operand:HI 0 "register_operand" "") (match_operand:HI 1 "immediate_operand" ""))] "reload_completed" ) In the define_insn for some alternatives i have '#' and for some i have the instruction template. But irrespective of whether '#' is present in the output template or not all the alternatives are being spilt. Should i be having a define_split specific for an alternative or only the '#' alternative will be split? Thanks for you time. Regards, Shafi
Re: IA-64 ICE on integer divide due to trap_if and cfgrtl
On Tue, Apr 15, 2008 at 6:27 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Jim Wilson <[EMAIL PROTECTED]> writes: > > > It seems odd that cfgrtl allows a conditional trap inside a basic block, > > but not an unconditional trap. The way things are now, it means we need > > to fix up the basic blocks after running combine or any other pass that > > might be able to simplify a conditional trap into an unconditional trap. > > > > I can work around this in the IA64 port. For instance I could use > > different patterns for conditional and unconditional traps so that one > > can't be converted to the other. Or I could try to hide the conditional > > trap inside some pattern that doesn't get expanded until after reload. > > None of these solutions seems quite right. > > > > But changing the basic block tree during/after combine doesn't seem > > quite right either. > > > > The other solution would be to fix cfgbuild to treat all trap > > instructions are control flow insns, instead of just the unconditional > > ones. I'm not sure why it was written this way though, so I don't know > > if this will cause other problems. I see that sibling and noreturn > > calls are handled the same way as trap instructions, implying that they > > are broken too. > > I think the current cfgbuild behaviour is just to avoid putting a > barrier in the middle of a basic block. A conditional trap > instruction is not necessarily a control flow instruction for the > compiler--it's similar to a function call which may or may not return. > An unconditional trap is similar to a function call which is known to > not return. > > I guess the difference is that combine can't turn a function call > which may or may not return into a function call which will not > return. > > Since traps are uncommon, and since you can't do a lot of optimization > around them anyhow, it's probably OK to make them always return true > from control_flow_insn_p. At least it's worth trying to see if > anything breaks. A similar issue exists on the tree level when you try to fix PR35468 the "right" way. Consider char *const line = "/dev/ptyXX"; line[8] = 1; ... the assignment to line[8] is a "conditional trap" which ccp transforms into "/dev/ptyXX"[8] = 1; which is invalid GIMPLE and we'd like to fold into a un-conditional trap (__builtin_trap(), as done elsewhere). Of course now you need to start splitting basic blocks in fold_stmt or teach its callers that it may need to cleanup themselves... both is kind of ugly, but of course we don't want every store to end a basic block either... Richard.
Re: Problem with reloading in a new backend...
Le lundi 14 avril 2008 à 18:27 -0700, Jim Wilson a écrit : > On Tue, 2008-04-15 at 00:06 +0200, Stelian Pop wrote: > > - I had to add a PLUS case in PREFERRED_RELOAD_CLASS() or else reload > > kept generating incorrect insn (putting constants into EVEN_REGS for > > example). I'm not sure this is correct or if it hides something else... > > It does sound odd, but I can't really say it is wrong, as you have an > odd set of requirements here. At least it is working which is good. Ok, thanks again. Stelian. -- Stelian Pop <[EMAIL PROTECTED]>
Re: Moving statements from one BB to other BB.
On Tue, Apr 15, 2008 at 7:49 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote: > On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > To clarify what Richard means, your assertion that "you have updated > > SSA information" is false. > > If you had updated the SSA information, the error would not occur :). > > > > How exactly are you updating the ssa information? > > I am calling update_ssa (TODO_update_ssa), after all the statements > are transferred. > > > > > > The general way to update SSA for this case would be: > > > > For each statement you have moved: > > Call update_stmt (t); > > > > Then call update_ssa (TODO_update_ssa) (or instead use > > rewrite_into_loop_closed_ssa if this is a loop pass). > > > > If you do not call update_stmt in this case, update_ssa won't actually > > do anything. > > > > Diego, the bsi iterators do not update the statements for you though > > it is not clear if this is a bug or not. > > > > The bsi iterators call update_modified_stmts, which says: > > > > /* Mark statement T as modified, and update it. */ > > static inline void > > update_modified_stmts (tree t) > > > > However, this only calls update_stmt_if_modified (IE it does not mark > > the statement as modified and update it, as it claims to). > > > > Sandeep, it should also suffice to call mark_stmt_modified *before* > > moving the statements (since the above routine should then update > > them). > > > > Thanks. I will use update_stmt, update_ssa now. You need to do more than that - you appearantly are moving uses of SSA names to a place where its definition is not available like if you do b_1 = 1; a_1 = b_1 + 1; and transform this to a_1 = b_1 + 1; b_1 = 1; which obviously cannot work. So "updating" SSA form won't help you and renaming the symbols will only make the verifier happy and leave you with wrong code. So you need to investigate what exactly you are doing wrong with your stmt movement. Richard.
template parameter does not hide class name
Hello all,
I have tested the following code on g++ 4.3, 4.2, 4.1 and 3.4.
#include
struct B {
static const int x = 1;
};
struct A {
static const int x = 0;
template
static void f() {
std::cerr << A::x << std::endl;
}
};
int main() {
A::f();
return 0;
}
The program just write zero to the standard error, which means that the
template parameter does not hide the class name. I have tested other
compilers, and they write one to the standard error. I do not know surely,
but I mean this a bug in gcc or a very strange behaviour of c++ standard.
Best, Balazs
Re: RFC: named address space support
On Tue, 15 Apr 2008, Ben Elliston wrote: > Hi Mark > > > I'm not terribly familiar with this proposal. > > > Ben, to answer your original question, I don't think that lack of nested > > address spaces is a fatal flaw, as long as the implementation otherwise > > meets the spec, and as long as the implementation doesn't somehow make > > it harder to add that. However, I'd like to know how final this > > proposal is, and how likely it is to make the WG14 WP. > > According to: > http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30822 > > .. the embedded C proposal as of 2008-01-18 is at stage 90.92. This > suggests that it's very close to being incorporated into the standard. > Have I understood that correctly? No. All it means is that TR 18037 is being revised, not anything to do with the standard. This is a TR Type 2, not an IS, and remains a TR Type 2, not an IS. As I recall, for a long time WG14 had a revised version fixing problems in the original TR, but trouble getting ISO to accept it; all the status means is that ISO is now accepting the revised version for publication. (This revised version is N1275, I think; that should be used in place of N1169.) ISO has nothing to do with whether TRs may be incorporated in the standard in subsequent revisions. It may be involved if a standalone TR changes into a standalone IS, as was proposed for the draft TR 24747 (special mathematical functions), but I think that's the only TR related to ISO C with such a proposal. There is no C1x draft as yet (N1256, C99+TC1+TC2+TC3, is the base document for the revision). I don't think it's been decided which TRs might end up in the base C1x standard, though there's an Austin Group paper arguing that TR 19769 (u"" and U"" strings) should remain a TR and not be included in the standard. I don't know what might be being decided at the Delft meeting right now. The agenda has "Status of TR 18037" as an unnumbered item. A TR Type 2 may be considered as indicating "if you want a feature to do this, it may be a good idea to do it this way and so gain implementation experience for future standardization". As such, I think it is reasonable to continue to add features from such TRs to GCC, provided we understand that they are experimental and may be changed incompatibly in future to accord with future TR versions or changes in the course of inclusion in the IS; that unlike actual language standards, we will not try to provide options to support different versions of a TR in the same compiler version. (The same applies to informative annexes in an IS, which may have the same sort of content as a Type 2 TR, such as Annex G in C99.) -- Joseph S. Myers [EMAIL PROTECTED]
Re: Moving statements from one BB to other BB.
Hi, > To clarify what Richard means, your assertion that "you have updated > SSA information" is false. > If you had updated the SSA information, the error would not occur :). > > How exactly are you updating the ssa information? > > The general way to update SSA for this case would be: > > For each statement you have moved: > Call update_stmt (t); > > Then call update_ssa (TODO_update_ssa) (or instead use > rewrite_into_loop_closed_ssa if this is a loop pass). > > If you do not call update_stmt in this case, update_ssa won't actually > do anything. actually, it will not do anything even if he calls update_stmt, as the statements that he is moving are already in ssa form, so update_stmt will not mark anything for renaming. IIRC what he tries to do is loop fusion, and according to the error message that he gets, he probably needs to add the calculations of the induction variable(s) of the original loop to the new one, and replace their uses (or maybe just move phi nodes), Zdenek
bootstrap failure in gcc4.3.1 on hppa2.0w-hp-hpux11.00
revision 134311
mkdir -p -- hppa2.0w-hp-hpux11.00/libgcc
Checking multilib configuration for libgcc...
Configuring stage 1 in hppa2.0w-hp-hpux11.00/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install...
/appl/shared/gnu/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/bin/install -c
checking for gawk... gawk
checking build system type... hppa2.0w-hp-hpux11.00
checking host system type... hppa2.0w-hp-hpux11.00
checking for hppa2.0w-hp-hpux11.00-ar...
/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/ar
checking for hppa2.0w-hp-hpux11.00-lipo... lipo
checking for hppa2.0w-hp-hpux11.00-nm...
/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/nm
checking for hppa2.0w-hp-hpux11.00-ranlib...
/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/ranlib
checking for hppa2.0w-hp-hpux11.00-strip...
/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/strip
checking whether ln -s works... yes
checking for hppa2.0w-hp-hpux11.00-gcc...
/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/xgcc
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/
-B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/
-B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/lib/
-isystem
/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/include
-isystem
/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/sys-include
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether
/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/xgcc
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/
-B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/
-B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/lib/
-isystem
/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/include
-isystem
/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/sys-include
accepts -g... yes
checking for
/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/xgcc
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/
-B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/
-B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/lib/
-isystem
/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/include
-isystem
/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/sys-include
option to accept ANSI C... none needed
checking how to run the C preprocessor...
/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/xgcc
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/./gcc/
-B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/bin/
-B/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/lib/
-isystem
/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/include
-isystem
/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/hppa2.0w-hp-hpux11.00/sys-include
-E
checking whether decimal floating point is supported... no
checking whether fixed-point is supported... no
checking for __attribute__((visibility("hidden")))... no
checking whether the target asssembler upports thread-local storage... yes
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: executing default commands
Adding multilib support to Makefile in
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.3.1/libgcc
multidirs=
with_multisubdir=
gmake[3]: Entering directory
`/data1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/hppa2.0w-hp-hpux11.00/libgcc'
# If this is the top-level multilib, build all the other
gmake[3]: *** [all-multi] Error 1
gmake[3]: Leaving directory
`/data1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1/hppa2.0w-hp-hpux11.00/libgcc'
gmake[2]: *** [all-stage1-target-libgcc] Error 2
gmake[2]: Leaving directory
`/data1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory
`/data1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.1/gcc-4.3.1'
gmake: *** [all] Error 2
Does anybody else has such issues?
--
Mit freundlichen Grüßen / Best Regards
Dipl.-Ing. Rainer Emrich
Dept. Manager IT/Softwareentwicklung
TECOSIM Technische Simulation GmbH
Ferdinand-Stuttmann-Straße 15
D-65428 Rüsselsheim
Phone +49 (0) 6142 8272-330
Fax+49 (0) 6142 8272-249
Mobile +49 (0) 163 5694920
www.tecosim.com
best partner fo
Bootstrap failure on native mingw32
I'm not exactly sure how this one was introduced, but a bootstrap on native i686-pc-mingw32 dies in stage1 libgcc with: ../../../trunk/libgcc/../gcc/libgcc2.c:2052: warning: no previous prototype for 'getpagesize' ../../../trunk/libgcc/../gcc/libgcc2.c:2062: error: conflicting types for 'VirtualProtect' c:/MinGW/include/winbase.h:1995: error: previous declaration of 'VirtualProtect' was here ../../../trunk/libgcc/../gcc/libgcc2.c:2066: warning: no previous prototype for 'mprotect' The prototype for VirtualProtect in libgcc2.c is: extern int VirtualProtect (char *, int, int, int *) __attribute__((stdcall)); In , it is: BOOL __attribute__((__stdcall__)) VirtualProtect(PVOID,DWORD,DWORD,PDWORD); with: typedef unsigned long DWORD; typedef int WINBOOL; typedef WINBOOL BOOL; typedef DWORD *PDWORD; typedef void *PVOID; Does that ring a bell to anyone? Any idea why it's showing up now even though it looks like this code wasn't modified in the recent past (and my winbase.h hasn't changed since my last successful bootstrap, a month ago). Thanks, FX PS: My exact configure line is: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-shared -- FX Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: Bootstrap failure on native mingw32
[EMAIL PROTECTED] wrote on 15.04.2008 14:28:17:
> I'm not exactly sure how this one was introduced, but a bootstrap on
> native i686-pc-mingw32 dies in stage1 libgcc with:
>
> ../../../trunk/libgcc/../gcc/libgcc2.c:2052: warning: no previous
> prototype for 'getpagesize'
> ../../../trunk/libgcc/../gcc/libgcc2.c:2062: error: conflicting types
> for 'VirtualProtect'
> c:/MinGW/include/winbase.h:1995: error: previous declaration of
> 'VirtualProtect' was here
> ../../../trunk/libgcc/../gcc/libgcc2.c:2066: warning: no previous
> prototype for 'mprotect'
>
> The prototype for VirtualProtect in libgcc2.c is:
> extern int VirtualProtect (char *, int, int, int *)
> __attribute__((stdcall));
>
> In , it is:
> BOOL __attribute__((__stdcall__))
VirtualProtect(PVOID,DWORD,DWORD,PDWORD);
> with:
> typedef unsigned long DWORD;
> typedef int WINBOOL;
> typedef WINBOOL BOOL;
> typedef DWORD *PDWORD;
> typedef void *PVOID;
>
>
> Does that ring a bell to anyone? Any idea why it's showing up now even
> though it looks like this code wasn't modified in the recent past (and
> my winbase.h hasn't changed since my last successful bootstrap, a
> month ago).
>
> Thanks,
> FX
>
>
> PS: My exact configure line is: ../trunk/configure --prefix=/mingw
> --enable-languages=c,fortran --with-gmp=/home/FX/local
> --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
> --enable-bootstrap --enable-threads --disable-nls
> --build=i586-pc-mingw32 --enable-libgomp --disable-shared
>
> --
> FX Coudert
> http://www.homepages.ucl.ac.uk/~uccafco/
>
I remember that modification. This is related to a patch in
config/i386/mingw32.h to include for libgcc2 the windows header. Danny
said he tested this patch, but for this the libgcc2.c prototype is no
longer necessary for mingw targets.
Regards,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Re: Official GCC git repository
On Tue, Apr 15, 2008 at 08:37:36AM +0200, Bernie Innocenti wrote: > Daniel Berlin wrote: >> I put my version of the gcc conversion (which has all branches but no >> tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update >> it appropriately. >> >> Note that i will not announce this anywhere until someone steps >> forward to actually maintain it because i do not know GIT. Neither of >> the people who volunteered have done it even after repeated prodding >> :( >> (I don't mean to shame them, i am simply pointing out that it appears >> we need new volunteers) > > Yes, unfortunately I don't seem to find much time to dedicate > to this lately. Sorry, I'm overwhelmed by higher priority > things at this time :-( Can anybody else can do it? -- Regards, Kirill A. Shutemov + Belarus, Minsk + ALT Linux Team, http://www.altlinux.com/ signature.asc Description: Digital signature
Re: Official GCC git repository
Hi, "Daniel Berlin" <[EMAIL PROTECTED]> writes: > I put my version of the gcc conversion (which has all branches but no > tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update > it appropriately. > > Note that i will not announce this anywhere until someone steps > forward to actually maintain it because i do not know GIT. What else is needed exactly? The mirror is in place and gets automatically updated, so that's already enough for many people I think. Thanks, Ludovic.
Re: Official GCC git repository
Hi, [EMAIL PROTECTED] (Ludovic Courtès) writes: > "Daniel Berlin" <[EMAIL PROTECTED]> writes: > >> I put my version of the gcc conversion (which has all branches but no >> tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update >> it appropriately. >> >> Note that i will not announce this anywhere until someone steps >> forward to actually maintain it because i do not know GIT. > > What else is needed exactly? The mirror is in place and gets > automatically updated, so that's already enough for many people I think. Actually I just cloned the repo and I can only see the following branches: $ git-branch -rl origin/HEAD origin/master origin/pre-globals-git Something's wrong with the import? Thanks, Ludovic.
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Tue, Apr 15, 2008 at 01:20:29PM +1000, Hasjim Williams wrote: > Suffice to say, it will compile, but when you try to run it, and your > program tries to do the libcall to the sqrt function it will segfault, > because there is no libcall sqrt defined. > > As far as I can tell, sqrt and div are the only major opcodes that are > needed (for ieee754 glibc --with-fp) that aren't implemented in > MaverickCrunch. I'm going to keep asking until I get something we can work with... you're reporting a bug in the compiler, so we need a test case and the exact error message. What is generating any kind of sqrt libcall? There is nothing in GCC to call __aeabi_sqrt, which AFAIK does not exist. -- Daniel Jacobowitz CodeSourcery
Re: Bootstrap failure on native mingw32
> I remember that modification. This is related to a patch in > config/i386/mingw32.h to include for libgcc2 the windows header. OK. Bootstrap does proceed with the prototype removed, of course (it's not yet finished). Question is: can we remove it altogether, or are there still cases where it is needed? It currently is inside: #if defined(WINNT) && ! defined(__CYGWIN__) && ! defined (_UWIN) ... #ifdef __i386__ So, if it's WINNT and neither cywin nor uwin, are we guaranteed it's mingw? FX -- FX Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: Bootstrap failure on native mingw32
FX <[EMAIL PROTECTED]> wrote on 15.04.2008 15:21:30:
> > I remember that modification. This is related to a patch in
> > config/i386/mingw32.h to include for libgcc2 the windows header.
>
> OK. Bootstrap does proceed with the prototype removed, of course (it's
> not yet finished).
>
> Question is: can we remove it altogether, or are there still cases
> where it is needed?
>
> It currently is inside:
>
> #if defined(WINNT) && ! defined(__CYGWIN__) && ! defined (_UWIN)
> ...
> #ifdef __i386__
>
> So, if it's WINNT and neither cywin nor uwin, are we guaranteed it's
mingw?
I am uncertain about this. AFAICS this is just for mingw.
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Re: Bootstrap failure on native mingw32
[EMAIL PROTECTED] wrote on 15.04.2008 14:40:15: > [EMAIL PROTECTED] wrote on 15.04.2008 14:28:17: > > > I'm not exactly sure how this one was introduced, but a bootstrap on > > native i686-pc-mingw32 dies in stage1 libgcc with: > > > > ../../../trunk/libgcc/../gcc/libgcc2.c:2052: warning: no previous > > prototype for 'getpagesize' > > ../../../trunk/libgcc/../gcc/libgcc2.c:2062: error: conflicting types > > for 'VirtualProtect' > > c:/MinGW/include/winbase.h:1995: error: previous declaration of > > 'VirtualProtect' was here > > ../../../trunk/libgcc/../gcc/libgcc2.c:2066: warning: no previous > > prototype for 'mprotect' > > > > The prototype for VirtualProtect in libgcc2.c is: > > extern int VirtualProtect (char *, int, int, int *) > > __attribute__((stdcall)); > > > > In , it is: > > BOOL __attribute__((__stdcall__)) > VirtualProtect(PVOID,DWORD,DWORD,PDWORD); > > with: > > typedef unsigned long DWORD; > > typedef int WINBOOL; > > typedef WINBOOL BOOL; > > typedef DWORD *PDWORD; > > typedef void *PVOID; > > > > > > Does that ring a bell to anyone? Any idea why it's showing up now even > > though it looks like this code wasn't modified in the recent past (and > > my winbase.h hasn't changed since my last successful bootstrap, a > > month ago). Here is a patch fixing this problem 2008-04-15 Kai Tietz <[EMAIL PROTECTED]> * libgcc2.c (L_trampoline): Disable VirtualProtect declaration if _WIN32 is defined. Cheers, Kai Index: gcc/gcc/libgcc2.c === --- gcc.orig/gcc/libgcc2.c +++ gcc/gcc/libgcc2.c @@ -2058,7 +2058,7 @@ getpagesize (void) #endif } -#ifdef __i386__ +#if defined(__i386__) && !defined(_WIN32) extern int VirtualProtect (char *, int, int, int *) __attribute__((stdcall)); #endif =
Re: A question regarding define_split pattern
"Mohamed Shafi" <[EMAIL PROTECTED]> writes: > I have the following define_insn and define_splt pattern > > (define_insn "movhi_const" > [(set (match_operand:HI 0 "register_operand" "=r,r,r,r,r") > (match_operand:HI 1 "immediate_operand" "L,K,N,O,i"))] > > ) > > (define_split > [(set (match_operand:HI 0 "register_operand" "") > (match_operand:HI 1 "immediate_operand" ""))] > "reload_completed" > > ) > > In the define_insn for some alternatives i have '#' and for some i > have the instruction template. > But irrespective of whether '#' is present in the output template or > not all the alternatives are being spilt. > Should i be having a define_split specific for an alternative or only > the '#' alternative will be split? Whether a define_split takes effect is independent of whether the output template is "#". Setting the output template to "#" is just a shorthand way of saying "give an error if this split does not occur." (There actually is one difference: if the output template is "#" gcc makes one last attempt to split the insn in the final phase. You could write your split predicate such that only that attempt will succeed. But it's hard to imagine a good reason to write it that way.) Ian
DU-chains Vs UD-chains
Hi all, i'm currently studing alias analysis, and i have some questions, for instance, when are the du/ud-chains calculated? Before translating to SSA form? If i'm not wrong the def-use chain connects a definition of a variable to all the uses it may flow to, and the use-def chain connects a use to all the definitions that may flow to it. But, what chain is better for data-flow analysis? Maybe the answer is both? Thanks in advance Fran
Warning during GCC bootstrap on i686-pc-mingw32
I've seen a weird warning during a bootstrap of mainline on native
i686-pc-mingw32, which I guess is related to the recent introduction
of MS printf formats. It can be reproduced on the following small
example:
$ cat foo.i
void format_gcov (void)
{
__builtin_printf ("%I64d", (long long) 1);
}
$ ../prev-gcc/xgcc.exe -S foo.i -pedantic -Wall -Wno-long-long
foo.i: In function 'format_gcov':
foo.i:3: warning: ISO C does not support the '' ms_printf length modifier
I don't think it's the intended behaviour, as the error message is
rather unclear. Is it worth opening a PR?
Thanks,
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
[tuples] creating singleton sequences
Hey there.
Frequently we want to create a new sequence that contains one element.
This is especially common when wrapping things with a BIND or in a TRY
block.
I'm tired of typing the same thing over and over.
How about a convenience function like this?
Index: gimple.h
===
--- gimple.h(revision 134265)
+++ gimple.h(working copy)
@@ -189,6 +189,17 @@ gimple_seq_empty_p (const_gimple_seq s)
}
+/* Allocate a new sequence and initialize its first element with STMT.
*/
+
+static inline gimple_seq
+gimple_seq_alloc_with_stmt (gimple stmt)
+{
+ gimple_seq seq = NULL;
+ gimple_seq_add_stmt (&seq, stmt);
+ return seq;
+}
Re: [tuples] creating singleton sequences
On 4/15/08 11:36 AM, Aldy Hernandez wrote: I'm tired of typing the same thing over and over. Lazy bum. How about a convenience function like this? Sure. Diego.
Where is restrict keyword used in dependence analysis?
Hello,
I am porting to GCC 4.3.0 for our VLIW processor, and try to utilize
improved restrict keyword support. Somehow, I find for normal data
types, including vector types up to 8bytes, the restrict keyword works
just fine. But for wider vector, such as 4 32-bit word type, the
restrict keyword doesn't work any more. For example, for the first two
following functions, compiler can unroll (-funroll-all-loops) loops and
produces good schedule, where load instructions of next iteration can be
moved beyond store instruction of this iteration. But for the third
example, it is different. As suggested in .sched2 file, the compiler can
only resolve dependence of next load instructions after store
instruction of this iteration is scheduled. I tried to print out
tree-ssa files by using -fdump-tree-all. Unliked previous GCC (4.2.1),
the information in those files is not helpful at all. I don't know
where to look at now. Could someone point me some files/functions/data
structures by which restrict keyword is used and passed to dependence
anaylsis part? Thanks in advance.
Bingfeng Mei
Broadcom UK
Example code:
typedef intV4W __attribute__ ((vector_size (16)));
typedef intV2W __attribute__ ((vector_size (8)));
void tst(int * restrict a, int * restrict b, int * restrict c)
{
int i;
for(i = 0; i < 256; i++){
c[i] = a[i] + b[i];
}
}
void tst2(int * restrict a, int * restrict b, int * restrict c)
{
int i;
for(i = 0; i < 256; i++){
c[i] = a[i] + b[i];
}
}
void tst3(V4W * restrict a, V4W * restrict b, V4W * restrict c)
{
int i;
for(i = 0; i < 256; i++){
c[i] = a[i] + b[i];
}
}
Implementation of string-literal as template parameter
Hi, Recently i have posted an idea of new language feature to comp.lang.c++.moderated. That is "String literal as template parameter?" form 12.04.2008, if anyone is interested to see whole thread. The idea is to allow string-literals as template argument, and make them equivalent to variadic character pack 'char...'. For example: template class Foo; Foo<"abc"> would be equivalent to Foo<'a', 'b', 'c'> I am interested in writing proof of concept implementation. Since i dont have expirience with g++ codebase, I wanted to ask: 1) Is it expected to be hard to implement? (which I rather dont expect to be, but better ask :-) 2) Any hints, how/where should I start? Thanks in advance for any feedback. Piotr Rak
Re: DU-chains Vs UD-chains
On Tue, Apr 15, 2008 at 10:59 AM, Fran Baena <[EMAIL PROTECTED]> wrote: > Hi all, > > i'm currently studing alias analysis, and i have some questions, for > instance, when are the du/ud-chains calculated? ud chains are implicit in SSA form, since each use only has one reaching definiiton. du chains are calculated after SSA by the operand scanner. > Before translating to > SSA form? Nope. > If i'm not wrong the def-use chain connects a definition of a variable > to all the uses it may flow to, and the use-def chain connects a use > to all the definitions that may flow to it. But, what chain is better > for data-flow analysis? one is useful for forward dataflow, the other is useful for backwards dataflow. > Maybe the answer is both? Yes. > > Thanks in advance > > Fran >
Re: Moving statements from one BB to other BB.
On Tue, Apr 15, 2008 at 8:05 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: > Hi, > > > > To clarify what Richard means, your assertion that "you have updated > > SSA information" is false. > > If you had updated the SSA information, the error would not occur :). > > > > How exactly are you updating the ssa information? > > > > The general way to update SSA for this case would be: > > > > For each statement you have moved: > > Call update_stmt (t); > > > > Then call update_ssa (TODO_update_ssa) (or instead use > > rewrite_into_loop_closed_ssa if this is a loop pass). > > > > If you do not call update_stmt in this case, update_ssa won't actually > > do anything. > > actually, it will not do anything even if he calls update_stmt, as the > statements that he is moving are already in ssa form, so update_stmt > will not mark anything for renaming. > You are partially right (and right where it matters, that it won't fix the problem) That said, update_stmt on ssa form statements will at least reset the vuse/vdef back to original variables for renaming. Or at least that is my recollection
Re: Official GCC git repository
No, nothing is wrong wit he import, if you want all the remote branches, you have to ask git to get all the remote branches git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' Then fetch again. then, if you want to really see all the branches, including the remote ones, use git branch -a -l, not -r -l. HTH, Dan On Tue, Apr 15, 2008 at 9:14 AM, Ludovic Courtès <[EMAIL PROTECTED]> wrote: > Hi, > > > > [EMAIL PROTECTED] (Ludovic Courtès) writes: > > > "Daniel Berlin" <[EMAIL PROTECTED]> writes: > > > >> I put my version of the gcc conversion (which has all branches but no > >> tags) at git://gcc.gnu.org/git/gcc.git and set a script up to update > >> it appropriately. > >> > >> Note that i will not announce this anywhere until someone steps > >> forward to actually maintain it because i do not know GIT. > > > > What else is needed exactly? The mirror is in place and gets > > automatically updated, so that's already enough for many people I think. > > Actually I just cloned the repo and I can only see the following > branches: > > $ git-branch -rl > origin/HEAD > origin/master > origin/pre-globals-git > > Something's wrong with the import? > > Thanks, > Ludovic. > >
Re: Where is restrict keyword used in dependence analysis?
On Tue, Apr 15, 2008 at 12:01 PM, Bingfeng Mei <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I am porting to GCC 4.3.0 for our VLIW processor, and try to utilize
> improved restrict keyword support. Somehow, I find for normal data
> types, including vector types up to 8bytes, the restrict keyword works
> just fine. But for wider vector, such as 4 32-bit word type, the
> restrict keyword doesn't work any more. For example, for the first two
> following functions, compiler can unroll (-funroll-all-loops) loops and
> produces good schedule, where load instructions of next iteration can be
> moved beyond store instruction of this iteration. But for the third
> example, it is different. As suggested in .sched2 file, the compiler can
> only resolve dependence of next load instructions after store
> instruction of this iteration is scheduled. I tried to print out
> tree-ssa files by using -fdump-tree-all. Unliked previous GCC (4.2.1),
> the information in those files is not helpful at all.
How not?
If we don't know, we can't fix them :)
> I don't know
> where to look at now. Could someone point me some files/functions/data
> structures by which restrict keyword is used and passed to dependence
> anaylsis part? Thanks in advance.
You mean the dependence analysis used by the scheduler?
That stuff is in sched-deps.c
At the RTL level, restrict ends up being transformed into a different alias set.
At the tree level, restrict info is not used very much right now.
> Example code:
>
> typedef intV4W __attribute__ ((vector_size (16)));
> typedef intV2W __attribute__ ((vector_size (8)));
>
> void tst(int * restrict a, int * restrict b, int * restrict c)
> {
> int i;
> for(i = 0; i < 256; i++){
> c[i] = a[i] + b[i];
> }
> }
>
> void tst2(int * restrict a, int * restrict b, int * restrict c)
> {
> int i;
> for(i = 0; i < 256; i++){
> c[i] = a[i] + b[i];
> }
> }
>
> void tst3(V4W * restrict a, V4W * restrict b, V4W * restrict c)
> {
> int i;
> for(i = 0; i < 256; i++){
> c[i] = a[i] + b[i];
> }
> }
>
>
>
Re: Official GCC git repository
"Daniel Berlin" <[EMAIL PROTECTED]> writes: > No, nothing is wrong wit he import, if you want all the remote > branches, you have to ask git to get all the remote branches > > git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' This will put the remote branch heads in refs/remotes, you might want to put them in refs/remotes/origin instead. $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*' > Then fetch again. > then, if you want to really see all the branches, including the remote > ones, use git branch -a -l, not -r -l. git branch -r should already show all remote branches (ie. every ref under refs/remotes), git branch -a shows you all local branches in addition. (And -l has no meaning unless you create a branch.) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Official GCC git repository
On Tue, Apr 15, 2008 at 1:12 PM, Andreas Schwab <[EMAIL PROTECTED]> wrote: > "Daniel Berlin" <[EMAIL PROTECTED]> writes: > > > > No, nothing is wrong wit he import, if you want all the remote > > branches, you have to ask git to get all the remote branches > > > > git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' > > This will put the remote branch heads in refs/remotes, you might want to > put them in refs/remotes/origin instead. > > $ git config --add remote.origin.fetch > '+refs/remotes/*:refs/remotes/origin/*' > > > > Then fetch again. > > then, if you want to really see all the branches, including the remote > > ones, use git branch -a -l, not -r -l. > > git branch -r should already show all remote branches (ie. every ref > under refs/remotes), git branch -a shows you all local branches in > addition. (And -l has no meaning unless you create a branch.) I hope this helps everyone understand why i have no desire to maintain the git setup :) Git is a foreign language to me, and one I am not particularly interested in becoming fluent in. I am happy to simply be able to ask the locals where the bathroom is.
Re: Moving statements from one BB to other BB.
Hi, > > > To clarify what Richard means, your assertion that "you have updated > > > SSA information" is false. > > > If you had updated the SSA information, the error would not occur :). > > > > > > How exactly are you updating the ssa information? > > > > > > The general way to update SSA for this case would be: > > > > > > For each statement you have moved: > > > Call update_stmt (t); > > > > > > Then call update_ssa (TODO_update_ssa) (or instead use > > > rewrite_into_loop_closed_ssa if this is a loop pass). > > > > > > If you do not call update_stmt in this case, update_ssa won't actually > > > do anything. > > > > actually, it will not do anything even if he calls update_stmt, as the > > statements that he is moving are already in ssa form, so update_stmt > > will not mark anything for renaming. > > > You are partially right (and right where it matters, that it won't fix > the problem) > That said, update_stmt on ssa form statements will at least reset the > vuse/vdef back to original variables for renaming. I don't think so; as long as you do not introduce new vops (which you should not by just moving the statements), update_stmt is a no-op on vops too (unless something has changed since the last time I needed this), Zdenek
-pthread switch and binary compatibitity
Hi there, Over at the Boost C++ libraries project we're trying to decide what is the correct thing to do when code is compiled with -pthread or not. The crux of the issue is this: if gcc/g++ is configured with the pthread threading model, then are object files always binary compatible irrespective of whether they are compiled with the -pthread command line option or not? If the answer is yes, then is it commonplace to link object files compiled with and without -pthread? Basically we're trying to decide whether to try and ensure that object files compiled with and without -pthread are always binary compatible, or whether to turn threading support on *only* when -pthread is specified (and _REENTRANT gets #defined). Many thanks for your help, John Maddock.
Re: Moving statements from one BB to other BB.
On 4/15/08 1:34 PM, Zdenek Dvorak wrote: Hi, > To clarify what Richard means, your assertion that "you have updated > SSA information" is false. > If you had updated the SSA information, the error would not occur :). > > How exactly are you updating the ssa information? > > The general way to update SSA for this case would be: > > For each statement you have moved: > Call update_stmt (t); > > Then call update_ssa (TODO_update_ssa) (or instead use > rewrite_into_loop_closed_ssa if this is a loop pass). > > If you do not call update_stmt in this case, update_ssa won't actually > do anything. actually, it will not do anything even if he calls update_stmt, as the statements that he is moving are already in ssa form, so update_stmt will not mark anything for renaming. You are partially right (and right where it matters, that it won't fix the problem) That said, update_stmt on ssa form statements will at least reset the vuse/vdef back to original variables for renaming. I don't think so; as long as you do not introduce new vops (which you should not by just moving the statements), update_stmt is a no-op on vops too (unless something has changed since the last time I needed this), Right. Moving statements in SSA form needs to introduce name->name mappings (eg, as is done during loop unrolling). Diego.
Re: Official GCC git repository
> "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes: Daniel> No, nothing is wrong wit he import, if you want all the remote Daniel> branches, you have to ask git to get all the remote branches Daniel> git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' Daniel, how did you setup the git repository? The branch heads are supposed to be located under "/refs/heads/" on gcc.gnu.org, not under "/refs/remotes/", where you generally find the remote references: those branches aren't supposed to be remote on the master repository. If you populate this repository by pushing from another one, the push command should use "--mirror". Excerpt from the manual: --mirror Instead of naming each ref to push, specifies that all refs under $GIT_DIR/refs/heads/ and $GIT_DIR/refs/tags/ be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This way, branches will be kept under /refs/heads/, not put under /refs/remotes/. Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/
Re: Official GCC git repository
Hi, Samuel Tardieu <[EMAIL PROTECTED]> writes: > how did you setup the git repository? The branch heads are supposed to > be located under "/refs/heads/" on gcc.gnu.org, not under > "/refs/remotes/", where you generally find the remote references: > those branches aren't supposed to be remote on the master > repository. Indeed. I suppose you can still "mv .git/remotes/* .git/heads/"? Thanks, Ludovic.
Re: Official GCC git repository
On Tue, Apr 15, 2008 at 2:23 PM, Samuel Tardieu <[EMAIL PROTECTED]> wrote: > > "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes: > > Daniel> No, nothing is wrong wit he import, if you want all the remote > Daniel> branches, you have to ask git to get all the remote branches > > Daniel> git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' > > Daniel, > > how did you setup the git repository? Using git-svn. > The branch heads are supposed to > be located under "/refs/heads/" on gcc.gnu.org, not under > "/refs/remotes/", For git-svn, it considers the svn branches to be remotes of the svn master. IE it acts as if the svn repository was a fake git repository, so the branches from svn are remote branches on the svn server. The local git master branch just happens to be an up-to-date non-modified branch of refs/remotes/trunk HTH, Dan
RE: Bootstrap failure on native mingw32
Committed as obvious.
This was already in my sources (for another reason) when I tested Kai's patch.
Sorry for not noticing.
Danny
* libgcc2.c [L_trampoline]: Remove unnecessary prototype for
Windows VirtualProtect function.
Index: libgcc2.c
===
--- libgcc2.c (revision 134329)
+++ libgcc2.c (working copy)
@@ -2058,10 +2058,6 @@
#endif
}
-#ifdef __i386__
-extern int VirtualProtect (char *, int, int, int *) __attribute__((stdcall));
-#endif
-
int
mprotect (char *addr, int len, int prot)
{
> -Original Message-
> From: FX [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 16 April 2008 12:28 a.m.
> To: GCC Development; Danny Smith
> Subject: Bootstrap failure on native mingw32
>
>
> I'm not exactly sure how this one was introduced, but a bootstrap on
> native i686-pc-mingw32 dies in stage1 libgcc with:
>
> ../../../trunk/libgcc/../gcc/libgcc2.c:2052: warning: no previous
> prototype for 'getpagesize'
> ../../../trunk/libgcc/../gcc/libgcc2.c:2062: error: conflicting types
> for 'VirtualProtect'
> c:/MinGW/include/winbase.h:1995: error: previous declaration of
> 'VirtualProtect' was here
> ../../../trunk/libgcc/../gcc/libgcc2.c:2066: warning: no previous
> prototype for 'mprotect'
>
> The prototype for VirtualProtect in libgcc2.c is:
> extern int VirtualProtect (char *, int, int, int *)
> __attribute__((stdcall));
>
> In , it is:
> BOOL __attribute__((__stdcall__))
> VirtualProtect(PVOID,DWORD,DWORD,PDWORD);
> with:
> typedef unsigned long DWORD;
> typedef int WINBOOL;
> typedef WINBOOL BOOL;
> typedef DWORD *PDWORD;
> typedef void *PVOID;
>
>
> Does that ring a bell to anyone? Any idea why it's showing up now even
> though it looks like this code wasn't modified in the recent past (and
> my winbase.h hasn't changed since my last successful bootstrap, a
> month ago).
>
> Thanks,
> FX
>
>
> PS: My exact configure line is: ../trunk/configure --prefix=/mingw
> --enable-languages=c,fortran --with-gmp=/home/FX/local
> --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
> --enable-bootstrap --enable-threads --disable-nls
> --build=i586-pc-mingw32 --enable-libgomp --disable-shared
>
> --
> FX Coudert
> http://www.homepages.ucl.ac.uk/~uccafco/
gfortran+libcpp: linking objects from c-compiler
Hi all. To integrate libcpp into gfortran, I copy/adapt quite some code from the c frontend. For include-path handling, I found that I can nicely re-use the functions defined in c-incpath.c and exported by c-incpath.h. Now, linking gfortran, the linker of course complains about undefined references, namely app_path() and register_include_chains(). Is it acceptable to simply link in the C-frontend object to gfortran (as C is a required language and the .o file will be available)? Do I need to do something else in addition or instead, like renaming or moving functions, pushing them to a library or anything else? Comments are highly welcome! Regards Daniel
Re: Official GCC git repository
Andreas Schwab <[EMAIL PROTECTED]> writes: > "Daniel Berlin" <[EMAIL PROTECTED]> writes: > >> No, nothing is wrong wit he import, if you want all the remote >> branches, you have to ask git to get all the remote branches >> >> git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' > > This will put the remote branch heads in refs/remotes, you might want to > put them in refs/remotes/origin instead. > > $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*' Actually this is not such a good idea, as it confuses git remote (it considers all refs imported from refs/remotes/* as stale branches). The original command is also the one recommended by git-svn(1). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: http://gcc.gnu.org/onlinedocs/libstdc++/ needs a bit of help
On Sun, 13 Apr 2008, Gerald Pfeifer wrote: > Yes, and no. I think there are two issues here. The one you are pointing > out, the other the fact that we changed existing URLs (some of them old or > "prominent" ones with external links towards them). > > I believe you have mostly addressed the first, and I'll try to help with > the second. Some changes I have committed already or plan to commit shortly, but there are some where I'd appreciate some help. As a consequence of the restructuring of the libstdc++ documentation, the following prominent links are broken. Do you have current replacements for these? http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html http://gcc.gnu.org/onlinedocs/libstdc++/ext/parallel_mode.html http://gcc.gnu.org/onlinedocs/libstdc++/ext/tr1.html Thanks,
Re: -pthread switch and binary compatibitity
"John Maddock" <[EMAIL PROTECTED]> writes: > The crux of the issue is this: if gcc/g++ is configured with the pthread > threading model, then are object files always binary compatible irrespective > of whether they are compiled with the -pthread command line option or not? Yes, modulo the #define of _REENTRANT. > If the answer is yes, then is it commonplace to link object files compiled > with and without -pthread? Yes. In general, all the -pthread option does is turn on -D_REENTRANT during compilation and -lpthread during linking. There is some cross-platform variation--different -D and -l options--but in no case does -pthread lead to a different ABI. Ian
Bootstrap failure on i686-apple-darwin9
At revision 134333, boostrap fails on i686-apple-darwin9 at stage 1 with: ... gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/. -I../../gcc-4.4-work/gcc/../include -I./../intl -I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.4-work/gcc/../libdecnumber -I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc-4.4-work/gcc/explow.c -o explow.o ../../gcc-4.4-work/gcc/except.c: In function 'dw2_size_of_call_site_table': ../../gcc-4.4-work/gcc/except.c:3382: error: 'struct eh_status' has no member named 'call_site_data_used' ../../gcc-4.4-work/gcc/except.c:3388: error: 'struct eh_status' has no member named 'call_site_data' ../../gcc-4.4-work/gcc/except.c: In function 'sjlj_size_of_call_site_table': ../../gcc-4.4-work/gcc/except.c:3398: error: 'struct eh_status' has no member named 'call_site_data_used' ../../gcc-4.4-work/gcc/except.c:3404: error: 'struct eh_status' has no member named 'call_site_data' make[3]: *** [except.o] Error 1 make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gcc.pod make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 TIA Dominique
Re: Bootstrap failure on i686-apple-darwin9
> At revision 134333, boostrap fails on i686-apple-darwin9 at stage 1
> with:
>
> ...
> gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
> -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
> -I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/.
> -I../../gcc-4.4-work/gcc/../include -I./../intl
> -I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include
> -I../../gcc-4.4-work/gcc/../libdecnumber
> -I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber
> ../../gcc-4.4-work/gcc/explow.c -o explow.o
> ../../gcc-4.4-work/gcc/except.c: In function 'dw2_size_of_call_site_table':
> ../../gcc-4.4-work/gcc/except.c:3382: error: 'struct eh_status' has no member
> named 'call_site_data_used'
> ../../gcc-4.4-work/gcc/except.c:3388: error: 'struct eh_status' has no member
> named 'call_site_data'
Hi,
this is mine, sorry for that.
Does this help?
Index: except.c
===
*** except.c(revision 134328)
--- except.c(working copy)
*** set_nothrow_function_flags (void)
*** 2784,2790
}
}
! for (insn = current_function_epilogue_delay_list; insn;
insn = XEXP (insn, 1))
if (can_throw_external (insn))
{
--- 2784,2790
}
}
! for (insn = crtl->epilogue_delay_list; insn;
insn = XEXP (insn, 1))
if (can_throw_external (insn))
{
*** push_sleb128 (varray_type *data_area, in
*** 3379,3391
static int
dw2_size_of_call_site_table (void)
{
! int n = cfun->eh->call_site_data_used;
int size = n * (4 + 4 + 4);
int i;
for (i = 0; i < n; ++i)
{
! struct call_site_record *cs = &cfun->eh->call_site_data[i];
size += size_of_uleb128 (cs->action);
}
--- 3379,3391
static int
dw2_size_of_call_site_table (void)
{
! int n = VEC_length (call_site_record, crtl->eh.call_site_record);
int size = n * (4 + 4 + 4);
int i;
for (i = 0; i < n; ++i)
{
! struct call_site_record *cs = VEC_index (call_site_record,
crtl->eh.call_site_record, i);
size += size_of_uleb128 (cs->action);
}
*** dw2_size_of_call_site_table (void)
*** 3395,3407
static int
sjlj_size_of_call_site_table (void)
{
! int n = cfun->eh->call_site_data_used;
int size = 0;
int i;
for (i = 0; i < n; ++i)
{
! struct call_site_record *cs = &cfun->eh->call_site_data[i];
size += size_of_uleb128 (INTVAL (cs->landing_pad));
size += size_of_uleb128 (cs->action);
}
--- 3395,3407
static int
sjlj_size_of_call_site_table (void)
{
! int n = VEC_length (call_site_record, crtl->eh.call_site_record);
int size = 0;
int i;
for (i = 0; i < n; ++i)
{
! struct call_site_record *cs = VEC_index (call_site_record,
crtl->eh.call_site_record, i);
size += size_of_uleb128 (INTVAL (cs->landing_pad));
size += size_of_uleb128 (cs->action);
}
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Tue, 15 Apr 2008 09:15:45 -0400, "Daniel Jacobowitz" <[EMAIL PROTECTED]>
said:
>
> I'm going to keep asking until I get something we can work
> with... you're reporting a bug in the compiler, so we need a test case
> and the exact error message. What is generating any kind of sqrt
> libcall? There is nothing in GCC to call __aeabi_sqrt, which AFAIK
> does not exist.
gcc shouldn't call __aeabi_sqrt, since it doesn't exist. It could
however try to do a libcall through the optab to sqrtsf2, since
sqrt_optab does exist in optabs.h/c and genopinit.c ...
Ok, to try and test this out, I added this patch to gcc, and recompiled
gcc & glibc --with-fp for crunch:
--- gcc-4.2.2/gcc/config/arm/arm.md 2008-04-15 17:59:35.0
+1000
+++ gcc-4.2.2/gcc/config/arm/arm.md 2008-04-15 18:02:08.0
+1000
@@ -3100,6 +3100,22 @@
"TARGET_ARM && TARGET_HARD_FLOAT && (TARGET_FPA || TARGET_VFP)"
"")
+(define_expand "sqrtsf2_soft_insn"
+ [(set (match_operand:SF 0 "s_register_operand" "")
+ (sqrt:SF (match_operand:SF 1 "s_register_operand" "")))]
+ "TARGET_ARM && !(TARGET_HARD_FLOAT && (TARGET_FPA || TARGET_VFP))"
+ "{
+ FAIL;
+ }")
+
+(define_expand "sqrtdf2_soft_insn"
+ [(set (match_operand:DF 0 "s_register_operand" "")
+ (sqrt:DF (match_operand:DF 1 "s_register_operand" "")))]
+ "TARGET_ARM && !(TARGET_HARD_FLOAT && (TARGET_FPA || TARGET_VFP))"
+ "{
+ FAIL;
+ }")
+
(define_insn_and_split "one_cmpldi2"
[(set (match_operand:DI 0 "s_register_operand" "=&r,&r")
(not:DI (match_operand:DI 1 "s_register_operand" "?r,0")))]
I was expecting it to fail since now gcc shouldn't be able to expand
that operation. I double check glibc config.status, and with_fp=yes.
So, I'm not sure how glibc is doing it's sqrt routines on arm. In that
case I suspect that glibc doesn't call sqrt for VFP or FPA, then, and
you were right in your first e-mail.
glibc uses its own internal sqrt function, rather than the
sqrtsf2/sqrtdf2 opcode, even on FPA or VFP.
In any case if you want a test, then something like
gcc/testsuite/gcc.dg/arm-vfp1.c is enough (of course with different
dejagnu lines, e.g. dg-final scan-assembler lines) ...
I still think something like the above patch needs to be added to gcc,
just to ensure that the sqrtsf2 / sqrtdf2 libcall never happens, and an
error happens at compile time rather than runtime. In the future glibc,
uclibc or some standalone function could make use of the "gcc" sqrt,
rather than the glibc sqrt.
Anyway, I misunderstood how the toolchain gets assembled and I would
appreciate it someone could point out where the sqrt function is in
glibc, on arm.
Does arm use glibc/sysdeps/ieee754/dbl-64/mpsqrt.c ???
Re: Bootstrap failure on i686-apple-darwin9
> Does this help? Thanks for tha answer, but now I have: ... ../../gcc-4.4-work/gcc/except.c: In function 'set_nothrow_function_flags': ../../gcc-4.4-work/gcc/except.c:2787: error: 'struct rtl_data' has no member named 'epilogue_delay_list' make[3]: *** [except.o] Error 1 ... Dominique
Structured Exception Handling in gcc
Hi, I am looking for information on how GCC implements Structured Exception Handling (try/catch) in C++ programs. I would really appreciate any pointers that helped me understand the internals. Thank you, Rodrigo
Re: Structured Exception Handling in gcc
"Rodrigo Dominguez" <[EMAIL PROTECTED]> writes: > I am looking for information on how GCC implements Structured Exception > Handling (try/catch) in C++ programs. I would really appreciate any pointers > that helped me understand the internals. gcc does not implement Structured Exception Handling in the Microsoft C++ sense. gcc does implement plain old C++ exception handling including try/catch. The ABI is documented here: http://www.codesourcery.com/cxx-abi/abi-eh.html Ignore the fact that this is labelled "Itanium," it's used for all targets. Ian
Re: gfortran+libcpp: linking objects from c-compiler
> "Daniel" == Daniel Franke <[EMAIL PROTECTED]> writes: Daniel> Is it acceptable to simply link in the C-frontend object to Daniel> gfortran (as C is a required language and the .o file will be Daniel> available)? Do I need to do something else in addition or Daniel> instead, like renaming or moving functions, pushing them to a Daniel> library or anything else? I think the usual rule is that c-* files are either specific to the C front end, or in some cases, shared by the C family of front ends. Perhaps this particular file could just be renamed and added to libbackend.a. This isn't completely ideal, because c-incpath.c refers to cpp_reader and some front ends don't actually need libcpp ... but if I read the Makefile correctly it looks like all the front ends already link to libcpp, so maybe it isn't a big deal. Tom
Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions
On Wed, Apr 16, 2008 at 09:18:07AM +1000, Hasjim Williams wrote: > glibc uses its own internal sqrt function, rather than the > sqrtsf2/sqrtdf2 opcode, even on FPA or VFP. Always. That's how it is supposed to work; the expander allows GCC to optimize sqrt operations inline, for architectures where it is profitable to do so. But the backing function remains "sqrt" (sqrtf, sqrtl). The implementation of that lives in the C library and is not dependent on GCC for the body. > Anyway, I misunderstood how the toolchain gets assembled and I would > appreciate it someone could point out where the sqrt function is in > glibc, on arm. > Does arm use glibc/sysdeps/ieee754/dbl-64/mpsqrt.c ??? I don't know for sure, but it seems likely. Build glibc with debug info and step through it? -- Daniel Jacobowitz CodeSourcery
Re: Bootstrap failure on i686-apple-darwin9
> > Does this help?
>
> Thanks for tha answer, but now I have:
>
> ...
> ../../gcc-4.4-work/gcc/except.c: In function 'set_nothrow_function_flags':
> ../../gcc-4.4-work/gcc/except.c:2787: error: 'struct rtl_data' has no member
> named 'epilogue_delay_list'
> make[3]: *** [except.o] Error 1
> ...
Sorry, that hunk was left over of my other local changes I was testing.
Index: except.c
===
*** except.c(revision 134328)
--- except.c(working copy)
*** push_sleb128 (varray_type *data_area, in
*** 3379,3391
static int
dw2_size_of_call_site_table (void)
{
! int n = cfun->eh->call_site_data_used;
int size = n * (4 + 4 + 4);
int i;
for (i = 0; i < n; ++i)
{
! struct call_site_record *cs = &cfun->eh->call_site_data[i];
size += size_of_uleb128 (cs->action);
}
--- 3379,3391
static int
dw2_size_of_call_site_table (void)
{
! int n = VEC_length (call_site_record, crtl->eh.call_site_record);
int size = n * (4 + 4 + 4);
int i;
for (i = 0; i < n; ++i)
{
! struct call_site_record *cs = VEC_index (call_site_record,
crtl->eh.call_site_record, i);
size += size_of_uleb128 (cs->action);
}
*** dw2_size_of_call_site_table (void)
*** 3395,3407
static int
sjlj_size_of_call_site_table (void)
{
! int n = cfun->eh->call_site_data_used;
int size = 0;
int i;
for (i = 0; i < n; ++i)
{
! struct call_site_record *cs = &cfun->eh->call_site_data[i];
size += size_of_uleb128 (INTVAL (cs->landing_pad));
size += size_of_uleb128 (cs->action);
}
--- 3395,3407
static int
sjlj_size_of_call_site_table (void)
{
! int n = VEC_length (call_site_record, crtl->eh.call_site_record);
int size = 0;
int i;
for (i = 0; i < n; ++i)
{
! struct call_site_record *cs = VEC_index (call_site_record,
crtl->eh.call_site_record, i);
size += size_of_uleb128 (INTVAL (cs->landing_pad));
size += size_of_uleb128 (cs->action);
}
