[Bug ada/51691] New: Cast of an array with type generates a please file bug message (See below)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51691 Bug #: 51691 Summary: Cast of an array with type generates a please file bug message (See below) Classification: Unclassified Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: minor Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: ale...@m2osw.com Created attachment 26193 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26193 Case Folding implementation for my own Ada compiler --- prompt gnatmake case_folding gcc-4.4 -c case_folding.adb +===GNAT BUG DETECTED==+ | 4.4.5 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:880 | | Error detected at case_folding.adb:401:32| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.4 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. case_folding.adb case_folding.adb:401:53: missing ) compilation abandoned gnatmake: case_folding.adb compilation error --- As I type fast, the error came from this line: output_line(1 .. indent) := string(1 .. indent = ' '); which includes an invalid cast, the proper line should be (without string): output_line(1 .. indent) := (1 .. indent = ' '); There are still problems on line 403 which I left in case the bug would not be reported without that other error (unlikely though.) Just in case, I'm on Ubuntu 11.04. I use the stock version of Ada. --- More info about my project can be found here: http://aada.m2osw.com/compiler
[Bug tree-optimization/51684] [4.7 Regression]: ICE in gfortran.dg/maxloc_bounds_5 on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51684 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-12-28 09:06:45 UTC --- (In reply to comment #1) Untested patch: I have bootstrapped and regression tested the patch on ia64-unknown-linux-gnu [1], where it fixes all mentioned failures. [1] http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg02709.html
[Bug rtl-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51667 --- Comment #19 from Uros Bizjak ubizjak at gmail dot com 2011-12-28 09:09:02 UTC --- FYI, the patch also works correctly on alpha [1], a target with sign-extended instructions. [1] http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg02710.html
[Bug target/50038] redundant zero extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50038 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #9 from Uros Bizjak ubizjak at gmail dot com 2011-12-28 09:13:03 UTC --- Patch was committed to mainline.
[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50722 --- Comment #7 from uros at gcc dot gnu.org 2011-12-28 09:16:28 UTC --- Author: uros Date: Wed Dec 28 09:16:24 2011 New Revision: 182704 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182704 Log: PR testsuite/50722 * gcc.dg/pr49994-3.c: Skip on ia64-*-*-*, hppa*-*-* and *-*-hpux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr49994-3.c
[Bug tree-optimization/51684] [4.7 Regression]: ICE in gfortran.dg/maxloc_bounds_5 on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51684 --- Comment #3 from irar at gcc dot gnu.org 2011-12-28 09:20:20 UTC --- Author: irar Date: Wed Dec 28 09:20:16 2011 New Revision: 182705 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182705 Log: PR tree-optimization/51684 * tree-vect-slp.c (vect_schedule_slp_instance): Get gsi of original statement in case of a pattern. (vect_schedule_slp): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug target/51685] FAIL: gcc.dg/tm/pr51472.c (internal compiler error) on ppc*-*-*, s390*-*-*, spu-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51685 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-28 CC||hp at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-12-28 09:38:27 UTC --- I checked my logs for r182695 (latest at this time) and yes, cris-axi-elf too, same message. A quick peek in gcc-testresults@ shows the same error for armv7l-unknown-linux-gnueabi (http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg02689.html) and ia64-linux (http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg02709.html) so it looks almost universal.
[Bug tree-optimization/51684] [4.7 Regression]: ICE in gfortran.dg/maxloc_bounds_5 on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51684 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-12-28 10:22:07 UTC --- Fixed.
[Bug tree-optimization/51692] New: [4.7 Regression] ICE on several valgrind tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51692
Bug #: 51692
Summary: [4.7 Regression] ICE on several valgrind tests
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: x86_64-linux
int
main ()
{
volatile double d = 0.0;
double *p = __builtin_calloc (1, sizeof (double));
d += 1.0;
*p += 2.0;
__builtin_free (p);
return 0;
}
ICEs at -O2, the free argument becomes a freed SSA_NAME for some reason.
Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=182009
[Bug tree-optimization/51692] [4.7 Regression] ICE on several valgrind tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51692 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug testsuite/51693] New: New XPASSes in vectorizer testsuite on powerpc64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693
Bug #: 51693
Summary: New XPASSes in vectorizer testsuite on
powerpc64-suse-linux
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@il.ibm.com
CC: michael.v.zolotuk...@gmail.com
Host: powerpc64-suse-linux
Target: powerpc64-suse-linux
Build: powerpc64-suse-linux
Revision 182583 http://gcc.gnu.org/viewcvs?view=revisionrevision=182583 caused
several XPASSes on powerpc64-suse-linux:
XPASS: gcc.dg/vect/vect-multitypes-1.c scan-tree-dump-times vect Alignment of
access forced using peeling 2
XPASS: gcc.dg/vect/vect-multitypes-1.c scan-tree-dump-times vect Vectorizing
an unaligned access 4
XPASS: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect Vectorizing an
unaligned access 1
XPASS: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect Alignment of access
forced using peeling 1
XPASS: gcc.dg/vect/vect-multitypes-1.c -flto scan-tree-dump-times vect
Alignment of access forced using peeling 2
XPASS: gcc.dg/vect/vect-multitypes-1.c -flto scan-tree-dump-times vect
Vectorizing an unaligned access 4
XPASS: gcc.dg/vect/vect-peel-3.c -flto scan-tree-dump-times vect Vectorizing
an unaligned access 1
XPASS: gcc.dg/vect/vect-peel-3.c -flto scan-tree-dump-times vect Alignment of
access forced using peeling 1
XPASS: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times vect
Alignment of access forced using peeling 2
The reason is that {!vect_aligned_arrays} was added to xfail of the above
checks, while vect_aligned_arrays is false for power.
Changing that, i.e.:
Index: ../../lib/target-supports.exp
===
--- ../../lib/target-supports.exp (revision 182703)
+++ ../../lib/target-supports.exp (working copy)
@@ -3222,7 +3222,8 @@ proc check_effective_target_vect_aligned_arrays {
set et_vect_aligned_arrays_saved 1
}
}
-if [istarget spu-*-*] {
+if {[istarget spu-*-*]
+ || [istarget powerpc*-*-*] } {
set et_vect_aligned_arrays_saved 1
}
}
fixes the XPASSes and doesn't cause any problems (on powerpc64-suse-linux), but
AFAIU arrays are not always vector aligned on power, so this is not a good
idea, unless we change the definition of
check_effective_target_vect_aligned_arrays.
What was the purpose of adding {!vect_aligned_arrays} to these tests? If
peeling is impossible on AVX because arrays are never vector aligned, maybe we
need a new target check instead of vect_aligned_arrays?
[Bug tree-optimization/51694] New: [4.7 Regression] ICE while compiling alliance package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51694
Bug #: 51694
Summary: [4.7 Regression] ICE while compiling alliance package
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: mkuvyr...@gcc.gnu.org
Target: x86_64-linux
void
foo (x, fn)
void (*fn) ();
{
int a = baz ((void *) 0, x);
(*fn) (x, 0);
}
void
bar (void)
{
void *x = 0;
foo (x);
}
ICEs at -O2 starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=181377
[Bug tree-optimization/51694] [4.7 Regression] ICE while compiling alliance package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51694 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693
--- Comment #1 from Michael Zolotukhin michael.v.zolotukhin at gmail dot com
2011-12-28 11:08:36 UTC ---
I though that if {vect_aligned_arrays} isn't true, than arrays could
be aligned even after peeling - that's why I added such check.
Unfortunately, I can't reproduce these fails, as I have no PowerPC. By
the way, if arrays aren't aligned on Power, why does GCC produce such
messages - does it really try to peel something? Maybe we should just
refine the check?
Anyway, if everything is ok with the tests (in original version) and
with gcc itself - we could check not for vect_aligned_arrays, but for
AVX. Please check
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01600.html and the
attached to that letter patch.
Thanks, Michael
On 28 December 2011 14:51, irar at il dot ibm.com
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693
Bug #: 51693
Summary: New XPASSes in vectorizer testsuite on
powerpc64-suse-linux
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@il.ibm.com
CC: michael.v.zolotuk...@gmail.com
Host: powerpc64-suse-linux
Target: powerpc64-suse-linux
Build: powerpc64-suse-linux
Revision 182583 http://gcc.gnu.org/viewcvs?view=revisionrevision=182583
caused
several XPASSes on powerpc64-suse-linux:
XPASS: gcc.dg/vect/vect-multitypes-1.c scan-tree-dump-times vect Alignment of
access forced using peeling 2
XPASS: gcc.dg/vect/vect-multitypes-1.c scan-tree-dump-times vect Vectorizing
an unaligned access 4
XPASS: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect Vectorizing an
unaligned access 1
XPASS: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect Alignment of
access
forced using peeling 1
XPASS: gcc.dg/vect/vect-multitypes-1.c -flto scan-tree-dump-times vect
Alignment of access forced using peeling 2
XPASS: gcc.dg/vect/vect-multitypes-1.c -flto scan-tree-dump-times vect
Vectorizing an unaligned access 4
XPASS: gcc.dg/vect/vect-peel-3.c -flto scan-tree-dump-times vect Vectorizing
an unaligned access 1
XPASS: gcc.dg/vect/vect-peel-3.c -flto scan-tree-dump-times vect Alignment of
access forced using peeling 1
XPASS: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times vect
Alignment of access forced using peeling 2
The reason is that {!vect_aligned_arrays} was added to xfail of the above
checks, while vect_aligned_arrays is false for power.
Changing that, i.e.:
Index: ../../lib/target-supports.exp
===
--- ../../lib/target-supports.exp (revision 182703)
+++ ../../lib/target-supports.exp (working copy)
@@ -3222,7 +3222,8 @@ proc check_effective_target_vect_aligned_arrays {
set et_vect_aligned_arrays_saved 1
}
}
- if [istarget spu-*-*] {
+ if {[istarget spu-*-*]
+ || [istarget powerpc*-*-*] } {
set et_vect_aligned_arrays_saved 1
}
}
fixes the XPASSes and doesn't cause any problems (on powerpc64-suse-linux),
but
AFAIU arrays are not always vector aligned on power, so this is not a good
idea, unless we change the definition of
check_effective_target_vect_aligned_arrays.
What was the purpose of adding {!vect_aligned_arrays} to these tests? If
peeling is impossible on AVX because arrays are never vector aligned, maybe we
need a new target check instead of vect_aligned_arrays?
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug tree-optimization/51694] [4.7 Regression] ICE while compiling alliance package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51694 Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-28 Ever Confirmed|0 |1 --- Comment #1 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2011-12-28 11:09:29 UTC --- Will investigate. Jakub, thanks for reporting this.
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |debug Target Milestone|--- |4.7.0
[Bug tree-optimization/51695] New: [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695
Bug #: 51695
Summary: [4.7 Regression] ICE while compiling argyllcms package
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: aol...@gcc.gnu.org
Target: x86_64-linux
typedef struct
{
struct { unsigned int t1, t2, t3, t4, t5, t6; } t;
int p;
struct { double X, Y, Z; } r;
} T;
typedef struct { T *h; } S;
static unsigned int v = 0x12345678;
int
foo (void)
{
v = (v 0x8000) ? ((v 1) ^ 0xa398655d) : (v 1);
return 0;
}
double
bar (void)
{
unsigned int o;
v = (v 0x8000) ? ((v 1) ^ 0xa398655d) : (v 1);
o = v 0x;
return (double) o / 32768.0;
}
int
baz (void)
{
foo ();
return 0;
}
void
test (S *x)
{
T *t = x-h;
t-t.t1 = foo ();
t-t.t2 = foo ();
t-t.t3 = foo ();
t-t.t4 = foo ();
t-t.t5 = foo ();
t-t.t6 = foo ();
t-p = baz ();
t-r.X = bar ();
t-r.Y = bar ();
t-r.Z = bar ();
}
ICEs at -O2 -g, starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=180194
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-28 11:35:23 UTC --- The NOTE_INSN_VAR_LOCATION argument for variable o is extremely huge in this case and we hit the 64KB limit on .debug_loc expressions.
[Bug target/51345] [avr] Devices with 8-bit SP need their own multilib(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51345 --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-12-28 12:21:40 UTC --- Created attachment 26194 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26194 tentative patch
[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693
--- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-12-28 12:27:18 UTC
---
(In reply to comment #1)
I though that if {vect_aligned_arrays} isn't true, than arrays could
be aligned even after peeling - that's why I added such check.
Sorry, I don't understand this sentence. What do you mean by aligned after
peeling? Could you please explain what exactly happens on AVX (a dump file with
-fdump-tree-vect-details would be the best thing).
Unfortunately, I can't reproduce these fails, as I have no PowerPC. By
the way, if arrays aren't aligned on Power, why does GCC produce such
messages - does it really try to peel something?
The arrays in the tests are aligned. I said that I think that we can't promise
that all the arrays are vector aligned on power. BTW, we can peel for unknown
misalignment as well.
Maybe we should just
refine the check?
Anyway, if everything is ok with the tests (in original version) and
with gcc itself - we could check not for vect_aligned_arrays, but for
AVX. Please check
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01600.html and the
attached to that letter patch.
I think that everything was ok, but I don't think that using vect_sizes_32B_16B
is a good idea. I would really like to see an AVX vect dump for eg.
vect-peel-3.c.
Thanks,
Ira
Thanks, Michael
[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693 --- Comment #3 from Michael Zolotukhin michael.v.zolotukhin at gmail dot com 2011-12-28 12:59:24 UTC --- Created attachment 26195 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26195 AVX2 vect dump
[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693
--- Comment #4 from Michael Zolotukhin michael.v.zolotukhin at gmail dot com
2011-12-28 13:01:51 UTC ---
(In reply to comment #2)
I though that if {vect_aligned_arrays} isn't true, than arrays could
be aligned even after peeling - that's why I added such check.
Sorry, I don't understand this sentence. What do you mean by aligned after
peeling? Could you please explain what exactly happens on AVX (a dump file
with
-fdump-tree-vect-details would be the best thing).
Sorry, I misspelled. I meant than arrays couldn't be aligned - at least
without some runtime checks. I.e. we can't peel some compile-time-known number
of iterations and be sure that array become aligned.
E.g., if we have array IA of ints aligned to 16-bytes, and we have access
IA[i+3], then peeling of one iteration will guarantee alignment to 16-byte. But
we don't know, how much iterations needs to be peeled to reach alignment to
32-bytes (as needed for AVX operations).
Unfortunately, I can't reproduce these fails, as I have no PowerPC. By
the way, if arrays aren't aligned on Power, why does GCC produce such
messages - does it really try to peel something?
The arrays in the tests are aligned. I said that I think that we can't promise
that all the arrays are vector aligned on power. BTW, we can peel for unknown
misalignment as well.
In this case we shouldn't add Power to vector_aligned_arrays, I guess.
Maybe we should just
refine the check?
Anyway, if everything is ok with the tests (in original version) and
with gcc itself - we could check not for vect_aligned_arrays, but for
AVX. Please check
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01600.html and the
attached to that letter patch.
I think that everything was ok, but I don't think that using
vect_sizes_32B_16B
is a good idea. I would really like to see an AVX vect dump for eg.
vect-peel-3.c.
In vect-peel-3.c we actually assume that vector length is 16 byte. Here is the
loop body:
suma += ia[i];
sumb += ib[i+5];
sumc += ic[i+1];
When vector-size is 16, then peeling can make two of three accesses aligned,
but when vector size is 32 that's impossible. That's why using
vector_sizes_32B_16B might be correct here.
Also, I uploaded the dump you asked.
Michael
Thanks,
Ira
[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693 --- Comment #5 from Ira Rosen irar at il dot ibm.com 2011-12-28 13:11:53 UTC --- (In reply to comment #4) In vect-peel-3.c we actually assume that vector length is 16 byte. Here is the loop body: suma += ia[i]; sumb += ib[i+5]; sumc += ic[i+1]; When vector-size is 16, then peeling can make two of three accesses aligned, but when vector size is 32 that's impossible. That's why using vector_sizes_32B_16B might be correct here. Ah, now I understand. I was confused by vect_aligned_arrays, and it's irrelevant here, right? Yes, vector_sizes_32B_16B seems to be ok in that case. Thanks, Ira
[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #7 from Marc Glisse marc.glisse at normalesup dot org 2011-12-28 13:44:16 UTC --- With g++-4.6, -O1 -finline-small-functions already inlines everything, so maybe the definition of small somehow changed a bit? g++-4.7 -fdump-ipa-all says that it doesn't inline because function not declared inline and code size would grow. g++-4.6 only tells me that the code size was unchanged by inlining the 2 calls.
[Bug c++/51547] auto, type deduction, reference collapsing and const: invalid initialization of reference of type 'const X' from expression of type 'const X'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51547 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-12-28 15:53:01 UTC --- Author: paolo Date: Wed Dec 28 15:52:54 2011 New Revision: 182709 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182709 Log: 2011-12-27 Paolo Carlini paolo.carl...@oracle.com PR c++/51547 * g++.dg/cpp0x/pr51547.C: New. Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #6 from Oleg Endo oleg.e...@t-online.de 2011-12-28 15:59:35 UTC
---
(In reply to comment #3)
Created attachment 26191 [details]
Proposed patch to improve some of the issues.
The attached patch removes the useless sequence and still allows the -1
constant to be CSE-ed for such cases as the example function above.
I haven't ran all tests on it yet, but CSiBE shows average code size reduction
of approx. -0.1% for -m4* with some code size increases in some files.
Some of the code size increases are caused by the ifcvt.c pass which tries to
transform sequences like:
int test_func_6 (int a, int b, int c)
{
if (a == 16)
c = 0;
return b + c;
}
into branch-free code like:
mov r4,r0 ! 45movsi_ie/2[length = 2]
cmp/eq #16,r0 ! 9 cmpeqsi_t/2[length = 2]
mov #-1,r0 ! 34movsi_ie/3[length = 2]
negcr0,r0 ! 38*negc[length = 2]
neg r0,r0 ! 36negsi2[length = 2]
and r6,r0 ! 37*andsi3_compact/2[length = 2]
rts ! 48*return_i[length = 2]
add r5,r0 ! 14*addsi3_compact[length = 2]
instead of the more compact (and on SH4 most likely better):
movr4,r0 ! 41movsi_ie/2[length = 2]
cmp/eq#16,r0 ! 9cmpeqsi_t/2[length = 2]
bf0f ! 34*movsicc_t_true/2[length = 4]
mov#0,r6
0:
addr5,r6 ! 14*addsi3_compact[length = 2]
rts ! 44*return_i[length = 2]
movr6,r0 ! 19movsi_ie/2[length = 2]
This particular case is handled in noce_try_store_flag_mask, which does the
transformation if BRANCH_COST = 2, which is true for -m4. I guess before the
patch ifcvt didn't realize that this transformation can be applied.
I've tried setting BRANCH_COST to 1, which avoids this transformation but
increases overall code size a bit.
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #6 from Pawel Sikora pluto at agmk dot net 2011-12-28 16:06:47 UTC --- btw, i've tested the default allocator with std::__7 and the i686-pc-mingw32 toolchain works fine while the x86_64-pc-mingw32 reports undefined reference to .text$_ZN9__gnu_cxx3__713new_allocatorIiE8allocateEyPKv[__gnu_cxx::__7::new_allocatorint::allocate(unsigned long long, void const*)] so, there's a bug with symbol exporting not directly related to mt_allocator. _Znwj vs. _Znwy issue?
[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693 --- Comment #6 from Michael Zolotukhin michael.v.zolotukhin at gmail dot com 2011-12-28 16:19:54 UTC --- (In reply to comment #5) In vect-peel-3.c we actually assume that vector length is 16 byte. Here is the loop body: suma += ia[i]; sumb += ib[i+5]; sumc += ic[i+1]; When vector-size is 16, then peeling can make two of three accesses aligned, but when vector size is 32 that's impossible. That's why using vector_sizes_32B_16B might be correct here. Ah, now I understand. I was confused by vect_aligned_arrays, and it's irrelevant here, right? Actually yes, you're right. I think, ideally, vect_aligned_arrays should be somehow checked in such tests, as in them we assume that array's beginning is aligned - but that's not the rootcause of the xpasses. Yes, vector_sizes_32B_16B seems to be ok in that case. Other two tests (vect-multitypes-1.c and no-section-anchors-vect-69.c) look like having the same problem - are you ok for similar fix for them too, i.e. is patch http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01600/vec-tests-avx2_fixes-7.patch ok for trunk? Thanks, Michael
[Bug rtl-optimization/51623] PowerPC section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51623 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org 2011-12-28 18:02:56 UTC --- Author: meissner Date: Wed Dec 28 18:02:49 2011 New Revision: 182710 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182710 Log: Fix PR 51623 Added: trunk/gcc/testsuite/gcc.target/powerpc/pr51623.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/51623] PowerPC section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51623 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||meissner at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |meissner at gcc dot gnu.org |gnu.org | --- Comment #3 from Michael Meissner meissner at gcc dot gnu.org 2011-12-28 18:04:03 UTC --- Fixed in subversion revision 182710.
[Bug c++/51556] Bizarre member template access control errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51556 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-28 18:12:17 UTC --- This works with current (Rev 182710) mainline.
[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-12-28 18:41:12 UTC --- Looking into it now. I am by no means expert on this code ;))
[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710
--- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-12-28
19:37:38 UTC ---
OK, loop hiearchy looks as follows:
loop_0 (header = 0, latch = 1, niter = )
{
bb_2 (preds = {bb_0 }, succs = {bb_3 })
bb_6 (preds = {bb_5 }, succs = {bb_13 })
bb_12 (preds = {bb_4 }, succs = {bb_1 })
loop_4 (header = 13, latch = 14, niter = )
{
bb_13 (preds = {bb_6 bb_14 }, succs = {bb_14 })
bb_14 (preds = {bb_13 }, succs = {bb_13 })
}
loop_1 (header = 3, latch = 9, niter = )
{
bb_3 (preds = {bb_2 bb_9 }, succs = {bb_4 })
bb_9 (preds = {bb_8 }, succs = {bb_3 })
loop_2 (header = 4, latch = 11, niter = )
{
bb_4 (preds = {bb_3 bb_11 }, succs = {bb_12 bb_5 })
bb_5 (preds = {bb_4 }, succs = {bb_6 bb_7 })
bb_7 (preds = {bb_5 }, succs = {bb_10 })
bb_11 (preds = {bb_10 }, succs = {bb_4 })
loop_3 (header = 10, latch = 15, niter = )
{
bb_8 (preds = {bb_10 }, succs = {bb_9 bb_15 })
bb_15 (preds = {bb_8 }, succs = {bb_10 })
bb_10 (preds = {bb_7 bb_15 }, succs = {bb_8 bb_11 })
}
}
}
}
We remove path from 10 to 8, that is closing the loop of loop_3.
Basic blocks removed are 8 9 and 15.
Finally we fail on BB 3 that is believed to be in loop 1, but header is null at
this point because of code in delete_basic_block:
504 /* If we remove the header or the latch of a loop, mark the loop for
405 removal by setting its header and latch to NULL. */
506 if (loop-latch == bb
507 || loop-header == bb)
508 {
509 loop-header = NULL;
510 loop-latch = NULL;
511 }
OK, so it seems that fix_bb_placements is not ready to see loops marked for
removal. I guess the catch is that loop peeling renders bb 3 unreachable.
I however do not understand how loop peeling can make this happen, perhaps
folding of the header condition is done?
Honza
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #7 from Pawel Sikora pluto at agmk dot net 2011-12-28 19:51:55 UTC --- please apply following obvious patch: --- gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver.orig 2011-12-28 12:43:50.0 +0100 +++ gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver 2011-12-28 20:25:36.603040153 +0100 @@ -42,9 +42,9 @@ __once_proxy; # operator new(size_t) -_Znw[jm]; +_Znw[jmy]; # operator new(size_t, std::nothrow_t const) -_Znw[jm]RKSt9nothrow_t; +_Znw[jmy]RKSt9nothrow_t; # operator delete(void*) _ZdlPv; @@ -52,9 +52,9 @@ _ZdlPvRKSt9nothrow_t; # operator new[](size_t) -_Zna[jm]; +_Zna[jmy]; # operator new[](size_t, std::nothrow_t const) -_Zna[jm]RKSt9nothrow_t; +_Zna[jmy]RKSt9nothrow_t; # operator delete[](void*) _ZdaPv; it fixes new/delete exports for x86_64-pc-mingw32. mt-allocator needs more exports...
[Bug c++/23211] using dec in nested class doesn't import name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211 --- Comment #15 from fabien at gcc dot gnu.org 2011-12-28 19:53:19 UTC --- Author: fabien Date: Wed Dec 28 19:53:14 2011 New Revision: 182711 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182711 Log: gcc/testsuite/ChangeLog 2011-12-28 Fabien Chene fab...@gcc.gnu.org PR c++/23211 * g++.dg/template/using18.C: New. * g++.dg/template/using19.C: New. * g++.dg/template/nested3.C: Remove dg-message at instantiation. * g++.dg/template/crash13.C: Likewise. gcc/cp/ChangeLog 2011-12-28 Fabien Chene fab...@gcc.gnu.org PR c++/23211 * name-lookup.c (do_class_using_decl): Use dependent_scope_p instead of dependent_type_p, to check that a non-dependent nested-name-specifier of a class-scope using declaration refers to a base, even if the current scope is dependent. * parser.c (cp_parser_using_declaration): Set USING_DECL_TYPENAME_P to 1 if the DECL is not null. Re-indent a 'else' close to the prior modification. Added: trunk/gcc/testsuite/g++.dg/template/using18.C trunk/gcc/testsuite/g++.dg/template/using19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/crash13.C trunk/gcc/testsuite/g++.dg/template/nested3.C
[Bug c++/23211] using dec in nested class doesn't import name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211 fabien at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #16 from fabien at gcc dot gnu.org 2011-12-28 20:04:25 UTC --- Fixed.
[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-28 20:09:32 UTC --- (In reply to comment #6) Well, it's just an impression ... :] I think one reason is that unlike normal functions, template functions are implicitly sort of local (by necessity), in that they can have a definition in many compilation units without causing a link conflict. To get this effect for normal functions, one must use the static or inline keywords -- so the impression (rightly or wrongly) is that template functions definitions are like one of those. Inline functions and templates both have vague linkage, which is how they avoid multiple definitions. That has nothing to do with inlining.
[Bug c++/51316] alignof doesn't work with arrays of unknown bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51316 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-28 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-28 20:24:44 UTC --- On it.
[Bug c/51696] New: [trans-mem] unsafe indirect function call in struct not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51696 Bug #: 51696 Summary: [trans-mem] unsafe indirect function call in struct not properly displayed Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, torv...@gcc.gnu.org Created attachment 26196 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26196 Attached testcase With an unsafe indirect function call, the error message is not clear. I don't know if it can display the declaration. In the worst case, unsafe indirect function call within ‘transaction_safe’ function should be ok. $ ./gcc/xgcc -B./gcc/ -fgnu-tm -O0 testcase.i testcase.i: In function ‘func’: testcase.i:7:21: error: unsafe function call ‘Uf3c0’ within ‘transaction_safe’ function testcase.i:8:12: error: unsafe function call ‘compare.1’ within ‘transaction_safe’ function Patrick Marlier.
[Bug rtl-optimization/51623] PowerPC section type conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51623 --- Comment #4 from Michael Meissner meissner at gcc dot gnu.org 2011-12-28 20:53:33 UTC --- Author: meissner Date: Wed Dec 28 20:53:30 2011 New Revision: 182712 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182712 Log: Backport PR 51623 change Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/pr51623.c - copied unchanged from r182710, trunk/gcc/testsuite/gcc.target/powerpc/pr51623.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org 2011-12-28 21:24:25 UTC --- (In reply to comment #7) please apply following obvious patch: --- gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver.orig 2011-12-28 12:43:50.0 +0100 +++ gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver 2011-12-28 20:25:36.603040153 +0100 @@ -42,9 +42,9 @@ __once_proxy; # operator new(size_t) -_Znw[jm]; +_Znw[jmy]; # operator new(size_t, std::nothrow_t const) -_Znw[jm]RKSt9nothrow_t; +_Znw[jmy]RKSt9nothrow_t; # operator delete(void*) _ZdlPv; @@ -52,9 +52,9 @@ _ZdlPvRKSt9nothrow_t; # operator new[](size_t) -_Zna[jm]; +_Zna[jmy]; # operator new[](size_t, std::nothrow_t const) -_Zna[jm]RKSt9nothrow_t; +_Zna[jmy]RKSt9nothrow_t; # operator delete[](void*) _ZdaPv; it fixes new/delete exports for x86_64-pc-mingw32. mt-allocator needs more exports... Thanks. Yes, confirmed patch fixes reported new/delete issue. From my side this patch is ok. If C++ maintainer ok-s it too, I will apply it. Kai
[Bug c++/51316] alignof doesn't work with arrays of unknown bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51316 --- Comment #5 from Nikolka tsoae at mail dot ru 2011-12-28 22:06:18 UTC --- On it. There is an active core issue about alignof: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3309.html#1305 Probably, you should take into account the proposed resolution.
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #7 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-12-28 22:25:48 UTC --- (In reply to comment #3) I haven't ran all tests on it yet, but CSiBE shows average code size reduction of approx. -0.1% for -m4* with some code size increases in some files. Would something like that be OK for stage 3? Looks good, though not appropriate for stage 3, I think.
[Bug testsuite/50988] gcc.target/powerpc/*: Several tests fail incorrectly on powerpc-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50988 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org 2011-12-28 22:30:22 UTC --- Created attachment 26197 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26197 Proposed patch Please check this patch on the spe compiler.
[Bug c++/51316] alignof doesn't work with arrays of unknown bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51316 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-28 22:31:02 UTC --- Yeah, just allow the types at issue, that was clarified in core/930 actually.
[Bug target/51340] SH Target: Make -mfused-madd enabled by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51340 --- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-12-28 22:31:27 UTC --- (In reply to comment #2) Uhm, yes... The title should have been Enable -mfused-madd by -ffast-math Do you mean something like this? --- ORIG/trunk/gcc/config/sh/sh.c2011-12-03 10:03:41.0 +0900 +++ trunk/gcc/config/sh/sh.c2011-12-27 08:33:23.0 +0900 @@ -838,6 +838,11 @@ sh_option_override (void) align_functions = min_align; } + /* Default to use fmac insn when -ffast-math. See PR target/29100. */ + if (global_options_set.x_TARGET_FMAC == 0 + fast_math_flags_set_p (global_options) +TARGET_FMAC = 1; + if (sh_fixed_range_str) sh_fix_range (sh_fixed_range_str); I don't know the exact semantics for the new patterns. All I know is that rounding is supposed to be done only once after the two operations. This is the case for the SH fmac insn. Not sure whether this is enough though. It seems that we can use the fma pattern, though it would be an another issue.
[Bug testsuite/50988] gcc.target/powerpc/*: Several tests fail incorrectly on powerpc-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50988 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-28 CC||meissner at gcc dot gnu.org AssignedTo|unassigned at gcc dot |meissner at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug testsuite/50988] gcc.target/powerpc/*: Several tests fail incorrectly on powerpc-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50988 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #3 from Michael Meissner meissner at gcc dot gnu.org 2011-12-28 22:32:41 UTC --- Klye, could you check this patch on your SPE compiler before I check it in?
[Bug fortran/51502] [4.6/4.7 Regression] Potentially wrong code generation due to wrong implict_pure check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51502 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org |
[Bug middle-end/42668] internal compiler error: in expand_expr_real_1, at expr.c:9314
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42668 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution||FIXED Target Milestone|--- |4.4.3 Severity|major |normal --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-28 22:52:12 UTC --- Has been fixed for awhile now.
[Bug target/51340] SH Target: Make -mfused-madd enabled by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51340 --- Comment #4 from Oleg Endo oleg.e...@t-online.de 2011-12-29 00:02:40 UTC --- (In reply to comment #3) (In reply to comment #2) Uhm, yes... The title should have been Enable -mfused-madd by -ffast-math Do you mean something like this? --- ORIG/trunk/gcc/config/sh/sh.c2011-12-03 10:03:41.0 +0900 +++ trunk/gcc/config/sh/sh.c2011-12-27 08:33:23.0 +0900 @@ -838,6 +838,11 @@ sh_option_override (void) align_functions = min_align; } + /* Default to use fmac insn when -ffast-math. See PR target/29100. */ + if (global_options_set.x_TARGET_FMAC == 0 + fast_math_flags_set_p (global_options) +TARGET_FMAC = 1; + if (sh_fixed_range_str) sh_fix_range (sh_fixed_range_str); Yes, something like that. Or maybe check flag_unsafe_math_optimizations, as it is done for FSCA and FSRRA insns in sh.md. I don't know the exact semantics for the new patterns. All I know is that rounding is supposed to be done only once after the two operations. This is the case for the SH fmac insn. Not sure whether this is enough though. It seems that we can use the fma pattern, though it would be an another issue. Maybe when trunk is back to stage 1.
[Bug target/51697] New: SH Target: Inefficient DImode comparisons for -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51697
Bug #: 51697
Summary: SH Target: Inefficient DImode comparisons for -Os
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
For -Os and everything but -m1 DImode comparisons are not optimized properly
which results in redundant SImode comparisons, producing code worse than for
-O1.
A reduced example:
int test_0 (long long* x)
{
return *x 0x ? -20 : -40;
}
-Os -m2/-m3/-m4:
mov#0,r2 ! 55movsi_ie/3[length = 2]
tstr2,r2 ! 57cmpeqsi_t/1[length = 2]
bf/s.L12! 58branch_false[length = 2]
mov.l@(4,r4),r3! 12movsi_ie/7[length = 2]
tstr3,r3 ! 59cmpeqsi_t/1[length = 2]
.L12:
bt/s.L11! 14branch_true[length = 2]
mov#-40,r0 ! 5movsi_ie/3[length = 2]
mov#-20,r0 ! 4movsi_ie/3[length = 2]
.L11:
rts
nop ! 65*return_i[length = 4]
-Os -m1:
-O2 -m4:
mov.l @(4,r4),r1 ! 10movsi_i/5[length = 2]
mov #-40,r0 ! 5movsi_i/3[length = 2]
tst r1,r1 ! 15cmpeqsi_t/1[length = 2]
bt .L7 ! 16branch_true[length = 2]
mov #-20,r0 ! 4movsi_i/3[length = 2]
.L7:
rts
nop ! 61*return_i[length = 4]
-O1 -m4:
mov.l @(4,r4),r1 ! 10movsi_ie/7[length = 2]
tst r1,r1 ! 17cmpeqsi_t/1[length = 2]
bt/s.L6 ! 18branch_true[length = 2]
mov #-40,r0 ! 5movsi_ie/3[length = 2]
mov #-20,r0 ! 4movsi_ie/3[length = 2]
.L6:
rts
nop ! 62*return_i[length = 4]
Another example would be:
int test_2 (unsigned long long x)
{
return x = 0x1LL ? -20 : -40;
}
-Os -m2/-m3/-m4:
mov #0,r2 ! 48movsi_ie/3[length = 2]
mov #-1,r3 ! 49movsi_ie/3[length = 2]
cmp/eq r2,r4 ! 9cmpgtudi_t[length = 8]
bf/s.Ldi67
cmp/hi r2,r4
cmp/hi r3,r5
.Ldi67:
bf/s.L16! 10branch_false[length = 2]
mov #-40,r0 ! 5movsi_ie/3[length = 2]
mov #-20,r0 ! 4movsi_ie/3[length = 2]
.L16:
rts
nop ! 52*return_i[length = 4]
-Os -m1:
tst r4,r4 ! 9cmpeqsi_t/1[length = 2]
mov #-20,r0 ! 4movsi_i/3[length = 2]
bf .L12! 10branch_false[length = 2]
mov #-40,r0 ! 5movsi_i/3[length = 2]
.L12:
rts
nop ! 56*return_i[length = 4]
The problem does not appear for -m1, only for -Os and -m2*, -m3*, -m4*.
[Bug target/49263] SH Target: underutilized TST #imm, R0 instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #15 from Oleg Endo oleg.e...@t-online.de 2011-12-29 00:34:53 UTC --- (In reply to comment #14) With trunk rev 181517 I have observed the following problem, which happens when compiling for -m2*, -m3*, -m4* and -Os: This is still present as of rev 182713 and seems to be a different issue. I've created PR51697 for it.
[Bug lto/51698] New: [trans-mem] TM runtime and application with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51698 Bug #: 51698 Summary: [trans-mem] TM runtime and application with LTO Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, r...@gcc.gnu.org, torv...@gcc.gnu.org Created attachment 26198 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26198 testcase app-itm with lto In my attempt to make _ITM_R/W* calls inlined into the application code, it seems that the TM builtins and TM defintions don't work as expected with LTO. $ gcc -flto -fgnu-tm -Wall -o bin appitm.c `_ITM_beginTransaction' referenced in section `.text' of /tmp/cc7uGSe1.ltrans0.ltrans.o: defined in discarded section `.text' of /tmp/ccJk2crp.o (symbol from plugin) `_ITM_RU4' referenced in section `.text' of /tmp/cc7uGSe1.ltrans0.ltrans.o: defined in discarded section `.text' of /tmp/ccJk2crp.o (symbol from plugin) `_ITM_commitTransaction' referenced in section `.text' of /tmp/cc7uGSe1.ltrans0.ltrans.o: defined in discarded section `.text' of /tmp/ccJk2crp.o (symbol from plugin) collect2: error: ld returned 1 exit status I have merged all .c in the same source for the testcase but it has the same problem if TM runtime is in a library. Patrick Marlier.
[Bug libstdc++/51699] New: Clang refuses to compile ext/rope citing scope resolution issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51699 Bug #: 51699 Summary: Clang refuses to compile ext/rope citing scope resolution issues Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: fedorabugm...@yahoo.com When using clang to compile an existing program, clang refuses to compile the ext/rope header files. One of the errors given is below. ropeimpl.h:433:2: error: use of undeclared identifier '_Data_allocate' _Data_allocate(_S_rounded_up_size(__old_len + __len)); g++ will compile this okay but the clang authors claim this code is invalid, http://llvm.org/bugs/show_bug.cgi?id=6454. Below are the 7 changes to the two files that allowed a successful compile. Line numbers may not be exact. In ropeimpl.h 383c381 this-_L_deallocate(__l, 1); --- _L_deallocate(__l, 1); 392c390 this-_C_deallocate(__c, 1); --- _C_deallocate(__c, 1); 400c398 this-_F_deallocate(__f, 1); --- _F_deallocate(__f, 1); 409c407 this-_S_deallocate(__ss, 1); --- _S_deallocate(__ss, 1); 433c431 _Rope_base_CharT, _Alloc::_Data_allocate(_S_rounded_up_size(__old_len + __len)); --- _Data_allocate(_S_rounded_up_size(__old_len + __len)); 514c512 _Rope_base_CharT, _Alloc::_C_deallocate(__result,1); --- _C_deallocate(__result,1); 817c815 _Rope_base_CharT, _Alloc::_Data_allocate(_S_rounded_up_size(__result_len)); --- _Data_allocate(_S_rounded_up_size(__result_len)); In rope 732c730 this-_S_free_string(_M_data, this-_M_size,this-_M_get_allocator()); --- __STL_FREE_STRING(_M_data, this-_M_size, this-_M_get_allocator());
[Bug target/51565] [4.4/4.5/4.6/4.7 Regression] fastcall in array of method pointers: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51565 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-29 Component|c++ |target Known to work||4.3.5 Target Milestone|--- |4.4.7 Summary|fastcall in array of method |[4.4/4.5/4.6/4.7 |pointers: internal compiler |Regression] fastcall in |error |array of method pointers: ||internal compiler error Ever Confirmed|0 |1 Known to fail||4.4.5, 4.7.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-29 06:00:53 UTC --- Confirmed.
[Bug fortran/51569] documentation on sign intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51569 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-29 06:02:53 UTC --- -0.0 does not exist in Fortran except when using the IEEE module IIRC.
[Bug c++/51613] [4.4/4.5/4.6/4.7 Regression] Ambiguous function template instantiations as template argument are not rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51613 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.3.5 Keywords||accepts-invalid Last reconfirmed||2011-12-29 Ever Confirmed|0 |1 Summary|Ambiguous function template |[4.4/4.5/4.6/4.7 |instantiations as template |Regression] Ambiguous |argument are not rejected |function template ||instantiations as template ||argument are not rejected Target Milestone|--- |4.4.7 Known to fail||4.4.5, 4.7.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-29 06:07:16 UTC --- Confirmed.
[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693 --- Comment #7 from Ira Rosen irar at il dot ibm.com 2011-12-29 07:37:53 UTC --- (In reply to comment #6) Yes, vector_sizes_32B_16B seems to be ok in that case. Other two tests (vect-multitypes-1.c and no-section-anchors-vect-69.c) look like having the same problem - are you ok for similar fix for them too, i.e. is patch http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01600/vec-tests-avx2_fixes-7.patch ok for trunk? Yes, just please don't forget to update testsuite/ChangeLog. Thanks, Ira Thanks, Michael
