Re: RFC: Add 32bit x86-64 support to binutils
On 01/04/2011 11:46 PM, Jan Beulich wrote: Oh god, please, no. I have to say I'm highly questioning to Jan's statement in the first place. Crossing 32- and 64-bit ELF like that sounds like a kernel security hole waiting to happen. A particular OS/kernel has the freedom to not implement support for other than the default format. But having the ABI disallow it altogether certainly isn't the right choice. And yes, we had been allowing cross-bitness ELF in an experimental (long canceled) OS of ours. Yeah, and there are other targets where the elf class determines ABI too (e.g. EM_S390 is used for both 31-bit and 64-bit binaries and the ELF class determines which). So the usual thing is going to happen - someone made a mistake (I'm convinced the ELF class was never meant to affect anything but the file format), and this gets taken as an excuse to let the mistake spread. I don't think it's all that unreasonable to say the ELF class affects the ABI. After all, there are lots of things about the ABI that is related to the ELF class -- the format of the GOT and PLT, for one thing. -hpa
Re: RFC: Add 32bit x86-64 support to binutils
On 05.01.11 at 09:01, H. Peter Anvin h...@zytor.com wrote: On 01/04/2011 11:46 PM, Jan Beulich wrote: Oh god, please, no. I have to say I'm highly questioning to Jan's statement in the first place. Crossing 32- and 64-bit ELF like that sounds like a kernel security hole waiting to happen. A particular OS/kernel has the freedom to not implement support for other than the default format. But having the ABI disallow it altogether certainly isn't the right choice. And yes, we had been allowing cross-bitness ELF in an experimental (long canceled) OS of ours. Yeah, and there are other targets where the elf class determines ABI too (e.g. EM_S390 is used for both 31-bit and 64-bit binaries and the ELF class determines which). So the usual thing is going to happen - someone made a mistake (I'm convinced the ELF class was never meant to affect anything but the file format), and this gets taken as an excuse to let the mistake spread. I don't think it's all that unreasonable to say the ELF class affects the ABI. After all, there are lots of things about the ABI that is related to the ELF class -- the format of the GOT and PLT, for one thing. That's in executables and dynamic objects only. I'm not aware of anything in relocatable objects, and I'd question it for core files. The ABI, however, has to cover all of them. Jan
Re: cloog(-parma) 0.16 and ppl 0.11 in infrastructure?
On Sun, Jan 02, 2011 at 04:55:09PM +0100, Richard Guenther wrote: On Fri, Dec 31, 2...@12:40 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: Sebastian, It appears that the official tarballs are now pos...@http://www.cloog.org/ for cloog and cloog-parma 0.16. Do you plan on placing those both in the infrastructure direct...@gcc.gnu.org's ftp site? If so, the newer ppl 0.11 tarball should be added as well. If those files are updated, we should be set to switch gcc trunk to require ppl = 0.11, cloog = 0.16 and the default cloog backend from legacy cloog-ppl to cloog-isl. I don't think this is a very good i...@this point. Richard, How about for gcc 4.6.1? It seems a shame to push the conversion to cloog.org in graphite to the next release. Hopefully enough of the remaining loop and vectorization issues with graphite can be ironed out by gcc 4.7 such that defaulting -fgraphite-identity for -O2 might finally be considered. Jack Richard. Jack
Re: register allocation
2011/1/3 Jeff Law l...@redhat.com: On 12/27/10 08:43, roy rosen wrote: I'd recommend to try ira-improv branch. I think that part of the problem is in usage of cover classes. The branch removes the cover classes and permits IRA to use intersected register classes and that helps to assign better hard registers. I tried now this branch and got better results for some cases but still in other cases I get lots of redundent register copies. I might be missing something from the gcc history but I wonder why do we need to limit the coloring stage to select a hard reg from a class that was chosen by a prior stage. It was a design decision with the introduction of IRA. It made certain problems easier to resolve at the time and in reality, most of the time the set of legitimate and profitable hard registers for a given pseudo maps to a register class reasonably well. Why not simply put in the interference graph edges for all registers which are not possible for a pseudo and let the coloring algorithm select the best hard reg. That's largely what the ira-improv branch does. Register classes at that point are used primarily to drive the costing model. Actually, I tried on this branch disabling the improve_allocation function and now it is doing a great job. For some reason the improve_allocation function only damaged the good allocation that was done. In order to look at that I am trying to understand the conflict table: I see ;; a3(r255,l0) conflicts: a4(r243,l0) a6(r129,l0) a8(r126,l0) a9(r254,l0) a10(r256,l0) a11(r257,l0) a12(r291,w0,l0) a12(r291,w1,l0) a13(r316,w0,l0) a13(r316,w1,l0) a14(r318,w0,l0) a14(r318,w1,l0) a15(r319,w0,l0) a15(r319,w1,l0) a16(r321,w0,l0) a16(r321,w1,l0) a5(r253,l0) a7(r252,l0) a17(r261,l0) ;; total conflict hard regs: 53 ;; conflict hard regs: 53 I see here conflicts of the pseudo with other pseudos and conflict with a hard reg - all are result of live range data. How is the constraint data which limits a pseudo in an insn to be of a certain class gets into this table? I have expected also all hard regs which are not allowed for this pseudo because of constraints in the insns to be also in the conflict table. I guess I miss something... If it isn't there then how is it guranteed that the pseudo would be allocated to a hard reg which is allowed by the constraints? Thanks, Roy. jeff
Re: register allocation
Why not simply put in the interference graph edges for all registers which are not possible for a pseudo and let the coloring algorithm select the best hard reg. That's largely what the ira-improv branch does. Register classes at that point are used primarily to drive the costing model. Actually, I tried on this branch disabling the improve_allocation function and now it is doing a great job. For some reason the improve_allocation function only damaged the good allocation that was done. I'm sure Vlad will want to take a look at that, particularly if you've got a testcase for a target that's part of the mainline sources. The whole point of that function is to spill a set of allocnos and using the hard regs for different allocnos when it seems profitable to do so. In order to look at that I am trying to understand the conflict table: I see ;; a3(r255,l0) conflicts: a4(r243,l0) a6(r129,l0) a8(r126,l0) a9(r254,l0) a10(r256,l0) a11(r257,l0) a12(r291,w0,l0) a12(r291,w1,l0) a13(r316,w0,l0) a13(r316,w1,l0) a14(r318,w0,l0) a14(r318,w1,l0) a15(r319,w0,l0) a15(r319,w1,l0) a16(r321,w0,l0) a16(r321,w1,l0) a5(r253,l0) a7(r252,l0) a17(r261,l0) ;; total conflict hard regs: 53 ;; conflict hard regs: 53 I see here conflicts of the pseudo with other pseudos and conflict with a hard reg - all are result of live range data. Right. How is the constraint data which limits a pseudo in an insn to be of a certain class gets into this table? Constraints are generally not used to drive conflict data, but instead are to build the set of potential hard registers that can be used to satisfy a particular allocno and costing models. I have expected also all hard regs which are not allowed for this pseudo because of constraints in the insns to be also in the conflict table. I guess I miss something... If a hard register can't be used for a particular allocno, then it's wasteful (in terms of memory and compilation speed) to represent conflicts between the unusable hard reg and the allocno. If it isn't there then how is it guranteed that the pseudo would be allocated to a hard reg which is allowed by the constraints? The mental picture you should probably work with is build a union of all the registers allowed by the constraints. Those are the set of hard registers that might be assigned to an allocno. If a hard register isn't allowed by any constraint referenced by a particular allocno, then that hard register will not be part of the set of registers considered by IRA for that particular allocno. Jeff
Re: [ARM] Implementing doloop pattern
On Thu, 2010-12-30 at 18:56 +0200, Revital1 Eres wrote:
Hello,
The attached patch is my latest attempt to model doloop for arm.
I followed Chung-Lin Tang suggestion and used subs+jump similar to your
patch.
On crotex-A8 I see gain of 29% on autocor benchmark (telecom suite) with
SMS using the following flags: -fmodulo-sched-allow-regmoves
-funsafe-loop-optimizations -fmodulo-sched -fno-auto-inc-dec
-fdump-rtl-sms -mthumb -mcpu=cortex-a8 -O3. (compare to using only
-mthumb -mcpu=cortex-a8 -O3)
I have not fully tested the patch and it's not in the proper format of
submission yet.
Thanks,
Revital
(See attached file: patch_arm_doloop.txt)
From: Roman Zhuykov zhr...@ispras.ru
To: gcc@gcc.gnu.org
Cc: d...@ispras.ru
Date: 30/12/2010 04:04 PM
Subject: [ARM] Implementing doloop pattern
Sent by: gcc-ow...@gcc.gnu.org
Hello!
The main idea of the work described below was to estimate speedup we can
gain from SMS on ARM. SMS depends on doloop_end pattern and there is no
appropriate instruction on ARM. We decided to create a fake
doloop_end pattern on ARM using a pair of subs and bne assembler
instructions. In implementation we used ideas from machine description
files of other architectures, e. g. spu, which expands doloop_end
pattern only when SMS is enabled. The patch is attached.
This patch allows to use any possible register for the doloop pattern.
It was tested on trunk snapshot from 30 Aug 2010. It works fine on
several small examples, but gives an ICE on sqlite-amalgamation-3.6.1
source:
sqlite3.c: In function 'sqlite3WhereBegin':
sqlite3.c:76683:1: internal compiler error: in patch_jump_insn, at
cfgrtl.c:1020
ICE happens in ira pass, when cleanup_cfg is called at the end or ira.
The bad instruction looks like
(jump_insn 3601 628 4065 76 (parallel [
(set (pc)
(if_then_else (ne (mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 36 [0x24])) [105 %sfp+-916
S4 A32])
(const_int 1 [0x1]))
(label_ref 3600)
(pc)))
(set (mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 36 [0x24])) [105 %sfp+-916 S4 A32])
(plus:SI (mem/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 36 [0x24])) [105 %sfp+-916 S4 A32])
(const_int -1 [0x])))
]) sqlite3.c:75235 328 {doloop_end_internal}
(expr_list:REG_BR_PROB (const_int 9100 [0x238c])
(nil))
- 3600)
So, the problem seems to be with ira. Memory is used instead of a
register to store doloop counter. We tried to fix this by explicitly
specifying hard register (r5) for doloop pattern. The fixed version
seems to work, but this doesn't look like a proper fix. On trunk
snapshot from 17 Dec 2010 the ICE described above have disappeared, but
probably it's just a coincidence, and it will shop up anyway on some
other test case.
The r5-fix shows the following results (compare -O2 -fno-auto-inc-dec
-fmodulo-sched vs -O2 -fno-auto-inc-dec).
Aburto benchmarks: heapsort and matmult - 3% speedup. nsieve - 7% slowdown.
Other aburto tests, sqlite tests and libevas rasterization library
(expedite testsuite) show around zero results.
A motivating example shows about 23% speedup:
char scal (int n, char *a, char *b)
{
int i;
char s = 0;
for (i = 0; i n; i++)
s += a[i] * b[i];
return s;
}
We have analyzed SMS results, and can conclude that if SMS has
successfully built a schedule for the loop we usually gain a speedup,
and when SMS fails, we often have some slowdown, which have appeared
because of do-loop conversion.
The questions are:
How to properly fix the ICE described?
Do you think this approach (after the fixes) can make its way into trunk?
Happy holidays!
--
Roman Zhuykov
[attachment sms-doloop-any-reg.diff deleted by Revital1 Eres/Haifa/IBM]
@@ -162,6 +175,7 @@ doloop_condition_get (rtx doloop_pat)
return 0;
if ((XEXP (condition, 0) == reg)
+ || (REGNO (XEXP (condition, 0)) == CC_REGNUM)
|| (GET_CODE (XEXP (condition, 0)) == PLUS
XEXP (XEXP (condition, 0), 0) == reg))
You can't depend on CC_REGNUM in generic code. That's part of the
private machine description for ARM. Other cores have different ways of
representing condition codes.
R.
[pph] Mainline merge r168483
No merge conflicts this time. Tested on x86_64. Diego.
Re: cloog(-parma) 0.16 and ppl 0.11 in infrastructure?
On Wed, Jan 5, 2011 at 08:23, Jack Howarth howa...@bromo.med.uc.edu wrote: On Sun, Jan 02, 2011 at 04:55:09PM +0100, Richard Guenther wrote: On Fri, Dec 31, 2...@12:40 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: Sebastian, It appears that the official tarballs are now pos...@http://www.cloog.org/ for cloog and cloog-parma 0.16. Do you plan on placing those both in the infrastructure direct...@gcc.gnu.org's ftp site? If so, the newer ppl 0.11 tarball should be added as well. If those files are updated, we should be set to switch gcc trunk to require ppl = 0.11, cloog = 0.16 and the default cloog backend from legacy cloog-ppl to cloog-isl. I don't think this is a very good i...@this point. Richard, How about for gcc 4.6.1? It seems a shame to push the conversion to cloog.org in graphite to the next release. Hopefully enough of the remaining loop and vectorization issues with graphite can be ironed out by gcc 4.7 such that defaulting -fgraphite-identity for -O2 might finally be considered. I tend to agree with Richard here: what about keeping cloog-ppl as the default for gcc4.6 and let people try cloog.org 0.16.x. IMO it's just safer this way as the majority of tests we did is based on cloog-ppl, not cloog.org. Sebastian
Re: libiberty/.gitignore isn't in gcc tree
On Tuesday, January 04, 2011 13:03:59 H.J. Lu wrote: libiberty/.gitignore was added to src. But it isn't in gcc tree. i dont have access to the gcc tree, so i can only post patches. if someone were to grant me access, i obviously wouldnt have a problem making the commit. otherwise someone else needs to merge my patch i sent out. -mike signature.asc Description: This is a digitally signed message part.
Re: RFC: Add 32bit x86-64 support to binutils
On 30 December 2010 18:23, H.J. Lu wrote:
This patch adds 32bit x86-64 support to binutils. Support in compiler,
library and OS is required to use it. It can be used to implement the
new 32bit OS for x86-64. Any comments?
I have a small comment on the changes to the c-i386.texi docs:
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 1c6175b..c3956a8 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -56,11 +56,14 @@ dependent options:
@table @gcctabopt
@cindex @samp{--32} option, i386
@cindex @samp{--32} option, x86-64
+...@cindex @samp{--n32} option, i386
+...@cindex @samp{--n32} option, x86-64
@cindex @samp{--64} option, i386
@cindex @samp{--64} option, x86-64
-...@item --32 | --64
+...@item --32 | --n32 | --64
Select the word size, either 32 bits or 64 bits. Selecting 32-bit
implies Intel i386 architecture, while 64-bit implies AMD x86-64
+architecture. @samp{--n32} selects 32bit word size with AMD x86-64
architecture.
Simply adding the new sentence at the end is not very clear, because
the last sentence contradicts the second sentence: --n32 selects
32-bit word size, but does not imply Intel i386 architecture.
Also, 32bit and 32-bit should be used consistently.
How about:
Select the word size, either 32 bits or 64 bits. @samp{--32}
implies Intel i386 architecture, while @samp{--n32} and @samp{--64}
imply AMD x86-64 architecture with 32-bit or 64-bit word-size
respectively.
Re: RFC: Add 32bit x86-64 support to binutils
On Wed, Jan 5, 2011 at 11:52 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 30 December 2010 18:23, H.J. Lu wrote:
This patch adds 32bit x86-64 support to binutils. Support in compiler,
library and OS is required to use it. It can be used to implement the
new 32bit OS for x86-64. Any comments?
I have a small comment on the changes to the c-i386.texi docs:
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 1c6175b..c3956a8 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -56,11 +56,14 @@ dependent options:
�...@table @gcctabopt
�...@cindex @samp{--32} option, i386
�...@cindex @samp{--32} option, x86-64
+...@cindex @samp{--n32} option, i386
+...@cindex @samp{--n32} option, x86-64
�...@cindex @samp{--64} option, i386
�...@cindex @samp{--64} option, x86-64
-...@item --32 | --64
+...@item --32 | --n32 | --64
Select the word size, either 32 bits or 64 bits. Selecting 32-bit
implies Intel i386 architecture, while 64-bit implies AMD x86-64
+architecture. �...@samp{--n32} selects 32bit word size with AMD x86-64
architecture.
Simply adding the new sentence at the end is not very clear, because
the last sentence contradicts the second sentence: --n32 selects
32-bit word size, but does not imply Intel i386 architecture.
Also, 32bit and 32-bit should be used consistently.
How about:
Select the word size, either 32 bits or 64 bits. @samp{--32}
implies Intel i386 architecture, while @samp{--n32} and @samp{--64}
imply AMD x86-64 architecture with 32-bit or 64-bit word-size
respectively.
Thanks. I checked it in.
--
H.J.
---
Index: ChangeLog
===
RCS file: /cvs/src/src/gas/ChangeLog,v
retrieving revision 1.4376
diff -u -p -r1.4376 ChangeLog
--- ChangeLog 5 Jan 2011 00:16:49 - 1.4376
+++ ChangeLog 5 Jan 2011 21:34:34 -
@@ -1,3 +1,7 @@
+2011-01-05 Jonathan Wakely jwakely@gmail.com
+
+ * doc/c-i386.texi: Clarify --n32.
+
2011-01-04 H.J. Lu hongjiu...@intel.com
* config/tc-i386.c (build_modrm_byte): Allow encoding 32/64bit
Index: doc/c-i386.texi
===
RCS file: /cvs/src/src/gas/doc/c-i386.texi,v
retrieving revision 1.53
diff -u -p -r1.53 c-i386.texi
--- doc/c-i386.texi 31 Dec 2010 00:33:34 - 1.53
+++ doc/c-i386.texi 5 Jan 2011 21:34:34 -
@@ -61,10 +61,10 @@ dependent options:
@cindex @samp{--64} option, i386
@cindex @samp{--64} option, x86-64
@item --32 | --n32 | --64
-Select the word size, either 32 bits or 64 bits. Selecting 32-bit
-implies Intel i386 architecture, while 64-bit implies AMD x86-64
-architecture. @samp{--n32} selects 32bit word size with AMD x86-64
-architecture.
+Select the word size, either 32 bits or 64 bits. @samp{--32}
+implies Intel i386 architecture, while @samp{--n32} and @samp{--64}
+imply AMD x86-64 architecture with 32-bit or 64-bit word-size
+respectively.
These options are only available with the ELF object file format, and
require that the necessary BFD support has been included (on a 32-bit
RE: call for libstdc++ profile mode diagnostic ideas
Your first example points to a weakness in the compiler optimization.
If base_string constructor is inlined, the compiler should be able to
figure out both 'name' and the heap memory it points to can not be
modified by the call to notify, and therefore hoist access name.c_str
() and name.length () out of the loop. Even without inlining, with
more powerful modeling of standard function side effect (e.g.,
base_string ctor does not expose name's address), the same
optimization should be performed.
You're right, 4.5.1 and current trunk appear to correctly hoist those accesses
out of the loop.
It would still be useful for codebases that are built using different compilers
that don't have this kind of optimization, though.
Example:
#include string
#include cstdio
void notify(const char* printable) { printf(%s\n, printable); }
int main(void)
{
std::string name(bob);
for (int i = 0; i name.length(); i++)
{
notify(name.c_str());
}
return 0;
}
Re: [ARM] Implementing doloop pattern
Hello,
@@ -162,6 +175,7 @@ doloop_condition_get (rtx doloop_pat)
return 0;
if ((XEXP (condition, 0) == reg)
+ || (REGNO (XEXP (condition, 0)) == CC_REGNUM)
|| (GET_CODE (XEXP (condition, 0)) == PLUS
XEXP (XEXP (condition, 0), 0) == reg))
You can't depend on CC_REGNUM in generic code. That's part of the
private machine description for ARM. Other cores have different ways of
representing condition codes.
R.
Yes, thanks, I found that out when testing the patch on PowerPC.
Attached is a newer version of the patch which is currently
under testing.
Thanks,
Revital
(See attached file: patch_arm_doloop_5.txt)Index: modulo-sched.c
===
--- modulo-sched.c (revision 168397)
+++ modulo-sched.c (working copy)
@@ -1021,7 +1021,8 @@ sms_schedule (void)
if (CALL_P (insn)
|| BARRIER_P (insn)
|| (NONDEBUG_INSN_P (insn) !JUMP_P (insn)
- !single_set (insn) GET_CODE (PATTERN (insn)) != USE)
+ !single_set (insn) GET_CODE (PATTERN (insn)) != USE
+ !reg_mentioned_p (count_reg, insn))
|| (FIND_REG_INC_NOTE (insn, NULL_RTX) != 0)
|| (INSN_P (insn) (set = single_set (insn))
GET_CODE (SET_DEST (set)) == SUBREG))
Index: loop-doloop.c
===
--- loop-doloop.c (revision 168397)
+++ loop-doloop.c (working copy)
@@ -78,6 +78,8 @@ doloop_condition_get (rtx doloop_pat)
rtx inc_src;
rtx condition;
rtx pattern;
+ rtx cc_reg = NULL_RTX;
+ rtx reg_orig;
/* The canonical doloop pattern we expect has one of the following
forms:
@@ -96,7 +98,16 @@ doloop_condition_get (rtx doloop_pat)
2) (set (reg) (plus (reg) (const_int -1))
(set (pc) (if_then_else (reg != 0)
(label_ref (label))
-(pc))). */
+(pc))).
+
+ Some targets (ARM) do the comparison before the branch, as in the
+ folloring form:
+
+ 3) (parallel [(set (cc) (compare ((plus (reg) (const_int -1), 0)))
+ (set (reg) (plus (reg) (const_int -1)))])
+(set (pc) (if_then_else (NE == cc)
+(label_ref (label))
+(pc))) */
pattern = PATTERN (doloop_pat);
@@ -104,14 +115,42 @@ doloop_condition_get (rtx doloop_pat)
{
rtx cond;
rtx prev_insn = prev_nondebug_insn (doloop_pat);
+ rtx src_orig;
+ rtx cmp_orig;
- /* We expect the decrement to immediately precede the branch. */
+ /* In case the pattern is not PARALLEL we expect two forms
+of doloop which are cases 2) and 3) above: in case 2) the
+decrement is immediately precedes the branch. while in case
+3) the compre and decrement instructions immediately precede
+the branch. */
if (prev_insn == NULL_RTX || !INSN_P (prev_insn))
return 0;
cmp = pattern;
- inc = PATTERN (PREV_INSN (doloop_pat));
+ if (GET_CODE (PATTERN (prev_insn)) == PARALLEL)
+{
+ /* The third case: the compre and decrement instructions
+immediately precede the branch. */
+ cmp_orig = XVECEXP (PATTERN (prev_insn), 0, 0);
+ if (GET_CODE (cmp_orig) != SET)
+ return 0;
+ if (GET_CODE (SET_SRC (cmp_orig)) != COMPARE)
+ return 0;
+ src_orig = XEXP (SET_SRC (cmp_orig), 0);
+ if (XEXP (SET_SRC (cmp_orig), 1) != const0_rtx
+ || GET_CODE (src_orig) != PLUS)
+ return 0;
+ reg_orig = XEXP (src_orig, 0);
+ if (XEXP (src_orig, 1) != GEN_INT (-1)
+ || !REG_P (reg_orig))
+ return 0;
+ cc_reg = SET_DEST (cmp_orig);
+
+ inc = XVECEXP (PATTERN (prev_insn), 0, 1);
+ }
+ else
+inc = PATTERN (PREV_INSN (doloop_pat));
/* We expect the condition to be of the form (reg != 0) */
cond = XEXP (SET_SRC (cmp), 0);
if (GET_CODE (cond) != NE || XEXP (cond, 1) != const0_rtx)
@@ -162,6 +201,9 @@ doloop_condition_get (rtx doloop_pat)
return 0;
if ((XEXP (condition, 0) == reg)
+ || ((cc_reg != NULL_RTX)
+ (XEXP (condition, 0) == cc_reg)
+ (reg_orig == reg))
|| (GET_CODE (XEXP (condition, 0)) == PLUS
XEXP (XEXP (condition, 0), 0) == reg))
{
@@ -181,7 +223,24 @@ doloop_condition_get (rtx doloop_pat)
(set (reg) (plus (reg) (const_int -1)))
(additional clobbers and uses)])
- So we return that form instead.
+For the third form we expect:
+
+(parallel [(set (cc) (compare ((plus (reg) (const_int -1)), 0))
+ (set (reg) (plus (reg) (const_int -1)))])
+(set (pc) (if_then_else (NE
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug rtl-optimization/47166] [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166
--- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-01-05
08:21:11 UTC ---
(In reply to comment #4)
(In reply to comment #0)
(insn 3163 3161 3164 107 rectmm.c:1041 (set (reg:SI 1 r1)
(plus:SI (reg:SI 1 r1)
(const_int 280 [0x118]))) 4 {*arm_addsi3} (nil))
Please consider my request in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45051#c8.
I mean, the But r1 is an input as well as an output , i.e. referred to, so
insn 3163 should have matched without your patch. I'm missing analysis on why
that didn't happen part.
[Bug fortran/47174] New: libquadmath: Build now depends on makeinfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47174 Summary: libquadmath: Build now depends on makeinfo Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org http://gcc.gnu.org/ml/fortran/2011-01/msg00012.html libquadmath now fails to build if makeinfo isn't installed on the system: [...] WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[3]: *** [libquadmath.info] Error 1 There is apparently a dependency on libquadmath.info via INFO_DEPS: INFO_DEPS = libquadmath.info In what way is that different from, say, libgomp? IIUC makeinfo is required for the development tree. libgomp doesn't fail to build in this configuration. In fact, all components used to build in this configuration (except maybe libjava) up to the patch.
[Bug fortran/46520] [4.6 Regression] libquadmath: fails at link test on bare irons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 08:57:59 UTC --- (In reply to comment #8) Tobias, anything left here or can this report be closed? I was just told for picochip-unknown-none: I just tried a build and libquadmath works fine. I had to disable libiberty, though. Thus, I close this PR as FIXED. If someone still has problems, please report them and either re-open this PR or fill a new PR (and CC me).
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 --- Comment #7 from janus at gcc dot gnu.org 2011-01-05 09:05:48 UTC --- Author: janus Date: Wed Jan 5 09:05:44 2011 New Revision: 168505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168505 Log: 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47024 * trans-decl.c (gfc_trans_deferred_vars): Initialize the _vpr component of polymorphic allocatables according to their declared type. 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47024 * gfortran.dg/storage_size_3.f08: New. Added: trunk/gcc/testsuite/gfortran.dg/storage_size_3.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/47024] [OOP] STORAGE_SIZE (for polymorphic types): Segfault at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47024 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from janus at gcc dot gnu.org 2011-01-05 09:17:25 UTC --- Fixed with r168505. Closing.
[Bug fortran/46262] [OOP] tree check: expected function_type or method_type, have pointer_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46262 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6 Regression] [OOP] tree |[OOP] tree check: expected |check: expected |function_type or |function_type or|method_type, have |method_type, have |pointer_type |pointer_type| --- Comment #9 from janus at gcc dot gnu.org 2011-01-05 09:33:56 UTC --- (In reply to comment #1) -fdump-tree-original shows wrong code being generated: struct class$integrable_model_a T3f8 (struct class$integrable_model restrict) D.1529; static real(kind=4) C.1528 = 2.0e+0; struct class$integrable_model_a D.1527; D.1527 = d_dt ((struct class$integrable_model *) model); D.1529 = d_dt (D.1527, C.1528); _gfortran_transfer_real_write (dt_parm.0, D.1529, 4); The second call to d_dt should actually be a call to D.1527-$vptr-multiply. Note that 4.5 also produces wrong code here: real(kind=4) D.1560; static real(kind=4) C.1559 = 2.0e+0; struct .class.integrable_model.a D.1558; D.1558 = d_dt ((struct .class.integrable_model *) model); D.1560 = multiply (D.1558, C.1559); _gfortran_transfer_real (dt_parm.0, D.1560, 4); It has a static call to 'multiply', instead of a polymorphic call via the vptr. So, since 4.5 also does not handle the test case correctly, I think it's fair to remove the regression tag. In a way one could even argue that the ICE in 4.6 is an improvement over 4.5 silently giving wrong results for such cases, since the user does at least get *some* error message (even though a crude and uninformative one), instead of assuming the feature was supported and getting wrong results in the end!
[Bug fortran/46017] Reject ALLOCATE(a, a%b) as a%b depends on the allocation status of a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46017 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-05 10:03:18 UTC --- Author: tkoenig Date: Wed Jan 5 10:03:15 2011 New Revision: 168506 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168506 Log: 2011-01-05 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/46017 * resolve.c (resolve_allocate_deallocate): Follow references to check for duplicate occurence of allocation/deallocation objects. 2011-01-05 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/46017 * gfortran.dg/allocate_error_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_error_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with cannot check for file existence when cross compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-05 10:07:40 UTC --- (In reply to comment #18) This xml catalog testing passed on Debian and RHEL: echo 'article/' | xsltproc --noout --nonet \ http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl - We use the xsl-ns stylesheets for Docbook 5 support and I think xsl-ns is less widely-installed than the older stylesheets. We also generate xhtml 1.1 so a better test would be http://docbook.sourceforge.net/release/xsl-ns/current/xhtml-1_1/docbook.xsl
[Bug fortran/47175] New: no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 Summary: no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jan.raub...@gmx.de Matlab and probably other software uses the predefined macros to check for the current platform to enable long pointer or not. I have found that the macros above are no more in gfortran 4.4 and higher. The only way to check for the right platform is the __LP64__ macro which seems not to be used on other compiles like sunf90. It takes me some hours to find why a Matlab mex file crashes immediately after calling. Whith gcc these macros are available, why not whith gfortran? Jan
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 11:23:43 UTC --- Author: ebotcazou Date: Wed Jan 5 11:23:40 2011 New Revision: 168508 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168508 Log: PR tree-optimization/47005 * tree-sra.c (struct access): Add 'non_addressable' bit. (create_access): Set it for a DECL_NONADDRESSABLE_P field. (decide_one_param_reduction): Return 0 if the parameter is passed by reference and one of the accesses in the group is non_addressable. Added: trunk/gcc/testsuite/gnat.dg/opt14.adb Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 11:26:29 UTC --- Done.
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with cannot check for file existence when cross compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.05 11:46:14 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with cannot check for file existence when cross compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 --- Comment #20 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-05 11:50:08 UTC --- Note: somebody should now change the subject to something more meaningful, about hard coded paths and such, because the original P1 issue is resolved.
[Bug go/47176] New: libgo doesn't compile if libunicode is installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47176 Summary: libgo doesn't compile if libunicode is installed Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: b...@arklinux.org Trying to build gcc with go support on a system that has libunicode (http://libunicode.sf.net/) installed results in libtool: compile: /usr/src/ark/BUILD/gcc-4.6.0/build/./gcc/gccgo -B/usr/src/ark/BUILD/gcc-4.6.0/build/./gcc/ -B/usr/x86_64-unknown-linux-gnu/bin/ -B/usr/x86_64-unknown-linux-gnu/lib/ -isystem /usr/x86_64-unknown-linux-gnu/include -isystem /usr/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -g -c -fgo-prefix=libgo_bytes ../../../libgo/go/bytes/buffer.go ../../../libgo/go/bytes/bytes.go ../../../libgo/go/bytes/bytes_decl.go -fPIC -o bytes/.libs/bytes.o ../../../libgo/go/bytes/bytes.go:10:9: error: /usr/lib/../lib64/libunicode.so exists but does not contain any Go export data make[4]: *** [bytes/libbytes.a] Error 1 The problem is that the libgo build process sees the system libunicode.so which has nothing to do with go before seeing the go libunicode it built before.
[Bug fortran/41580] [OOP] SAME_TYPE_AS and EXTENDS_TYPE_OF - add compile-time simplifcation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41580 --- Comment #4 from janus at gcc dot gnu.org 2011-01-05 12:16:33 UTC --- (In reply to comment #2) For SAME_TYPE_AS and EXTENDS_TYPE_OF one should add a compile-time simplification to simplify.c. Currently, only the run-time version is implemented. Well, currently the translation of SAME_TYPE_AS is done by gfc_conv_same_type_as (trans-intrinsic.c), for both TYPE- and CLASS-valued arguments. Note: If both arguments are TYPE-valued, the result will be a compile-time constant, otherwise it has to be evaluated at runtime, according to the _hash values in the vtabs. In which situations would we actually gain something by treating the TYPE-TYPE case in simplify.c?
[Bug fortran/47177] New: bad example of using -dM in manual
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47177 Summary: bad example of using -dM in manual Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: documentation Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org http://gcc.gnu.org/onlinedocs/gfortran/Preprocessing-Options.html gives an example of using -dM: touch foo.f90; gfortran -cpp -dM foo.f90 But the CPP documentation for -dM at http://gcc.gnu.org/onlinedocs/cpp/Invocation.html#index-dM-183 points out that without -E it will be interpreted as a synonym for -fdump-rtl-mach To print the predefined macros the example should be changed to touch foo.f90; gfortran -cpp -E -dM foo.f90
[Bug libstdc++/47145] configure test for docbook-xsl-ns stylesheets uses hardcoded path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6 Regression]|configure test for |cross-compilation fails |docbook-xsl-ns stylesheets |with cannot check for file |uses hardcoded path |existence when cross| |compiling | --- Comment #21 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-05 12:22:09 UTC --- summary changed
[Bug target/47178] New: QtWebKit miscompiled for x86_64-*-mingw*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47178 Summary: QtWebKit miscompiled for x86_64-*-mingw* Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com The 64-bit runtime provided by the mingw-w64 project together with the GCC toolchain can compile Qt completely (with no known issues as far as I know) with GCC 4.4 (earlier versions don't have the necessary support for x64 Windows). Only with GCC 4.5 and 4.6, issues arise in the form of runtime errors when QtWebKit is compiled for x86_64-w64-mingw32. I have created a WebKit bug report here: https://bugs.webkit.org/show_bug.cgi?id=44052 The report has a stack backtrace of a Qt application (Assistant) showing the crash. All binaries are compiled with -g3 (highest debug level). Optimization level (none or -O2) does not change the fact that the app crashes. Looking at the backtrace, the problem is in WebKit somewhere, but as no other platforms show this problem, the issue must be toolchain-side somewhere. A correct binary is produced using patched (for Win64) 4.4 GCC toolchains.
[Bug tree-optimization/47179] New: [4.5/4.6 Regression] SPU: errno misoptimization around malloc call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47179 Summary: [4.5/4.6 Regression] SPU: errno misoptimization around malloc call Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: uweig...@gcc.gnu.org CC: rguent...@suse.de Target: spu-elf The problem described in PR 42944 is still present on SPU. This is because the SPU system library (newlib) uses: extern struct _reent _impure_data; #define errno (_impure_data._errno) in its version of errno.h, but GCC's call_may_clobber_ref_p_1 routine assumes errno is always either a global or else accessed via a pointer. It does not handle component references. (Note that the problem seems to be specific to the SPU, because of an optimization that makes use of the fact that SPU code is always single-threaded. On other platforms, newlib accesses errno via a pointer as well.)
[Bug c/47150] [4.5/4.6 Regression] ICE in gimplify_expr at gimplify.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-05 13:31:07 UTC --- Created attachment 22903 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22903 gcc46-pr47150.patch Untested fix.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||jason at redhat dot com, ||mark at codesourcery dot ||com --- Comment #21 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-05 13:36:37 UTC --- I am re-building now. Martin's edge cgraph_opt streaming fix is needed and flag_shlib needs to be set in lto-options.c With this fixed oprofile shows that cc1plus spends a lot of time in lookup_filed_1. 40259 5.6000 cc1plus cc1plus lookup_field_1 20275 2.8203 cc1plus cc1plus longest_match 15843 2.2038 libc-2.11.1.so libc-2.11.1.so _int_malloc 12409 1.7261 libc-2.11.1.so libc-2.11.1.so memset 10680 1.4856 cc1plus cc1plus htab_find_slot_with_hash 10471 1.4565 libc-2.11.1.so libc-2.11.1.so vfprintf 9004 1.2525 cc1plus cc1plus deflate_slow 8580 1.1935 cc1plus cc1plus ggc_internal_alloc_stat 8300 1.1545 libc-2.11.1.so libc-2.11.1.so memcpy 8100 1.1267 cc1plus cc1plus ht_lookup_with_hash 8044 1.1189 libpython2.6.so.1.0 libpython2.6.so.1.0 /usr/lib64/libpython2.6.so.1.0 7840 1.0905 cc1plus cc1plus _cpp_lex_direct 6340 0.8819 cc1plus cc1plus pointer_set_insert I am adding c++ maintainers to CC as this seems like relatively low hanging fruit for noticeable compilation speedup? It tends to show in oprofile as 5-7% of compile time.
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-01-05 13:41:57 UTC --- Checking __amd64, __amd64__, __x86_64 __x86_64__ for pointer size is wrong since pointer size may be 32bit on x86-64. Checking __LP64__ is correct.
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #11 from John Marino gnugcc at marino dot st 2011-01-05 13:49:47 UTC --- I rebuilt OpenBSD i386 using then Jan 5 daily bump (SVN 168495) and patched it with tree-src.c file. ACATS 62002a now passes, thanks.
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 13:54:30 UTC --- ACATS 62002a now passes, thanks. Thanks for confirming. ACATS is clean on both i386 and i586 Linux SJLJ now, are there any remaining failures on BSD platforms?
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 --- Comment #2 from Jan jan.rauberg at gmx dot de 2011-01-05 14:00:43 UTC --- (In reply to comment #1) Checking __amd64, __amd64__, __x86_64 __x86_64__ for pointer size is wrong since pointer size may be 32bit on x86-64. No, it can't be. The macros are set in dependence of the target platform (m32 or m64). That means, if m32 is given the macro __i686 is set instead of __amd64. On the other hand, if m64 is given the macro __amd64 is set. I don't want to know the really underlying platform. I (or Matlab) want to know the target platform. So it is right to check the __amd64 macro. You can try it with the gcc-4.4. Only with gfortran-4.4 the macro is missed. Checking __LP64__ is correct. Yes maybe, but this is not the default way (by Matlab and other tools) Jan
[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45989 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-05 14:02:15 UTC --- Did somebody test the patch in comment #3?
[Bug go/47176] libgo doesn't compile if libunicode is installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47176 --- Comment #1 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2011-01-05 14:12:41 UTC --- Author: ian Date: Wed Jan 5 14:12:37 2011 New Revision: 168512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168512 Log: PR go/47176 byte/libbytes.a depends on unicode.gox. Modified: trunk/libgo/Makefile.am trunk/libgo/Makefile.in
[Bug go/47176] libgo doesn't compile if libunicode is installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47176 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Ian Lance Taylor ian at airs dot com 2011-01-05 14:13:20 UTC --- There was a missing dependency in libgo/Makefile.am. This should be fixed now. Let me know if not. Thanks for reporting it.
[Bug fortran/47180] New: [OOP] EXTENDS_TYPE_OF returns the wrong result if the polymorphic variable is unallocated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 Summary: [OOP] EXTENDS_TYPE_OF returns the wrong result if the polymorphic variable is unallocated Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Found when looking at PR 41580. The following program should print 6 times T but it prints trice F followed by trice T. From Fortran 2008: 13.7.60 EXTENDS_TYPE_OF (A, MOLD) Result Value. [unlimited polymorphic] ; otherwise if the dynamic type of A or MOLD is extensible, the result is true if and only if the dynamic type of A is an extension type of the dynamic type of MOLD; otherwise the result is processor dependent. NOTE 13.12 The dynamic type of a disassociated pointer or unallocated allocatable variable is its declared type. (NAG 5.1 ICEs and ifort prints the same result as gfortran; nevertheless, I expect that the code is correct, which is in line with NOTE 13.12.) implicit none type t1 integer :: a end type t1 type, extends(t1):: t11 integer :: b end type t11 type(t1) a1 type(t11) a11 class(t1), allocatable :: b1 class(t11), allocatable :: b11 print *, extends_type_of(b1,a1) ! T - currently, gfortran prints F print *, extends_type_of(b11,a1) ! T - currently, gfortran prints F print *, extends_type_of(b11,a11) ! T - currently, gfortran prints F allocate(t1 :: b1) allocate(t11 :: b11) print *, extends_type_of(b1,a1) ! T print *, extends_type_of(b11,a1) ! T print *, extends_type_of(b11,a11) ! T end
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-01-05 14:28:51 UTC --- (In reply to comment #2) (In reply to comment #1) Checking __amd64, __amd64__, __x86_64 __x86_64__ for pointer size is wrong since pointer size may be 32bit on x86-64. No, it can't be. The macros are set in dependence of the target platform (m32 or m64). That means, if m32 is given the macro __i686 is set instead of __amd64. On the other hand, if m64 is given the macro __amd64 is set. I don't want to know the really underlying platform. I (or Matlab) want to know the target platform. So it is right to check the __amd64 macro. You can try it with the gcc-4.4. Only with gfortran-4.4 the macro is missed. See http://www.kernel.org/pub/linux/devel/binutils/ilp32/abi.pdf where pointer size is 32bit.
[Bug fortran/46402] libquadmath: Add fmalq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46402 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2011.01.05 14:37:05 Resolution|DUPLICATE | Ever Confirmed|0 |1 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 14:37:05 UTC --- Reopen as this is only about porting existing code and not starting from scratch.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result if the polymorphic variable is unallocated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #1 from janus at gcc dot gnu.org 2011-01-05 14:37:26 UTC --- (In reply to comment #0) Found when looking at PR 41580. The following program should print 6 times T but it prints trice F followed by trice T. Actually it does print six time T for me! Are you sure your trunk is up to date? Note that r168505 is crucial here, which is the fix for PR47024 that I just committed a few hours ago, and which fixes this very issue ...
[Bug rtl-optimization/47166] [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #6 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-05 14:38:42 UTC --- I mean, the But r1 is an input as well as an output , i.e. referred to, so insn 3163 should have matched without your patch. I'm missing analysis on why that didn't happen part. OK, I will do more analysis to try to determine what's going on.
[Bug other/47167] Performance regression in numerical code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167 --- Comment #1 from Martin Reinecke mar...@mpa-garching.mpg.de 2011-01-05 14:42:20 UTC --- Created attachment 22904 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22904 shorter test case More compact test case; the hot spot is marked with CRITICAL LOOP. Compile with gcc -O2 -fomit-frame-pointer testcase2.c -lm and test using time ./a.out.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result if the polymorphic variable is unallocated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 14:46:29 UTC --- (In reply to comment #1) Actually it does print six time T for me! Are you sure your trunk is up to date? Note that r168505 is crucial here, which is the fix for PR47024 that I just committed a few hours ago, and which fixes this very issue ... I think that my vanilla trunk is then not sufficiently up to date; I have another build which contains your patch - but also a draft patch for PR 41580 and is thus not reliably. Thus, I believe your result: Close as FIXED.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 janus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2011.01.05 14:48:38 Resolution|FIXED | Summary|[OOP] EXTENDS_TYPE_OF |[OOP] EXTENDS_TYPE_OF |returns the wrong result if |returns the wrong result |the polymorphic variable is |for disassociated |unallocated |polymorphic pointers Ever Confirmed|0 |1 --- Comment #3 from janus at gcc dot gnu.org 2011-01-05 14:48:38 UTC --- (In reply to comment #1) Note that r168505 is crucial here, which is the fix for PR47024 that I just committed a few hours ago, and which fixes this very issue ... Anyway r168505 only fixed the issue for allocatables, not pointers! Therefore the following variant indeed still gives the wrong output: implicit none type t1 integer :: a end type t1 type, extends(t1):: t11 integer :: b end type t11 type(t1), target :: a1 type(t11), target :: a11 class(t1), pointer :: b1 class(t11), pointer :: b11 b1 = NULL() b11 = NULL() print *, extends_type_of(b1,a1) ! T - currently, gfortran prints F print *, extends_type_of(b11,a1) ! T - currently, gfortran prints F print *, extends_type_of(b11,a11) ! T - currently, gfortran prints F b1 = a1 b11 = a11 print *, extends_type_of(b1,a1) ! T print *, extends_type_of(b11,a1) ! T print *, extends_type_of(b11,a11) ! T end
[Bug lto/47162] [4.6 Regression] LTO is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47162 --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-01-05 14:55:32 UTC --- Author: hjl Date: Wed Jan 5 14:55:27 2011 New Revision: 168515 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168515 Log: Fix PR lto/47162. 2011-01-05 Martin Jambor mjam...@suse.cz PR lto/47162 * lto-cgraph.c (output_cgraph_opt_summary_p): Also check for thunk deltas on streamed outgoing edges. (output_node_opt_summary): Output info for outgoing edges only when the node is in new parameter set. (output_cgraph_opt_summary): New parameter set, passed to the two aforementioned functions. Update its forward declaration and its callee too. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-cgraph.c
[Bug lto/47181] New: memops-asm testcase fails with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47181 Summary: memops-asm testcase fails with -flto -fuse-linker-plugin Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org memops-asm testcase fails with -flto -fuse-linker-plugin. We produce undefined call to my_memcpy: evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# ./xgcc -B ./ -O2 memops-asm*.c /abuild/jh/trunk-3/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -g -O0 -flto --save-temps -fdump-ipa-all-details-save-temps memops-asm.c: In function ?main_test?: memops-asm.c:37:3: warning: incompatible implicit declaration of built-in function ?printf? [enabled by default] [Leaving LTRANS /tmp/ccrBB4II.args] [Leaving LTRANS /tmp/ccc7Rjx0.ltrans.out] [Leaving LTRANS /tmp/ccOzcZ98.args] [Leaving LTRANS /tmp/ccc7Rjx0.ltrans0.o] evans:/abuild/jh/trunk-3/build-inst2/gcc/:[0]# grep memcpy *.s ccc7Rjx0.ltrans0.s: .globl memcpy ccc7Rjx0.ltrans0.s: .type memcpy, @function ccc7Rjx0.ltrans0.s:memcpy: ccc7Rjx0.ltrans0.s: callmy_memcpy.2055 ccc7Rjx0.ltrans0.s: .size memcpy, .-memcpy ccc7Rjx0.ltrans0.s: .type my_memcpy.2055, @function ccc7Rjx0.ltrans0.s:my_memcpy.2055: ccc7Rjx0.ltrans0.s: .size my_memcpy.2055, .-my_memcpy.2055 ccc7Rjx0.ltrans0.s: callmy_memcpy ccc7Rjx0.ltrans0.s: callmy_memcpy ccc7Rjx0.ltrans0.s: .string memcpy ccc7Rjx0.ltrans0.s: .string my_memcpy the issue is that my_memcpy is declared once as: extern void *memcpy (void *, const void *, size_t) __asm (ASMNAME (my_memcpy)); and in the other unit as void * my_memcpy (void *d, const void *s, size_t n) we fail to merge the declarations in lto-symtab since builtins are streamed in special way. This leads to linker bug and wrong code: http://sourceware.org/bugzilla/show_bug.cgi?id=12365
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #4 from janus at gcc dot gnu.org 2011-01-05 15:08:09 UTC ---
Draft patch:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 168504)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -6121,25 +6121,24 @@ gfc_trans_class_assign (gfc_expr *expr1, gfc_expr
if (expr2-ts.type != BT_CLASS)
{
/* Insert an additional assignment which sets the '_vptr' field. */
+ gfc_symbol *vtab;
+ gfc_symtree *st;
+
lhs = gfc_copy_expr (expr1);
gfc_add_vptr_component (lhs);
+
if (expr2-ts.type == BT_DERIVED)
-{
- gfc_symbol *vtab;
- gfc_symtree *st;
- vtab = gfc_find_derived_vtab (expr2-ts.u.derived);
- gcc_assert (vtab);
- rhs = gfc_get_expr ();
- rhs-expr_type = EXPR_VARIABLE;
- gfc_find_sym_tree (vtab-name, vtab-ns, 1, st);
- rhs-symtree = st;
- rhs-ts = vtab-ts;
-}
+vtab = gfc_find_derived_vtab (expr2-ts.u.derived);
else if (expr2-expr_type == EXPR_NULL)
-rhs = gfc_get_int_expr (gfc_default_integer_kind, NULL, 0);
- else
-gcc_unreachable ();
+vtab = gfc_find_derived_vtab (expr1-ts.u.derived);
+ gcc_assert (vtab);
+ rhs = gfc_get_expr ();
+ rhs-expr_type = EXPR_VARIABLE;
+ gfc_find_sym_tree (vtab-name, vtab-ns, 1, st);
+ rhs-symtree = st;
+ rhs-ts = vtab-ts;
+
tmp = gfc_trans_pointer_assignment (lhs, rhs);
gfc_add_expr_to_block (block, tmp);
Will commit as obvious after regtesting.
[Bug fortran/47182] New: libquadmath.texi: undefined flag: BUGURL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47182
Summary: libquadmath.texi: undefined flag: BUGURL
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
./libquadmath/libquadmath.texi uses:
Bugs in the GCC Quad-Precision Math Library implementation should be
reported via @value{BUGURL}.
But BUGURL is never set. For ./gcc/ one passes the value via configure:
ACX_BUGURL([http://gcc.gnu.org/bugs.html])
However, such an entry is missing from libquadmath/configure.ac.
(The macro is defined at ./config/acx.m4)
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 --- Comment #4 from Jan jan.rauberg at gmx dot de 2011-01-05 15:13:23 UTC --- (In reply to comment #3) (In reply to comment #2) (In reply to comment #1) Checking __amd64, __amd64__, __x86_64 __x86_64__ for pointer size is wrong since pointer size may be 32bit on x86-64. No, it can't be. The macros are set in dependence of the target platform (m32 or m64). That means, if m32 is given the macro __i686 is set instead of __amd64. On the other hand, if m64 is given the macro __amd64 is set. I don't want to know the really underlying platform. I (or Matlab) want to know the target platform. So it is right to check the __amd64 macro. You can try it with the gcc-4.4. Only with gfortran-4.4 the macro is missed. See http://www.kernel.org/pub/linux/devel/binutils/ilp32/abi.pdf where pointer size is 32bit. As far as I understood means ILP32 a 32bit application in a 64bit environment and LP64 a 64bit application in 64bit environment. Am I Right? The predefined preprocessor macro __amd64 is true if I compile with -m64 (default on Linux) and it is not true if I compile with -m32. So why I can't check against this macro, as far it is supported (as in gcc)? Please correct me if I'm totally wrong. Or do you want to tell me that a 64bit application could use 32bit pointers, or the other way round? If so, how is it possible? Jan
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #13 from John Marino gnugcc at marino dot st 2011-01-05 15:14:36 UTC --- (In reply to comment #12) Thanks for confirming. ACATS is clean on both i386 and i586 Linux SJLJ now, are there any remaining failures on BSD platforms? There are no ACATS or gnat.dg failures on the ZCX platforms (FreeBSD, DragonFlyBSD, NetBSD: i386 and x86_64) The regression tests just completed for OpenBSD i386. There is one failure on ACATS (cb1010a timeout)* Between yesterday and today, the test sse_nolib result went from passing to UNSUPPORTED Comments: 1) Between yesterday and today, test c390001 wouldn't even compile, but now it passes. 2)* I haven't investigated cb1010a timeout yet, but I think the problem is with OpenBSD, not gnat 3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD. I was expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail. 4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro is ignored), the null_deref and stack_check gnat.dg tests pass. in gdb, the segfault comes and then the program just exits normally. 5) I don't know if the behavior of 3) and 4) is normal for an SJLJ target, or if it's because apparently there's some missing support on OpenBSD for DWARF2 (if I try to set OpenBSD32 to ZCX handling the compile breaks with the unwind_context structure considered illegal), and commit commits also indicate something is missing for OpenBSD. The summary is that the OpenBSD port is currently better then it has ever been, and one remaining ACATS failure is probably related to how OpenBSD handles their stack. As of today, I don't have any errors to report, but that may change as I discover more about the issues I just outlined above.
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-01-05 15:17:50 UTC --- (In reply to comment #4) (In reply to comment #3) (In reply to comment #2) (In reply to comment #1) Checking __amd64, __amd64__, __x86_64 __x86_64__ for pointer size is wrong since pointer size may be 32bit on x86-64. No, it can't be. The macros are set in dependence of the target platform (m32 or m64). That means, if m32 is given the macro __i686 is set instead of __amd64. On the other hand, if m64 is given the macro __amd64 is set. I don't want to know the really underlying platform. I (or Matlab) want to know the target platform. So it is right to check the __amd64 macro. You can try it with the gcc-4.4. Only with gfortran-4.4 the macro is missed. See http://www.kernel.org/pub/linux/devel/binutils/ilp32/abi.pdf where pointer size is 32bit. As far as I understood means ILP32 a 32bit application in a 64bit environment No. ILP32 is a 32bit environment with 64bit instruction sets. and LP64 a 64bit application in 64bit environment. Am I Right? The predefined preprocessor macro __amd64 is true if I compile with -m64 (default on Linux) and it is not true if I compile with -m32. So why I can't check against this macro, as far it is supported (as in gcc)? Please correct me if I'm totally wrong. Or do you want to tell me that a 64bit application could use 32bit pointers, or the other way round? If so, how is it possible? ILP32 will define both __amd64 and __ILP32__. __amd64 is ISA, which can have 32bit or 64bit pointer sizes.
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 15:33:24 UTC --- The regression tests just completed for OpenBSD i386. There is one failure on ACATS (cb1010a timeout)* This is a stack checking test. 3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD. I was expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail. The tests should pass w and w/o it on x86, but it's better to define it. 4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro is ignored), the null_deref and stack_check gnat.dg tests pass. in gdb, the segfault comes and then the program just exits normally. This is expected with SJLJ exceptions, you don't need MD_UNWIND_SUPPORT. The summary is that the OpenBSD port is currently better then it has ever been, and one remaining ACATS failure is probably related to how OpenBSD handles their stack. As of today, I don't have any errors to report, but that may change as I discover more about the issues I just outlined above. Great, thanks for the detailed report.
[Bug lto/47162] [4.6 Regression] LTO is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47162 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org 2011-01-05 15:39:41 UTC --- Fixed.
[Bug fortran/46402] libquadmath: Add fmalq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46402 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-05 16:09:10 UTC --- Created attachment 22905 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22905 gcc46-pr46402.patch So far only very lightly tested patch, will do full bootstrap/regtest now.
[Bug fortran/46402] libquadmath: Add fmalq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46402 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-05 16:10:17 UTC --- Created attachment 22906 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22906 fmaq-test.c Testcase I was using.
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #15 from John Marino gnugcc at marino dot st 2011-01-05 16:25:56 UTC --- [off PR] Hi Eric, Can you clarify one statement? Regarding the ten stack-check tests as I can them (c5210[3x,4x,4y], cb1010[a,c,d], null_deref[1,2], stack-check[1,2]), I now understand that it is expected that these tests pass on SJLJ targets. Are these true passes meaning SJLJ targets are fully capable of handling stack overflow and segfaults? Or are these results just false positives? Thanks, John ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 15:33:24 UTC --- The regression tests just completed for OpenBSD i386. There is one failure on ACATS (cb1010a timeout)* This is a stack checking test. 3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD. I was expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail. The tests should pass w and w/o it on x86, but it's better to define it. 4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro is ignored), the null_deref and stack_check gnat.dg tests pass. in gdb, the segfault comes and then the program just exits normally. This is expected with SJLJ exceptions, you don't need MD_UNWIND_SUPPORT. The summary is that the OpenBSD port is currently better then it has ever been, and one remaining ACATS failure is probably related to how OpenBSD handles their stack. As of today, I don't have any errors to report, but that may change as I discover more about the issues I just outlined above. Great, thanks for the detailed report.
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213 --- Comment #22 from Rob rob1weld at aol dot com 2011-01-05 16:26:43 UTC --- (In reply to comment #21) At long last. It was only 2 years... I have some older than that. Thank you for your work on my Bug Report, Rob
[Bug other/45915] Check for gnu_unique_object in ld.so in gcc/configure.ac is broken for non-glibc ldd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45915 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg00233.htm ||l Last reconfirmed||2011.01.05 16:44:40 CC||ro at gcc dot gnu.org AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-01-05 16:44:40 UTC --- Mine, patch posted.
[Bug rtl-optimization/47166] [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.05 16:45:57 Ever Confirmed|0 |1 --- Comment #7 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-05 16:45:57 UTC --- I have altered the source, so that I call both refers_to_regno_p and reg_mentioned_p and print out when the two disagree. For the attached rectmm.i input file, there are only 5 disagreements: mismatch for regno=2343: refersto=F,mentions=T reg = (reg/f:SI 2343) i1 = (insn 3162 1730 3165 99 rectmm.c:1041 (set (reg/f:SI 2343) (reg:SI 1 r1)) -1 (nil)) mismatch for regno=2355: refersto=F,mentions=T reg = (reg/f:SI 2355) i1 = (insn 3166 1745 3169 99 rectmm.c:1043 (set (reg/f:SI 2355) (reg:SI 9 r9)) -1 (nil)) mismatch for regno=2377: refersto=F,mentions=T reg = (reg/f:SI 2377) i1 = (insn 3170 1770 1731 99 rectmm.c:1045 (set (reg/f:SI 2377) (reg:SI 12 ip)) -1 (nil)) mismatch for regno=2349: refersto=F,mentions=T reg = (reg/f:SI 2349) i1 = (insn 3174 1737 3177 99 rectmm.c:1042 (set (reg/f:SI 2349) (reg:SI 0 r0)) -1 (nil)) mismatch for regno=2361: refersto=F,mentions=T - reg and i1 follow ... reg = (reg/f:SI 2361) il = (insn 3178 1752 1772 99 rectmm.c:1044 (set (reg/f:SI 2361) (reg:SI 3 r3)) -1 (nil)) This occurs because reg_mentioned_p looks at output regs, but refers_to_regno_p does not. The knock-on effect of this difference must lead to those increments being lost, but I don't know why yet.
[Bug fortran/42954] [4.5/4.6 regression] TARGET_*_CPP_BUILDINS issues with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||jan.rauberg at gmx dot de --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org 2011-01-05 16:49:54 UTC --- *** Bug 47175 has been marked as a duplicate of this bug. ***
[Bug fortran/47175] no predefined macros __amd64, __amd64__, __x86_64 __x86_64__ in prepocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47175 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2011-01-05 16:49:54 UTC --- This is a dup of bug 42954 anyways. But really it should be using __LP64__ for checking what size of a pointer is. *** This bug has been marked as a duplicate of bug 42954 ***
[Bug tree-optimization/46021] 3 tree-ssa tests XPASS almost everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46021 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg00238.htm ||l Target Milestone|--- |4.6.0 --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-01-05 16:51:09 UTC --- Patch for gcc.dg/tree-ssa/20040204-1.c on alpha, i386, x86_64 posted.
[Bug tree-optimization/47005] [4.6 Regression] ACATS c62002a is miscompiled at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 --- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-05 16:55:57 UTC --- Regarding the ten stack-check tests as I can them (c5210[3x,4x,4y], cb1010[a,c,d], null_deref[1,2], stack-check[1,2]), I now understand that it is expected that these tests pass on SJLJ targets. null_deref[1,2] are not really about stack checking, but I get the point. Are these true passes meaning SJLJ targets are fully capable of handling stack overflow and segfaults? Or are these results just false positives? Stack checking per se is orthogonal to ZCX vs SJLJ. What isn't orthogonal is the handling of segfaults (hence the connection to stack checking done with probes): SJLJ handles segfaults out of the box whereas ZCX needs MD_UNWIND_SUPPORT. So, yes, the aforementioned 10 special tests are expected to pass on SJLJ targets out of the box, i.e. without additional target-specific support.
[Bug fortran/41580] [OOP] SAME_TYPE_AS and EXTENDS_TYPE_OF - add compile-time simplifcation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41580 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 17:19:45 UTC --- Created attachment 22907 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22907 Draft patch - not fully working (In reply to comment #4) Note: If both arguments are TYPE-valued, the result will be a compile-time constant, otherwise it has to be evaluated at runtime, according to the _hash values in the vtabs. Well, extends_type_of can also be (sometimes) be evaluated at compile time for CLASS. In which situations would we actually gain something I assume that in practice it only matters for automatically generated code - but there it might reduce the code size and improve the performance. By the way: I think that's a 4.7 item. * * * I attached a draft patch. Note, however, that it does not work (cf. bottom of patch/test case). For if (extends_type_of(a11,b11) .neqv. .true.) call abort() one enters gfc_simplify_extends_type_of twice: Once the second argument (mold) is BT_CLASS (which give the correct result: NULL, i.e. not compile-time simplifiable). But then again with mold being BT_DERIVED - which is then compile-time simplified to .TRUE. as a11 and b11 are the same type. I have not dug into this, but it seems to occur in two steps - first a normal simplification happens, then a specific interface is used via gfc_intrinsic_func_interface, which is then again simplified - but with BT_DERIVED argument (base type). I think all gfc_simplify_* functions could be affected. TODO: - Fix the double-simplification problem - Add more test cases - I think the double-simplification also affects same_type, but it is currently not tested for.
[Bug other/47167] Performance regression in numerical code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-01-05 17:31:20 UTC --- The only difference in the hot loop is the usage of two regs in the address: 4.5.1: .L142: movapd%xmm0, (%rcx) mulpd%xmm6, %xmm2 addq$32, %rbx movapd%xmm1, %xmm6 mulpd%xmm0, %xmm6 movsd(%rax), %xmm1 movsd8(%rax), %xmm3 unpcklpd%xmm1, %xmm1 subpd%xmm2, %xmm6 unpcklpd%xmm3, %xmm3 mulpd%xmm9, %xmm1 mulpd%xmm0, %xmm3 movapd%xmm6, 16(%rcx) addq$32, %rcx movapd%xmm1, %xmm0 movsd16(%rax), %xmm1 mulpd%xmm6, %xmm0 unpcklpd%xmm1, %xmm1 movsd24(%rax), %xmm2 addq$32, %rax cmpq%rsi, %rbx unpcklpd%xmm2, %xmm2 subpd%xmm3, %xmm0 mulpd%xmm9, %xmm1 jne.L142 4.6: .L167: movapd%xmm0, %xmm10 .L143: mulpd%xmm2, %xmm6 movapd%xmm3, %xmm2 movapd%xmm10, (%rsi,%rcx) mulpd%xmm10, %xmm2 movsd(%rdx), %xmm0 movsd8(%rdx), %xmm1 subpd%xmm6, %xmm2 unpcklpd%xmm0, %xmm0 unpcklpd%xmm1, %xmm1 mulpd%xmm11, %xmm0 movapd%xmm2, 16(%rsi,%rcx) mulpd%xmm10, %xmm1 addq$32, %rcx mulpd%xmm2, %xmm0 movsd16(%rdx), %xmm3 movsd24(%rdx), %xmm6 addq$32, %rdx cmpq%rdi, %rcx unpcklpd%xmm3, %xmm3 unpcklpd%xmm6, %xmm6 subpd%xmm1, %xmm0 mulpd%xmm11, %xmm3 jne.L167 Given the comment above ix86_address_cost: /* Return cost of the memory address x. For i386, it is better to use a complex address than let gcc copy the address into a reg and make a new pseudo. But not if the address requires to two regs - that would mean more pseudos with longer lifetimes. */ this could be the reason for slowdown.
[Bug lto/47183] New: Please discard unused functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47183 Summary: Please discard unused functions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 22908 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22908 Testcase Compile it with `g++ -O2 -flto -fuse-linker-plugin 47183.C'.
[Bug fortran/22210] gfc_conv_array_initializer weirdness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210 John T jrt at worldlinc dot net changed: What|Removed |Added CC||jrt at worldlinc dot net --- Comment #15 from John T jrt at worldlinc dot net 2011-01-05 17:47:45 UTC --- Using gfortran for gcc-4.4.5 on i686 Linux, compiled here with glib-2.7-something on Mandriva 2008.1, I got the following error while compiling files for an old program. I looked at the gfortran source around line 4781 of varasm.c, but don't know enough to make any suggestions about the problem. The only observation I have is that the preceding if statement assures that pos doesn't equal totalbytes, so the = operator shouldn't need the = in the assert argument. I don't know what statement sets the size of the data block (and its size). gfortran -c -o mind.o mind.f mind.f:457: internal compiler error: in output_constructor, at varasm.c:4781 line 454+ of mind.f contains the statements return end c- block data general c- c common /grid/grid_on
[Bug fortran/46402] libquadmath: Add fmalq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46402 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 17:56:50 UTC --- (In reply to comment #4) Created attachment 22905 [details] gcc46-pr46402.patch Please also add an item to libquadmath.texi
[Bug fortran/46416] libquadmath: missing functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46416 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 18:00:00 UTC --- I now compared the list of libquadmath functions at http://gcc.gnu.org/onlinedocs/libquadmath/Math-Library-Routines.html with the C99 functions in math.h and complex.h (cf. http://en.wikipedia.org/wiki/Math.h and http://en.wikipedia.org/wiki/Complex.h). Missing (no guarantee for completeness or correctness) a) fmaq, cf. Jakub's patch at PR 46402 b) math.h functions: fdimq, fmaq [cf. above], fmaxq, fminq, ilogbq, llrintq, lrintq, log2q, nearbyintq, nexttowardq, remquoq c) complex.h functions - casinq, cacosq, catanq, casinhq, cacoshq, catanhq - cimagq, conjq, cprojq, crealq
[Bug lto/47183] Please discard unused functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47183 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-01-05 18:00:15 UTC --- I don't see any unused functions here.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #5 from janus at gcc dot gnu.org 2011-01-05 18:06:25 UTC --- Author: janus Date: Wed Jan 5 18:06:21 2011 New Revision: 168524 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168524 Log: 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47180 * trans-expr.c (gfc_trans_class_assign): For a polymorphic NULL pointer assignment, set the _vptr component to the declared type. 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47180 * gfortran.dg/extends_type_of_2.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/extends_type_of_2.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug boehm-gc/11412] boehm-gc testing problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11412 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg00244.htm ||l CC||ro at gcc dot gnu.org AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-01-05 18:08:38 UTC --- Mine, initial patch posted.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from janus at gcc dot gnu.org 2011-01-05 18:12:48 UTC --- Fixed with r168524. Closing.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-05 18:18:34 UTC --- Compiling revision 168524 gives: ../../work/gcc/fortran/trans-expr.c: In function 'gfc_trans_class_assign': ../../work/gcc/fortran/trans-expr.c:6172:42: error: 'vtab' may be used uninitialized in this function [-Werror=uninitialized] cc1: all warnings being treated as errors
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 Victor K. vityan at vityan dot sytes.net changed: What|Removed |Added CC||vityan at vityan dot ||sytes.net --- Comment #8 from Victor K. vityan at vityan dot sytes.net 2011-01-05 18:20:35 UTC --- Testsuite works just fine with MingW-W64(GCC 4.6.0) + WinPthreads: /mw64src $ g++ -m32 omp_test.c -o ./omptst.exe -D_OPENMP -lgomp -lpthread /mw64src $ ./omptst OMP : All looks good /mw64src $ g++ -m64 -static omp_test.c -o ./omptst64.exe -D_OPENMP -lgomp -lpthread /mw64src $ ./omptst64 OMP : All looks good
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 --- Comment #9 from Dmitri Zolotukhin zlogic at gmail dot com 2011-01-05 18:30:46 UTC --- @Victor K. Are you using the MinGW or TDM version of GCC? TDM 4.5.0 passes the test cases on my machine. Seems the problem existed only in the 4.4.* branch of gcc.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-05 18:34:10 UTC --- REOPEN: Causes build issues (cf. comment 7). gfc_symbol *vtab; if (expr2-ts.type == BT_DERIVED) vtab = gfc_find_derived_vtab (expr2-ts.u.derived); else if (expr2-expr_type == EXPR_NULL) vtab = gfc_find_derived_vtab (expr1-ts.u.derived); gcc_assert (vtab); Which means that vtab is not initialized if the if/if else branch is not entered. Simple solution: - gfc_symbol *vtab; + gfc_symbol *vtab = NULL;
[Bug c++/47184] New: gcc interprets C++0x initialization construct as function declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47184
Summary: gcc interprets C++0x initialization construct as
function declaration
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
For the following code:
struct S
{
int a;
float b;
};
struct T
{
T(S s) {}
};
int main()
{
T t(S{1, 0.1}); // ERROR HERE
}
gcc 4.6 trunk gives the following errors (with the --std=c++0x option):
decl.cpp: In function 'int main()':
decl.cpp:14:10: error: expected ')' before '{' token
decl.cpp:14:10: error: a function-definition is not allowed here before '{'
token
decl.cpp:14:18: error: expected primary-expression before ')' token
decl.cpp:14:18: error: expected ';' before ')' token
It seems gcc is interpreting the statement as a function declaration.
I think this is valid C++0x.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-05 18:41:36 UTC --- Simple solution: - gfc_symbol *vtab; + gfc_symbol *vtab = NULL; This is the fix I have also reached and it allows gcc/fortran/trans-expr.c to be compiled.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #10 from janus at gcc dot gnu.org 2011-01-05 18:55:59 UTC --- (In reply to comment #8) REOPEN: Causes build issues (cf. comment 7). Thanks for noticing, and sorry for the breakage. Simple solution: - gfc_symbol *vtab; + gfc_symbol *vtab = NULL; Yes, I'll commit shortly.
[Bug libstdc++/47185] New: UB in TR1 and C++0x placeholders and non conforming implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47185
Summary: UB in TR1 and C++0x placeholders and non conforming
implementation
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thom.hel...@gmail.com
According to C++ TR1 3.6.4 [tr.func.bind.place] and C++0x (n3092) 20.8.10.1.3
[func.bind.place] placeholders are declared as:
namespace placeholders {
// M is the implementation-defined number of placeholders
extern unspecified _1;
extern unspecified _2;
.
.
.
extern unspecified _M;
}
However, in libstdc++ they are defined as:
namespace placeholders
{
namespace
{
_Placeholder1 _1;
_Placeholder2 _2;
.
.
.
_Placeholder29 _29;
}
}
The implementation is the same for tr1 and c++0x.
This implementation can lead to UB as discussed here:
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/c08e83496d251ba9?pli=1
[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45989 --- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2011-01-05 19:10:41 UTC --- I successfully did on i386-pc-solaris2.11. I'd suggest a slightly updated version (attached), with two changes * We should use i?86*-*-* (or perhaps just i?86-*-*, I see no reason for the first *). * The comment should be updated (perhaps with PR #s) to provide documentation for the XFAILed changes.
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 --- Comment #11 from janus at gcc dot gnu.org 2011-01-05 19:15:19 UTC --- Author: janus Date: Wed Jan 5 19:14:56 2011 New Revision: 168526 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168526 Log: 2011-01-05 Janus Weil ja...@gcc.gnu.org PR fortran/47180 * trans-expr.c (gfc_trans_class_assign): Bugfix for r168524 (make sure 'vtab' is initialized). Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c
[Bug libstdc++/47185] UB in TR1 and C++0x placeholders and non conforming implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47185 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.05 19:16:45 Ever Confirmed|0 |1 Severity|major |normal --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-05 19:16:45 UTC --- Easy enough to fix, but it won't happen in time for 4.6.0 I agree with the analysis, and I know you could contrive a test that relies on the address of a placeholder, but this is not major severity unless you can show an *actual* problem caused by this, rather than a theoretical one.
[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45989 --- Comment #6 from Rainer Orth ro at gcc dot gnu.org 2011-01-05 19:17:42 UTC --- Created attachment 22909 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22909 slightly revised patch
[Bug fortran/47180] [OOP] EXTENDS_TYPE_OF returns the wrong result for disassociated polymorphic pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47180 janus at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #12 from janus at gcc dot gnu.org 2011-01-05 19:21:18 UTC --- Ok. Build problem fixed. Closing, finally.
[Bug other/47167] Performance regression in numerical code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2011-01-05 19:30:49 UTC --- this could be the reason for slowdown. Hm, not really. But, by changing the generated assembly around loop entry: $ diff -u testcase2.s testcase2_.s --- testcase2.s2011-01-05 20:21:01.492919294 +0100 +++ testcase2_.s2011-01-05 20:22:23.616577277 +0100 @@ -1678,6 +1678,7 @@ addq%r15, %rdx addq$1, %rdi salq$5, %rdi +movapd%xmm10, %xmm0 jmp.L143 .p2align 4,,10 .p2align 3 @@ -1687,7 +1688,7 @@ mulpd%xmm2, %xmm6 movapd%xmm3, %xmm2 movapd%xmm10, (%rsi,%rcx) -mulpd%xmm10, %xmm2 +mulpd%xmm0, %xmm2 movsd(%rdx), %xmm0 movsd8(%rdx), %xmm1 subpd%xmm6, %xmm2 The slowdown is magically fixed: $ gcc -lm testcase2_.s $ time ./a.out real0m4.041s user0m4.034s sys0m0.003s versus: $ gcc -lm testcase2.s $ time ./a.out real0m4.239s user0m4.234s sys0m0.001s The important change is the change of %xmm10 - %xmm0 in the mulpd instruction. The functionality of the test didn't change due to existing movapd%xmm0, %xmm10 at the top of the loop and added extra movapd%xmm10, %xmm0 before the loop. This all happens on SnB, the code is generated with -O2 only. H.J., any ideas?
[Bug other/47167] Performance regression in numerical code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167 --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2011-01-05 19:48:58 UTC --- Applying the same medicine to original test gets us from: wall time for map2alm: 6.908527s to wall time for map2alm: 6.703142s where 4.5.1 wins with: wall time for map2alm: 6.651740s
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 --- Comment #22 from Sean McGovern gseanmcg at gmail dot com 2011-01-05 19:50:09 UTC --- Sorry, still learning -- collect2 is definitely not the place for this. Target-specific plugin maybe?
[Bug other/47167] Performance regression in numerical code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47167 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-01-05 20:09:11 UTC --- (In reply to comment #3) this could be the reason for slowdown. $ gcc -lm testcase2.s $ time ./a.out real0m4.239s user0m4.234s sys0m0.001s The important change is the change of %xmm10 - %xmm0 in the mulpd instruction. The functionality of the test didn't change due to existing movapd%xmm0, %xmm10 at the top of the loop and added extra movapd%xmm10, %xmm0 before the loop. This all happens on SnB, the code is generated with -O2 only. H.J., any ideas? Some loop performance is very sensitive to code sizes. This change -mulpd%xmm10, %xmm2 +mulpd%xmm0, %xmm2 will impact loop size due to exta REX prefix.
[Bug fortran/46416] libquadmath: missing functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46416
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.01.05 21:14:44
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-05
21:14:44 UTC ---
Created attachment 22910
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22910
gcc46-pr46416.patch
Very lightly tested patch to add ca{sin,cos,tan}{,h}q and fix broken atan2q.
[Bug lto/47183] Please discard unused functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47183 --- Comment #2 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-01-05 22:13:55 UTC --- It's operator delete(void*). Also, typeinfo for S, typeinfo name for S, vtable for __cxxabiv1::__class_type_info are unused, too.
[Bug libstdc++/47185] UB in TR1 and C++0x placeholders and non conforming implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47185 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.6.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-05 22:31:03 UTC --- A fix seems to me safe enough even at this Stage, I'll post it momentarily. Note, we are not going to fiddle with TR1, very serious regressions only.
[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45989 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-05 22:31:14 UTC --- * We should use i?86*-*-* (or perhaps just i?86-*-*, I see no reason for the first *). I don't think this cover x86_64-*-*, this is why I have tested *86*-*-* * The comment should be updated (perhaps with PR #s) to provide documentation for the XFAILed changes. See the end of comment #2. This should probably addressed by the objc maintainers.
