Re: Why is -fstrict-aliasing excluded from function "optimize" attribute?
On 11/03/2010 08:44 PM, Richard Guenther wrote:
> On Wed, Nov 3, 2010 at 6:12 PM, Andrew Haley wrote:
>> On 11/03/2010 04:49 PM, Bingfeng Mei wrote:
>>> Hello,
>>> I came across an issue with function "optimize" attribute. The code is like:
>>> __attribute__((optimize("-fno-strict-aliasing")))
>>> void foo()
>>> {
>>>...
>>> }
>>>
>>> When compiling with -O2, we expect this function is compiled without
>>> following
>>> strict aliasing rule, whereas other code does. However, I found this
>>> function still
>>> has strict aliasing flag turned on during compilation. After a little
>>> investigation,
>>> I found the following lines of code in parse_optimize_options of c-common.c
>>> (4.5, 4.6 is similar)
>>>
>>> ...
>>> saved_flag_strict_aliasing = flag_strict_aliasing;
>>>
>>> /* Now parse the options. */
>>> decode_options (opt_argc, opt_argv);
>>>
>>> targetm.override_options_after_change();
>>>
>>> /* Don't allow changing -fstrict-aliasing. */
>>> flag_strict_aliasing = saved_flag_strict_aliasing;
>>> ...
>>>
>>> -fstrict-aliasing is excluded from function specific optimize option. I
>>> checked
>>> both internal manual and gcc manual. It seems not to be documented. I wonder
>>> whether there is a good reason for this? If yes, at least we should
>>> document it.
>>> BTW, the code certainly works in 4.4.
>>
>> As far as I can tell the problem was that it didn't work.
>>
>> See http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00073.html
>
> A proper way to implement it nowadays would be to make sure that
> during gimplification we make the alias type in all MEM-REFs
> ref-all if no-strict-aliasing is in effect. This would of course also require
> to wrap all memory accesses in a MEM_REF tree.
In the meantime, should we not emit a warning?
Andrew.
RE: Why is -fstrict-aliasing excluded from function "optimize" attribute?
I think of adding a warning too. Should I submit a patch?
Bingfeng
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Andrew Haley
> Sent: 04 November 2010 08:31
> To: Richard Guenther
> Cc: gcc@gcc.gnu.org
> Subject: Re: Why is -fstrict-aliasing excluded from function "optimize"
> attribute?
>
> On 11/03/2010 08:44 PM, Richard Guenther wrote:
> > On Wed, Nov 3, 2010 at 6:12 PM, Andrew Haley wrote:
> >> On 11/03/2010 04:49 PM, Bingfeng Mei wrote:
> >>> Hello,
> >>> I came across an issue with function "optimize" attribute. The code
> is like:
> >>> __attribute__((optimize("-fno-strict-aliasing")))
> >>> void foo()
> >>> {
> >>>...
> >>> }
> >>>
> >>> When compiling with -O2, we expect this function is compiled
> without following
> >>> strict aliasing rule, whereas other code does. However, I found
> this function still
> >>> has strict aliasing flag turned on during compilation. After a
> little investigation,
> >>> I found the following lines of code in parse_optimize_options of c-
> common.c
> >>> (4.5, 4.6 is similar)
> >>>
> >>> ...
> >>> saved_flag_strict_aliasing = flag_strict_aliasing;
> >>>
> >>> /* Now parse the options. */
> >>> decode_options (opt_argc, opt_argv);
> >>>
> >>> targetm.override_options_after_change();
> >>>
> >>> /* Don't allow changing -fstrict-aliasing. */
> >>> flag_strict_aliasing = saved_flag_strict_aliasing;
> >>> ...
> >>>
> >>> -fstrict-aliasing is excluded from function specific optimize
> option. I checked
> >>> both internal manual and gcc manual. It seems not to be documented.
> I wonder
> >>> whether there is a good reason for this? If yes, at least we should
> document it.
> >>> BTW, the code certainly works in 4.4.
> >>
> >> As far as I can tell the problem was that it didn't work.
> >>
> >> See http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00073.html
> >
> > A proper way to implement it nowadays would be to make sure that
> > during gimplification we make the alias type in all MEM-REFs
> > ref-all if no-strict-aliasing is in effect. This would of course
> also require
> > to wrap all memory accesses in a MEM_REF tree.
>
> In the meantime, should we not emit a warning?
>
> Andrew.
GCC vector extensions
Hello all, Is it possible to use rtl vector patterns like vec_extractm, vec_setm from C code? It looks like C subscipting for vector variables was allowed at some point and then removed. So, can these rtl patterns only be used from languages other than C? Of course, i can use these in target builtins, but i am trying to see if these can be used by language constructs itself. Cheers Hari PS: I raised a related question in http://gcc.gnu.org/ml/gcc-help/2010-11/msg00021.html.
Re: pipeline description
roy rosen writes: > I am writing now the pipeline description in order to get a parallel code. > My machine has many restrictions regarding which instruction can be > parallelized with another. > I am under the assumption that for each insn only one > define_insn_reservation is matched. > Is that correct? Yes. > If so then the number of define_insn_reservation is > very high since I have to put here all possible attribute > permutations. That may be true for your machine. Most processors, in fact all that I have ever worked with myself, have a relatively small number of resources and instructions use them in predictable ways. There are generally not that many combinations. That is the case that gcc's scheduling code is written for. It sounds like your machine might be quite different: each instruction has different resource requirements and uses them in different ways. The scheduler has a lot of hooks which you can define in your cpu.c file. Their names all start with TARGET_SCHED. Those hooks make it easier to, for example, use the scheduler with a VLIW machine. You should read over the docs and see if you can use them to simplify your scenario. Ian
Re: GCC vector extensions
Hariharan Sandanagobalane writes: > Is it possible to use rtl vector patterns like vec_extractm, vec_setm > from C code? It looks like C subscipting for vector variables was > allowed at some point and then removed. So, can these rtl patterns > only be used from languages other than C? They were just recently added and have not been removed. Also answered on gcc-help. Ian
gcc (g++4.4.3) have no right to modify the name of my varialbe
dear alex:
thanks your email, but
(1) your suggestion is not work, it still get same error
(2) g++(4.4.3) have no right to modify the name of my variable, it is "string"
that I use(or Bjarne Stroustrup use)
not "String" that gcc/g++4.4.3 show on the compiler error
(3) if I put std::string replace string on Window.cpp file, g++ will complaint
r...@eric-laptop:/home/eric/BStrou/usingC++4/code/Chapter12# g++
-Wno-deprecated chapter.12.3.cpp Simple_window.cpp GUI.cpp Window.cpp Graph.cpp
-lfltk
Window.cpp:17: error: expected unqualified-id before ‘&’ token
Window.cpp:17: error: expected ‘)’ before ‘&’ token
Window.cpp:17: error: expected initializer before ‘&’ token
Window.cpp:25: error: expected unqualified-id before ‘&’ token
Window.cpp:25: error: expected ‘)’ before ‘&’ token
Window.cpp:25: error: expected initializer before ‘&’ token
---
Hy eric,
> but, there still are some compile error
> ---
> r...@eric-laptop:/home/eric/BStrou/usingC++4/code/Chapter12# g++
> -Wno-deprecated chapter.12.3.cpp Simple_window.cpp GUI.cpp Window.cpp
> -lfltk
> Window.cpp:17: error: prototype for âGraph_lib::Window2::Window2(int, int,
> const String&)â does not match any in class âGraph_lib::Window2â
> Window.h:26: error: candidates are: Graph_lib::Window2::Window2(const
> Graph_lib::Window2&)
> Window.h:31: error: Graph_lib::Window2::Window2(Point, int,
> int, const std::string&)
> Window.h:29: error: Graph_lib::Window2::Window2(int, int,
> const std::string&)
> Window.cpp:25: error: prototype for âGraph_lib::Window2::Window2(Point, int,
> int, const String&)â does not match any in class âGraph_lib::Window2â
> Window.h:26: error: candidates are: Graph_lib::Window2::Window2(const
> Graph_lib::Window2&)
> Window.h:31: error: Graph_lib::Window2::Window2(Point, int,
> int, const std::string&)
> Window.h:29: error: Graph_lib::Window2::Window2(int, int,
> const std::string&)
> --
> here is my window.h and window.cpp
This are probably NOT the same files as the ones you passed to the compiler:
According to the error-message, the type "string" in Window.cpp:17 starts
with a capital letter -- in your Window.cpp that's not the case.
The same is true for Windows.cpp:25.
If those are really the correct files, I would suspect that in one of
the Header-files included in Window.cpp and NOT included in Window.h
(that is: Graph.h or GUI.h or files included into these two) you
redefine the type "string" (to be equivalent to a type "String") -- so
"string" in Window.cpp refers to a different type as "string" in
Window.h...
If you remove the "using std::string;" in Window.h and replace all
occurences of "string" by "std::string", it should compile...
> /*/
> ---Window.h-
> #include
> #include
> #include
> #include
> #include "Point.h"
>
> using std::string;
> namespace Graph_lib
> {
> class Window2 : public Fl_Window {
> public:
> Window2(int w, int h, const string & title);
> };
> }
> /*/
> -here is my Window.cpp---
> #include
> #include "Window.h"
> #include "Graph.h"
> #include "GUI.h"
> namespace Graph_lib {
> Window2::Window2(int ww, int hh, const string &
> title):Fl_Window(ww,hh,title.c_str()),w(ww),h(hh)
> {
> init();
> }
Axel
_
Luxmail.com is spam free. However, we do not throw your important emails into
spam box like other defective email systems.
gcc-4.5-20101104 is now available
Snapshot gcc-4.5-20101104 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20101104/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 166338 You'll find: gcc-4.5-20101104.tar.bz2 Complete GCC (includes all of below) MD5=fa03220d4148d5de60cac2132e2db95c SHA1=f27cf7fed6178eb95f6bc0b822cf6c89ec178854 gcc-core-4.5-20101104.tar.bz2C front end and core compiler MD5=115675fe23a351a6d134730ed7e562e8 SHA1=b4a8e1b17eafb72b38580ae4d55ccc03680efde4 gcc-ada-4.5-20101104.tar.bz2 Ada front end and runtime MD5=f5e81927c819c483c22e1ca2f3c2409e SHA1=e35204c3bb141857ee9020e85dcc6c20946351e1 gcc-fortran-4.5-20101104.tar.bz2 Fortran front end and runtime MD5=8651cb641193220f523b4315aae5c6ab SHA1=3036d31bf8a06257ea71b5ee2dfcc4a86da2a3d0 gcc-g++-4.5-20101104.tar.bz2 C++ front end and runtime MD5=50075aba6b8bef3dc168995192c6ed61 SHA1=3a65531cada98b088e15e61a7a764becf53789b9 gcc-java-4.5-20101104.tar.bz2Java front end and runtime MD5=bc00e48fb0b91e33b5eb07092a9ca724 SHA1=a61ef49fb38233c9e89cb6501b6760a455fdbe9d gcc-objc-4.5-20101104.tar.bz2Objective-C front end and runtime MD5=821449908d30d38ccf2fba17b236f9e9 SHA1=a06154192672a060fe88c42af0e1eb44399867e7 gcc-testsuite-4.5-20101104.tar.bz2 The GCC testsuite MD5=59b7cf73b50d62a8cc7578072ab824a8 SHA1=540951e6d683cd0eec2256eda06e0e8cf026ece7 Diffs from 4.5-20101028 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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: build issue
Hi, > I've been working in this area lately and have been using GOLD rather than > GNU LD, so there could be a problem here. I'll see if I can reproduce it. Thanks Dave for your availability. For the record, I don't personally use gold. Paolo >
Re: build issue
On 04/11/2010 23:27, Paolo Carlini wrote: > Hi, > >> I've been working in this area lately and have been using GOLD rather >> than GNU LD, so there could be a problem here. I'll see if I can >> reproduce it. > > Thanks Dave for your availability. For the record, I don't personally use > gold. > > Paolo I configured r.166338 using: da...@gcc10:~/gcc/obj2$ '/n/10/davek/gcc/gcc/configure' '--prefix=/n/10/davek/gcc' '--with-mpfr=/opt/cfarm/mpfr-2.4.1' '--with-gmp=/opt/cfarm/gmp-4.2.4' '--with-mpc=/opt/cfarm/mpc-0.8' '--with-libelf=/n/10/davek/usr' '--enable-bootstrap' '--enable-static' '--enable-shared' '--enable-shared-libgcc' '--enable-lto' '--enable-plugin' --with-plugin-ld=ld '--enable-languages=c,c++,fortran,objc,obj-c++' ... and it just completed bootstrap fine, so I definitely need François' settings. I'll try a few other variants experimentally while waiting to hear back. cheers, DaveK
Re: gcc (g++4.4.3) have no right to modify the name of my varialbe
"eric lin" writes: > dear alex: > thanks your email, but > (1) your suggestion is not work, it still get same error > (2) g++(4.4.3) have no right to modify the name of my variable, it is > "string" that I use(or Bjarne Stroustrup use) > not "String" that gcc/g++4.4.3 show on the compiler error > (3) if I put std::string replace string on Window.cpp file, g++ will complaint Please never send e-mail to both the mailing lists gcc@gcc.gnu.org and gcc-h...@gcc.gnu.org. This e-mail is not appropriate for gcc@gcc.gnu.org, and should only have been sent to gcc-help. Thanks. g++ never changes the names of types. If you are seeing String where you wrote string, then some #define is in effect. If you want help with this, you need to provide a complete standalone test case. However, from what I have seen so far this is not a gcc issue, and you are asking in the wrong place. You are having basic C++ trouble, perhaps due to a confusion of header files. You should be asking in a C++ or Windows help group. Ian
