gcc-5-20160621 is now available
Snapshot gcc-5-20160621 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160621/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 237667 You'll find: gcc-5-20160621.tar.bz2 Complete GCC MD5=33cd38278e16fa094e2ff6fdaf91082c SHA1=07d8ad2c3fe7f51babae31d966c0cd3bba06ccbd Diffs from 5-20160614 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-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: Deprecating basic asm in a function - What now?
On Tue, Jun 21, 2016 at 06:29:45PM +, Bernd Edlinger wrote: > I do not like the idea to deprecate the basic asm at all, I must admit, > but I think if we added a warning, that just contains a positive information, > like > "warning: basic asm semantic has been changed to implicitly clobber memory, > if you have a problem with that, please convert this asm statement to extended > asm syntax." I don't see any point of such a warning. And, I agree that deprecation of basic asm is a bad idea. Jakub
Re: Deprecating basic asm in a function - What now?
On 21/06/2016 17:53, Andrew Haley wrote: > On 21/06/16 17:43, Jeff Law wrote: > > I think there's enough resistance to deprecating basic asms within a > > function that we should probably punt that idea. > > > > I do think we should look to stomp out our own uses of basic asms > > within functions just from a long term maintenance standpoint. > > > > Finally I think we should continue to bring the implementation of > > basic asms more in-line with expectations and future proofing them > > since I'm having a hard time seeing a reasonable path to deprecating > > their use. > > Me too. I wonder if there's anything else we can do to make basic asm > in a function a bit less of a time bomb. > > Andrew. I do not like the idea to deprecate the basic asm at all, I must admit, but I think if we added a warning, that just contains a positive information, like "warning: basic asm semantic has been changed to implicitly clobber memory, if you have a problem with that, please convert this asm statement to extended asm syntax." Then that would possibly be acceptable for everybody here. We could still discuss, if that warning should be enabled with -Wall, -Wextra or only on request. Bernd.
Re: Deprecating basic asm in a function - What now?
On 21/06/16 17:43, Jeff Law wrote: > I think there's enough resistance to deprecating basic asms within a > function that we should probably punt that idea. > > I do think we should look to stomp out our own uses of basic asms > within functions just from a long term maintenance standpoint. > > Finally I think we should continue to bring the implementation of > basic asms more in-line with expectations and future proofing them > since I'm having a hard time seeing a reasonable path to deprecating > their use. Me too. I wonder if there's anything else we can do to make basic asm in a function a bit less of a time bomb. Andrew.
Re: Deprecating basic asm in a function - What now?
On 06/21/2016 10:33 AM, Andrew Haley wrote: Hi, On 21/06/16 13:08, Michael Matz wrote: On Tue, 21 Jun 2016, Andrew Haley wrote: As said in the various threads about basic asms, all correctness problems can be solved by making GCC more conservative in handling them (or better said: not making it less conservative). Well, yes. That's exactly why we've agreed to change basic asms to make them clobber memory, i.e. to make GCC more conservative. Exactly. But this thread is about something else, see subject. Well, you brought up the idea of making GCC "less conservative". But making GCC less conservative is something that we have not agreed to do. So why did you even mention it if it wasn't relevant? I think there's enough resistance to deprecating basic asms within a function that we should probably punt that idea. I do think we should look to stomp out our own uses of basic asms within functions just from a long term maintenance standpoint. Finally I think we should continue to bring the implementation of basic asms more in-line with expectations and future proofing them since I'm having a hard time seeing a reasonable path to deprecating their use. Jeff
Re: Deprecating basic asm in a function - What now?
Hi, On 21/06/16 13:08, Michael Matz wrote: > On Tue, 21 Jun 2016, Andrew Haley wrote: > >>> As said in the various threads about basic asms, all correctness >>> problems can be solved by making GCC more conservative in handling >>> them (or better said: not making it less conservative). >> >> Well, yes. That's exactly why we've agreed to change basic asms to make >> them clobber memory, i.e. to make GCC more conservative. > > Exactly. But this thread is about something else, see subject. Well, you brought up the idea of making GCC "less conservative". But making GCC less conservative is something that we have not agreed to do. So why did you even mention it if it wasn't relevant? >> Well, maybe. It's also fairly likely that many work by accident. IMO >> this is more of a statement of hope than any kind of reasonable >> expectation. > > Like yours, of course. Hmm. The problem is that programmers have false ideas about basic asms. I was one of those programmers: I "knew" that basic asms implicitly clobbered memory, and I was startled to find out I was wrong. And I have been a GCC mainatiner for a long time. I guess it is possible that all of those uses of basic asm David mentioned are in fact correct. It's likely that adding a memory clobber will help. But some things I have seen (such as changing the floating-point status register) may not be be reliable without inputs and outputs and should be fixed. On the one hand we have the risk of churn, but basic asm in a function isn't such a great idea anyway. Andrew.
Re: Deprecating basic asm in a function - What now?
Hi, On Tue, 21 Jun 2016, Andrew Haley wrote: > > As said in the various threads about basic asms, all correctness > > problems can be solved by making GCC more conservative in handling > > them (or better said: not making it less conservative). > > Well, yes. That's exactly why we've agreed to change basic asms to make > them clobber memory, i.e. to make GCC more conservative. Exactly. But this thread is about something else, see subject. > Well, maybe. It's also fairly likely that many work by accident. IMO > this is more of a statement of hope than any kind of reasonable > expectation. Like yours, of course. > > Then the compiler better won't change into less conservative handling > > of basic asms. > > Repeat, repeat: the change being made is to make gcc MORE > conservative. This thread is about deprecating basic asms. That's not more conservative, it's simply breaking backward compatibility for many users. > > they work fine now. Even if it weren't so it still would be silly if > > GCC simply could regard the former as the latter internally. > > That's what we're doing. Currently. But not the proposed patch in this thread, and the general idea of deprecating the basic syntax. Ciao, Michael.
Importing gnulib inside gcc
I’m working on importing gnulib inside gcc so that gcc can leverage it’s functionality (and possible replace certain dependencies from libiberty). I have imported the required gnulib modules in a directory inside the gcc directory, along with the necessary configure.ac and Makefile.in required to configure and compile gnulib. In order to invoke these from the top directory, I’m making the corresponding changes in gcc/Makefile.in and gcc/configure.ac However the build is giving me an error (specifically it is not able to find the libgnu.a file). I’m not sure why this is happening. I’m attaching the changes that I’ve made in the configure.ac and Makefile.in files Thanks, Ayush make_configure_gcc Description: Binary data
Re: Deprecating basic asm in a function - What now?
Hi,
On 20/06/16 19:01, Michael Matz wrote:
> On Mon, 20 Jun 2016, Andrew Haley wrote:
>
>> On 20/06/16 18:36, Michael Matz wrote:
>>> I see zero gain by deprecating them and only churn. What would be the
>>> advantage again?
>>
>> Correctness.
>
> As said in the various threads about basic asms, all correctness
> problems can be solved by making GCC more conservative in handling them
> (or better said: not making it less conservative).
Well, yes. That's exactly why we've agreed to change basic asms to
make them clobber memory, i.e. to make GCC more conservative.
> If you talk about cases where basic asms diddle registers expecting GCC to
> have placed e.g. local variables into specific ones (without using local
> reg vars, or extended asm) I won't believe any claims ...
>
>> It is very likely that many of these basic asms are not
>> robust
>
> ... of them being very likely without proof. They will have stopped
> working with every change in compilation options or compiler
> version. In contrast I think those that did survive a couple years
> in software very likely _are_ correct, under the then documented (or
> implicit) assumptions. Those usually are: clobbers and uses memory,
> processor state and fixed registers.
Well, maybe. It's also fairly likely that many work by accident. IMO
this is more of a statement of hope than any kind of reasonable
expectation.
>> in the face of compiler changes because they don't declare their
>> dependencies and therefore work only by accident.
>
> Then the compiler better won't change into less conservative
> handling of basic asms.
Repeat, repeat: the change being made is to make gcc MORE
conservative.
> You see, the experiment shows that there's a gazillion uses of basic
> asms out there. Deprecating them means that each and every one of
> them (for us alone that's 540 something, including testsuite and
> boehm) has to be changed from asm("body") into asm("body" : : :
> "memory") (give and take some syntax for also clobbering flags).
> Alternatively rewrite the body to actually make use of extended asm.
> I guarantee you that a non-trivial percentage will be wrong _then_
> while they work fine now. Even if it weren't so it still would be
> silly if GCC simply could regard the former as the latter
> internally.
That's what we're doing.
Andrew.
