Complex log builtins

Complex log builtins

[Paul Brook]

I just tried to make gfortran use the _Complex log builtins (clog, etc.), and 
discovered they don't exist.

The original post adding the other C99 math functions
(http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00180.html)
Mentions conflicts with C++ iostreams clog.

However since these are C99 builtins they don't get enabled for C++ (right?). 
I enabled the builtins and tried various combinations of clog, 
std::clog, ::clog and using namespace std; and couldn't trigger any bad 
behaviour. The C99 clog was uniformly ignored.

Can these builtins (clog, clogf and clogl) be enabled?

Paul

P.S. If we do enable clog, we probably want to add clog10 as well.

Re: Complex log builtins

[Gabriel Dos Reis]

Paul Brook <paul@codesourcery.com> writes:

| I just tried to make gfortran use the _Complex log builtins (clog, etc.), and 
| discovered they don't exist.
| 
| The original post adding the other C99 math functions
| (http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00180.html)
| Mentions conflicts with C++ iostreams clog.
| 
| However since these are C99 builtins they don't get enabled for C++ (right?). 
Only under some circumstances, they are not enabled for C++.  As a matter
of fact, some people wants them unconditionally, others don't.  The
comprise was to have a switch that turns them on/off.  But you can't assume
they're never enabled.

| I enabled the builtins and tried various combinations of clog, 
| std::clog, ::clog and using namespace std; and couldn't trigger any bad 
| behaviour. The C99 clog was uniformly ignored.

Could you post your testing programs?

| Can these builtins (clog, clogf and clogl) be enabled?

As discussed with Joseph S. Myers in another thread, what we should do
is to put GCC built-ins in a GCC name space, say "__gcc_".  The reason
is that those are used by the middle-end which is language indendent
and should not dump C name space rules onto other languages.  But, as
I understand it, we should coordinate these with Glibc people -- and I
remember Benjamin offering to look into this if I send him examples.

-- Gaby

Re: Complex log builtins

[Kaveh R. Ghazi]

 > I just tried to make gfortran use the _Complex log builtins (clog,
 > etc.), and discovered they don't exist.
 > 
 > The original post adding the other C99 math functions
 > (http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00180.html)
 > Mentions conflicts with C++ iostreams clog.
 > 
 > [...]
 > I enabled the builtins and tried various combinations of clog,
 > std::clog, ::clog and using namespace std; and couldn't trigger any
 > bad behaviour. The C99 clog was uniformly ignored.

I don't recall the exact failure I got, but it would have probably
been something exposed during a testsuite run.  Not sure if it was the
G++ or the libstdc++ testsuite.

If running those with the clog* builtins enabled doesn't break
something, it may just be that the compiler is different enough that
it's not longer a problem.  E.g. the new parser or builtins work may
have safely compartmentalized things.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Complex log builtins

[Gabriel Dos Reis]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

[...]

| If running those with the clog* builtins enabled doesn't break
| something, it may just be that the compiler is different enough that
| it's not longer a problem.  E.g. the new parser or builtins work may
| have safely compartmentalized things.

Assuming C99's clog is enabled, I don't know how the compiler managed
to safely compartmentalize this: 

   #include <math.h>    // bring in C99's stuff
   #include <iostream>  // bring in C++ streams

   int main()
   {
      using namespace std;
      clog << "Hellow, World\n";
   } 

I can think of some library hacks attempting to make that work -in the
small-, but they're brittle hacks. 

-- Gaby

Re: Complex log builtins

[Paul Brook]

On Monday 30 August 2004 04:00, Gabriel Dos Reis wrote:
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
>
> [...]
>
> | If running those with the clog* builtins enabled doesn't break
> | something, it may just be that the compiler is different enough that
> | it's not longer a problem.  E.g. the new parser or builtins work may
> | have safely compartmentalized things.
>
> Assuming C99's clog is enabled, I don't know how the compiler managed
> to safely compartmentalize this:
>
>    #include <math.h>    // bring in C99's stuff
>    #include <iostream>  // bring in C++ streams
>
>    int main()
>    {
>       using namespace std;
>       clog << "Hellow, World\n";
>    }

The above testcase works with the builtins enabled. Adding a call to 
__builtin_clog to the body of main() also works.

Note that the C99 clog is declared in <complex.h>, not <math.h>.
Adding #include <compex.h> to the above test still works correctly because g++ 
overrides complex.h with a header that just does #include <complex>

Adding #include "/usr/include/complex.h" forces an explicit definition of 
clog, and does break the program.

In summary enabling the builtins doesn't seem to break anything, though I'm 
not sure why.

Does this help any?

Paul

Re: Complex log builtins

[Kaveh R. Ghazi]

 > The above testcase works with the builtins enabled. Adding a call to
 > __builtin_clog to the body of main() also works.
 > 
 > Note that the C99 clog is declared in <complex.h>, not <math.h>.
 > Adding #include <compex.h> to the above test still works correctly
 > because g++ overrides complex.h with a header that just does #include
 > <complex>
 > 
 > Adding #include "/usr/include/complex.h" forces an explicit definition
 > of clog, and does break the program.
 > 
 > In summary enabling the builtins doesn't seem to break anything,
 > though I'm not sure why.
 > 
 > Does this help any?
 > Paul

I really don't remember how it broke for me, have you tried running
the G++/libstdc++ testsuites with the builtins enabled?

Actually I'm not sure you need to worry about this.  Ultimately if
clog turns out still to be a conflict, you can activate just the
__builtin_clog style and leave clog out by using DEF_GCC_BUILTIN.  I
suspect that's all you need to get the middle-end machinery hooked up
with fortran.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu