Re: Add clog10 to builtins.def, round 2
>> * builtins.def: Add DEF_EXT_C99RES_BUILTIN to define builtins >> that C99 reserve for future use. Use it to define clog10, clog10f >> and clog10l. > > Ok. Commited. Thanks, FX
Re: Someone broke bootstrap with gfortran, again!
On Sat, 23 Jul 2005, 15:53:21 +0200, Daniel Berlin wrote: > On Fri, 2005-07-22 at 17:53 -0700, Steve Kargl wrote: > > On Fri, Jul 22, 2005 at 05:44:44PM -0700, Jerry DeLisle wrote: > > > Steve Kargl wrote: > > > >Does this look familiar to anyone? > > > > > > > I was having troubles doing a build after a cvs update. I had to delete > > > everything in the build directory and rerun configure and then it would > > > build ok. Not sure its the same problem you are seeing, but it happened > > > today. I am running on i686-pc-linux-gnu. > > > > > > > I always remove the contents in the build directory, run configure, > > then do a "gmake bootstrap". The only exception to this process > > is when I'm making small changes to gfortran files where I know > > a "gmake bubblestrap" will not run into problems. > > > > I suspect the commit that broken gfortran is > > > > 2005-07-22 Manfred Hollstein <[EMAIL PROTECTED]> > > > > * tree-ssa-structalias.c (merge_graph_nodes): Fix uninitialised > > warnings. > > (int_add_graph_edge): Likewise. > > (collapse_nodes): Likewise. > > (process_unification_queue): Likewise. > > > > I'll know with certainty in an hour or so. > > I should simply note that the te warnings are invalid. > We don't *use* the weights uninitialized (this is easily verifiable). Correct, but unfortunately -Werror errors out at -O3 due to these warnings... That's why I suggested the fix. Cheers. l8er manfred
Bugzilla querys via email interface
Hi Dan, Commands for querying open bugs for a specific target (say 3.4.5) of a product do not seem to exist. The documentation for "index" says index But what I'm looking for is something like index probably augmented with "known-to-fail" or "known-to-work". But the pressing need for me is the ability to specify the target. Thanks, -- Gaby
Re: Bugzilla querys via email interface
On Sun, 2005-07-24 at 19:44 +0200, Gabriel Dos Reis wrote: > Hi Dan, > > Commands for querying open bugs for a specific target (say 3.4.5) of > a product do not seem to exist. The documentation for "index" says > > index > > But what I'm looking for is something like > > index > > probably augmented with "known-to-fail" or "known-to-work". But the > pressing need for me is the ability to specify the target. I just added this form. Give it a try. > > Thanks, > > -- Gaby
Re: Bugzilla querys via email interface
Daniel Berlin <[EMAIL PROTECTED]> writes: | > But what I'm looking for is something like | > | > index | > | > probably augmented with "known-to-fail" or "known-to-work". But the | > pressing need for me is the ability to specify the target. | | | I just added this form. | Give it a try. Tried but got no answer back. -- Gaby
Re: Surprising behavior of __attribute__((deprecated)) in ctor
On Saturday, July 23, 2005, at 05:42 PM, Mathieu Malaterre wrote: I have quite a surpising behavior with gcc when compiling the following code (*). Here is the output: Using: $ g++ --version g++ (GCC) 3.3 20030304 (Apple Computer, Inc. build 1671) g++-4.0 --version powerpc-apple-darwin8-g++-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer, Inc. build 4061) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. mrs $ g++-4.0 t7.cc mrs $ Maybe you want to run 4.0? Maybe you want a newer release? mrs $ g++-3.3 t7.cc t7.cc: In constructor `A::A(int)': t7.cc:11: warning: `A' is deprecated (declared at t7.cc:9) t7.cc: In constructor `A::A(int)': t7.cc:11: warning: `A' is deprecated (declared at t7.cc:9) Yup, right testcase...
Re: Bugzilla querys via email interface
Fixed now Sorry about that. On Sun, 2005-07-24 at 21:03 +0200, Gabriel Dos Reis wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > | > But what I'm looking for is something like > | > > | > index > | > > | > probably augmented with "known-to-fail" or "known-to-work". But the > | > pressing need for me is the ability to specify the target. > | > | > | I just added this form. > | Give it a try. > > Tried but got no answer back. > > -- Gaby
Re: Bugzilla querys via email interface
Daniel Berlin <[EMAIL PROTECTED]> writes: | Fixed now Indeed. works now. It would be great if bugzilla could send a notice back when it decides to ignore commands :-) | Sorry about that. No problem. Thanks for the quick fix! -- Gaby
Re: Bugzilla querys via email interface
On Sun, 2005-07-24 at 22:06 +0200, Gabriel Dos Reis wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > | Fixed now > > Indeed. works now. > It would be great if bugzilla could send a notice back when it decides > to ignore commands :-) Perl error handling is hard :( > > | Sorry about that. > > No problem. Thanks for the quick fix! > > -- Gaby
Re: Surprising behavior of __attribute__((deprecated)) in ctor
mrs $ g++-3.3 t7.cc t7.cc: In constructor `A::A(int)': t7.cc:11: warning: `A' is deprecated (declared at t7.cc:9) t7.cc: In constructor `A::A(int)': t7.cc:11: warning: `A' is deprecated (declared at t7.cc:9) Yup, right testcase... To support Panther I defined a MACRO: # if defined(__GNUC__) && !defined(__INTEL_COMPILER) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) #if defined(__APPLE__) && (__GNUC__ == 3) && (__GNUC_MINOR__ == 3) // Seems like there is a bug in APPLE gcc for deprecated attribute and ctor // This is fixed in g++ 4.0 (Tiger) # define GDCM_LEGACY(method) method #else # define GDCM_LEGACY(method) method __attribute__((deprecated)) #endif # elif defined(_MSC_VER) && _MSC_VER >= 1300 # define GDCM_LEGACY(method) __declspec(deprecated) method # else # define GDCM_LEGACY(method) method # endif #endif Basically I am testing if GNU and not APPLE with 'feature' :) Mathieu
Re: Bugzilla querys via email interface
Daniel Berlin <[EMAIL PROTECTED]> writes: | On Sun, 2005-07-24 at 22:06 +0200, Gabriel Dos Reis wrote: | > Daniel Berlin <[EMAIL PROTECTED]> writes: | > | > | Fixed now | > | > Indeed. works now. | > It would be great if bugzilla could send a notice back when it decides | > to ignore commands :-) | | Perl error handling is hard :( OK. I have one more request. Is it possible for "index" to also output the number of matches found, as first line? (just like with the web interface). One thing I would also find quite valuable is that the description contains the component name, e.g. c++/21784: [3.4 Regression] Using vs builtin names instead of the current Bug 21784: [3.4 Regression] Using vs builtin names because otherwise I would have to send another query to ask for the component name :-) Thanks, -- Gaby
Stack protector documentation still missing
Hi, You added the stack protector patch on May 12, but Joseph already pointed out then that you did not add user documentation (see his mail: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01235.html). Can you add this documentation please? Gr. Steven
Re: Bugzilla querys via email interface
> OK. > > I have one more request. > > Is it possible for "index" to also output the number of matches found, > as first line? (just like with the web interface). > > One thing I would also find quite valuable is that the description > contains the component name, e.g. > > c++/21784: [3.4 Regression] Using vs builtin names > > instead of the current > > Bug 21784: [3.4 Regression] Using vs builtin names > > because otherwise I would have to send another query to ask for the > component name :-) > > Thanks, > Done on both counts.
Re: Bugzilla querys via email interface
Daniel Berlin <[EMAIL PROTECTED]> writes: | Done on both counts. Great! Thanks, -- Gaby
front-end that translate C++ to C
Hi all, Are there any open-source(or free) front-end which translates C++ to C? I could find some commercial things - Comeau, AT&T Cfront, etc., but these have many limitations(especially, It's too difficult to get cfront because there are few cfront-based compiler at present) Cheers, -- Yi-kwon Hwang
Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
Kean Johnston wrote on 22/07/2005 00:41:06:
[...]
>
> I hope someone can help me. I am C++ impaired, and I am getting
> the following error when trying to bootstrap the current 4.0.2
> CVS. The error is coming from include/ext/bitmap_allocator.h
> line 111. The relevant code snippet is:
>
> class _Mutex {
>__gthread_mutex_t _M_mut;
>
>// Prevent Copying and assignment.
>_Mutex(_Mutex const&);
>_Mutex& operator=(_Mutex const&);
>
> public:
>_Mutex()
>{
> if (__threads_enabled)
>{
> #if !defined __GTHREAD_MUTEX_INIT
> _GTHREAD_MUTEX_INIT_FUNCTION(&_M_mut);
> #else
> __gthread_mutex_t __mtemp = __GTHREAD_MUTEX_INIT;
> _M_mut = __mtemp; THIS CAUSES THE ERROR
> #endif
>}
>}
>
> I get the following error message from the compiler:
> error: no match for 'operator=' in
> '((__gnu_cxx::_Mutex)this)->__gnu_cxx::_Mutex::_M_Mut = __mtemp'
>
> */gcc/include/sys/types.h:678: note: candidates are: __pthread_mutex&
> __pthread_mutex::operator=(const __pthread_mutex&)
>
> The contents of sys/types.h at that location are:
> typedef volatile struct __pthread_mutex {
> mutex_t __pt_mutex_mutex;
> pid_t __pt_mutex_pid;
> thread_t __pt_mutex_owner;
> int __pt_mutex_depth;
> pthread_mutexattr_t __pt_mutex_attr;
> } pthread_mutex_t;
>
> If I remove the 'volatile' keyword, then everything just works.
> So, do I adjust fixincludes to remove the 'volatile' keyword,
> or is this some weird side effect of the recent discussions on
> volatile (which I didn't read).
>
The error makes perfect sense. __pthread_mutex has only one
assignment operator for it (implicitly generated by the compiler):
__pthread_mutex & operator=(const __pthread_mutex&).
When you try to pass a volatile __pthread_mutex (named as
pthread_mutex_t), the compiler can't pass it to the assignment
operator - because then `volatile' would be stripped off the
reference.
I have created a small test case to demonstrate this:
typedef volatile struct A{} Av;
void foo()
{
Av x;
x = Av();
}
This test gives an error with any compiler I could tested it with:
gcc-2.96, gcc-3.2.1, gcc-4.0.0, xlC-6.0.0
> Any help / advice appreciated.
>
> Oh PS ... if I change that from a simple assignment to:
>__builtin_memcpy((void *)&_M_mut, (const void *)&__mtemp,
> sizeof(__gthread_mutex_t));
I don't think it is a good idea in general to cast `volatile' away
from _M_mut in that way. I am not sure, but that may trigger
undefined behavior (the object is volatile, but it is being modified
through a non-volatile pointer). And this concern comes out from
the long thread on volatile.
Another option would be to define __gthread_mutex_t in terms of
struct __pthread_mutex
rather than using the volatile typedef.
> Then it also just works. I could of course adjust the header file
> to do that for the platform.
>
Do you know why the type itself is defined as volatile, as opposed to
declaring only relevant variables as volatile? What system is it anyway?
Michael
Re: extension to -fdump-tree-*-raw
> -Ursprüngliche Nachricht- > Von: Gabriel Dos Reis [SMTP:[EMAIL PROTECTED] > > "Giovanni Bajo" <[EMAIL PROTECTED]> writes: > | Ebke, Hans-Christian <[EMAIL PROTECTED]> wrote: > | > | > I have to write this in Outlook, so I don't even try to get the > quoting > | > right. Sorry. :-( > | > | http://jump.to/outlook-quotefix > Outlook-Quotefix doesn't work with Outlook 97 (which I'm using). Thanks anyway. > | > | > But it would break applications relying on the old format. > | > | There is no format either. dump-tree is *very* specific of GCC inners, > and > | it can dramatically changes between releases. > > Yes, and I don't want to make any promise of any kind. > > | OK, maybe not the syntax, > > the syntax may change too. It just did for 4.1. > So if the syntax changed for 4.1 anyway and since my changes apply to the 4.0.1 sources I figure there's no need for my patches, right? Hans-Christian
Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
The error makes perfect sense. __pthread_mutex has only one
assignment operator for it (implicitly generated by the compiler):
__pthread_mutex & operator=(const __pthread_mutex&).
When you try to pass a volatile __pthread_mutex (named as
pthread_mutex_t), the compiler can't pass it to the assignment
operator - because then `volatile' would be stripped off the
reference.
I have created a small test case to demonstrate this:
typedef volatile struct A{} Av;
void foo()
{
Av x;
x = Av();
}
This test gives an error with any compiler I could tested it with:
gcc-2.96, gcc-3.2.1, gcc-4.0.0, xlC-6.0.0
Interestingly enough, it gives an error with the native
compiler too (based on teh EDG front-end).
To fix this for GCC, I will fixincludes the volatile away.
Do you know why the type itself is defined as volatile, as opposed to
I don't, but I shall ask the person who wrote the header file.
declaring only relevant variables as volatile? What system is it anyway?
System V Release 5 (UnixWare / OpenServer 6).
Kean
Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
--- Kean Johnston <[EMAIL PROTECTED]> wrote: > System V Release 5 (UnixWare / OpenServer 6). > Your system is NOT supported by GCC, please read http://www.fsf.org/licensing/sco/ ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
