Re: RFH: GPLv3
On Jul 12, 2007, Michael Eager [EMAIL PROTECTED] wrote: This would be chaotic. Acme Co's version of gcc-3.4 might be GPLv2 while MegaCorp's gcc-3.4 might be GPLv3. This is already true today. Even if MegaCorp doesn't make any changes to the code, the code is available under GPLv2+, which means they can license their compiler under GPLv3+, or GPLv3 only, at their choice. And this is a good thing. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
On Jul 12, 2007, Benjamin Smedberg [EMAIL PROTECTED] wrote: Obviously the FSF can relicense any code they want to GPL3... that doesn't mean that this community couldn't decide to only accept patches to the GCC4.2 branch that are licensed under the GPL2+. This wouldn't change the fact that any upcoming release of GCC issued by the FSF ought to be under GPLv3. But yes, people could still backport patches into their own GPLv2 releases given the policy above. But having backporters ask for permission from the authors or from the FSF sounds like a good incentive for them to switch to GPLv3 to avoid the hassle. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
On Jul 12, 2007, Mark Mitchell [EMAIL PROTECTED] wrote: 2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit backports from mainline to GCC 4.2.1, if necessary, to be downlicensed to GPLv2, as part of that release. 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. How about, after the 4.2.1 release, switch the branch to GPLv3 and then release 4.2.3, without any functional changes, under GPLv3? The skipped minor version number (to a .3, no less) and the quick succession of releases would probably hint at the license upgrade, and it would probably make the FSF happier with a GCC release under GPLv3 in a short time-frame. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
Alexandre Oliva wrote: Anyone who had their heads in the sand for the past 18 months when GPLv3 was being publicly discussed and developed, or wasn't at the GCC Summit last year when I mentioned that the FSF would most certainly want to upgrade the license of every project whose copyright it held as soon as GPLv3 was ready, may indeed consider the license upgrade as a surprising new feature. Not surprising, but significant. I think you greatly underestimate the cost and difficulty of upgrading to a new license for many large corporate users. This means getting lawyers involved, and for sure you don't want them wasting time tracking an 18 month period in which the license keeps changing. So you typically would wait till the license change was definite. All the version number change does is signal the need for initiating this process. Many of these users are not the kind of people who jump to every new latest-and-greatest version quickly anyway. Now, why should we weaken our defenses I am at a loss to understand this rhetoric, all we are talking about is what version number to use, how does this weaken our defenses (what defenses? against whom?).
Re: RFH: GPLv3
On Fri, 13 Jul 2007, Alexandre Oliva wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Every release of GCC in the past decade (and then some) was GPLv2+. GPLv3 has always been one of the options. Anyone who had their heads in the sand for the past 18 months when GPLv3 was being publicly discussed and developed, or wasn't at the GCC Summit last year when I mentioned that the FSF would most certainly want to upgrade the license of every project whose copyright it held as soon as GPLv3 was ready, may indeed consider the license upgrade as a surprising new feature. But anyone who wanted to participate was welcome to do so, and GPLv3 shouldn't be a surprise for anyone who did, or even just watched it from a distance. Now, why should we weaken our defenses for the sake of those who didn't plan for something that could have been so easily forecast 18 months ago, and that was even planned to be finished 4 months ago? Heck, the last-call draft, published one month before the final release, was so close to the final release that non-insider lawyers who were on top of the process managed to emit solid opinions about the final license the day after it was released. It's those who didn't do their homework and didn't plan ahead for this predictable upgrade who should be burdened now, rather than all of us having to accept weaker defenses for our freedoms or facing additional requirements on patches or backports. It was all GPLv2+, and this means permission for *anyone* to upgrade to GPLv3+. The license upgrade path is the easy path, and that's by design. I was just suggesting a rationale for choosing a version number. Nick
Re: abs insn with QI and HI mode
Hi, Thanks very much for your help. I have fixed the problem of the abs insn with HI and QI mode as you advised. Best regards Maggie
Re: RFH: GPLv3
On Jul 13, 2007, Robert Dewar [EMAIL PROTECTED] wrote: This means getting lawyers involved, and for sure you don't want them wasting time tracking an 18 month period in which the license keeps changing. Yet somehow a number of large stakeholders not only tracked the license development over 18 months, but actually participated and influenced it so as to meet their interests. And they somehow didn't think of it as wasting time. See, I'm not diminishing the importance of licensing issues, I'm just saying it's legally irresponsible to sit back and *not* even watch what's going on in the development of the license that a bunch of software one is very clearly interested in, and then try to frame the moment when the development is completed and the license is to be adopted, as forecast throughout the process and as explicitly permitted by the licensing practice in place for almost two decades, as something unexpected, as a sudden major legal burden. So you typically would wait till the license change was definite. It seems to me that it would be saner to not only keep up with the developments of the license, but also get one's major customers aware of the upcoming changes, not creating false expectations as to licensing issues. We shouldn't hold back the upgrade just because some vendors *might* have failed to keep up on the legal front. Now, why should we weaken our defenses I am at a loss to understand this rhetoric, all we are talking about is what version number to use, how does this weaken our defenses (what defenses? against whom?). Some people are advocating that patches be under GPLv2+, to enable earlier releases with backports to remain in GPLv2. Since GPLv2 has weaker defenses for users' freedoms than GPLv3, against those who might wish to impose restrictions on these freedoms, GPLv2-compatible patches would enable backports into more weakly-defended releases. The weaker defenses stem mainly out of uncertainty as to the extent of no further restrictions. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
On Jul 13, 2007, Nicholas Nethercote [EMAIL PROTECTED] wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Every release of GCC in the past decade (and then some) was GPLv2+. GPLv3 has always been one of the options. Anyone who had their heads in the sand for the past 18 months when GPLv3 was being publicly discussed and developed, or wasn't at the GCC Summit last year when I mentioned that the FSF would most certainly want to upgrade the license of every project whose copyright it held as soon as GPLv3 was ready, may indeed consider the license upgrade as a surprising new feature. But anyone who wanted to participate was welcome to do so, and GPLv3 shouldn't be a surprise for anyone who did, or even just watched it from a distance. Now, why should we weaken our defenses for the sake of those who didn't plan for something that could have been so easily forecast 18 months ago, and that was even planned to be finished 4 months ago? Heck, the last-call draft, published one month before the final release, was so close to the final release that non-insider lawyers who were on top of the process managed to emit solid opinions about the final license the day after it was released. It's those who didn't do their homework and didn't plan ahead for this predictable upgrade who should be burdened now, rather than all of us having to accept weaker defenses for our freedoms or facing additional requirements on patches or backports. It was all GPLv2+, and this means permission for *anyone* to upgrade to GPLv3+. The license upgrade path is the easy path, and that's by design. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RFH: GPLv3
Nicholas Nethercote wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Therefore what was going to be 4.2.2 should become 4.3.0. I certainly agree that the license is a feature, and a pretty important one for many users.
Re: RFH: GPLv3
On Thu, 12 Jul 2007, Michael Eager wrote: 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. This seems to confabulate the meaning of version numbers to now mean something about licensing. The difference between 4.2.1 and 4.2.2 would normally be considered a minor bug fix release, under this scheme of calling it 4.3.3, one would be misled to think that this is a minor bug fix for a non-existent minor release. The version numbering scheme correlating to functional changes is more valuable than any (IMO insubstantial) benefit of identifying the change in license version. One way to view it: the license is a feature. Therefore changing the license is changing a feature. Therefore what was going to be 4.2.2 should become 4.3.0. Nick
Re: RFH: GPLv3
Hi David, 2. Turn off public access to the code while changing license text in the source. This is not necessary. (I am assuming here that by public access to the code you mean access to the svn repository, not access to the various release tarballs). The repository sources are not an official release. They are part of the development process for future releases. Anyone using these sources should be aware of this and not expect them to remain constant. In particular, in the context of this discussion, no-one should expect that the mainline repository sources will all exist under the governance of just one version of the GPL. I will be as quick as I can in updating the mainline sources, but it is going to take me a couple of days. I am going to perform the upgrade in an incremental fashion as I do not have the bandwidth to perform a single pass commit of all of the sources. Cheers Nick
Re: RFH: GPLv3
Alexandre Oliva wrote: On Jul 13, 2007, Robert Dewar [EMAIL PROTECTED] wrote: So you typically would wait till the license change was definite. It seems to me that it would be saner to not only keep up with the developments of the license, but also get one's major customers aware of the upcoming changes, not creating false expectations as to licensing issues. We shouldn't hold back the upgrade just because some vendors *might* have failed to keep up on the legal front. I don't think the FSF should delay at all in moving its distributions to GPLv3. Do whatever version numbering is required to make it clear to users. The FSF can even go so far as to release no further GPLv2 patches. That is their right and they have no obligation to provide further support for older compilers. OTOH there are a number of non-FSF entities that have committed morally and/or legally to providing long-term support for gcc directly and/or OSes that ship with a gcc. I really believe these people need guidance from the FSF on what to do. --joel sherrill
Re: RFH: GPLv3
Robert Dewar wrote: Nicholas Nethercote wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Therefore what was going to be 4.2.2 should become 4.3.0. I certainly agree that the license is a feature, and a pretty important one for many users. There's a saying if you call a dog's tail a leg, how many legs does a dog have. Four. Calling its tail a leg doesn't make it one. Version numbers have been based on binary compatibility and interoperability between versions. Saying that license is an interoperability issue doesn't make it one. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFH: GPLv3
Alexandre Oliva wrote: On Jul 13, 2007, Nicholas Nethercote [EMAIL PROTECTED] wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Every release of GCC in the past decade (and then some) was GPLv2+. GPLv3 has always been one of the options. Anyone who had their heads in the sand for the past 18 months when GPLv3 was being publicly discussed and developed, or wasn't at the GCC Summit last year when I mentioned that the FSF would most certainly want to upgrade the license of every project whose copyright it held as soon as GPLv3 was ready, may indeed consider the license upgrade as a surprising new feature. Not everyone is a GCC developer. Upgrade the license of every project implied that this would be effective for future releases, not retroactive. Now, why should we weaken our defenses for the sake of those who didn't plan for something that could have been so easily forecast 18 months ago, and that was even planned to be finished 4 months ago? Heck, the last-call draft, published one month before the final release, was so close to the final release that non-insider lawyers who were on top of the process managed to emit solid opinions about the final license the day after it was released. It seems to me that it is the FSF which didn't forecast consequences well, and has now created a problem. No one is suggesting that any defenses be weakened. Only that source currently available under GPLv2 continue to be available under that license. It's those who didn't do their homework and didn't plan ahead for this predictable upgrade who should be burdened now, rather than all of us having to accept weaker defenses for our freedoms or facing additional requirements on patches or backports. It was all GPLv2+, and this means permission for *anyone* to upgrade to GPLv3+. The license upgrade path is the easy path, and that's by design. Companies will not upgrade to GPLv3 until they have reviewed it. It was released ~2 weeks ago. It's clearly been in a state of flux for many months, up until the release date. The question is not whether companies can upgrade past releases to GPLv3 voluntarily. That's a red herring. The question is whether companies who are currently releasing source under GPLv2 will be prohibited from releasing the code under GPLv2 if they do something as innocuous as apply a publicly posted patch. Try a pragmatic approach, rather than a dogmatic approach. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
incremental compiler project
I've started work on a project to turn GCC into an incremental compiler. This project is still in an investigative stage but I thought I would post some of my plans and ideas before making a branch. The primary goal of this project is improving the developer user experience by decreasing turnaround time for typical changes to a program. This project will focus on the C and C++ compilers. The basic idea of the project is to run GCC as a server (similar in a way to the old compile server branch) and try to minimize the amount of re-compilation done when a source file changes. This is a complicated task with several components: * Change GCC to run as a server. * Change the front ends to re-use the results of parsing header files. Currently I'm experimenting with a prototype based on --combine; the results of this will help determine the final design. One idea for the incremental part of the plan is to do nothing special aside from this reuse; determining whether this is practical is one of the goals of the prototype. BTW the prototype already has shown some nice results: 1/2 to 2/3 the runtime of the ordinary compiler, and 1/2 the memory. * Change GCC to avoid generating object code for objects (functions, variables definitions, etc) that have not changed. My current code generation plan is to fork the server process and generate a separate object per top-level definition. (I'm not totally sure if this is practical.) For the full benefit I expect we'll need an incremental (re-)linker as well, but this is a separate project. * Ideally, make the front ends parallel safe and parse in multiple threads. This will require removing most of the global variables from the C and C++ front ends. I'll be sending patches to the gcc-patches list, of course, and I will make a wiki page describing the project and its current state. I'll be at the GCC Summit in case anybody wants to talk in person about this. And, of course, I'm happy to answer questions and concerns via email as well. Tom
Re: RFH: GPLv3
Alexandre Oliva wrote: On Jul 13, 2007, Robert Dewar [EMAIL PROTECTED] wrote: See, I'm not diminishing the importance of licensing issues, I'm just saying it's legally irresponsible to sit back and *not* even watch what's going on in the development of the license Everybody's been watching. The license has changed many times. There's been on-going conflict between FSF and Linux. There's been widely publicized conflicts about about DRM, and Novell/Microsoft, patent license and other issues. It's been like watching a cat fight -- fur flying everywhere. No lawyer is going to spend his time trying to sort out the effect of the license until it is finalized. Some people are advocating that patches be under GPLv2+, to enable earlier releases with backports to remain in GPLv2. Since GPLv2 has weaker defenses for users' freedoms than GPLv3, against those who might wish to impose restrictions on these freedoms, GPLv2-compatible patches would enable backports into more weakly-defended releases. The weaker defenses stem mainly out of uncertainty as to the extent of no further restrictions. GPLv2 has been effective for many years. It doesn't stop being effective overnight. Let's tone down the high falootin' rhetoric about defending freedoms and discuss the pragmatic issues of how to manage licenses in a real world with real companies and real lawyers and real concerns. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
GCC 4.2.1 RC2
GCC 4.2.1 RC2 is now available from: ftp://gcc.gnu.org/pub/gcc/snapshots/4.2.1-RC-20070712 Unless severe problems are found with this release candidates, this will become the official GCC 4.2.1 release in the middle of next week. (I'm sorry it took me longer than I hoped to build RC2; I had a couple of aborted builds and some travel that interfered.) As always with release candidates, please do not directly send me email about problems you encounter. Instead, please file issues in the GCC bug-tracking system: http://gcc.gnu.org/bugzilla/ and add me to the CC: list. The GCC 4.2 branch remains frozen to all changes, without my explicit permission. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: incremental compiler project
On Jul 13, 2007, at 2:05 PM, Tom Tromey wrote: I've started work on a project to turn GCC into an incremental compiler. Sounds neat. :-) The basic idea of the project is to run GCC as a server (similar in a way to the old compile server branch) and try to minimize the amount of re-compilation done when a source file changes. Sounds familiar. :-) Good luck.
Re: RFH: GPLv3
As a (non-developer) user, may I humbly submit a slightly different view: The change of license is an Event, which needs to be marked in concrete by a version number change. All future mainline development will be under the GPLv3. However, there are many people who (due to legal or commercial pressures, amongst others) are required to continue under GPLv2, and there doesn't seem to be a good pragmatic reason to actively penalise those people. I think that having one more GPLv2 release, and then all future releases under GPLv3, creates a discontinuity in the compiler between licenses which may be unhelpful because the first GPLv3 gcc will be technically different to the last GPLv2 gcc. This means that the decision about which to use will be a combination of license issues and technical issues. So, could there be a simultaneous release of gcc under GPLv2 and GPLv3, identical in all respects except for the license? The GPLv2 release will represent the best-quality compiler that the project can deliver, as a base for those who must continue to support it. The GPLv3 release will be the reference point for future development, and will be a known quantity in technical terms. The GPLv2 compiler could be gcc 4.2.1, and the GPLv3 compiler could be gcc 4.3.0. There is an issue that people have been hearing about the new functionalities that gcc 4.3 will have, but it shouldn't be too hard to market the concept that 4.3 is now a license change version, and 4.4 will be the compiler that 4.3 was going to be. Perhaps the simultaneous release could be done on July 31, which is iirc the FSF's deadline for GPLv2 releases. Extending the gcc 4.2.1 release date might allow some last-minute bug-fixes to make it in there. Compiler vendors etc will have an increased workload maintaining the separability of GPLv2 and GPLv3 code during the transition to the new license, and it would seem that the transition will take quite some time (years?), but I'm sure that they will develop procedures to make it manageable. Cheers, Rob Brown.
gcc-4.3-20070713 is now available
Snapshot gcc-4.3-20070713 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070713/ 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/trunk revision 126629 You'll find: gcc-4.3-20070713.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070713.tar.bz2 C front end and core compiler gcc-ada-4.3-20070713.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070713.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070713.tar.bz2 C++ front end and runtime gcc-java-4.3-20070713.tar.bz2 Java front end and runtime gcc-objc-4.3-20070713.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070713.tar.bz2The GCC testsuite Diffs from 4.3-20070707 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: Host/Target confusion in Dwarf output
Michael Eager wrote: Is it guaranteed to hold all target integer sizes? How does this work for 32-bit hosts and 64-bit targets? RTL and tree constants were defined from the beginning as two HOST_WIDE_INTs. This was necessary to bootstrap long long support on 32-bit systems before most compilers had long long support. This means that the largest int on the host must be at least half the size of the largest int on the target. Hence, building 64-bit target compilers on 32-bit host systems has never been a problem. We have never supported 16-bit hosts from the beginning, so that is no problem. This does mean that you can't build a 128-bit target compiler on a 32-bit host, but that hasn't been a problem yet. This restriction by the way is one of the reasons why long long is 64-bits on 64-bit targets, because the 32-bit hosts used to build the initial 64-bit cross compilers could not support 128-bit integer constants. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: RFH: GPLv3
On Fri, Jul 13, 2007 at 08:54:17AM -0700, Michael Eager wrote: Robert Dewar wrote: Nicholas Nethercote wrote: One way to view it: the license is a feature. Therefore changing the license is changing a feature. Therefore what was going to be 4.2.2 should become 4.3.0. I certainly agree that the license is a feature, and a pretty important one for many users. There's a saying if you call a dog's tail a leg, how many legs does a dog have. Four. Calling its tail a leg doesn't make it one. Version numbers have been based on binary compatibility and interoperability between versions. Saying that license is an interoperability issue doesn't make it one. GPLv3+ code is however incompatible to GPLv2+ code, so it warrants a major version bump. Ciao, Marcus
Re: Host/Target confusion in Dwarf output
Jim Wilson wrote: This does mean that you can't build a 128-bit target compiler on a 32-bit host, but that hasn't been a problem yet. And now that we allow HOST_WIDE_INT to be defined as long long, this shouldn't be a problem any more either. A 32-bit host with 2 long longs gets us up to 128-bit constants. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: RFH: GPLv3
Geoffrey Keating wrote: Speaking as an individual developer who nonetheless needs to follow his company's policies on licensing, I need it to be *absolutely clear* whether a piece of software can be used under GPLv2 or not. If there's a situation where 'silent' license upgrades can occur, where even just one file in a release might be GPLv3, or any other situation where the license is not clear, then to me that software is unusable. This applies to subversion as well to releases in tarballs. That's a good point. I think it would be a good idea to pick a clear point at which the gcc mainline on SVN will stop being GPLv2, and make sure that a tarball of its state immediately before that point is produced. (I guess that point is whenever the first license-change patch gets committed.) This should also be documented clearly on the GCC main page, I think. - Brooks
valid_gimple_expression_p claims validity of invalid gimple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32746 is really caused by a combination of two things First is_gimple_min_invariant in try_to_simplify where it chooses DECL_INITIAL should be valid_gimple_expression_p instead. However, even if i fix this, the testcase still fails because valid_gimple_expression says something that is clearly invalid is valid. (gdb) p valid_gimple_expression_p ($2) $3 = 1 '\001' (gdb) p debug_generic_stmt ($2) ((struct RegisterLayout *) (char *) SimulatedRegisters)-intmask; This is not valid gimple by a longshot :) If you fix this part, i'll happily fix the bug report with the first part.
Re: RFH: GPLv3
Michael Eager wrote: Saying that license is an interoperability issue doesn't make it one. No, saying that is not what makes it so, that's true. However, the fact is that licensing *is* an interoperability issue, since it has to do with what units can be mixed together in a particular situation, which is what interoperability is about. If you mix one GPLv3 unit into a GPLv2 environment, you have a problem if you cannot tolerate GPLv3 licensing (e.g. because your lawyers have not got around to OKaying it, or worse because they have got around to not OKaying it). So it is really important to understand the circumstances in which GPLv3 is showing up. One could of course just take a blanket view that everything on the site is, as of a certain moment, licensed under GPLv3 (note you don't have to change file headers to achieve this, the file headers have no particular legal significance in any case). That at least would be clean, and anyone concerned with accepting GPLv3 stuff would simply know that as of this date and time, they should no longer download ANYTHING from the entire gnu.org site. That's actually not so terrible, you lose some users temporarily, but at least there is no misunderstanding.
[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args
--- Comment #7 from ubizjak at gmail dot com 2007-07-13 06:08 ---
I have following patch that solves nested VEC_SELECT insn. However, I would
like to enhance it for nested VEC_SELECT (VEC_SELECT (VEC_DUPLICATE (...)))
that is generated i.e. for __builtin_ia32_vec_ext_v4si(*val, 2);
Index: simplify-rtx.c
===
--- simplify-rtx.c (revision 126587)
+++ simplify-rtx.c (working copy)
@@ -2669,6 +2669,31 @@ simplify_binary_operation_1 (enum rtx_co
if (GET_CODE (trueop0) == CONST_VECTOR)
return CONST_VECTOR_ELT (trueop0, INTVAL (XVECEXP
(trueop1, 0, 0)));
+ if (GET_CODE (trueop0) == VEC_SELECT
+ (GET_MODE (XEXP (trueop0, 0)) == GET_MODE (trueop0)))
+ {
+ rtx op = XEXP (trueop0, 0);
+ rtx sel = XEXP (trueop0, 1);
+ enum machine_mode opmode = GET_MODE (op);
+ rtvec vec;
+ rtx tmp;
+
+ int elt_size = GET_MODE_SIZE (GET_MODE_INNER (opmode));
+ int n_elts = GET_MODE_SIZE (opmode) / elt_size;
+
+ int i = INTVAL (XVECEXP (trueop1, 0, 0));
+
+ gcc_assert (GET_CODE (sel) == PARALLEL);
+ gcc_assert (i n_elts);
+
+ /* Select value, pointed by nested selector. */
+ vec = rtvec_alloc (1);
+ RTVEC_ELT (vec, 0) = CONST_VECTOR_ELT (sel, i);
+ tmp = gen_rtx_PARALLEL (VOIDmode, vec);
+
+ tmp = gen_rtx_fmt_ee (code, mode, op, tmp);
+ return tmp;
+ }
}
else
{
Index: config/i386/sse.md
===
--- config/i386/sse.md (revision 126587)
+++ config/i386/sse.md (working copy)
@@ -4578,6 +4578,22 @@
operands[1] = gen_rtx_REG (SImode, REGNO (operands[1]));
})
+(define_insn_and_split *sse2_stored_1
+ [(set (match_operand:SI 0 register_operand =r)
+ (vec_select:SI
+ (match_operand:V4SI 1 memory_operand o)
+ (parallel [(match_operand 2 const_0_to_3_operand )])))]
+ TARGET_SSE
+ #
+ reload_completed
+ [(const_int 0)]
+{
+ int i = INTVAL (operands[2]);
+
+ emit_move_insn (operands[0], adjust_address (operands[1], SImode, i*4));
+ DONE;
+})
+
(define_expand sse_storeq
[(set (match_operand:DI 0 nonimmediate_operand )
(vec_select:DI
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661
[Bug fortran/32310] Intel-darwin specific ICE on CP2K code
--- Comment #7 from jv244 at cam dot ac dot uk 2007-07-13 07:17 --- is this still failing ? Yesterday, I ran a valgrinded compilation of CP2K, and it showed no errors (didn't check memory leaks). This has been on x86_64 though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32310
[Bug fortran/32727] [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util'
--- Comment #14 from jv244 at cam dot ac dot uk 2007-07-13 07:14 --- (In reply to comment #13) I would use your cp2k testcase but it does not compile on Cygwin - it runs out of memory during compilation. When I have a moment, I'll break itup. yes, it can be trivially split after every module, and compiled in that order. The other option is to check (a fixed version) out from cvs. See http://cp2k.berlios.de/download.html. That might initially be a few minutes more work to setup, but has the advantage that make -j X speeds up testing and that miscompilations can be more easily found. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32727
[Bug bootstrap/32753] New: building a crosscompiler for arm-elf fails because of an error in cirrus.md
When trying to build a crosscompiler for arm-elf with cd i386-linux8; CC=gcc CFLAGS=-O LDFLAGS=-s CLIB= LANGUAGES=c ../gcc-4.2.1-RC-20070703/configure --srcdir=../gcc-4.2.1-RC-20070703 --prefix=/usr/arch --with-local-prefix=/usr/arch --target=arm-elf --with-newlib --disable-libssp it will fail with: build/genoutput.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o ../build-i686-pc-linux-gnu/libiberty/libiberty.a build/genoutput ../../gcc-4.2.1-RC-20070703/gcc/config/arm/arm.md \ insn-conditions.md tmp-output.c ../../gcc-4.2.1-RC-20070703/gcc/config/arm/cirrus.md:407: error: undefined machine-specific constraint at this point: T,*v ../../gcc-4.2.1-RC-20070703/gcc/config/arm/cirrus.md:407: note: in operand 0 ../../gcc-4.2.1-RC-20070703/gcc/config/arm/cirrus.md:407: error: undefined machine-specific constraint at this point: T,*v,*v ../../gcc-4.2.1-RC-20070703/gcc/config/arm/cirrus.md:407: note: in operand 1 gmake[2]: *** [s-output] Error 1 gmake[2]: Leaving directory `/mnt/projekt/soft/uti/cmd/gcc/thumb/i386-linux8/gcc' gmake[1]: *** [all-gcc] Error 2 gmake[1]: Leaving directory `/mnt/projekt/soft/uti/cmd/gcc/thumb/i386-linux8' gmake: *** [all] Error 2 *** Error code 2 Stop. -- Summary: building a crosscompiler for arm-elf fails because of an error in cirrus.md Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: leo at marco dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32753
[Bug bootstrap/32753] building a crosscompiler for arm-elf fails because of an error in cirrus.md
--- Comment #1 from leo at marco dot de 2007-07-13 07:12 --- Created an attachment (id=13908) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13908action=view) Stupid patch to fix the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32753
[Bug tree-optimization/32589] [4.3 regression] exp_dbug.adb:981: error: invalid array index
--- Comment #14 from rob1weld at aol dot com 2007-07-13 07:27 --- Comment #13 From Eric Botcazou 2007-07-12 06:00 [reply] --- Please do not pollute this ticket with unrelated stuff. I posted here after previously searching many messages, and again re-searching more messages to see if you had made a new ticket in regards to: ... but the library still doesn't build. I only posted in relation to the build being broken at this point. I thought the info was related and would assist you in your repairs to have the build work _completely_ at this point in time. Thank you for fixing the portion that was fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32589
[Bug other/32754] New: The opt?-gen.awk file generators produce incorrect credits
Files: gcc-4_2-branch/gcc/optc-gen.awk , gcc-4_2-branch/gcc/opth-gen.awk ,
gcc-4_3-trunk/gcc/optc-gen.awk and gcc-4_3-trunk/gcc/opth-gen.awk
All contain this credit line:
print /* This file is auto-generated by opts.sh. */
Numerous documents and other files all mention opts.sh but I can find no such
file:
gcc-4_2-branch/gcc/ChangeLog-2004: * opts.sh: Generate variable
declarations, handle CL_REPORT.
gcc-4_2-branch/gcc/doc/.svn/text-base/options.texi.svn-base:@cindex
@samp{opts.sh}
gcc-4_2-branch/gcc/doc/options.texi:@cindex @samp{opts.sh}
gcc-4_2-branch/gcc/optc-gen.awk:print /* This file is auto-generated by
opts.sh. */
gcc-4_2-branch/gcc/opth-gen.awk:print /* This file is auto-generated by
opts.sh. */
gcc-4_2-branch/gcc/opts-common.c: issue, opts.sh makes -gen-decls point,
via the back_chain member,
...
It would be better if each of the opt?-gen.awk files credited themselves
instead of a non-existant file. It makes it more difficult to find out how the
files they create were created when you read those files with this erroneous
information.
--
Summary: The opt?-gen.awk file generators produce incorrect
credits
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32754
[Bug rtl-optimization/32747] [4.3 Regression] ICE segmentation fault or abort in combine on alpha
--- Comment #1 from belyshev at depni dot sinp dot msu dot ru 2007-07-13 08:26 --- Broken by r126517: 2007-07-10 Ian Lance Taylor [EMAIL PROTECTED] Replace no_new_pseudos in backends. ... -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||iant at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32747
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #36 from paolo dot bonzini at lu dot unisi dot ch 2007-07-13 09:57 --- Subject: Re: [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm' kkojima at gcc dot gnu dot org wrote: --- Comment #33 from kkojima at gcc dot gnu dot org 2007-07-12 01:11 --- It seems that the patch 126418 causes an ICE for gcc.dg/asm-4.c and the patch 126487 breaks gcc.c-torture/compile/2804-1.c on 4.2 for SH. Both failures happen only with -O0. It looks ia64 testresults show similar errors: http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00309.html http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00446.html The former is easy and I have a patch. I don't understand the latter instead, it looks like (on sh at least) reload is not able to make a valid address and it might be a latent bug. Could anybody look at it? Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug middle-end/32546] 'warning: array subscript is above/below array bounds' on delete[]
--- Comment #2 from mueller at gcc dot gnu dot org 2007-07-13 11:10 --- unfortunately setting TREE_NO_WARNING on the synthesized delete[] parameters does not help because it is lost during middle end folding -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32546
[Bug tree-optimization/32721] CCP removes volatile qualifiers.
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-13 12:19 ---
Actually, the optimized dump ist still correct:
main ()
{
int D.2011;
bb 2:
spinlock[0] = 0;
spinlock[1] = 0;
bb 3:
D.2011 = spinlock[0];
if (D.2011 != 0)
goto bb 3;
else
goto bb 4;
bb 4:
return;
}
spinlock[0] is re-loaded in every loop iteration. Likewise the assembly
is correct. Only if I remove the volatile qualifier from the declaration
of spinlock then FRE removes the redundancy. And this is because while
we keep the has_volatile_ops on the stmt after the propagation of the
pointer, the first alias pass clears it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug other/32188] DFP instrinic document is out of date
--- Comment #4 from hjl at lucon dot org 2007-07-13 13:22 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32188
[Bug libgcj/30632] libgcj failed to build for Linux/ia64
--- Comment #5 from hjl at lucon dot org 2007-07-13 13:26 --- Seems to work now. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30632
[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args
--- Comment #8 from ubizjak at gmail dot com 2007-07-13 13:25 --- Patch for SImode and SFmode vec_select at http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01263.html -- ubizjak at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2007- |patches/2007- |07/msg01077.html|07/msg01263.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661
[Bug other/32188] DFP instrinic document is out of date
--- Comment #3 from hjl at gcc dot gnu dot org 2007-07-13 13:22 --- Subject: Bug 32188 Author: hjl Date: Fri Jul 13 13:22:10 2007 New Revision: 126619 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126619 Log: 2007-07-13 H.J. Lu [EMAIL PROTECTED] PR other/32188 * doc/libgcc.texi: Update DFP intrinsics for DPD and BID. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/libgcc.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32188
[Bug ada/32733] g-spipat.adb:1597: error: definition in block 11 does not dominate use in block 12
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-07-13 13:15 --- Confirmed on platforms using SJLJ exceptions for Ada. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i386-unknown-netbsdelf3.1 | GCC host triplet|i386-unknown-netbsdelf3.1 | GCC target triplet|i386-unknown-netbsdelf3.1 | Last reconfirmed|-00-00 00:00:00 |2007-07-13 13:15:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32733
[Bug fortran/31320] Illegal read with gfortran.dg/alloc_comp_assign_2.f90 and *_3.f90
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-13 13:47 --- (In reply to comment #5) struct a a.0; struct array1_int4 parm.2; parm.2.dim[0].ubound = 3; a.0.i = (struct array1_int4) parm.2; /* ubound == 3 */ a.0.i.dim[0].ubound = a.0.i.dim[0].ubound + 1; /* ubound == 4 (!) */ x = a.0; Adding print *, ubound(x%i, 1), ubound(y%i, 1) to the source gives 4/4 instead of 3/3 as one would expect from the initalizer. This all happens in trans-expr.c(gfc_trans_subcomponent_assign):3007 The change for 0 to unity based indexing is done incorrectly - apparently, what is assumed to be zero based comes through as something else... sometimes! I think that the right thing to do here is to use the array_spec lower bound as the base and to use the expression upper-lower as the range. I'll see if I cannot post a fix in the next couple of days. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
[Bug rtl-optimization/32755] Seg fault when compile CPU2000 with -fsee
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-13 13:07 --- -fsee is broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32755
[Bug tree-optimization/32721] [4.3 Regression] CCP removes volatile qualifiers.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.1.2 4.2.0 Summary|CCP removes volatile|[4.3 Regression] CCP removes |qualifiers. |volatile qualifiers. Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug tree-optimization/32721] CCP removes volatile qualifiers.
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-07-13 12:36 ---
Basically we could just make sure to preserve TREE_THIS_VOLATILE on folded
memory references *spinlock[0] (where the indirect reference has this flag
set, but the result from maybe_fold_offset_to_reference, spinlock[0], has not),
and properly set has_volatile_ops on array references with TREE_THIS_VOLATILE
set. Like
Index: tree-ssa-ccp.c
===
*** tree-ssa-ccp.c (revision 126617)
--- tree-ssa-ccp.c (working copy)
*** static tree
*** 1839,1844
--- 1839,1845
maybe_fold_stmt_indirect (tree expr, tree base, tree offset)
{
tree t;
+ bool volatile_p = TREE_THIS_VOLATILE (expr);
/* We may well have constructed a double-nested PLUS_EXPR via multiple
substitutions. Fold that down to one. Remove NON_LVALUE_EXPRs that
*** maybe_fold_stmt_indirect (tree expr, tre
*** 1882,1888
t = maybe_fold_offset_to_reference (base_addr, offset,
TREE_TYPE (expr));
if (t)
! return t;
}
else
{
--- 1883,1892
t = maybe_fold_offset_to_reference (base_addr, offset,
TREE_TYPE (expr));
if (t)
! {
! TREE_THIS_VOLATILE (t) = volatile_p;
! return t;
! }
}
else
{
Index: tree-ssa-operands.c
===
--- tree-ssa-operands.c (revision 126617)
+++ tree-ssa-operands.c (working copy)
@@ -2078,6 +2078,9 @@ get_expr_operands (tree stmt, tree *expr
if (!none)
flags |= opf_no_vops;
+
+ if (TREE_THIS_VOLATILE (expr))
+ get_stmt_ann (stmt)-has_volatile_ops = true;
}
else if (TREE_CODE (ref) == INDIRECT_REF)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug rtl-optimization/32755] Seg fault when compile CPU2000 with -fsee
-- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-13 13:48:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32755
[Bug ada/32733] g-spipat.adb:1597: error: definition in block 11 does not dominate use in block 12
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-07-13 13:15 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-13 13:15:22 |2007-07-13 13:15:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32733
[Bug tree-optimization/32721] [4.3 Regression] CCP removes volatile qualifiers.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-10 16:15:57 |2007-07-13 12:45:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug middle-end/32546] 'warning: array subscript is above/below array bounds' on delete[]
--- Comment #1 from mueller at gcc dot gnu dot org 2007-07-13 11:05 --- this is yet another case of the middle end folding memory arithmetics back into an array ref that is out of bounds: operator delete [] ((void *) A + 0xfffc); (from orig dump) later it is: D.2607_30 = (*D.2517_7)[-4]; operator delete [] (D.2607_30); which will then trigger this warning (because -4 is clearly out of bounds). -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-13 11:05:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32546
[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-07-13 14:37 --- Does this function have cfun-static_chain_decl being used, and we have a copy of that here? No, it's a toplevel function. It is theoretically safe to call set_ssa_to_val with to == vn_top, but it's probably a bug somewhere, and i'd rather eliminate the bug cases before turning it off. visit_phi is called on a PHI node with 1 argument (shrinked by DOM): # NMT.152_89(ab) = PHI NMT.152_264(ab)(22) and the SSA_VAL of NMT.152_264 is VN_TOP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug c++/32756] New: wrong ambiguous overload error?
Hi,
this might be invalid, needs verification. starting with gcc 4.3, the following
testcase is rejected:
=== Cut ===
class QString;
struct QByteArray
{
QByteArray ();
bool operator!= (const QString s2) const;
};
bool operator!= (const QByteArray a1, const QByteArray a2);
struct QString
{
QString ();
QString (const QByteArray a);
};
QByteArray abbreviation ();
void
fromString ()
{
QByteArray zoneAbbrev;
if (abbreviation () != zoneAbbrev)
{
}
}
=== Cut ===
ambiguity.cc:23: error: ISO C++ says that these are ambiguous, even though the
worst conversion for the first is better than the worst conversion for the
second:
ambiguity.cc:9: note: candidate 1: bool operator!=(const QByteArray, const
QByteArray)
ambiguity.cc:6: note: candidate 2: bool QByteArray::operator!=(const QString)
const
--
Summary: wrong ambiguous overload error?
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32756
[Bug fortran/32665] allocatable array on lhs deleted while still in use on rhs
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-13 09:58 --- Paul, please have a look at PR31320 as well. The issue described there is at least very close to your observation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32665
[Bug fortran/32665] allocatable array on lhs deleted while still in use on rhs
--- Comment #2 from pault at gcc dot gnu dot org 2007-07-13 09:50 --- This is a two-in-oner; as well as the deallocation, this is broken: $ cat pr32665.f90 TYPE :: x INTEGER, ALLOCATABLE :: a(:) END TYPE TYPE(x) :: a, b call foo b = x((/ (a%a), 4 /)) print *, foo gives , b%a call bar b = x((/ (a%a), 4 /)) print *, bar gives , b%a contains subroutine foo allocate (a%a(2)) a%a(1) = 1 a%a(2) = 2 end subroutine subroutine bar a = x ((/1, 2/)) end subroutine end $ ./a foo gives1 2 4 bar gives1 2 0 4 This comes about because the structure constructor suddenly runs amok, with: parm.2.data = 0B; x.0.a.offset = 0; x.0.a.dim[0].ubound = x.0.a.dim[0].ubound + 1; x.0.a.dim[0].lbound = 1; D.1014 = x.0.a.dim[0].lbound * x.0.a.dim[0].stride; x.0.a.offset = x.0.a.offset - D.1014; } a = x.0; *sigh* Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32665
[Bug c/32751] Missed optimization with function ptrs even when inline
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-13 09:41 --- We would have to re-build cgraph edges incrementally during inlining. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-07-13 09:41:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32751
[Bug rtl-optimization/32755] Seg fault when compile CPU2000 with -fsee
--- Comment #1 from Joey dot ye at intel dot com 2007-07-13 09:21 --- Created an attachment (id=13909) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13909action=view) Reduced testcase GCC crashes with gcc -O2 -fsee case-see.c -c Fails at all recent 4.3 trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32755
[Bug rtl-optimization/32755] New: Seg fault when compile CPU2000 with -fsee
4.3 trunk fails to build any 2006 with -fsee on x86_64: gcc -c -o av.o -DSPEC_CPU -DNDEBUG -DPERL_CORE -O2 -fsee -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX_X64 av.c av.c: In function 'Perl_av_reify': av.c:50: internal compiler error: Segmentation fault -- Summary: Seg fault when compile CPU2000 with -fsee Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Joey dot ye at intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32755
[Bug target/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90
--- Comment #2 from hjl at lucon dot org 2007-07-13 14:50 --- revision 126030 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32749
[Bug target/32748] [4.3 regression]: gfortran.dg/array_constructor_6.f90
--- Comment #1 from hjl at lucon dot org 2007-07-13 14:50 --- revision 126200 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748
[Bug rtl-optimization/32755] Seg fault when compile CPU2000 with -fsee
--- Comment #2 from Joey dot ye at intel dot com 2007-07-13 09:27 --- Root cause looks like at see.c line 1643: emit_insn_after (merged_ref, ref); delete_insn (ref); where merged_ref and ref have the same INSN_UID. delete_insn will clear the df information of that UID, resulted as no df information for merged_ref. I tried inserting following line and it works: + INSN_UID(merged_ref)=cfun-emit-x_cur_insn_uid++; But it is apparantly ugly. Anyone can share the right approach to replace a insn with another one who has the same UID? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32755
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #35 from bonzini at gnu dot org 2007-07-13 09:28 --- Subject: Bug 32004 Author: bonzini Date: Fri Jul 13 09:28:16 2007 New Revision: 126616 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126616 Log: 2007-07-13 Paolo Bonzini [EMAIL PROTECTED] Revert these patches: 2007-07-09 Paolo Bonzini [EMAIL PROTECTED] PR middle-end/32004 * function.c (rest_of_match_asm_constraints): Pass PROP_REG_INFO. 2007-07-06 Paolo Bonzini [EMAIL PROTECTED] PR middle-end/32004 * function.c (match_asm_constraints_1, rest_of_match_asm_constraints, pass_match_asm_constraints): New. * passes.c (init_optimization_passes): Add new pass. * stmt.c (expand_asm_operands): Set cfun-has_asm_statement. * function.h (struct function): Add has_asm_statement bit. (current_function_has_asm_statement): New. * tree-pass.h (pass_match_asm_constraints): New. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/function.c branches/gcc-4_1-branch/gcc/function.h branches/gcc-4_1-branch/gcc/passes.c branches/gcc-4_1-branch/gcc/stmt.c branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr21291.c branches/gcc-4_1-branch/gcc/tree-pass.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug fortran/32665] allocatable array on lhs deleted while still in use on rhs
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-13 13:48 --- (In reply to comment #3) Paul, please have a look at PR31320 as well. The issue described there is at least very close to your observation. (In reply to comment #3) Paul, please have a look at PR31320 as well. The issue described there is at least very close to your observation. Daniel, So close, in fact, as to be identical! Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32665
[Bug fortran/32737] internal compiler error: Segmentation fault
--- Comment #9 from alex_zuma1 at yahoo dot com 2007-07-13 12:35 --- (In reply to comment #8) I downloaded the latest binaries and I had no problems compiling the code. The bug must have been fixed recently (I downloaded gfortran at the beginning of July 07). What should I do with the bug on Bugzilla? Alessandro -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32737
[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-07-13 15:12
---
visit_phi is called on a PHI node with 1 argument (shrinked by DOM):
I presume this degenerated PHI is not eliminated because it is abnormal:
(gdb) p debug_tree(phi)
phi_node 0x5577f700 asm_written
(gdb) p debug_tree(def)
ssa_name 0x557f04e0
type record_type 0x5577672c string___XUB readonly DI
size integer_cst 0x55709738 constant invariant 64
unit size integer_cst 0x55709754 constant invariant 8
align 32 symtab 0 alias set 45 canonical type 0x5577672c
fields field_decl 0x5576a5a0 LB0 type integer_type 0x557162f4
integer
nonaddressable SI file gcc/ada/rts/a-except.ads line 306
size integer_cst 0x5570963c constant invariant 32
unit size integer_cst 0x55709428 constant invariant 4
align 32 offset_align 128
offset integer_cst 0x55709968 constant invariant 0
bit offset integer_cst 0x55709984 constant invariant 0 context
record_type 0x5577672c string___XUB chain field_decl 0x5576a600 UB0 Ada
size integer_cst 0x55709738 64
pointer_to_this pointer_type 0x55776798 chain type_decl 0x55776b64
D.690
asm_written visited var name_memory_tag 0x557de958 NMT.152 def_stmt
call_expr 0x5571439c
version 264 in-abnormal-phi
/* Propagate RHS into all uses of LHS (when possible).
RHS and LHS are derived from STMT, which is passed in solely so
that we can remove it if propagation is successful.
When propagating into a PHI node or into a statement which turns
into a trivial copy or constant initialization, set the
appropriate bit in INTERESTING_NAMEs so that we will visit those
nodes as well in an effort to pick up secondary optimization
opportunities. */
static void
propagate_rhs_into_lhs (tree stmt, tree lhs, tree rhs, bitmap
interesting_names)
{
/* First verify that propagation is valid and isn't going to move a
loop variant variable outside its loop. */
if (! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs)
(TREE_CODE (rhs) != SSA_NAME
|| ! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug c++/32089] Winline reports bogus warning
--- Comment #5 from James dot W dot Mckelvey at jpl dot nasa dot gov 2007-07-13 15:28 --- (In reply to comment #3) Can you attach the preprocessed source? I did on June 10, I see the status is still Waiting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32089
[Bug c/32757] New: Optimizer too aggressive
When compiling the following code with -O2 or -Os, the if clause at the end of
STRING_hash_code is optimized away, yielding in a negative result
if(R0){
R=~R;
}
With -O1 everything works as expected (positive result)
#include stdint.h
#include stdio.h
#include string.h
typedef struct {unsigned char* storage;int32_t count;int32_t capacity;} STRING;
int main(int argc, char *argv[]) {
STRING x;
x.storage=HASHED_DICTIONARY[WEAK_REFERENCE[ANY_HASHED_DICTIONARY_NODE],STRING];
x.count=strlen(x.storage);
x.capacity=x.count+1;
printf(%d\n,STRING_hash_code(x));
}
int32_t STRING_hash_code(STRING* C){
int32_t R=0;
int32_t i=0;
int32_t j=0;
j=C-count;
i=1;
while (j0)
{
R=5*R+C-storage[i-1];
i++;
j--;
}
if(R0){
R=~R;
}
return R;
}
--
Summary: Optimizer too aggressive
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: frederic dot merizen at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32757
[Bug fortran/32737] internal compiler error: Segmentation fault
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-07-13 15:28 --- (In reply to comment #9) What should I do with the bug on Bugzilla? I'll close it for you. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32737
[Bug c/32757] Optimizer too aggressive
--- Comment #1 from rask at sygehus dot dk 2007-07-13 15:34 ---
I don't see how R can become negative:
R=0;
while (...)
{
...
R=R*5+[unsigned value here];
...
}
What am I missing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32757
[Bug c/32757] Optimizer too aggressive
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-13 15:35 --- Overflow of signed integers is undefined. Use an unsigned quantity for R. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32757
[Bug tree-optimization/32751] Missed optimization with function ptrs even when inline
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-13 15:46 --- *** This bug has been marked as a duplicate of 9079 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32751
[Bug tree-optimization/9079] [tree-ssa] Inline constant function pointers
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-07-13 15:46 --- *** Bug 32751 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rusty at rustcorp dot com ||dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9079
[Bug fortran/31519] spurious ICE messages when module does not compile
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-07-13 15:47 --- (In reply to comment #6) Bugs where the compiler proper crashes when run under the driver, but not when run directly, can often be reproduced by varying the amount of space taken up by environment variables, e.g. Excellent advice, thanks very much! By making a variable x that contains 1064449 successive 1 characters, I get the following: $ X=$x c:/msys/1.0.10/home/fx/irun/mingw/libexec/gcc/i386-pc-mingw32/4.3.0/f951 .exe a.f90 -quiet Segmentation fault Unfortunately, I can't really debug it, because gdb itself segfaults when used with such a large environment variable. In fact, most programs I tried do segfault when used with this large environment variable (including as, ld, flex). So... now the question is more about how the driver ends up creating so large environment variables. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-04-13 15:20:21 |2007-07-13 15:47:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519
[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-07-13 15:48
---
And of course the naive patch:
[EMAIL PROTECTED]:~/svn/gcc/gcc Index: tree-ssa-sccvn.c
===
--- tree-ssa-sccvn.c(revision 126547)
+++ tree-ssa-sccvn.c(working copy)
@@ -1279,7 +1279,7 @@ visit_phi (tree phi)
/* If all value numbered to the same value, the phi node has that
value. */
- if (allsame)
+ if (allsame sameval != VN_TOP)
{
if (is_gimple_min_invariant (sameval))
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug c/32757] Optimizer too aggressive
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-13 15:50 --- Not if you test against (signed)R ;). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32757
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-13 15:53 --- *** Bug 32755 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Joey dot ye at intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug rtl-optimization/32755] Seg fault when compile CPU2000 with -fsee
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-13 15:53 --- *** This bug has been marked as a duplicate of 32300 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32755
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-13 15:55 --- Joseph - does your candidate patch still exist? We run into exactly the same problem with the proposed gimple type verifier posted at http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01265.html Thanks. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug other/22368] [meta-bug] mis-match types in GCC
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-07-13 15:56 --- http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01265.html has some fixes for some of this PRs and a verifier. So while we're working on this, this is my bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-01 02:27:34 |2007-07-13 15:56:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug tree-optimization/32721] [4.3 Regression] CCP removes volatile qualifiers.
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-13 15:41 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug c/32757] Optimizer too aggressive
--- Comment #3 from rask at sygehus dot dk 2007-07-13 15:40 --- Well, if you declare R as unsigned, GCC will still optimize away if (R0). ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32757
[Bug tree-optimization/32721] [4.3 Regression] CCP removes volatile qualifiers.
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-07-13 15:41 --- Subject: Bug 32721 Author: rguenth Date: Fri Jul 13 15:41:02 2007 New Revision: 126624 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126624 Log: 2007-07-13 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/32721 * tree-ssa-ccp.c (maybe_fold_stmt_indirect): Preserve TREE_THIS_VOLATILE on the folded reference. * tree-ssa-operands.c (get_expr_operands): Set has_volatile_ops if the array reference has TREE_THIS_VOLATILE set. * gcc.dg/pr32721.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr32721.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-ssa-operands.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
We need a Representative in the United States/Canada
I am Sarah Alcott,the Initiator of FOUNDATION OF HOPE UK. The Foundation for Hope is non-profit and Our Mission is to facilitate inspiring, meaningful outdoor experiences for youth who suffer life-challenging medical conditions. We value,promote and continue to preserve the heritage of the Outdoor Sportsman. We have sent letters to well meaning and high net worth individual and Companies in CANADA seeking donations and funding but we usually have donors refusing to send money overseas . Presently our Website is still under construction so We need a Representative in the United States/Canada who can help accept Drafts/Check/Money order on our behalf or be our Payment Agent . We will offer you 10% of any of my payment that passed through you ,if Neccesary. Would you consider joining us to help make a youth's outdoor dream come true? Whether you give time or financial resources, your involvement will make a significant difference in the life of an individual. All Donations made to the foundation are tax deductible. I will give details you as soon as I hear from you Miss Sarah Alcott FOUNDATION OF HOPE DEVLIN HOUSE 2D FLOOR, 36 ST GEORGE ST, MAYFAIR,LONDON W1S 2FW9FA Registered No. 04292324 (http://www.ukdata.com/)
[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #10 from dberlin at gcc dot gnu dot org 2007-07-13 16:47
---
Subject: Re: [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
On 13 Jul 2007 15:49:03 -, ebotcazou at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-07-13 15:48
---
And of course the naive patch:
[EMAIL PROTECTED]:~/svn/gcc/gcc Index: tree-ssa-sccvn.c
===
--- tree-ssa-sccvn.c(revision 126547)
+++ tree-ssa-sccvn.c(working copy)
@@ -1279,7 +1279,7 @@ visit_phi (tree phi)
/* If all value numbered to the same value, the phi node has that
value. */
- if (allsame)
+ if (allsame sameval != VN_TOP)
{
if (is_gimple_min_invariant (sameval))
{
Nah, that's not quite right, since this is a legal value.
Instead, where we init everything to VN_TOP, init everything with
SSA_NAME_OCCURS_IN_ABNORMAL_PHI to itself instead of VN_TOP.
IE VN_INFO (a)-valnum = a iff SSA_NAME_OCCURS_IN_ABNORMAL_PHI (a)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug target/32340] libjava build failure due to missing thread synchronization primitives
--- Comment #2 from patchapp at dberlin dot org 2007-07-13 17:15 --- Subject: Bug number PR 32340 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01273.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340
[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-07-13 17:16
---
Nah, that's not quite right, since this is a legal value.
Instead, where we init everything to VN_TOP, init everything with
SSA_NAME_OCCURS_IN_ABNORMAL_PHI to itself instead of VN_TOP.
Note that we already deal with SSA_NAME_OCCURS_IN_ABNORMAL_PHI in visit_use,
but not for PHI nodes:
if (TREE_CODE (stmt) == PHI_NODE)
{
changed = visit_phi (stmt);
}
else if (TREE_CODE (stmt) != GIMPLE_MODIFY_STMT
|| (ann ann-has_volatile_ops))
{
changed = defs_to_varying (stmt);
}
[...]
if (TREE_CODE (lhs) == SSA_NAME
SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs))
changed = defs_to_varying (stmt);
What about doing the same for them?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #12 from dberlin at gcc dot gnu dot org 2007-07-13 17:18
---
Subject: Re: [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
On 13 Jul 2007 17:16:27 -, ebotcazou at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-07-13 17:16
---
Nah, that's not quite right, since this is a legal value.
Instead, where we init everything to VN_TOP, init everything with
SSA_NAME_OCCURS_IN_ABNORMAL_PHI to itself instead of VN_TOP.
Note that we already deal with SSA_NAME_OCCURS_IN_ABNORMAL_PHI in visit_use,
but not for PHI nodes:
if (TREE_CODE (stmt) == PHI_NODE)
{
changed = visit_phi (stmt);
}
else if (TREE_CODE (stmt) != GIMPLE_MODIFY_STMT
|| (ann ann-has_volatile_ops))
{
changed = defs_to_varying (stmt);
}
[...]
if (TREE_CODE (lhs) == SSA_NAME
SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs))
changed = defs_to_varying (stmt);
What about doing the same for them?
Sure, that would work too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug java/32758] New: ecj1 hangs
I built gcj and when I try to compile anything ecj1 uses about 5:33 minutes of CPU time, then ecj1 and gcj just sit doing nothing. PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 9951 ecj1 0.0% 5:33.55 23270 41.5M 94.1M 60.9M 350M 9950 gcj 0.0% 0:00.01 11926 260K 1.43M 1.05M 87.8M [dranta:~/tests] dir% gcj -bind_at_load --main=picture -o picture picture.java ^C [dranta:~/tests] dir% gcj --v Using built-in specs. Reading specs from /usr/local/java/lib/gcc/powerpc-apple-darwin8.10.0/4.3.0/../../../libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig Target: powerpc-apple-darwin8.10.0 Configured with: ../gcc/configure --prefix=/usr/local/java --enable-languages=c,c++,java --enable-java-awt=gtk --enable-gtk-cairo --disable-multilib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-ecj-jar=/Users/dir/gfortran/gcc/ecj.jar Thread model: posix gcc version 4.3.0 20070705 (experimental) -- Summary: ecj1 hangs Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: Darwin 8.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758
[Bug target/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90
--- Comment #3 from hjl at lucon dot org 2007-07-13 18:52 --- revision 126045 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32749
[Bug target/32748] [4.3 regression]: gfortran.dg/array_constructor_6.f90
--- Comment #2 from hjl at lucon dot org 2007-07-13 18:53 --- revision 126240 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748
[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-07-13 19:09
---
What about doing the same for them?
That doesn't work as easily as I expected. :-)
Now I get the same assertion failure for non-degenerate PHI nodes whose result
is not SSA_NAME_OCCURS_IN_ABNORMAL_PHI but whose operands are, so something
like
--- tree-ssa-sccvn.c(revision 126547)
+++ tree-ssa-sccvn.c(working copy)
@@ -1502,7 +1502,11 @@ visit_use (tree use)
{
if (TREE_CODE (stmt) == PHI_NODE)
{
- changed = visit_phi (stmt);
+ tree result = PHI_RESULT (stmt);
+ if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (result))
+ changed = set_ssa_val_to (result, result);
+ else
+ changed = visit_phi (stmt);
}
else if (TREE_CODE (stmt) != GIMPLE_MODIFY_STMT
|| (ann ann-has_volatile_ops))
is not sufficient. So I'm going to test your solution.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug c/32759] New: False claim of that xyz is used uninitialized
I'd accept may be used uninitialized, but I'm positively told
is used uninitialized, which ain't true.
This is similar to bugs 32395 and 22197: apologies if it turns out to be
a mere duplicate. My code example is much simpler than the examples
given for those bugs: there are no aggregate types, the parameter
passing isn't interesting, and initialisation obviously DOES happen.
Also seen in 4.1.2 (I got around to building 4.2.0 so I could
verify the problem...)
The warning is attached to the line where 'diff' is assigned a
value. Note that this value is not then used again.
Required flags: -c -Wuninitialized -O1
(n.b.: -Wuninitialized is incompatible with -O0, but any other -On will do)
No headers required.
double Find_Limit(double xcentre, unsigned ang)
{
double diff;
long xlimit;
ang = 1U;
switch (ang)
{
case 0U:
xlimit = xcentre;
break;
case 1U:
xlimit = xcentre;
break;
}
diff = xlimit;
return ang ? xlimit : 0.0;
} /* End of function Find_Limit() */
Removing the assignment to diff (which isn't used) demotes
is uninitialized to may be uninitialized. Combining the two
case-clauses of the switch statement under the same header
(case 0U: case 1U: stuff) likewise demotes. Removing the use of
xlimit in the final (returned-value) expression removes the warning
entirely (so it DOES notice that diff isn't used - or is it more
confused than I think?)
If, in the assignments to xlimit, the right-hand expressions are replaced
with literal constants, the warning disappears entirely - even if the
two literal constants are unequal. So does the compiler recognise
that the two handled cases in the switch are exhaustive or doesn't it?
This looks deeply strange to me.
--
Summary: False claim of that xyz is used uninitialized
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard at brenda-arkle dot demon dot co dot uk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32759
[Bug target/32748] [4.3 regression]: gfortran.dg/array_constructor_6.f90
--- Comment #3 from hjl at lucon dot org 2007-07-13 20:03 --- revision 126260 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748
[Bug target/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90
--- Comment #4 from hjl at lucon dot org 2007-07-13 20:02 --- revision 126056 is bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32749
[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2007-07-13 20:43
---
Instead, where we init everything to VN_TOP, init everything with
SSA_NAME_OCCURS_IN_ABNORMAL_PHI to itself instead of VN_TOP.
@@ -1912,13 +1912,16 @@ init_scc_vn (void)
VN_TOP = create_tmp_var_raw (void_type_node, vn_top);
/* Create the VN_INFO structures, and initialize value numbers to
- TOP. */
+ TOP, except for SSA names appearing in abnormal PHI nodes. */
for (i = 0; i num_ssa_names; i++)
{
tree name = ssa_name (i);
if (name)
{
- VN_INFO_GET (name)-valnum = VN_TOP;
+ if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (name))
+ VN_INFO_GET (name)-valnum = name;
+ else
+ VN_INFO_GET (name)-valnum = VN_TOP;
VN_INFO (name)-expr = name;
}
}
is not sufficient to eliminate all the failures. I get the same assertion
failure for non-degenerate PHI nodes without SSA_NAME_OCCURS_IN_ABNORMAL_PHI
anywhere, all operands having SSA_VAL set to VN_TOP. Top-level function too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug target/32748] [4.3 regression]: gfortran.dg/array_constructor_6.f90
--- Comment #4 from hjl at lucon dot org 2007-07-13 20:50 --- revision 126271 is bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748
[Bug target/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90
--- Comment #5 from hjl at lucon dot org 2007-07-13 20:56 --- revision 126050 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32749
[Bug c/32757] Optimizer too aggressive
--- Comment #5 from frederic dot merizen at gmail dot com 2007-07-13 21:44 --- OK. I assumed signed overflow was at least defined to yield an integer (i.e. a quantity that is consistently negative or non-negative) but that is actually not specified. I don't quite know what I'll do with our library yet. Adding lots of unsigned/signed casts is an option, but it's likely to break a lot of valid optimizations so I'll try to avoid that. Would the -fno-strict-overflow option be a valid workaround in the meantime? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32757
[Bug target/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90
--- Comment #6 from hjl at lucon dot org 2007-07-13 21:53 --- revision 126054 is bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32749
[Bug target/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90
--- Comment #7 from hjl at lucon dot org 2007-07-13 21:57 --- This patch http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01977.html is the cause. Richard, can you look into it? Thanks. -- hjl at lucon dot org changed: What|Removed |Added CC||rguenther at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32749
[Bug target/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-13 22:07 --- Sure, though I doubt this patch changed anything. I won't get to it until after the summit though. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|rguenther at suse dot de|rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32749
