Re: Wrong-code bug in execute_update_addresses_taken?
On Sat, Feb 5, 2011 at 4:55 PM, Ulrich Weigand wrote:
> Hello,
>
> the following program seems to be miscompiled at -O or higher:
>
> int
> main (void)
> {
> int data = 1;
>
> struct ptr
> {
> int val;
> } *ptr = (struct ptr *) &data;
>
> ptr->val = 0;
>
> return data;
> }
>
> This program should return 0, but actually returns 1.
>
> [ As far as I can tell, this program does not violate the aliasing
> rules; all memory accesses refer to an object of effective (because
> declared) type "int", and use lvalue references of type "int".
> The pointer cast might depend on implementation-defined behaviour,
> but is not undefined. In any case, there are no warnings, and use
> of -fno-strict-aliasing does not fix the problem. ]
>
> In 024t.forwprop1, we still have (correctly):
>
> # .MEMD.3455_4 = VDEF <.MEMD.3455_3(D)>
> dataD.1975 = 1;
>
> # .MEMD.3455_5 = VDEF <.MEMD.3455_4>
> MEM[(struct ptr *)&dataD.1975].valD.1977 = 0;
>
> # VUSE <.MEMD.3455_5>
> D.3453_2 = dataD.1975;
> return D.3453_2;
>
> but then in 025t.ealias, we get:
>
> dataD.1975_4 = 1;
>
> # .MEMD.3455_5 = VDEF <.MEMD.3455_3(D)>
> MEM[(struct ptr *)&dataD.1975].valD.1977 = 0;
>
> D.3453_2 = dataD.1975_4;
> return D.3453_2;
>
> This is apparently caused by the "addresses taken" pass,
> which results in those messages:
>
> No longer having address taken: data
>
> Registering new PHI nodes in block #0
> Registering new PHI nodes in block #2
>
> Updating SSA information for statement data = 1;
> Updating SSA information for statement D.3453_2 = data;
>
> It seems that for some reason, the pass claims to be able to
> eliminate all statements that take the address of "data",
> but then leaves the MEM reference unchanged ...
>
> Any suggestions on what might cause this problem?
A bug? Can you file a bugreport and CC me? I'll look into the
problem.
Thanks,
Richard.
> Thanks,
> Ulrich
>
> --
> Dr. Ulrich Weigand
> GNU Toolchain for Linux on System z and Cell BE
> ulrich.weig...@de.ibm.com
>
Re: Wrong-code bug in execute_update_addresses_taken?
Richard Guenther wrote: > A bug? Can you file a bugreport and CC me? I'll look into the > problem. Sure, this is now PR tree-optimization/47621. Thanks for looking into it! Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
enum built_in_function and divdc3
Richard,
The ___divdc3 symbol on Snow Leopard in libSystem is less accurate
than that in FSF libgcc (PR42333). We plan to use DECLARE_LIBRARY_RENAMES
to provide an alternative symbol ___ieee_divdc3 to access the FSF libgcc
___divdc3 symbol when libSystem.dylib is linked first and
!flag_unsafe_math_optimization.
We originally planned to use a darwin_patch_divdc3() modelled directly on
darwin_patch_builtin() in gcc/config/darwin.c, however the absence of a listing
of divdc3 in gcc/builtins.def makes the syntax...
tree fn = built_in_decls[BUILT_IN_DIVDC3];
impossible. I noticed you did the original commit for the current complex
division functions...
2005-02-11 Richard Henderson
* tree-complex.c (expand_complex_libcall): New.
(expand_complex_multiplication): Use it for c99 compliance.
(expand_complex_division): Likewise.
* fold-const.c (fold_complex_add, fold_complex_mult): New.
(fold): Call them.
* builtins.c (built_in_names): Remove const.
* tree.c (build_common_builtin_nodes): Build complex arithmetic
builtins.
* tree.h (BUILT_IN_COMPLEX_MUL_MIN, BUILT_IN_COMPLEX_MUL_MAX): New.
(BUILT_IN_COMPLEX_DIV_MIN, BUILT_IN_COMPLEX_DIV_MAX): New.
(built_in_names): Remove const.
* c-common.c (c_common_type_for_mode): Handle complex modes.
* flags.h, toplev.c (flag_complex_method): Rename from
flag_complex_divide_method.
* libgcc2.c (__divsc3, __divdc3, __divxc3, __divtc3,
__mulsc3, __muldc3, __mulxc3, __multc3): New.
* libgcc2.h: Declare them.
* libgcc-std.ver: Export them.
* mklibgcc.in (lib2funcs): Build them.
I also noticed...
#define DEF_BUILTIN(ENUM, N, C, T, LT, B, F, NA, AT, IM, COND) ENUM,
enum built_in_function
{
#include "builtins.def"
/* Complex division routines in libgcc. These are done via builtins
because emit_library_call_value can't handle complex values. */
BUILT_IN_COMPLEX_MUL_MIN,
BUILT_IN_COMPLEX_MUL_MAX
= BUILT_IN_COMPLEX_MUL_MIN
+ MAX_MODE_COMPLEX_FLOAT
- MIN_MODE_COMPLEX_FLOAT,
BUILT_IN_COMPLEX_DIV_MIN,
BUILT_IN_COMPLEX_DIV_MAX
= BUILT_IN_COMPLEX_DIV_MIN
+ MAX_MODE_COMPLEX_FLOAT
- MIN_MODE_COMPLEX_FLOAT,
/* Upper bound on non-language-specific builtins. */
END_BUILTINS
};
#undef DEF_BUILTIN
what is the correct value is use for the enum entry of the ___divdc3
symbol? Is it END_BUILTINS-1 or END_BUILTINS-2? Thanks in advance for
any clarifications.
Jack
Re: enum built_in_function and divdc3
On 02/06/2011 08:12 AM, Jack Howarth wrote: > what is the correct value is use for the enum entry of the ___divdc3 > symbol? Is it END_BUILTINS-1 or END_BUILTINS-2? Thanks in advance for > any clarifications. See build_common_builtin_modes: dcode = ((enum built_in_function) (BUILT_IN_COMPLEX_DIV_MIN + mode - MIN_MODE_COMPLEX_FLOAT)); r~
Re: enum built_in_function and divdc3
On Sun, Feb 06, 2011 at 09:40:41AM -0800, Richard Henderson wrote: > On 02/06/2011 08:12 AM, Jack Howarth wrote: > > what is the correct value is use for the enum entry of the ___divdc3 > > symbol? Is it END_BUILTINS-1 or END_BUILTINS-2? Thanks in advance for > > any clarifications. > > See build_common_builtin_modes: > > dcode = ((enum built_in_function) > (BUILT_IN_COMPLEX_DIV_MIN + mode - MIN_MODE_COMPLEX_FLOAT)); So for divc3 in libgcc2.c... #elif defined(L_muldc3) || defined(L_divdc3) # define MTYPE DFtype # define CTYPE DCtype # define MODE dc I assume that BUILT_IN_COMPLEX_DIV_MIN and MIN_MODE_COMPLEX_FLOAT will be available to me in darwin.c but where is dc defined? I am looking to be able to execute... tree fn = built_in_decls[BUILT_IN_COMPLEX_DIV_MIN + sc - MIN_MODE_COMPLEX_FLOAT]; or is MODE not the same as mode? Jack > > > r~
Re: enum built_in_function and divdc3
On Sun, 6 Feb 2011, Jack Howarth wrote: > Richard, >The ___divdc3 symbol on Snow Leopard in libSystem is less accurate > than that in FSF libgcc (PR42333). We plan to use DECLARE_LIBRARY_RENAMES > to provide an alternative symbol ___ieee_divdc3 to access the FSF libgcc > ___divdc3 symbol when libSystem.dylib is linked first and > !flag_unsafe_math_optimization. Do you have a clear characterization of "less accurate" that indicates that flag_unsafe_math_optimizations is the appropriate flag? (The whole point of this function is to avoid problems with a naive implementation such as is used under -fcx-limited-range, so if the libSystem function simply implements the -fcx-limited-range method then it would never make sense to use it at all.) -- Joseph S. Myers jos...@codesourcery.com
gcc-4.3-20110206 is now available
Snapshot gcc-4.3-20110206 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110206/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 169867 You'll find: gcc-4.3-20110206.tar.bz2 Complete GCC (includes all of below) MD5=0db889e7a0d8ed3b97849ac2b165616f SHA1=f03a283a53e0acd49a3e3a36317c6a3419d69449 gcc-core-4.3-20110206.tar.bz2C front end and core compiler MD5=eb079c16e7193884f5b37199a28fd947 SHA1=bb632552eb1f22c805f0489e90a1e1883c449bcc gcc-ada-4.3-20110206.tar.bz2 Ada front end and runtime MD5=c24afe70f86600b8bafc44fa40a38326 SHA1=d8b730f503be9d553fece3dc02c9ce7197148047 gcc-fortran-4.3-20110206.tar.bz2 Fortran front end and runtime MD5=d98bc05d51303ad60228ed45e15fdd35 SHA1=54ce055e6887fa18bfc7cbede34f9a237098a068 gcc-g++-4.3-20110206.tar.bz2 C++ front end and runtime MD5=f51445b5b47ddc3f818140b4ac5ce4e2 SHA1=7b4536794fd05eaaddc2c577861ed895416b gcc-go-4.3-20110206.tar.bz2 Go front end and runtime MD5=6f053d29e9600c7b8d4c57bb6f61b4c1 SHA1=8a672cadedbf56f455ababf003171632cd5ee40c gcc-java-4.3-20110206.tar.bz2Java front end and runtime MD5=88b244a8f1c95244bf3608ea38d5ab35 SHA1=ef2d7a1b6917fd5c573085fdf93ec7bb02257394 gcc-objc-4.3-20110206.tar.bz2Objective-C front end and runtime MD5=183c7b86c1bdae6d701d8552c8e7ea50 SHA1=c5134fb8b7ee25e863ee830db74354dbbe85df93 gcc-testsuite-4.3-20110206.tar.bz2 The GCC testsuite MD5=795e0a6125cf1406406eaf8b5e6b6de3 SHA1=b004f47b4288ee56a223973ecd6555f4610d6f77 Diffs from 4.3-20110130 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: enum built_in_function and divdc3
On 02/06/2011 09:56 AM, Jack Howarth wrote: > tree fn = built_in_decls[BUILT_IN_COMPLEX_DIV_MIN + sc - > MIN_MODE_COMPLEX_FLOAT]; Use DCmode or SCmode here. r~
Re: [doc,patch] Move from GFDL 1.2 to GFDL 1.3
On Mon, 14 Jun 2010, Jonathan Wakely wrote: And wouldn't it be appropriate to remove doc/xml/gnu/fdl-1.2.xml now that you have added fdl-1.3.xml? >>> Possibly. We still have gpl-2.0.xml there, which doesn't seem to be >>> included. I followed that example. >> >> If you are not using GPL 2.0 nor FDL 1.2 anymore in libstdc++ (and we >> should not be using these two anymore in all of GCC), we should remove >> them. Would you mind doing that or should I give it a try? > I can do that, assuming no objections from the other maintainers. Hmm, I see that these two are still in there. We should not be using them anymore. Would you mind removing them, or do you see a problem? (It would be good to make the same change for GCC 4.5 as well.) Thanks, Gerald
Re: [doc,patch] Move from GFDL 1.2 to GFDL 1.3
On 6 February 2011 23:57, Gerald Pfeifer wrote: > On Mon, 14 Jun 2010, Jonathan Wakely wrote: > And wouldn't it be appropriate to remove doc/xml/gnu/fdl-1.2.xml now > that you have added fdl-1.3.xml? Possibly. We still have gpl-2.0.xml there, which doesn't seem to be included. I followed that example. >>> >>> If you are not using GPL 2.0 nor FDL 1.2 anymore in libstdc++ (and we >>> should not be using these two anymore in all of GCC), we should remove >>> them. Would you mind doing that or should I give it a try? >> I can do that, assuming no objections from the other maintainers. > > Hmm, I see that these two are still in there. We should not be > using them anymore. Would you mind removing them, or do you see > a problem? > > (It would be good to make the same change for GCC 4.5 as well.) Ah sorry, I think I forgot about it, I'll do it tomorrow.
targetm.init_builtins and build_common_builtin_nodes ordering
So, in c-common.c we have: targetm.init_builtins (); build_common_builtin_nodes (); and in f95-1.c we have: build_common_builtin_nodes (); targetm.init_builtins (); I would like to change c-common.c to match fortran, so that the target hook can slightly alter (rename) the linkage name of some of the common builtin nodes. If that answer is no, what's the best way to get __divdc3 renamed? Thoughts?
Joseph Myers appointed option handling maintainer
In what may be the most surprising announcement this year (not), I am happy to announce that the steering committee is appointing Joseph option handling maintainer. Thanks for all the time and energy you have put into this already, Joseph! Please adjust the MAINTAINERS file accordingly, and Happy Hacking! Gerald
How to default to -fno-math-errno on all FreeBSD targets
David Schultz noticed that the FreeBSD libm does not set errno, never
has done, and never will, and thus has made -fno-math-errno the default
in the (old, GCC 4.2-based) system compiler:
http://svn.freebsd.org/viewvc/base?view=revision&revision=181538
We should also make this change for GCC 4.6 and possibly retroactively
GCC 4.5 since we are giving away performance for nothing.
Our documentation already notes that this is the case on Darwin
On Darwin systems, the math library never sets @code{errno}. There is
therefore no reason for the compiler to consider the possibility that
it might, and @option{-fno-math-errno} is the default.
which hacks config/i386/i386.c as follows:
ix86_option_init_struct (struct gcc_options *opts)
{
if (TARGET_MACHO)
/* The Darwin libraries never set errno, so we might as well
avoid calling them when that's the only reason we would. */
opts->x_flag_errno_math = 0;
I guess I could just add a check for FSB_MAJOR there, but that would
only address i386. Is there a better way to accomplish this?
Gerald
