[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60267 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Feb 19 18:11:54 2014 New Revision: 207914 URL: http://gcc.gnu.org/viewcvs?rev=207914root=gccview=rev Log: PR c++/60267 * pt.c (tsubst_expr): Handle ANNOTATE_EXPR. * g++.dg/ext/ivdep-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/ivdep-1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug debug/56563] no debuginfo for explicit operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56563 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Feb 19 18:12:31 2014 New Revision: 207915 URL: http://gcc.gnu.org/viewcvs?rev=207915root=gccview=rev Log: PR debug/56563 * cp-objcp-common.c (cp_function_decl_explicit_p): Remove FUNCTION_FIRST_USER_PARMTYPE (decl) != void_list_node check. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.c
[Bug c++/60046] [4.7/4.8/4.9 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1280
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60046 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/60272] atomic::compare_exchange_weak has spurious store and can cause race conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60272 --- Comment #2 from torvald at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) So, either we'd need to change this function, so that it sets oldval to NULL_RTX first, and passes ..., oldval, mem, expected, ... and needs to also always ask for target, then conditionally on target store to expected, or perhaps add extra parameter to expand_atomic_compare_and_swap and do the store only conditionally in that case. Richard/Torvald? I'm not sure what's better. But getting this fixed in 4.9.0 would be good! :)
[Bug c/37743] Bogus printf format warning with __builtin_bswap32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed. That said, both testcases in this PR are inherently non-portable, on some targets __builtin_bswap32 returns unsigned long, on most unsigned int, could be even unsigned long long. So, one should really use uint32_t and PRIu32.
[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #11 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Uroš Bizjak from comment #10)
(In reply to Vittorio Zecca from comment #5)
Adding option -m32 I get ICE in ix86_expand_prologue, at
config/i386/i386.c:10559
I can confirm this with:
gcc version 4.8.3 20140219 (prerelease) [gcc-4_8-branch revision 207910]
(GCC)
~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c
This is the same problem, as confirmed by following debug patch:
--cut here--
Index: i386.c
===
--- i386.c (revision 207912)
+++ i386.c (working copy)
@@ -10449,8 +10449,12 @@ ix86_expand_prologue (void)
else if (!ix86_target_stack_probe ()
|| frame.stack_pointer_offset CHECK_STACK_LIMIT)
{
+ rtx x = GEN_INT (-allocate);
+
+ printf (\nTestP1 %li\n, -allocate);
+ debug_rtx (x);
pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx,
-GEN_INT (-allocate), -1,
+x, -1,
m-fs.cfa_reg == stack_pointer_rtx);
}
else
@@ -10536,6 +10540,7 @@ ix86_expand_prologue (void)
gen_frame_mem (word_mode, t));
}
}
+ printf (\nTestP2 %li %li\n, m-fs.sp_offset, frame.stack_pointer_offset);
gcc_assert (m-fs.sp_offset == frame.stack_pointer_offset);
/* If we havn't already set up the frame pointer, do so now. */
--cut here--
GEN_INT (...) produces some non-sensical RTX, and INTVAL at the end of
pro_epilogue_adjust_stack chokes on it.
m-fs.sp_offset = ooffset - INTVAL (offset);
m-fs.sp_valid = valid;
~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c
...
TestP1 -56
(??? bad code 42752
)
TestP2 -139787679344504 64
pr57896.c: In function ‘__get_cpuid_max’:
pr57896.c:4:1: internal compiler error: in ix86_expand_prologue, at
config/i386/i386.c:10544
}
^
0x98fe35 ix86_expand_prologue()
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:10544
0xa1ce9a gen_prologue()
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.md:11829
0x673927 thread_prologue_and_epilogue_insns
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:5949
0x673927 rest_of_handle_thread_prologue_and_epilogue
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:6973
[Bug c++/60272] atomic::compare_exchange_weak has spurious store and can cause race conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60272 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org --- Comment #3 from Richard Henderson rth at gcc dot gnu.org --- Agreed. Mine.
[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60267 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now.
[Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org, ||jakub at redhat dot com Component|target |middle-end Version|4.8.1 |4.8.3 --- Comment #12 from Uroš Bizjak ubizjak at gmail dot com --- Reconfirmed on 4.8.3 as middle-end catch-all bug. Adding some CCs that might be interested in this PR.
[Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60267 --- Comment #12 from Sylwester Arabas slayoo at staszic dot waw.pl --- Thanks a lot! I'll try it as soon as it will get into Debian's gcc-snapshot package. Sylwester
[Bug c++/60046] [4.7/4.8/4.9 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1280
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60046 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Feb 19 19:03:19 2014 New Revision: 207917 URL: http://gcc.gnu.org/viewcvs?rev=207917root=gccview=rev Log: PR c++/60046 * pt.c (maybe_instantiate_noexcept): Don't instantiate exception spec from template context. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept22.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #13 from Marek Polacek mpolacek at gcc dot gnu.org --- Seems like r196890 made this latent.
[Bug tree-optimization/45833] Unnecessary runtime versioning for aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45833
rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org
---
Same thing without a union:
struct v { int v[4]; } __attribute__ ((aligned (4 * sizeof (int;
void
f (struct v *x, struct v *y, struct v *z)
{
for (int i = 0; i 4; i++)
x-v[i] = y-v[i] + z-v[i];
}
produces (with -msee4.2):
leaq16(%rsi), %rcx
leaq16(%rdi), %rax
cmpq%rcx, %rdi
setae %r8b
cmpq%rsi, %rax
setbe %cl
orb %cl, %r8b
je .L5
leaq16(%rdx), %rcx
cmpq%rcx, %rdi
setae %cl
cmpq%rdx, %rax
setbe %al
orb %al, %cl
je .L5
vmovdqa (%rsi), %xmm0
vpaddd (%rdx), %xmm0, %xmm0
vmovaps %xmm0, (%rdi)
ret
...
[Bug c/60276] New: -O3 autovectorizer breaks on a particular loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276 Bug ID: 60276 Summary: -O3 autovectorizer breaks on a particular loop Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: maister at archlinux dot us Created attachment 32174 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32174action=edit Reduced testcase GCC 4.8.2 with -O3 breaks a certain loop I'm compiling. Disabling the vectorizer with -fno-tree-vectorize fixes the issue, as well as compiling with -O2. I've reduced the problem to a small test case which is attached as legall.c. Distro: Arch Linux x86_64 gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-4.8-20140206/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.8.2 20140206 (prerelease) (GCC) Miscompile: gcc -o legall legall.c -std=gnu99 -O3 Working: gcc -o legall legall.c -std=gnu99 -O3 -fno-tree-vectorize Expected output: (0) (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) (25) (26) (27) (28) (29) (30) (31) (32) (33) (34) (35) (36) (37) (38) (39) (40) (41) (42) (43) (44) (45) (46) (47) (48) Wrong output by -O3: (0) (1) (2) (2) (4) (3) (6) (4) (8) (5) (10) (6) (12) (7) (14) (8) (16) (17) (18) (10) (20) (11) (22) (12) (24) (13) (26) (14) (28) (15) (30) (16) (32) (33) (34) (35) (36) (37) (38) (39) (40) (41) (42) (43) (44) (45) (46) (47) (48)
[Bug c++/60277] New: Bogus inline function virtual ... used but never defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60277
Bug ID: 60277
Summary: Bogus inline function virtual ... used but never
defined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Test case:
struct Foo {
inline virtual void func() = 0;
};
struct Bar : public Foo {
void func() { }
};
int main()
{
Foo *f = new Bar;
f-func();
}
Using trunk:
g++ (GCC) 4.9.0 20140219 (experimental)
g++ -c -Wall -Wextra t.cc
t.cc:2:23: warning: inline function 'virtual void Foo::func()' used but never
defined
inline virtual void func() = 0;
^
But Foo::func is never actually used.
Analysis by Nick Lewycky:
The relevant [basic.odr]/2 text is:
A virtual member function is odr-used if it is not pure. A non-overloaded
function whose name appears as a potentially-evaluated expression or a member
of a set of candidate functions, if selected by overload resolution when
referred to from a potentially-evaluated expression, is odr-used, unless it is
a pure virtual function and its name is not explicitly qualified.
Since the function isn't ODR-used, there's no need for it to have a definition:
An inline function shall be defined in every translation unit in which it is
odr-used. [basic.odr]/3
[Bug debug/56563] no debuginfo for explicit operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56563 Mark Wielaard mark at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Mark Wielaard mark at gcc dot gnu.org --- With the patch we get the following for the example in the description: [37] subprogram external (flag_present) Yes name (strp) operator int decl_file(data1) 1 decl_line(data1) 3 linkage_name (strp) _ZN1qcviEv type (ref4) [51] declaration (flag_present) Yes explicit (flag_present) Yes object_pointer (ref4) [4a]
[Bug c++/60046] [4.7/4.8/4.9 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1280
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60046 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Feb 19 19:59:07 2014 New Revision: 207921 URL: http://gcc.gnu.org/viewcvs?rev=207921root=gccview=rev Log: PR c++/60046 * pt.c (maybe_instantiate_noexcept): Don't instantiate exception spec from template context. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/noexcept22.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/pt.c
[Bug c++/60046] [4.7/4.8/4.9 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1280
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60046 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Feb 19 19:59:09 2014 New Revision: 207922 URL: http://gcc.gnu.org/viewcvs?rev=207922root=gccview=rev Log: PR c++/60046 * pt.c (maybe_instantiate_noexcept): Don't instantiate exception spec from template context. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/noexcept22.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/pt.c
[Bug c++/60273] gcc gets confused when one class uses variadic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60273 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- My understanding is that your example is touching an open language issue, namely http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1430 The current tendency seems to be that this should be ill-formed (personally I'm not happy with that decision). Current clang and gcc do both reject your code. I suggest to mark this issue as deferred pending 1430.
[Bug c++/60273] gcc gets confused when one class uses variadic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60273 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2014-02-19 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Ok, suspended for now.
[Bug c/59933] for loop goes wild with assert() enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59933 --- Comment #11 from Mark Warner warnerme at ptd dot net --- I'm confused .. what about.. for (k = i; k (int)(sizeof(NSQ_del_dec_struct) / sizeof(opus_int32)); ++k) ... is illegal or invalid ? Why does it only fail if -DDEBUG is defined ? I mean, this code worked fine for months .. and now
[Bug c/59933] for loop goes wild with assert() enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59933 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Mark Warner from comment #11) I'm confused .. what about.. for (k = i; k (int)(sizeof(NSQ_del_dec_struct) / sizeof(opus_int32)); ++k) ... is illegal or invalid ? Why does it only fail if -DDEBUG is defined ? I mean, this code worked fine for months .. and now The undefined behavior is if i is smaller than 292, you access out of bound array members (well, in C already the address arithmetics is undefined behavior when you go further than one past the last element of the array). The sLPC_Q14 has only 112 entries, so say if i is 0, then when k is 112, you invoke undefined behavior, because you can't read or write sLPC_Q14[112].
[Bug libstdc++/51823] [DR 198] [DR 2204] reverse iterator returns uninitialized values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51823 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |INVALID --- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org --- The definition of reverse_iterator has been reverted to the C++03 version, which does not use an extra member, so stashing iterators can not be used with reverse_iterator.
[Bug c++/60277] Bogus inline function virtual ... used but never defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60277 --- Comment #1 from Nick Lewycky nlewycky at google dot com --- Furthermore, if the testcase ended with: f-Foo::func(); then the warning should be issued.
[Bug middle-end/52306] [4.8 regression] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #31 from Andreas Schwab sch...@linux-m68k.org --- Created attachment 32175 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32175action=edit Testcase from jumpnbump After backporting the patch to 4.8 there is still a package that fails with the same error, though it doesn't fail with 4.9. $ gcc/xgcc -B gcc/ -O -fomit-frame-pointer filter.i filter.i: In function ‘do_scale2x’: filter.i:202:1: internal compiler error: in cselib_record_set, at cselib.c:2373 } ^ 0x5c092e cselib_record_set ../../gcc/gcc/cselib.c:2373 0x5c092e cselib_record_sets ../../gcc/gcc/cselib.c:2590 0x5c0c8f cselib_process_insn(rtx_def*) ../../gcc/gcc/cselib.c:2665 0x753c27 reload_cse_regs_1 ../../gcc/gcc/postreload.c:222 0x75426b reload_cse_regs ../../gcc/gcc/postreload.c:68 0x75426b rest_of_handle_postreload ../../gcc/gcc/postreload.c:2287
[Bug c++/53711] Wunused-function should warn for functions in the unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53711 patrick at parcs dot ath.cx changed: What|Removed |Added CC||patrick at parcs dot ath.cx --- Comment #2 from patrick at parcs dot ath.cx --- This is fixed on trunk (with r199906 I believe).
[Bug c/37743] Bogus printf format warning with __builtin_bswap32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743
--- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Wed Feb 19 22:27:40 2014
New Revision: 207924
URL: http://gcc.gnu.org/viewcvs?rev=207924root=gccview=rev
Log:
PR c/37743
* c-common.c (c_common_nodes_and_builtins): When initializing
c_uint{16,32,64}_type_node, also set corresponding
uint{16,32,64}_type_node to the same value.
* g++.dg/ext/builtin-bswap1.C: New test.
* c-c++-common/pr37743.c: New test.
Added:
trunk/gcc/testsuite/c-c++-common/pr37743.c
trunk/gcc/testsuite/g++.dg/ext/builtin-bswap1.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/57320] [4.9 Regression] Shrink-wrapping leaves unreachable blocks in the CFG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57320 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) This has been fixed by r204211 on the trunk, any reason to keep this PR open? Eh, really? That commit is supposed to change nothing except the graph dumper. Note that Steven's patch has been approved, but never committed: http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01020.html That patch is still necessary. I've simply forgotten about it. I don't have access to a machine to commit it this or next week. Much appreciated if you could take care of it!
[Bug target/60207] Wrong TFmode check in construct_container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60207 --- Comment #3 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Wed Feb 19 22:43:19 2014 New Revision: 207925 URL: http://gcc.gnu.org/viewcvs?rev=207925root=gccview=rev Log: Remove TFmode check for X86_64_INTEGER_CLASS Backport from mainline PR target/60207 * config/i386/i386.c (construct_container): Remove TFmode check for X86_64_INTEGER_CLASS. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c
[Bug target/60207] Wrong TFmode check in construct_container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60207 --- Comment #4 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Wed Feb 19 22:45:34 2014 New Revision: 207926 URL: http://gcc.gnu.org/viewcvs?rev=207926root=gccview=rev Log: Remove TFmode check for X86_64_INTEGER_CLASS Backport from mainline PR target/60207 * config/i386/i386.c (construct_container): Remove TFmode check for X86_64_INTEGER_CLASS. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/i386.c
[Bug target/60207] Wrong TFmode check in construct_container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60207 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.7.4 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- Fixed for 4.7.4, 4.8.3 and 4.9.0.
[Bug tree-optimization/60172] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #12 from Steven Bosscher steven at gcc dot gnu.org --- (In reply to Joey Ye from comment #11) Sometimes it helps to use -fdump-rtl-slim. Matter of taste but I find that much easier to interpret than LISP-like RTL dumps. Annotated good expansion: ;; _41 = _42 * 4; 20: r126=r1312 ;; _40 = _2 + _41; 21: r136=r130+r119 // r136=Arr_2_Par_Ref+r119 22: r125=r136+r126 // r125=Arr_2_Par_Ref+r119+r1312 ;; MEM[(int[25] *)_51 + 20B] = _34; 29: r139=r130+r119 // r139=Arr_2_Par_Ref+r119 30: r140=r139+r126 // r140=Arr_2_Par_Ref+r119+r1312 (==r125) 31: r141=r140+1000 // r141=Arr_2_Par_Ref+r119+r1312+1000 (==r125+1000) 32: [r141+20]=r124 In this case, the RHS for the SETs of r140 and r125 are lexically identical for value numbering, so the job for CSE is easy. Annotated bad expansion: ;; _40 = Arr_2_Par_Ref_22(D) + _12; 22: r138=r128+r121 23: r127=r132+r138 // r127=Arr_2_Par_Ref+r128+r121 ;; _32 = _20 + 1000; 29: r124=r121+1000 ;; MEM[(int[25] *)_51 + 20B] = _34; 32: r141=r132+r124 // r141=Arr_2_Par_Ref+r121+1000 33: r142=r141+r128 // r142=Arr_2_Par_Ref+r128+r121+1000 (==r127+1000) 34: [r142+20]=r126 Here, the +1000 confuses CSE. The sets of r127 and r142 have a common sub-expression as value, but none of the sub-expressions are lexically identical. RTL CSE has limited ability to look through sub-expressions to identify same value sub-expressions (anchors, base regs, etc.) but apparently this case is too complex for it to handle.
[Bug fortran/49397] [4.7/4.8/4.9 Regression] [F03] ICE with proc pointer assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49397 --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed Feb 19 23:32:46 2014 New Revision: 207927 URL: http://gcc.gnu.org/viewcvs?rev=207927root=gccview=rev Log: 2014-02-19 Tobias Burnus bur...@net-b.de PR fortran/49397 * expr.c (gfc_check_pointer_assign): Add check for F2008Cor2, C729. * trans-decl.c (gfc_get_symbol_decl): Correctly generate external decl in a corner case. 2014-02-19 Tobias Burnus bur...@net-b.de PR fortran/49397 * gfortran.dg/proc_ptr_45.f90: New. * gfortran.dg/proc_ptr_46.f90: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/proc_ptr_45.f90 branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/proc_ptr_46.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/expr.c branches/gcc-4_8-branch/gcc/fortran/trans-decl.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/60278] New: string::erase() (and other containers) does not take const_iterators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60278 Bug ID: 60278 Summary: string::erase() (and other containers) does not take const_iterators Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rscrihf at gmail dot com As of C++11, std::string::erase takes const_iterators in its signature. As of 4.8.2, this isn't the case. I see other bugs referencing similar issues - for instance, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54577 is marked as FIXED, but I see the signature of deque::erase is still wrong.
[Bug fortran/49397] [4.7/4.8/4.9 Regression] [F03] ICE with proc pointer assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49397 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.7.4 |4.8.3 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org --- Fixed on the trunk (4.9) and on the 4.8 branch. For 4.7, the valid test case fails due to other bugs. Thus, I decided it is not worthwhile to adapt the patch for 4.7. Hence, I close this bug as FIXED.
[Bug libstdc++/60278] string::erase() (and other containers) does not take const_iterators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60278 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- deque::erase() is fixed for 4.9, string will be fixed after 4.9
[Bug c/59933] for loop goes wild with assert() enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59933 --- Comment #13 from Ian Hamilton ian at g0tcd dot com --- (In reply to Mark Warner from comment #11) I'm confused .. what about.. for (k = i; k (int)(sizeof(NSQ_del_dec_struct) / sizeof(opus_int32)); ++k) ... is illegal or invalid ? Why does it only fail if -DDEBUG is defined ? I mean, this code worked fine for months .. and now What this code seems to be doing is copying a section at the end of the sLPC_Q14 array at the beginning of the NSQ_del_dec_struct structure, plus all the other structure members that follow the array (RandState[32], Q_Q10[32], etc.). It is doing this by deliberately running the sLPC_Q14 array index beyond the end of the array, i.e. it is RELYING on undefined behaviour. I'd have said your work-around solution is actually the better code.
[Bug c/60279] New: Incorrect column number for -Wuninitialized in return statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60279
Bug ID: 60279
Summary: Incorrect column number for -Wuninitialized in return
statement
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
I found the column number in the return statement of -Wuninitialized is not
correct.
$: cat s.c
int g(char *);
int f(void) {
char *s;
return g(s);
}
$: gcc-trunk -Wuninitialized -c s.c
s.c: In function ‘f’:
s.c:4:3: warning: ‘s’ is used uninitialized in this function [-Wuninitialized]
return g(s);
^
$: gcc-trunk --version
gcc-trunk (GCC) 4.9.0 20140217 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$:
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 --- Comment #24 from Jan Hubicka hubicka at ucw dot cz --- So, shall we just apply #c15 here? Diff works fine for me for over five weeks now, so I say yes. It is easier to just return at beggining instead of duplicating the check. Have patch for it, just for some reason I wanted to look deper into why we inline here. I forgot the reason, but will work it out again today. Honza
[Bug ipa/60243] IPA is slow on large cgraph tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243 --- Comment #10 from Jan Hubicka hubicka at ucw dot cz --- --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- estimate_calls_size_and_time is quite high on the profile - called via do_estimate_edge_size it walks callgraph edges O(n^2). It seems that the idea of having a cache is worse than devising an algorithm to compute sizes and times for the whole cgraph at once? Yep, the problem is that they are changing as the inlining progresses, since we propagate predicates on them on each inline. I will check the testcase.
[Bug c++/60065] [c++1y] ICE with auto parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60065 Adam Butcher abutcher at gcc dot gnu.org changed: What|Removed |Added CC||abutcher at gcc dot gnu.org --- Comment #1 from Adam Butcher abutcher at gcc dot gnu.org --- I think it is valid. It should be considered equivalent to: template int, typename... T void foo(T... x); Looks like the generic parameter pack 'auto...' is replacing the template argument list rather than extending it. I'll look into it.
[Bug c/59193] Unused postfix operator temporaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193 Max TenEyck Woodbury mtewoodbury at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- Severity|minor |trivial --- Comment #8 from Max TenEyck Woodbury mtewoodbury at gmail dot com --- Re: Manuel López-Ibáñez Yes, as soon as I feel that my efforts will not be ignored, as they have been so far... Re: Jakub Jelinek You admit that different 'tree codes' are generated, so there is a difference between the two sequences. You further admit that -O0 does do some optimization, otherwise the machine code emitted would store and discard the temporary value because that is what the language standard says should happen. While this is quite trivial in practice, it shows that you place your opinion over the exact semantics called for by the standard and lack the ability to see that. That is distinctly disturbing.
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555
--- Comment #25 from Jan Hubicka hubicka at ucw dot cz ---
It is easier to just return at beggining instead of duplicating the check.
Have patch for it, just for some reason
I wanted to look deper into why we inline here. I forgot the reason, but will
work it out again today.
OK, remember the reason, the inlining decisions did not make sense :)
It turned out to be very basic and apparently ages old profile updating but in
clone_inlined_nodes. This function is used when one inlines call a-b
and it produces clone of b to be inlined into a. It updates frequencies in
the clone, so if the edge is, say, executing twice per invocation of a,
the frequencies in b are doubled.
Now it may happen that b has inlined functions to it. In that case the function
recurses and inlines further. It stil updates frequencies on the same basis:
i.e. it takes average number of executions of edge per invocation and multiply.
This is completely wrong. If there is chain b-c-d-e all inlined and c is
executed at average 10 times per execution of b and c-d, the the frequenceis
of edge c-d-e are already scaled up 10fold.
The current logic sees edge c-d already multiplied and scale again causing
quite an explosion in frequencies.
Bootstrapping/regtesting x86_64-linux.
Index: ipa-inline.c
===
--- ipa-inline.c(revision 207870)
+++ ipa-inline.c(working copy)
@@ -708,6 +684,12 @@
if (outer_node-global.inlined_to)
caller_freq = outer_node-callers-frequency;
+ if (!caller_freq)
+{
+ reason = function is inlined and ulikely;
+ want_inline = false;
+}
+
if (!want_inline)
;
/* Inlining of self recursive function into copy of itself within other
function
Index: ipa-inline.h
===
--- ipa-inline.h(revision 207870)
+++ ipa-inline.h(working copy)
@@ -233,7 +234,8 @@
/* In ipa-inline-transform.c */
bool inline_call (struct cgraph_edge *, bool, veccgraph_edge_p *, int *,
bool);
unsigned int inline_transform (struct cgraph_node *);
-void clone_inlined_nodes (struct cgraph_edge *e, bool, bool, int *);
+void clone_inlined_nodes (struct cgraph_edge *e, bool, bool, int *,
+ int freq_scale = -1);
extern int ncalls_inlined;
extern int nfunctions_inlined;
Index: ipa-inline-transform.c
===
--- ipa-inline-transform.c(revision 207870)
+++ ipa-inline-transform.c(working copy)
@@ -127,11 +127,16 @@
the edge and redirect it to the new clone.
DUPLICATE is used for bookkeeping on whether we are actually creating new
clones or re-using node originally representing out-of-line function call.
- */
+ By default the offline copy is removed, when it appers dead after inlining.
+ UPDATE_ORIGINAL prevents this transformation.
+ If OVERALL_SIZE is non-NULL, the size is updated to reflect the
+ transformation.
+ FREQ_SCALE is implicit parameter used for internal bookeeping when
+ recursively copying functions inlined into the clone. */
void
clone_inlined_nodes (struct cgraph_edge *e, bool duplicate,
- bool update_original, int *overall_size)
+ bool update_original, int *overall_size, int freq_scale)
{
struct cgraph_node *inlining_into;
struct cgraph_edge *next;
@@ -171,12 +176,16 @@
duplicate = false;
e-callee-externally_visible = false;
update_noncloned_frequencies (e-callee, e-frequency);
+ gcc_assert (freq_scale == -1);
}
else
{
struct cgraph_node *n;
+
+ if (freq_scale == -1)
+freq_scale = e-frequency;
n = cgraph_clone_node (e-callee, e-callee-decl,
- e-count, e-frequency, update_original,
+ e-count, freq_scale, update_original,
vNULL, true, inlining_into);
cgraph_redirect_edge_callee (e, n);
}
@@ -191,7 +200,7 @@
{
next = e-next_callee;
if (!e-inline_failed)
-clone_inlined_nodes (e, duplicate, update_original, overall_size);
+clone_inlined_nodes (e, duplicate, update_original, overall_size,
freq_scale);
if (e-speculative !speculation_useful_p (e, true))
{
cgraph_resolve_speculation (e, NULL);
[Bug c++/60065] [c++1y] ICE with auto parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60065 --- Comment #2 from Adam Butcher abutcher at gcc dot gnu.org --- Turns out the base template parameter index was not been initialized correctly so it was trying to convert the 'int' parameter to a pack as well as the invented template parameter generated for the 'auto'. See http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01197.html
[Bug tree-optimization/60280] New: gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c failed caused by preserving loop structure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280
Bug ID: 60280
Summary: gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c
failed caused by preserving loop structure.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amker.cheng at gmail dot com
gcc.target/arm/ivopts-2.c is like:
/* { dg-do assemble } */
/* { dg-options -Os -fdump-tree-ivopts -save-temps } */
extern void foo2 (short*);
void
tr4 (short array[], int n)
{
int x;
if (n 0)
for (x = 0; x n; x++)
foo2 (array[x]);
}
/* { dg-final { scan-tree-dump-times PHI ivtmp 1 ivopts} } */
/* { dg-final { scan-tree-dump-times PHI 1 ivopts} } */
/* { dg-final { object-size text = 26 { target arm_thumb2 } } } */
/* { dg-final { cleanup-tree-dump ivopts } } */
/* { dg-final { cleanup-saved-temps ivopts } } */
Build with options: -mthumb -mcpu=cortex-a15 -c
The size of text section is 28, causing regression.
Same story happens to ivopts.c
[Bug tree-optimization/60280] gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c failed caused by preserving loop structure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280
--- Comment #1 from bin.cheng amker.cheng at gmail dot com ---
It's caused by patch at (revision r198333):
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01530.html
After patching, forwarder basic block 6 in below dump didn't get removed:
tr4 (short int * array, int n)
{
int x;
unsigned int x.0;
unsigned int _7;
short int * _9;
bb 2:
if (n_4(D) 0)
goto bb 6;
else
goto bb 5;
bb 3:
bb 4:
# x_14 = PHI x_11(3), 0(6)
x.0_6 = (unsigned int) x_14;
_7 = x.0_6 * 2;
_9 = array_8(D) + _7;
foo2 (_9);
x_11 = x_14 + 1;
if (x_11 n_4(D))
goto bb 3;
else
goto bb 5;
bb 5:
return;
bb 6:
goto bb 4;
}
After expanding, pre-header is filled with pre-loop initialization instructions
and the problem turns into a cfglayout problem:
5: NOTE_INSN_BASIC_BLOCK 2
2: r115:SI=r0:SI
REG_DEAD r0:SI
3: NOTE_INSN_DELETED
4: NOTE_INSN_FUNCTION_BEG
7: {cc:CC=cmp(r1:SI,0);r116:SI=r1:SI;}
REG_DEAD r1:SI
8: pc={(cc:CC0)?L24:pc}
REG_DEAD cc:CC
REG_BR_PROB 0x1f98
;; succ: 4
;; 5
29: L29:
13: NOTE_INSN_BASIC_BLOCK 3
14: r0:SI=r110:SI
15: call [`foo2'] argc:0
REG_DEAD r0:SI
16: r110:SI=r110:SI+0x2
18: cc:CC=cmp(r110:SI,r114:SI)
19: pc={(cc:CC!=0)?L29:pc}
REG_DEAD cc:CC
REG_BR_PROB 0x2333
;; succ: 3
;; 5
24: L24:
25: NOTE_INSN_BASIC_BLOCK 4
26: r110:SI=r115:SI
REG_DEAD r115:SI
27: NOTE_INSN_DELETED
28: r114:SI=r116:SI*0x2+r110:SI
REG_DEAD r116:SI
;; succ: 3
32: L32:
33: NOTE_INSN_BASIC_BLOCK 5
;; succ: EXIT
After outof_cfglayout, a jump (in bb3) to exit block is introduced:
5: NOTE_INSN_BASIC_BLOCK 2
3: NOTE_INSN_DELETED
4: NOTE_INSN_FUNCTION_BEG
7: {cc:CC=cmp(r1:SI,0);r1:SI=r1:SI;}
8: pc={(cc:CC0)?L24:pc}
REG_BR_PROB 0x1f98
;; succ: 6
;; 3
55: NOTE_INSN_BASIC_BLOCK 3
56: pc=L32
;; succ: 7
29: L29:
13: NOTE_INSN_BASIC_BLOCK 4
14: r0:SI=r4:SI
15: call [`foo2'] argc:0
16: r4:SI=r4:SI+0x2
18: cc:CC=cmp(r4:SI,r5:SI)
19: pc={(cc:CC!=0)?L29:pc}
REG_BR_PROB 0x2333
;; succ: 4
;; 5
58: NOTE_INSN_BASIC_BLOCK 5
59: pc=L32
;; succ: 7
24: L24:
25: NOTE_INSN_BASIC_BLOCK 6
26: r4:SI=r0:SI
27: NOTE_INSN_DELETED
28: r5:SI=r1:SI*0x2+r4:SI
61: pc=L29
;; succ: 4
32: L32:
33: NOTE_INSN_BASIC_BLOCK 7
;; succ: EXIT
Ideally, basic block reordering could fix this, but before that, pass
pro_and_epilogue threads jump in bb3 to a direct return instruction and bb
reordering can do nothing any more.
So:
1) Unless we can teach passes before pro_and_epilogue to do some bb reordering
work, it's inappropriate to fix it on RTL.
2) It's natural to be fixed on GIMPLE, but it's disruptive because the cfg
stuff are shared by all GIMPLE(even RTL) optimizers. Yet this method makes more
sense than 1).
I am trying to work out a less intrusive patch for stage 4.
[Bug tree-optimization/60279] Incorrect column number for -Wuninitialized in return statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60279 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-20 CC||mpolacek at gcc dot gnu.org Component|c |tree-optimization Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed, though this warning isn't generated by the C FE.
[Bug c/59193] Unused postfix operator temporaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Max TenEyck Woodbury from comment #8) Re: Jakub Jelinek You admit that different 'tree codes' are generated, so there is a difference between the two sequences. You further admit that -O0 does do some optimization, otherwise the machine code emitted would store and discard the temporary value because that is what the language standard says should happen. While this is quite trivial in practice, it shows that you place your opinion over the exact semantics called for by the standard and lack the ability to see that. That is distinctly disturbing. The language semantics != middle-end semantics. There is no temporary variable if the value is unused and will never be as it is expanded to ignore it if the resulting value is unused. This is the middle-end semantics of these tree codes. If the front-end wants the temporary variable always then it needs to do the assignment. The language semantics does not require a temporary variable to hold the value if the value is unused so the middle-end semantics of these tree codes fit the bill.
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 --- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org --- Thanks, but please fix the typoes: s/ulikely/unlikely/ s/appers/appears/ s/bookeeping/bookkeeping/ ?
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #27 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #26) Thanks, but please fix the typoes: s/typoes/typos
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 --- Comment #28 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #27) s/typoes/typos ;)
[Bug target/60204] struct with __m512i is mishandled in function parameter passing and return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60204 --- Comment #6 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Thu Feb 20 06:32:21 2014 New Revision: 207933 URL: http://gcc.gnu.org/viewcvs?rev=207933root=gccview=rev Log: gcc/ PR target/60204 * config/i386/i386.c (classify_argument): Pass structures of size 64 bytes or less in register. tessuite/gcc/ PR target/60204 * gcc.target/x86_64/abi/avx512f/test_passing_structs.c: Update to reflect abi fix. * gcc.target/x86_64/abi/avx512f/test_passing_unions.c: Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c trunk/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_unions.c
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 --- Comment #29 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Thu Feb 20 06:40:07 2014 New Revision: 207934 URL: http://gcc.gnu.org/viewcvs?rev=207934root=gccview=rev Log: PR ipa/58555 * ipa-inline-transform.c (clone_inlined_nodes): Add freq_scale parameter specifying the scaling. (inline_call): Update. (want_inline_recursively): Guard division by zero. (recursive_inlining): Update. * ipa-inline.h (clone_inlined_nodes): Update. * testsuite/g++.dg/torture/pr58555.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr58555.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-transform.c trunk/gcc/ipa-inline.c trunk/gcc/ipa-inline.h trunk/gcc/testsuite/ChangeLog
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #30 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed. Thanks.
Re: [testsuite] XFAIL gcc.dg/torture/pr60092.c execution on Solaris 11
On Tue, 18 Feb 2014, Rainer Orth wrote: As described in PR middle-end/60092, gcc.dg/torture/pr60092.c execution FAILs at -O0 on Solaris 11. posix_memalign modifies it's first arg in the error case, which is at least a QOI issue. Therefore I'd like to XFAIL the test like this. Tested with the appropriate runtest invocation on i386-pc-solaris2.10, i386-pc-solaris2.11, sparc-sun-solaris2.11, and x86_64-unknown-linux-gnu. Ok for mainline? Ok. Thanks, Richard. Rainer 2014-02-18 Rainer Orth r...@cebitec.uni-bielefeld.de * gcc.dg/torture/pr60092.c: xfail execution on *-*-solaris2.11* at -O0.
Re: [PATCH] Fix -ftrack-macro-expansion preprocessing of A######A (PR preprocessor/58844)
Jakub Jelinek ja...@redhat.com writes: Hi! The following testcase build with -ftrack-macro-expansion=0, but don't build otherwise. The problem seems to be that the libcpp for macro redefinition warning/error purposes if it sees more than one paste operator adds those extra CPP_PASTE tokens at the end, after normal tokens from the macro. For -ftrack-macro-expansion=0 we were using macro_real_token_count (macro) to only use the real tokens for macro expansion purposes, but for track_macro_expansion it used macro-count, which includes also the extra tokens. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk (and after a while for 4.8)? For what it's worth, this is OK for me, yes. Though I am just a casual contributor giving my point of view here. 2014-02-18 Jakub Jelinek ja...@redhat.com PR preprocessor/58844 * macro.c (enter_macro_context): Only push macro_real_token_count (macro) tokens rather than macro-count tokens, regardless of CPP_OPTION (pfile, track-macro-expansion). * c-c++-common/cpp/pr58844-1.c: New test. * c-c++-common/cpp/pr58844-2.c: New test. Thanks. -- Dodji
Re: FRE may run out of memory
Richard Biener-2 wrote On Fri, Feb 14, 2014 at 3:50 AM, dxq lt; ziyan01@ gt; wrote: What compiler version did you check? I think that 4.8 has improvements for 1. and 2. (SMS is unmaintained). Note that we only spent time to make -O1 behave sanely with extremely large functions. Finally I'd suggest you open a bugreport and attach a testcase to it that exposes the issues you list. Richard. hi Richard, We are working on gcc-4.7.1. seems that these issues have been fixed in gcc-4.8.3. BTW, we notice that Obstack is used in LIM for memory management, which is really a nice way, and also, we used Ostack to solve the GGC problem in our SMS-UNROLL framework, we put all backup into the Obstack, so it's safe now. http://gcc.1065356.n5.nabble.com/A-GGC-related-question-td988400.html Thanks! danxiaoqiang -- View this message in context: http://gcc.1065356.n5.nabble.com/FRE-may-run-out-of-memory-tp1009578p1012489.html Sent from the gcc - patches mailing list archive at Nabble.com.
Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs
On Tue, 18 Feb 2014, Richard Biener wrote: The following two pieces fix the fallout of 2013-05-22 Mark Mitchell m...@codesourcery.com Sandra Loosemore san...@codesourcery.com * configure.ac (dbexecdir): Base on $(toolexeclibdir), not $(libdir). ... that makes a wreck out of my 4.9-based libjava installs. First it avoids to break dbexecdir with MULTSUBDIR= by removing the redundant but non-version-specific-aware multilib addition. Second, it makes sure that gcc_version, used in the version-specific path, is defined at all in classpath/ and its subdirs. Tested for my particular configuration, I'll do a default, non-version-specific one as well (but expect no changes). Ok for trunk? In addition to my weird non-multilib version-specific variant I now tested regular non-version-specific and multilib variant as well as version-specific multilib variant and all looks ok. Thus, Ok for trunk? Thanks, Richard. Thanks, Richard. 2014-02-18 Richard Biener rguent...@suse.de PR libjava/60261 * configure.ac (dbexecdir): Remove redundant multilib addition. * Makefile.am (gcc_version): Export. * configure: Regenerate. * Makefile.in: Likewise. Index: libjava/configure.ac === --- libjava/configure.ac (revision 207837) +++ libjava/configure.ac (working copy) @@ -1596,15 +1596,7 @@ AC_DEFINE_UNQUOTED(GCJVERSION, $GCJVERS # Determine where the standard .db file and GNU Classpath JNI # libraries are found. gcjsubdir=gcj-$gcjversion-$libgcj_soversion -multi_os_directory=`$CC -print-multi-os-directory` -case $multi_os_directory in - .) - dbexecdir='$(toolexeclibdir)/'$gcjsubdir # Avoid /. - ;; - *) - dbexecdir='$(toolexeclibdir)/'$multi_os_directory/$gcjsubdir - ;; -esac +dbexecdir='$(toolexeclibdir)/'$gcjsubdir AC_SUBST(dbexecdir) AC_SUBST(gcjsubdir) Index: libjava/configure === --- libjava/configure (revision 207837) +++ libjava/configure (working copy) @@ -24016,15 +24016,7 @@ _ACEOF # Determine where the standard .db file and GNU Classpath JNI # libraries are found. gcjsubdir=gcj-$gcjversion-$libgcj_soversion -multi_os_directory=`$CC -print-multi-os-directory` -case $multi_os_directory in - .) - dbexecdir='$(toolexeclibdir)/'$gcjsubdir # Avoid /. - ;; - *) - dbexecdir='$(toolexeclibdir)/'$multi_os_directory/$gcjsubdir - ;; -esac +dbexecdir='$(toolexeclibdir)/'$gcjsubdir Index: libjava/Makefile.am === --- libjava/Makefile.am (revision 207837) +++ libjava/Makefile.am (working copy) @@ -6,6 +6,7 @@ ACLOCAL_AMFLAGS = -I . -I .. -I ../confi # May be used by various substitution variables. gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) +export gcc_version SUBDIRS = $(DIRLTDL) gcj include classpath if TESTSUBDIR Index: libjava/Makefile.in === --- libjava/Makefile.in (revision 207837) +++ libjava/Makefile.in (working copy) @@ -10581,6 +10581,7 @@ uninstall-am: uninstall-binPROGRAMS unin uninstall-libexecsubPROGRAMS uninstall-toolexeclibLTLIBRARIES \ uninstall-toolexecmainlibDATA +export gcc_version interpret.lo: AM_CXXFLAGS += -fwrapv prims.lo: AM_CXXFLAGS += -fno-omit-frame-pointer -- Richard Biener rguent...@suse.de SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendorffer
[PATCH] Fix up -save-temps with #pragma simd
Hi!
While fixing PR60267, I've noticed that #pragma simd is not registered
when -E -fcilkplus, even when it asks for macro replacements in the clauses.
So, either we have to register it even when preprocessing, so that say for
-save-temps, or other cases of separate preprocessing and separate
compilation you get the macro replacement in there, or #pragma simd doesn't
want to do macro replacement in the clauses, in that case it should call
the cpp_register_deferred_pragma function with false, false rather than
true, false. But then even #define N 8 ... #pragma simd vectorlength(N)
wouldn't work.
2014-02-19 Jakub Jelinek ja...@redhat.com
* c-pragma.c (c_pp_lookup_pragma): Handle PRAGMA_CILK_SIMD.
(init_pragma): Call cpp_register_deferred_pragma for PRAGMA_CILK_SIMD
even when flag_preprocess_only.
* c-c++-common/cilk-plus/PS/vectorlength-2.c: New test.
* c-c++-common/cilk-plus/PS/vectorlength-3.c: New test.
--- gcc/c-family/c-pragma.c.jj 2014-02-19 09:49:08.0 +0100
+++ gcc/c-family/c-pragma.c 2014-02-19 10:02:52.148421881 +0100
@@ -1221,6 +1221,13 @@ c_pp_lookup_pragma (unsigned int id, con
return;
}
+ if (id == PRAGMA_CILK_SIMD)
+{
+ *space = NULL;
+ *name = simd;
+ return;
+}
+
if (id = PRAGMA_FIRST_EXTERNAL
(id PRAGMA_FIRST_EXTERNAL + registered_pp_pragmas.length ()))
{
@@ -1384,7 +1391,7 @@ init_pragma (void)
omp_pragmas_simd[i].id, true, true);
}
- if (flag_cilkplus !flag_preprocess_only)
+ if (flag_cilkplus)
cpp_register_deferred_pragma (parse_in, NULL, simd, PRAGMA_CILK_SIMD,
true, false);
--- gcc/testsuite/c-c++-common/cilk-plus/PS/vectorlength-2.c.jj 2014-02-19
10:07:10.478961407 +0100
+++ gcc/testsuite/c-c++-common/cilk-plus/PS/vectorlength-2.c2014-02-19
10:07:57.005697907 +0100
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fcilkplus } */
+
+#define vl(n) vectorlength(2*n)
+void
+foo (int *a, int *b, int *c)
+{
+ int i;
+#pragma simd vl(4)
+ for (i = 0; i 64; i++)
+a[i] = b[i] * c[i];
+}
--- gcc/testsuite/c-c++-common/cilk-plus/PS/vectorlength-3.c.jj 2014-02-19
10:07:13.955941631 +0100
+++ gcc/testsuite/c-c++-common/cilk-plus/PS/vectorlength-3.c2014-02-19
10:07:49.812737607 +0100
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -fcilkplus -save-temps } */
+
+#define vl(n) vectorlength(2*n)
+void
+foo (int *a, int *b, int *c)
+{
+ int i;
+#pragma simd vl(4)
+ for (i = 0; i 64; i++)
+a[i] = b[i] * c[i];
+}
+
+/* { dg-final { cleanup-saved-temps } } */
Jakub
Re: [PATCH] Remove N^2 update-ssa calls in IPA SRA
On Mon, Feb 17, 2014 at 02:38:42PM +0100, Richard Biener wrote: This removes the update_ssa call in ipa_modify_call_arguments by keeping virtual SSA form up-to-date. It also avoids leaking the virtual SSA name defined by the replaced call (and thus keeping more than necessary memory live during early transforms). Bootstrap and regtest in progress on x86_64-unknown-linux-gnu, ok for trunk at this stage? (didn't come here with the compile-time issue but with the leaked SSA name, both would improve the general compile-time-hog/memory-usage regression) 2014-02-17 Richard Biener rguent...@suse.de * ipa-prop.c: Include stringpool.h and tree-ssanames.h. (ipa_modify_call_arguments): Emit an argument load explicitely and preserve virtual SSA form there and for the replacement call. Do not update SSA form nor free dominance info. Ok, thanks. Jakub
RE: [PATCH][4.8] Backport strict-volatile-bitfields fixes to 4.8
Ping ^ 4 -Original Message- From: Joey Ye [mailto:joey...@arm.com] Sent: Friday, February 14, 2014 9:58 To: gcc-patches@gcc.gnu.org Subject: RE: [PATCH][4.8] Backport strict-volatile-bitfields fixes to 4.8 Ping ^3 These fixes are very important to 4.8 ARM embedded users, as they rely on strict volatile bitfields a lot. Please let them in 4.8. -Original Message- From: Joey Ye [mailto:joey...@arm.com] Sent: Saturday, February 08, 2014 10:42 To: gcc-patches@gcc.gnu.org Subject: RE: [PATCH][4.8] Backport strict-volatile-bitfields fixes to 4.8 Ping ^ 2 OK to 4.8? -Original Message- From: Joey Ye [mailto:joey...@arm.com] Sent: Monday, January 20, 2014 10:47 To: gcc-patches@gcc.gnu.org Subject: RE: [PATCH][4.8] Backport strict-volatile-bitfields fixes to 4.8 Ping -Original Message- From: Joey Ye [mailto:joey...@arm.com] Sent: Thursday, January 16, 2014 16:28 To: gcc-patches@gcc.gnu.org Subject: [PATCH][4.8] Backport strict-volatile-bitfields fixes to 4.8 4.8 has a number of strict-volatile-bitfields issues that can be fixed by following patches. trunk@205899, 205898, 205897, 205896, 203003 Tested on x86_64 and arm without regression. OK to 4.8? 2013-09-28 Sandra Loosemore san...@codesourcery.com gcc/ * expr.h (extract_bit_field): Remove packedp parameter. * expmed.c (extract_fixed_bit_field): Remove packedp parameter from forward declaration. (store_split_bit_field): Remove packedp arg from calls to extract_fixed_bit_field. (extract_bit_field_1): Remove packedp parameter and packedp argument from recursive calls and calls to extract_fixed_bit_field. (extract_bit_field): Remove packedp parameter and corresponding arg to extract_bit_field_1. (extract_fixed_bit_field): Remove packedp parameter. Remove code to issue warnings. (extract_split_bit_field): Remove packedp arg from call to extract_fixed_bit_field. * expr.c (emit_group_load_1): Adjust calls to extract_bit_field. (copy_blkmode_from_reg): Likewise. (copy_blkmode_to_reg): Likewise. (read_complex_part): Likewise. (store_field): Likewise. (expand_expr_real_1): Likewise. * calls.c (store_unaligned_arguments_into_pseudos): Adjust call to extract_bit_field. * config/tilegx/tilegx.c (tilegx_expand_unaligned_load): Adjust call to extract_bit_field. * config/tilepro/tilepro.c (tilepro_expand_unaligned_load): Adjust call to extract_bit_field. * doc/invoke.texi (Code Gen Options): Remove mention of warnings and special packedp behavior from -fstrict-volatile-bitfields documentation. 2013-12-11 Bernd Edlinger bernd.edlin...@hotmail.de * expr.c (expand_assignment): Remove dependency on flag_strict_volatile_bitfields. Always set the memory access mode. (expand_expr_real_1): Likewise. 2013-12-11 Sandra Loosemore san...@codesourcery.com PR middle-end/23623 PR middle-end/48784 PR middle-end/56341 PR middle-end/56997 gcc/ * expmed.c (strict_volatile_bitfield_p): New function. (store_bit_field_1): Don't special-case strict volatile bitfields here. (store_bit_field): Handle strict volatile bitfields here instead. (store_fixed_bit_field): Don't special-case strict volatile bitfields here. (extract_bit_field_1): Don't special-case strict volatile bitfields here. (extract_bit_field): Handle strict volatile bitfields here instead. (extract_fixed_bit_field): Don't special-case strict volatile bitfields here. Simplify surrounding code to resemble that in store_fixed_bit_field. * doc/invoke.texi (Code Gen Options): Update -fstrict-volatile-bitfields description. gcc/testsuite/ * gcc.dg/pr23623.c: New test. * gcc.dg/pr48784-1.c: New test. * gcc.dg/pr48784-2.c: New test. * gcc.dg/pr56341-1.c: New test. * gcc.dg/pr56341-2.c: New test. * gcc.dg/pr56997-1.c: New test. * gcc.dg/pr56997-2.c: New test. * gcc.dg/pr56997-3.c: New test. 2013-12-11 Bernd Edlinger bernd.edlin...@hotmail.de Sandra Loosemore san...@codesourcery.com PR middle-end/23623 PR middle-end/48784 PR middle-end/56341 PR middle-end/56997 * expmed.c (strict_volatile_bitfield_p): Add bitregion_start and
Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs
On 02/19/2014 09:03 AM, Richard Biener wrote: On Tue, 18 Feb 2014, Richard Biener wrote: The following two pieces fix the fallout of 2013-05-22 Mark Mitchell m...@codesourcery.com Sandra Loosemore san...@codesourcery.com * configure.ac (dbexecdir): Base on $(toolexeclibdir), not $(libdir). ... that makes a wreck out of my 4.9-based libjava installs. First it avoids to break dbexecdir with MULTSUBDIR= by removing the redundant but non-version-specific-aware multilib addition. Second, it makes sure that gcc_version, used in the version-specific path, is defined at all in classpath/ and its subdirs. Tested for my particular configuration, I'll do a default, non-version-specific one as well (but expect no changes). Ok for trunk? In addition to my weird non-multilib version-specific variant I now tested regular non-version-specific and multilib variant as well as version-specific multilib variant and all looks ok. Thus, Ok for trunk? It may be that someone understands this, but I don't. What does this change do? Andrew.
Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs
On Wed, 19 Feb 2014, Andrew Haley wrote: On 02/19/2014 09:03 AM, Richard Biener wrote: On Tue, 18 Feb 2014, Richard Biener wrote: The following two pieces fix the fallout of 2013-05-22 Mark Mitchell m...@codesourcery.com Sandra Loosemore san...@codesourcery.com * configure.ac (dbexecdir): Base on $(toolexeclibdir), not $(libdir). ... that makes a wreck out of my 4.9-based libjava installs. First it avoids to break dbexecdir with MULTSUBDIR= by removing the redundant but non-version-specific-aware multilib addition. Second, it makes sure that gcc_version, used in the version-specific path, is defined at all in classpath/ and its subdirs. Tested for my particular configuration, I'll do a default, non-version-specific one as well (but expect no changes). Ok for trunk? In addition to my weird non-multilib version-specific variant I now tested regular non-version-specific and multilib variant as well as version-specific multilib variant and all looks ok. Thus, Ok for trunk? It may be that someone understands this, but I don't. What does this change do? It fixes breakage introduced by Sandras patch. In particular it avoids libjava to end up in random places: /usr/lib64/gcc/x86_64-suse-linux/ 4.9 gcj-4.9-15 lib64 logging.properties security /usr/lib64/gcc/x86_64-suse-linux/4.9/ ecj.jar include jvgenmainlibgcj.la libgcj.spec libgij.so ecj1 jc1 libgcj-tools.so libgcj.so libgcj_bc.so pkgconfig /usr/lib64/gcc/x86_64-suse-linux/gcj-4.9-15/ libjavamath.la libjavamath.so /usr/lib64/gcc/x86_64-suse-linux/lib64/gcj-4.9-15 classmap.db libjvm.la libjvm.so and changes that to /usr/lib64/gcc/x86_64-suse-linux/4.9/ ecj.jar include jvgenmainlibgcj.la libgcj.spec libgij.so ecj1 jc1 libgcj-tools.so libgcj.so libgcj_bc.so pkgconfig gcj-4.9-15 logging.properties security /usr/lib64/gcc/x86_64-suse-linux/4.9/gcj-4.9-15 classmap.db libjvm.la libjvm.so libjavamath.la libjavamath.so for --enable-version-specific-runtime-libs (no changes for without that option). Sandras patch was supposed to introduce support for --enable-version-specific-runtime-libs in libgcj (but obviously it failed, given the result above). With multilibs there is a 2nd gcj-4.9-15 inside /usr/lib64/gcc/x86_64-suse-linux/4.9/32/ with the patch. Hope this helps. Thanks, Richard.
[Patch, Fortran, OOP] PR 60232: The rank of the element in the structure constructor does not match that of the component
Hi all,
here is a small patch for an OOP-related rejects-valid problem, which
is technically not a regression, but I hope the patch is simple enough
to still make it into trunk.
The problem is this: When using a dimensionful function as an
EXPR_VARIABLE (e.g. as the target in a procedure pointer assignment),
we wrongly add a REF_ARRAY, because we are tricked to believe that the
expression is dimensionful (which is not the case). In the test case
at hand this problem appears in an OOP context, where we have a
dimensionful type-bound procedure, which then appears as the target to
the corresponding procedure-pointer component in the vtab.
The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-02-19 Janus Weil ja...@gcc.gnu.org
PR fortran/60232
* expr.c (gfc_get_variable_expr): Don't add REF_ARRAY for dimensionful
functions, which are used as procedure pointer target.
2014-02-19 Janus Weil ja...@gcc.gnu.org
PR fortran/60232
* gfortran.dg/typebound_proc_33.f90: New.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 207846)
+++ gcc/fortran/expr.c (working copy)
@@ -3962,9 +3962,10 @@ gfc_get_variable_expr (gfc_symtree *var)
e-symtree = var;
e-ts = var-n.sym-ts;
- if ((var-n.sym-as != NULL var-n.sym-ts.type != BT_CLASS)
- || (var-n.sym-ts.type == BT_CLASS CLASS_DATA (var-n.sym)
- CLASS_DATA (var-n.sym)-as))
+ if (var-n.sym-attr.flavor != FL_PROCEDURE
+ ((var-n.sym-as != NULL var-n.sym-ts.type != BT_CLASS)
+ || (var-n.sym-ts.type == BT_CLASS CLASS_DATA (var-n.sym)
+ CLASS_DATA (var-n.sym)-as)))
{
e-rank = var-n.sym-ts.type == BT_CLASS
? CLASS_DATA (var-n.sym)-as-rank : var-n.sym-as-rank;
! { dg-do compile }
!
! PR 60232: [OOP] The rank of the element in the structure constructor does not match that of the component
!
! Contributed by Antony Lewis ant...@cosmologist.info
module ObjectLists
implicit none
Type TObjectList
contains
procedure :: ArrayItem
end Type
contains
function ArrayItem(L) result(P)
Class(TObjectList) :: L
Class(TObjectList), pointer :: P(:)
end function
end module
use ObjectLists
implicit none
Type, extends(TObjectList):: TSampleList
end Type
contains
subroutine TSampleList_ConfidVal(L)
Class(TSampleList) :: L
end subroutine
end
! { dg-final { cleanup-modules ObjectLists } }
Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs
On 02/19/2014 09:34 AM, Richard Biener wrote: Sandras patch was supposed to introduce support for --enable-version-specific-runtime-libs in libgcj (but obviously it failed, given the result above). Sandra? You're very quiet. What say you? I don't want this ping-ponging. Andrew.
Re: [Patch, Fortran, OOP] PR 60232: The rank of the element in the structure constructor does not match that of the component
Hi Janus, Janus Weil wrote: The problem is this: When using a dimensionful function as an EXPR_VARIABLE (e.g. as the target in a procedure pointer assignment), we wrongly add a REF_ARRAY, because we are tricked to believe that the expression is dimensionful The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk? Looks good to me. Thanks for the patch! Tobias
[PATCH, ARM] Support ORN for DImode
Hi,
Patterns had previously been added to thumb2.md to support ORN, but only for
SImode.
This patch adds DImode support, to cover the full 64|64-64 operation and
the various 32|64-64 operations (see AND:DI variants that use NOT).
The patch comes with its own execution test and looks for correct number of
ORN instructions in the assembly.
Regressions passed.
OK for stage 1?
2014-02-19 Ian Bolton ian.bol...@arm.com
gcc/
* config/arm/thumb2.md (*iordi_notdi_di): New pattern.
(*iordi_notzesidi): New pattern.
(*iordi_notsesidi_di): New pattern.
testsuite/
* gcc.target/arm/iordi_notdi-1.c: New test.diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md
index 4f247f8..6a71fec 100644
--- a/gcc/config/arm/thumb2.md
+++ b/gcc/config/arm/thumb2.md
@@ -1366,6 +1366,79 @@
(set_attr type alu_reg)]
)
+; Constants for op 2 will never be given to these patterns.
+(define_insn_and_split *iordi_notdi_di
+ [(set (match_operand:DI 0 s_register_operand =r,r)
+ (ior:DI (not:DI (match_operand:DI 1 s_register_operand 0,r))
+ (match_operand:DI 2 s_register_operand r,0)))]
+ TARGET_THUMB2
+ #
+ TARGET_THUMB2 reload_completed
+ [(set (match_dup 0) (ior:SI (not:SI (match_dup 1)) (match_dup 2)))
+ (set (match_dup 3) (ior:SI (not:SI (match_dup 4)) (match_dup 5)))]
+
+ {
+operands[3] = gen_highpart (SImode, operands[0]);
+operands[0] = gen_lowpart (SImode, operands[0]);
+operands[4] = gen_highpart (SImode, operands[1]);
+operands[1] = gen_lowpart (SImode, operands[1]);
+operands[5] = gen_highpart (SImode, operands[2]);
+operands[2] = gen_lowpart (SImode, operands[2]);
+ }
+ [(set_attr length 8)
+ (set_attr predicable yes)
+ (set_attr predicable_short_it no)
+ (set_attr type multiple)]
+)
+
+(define_insn_and_split *iordi_notzesidi_di
+ [(set (match_operand:DI 0 s_register_operand =r,r)
+ (ior:DI (not:DI (zero_extend:DI
+(match_operand:SI 2 s_register_operand r,r)))
+ (match_operand:DI 1 s_register_operand 0,?r)))]
+ TARGET_THUMB2
+ #
+ ; (not (zero_extend...)) means operand0 will always be 0x
+ TARGET_THUMB2 reload_completed
+ [(set (match_dup 0) (ior:SI (not:SI (match_dup 2)) (match_dup 1)))
+ (set (match_dup 3) (const_int -1))]
+
+ {
+operands[3] = gen_highpart (SImode, operands[0]);
+operands[0] = gen_lowpart (SImode, operands[0]);
+operands[1] = gen_lowpart (SImode, operands[1]);
+ }
+ [(set_attr length 4,8)
+ (set_attr predicable yes)
+ (set_attr predicable_short_it no)
+ (set_attr type multiple)]
+)
+
+(define_insn_and_split *iordi_notsesidi_di
+ [(set (match_operand:DI 0 s_register_operand =r,r)
+ (ior:DI (not:DI (sign_extend:DI
+(match_operand:SI 2 s_register_operand r,r)))
+ (match_operand:DI 1 s_register_operand 0,r)))]
+ TARGET_THUMB2
+ #
+ TARGET_THUMB2 reload_completed
+ [(set (match_dup 0) (ior:SI (not:SI (match_dup 2)) (match_dup 1)))
+ (set (match_dup 3) (ior:SI (not:SI
+ (ashiftrt:SI (match_dup 2) (const_int 31)))
+ (match_dup 4)))]
+
+ {
+operands[3] = gen_highpart (SImode, operands[0]);
+operands[0] = gen_lowpart (SImode, operands[0]);
+operands[4] = gen_highpart (SImode, operands[1]);
+operands[1] = gen_lowpart (SImode, operands[1]);
+ }
+ [(set_attr length 8)
+ (set_attr predicable yes)
+ (set_attr predicable_short_it no)
+ (set_attr type multiple)]
+)
+
(define_insn *orsi_notsi_si
[(set (match_operand:SI 0 s_register_operand =r)
(ior:SI (not:SI (match_operand:SI 2 s_register_operand r))
diff --git a/gcc/testsuite/gcc.target/arm/iordi_notdi-1.c
b/gcc/testsuite/gcc.target/arm/iordi_notdi-1.c
new file mode 100644
index 000..cda9c0e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/iordi_notdi-1.c
@@ -0,0 +1,54 @@
+/* { dg-do run } */
+/* { dg-options -O2 -fno-inline --save-temps } */
+
+extern void abort (void);
+
+typedef long long s64int;
+typedef int s32int;
+typedef unsigned long long u64int;
+typedef unsigned int u32int;
+
+s64int
+iordi_notdi (s64int a, s64int b)
+{
+ return (a | ~b);
+}
+
+s64int
+iordi_notzesidi (s64int a, u32int b)
+{
+ return (a | ~(u64int) b);
+}
+
+s64int
+iordi_notsesidi (s64int a, s32int b)
+{
+ return (a | ~(s64int) b);
+}
+
+int main ()
+{
+ s64int a64 = 0xdeadbeefll;
+ s64int b64 = 0x4f4f0112ll;
+
+ u32int c32 = 0x01124f4f;
+ s32int d32 = 0xabbaface;
+
+ s64int z = iordi_notdi (a64, b64);
+ if (z != 0xb0b0feedll)
+abort ();
+
+ z = iordi_notzesidi (a64, c32);
+ if (z != 0xfeedb0b0ll)
+abort ();
+
+ z = iordi_notsesidi (a64, d32);
+ if (z != 0xdeadbeef54450531ll)
+abort ();
+
+ return 0;
+}
+
+/* { dg-final { scan-assembler-times orn\t 5 { target arm_thumb2 } } } */
+
+/* { dg-final { cleanup-saved-temps } } */
[Ada] Error recovery in task body
This patch fixes a crash in a task body with a single statement missing a terminating semicolon. The tree can be repaired locally so further compilation can proceed. Compiling libthr3.adb must yield: libthr3.adb:10:18: missing ; libthr3.adb:13:04: warning: no accept for entry Test --- procedure Libthr3 is task type TSK; task Driver is entry Test; end Driver; task body TSK is begin Driver.Test -- Missing ; gives GNAT BUG DETECTED box end TSK; task body Driver is P : access TSK; begin P := new TSK; end Driver; begin null; end Libthr3; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-02-19 Ed Schonberg schonb...@adacore.com * par-ch9.adb (P_Task): Add a null statement to produce a well-formed task body when due to a previous syntax error the statement list is empty. Index: par-ch9.adb === --- par-ch9.adb (revision 207879) +++ par-ch9.adb (working copy) @@ -144,6 +144,17 @@ end if; Parse_Decls_Begin_End (Task_Node); + +-- The statement list of a task body needs to include at least a +-- null statement, so if a parsing error produces an empty list, +-- patch it now. + +if + No (First (Statements (Handled_Statement_Sequence (Task_Node +then + Set_Statements (Handled_Statement_Sequence (Task_Node), + New_List (Make_Null_Statement (Token_Ptr))); +end if; end if; return Task_Node;
[Ada] Accept a constituent in a null dependency clause
This patch implements the following SPARK RM rule from 7.2.5 (3g): at least one of its constituents shall be denoted in the input_list of a null_dependency_clause; or -- Source -- -- null_dependency.ads package Null_Dependency with Abstract_State = (Input_State, Output_State) is procedure OK_1 with Global = (Input = Input_State), Depends = (null = Input_State); procedure OK_2 with Global = (Input = Input_State, Output = Output_State), Depends = (Output_State = Input_State); end Null_Dependency; -- null_dependency.adb package body Null_Dependency with Refined_State = (Input_State = (C1, C2), Output_State = (C3, C4)) is C1, C2, C3, C4 : Integer := 0; procedure OK_1 with Refined_Global = (Input = C1), Refined_Depends = (null = C1) is begin null; end OK_1; procedure OK_2 with Refined_Global = (Input = (C1, C2), Output = (C3, C4)), Refined_Depends = ((C3, C4) = C1, null= C2) is begin null; end OK_2; end Null_Dependency; - -- Compilation -- - $ gcc -c null_dependency.adb Tested on x86_64-pc-linux-gnu, committed on trunk 2014-02-19 Hristian Kirtchev kirtc...@adacore.com * sem_prag.adb (Check_Dependency_Clause): Account for the case where a state with a non-null refinement matches a null output list. Comment reformatting. (Inputs_Match): Copy a solitary input to avoid an assertion failure when trying to match the same input in multiple clauses. Index: sem_prag.adb === --- sem_prag.adb(revision 207879) +++ sem_prag.adb(working copy) @@ -21434,16 +21434,38 @@ elsif Has_Non_Null_Refinement (Dep_Id) then Has_Refined_State := True; - if Is_Entity_Name (Ref_Output) then + -- Account for the case where a state with a non-null + -- refinement matches a null output list: + + --Refined_State = (State_1 = (C1, C2), + --State_2 = (C3, C4)) + --Depends = (State_1 = State_2) + --Refined_Depends = (null= C3) + + if Nkind (Ref_Output) = N_Null + and then Inputs_Match + (Dep_Clause = Dep_Clause, + Ref_Clause = Ref_Clause, + Post_Errors = False) + then +Has_Constituent := True; + +-- Note that the search continues after the clause is +-- removed from the pool of candidates because it may +-- have been normalized into multiple simple clauses. + +Remove (Ref_Clause); + + -- Otherwise the output of the refinement clause must be + -- a valid constituent of the state: + + --Refined_State = (State = (C1, C2)) + --Depends = (State = input) + --Refined_Depends = (C1= input) + + elsif Is_Entity_Name (Ref_Output) then Ref_Id := Entity_Of (Ref_Output); --- The output of the refinement clause is a valid --- constituent of the state. Remove the clause from --- the pool of candidates if both input lists match. --- Note that the search continues because one clause --- may have been normalized into multiple clauses as --- per the example above. - if Ekind_In (Ref_Id, E_Abstract_State, E_Variable) and then Present (Encapsulating_State (Ref_Id)) and then Encapsulating_State (Ref_Id) = Dep_Id @@ -21453,6 +21475,12 @@ Post_Errors = False) then Has_Constituent := True; + + -- Note that the search continues after the clause + -- is removed from the pool of candidates because + -- it may have been normalized into multiple simple + -- clauses. + Remove (Ref_Clause); end if; end if; @@ -21819,12 +21847,13 @@ begin -- Construct a list of all refinement inputs. Note that the input -- list is copied because the algorithm modifies its contents and -
[Ada] Incorrect error on valid global refinement
This patch updates the analysis of aspect/pragma Refined_Global to interpret states and variables with an encapsulating state as constituents only when the related state has visible refinement. -- Source -- -- parent.ads package Parent with Abstract_State = State is procedure Dummy; private Var : Integer := 0 with Part_Of = State; end Parent; -- parent.adb with Parent.Priv_Child; package body Parent with Refined_State = (State = (Var, Parent.Priv_Child.Priv_State)) is procedure Dummy is begin null; end Dummy; end Parent; -- parent-priv_child.ads private package Parent.Priv_Child with Abstract_State = (Priv_State with Part_Of = State) is procedure OK (Param : Integer) with Global = (In_Out = (Var, Priv_State)); end Parent.Priv_Child; -- parent-priv_child.adb package body Parent.Priv_Child with Refined_State = (Priv_State = Priv_Var) is Priv_Var : Integer := 0; procedure OK (Param : Integer) with Refined_Global = (In_Out = (Var, Priv_Var)) is begin null; end OK; end Parent.Priv_Child; - -- Compilation -- - $ gcc -c parent-priv_child.adb Tested on x86_64-pc-linux-gnu, committed on trunk 2014-02-19 Hristian Kirtchev kirtc...@adacore.com * sem_prag.adb (Check_Refined_Global_Item): A state or variable acts as a constituent only it is part of an encapsulating state and the state has visible refinement. Index: sem_prag.adb === --- sem_prag.adb(revision 207884) +++ sem_prag.adb(working copy) @@ -22610,10 +22610,13 @@ -- Start of processing for Check_Refined_Global_Item begin --- The state or variable acts as a constituent of a state, collect --- it for the state completeness checks performed later on. +-- When the state or variable acts as a constituent of another +-- state with a visible refinement, collect it for the state +-- completeness checks performed later on. -if Present (Encapsulating_State (Item_Id)) then +if Present (Encapsulating_State (Item_Id)) + and then Has_Visible_Refinement (Encapsulating_State (Item_Id)) +then if Global_Mode = Name_Input then Add_Item (Item_Id, In_Constits);
[Ada] GNAT driver and externally built library project files
When the GNAT driver is invoked to bind a main of a project file, and there are externally built library projects in the closure of the main project file, the invocation of gnatbind may fail if the object directory does not contain any ALI files. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-02-19 Vincent Celier cel...@adacore.com * gnatcmd.adb (GNATCmd): Always replace the object dirs of imported library projects with the library ALI dirs, when setting the object paths. * prj-env.ads (Ada_Objects_Path): Correct comments about argument Including_Libraries. Index: gnatcmd.adb === --- gnatcmd.adb (revision 207879) +++ gnatcmd.adb (working copy) @@ -1040,6 +1040,7 @@ accept project file switches -vPx, -Pprj and -Xnam=val); New_Line; end Non_VMS_Usage; + -- -- Process_Link -- -- @@ -2106,7 +2107,7 @@ -- Set up the env vars for project path files Prj.Env.Set_Ada_Paths - (Project, Project_Tree, Including_Libraries = False); + (Project, Project_Tree, Including_Libraries = True); -- For gnatcheck, gnatstub, gnatmetric, gnatpp and gnatelim, create -- a configuration pragmas file, if necessary. Index: prj-env.adb === --- prj-env.adb (revision 207879) +++ prj-env.adb (working copy) @@ -1681,8 +1681,6 @@ Path : Path_Name_Type; begin - -- ??? This is almost the equivalent of For_All_Source_Dirs - if Process_Source_Dirs then -- Add to path all source directories of this project if there are Index: prj-env.ads === --- prj-env.ads (revision 207879) +++ prj-env.ads (working copy) @@ -92,7 +92,7 @@ Including_Libraries : Boolean := True) return String_Access; -- Get the ADA_OBJECTS_PATH of a Project file. For the first call with the -- exact same parameters, compute it and cache it. When Including_Libraries - -- is False, the object directory of a library project is replaced with the + -- is True, the object directory of a library project is replaced with the -- library ALI directory of this project (usually the library directory of -- the project, except when attribute Library_ALI_Dir is declared) except -- when the library ALI directory does not contain any ALI file.
Re: [PATCH] Fixing SEH exceptions for languages != C++
Am Tue, 18 Feb 2014 17:51:00 +0100 schrieb Kai Tietz ktiet...@googlemail.com: So patch is ok with proper ChangeLog mentioning PR. Patch is ok for back-port too. I wonder if the instaned of RtlUnwindEx that come before the patched line should be changed as well, though. -- Jonathan
[Ada] Missing parentheses on [Refined_]Global and [Refined_]Depends
This patch modifies the parser to detect missing parentheses on SPARK aspects Global, Depends, Refined_Global and Refined_Depends. -- Source -- -- malformed_contracts.ads package Malformed_Contracts with Abstract_State = (State_1, State_2) is procedure OK_1 with Global = State_1; procedure OK_2 with Global = (State_1, State_2); procedure Error_0 with Global = State_1, State_2; procedure Error_1 with Global = Input = State_1; procedure Error_2 with Global = (Input = State_1; procedure Error_3 with Global = Input = State_1, In_Out = State_2; procedure Error_4 with Global = (Input = State_1, In_Out = State_2; procedure Error_5 with Global = (In_Out = State_1), Depends = State_1 = State_1; procedure Error_6 with Global = (In_Out = State_1), Depends = (State_1 = State_1; procedure Error_7 with Global = (Input = State_1, In_Out = State_2), Depends = State_2 = State_1, null = State_2; procedure Error_8 with Global = (Input = State_1, In_Out = State_2), Depends = (State_2 = State_1, null = State_2; end Malformed_Contracts; -- Compilation and output -- $ gcc -c malformed_contracts.ads malformed_contracts.ads:11:21: missing ( malformed_contracts.ads:14:21: missing ( malformed_contracts.ads:17:38: ; should be , malformed_contracts.ads:20:21: missing ( malformed_contracts.ads:23:57: ; should be , malformed_contracts.ads:27:23: missing ( malformed_contracts.ads:31:41: ; should be , malformed_contracts.ads:35:23: missing ( malformed_contracts.ads:39:60: missing ) Tested on x86_64-pc-linux-gnu, committed on trunk 2014-02-19 Hristian Kirtchev kirtc...@adacore.com * par.adb Alphabetize the routines in Par.Sync. (Resync_Past_Malformed_Aspect): New routine. * par-ch13.adb (Get_Aspect_Specifications): Alphabetize local variables. Code and comment reformatting. Detect missing parentheses on aspects [Refined_]Global and [Refined_]Depends with a non-null definition. * par-sync.adb: Alphabetize all routines in this separate unit. (Resync_Past_Malformed_Aspect): New routine. Index: par-sync.adb === --- par-sync.adb(revision 207879) +++ par-sync.adb(working copy) @@ -148,47 +148,75 @@ end if; end Resync_Init; - --- - -- Resync_Past_Semicolon -- - --- + -- + -- Resync_Past_Malformed_Aspect -- + -- - procedure Resync_Past_Semicolon is + procedure Resync_Past_Malformed_Aspect is begin Resync_Init; loop - -- Done if we are at a semicolon + -- A comma may separate two aspect specifications, but it may also + -- delimit multiple arguments of a single aspect. - if Token = Tok_Semicolon then -Scan; -- past semicolon + if Token = Tok_Comma then +declare + Scan_State : Saved_Scan_State; + +begin + Save_Scan_State (Scan_State); + Scan; -- past comma + + -- The identifier following the comma is a valid aspect, the + -- current malformed aspect has been successfully skipped. + + if Token = Tok_Identifier + and then Get_Aspect_Id (Token_Name) /= No_Aspect + then + Restore_Scan_State (Scan_State); + exit; + + -- The comma is delimiting multiple arguments of an aspect + + else + Restore_Scan_State (Scan_State); + end if; +end; + + -- An IS signals the last aspect specification when the related + -- context is a body. + + elsif Token = Tok_Is then exit; - -- Done if we are at a token which normally appears only after - -- a semicolon. One special glitch is that the keyword private is - -- in this category only if it does NOT appear after WITH. + -- A semicolon signals the last aspect specification - elsif Token in Token_Class_After_SM -and then (Token /= Tok_Private or else Prev_Token /= Tok_With) - then + elsif Token = Tok_Semicolon then exit; - -- Otherwise keep going + -- In the case of a mistyped semicolon, any token which follows a + -- semicolon signals the last aspect specification. - else -Scan; + elsif Token in Token_Class_After_SM then +exit; end if; + + -- Keep on resyncing + + Scan; end loop; -- Fall out of loop with resynchronization complete
[Ada] Semantics of attribute 'Old in aspect/pragma Contract_Cases
This patch implements rule SPARK RM 6.1.3 (5) which states: If an Old attribute_reference occurs within a consequence other than the consequence selected for (later) evaluation as described above, then the associated implicit constant declaration (see Ada RM 6.1.1) is not elaborated. [In particular, the prefix of the Old attribute_reference is not evaluated]. -- Source -- -- old_evaluation.ads package Old_Evaluation is procedure Reset_Self; function Self (Val : Integer) return Integer; procedure Check_Old (Val : in out Integer) with Contract_Cases = (Val 0 = Val = Self (Val)'Old - 1, Val = 0 = Val = Self (Val)'Old, Val 0 = Val = Self (Val)'Old + 1); end Old_Evaluation; -- old_evaluation.adb package body Old_Evaluation is Self_Called : Boolean := False; procedure Check_Old (Val : in out Integer) is begin if Val 0 then Val := Val - 1; elsif Val 0 then Val := Val + 1; end if; end Check_Old; procedure Reset_Self is begin Self_Called := False; end Reset_Self; function Self (Val : Integer) return Integer is begin if Self_Called then raise Program_Error; else Self_Called := True; return Val; end if; end Self; end Old_Evaluation; -- old_main.adb with Ada.Text_IO;use Ada.Text_IO; with Old_Evaluation; use Old_Evaluation; procedure Old_Main is procedure Test_Value (Val : Integer) is Num : Integer := Val; begin Reset_Self; Check_Old (Num); exception when others = Put_Line (ERROR: Val'Img failed); end Test_Value; begin Test_Value (-2); Test_Value (0); Test_Value (5); end Old_Main; - -- Compilation -- - $ gnatmake -q -gnata old_main.adb $ ./old_main Tested on x86_64-pc-linux-gnu, committed on trunk 2014-02-19 Hristian Kirtchev kirtc...@adacore.com * exp_ch6.adb Add with and use clause for Exp_Prag. (Expand_Contract_Cases): Relocated to Exp_Prag. * exp_ch6.ads (Expand_Contract_Cases): Relocated to Exp_Prag. * exp_prag.adb Add with and use clauses for Checks and Validsw. (Expand_Contract_Cases): Relocated from Exp_Ch6. Update the structure of the expanded code to showcase the evaluation of attribute 'Old prefixes. Add local variable Old_Evals. Expand any attribute 'Old references found within a consequence. Add circuitry to evaluate the prefixes of attribute 'Old that belong to a selected consequence. (Expand_Old_In_Consequence): New routine. * exp_prag.ads (Expand_Contract_Cases): Relocated from Exp_Ch6. * sem_attr.adb (Check_Use_In_Contract_Cases): Warn that a potentially unevaluated prefix is always evaluated. Index: exp_ch6.adb === --- exp_ch6.adb (revision 207890) +++ exp_ch6.adb (working copy) @@ -41,6 +41,7 @@ with Exp_Dist; use Exp_Dist; with Exp_Intr; use Exp_Intr; with Exp_Pakd; use Exp_Pakd; +with Exp_Prag; use Exp_Prag; with Exp_Tss; use Exp_Tss; with Exp_Util; use Exp_Util; with Exp_VFpt; use Exp_VFpt; @@ -4118,476 +4119,6 @@ end if; end Expand_Call; - --- - -- Expand_Contract_Cases -- - --- - - -- Pragma Contract_Cases is expanded in the following manner: - - --subprogram S is - -- Flag_1 : Boolean := False; - -- . . . - -- Flag_N : Boolean := False; - -- Flag_N+1 : Boolean := False; -- when others present - -- Count: Natural := 0; - - -- preconditions (if any) - - -- if Case_Guard_1 then - -- Flag_1 := True; - -- Count := Count + 1; - -- end if; - -- . . . - -- if Case_Guard_N then - -- Flag_N := True; - -- Count := Count + 1; - -- end if; - - -- if Count = 0 then - -- raise Assertion_Error with xxx contract cases incomplete; - --or - -- Flag_N+1 := True; -- when others present - - -- elsif Count 1 then - -- declare - -- Str0 : constant String := - -- contract cases overlap for subprogram ABC; - -- Str1 : constant String := - -- (if Flag_1 then - -- Str0 case guard at xxx evaluates to True - -- else Str0); - -- StrN : constant String := - -- (if Flag_N then - -- StrN-1 case guard at xxx evaluates to True - -- else StrN-1); - -- begin - -- raise Assertion_Error with StrN; - -- end; - -- end if; - - -- procedure _Postconditions is - -- begin - --
[Ada] Fix removal of side-effects in GNATprove mode
In the GNATprove mode for formal verification, side-effects are removed from expressions when the corresponding procedure is called in the frontend. This should only be done when not inside a generic, which is both useless and harmful as it deactivates the mechanism for name resolution of generic instances. Now fixed. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-02-19 Yannick Moy m...@adacore.com * exp_util.adb (Remove_Side_Effects): Do not remove side-effects inside a generic. Index: exp_util.adb === --- exp_util.adb(revision 207892) +++ exp_util.adb(working copy) @@ -6638,9 +6638,12 @@ begin -- Handle cases in which there is nothing to do. In GNATprove mode, -- removal of side effects is useful for the light expansion of - -- renamings. + -- renamings. This removal should only occur when not inside a + -- generic and not doing a pre-analysis. - if not (Expander_Active or (Full_Analysis and GNATprove_Mode)) then + if not Expander_Active +and (Inside_A_Generic or not Full_Analysis or not GNATprove_Mode) + then return; end if;
[Ada] Legality rules for Synchronization aspect on protected operations
This patch detects additional errors when a Synchronization aspect on an overriding protected operation does not match the given aspect on the overridden operation of an ancestor interface. Compiling b95000g.ads must yield: b95000g.ads:29:13: type Lock_Type must implement abstract subprogram Unlock with a procedure b95000g.ads:30:17: overriding operation Unlock_2 must have synchronization BY_PROTECTED_PROCEDURE b95000g.ads:32:17: type Lock_Type must implement abstract subprogram Lock with an entry b95000g.ads:33:17: overriding operation Lock_2 must have syncrhonization OPTIONAL b95000g.ads:38:14: overriding operation Try_Lock must have syncrhonization OPTIONAL --- -- B95000G.A -- --* -- -- OBJECTIVE: -- Check that primitive procedures of synchronized interfaces with -- a Synchronization aspect cannot be completed with different callable -- entity, or can have conflicting -- -- CHANGE HISTORY: -- 16 Nov 13 GRB Initial version --! package B95000G is type Spinlock is synchronized interface; procedure Unlock (L : in out Spinlock) is abstract with Synchronization = By_Protected_Procedure; procedure Lock (L : in out Spinlock) is abstract with Synchronization = By_Entry; procedure Try_Lock (L : in out Spinlock; Success : out Boolean) is abstract with Synchronization = Optional; procedure Unlock_2 (L : in out Spinlock) is abstract with Synchronization = By_Protected_Procedure; procedure Lock_2 (L : in out Spinlock) is abstract with Synchronization = Optional; protected type Lock_Type is new Spinlock with entry Unlock; -- ERROR: must be protected procedure procedure Unlock_2 with Synchronization = Optional; -- ERROR: should be By_Prot_Proc procedure Lock; -- ERROR: must be entry procedure Lock_2 with Synchronization = By_Entry; -- ERROR: is procedure private Unlocked : Boolean := True; end Lock_Type; procedure Try_Lock (L : in out Lock_Type; Success : out Boolean) with Synchronization = By_Entry; -- ERROR: is procedure end B95000G; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-02-19 Ed Schonberg schonb...@adacore.com * sem_ch3.adb (Check_Pragma_Implemented): Detect additional errors when a Synchronization aspect on an overriding protected operation does not match the given aspect on the overridden operation of an ancestor interface. Index: sem_ch3.adb === --- sem_ch3.adb (revision 207879) +++ sem_ch3.adb (working copy) @@ -9377,7 +9377,26 @@ Error_Msg_NE (type must implement abstract subprogram with a procedure, Subp_Alias, Contr_Typ); + +elsif Present (Get_Rep_Pragma (Impl_Subp, Name_Implemented)) + and then Implementation_Kind (Impl_Subp) /= Impl_Kind +then + Error_Msg_Name_1 := Impl_Kind; + Error_Msg_N +(overriding operation must have synchronization%, + Subp_Alias); end if; + + -- If primitive has Optional synchronization, overriding operation + -- must match if it has an explicit synchronization.. + + elsif Present (Get_Rep_Pragma (Impl_Subp, Name_Implemented)) + and then Implementation_Kind (Impl_Subp) /= Impl_Kind + then + Error_Msg_Name_1 := Impl_Kind; + Error_Msg_N +(overriding operation must have syncrhonization%, + Subp_Alias); end if; end Check_Pragma_Implemented;
Re: [PING] [PATCH] _Cilk_for for C and C++
On Wed, Feb 19, 2014 at 04:43:06AM +, Iyer, Balaji V wrote:
Attached, please find a patch with the test case attached (for1.cc). The
patch is the same but the cp-changelog has been modified to reflect the
new test-case. Is this OK to install?
1) have you tested the patch at all? I see
FAIL: g++.dg/gomp/for-1.C -std=c++98 (test for errors, line 27)
FAIL: g++.dg/gomp/for-1.C -std=c++98 (test for excess errors)
FAIL: g++.dg/gomp/for-1.C -std=c++11 (test for errors, line 27)
FAIL: g++.dg/gomp/for-1.C -std=c++11 (test for excess errors)
FAIL: g++.dg/gomp/for-19.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/gomp/for-19.C -std=gnu++98 (test for warnings, line 30)
FAIL: g++.dg/gomp/for-19.C -std=gnu++98 (test for warnings, line 37)
FAIL: g++.dg/gomp/for-19.C -std=gnu++98 (test for warnings, line 40)
FAIL: g++.dg/gomp/for-19.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/gomp/for-19.C -std=gnu++11 (internal compiler error)
FAIL: g++.dg/gomp/for-19.C -std=gnu++11 (test for warnings, line 30)
FAIL: g++.dg/gomp/for-19.C -std=gnu++11 (test for warnings, line 37)
FAIL: g++.dg/gomp/for-19.C -std=gnu++11 (test for warnings, line 40)
FAIL: g++.dg/gomp/for-19.C -std=gnu++11 (test for excess errors)
regressions caused by the patch, that is of course unacceptable.
2) try this updated cf3.cc, e.g. with -O2 -fcilkplus if you can't find out
why calling something multiple times is a bad idea, actually the latest patch
is even worse than the older one, you now create 3 calls to the end method
and 3 calls to operator-. There should be just one call to that, before the
#pragma omp parallel obviously, anything that doesn't do that is just bad.
I don't see a point in having if clause on the _Cilk_for, just keep it on
the #pragma omp parallel only, at ompexp time you can easily find it there,
there is no point to check it again in the parallel body of the function.
typedef __PTRDIFF_TYPE__ ptrdiff_t;
template typename T
class I
{
public:
typedef ptrdiff_t difference_type;
I ();
~I ();
I (T *);
I (const I );
T operator * ();
T *operator - ();
T operator [] (const difference_type ) const;
I operator = (const I );
I operator ++ ();
I operator ++ (int);
I operator -- ();
I operator -- (int);
I operator += (const difference_type );
I operator -= (const difference_type );
I operator + (const difference_type ) const;
I operator - (const difference_type ) const;
template typename S friend bool operator == (IS , IS );
template typename S friend bool operator == (const IS , const IS );
template typename S friend bool operator (IS , IS );
template typename S friend bool operator (const IS , const IS );
template typename S friend bool operator = (IS , IS );
template typename S friend bool operator = (const IS , const IS );
template typename S friend bool operator (IS , IS );
template typename S friend bool operator (const IS , const IS );
template typename S friend bool operator = (IS , IS );
template typename S friend bool operator = (const IS , const IS );
template typename S friend typename IS::difference_type operator - (IS
, IS );
template typename S friend typename IS::difference_type operator - (const
IS , const IS );
template typename S friend IS operator + (typename IS::difference_type
, const IS );
private:
T *p;
};
template typename T IT::I () : p (0) {}
template typename T IT::~I () {}
template typename T IT::I (T *x) : p (x) {}
template typename T IT::I (const I x) : p (x.p) {}
template typename T T IT::operator * () { return *p; }
template typename T T *IT::operator - () { return p; }
template typename T T IT::operator [] (const difference_type x) const {
return p[x]; }
template typename T IT IT::operator = (const I x) { p = x.p; return
*this; }
template typename T IT IT::operator ++ () { ++p; return *this; }
template typename T IT IT::operator ++ (int) { return I (p++); }
template typename T IT IT::operator -- () { --p; return *this; }
template typename T IT IT::operator -- (int) { return I (p--); }
template typename T IT IT::operator += (const difference_type x) { p +=
x; return *this; }
template typename T IT IT::operator -= (const difference_type x) { p -=
x; return *this; }
template typename T IT IT::operator + (const difference_type x) const {
return I (p + x); }
template typename T __attribute__((noinline)) IT IT::operator - (const
difference_type x) const { __asm (); return I (p - x); }
template typename T bool operator == (IT x, IT y) { return x.p == y.p; }
template typename T bool operator == (const IT x, const IT y) { return
x.p == y.p; }
template typename T bool operator != (IT x, IT y) { return !(x == y); }
template typename T bool operator != (const IT x, const IT y) { return
!(x == y); }
template typename T bool operator (IT x, IT y) { return x.p y.p; }
template typename T bool operator (const IT x, const IT y) { return
x.p y.p; }
template typename T bool operator = (IT x, IT y) { return x.p = y.p; }
Re: [Patch, Fortran, OOP] PR 60232: The rank of the element in the structure constructor does not match that of the component
Hi, The problem is this: When using a dimensionful function as an EXPR_VARIABLE (e.g. as the target in a procedure pointer assignment), we wrongly add a REF_ARRAY, because we are tricked to believe that the expression is dimensionful The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk? Looks good to me. Thanks for the patch! thanks. Committed as r207896. Cheers, Janus
Re: [patch] Fix wrong code with VCE to bit-field type at -O
Woudln't it be better to do this in the series of conversions, that is inside the preceeding if-statement? (the integral type case using convert_modes looks weird enough, so adding this kind-of less weird one there looks sensible) Yes, the integral type case is very strange: it was introduced in r103660 as + /* If both modes are integral, then we can convert from one to the +other. */ + else if (SCALAR_INT_MODE_P (GET_MODE (op0)) + SCALAR_INT_MODE_P (TYPE_MODE (type))) + op0 = convert_modes (TYPE_MODE (type), GET_MODE (op0), op0, +TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (exp, 0; which was very problematic (to say the least), so I've restricted it to integral types in r158675. I don't think that we should touch it here. Something like the attached patch? This seems to work fine too. Ok with moving it there (before the else if (!MEM_P (op0))). You probably want to guard with INTEGRAL_TYPE_P (type) as well, not only GET_MODE (op0) != mode - just to prepare for weird stuff like a vector-type where TYPE_PRECISION means sth else. It's already guarded since reduce_bit_field = INTEGRAL_TYPE_P (type). -- Eric BotcazouIndex: expr.c === --- expr.c (revision 207796) +++ expr.c (working copy) @@ -10436,6 +10436,11 @@ expand_expr_real_1 (tree exp, rtx target else if (INTEGRAL_TYPE_P (type) INTEGRAL_TYPE_P (TREE_TYPE (treeop0))) op0 = convert_modes (mode, GET_MODE (op0), op0, TYPE_UNSIGNED (TREE_TYPE (treeop0))); + /* If the output type is a bit-field type, do an extraction. */ + else if (reduce_bit_field) + return extract_bit_field (op0, TYPE_PRECISION (type), 0, + TYPE_UNSIGNED (type), NULL_RTX, + mode, mode); /* As a last resort, spill op0 to memory, and reload it in a different mode. */ else if (!MEM_P (op0))
[PATCH] Allow cfgcleanup to remove forwarder loop preheaders and latches
This allows cfgcleanup to remove some of the extra CFG that exists
just for loop analysis passes convenience (those can be and are
easily re-created by passes doing loop_optimizer_init ()).
It may fix a regression uncovered in private communication.
Untested - my original idea how to fix this (tree_forwarder_block_p
hunk) ran into the issue in remove_forwarder_block which causes
loops to be removed / re-discovered (losing meta-data).
Richard.
2014-02-19 Richard Biener rguent...@suse.de
* tree-cfgcleanup.c (tree_forwarder_block_p): Protect
latches and preheaders only if requested.
(remove_forwarder_block): Update loop structure if we
removed a forwarder that is a loop latch.
Index: gcc/tree-cfgcleanup.c
===
*** gcc/tree-cfgcleanup.c (revision 207878)
--- gcc/tree-cfgcleanup.c (working copy)
*** tree_forwarder_block_p (basic_block bb,
*** 307,321
if (current_loops)
{
! basic_block dest;
! /* Protect loop latches, headers and preheaders. */
if (bb-loop_father-header == bb)
return false;
- dest = EDGE_SUCC (bb, 0)-dest;
! if (dest-loop_father-header == dest)
return false;
}
return true;
}
--- 307,324
if (current_loops)
{
! /* Protect loop headers. */
if (bb-loop_father-header == bb)
return false;
! /* Protect loop latches and preheaders if requested. */
! basic_block dest = EDGE_SUCC (bb, 0)-dest;
! if (dest-loop_father-header == dest
! (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
! || loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)))
return false;
}
+
return true;
}
*** remove_forwarder_block (basic_block bb)
*** 497,503
set_immediate_dominator (CDI_DOMINATORS, dest, dom);
}
! /* And kill the forwarder block. */
delete_basic_block (bb);
return true;
--- 500,511
set_immediate_dominator (CDI_DOMINATORS, dest, dom);
}
! /* And kill the forwarder block, but first adjust its parent loop
! latch info as otherwise the cfg hook has a hard time not to
! kill the loop. */
! if (current_loops
!bb-loop_father-latch == bb)
! bb-loop_father-latch = dest;
delete_basic_block (bb);
return true;
Re: [patch] Fix wrong code with VCE to bit-field type at -O
On Wed, Feb 19, 2014 at 12:55 PM, Eric Botcazou ebotca...@adacore.com wrote: Woudln't it be better to do this in the series of conversions, that is inside the preceeding if-statement? (the integral type case using convert_modes looks weird enough, so adding this kind-of less weird one there looks sensible) Yes, the integral type case is very strange: it was introduced in r103660 as + /* If both modes are integral, then we can convert from one to the +other. */ + else if (SCALAR_INT_MODE_P (GET_MODE (op0)) + SCALAR_INT_MODE_P (TYPE_MODE (type))) + op0 = convert_modes (TYPE_MODE (type), GET_MODE (op0), op0, +TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (exp, 0; which was very problematic (to say the least), so I've restricted it to integral types in r158675. I don't think that we should touch it here. Something like the attached patch? This seems to work fine too. Yes. That looks fine. Thanks, Richard. Ok with moving it there (before the else if (!MEM_P (op0))). You probably want to guard with INTEGRAL_TYPE_P (type) as well, not only GET_MODE (op0) != mode - just to prepare for weird stuff like a vector-type where TYPE_PRECISION means sth else. It's already guarded since reduce_bit_field = INTEGRAL_TYPE_P (type). -- Eric Botcazou
Re: RFA: Fix some gcc tests for 16-bit targets
On Tue, Feb 18, 2014 at 5:39 PM, nick clifton ni...@redhat.com wrote: Hi Richard, Instead of modifying testcases I'd be less nervous if you'd make them require 32bit. Otherwise you should reproduce the original issues with the modified testcases. OK, I can do that. How about this patch. OK to apply ? Ok. Thanks, Richard. Cheers Nick gcc/testsuite/ChangeLog 2014-02-18 Nick Clifton ni...@redhat.com * gcc.dg/graphite/pr46966.c: Only run on 32-bit+ targets. * gcc.dg/pr23623.c: Likewise. * gcc.dg/pr48784-1.c: Likewise. * gcc.dg/pr48784-2.c: Likewise. * gcc.dg/pr56997-2.c: Likewise. * gcc.dg/sms-6.c: Likewise. * gcc.dg/torture/pr60183.c: Likewise. * gcc.dg/torture/vec-cvt-1.c: Likewise. * gcc.c-torture/execute/20061220-1.x: New. * gcc.c-torture/execute/pr43220.x: New. * gcc.c-torture/execute/pr51581-1.x: New. * gcc.c-torture/execute/pr51581-2.x: New. * gcc.c-torture/execute/pr58570.x: New. * gcc.c-torture/unsorted/DFcmp.x: New. * gcc.c-torture/unsorted/SFset.x: New.
c-parser.c replace error() by error_at()
Replace calls to error() by error_at().
* c-parser.c (c_parser_declspecs): replace call to error () by error_at ()
* c-parser.c (c_parser_parameter_declaration): Likewise
Bootstrapped on x86_64-unknown-linux-gnu
Ok for trunk ?
Thanks and Regards,
Prathamesh
Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c (revision 207700)
+++ gcc/c/c-parser.c (working copy)
@@ -2223,7 +2223,7 @@ c_parser_declspecs (c_parser *parser, st
attrs_ok = true;
if (kind == C_ID_ID)
{
- error (unknown type name %qE, value);
+ error_at (loc, unknown type name %qE, value);
t.kind = ctsk_typedef;
t.spec = error_mark_node;
}
@@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
c_parser_set_source_position_from_token (token);
if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
{
- error (unknown type name %qE, token-value);
+ error_at (token-location, unknown type name %qE, token-value);
parser-error = true;
}
/* ??? In some Objective-C cases '...' isn't applicable so there
Re: [PATCH] Fix sanitizer build on sparc (PR sanitizer/59758)
On Tue, Feb 18, 2014 at 06:55:51PM +0100, Jose E. Marchesi wrote: This patch fixes builds with --enable-sanitizer, which seems to be the default for sparc now. Build tested in a sparc64-*-linux-gnu system with linux 3.8.13 headers. 2014-02-18 Jose E. Marchesi jose.march...@oracle.com PR sanitizer/59758 * sanitizer_common/sanitizer_platform_limits_posix.h (__sanitizer): Define struct__old_kernel_stat_sz, struct_kernel_stat_sz and struct_kernel_stat64_sz for sparc targets (both 32 and 64 bits). (__sanitizer_ipc_perm): Adjust for sparc targets. (__sanitizer_shmid_ds): Likewise. (__sanitizer_sigaction): Likewise. (IOC_SIZE): Likewise. * sanitizer_common/sanitizer_platform_limits_linux.cc (time_t): defined as __kernel_time_t, which is needed for sparc. (struct___old_kernel_stat_sz): Don't check if __sparc__ is defined. Please talk to Konstantin about getting this into the upstream compiler-rt repository, we don't need to wait for a merge from there, so once it is accepted there, the same patch can be applied to gcc too. Right. Please read https://code.google.com/p/address-sanitizer/wiki/HowToContribute Ok, I follow up on llvm-comm...@cs.uiuc.edu then..
[PATCH] Missing __divtf3@@GCC_4.4.0 on ia64
Since there is already the __divtf3@GCC_3.0 compatibility alias in
libgcc we need to attach an explicit symbol version to the real __divtf3
in order to get it exported. This fixes the unversioned reference in
libgfortran.so, and fixes the failure of gfortran.dg/erf_3.F90. Tested
on ia64-suse-linux.
Andreas.
gcc/testsuite/
PR libfortran/59227
* gfortran.dg/erf_3.F90: Remove XFAIL on ia64-*-linux*.
libgcc/
PR target/59230
PR libfortran/59227
* config/ia64/t-softfp-compat (softfp_file_list): Filter out
soft-fp/divtf3.c.
(LIB2ADD): Add config/ia64/divtf3.c.
* config/ia64/divtf3.c: New file.
---
gcc/testsuite/gfortran.dg/erf_3.F90 | 5 +
libgcc/config/ia64/divtf3.c | 9 +
libgcc/config/ia64/t-softfp-compat | 3 +++
3 files changed, 13 insertions(+), 4 deletions(-)
create mode 100644 libgcc/config/ia64/divtf3.c
diff --git a/gcc/testsuite/gfortran.dg/erf_3.F90
b/gcc/testsuite/gfortran.dg/erf_3.F90
index d9d6589..e7130f6 100644
--- a/gcc/testsuite/gfortran.dg/erf_3.F90
+++ b/gcc/testsuite/gfortran.dg/erf_3.F90
@@ -1,4 +1,4 @@
-! { dg-do run { xfail spu-*-* ia64-*-linux* } }
+! { dg-do run { xfail spu-*-* } }
! { dg-options -fno-range-check -ffree-line-length-none -O0 }
! { dg-add-options ieee }
!
@@ -7,9 +7,6 @@
!
! XFAILed for SPU targets because our library implementation of
! the double-precision erf/erfc functions is not accurate enough.
-!
-! XFAILed for IA64 Linux because of a glibc bug:
-! http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227
program test
use, intrinsic :: iso_fortran_env
diff --git a/libgcc/config/ia64/divtf3.c b/libgcc/config/ia64/divtf3.c
new file mode 100644
index 000..e1afa29
--- /dev/null
+++ b/libgcc/config/ia64/divtf3.c
@@ -0,0 +1,9 @@
+#ifdef SHARED
+#define __divtf3 __divtf3_shared
+#endif
+
+#include soft-fp/divtf3.c
+
+#ifdef SHARED
+asm (.symver __divtf3_shared, __divtf3@@GCC_4.4.0);
+#endif
diff --git a/libgcc/config/ia64/t-softfp-compat
b/libgcc/config/ia64/t-softfp-compat
index 00f45d5..38bcea7 100644
--- a/libgcc/config/ia64/t-softfp-compat
+++ b/libgcc/config/ia64/t-softfp-compat
@@ -5,3 +5,6 @@ libgcc1-tf-functions = __divxf3 _fixtfdi _fixunstfdi _floatditf
LIB1ASMFUNCS := $(filter-out $(libgcc1-tf-functions), $(LIB1ASMFUNCS))
libgcc1-tf-compats = $(addsuffix .S, $(libgcc1-tf-functions))
LIB2ADD += $(addprefix $(srcdir)/config/ia64/, $(libgcc1-tf-compats))
+# Wrap divtf3.c to set the default symbol version
+softfp_file_list := $(filter-out $(srcdir)/soft-fp/divtf3.c,
$(softfp_file_list))
+LIB2ADD += $(srcdir)/config/ia64/divtf3.c
--
1.9.0
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
And now for something completely different.
[PATCH][i386][AVX512] PR60204 - update abi for large structs.
Hi everyone,
As AVX512 abi for passing/returing structs was recently changed in
https://github.com/hjl-tools/x86-64-psABI/commit/6d7ccd614fe67111d2aecec853c3df0310b372d2
We need to update GCC accordingly. This patch does it.
It bootstraps, passes make check (including updated abi tests), spec2006
is ok. Ok for trunk?
ChangeLog bellow:
2014-02-19 Ilya Tocar ilya.to...@intel.com
* config/i386/i386.c (classify_argument): Update to reflect abi fix.
And for testsuite:
2014-02-19 Ilya Tocar ilya.to...@intel.com
* gcc.target/x86_64/abi/avx512f/test_passing_structs.c: Update to
reflect abi fix.
* gcc.target/x86_64/abi/avx512f/test_passing_unions.c: Ditto.
---
gcc/config/i386/i386.c | 4 +-
.../x86_64/abi/avx512f/test_passing_structs.c | 12 +---
.../x86_64/abi/avx512f/test_passing_unions.c | 78 +++---
3 files changed, 12 insertions(+), 82 deletions(-)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index acfc021..2d16fb9 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -6431,8 +6431,8 @@ classify_argument (enum machine_mode mode, const_tree
type,
tree field;
enum x86_64_reg_class subclasses[MAX_CLASSES];
- /* On x86-64 we pass structures larger than 32 bytes on the stack. */
- if (bytes 32)
+ /* On x86-64 we pass structures larger than 64 bytes on the stack. */
+ if (bytes 64)
return 0;
for (i = 0; i words; i++)
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c
b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c
index a5e1477..8daa676 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c
+++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c
@@ -26,16 +26,8 @@ check_struct_passing1 (struct m512_struct ms1
ATTRIBUTE_UNUSED,
struct m512_struct ms7 ATTRIBUTE_UNUSED,
struct m512_struct ms8 ATTRIBUTE_UNUSED)
{
- /* Check the passing on the stack by comparing the address of the
- stack elements to the expected place on the stack. */
- assert ((unsigned long)ms1.x == rsp+8);
- assert ((unsigned long)ms2.x == rsp+72);
- assert ((unsigned long)ms3.x == rsp+136);
- assert ((unsigned long)ms4.x == rsp+200);
- assert ((unsigned long)ms5.x == rsp+264);
- assert ((unsigned long)ms6.x == rsp+328);
- assert ((unsigned long)ms7.x == rsp+392);
- assert ((unsigned long)ms8.x == rsp+456);
+ /* Check register contents. */
+ check_m512_arguments;
}
void
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_unions.c
b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_unions.c
index 9712290..370d15b6 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_unions.c
+++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_unions.c
@@ -52,24 +52,8 @@ check_union_passing1(union un1 u1 ATTRIBUTE_UNUSED,
union un1 u7 ATTRIBUTE_UNUSED,
union un1 u8 ATTRIBUTE_UNUSED)
{
- /* Check the passing on the stack by comparing the address of the
- stack elements to the expected place on the stack. */
- assert ((unsigned long)u1.x == rsp+8);
- assert ((unsigned long)u1.f == rsp+8);
- assert ((unsigned long)u2.x == rsp+72);
- assert ((unsigned long)u2.f == rsp+72);
- assert ((unsigned long)u3.x == rsp+136);
- assert ((unsigned long)u3.f == rsp+136);
- assert ((unsigned long)u4.x == rsp+200);
- assert ((unsigned long)u4.f == rsp+200);
- assert ((unsigned long)u5.x == rsp+264);
- assert ((unsigned long)u5.f == rsp+264);
- assert ((unsigned long)u6.x == rsp+328);
- assert ((unsigned long)u6.f == rsp+328);
- assert ((unsigned long)u7.x == rsp+392);
- assert ((unsigned long)u7.f == rsp+392);
- assert ((unsigned long)u8.x == rsp+456);
- assert ((unsigned long)u8.f == rsp+456);
+ /* Check register contents. */
+ check_m512_arguments;
}
void
@@ -82,24 +66,8 @@ check_union_passing2(union un2 u1 ATTRIBUTE_UNUSED,
union un2 u7 ATTRIBUTE_UNUSED,
union un2 u8 ATTRIBUTE_UNUSED)
{
- /* Check the passing on the stack by comparing the address of the
- stack elements to the expected place on the stack. */
- assert ((unsigned long)u1.x == rsp+8);
- assert ((unsigned long)u1.d == rsp+8);
- assert ((unsigned long)u2.x == rsp+72);
- assert ((unsigned long)u2.d == rsp+72);
- assert ((unsigned long)u3.x == rsp+136);
- assert ((unsigned long)u3.d == rsp+136);
- assert ((unsigned long)u4.x == rsp+200);
- assert ((unsigned long)u4.d == rsp+200);
- assert ((unsigned long)u5.x == rsp+264);
- assert ((unsigned long)u5.d == rsp+264);
- assert ((unsigned long)u6.x == rsp+328);
- assert ((unsigned long)u6.d == rsp+328);
- assert ((unsigned long)u7.x == rsp+392);
- assert ((unsigned long)u7.d == rsp+392);
- assert ((unsigned long)u8.x == rsp+456);
-
Re: c-parser.c replace error() by error_at()
On Wed, Feb 19, 2014 at 06:05:12PM +0530, Prathamesh Kulkarni wrote:
Replace calls to error() by error_at().
* c-parser.c (c_parser_declspecs): replace call to error () by error_at ()
Replace, drop ()'s, full stop at the end.
* c-parser.c (c_parser_parameter_declaration): Likewise
Full stop at the end.
@@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
c_parser_set_source_position_from_token (token);
if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
{
- error (unknown type name %qE, token-value);
+ error_at (token-location, unknown type name %qE, token-value);
Only one space between , and .
It'd be nice to add a testcase as well, e.g. something like this
void
fn1 (const foo x) /* { dg-error ... } */
{
}
void
fn2 (int i; foo a; int i) /* { dg-error ... } */
{
}
void
fn3 (char c, foo x, ...) /* { dg-error ... } */
{
}
Marek
Re: [PATCH][i386][AVX512] PR60204 - update abi for large structs.
On Wed, Feb 19, 2014 at 2:30 PM, Ilya Tocar tocarip.in...@gmail.com wrote: Hi everyone, As AVX512 abi for passing/returing structs was recently changed in https://github.com/hjl-tools/x86-64-psABI/commit/6d7ccd614fe67111d2aecec853c3df0310b372d2 We need to update GCC accordingly. This patch does it. It bootstraps, passes make check (including updated abi tests), spec2006 is ok. Ok for trunk? ChangeLog bellow: 2014-02-19 Ilya Tocar ilya.to...@intel.com * config/i386/i386.c (classify_argument): Update to reflect abi fix. Better say Pass structures of size 64 bytes or less in register. And for testsuite: 2014-02-19 Ilya Tocar ilya.to...@intel.com * gcc.target/x86_64/abi/avx512f/test_passing_structs.c: Update to reflect abi fix. * gcc.target/x86_64/abi/avx512f/test_passing_unions.c: Ditto. Please mention PR target/60204 in both ChangeLogs. OK for mainline with these (minor) changes. Thanks, Uros.
Re: [PATCH] Properly check for _Cilk_spawn in return stmt (PR c/60197)
On Tue, Feb 18, 2014 at 10:06:14PM +, Iyer, Balaji V wrote:
This is invalid.
Thanks. In that case, this patch should error out on such invalid uses as
well, instead of ICEing.
Regtested/bootstrapped on x86_64-linux.
2014-02-19 Marek Polacek pola...@redhat.com
PR c/60197
c-family/
* cilk.c (contains_cilk_spawn_stmt): New function.
(contains_cilk_spawn_stmt_walker): Likewise.
(recognize_spawn): Give error on invalid use of _Cilk_spawn.
* c-common.h (contains_cilk_spawn_stmt): Add declaration.
c/
* c-typeck.c (c_finish_return): Call contains_cilk_spawn_stmt instead
of checking tree code.
cp/
* typeck.c (check_return_expr): Call contains_cilk_spawn_stmt instead
of checking tree code.
testsuite/
* c-c++-common/cilk-plus/CK/pr60197.c: New test.
* c-c++-common/cilk-plus/CK/pr60197-2.c: New test.
diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index f074ab1..1099b10 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -1389,4 +1389,5 @@ extern tree make_cilk_frame (tree);
extern tree create_cilk_function_exit (tree, bool, bool);
extern tree cilk_install_body_pedigree_operations (tree);
extern void cilk_outline (tree, tree *, void *);
+extern bool contains_cilk_spawn_stmt (tree);
#endif /* ! GCC_C_COMMON_H */
diff --git gcc/c-family/cilk.c gcc/c-family/cilk.c
index f2179dfc..6a7bf4f 100644
--- gcc/c-family/cilk.c
+++ gcc/c-family/cilk.c
@@ -235,6 +235,9 @@ recognize_spawn (tree exp, tree *exp0)
walk_tree (exp0, unwrap_cilk_spawn_stmt, NULL, NULL);
spawn_found = true;
}
+ /* _Cilk_spawn can't be wrapped in expression such as PLUS_EXPR. */
+ else if (contains_cilk_spawn_stmt (exp))
+error (invalid use of %_Cilk_spawn%);
return spawn_found;
}
@@ -1292,3 +1295,25 @@ build_cilk_sync (void)
TREE_SIDE_EFFECTS (sync) = 1;
return sync;
}
+
+/* Helper for contains_cilk_spawn_stmt, callback for walk_tree. Return
+ non-null tree if TP contains CILK_SPAWN_STMT. */
+
+static tree
+contains_cilk_spawn_stmt_walker (tree *tp, int *, void *)
+{
+ if (TREE_CODE (*tp) == CILK_SPAWN_STMT)
+return *tp;
+ else
+return NULL_TREE;
+}
+
+/* Returns true if EXPR or any of its subtrees contain CILK_SPAWN_STMT
+ node. */
+
+bool
+contains_cilk_spawn_stmt (tree expr)
+{
+ return walk_tree (expr, contains_cilk_spawn_stmt_walker, NULL, NULL)
+!= NULL_TREE;
+}
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 2b54290..7c4ba0e 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -9140,7 +9140,7 @@ c_finish_return (location_t loc, tree retval, tree
origtype)
return error_mark_node;
}
}
- if (flag_cilkplus retval TREE_CODE (retval) == CILK_SPAWN_STMT)
+ if (flag_cilkplus retval contains_cilk_spawn_stmt (retval))
{
error_at (loc, use of %_Cilk_spawn% in a return statement is not
allowed);
diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 5fc0e6b..566411f 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -8328,7 +8328,7 @@ check_return_expr (tree retval, bool *no_warning)
*no_warning = false;
- if (flag_cilkplus retval TREE_CODE (retval) == CILK_SPAWN_STMT)
+ if (flag_cilkplus retval contains_cilk_spawn_stmt (retval))
{
error_at (EXPR_LOCATION (retval), use of %_Cilk_spawn% in a return
statement is not allowed);
diff --git gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c
gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c
index e69de29..1e5ca00 100644
--- gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c
+++ gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c
@@ -0,0 +1,35 @@
+/* PR c/60197 */
+/* { dg-do compile } */
+/* { dg-options -fcilkplus } */
+
+extern int foo (void);
+
+int
+fn1 (void)
+{
+ int i;
+ i = (_Cilk_spawn foo ()) + 1; /* { dg-error invalid use of } */
+ return i;
+}
+
+int
+fn2 (void)
+{
+ int i = (_Cilk_spawn foo ()) + 1; /* { dg-error invalid use of } */
+ return i;
+}
+
+int
+fn3 (int j, int k, int l)
+{
+ int i = (_Cilk_spawn foo ()) + 1) - l) * k) / j); /* { dg-error invalid
use of } */
+ return i;
+}
+
+int
+fn4 (int j, int k, int l)
+{
+ int i;
+ i = (_Cilk_spawn foo ()) + 1) - l) * k) / j); /* { dg-error invalid use
of } */
+ return i;
+}
diff --git gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197.c
gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197.c
index e69de29..2b47d1e 100644
--- gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197.c
+++ gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197.c
@@ -0,0 +1,66 @@
+/* PR c/60197 */
+/* { dg-do compile } */
+/* { dg-options -fcilkplus } */
+
+extern int foo (void);
+extern int bar (int);
+
+int
+fn1 (void)
+{
+ return (_Cilk_spawn foo ()) * 2; /* { dg-error in a return statement is not
allowed } */
+}
+
+int
+fn2 (void)
+{
+ return (_Cilk_spawn foo ()) 2; /* { dg-error in a return statement is not
allowed } */
+}
+
+int
+fn3 (int i, int j, int k)
+{
+ return
Re: [PATCH] Allow cfgcleanup to remove forwarder loop preheaders and latches
Hi Richard,
Does this have to wait for stage 1? Or I will try to work out a full
patch with loop recreating issue fixed.
On Wed, Feb 19, 2014 at 7:57 PM, Richard Biener rguent...@suse.de wrote:
This allows cfgcleanup to remove some of the extra CFG that exists
just for loop analysis passes convenience (those can be and are
easily re-created by passes doing loop_optimizer_init ()).
It may fix a regression uncovered in private communication.
It's the regression about the code size checks in
gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c
Untested - my original idea how to fix this (tree_forwarder_block_p
hunk) ran into the issue in remove_forwarder_block which causes
loops to be removed / re-discovered (losing meta-data).
Richard.
2014-02-19 Richard Biener rguent...@suse.de
* tree-cfgcleanup.c (tree_forwarder_block_p): Protect
latches and preheaders only if requested.
(remove_forwarder_block): Update loop structure if we
removed a forwarder that is a loop latch.
Index: gcc/tree-cfgcleanup.c
===
*** gcc/tree-cfgcleanup.c (revision 207878)
--- gcc/tree-cfgcleanup.c (working copy)
*** tree_forwarder_block_p (basic_block bb,
*** 307,321
if (current_loops)
{
! basic_block dest;
! /* Protect loop latches, headers and preheaders. */
if (bb-loop_father-header == bb)
return false;
- dest = EDGE_SUCC (bb, 0)-dest;
! if (dest-loop_father-header == dest)
return false;
}
return true;
}
--- 307,324
if (current_loops)
{
! /* Protect loop headers. */
if (bb-loop_father-header == bb)
return false;
! /* Protect loop latches and preheaders if requested. */
! basic_block dest = EDGE_SUCC (bb, 0)-dest;
! if (dest-loop_father-header == dest
! (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
! || loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)))
return false;
}
Sorry for being nit-picking here. There is a scenario that bb is
pre-header and loop prop is set to (!LOOPS_HAVE_PREHEADERS
LOOPS_HAVE_SIMPLE_LATCHES). Of course, this may not happen anyway.
+
return true;
}
*** remove_forwarder_block (basic_block bb)
*** 497,503
set_immediate_dominator (CDI_DOMINATORS, dest, dom);
}
! /* And kill the forwarder block. */
delete_basic_block (bb);
return true;
--- 500,511
set_immediate_dominator (CDI_DOMINATORS, dest, dom);
}
! /* And kill the forwarder block, but first adjust its parent loop
! latch info as otherwise the cfg hook has a hard time not to
! kill the loop. */
! if (current_loops
!bb-loop_father-latch == bb)
! bb-loop_father-latch = dest;
delete_basic_block (bb);
By this code, do you mean to prevent cfgcleanup from
removing/rebuilding the loop struct?
return true;
Thanks,
bin
Re: [AArch64 00/14] Pipeline-independent changes for XGene-1
On 18/02/14 21:09, Philipp Tomsich wrote: The following patch-set contains the pipeline-independent changes to gcc to support the APM XGene-1 and contains various enhancements derived from real-world applications and benchmarks running on XGene-1. As the pipeline model has not been fully adapted to the new instruction typing shared between the ARM backend and the AArch64 backend, it is not yet contained in these patches. The most controversial part of these patches will likely consist in the new cost-model, which has intentionally been provided as a hook that intercepts the current cost-model when compiling for XGene-1. Given that the matching/structure of this cost-model is different from the existing implementation, we've chosen to keep this in a separate function for the time being. This patch series is too late for 4.9 and for stage 1 I'd like to see this fixed before the code goes in. Code like this rapidly becomes unmaintainable and makes it difficult to add support for future variants; it tends to proliferate once started and then it becomes necessary to analyse every part of the machine description each time a new device is added to find out whether it needs adjusting. It should be possible to plug the XGene timings into the current infrastructure, though it might be necessary to add some new data values when doing so. The end goal is that nothing in the back-end, apart from instruction scheduling, should be testing for a specific CPU; the backend should make all its code generation decisions from the architecture and tuning tables. R. Philipp Tomsich (14): Use generic target, if no other default. Add xgene1 core identifier. Retrieve BRANCH_COST from tuning structure. Correct the maximum shift amount for shifted operands. Add AArch64 'prefetch'-pattern. Extend '*tboptabmode1'. Define additional patterns for adds/subs. Define a variant of cmp for the CC_NZ case. Add special cases of zero-extend w/ compare operations. Add movmodecc definition for GPF case. Optimize and(s) patterns for HI/QI operands. Generate 'bics', when only interested in CC_NZ. Initial tuning description for XGene-1 core. Add cost-model for XGene-1. gcc/config/aarch64/aarch64-cores.def | 1 + gcc/config/aarch64/aarch64-protos.h | 2 + gcc/config/aarch64/aarch64-tune.md | 2 +- gcc/config/aarch64/aarch64.c | 922 ++- gcc/config/aarch64/aarch64.h | 10 +- gcc/config/aarch64/aarch64.md| 246 +- gcc/config/aarch64/iterators.md | 2 + gcc/config/arm/types.md | 2 + 8 files changed, 1172 insertions(+), 15 deletions(-)
Re: [PATCH] Allow cfgcleanup to remove forwarder loop preheaders and latches
On Wed, 19 Feb 2014, Bin.Cheng wrote:
Hi Richard,
Does this have to wait for stage 1? Or I will try to work out a full
patch with loop recreating issue fixed.
If it is a regression and there is a bugzilla about it it doesn't
have to wait.
The patch should be complete (but is untested yet)
On Wed, Feb 19, 2014 at 7:57 PM, Richard Biener rguent...@suse.de wrote:
This allows cfgcleanup to remove some of the extra CFG that exists
just for loop analysis passes convenience (those can be and are
easily re-created by passes doing loop_optimizer_init ()).
It may fix a regression uncovered in private communication.
It's the regression about the code size checks in
gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c
I see. So it is a regression then.
Untested - my original idea how to fix this (tree_forwarder_block_p
hunk) ran into the issue in remove_forwarder_block which causes
loops to be removed / re-discovered (losing meta-data).
Richard.
2014-02-19 Richard Biener rguent...@suse.de
* tree-cfgcleanup.c (tree_forwarder_block_p): Protect
latches and preheaders only if requested.
(remove_forwarder_block): Update loop structure if we
removed a forwarder that is a loop latch.
Index: gcc/tree-cfgcleanup.c
===
*** gcc/tree-cfgcleanup.c (revision 207878)
--- gcc/tree-cfgcleanup.c (working copy)
*** tree_forwarder_block_p (basic_block bb,
*** 307,321
if (current_loops)
{
! basic_block dest;
! /* Protect loop latches, headers and preheaders. */
if (bb-loop_father-header == bb)
return false;
- dest = EDGE_SUCC (bb, 0)-dest;
! if (dest-loop_father-header == dest)
return false;
}
return true;
}
--- 307,324
if (current_loops)
{
! /* Protect loop headers. */
if (bb-loop_father-header == bb)
return false;
! /* Protect loop latches and preheaders if requested. */
! basic_block dest = EDGE_SUCC (bb, 0)-dest;
! if (dest-loop_father-header == dest
! (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
! || loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)))
return false;
}
Sorry for being nit-picking here. There is a scenario that bb is
pre-header and loop prop is set to (!LOOPS_HAVE_PREHEADERS
LOOPS_HAVE_SIMPLE_LATCHES). Of course, this may not happen anyway.
Yeah, but then we'd have to detect whether this is a preheader
forwarder or a latch forwarder. I doubt it happens right now
so I thought it doesn't matter to do it like above.
+
return true;
}
*** remove_forwarder_block (basic_block bb)
*** 497,503
set_immediate_dominator (CDI_DOMINATORS, dest, dom);
}
! /* And kill the forwarder block. */
delete_basic_block (bb);
return true;
--- 500,511
set_immediate_dominator (CDI_DOMINATORS, dest, dom);
}
! /* And kill the forwarder block, but first adjust its parent loop
! latch info as otherwise the cfg hook has a hard time not to
! kill the loop. */
! if (current_loops
!bb-loop_father-latch == bb)
! bb-loop_father-latch = dest;
delete_basic_block (bb);
By this code, do you mean to prevent cfgcleanup from
removing/rebuilding the loop struct?
Yes. It prevents triggering cfghooks.c:
void
delete_basic_block (basic_block bb)
{
...
/* If we remove the header or the latch of a loop, mark the loop for
removal by setting its header and latch to NULL. */
if (loop-latch == bb
|| loop-header == bb)
{
loop-header = NULL;
loop-latch = NULL;
loops_state_set (LOOPS_NEED_FIXUP);
generally delete_basic_block has too little context to work out
anything more specific than the above (so it's a very bad tool ;))
Richard.
return true;
Thanks,
bin
Re: c-parser.c replace error() by error_at()
On Wed, Feb 19, 2014 at 7:01 PM, Marek Polacek pola...@redhat.com wrote:
On Wed, Feb 19, 2014 at 06:05:12PM +0530, Prathamesh Kulkarni wrote:
Replace calls to error() by error_at().
* c-parser.c (c_parser_declspecs): replace call to error () by error_at ()
Replace, drop ()'s, full stop at the end.
* c-parser.c (c_parser_parameter_declaration): Likewise
Full stop at the end.
@@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
c_parser_set_source_position_from_token (token);
if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
{
- error (unknown type name %qE, token-value);
+ error_at (token-location, unknown type name %qE, token-value);
Only one space between , and .
It'd be nice to add a testcase as well, e.g. something like this
void
fn1 (const foo x) /* { dg-error ... } */
{
}
void
fn2 (int i; foo a; int i) /* { dg-error ... } */
{
}
void
fn3 (char c, foo x, ...) /* { dg-error ... } */
{
}
Is this fine ?
* c-parser.c (c_parser_declspecs): Replace call to error by error_at.
* c-parser.c (c_parser_parameter_declaration): Likewise.
Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c (revision 207700)
+++ gcc/c/c-parser.c (working copy)
@@ -2223,7 +2223,7 @@ c_parser_declspecs (c_parser *parser, st
attrs_ok = true;
if (kind == C_ID_ID)
{
- error (unknown type name %qE, value);
+ error_at (loc, unknown type name %qE, value);
t.kind = ctsk_typedef;
t.spec = error_mark_node;
}
@@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
c_parser_set_source_position_from_token (token);
if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
{
- error (unknown type name %qE, token-value);
+ error_at (token-location, unknown type name %qE, token-value);
parser-error = true;
}
/* ??? In some Objective-C cases '...' isn't applicable so there
Index: gcc/testsuite/gcc.dg/decl-9.c
===
--- gcc/testsuite/gcc.dg/decl-9.c (revision 207700)
+++ gcc/testsuite/gcc.dg/decl-9.c (working copy)
@@ -30,3 +30,14 @@ void *f3()
return x; /* { dg-bogus 'x' undeclared } */
}
+void
+f4(const foo x) /* { dg-error unknown type name 'foo' } */
+{}
+
+void
+f5(int i; foo x, int i) /* { dg-error unknown type name 'foo' } */
+{}
+
+void
+f6(char c, foo x, ...) /* { dg-error unknown type name 'foo' } */
+{}
Marek
Re: [PATCH] Allow cfgcleanup to remove forwarder loop preheaders and latches
On Wed, Feb 19, 2014 at 10:06 PM, Richard Biener rguent...@suse.de wrote:
On Wed, 19 Feb 2014, Bin.Cheng wrote:
Hi Richard,
Does this have to wait for stage 1? Or I will try to work out a full
patch with loop recreating issue fixed.
If it is a regression and there is a bugzilla about it it doesn't
have to wait.
The patch should be complete (but is untested yet)
On Wed, Feb 19, 2014 at 7:57 PM, Richard Biener rguent...@suse.de wrote:
This allows cfgcleanup to remove some of the extra CFG that exists
just for loop analysis passes convenience (those can be and are
easily re-created by passes doing loop_optimizer_init ()).
It may fix a regression uncovered in private communication.
It's the regression about the code size checks in
gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c
I see. So it is a regression then.
OK, I will file a PR about it.
Untested - my original idea how to fix this (tree_forwarder_block_p
hunk) ran into the issue in remove_forwarder_block which causes
loops to be removed / re-discovered (losing meta-data).
Richard.
2014-02-19 Richard Biener rguent...@suse.de
* tree-cfgcleanup.c (tree_forwarder_block_p): Protect
latches and preheaders only if requested.
(remove_forwarder_block): Update loop structure if we
removed a forwarder that is a loop latch.
Index: gcc/tree-cfgcleanup.c
===
*** gcc/tree-cfgcleanup.c (revision 207878)
--- gcc/tree-cfgcleanup.c (working copy)
*** tree_forwarder_block_p (basic_block bb,
*** 307,321
if (current_loops)
{
! basic_block dest;
! /* Protect loop latches, headers and preheaders. */
if (bb-loop_father-header == bb)
return false;
- dest = EDGE_SUCC (bb, 0)-dest;
! if (dest-loop_father-header == dest)
return false;
}
return true;
}
--- 307,324
if (current_loops)
{
! /* Protect loop headers. */
if (bb-loop_father-header == bb)
return false;
! /* Protect loop latches and preheaders if requested. */
! basic_block dest = EDGE_SUCC (bb, 0)-dest;
! if (dest-loop_father-header == dest
! (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
! || loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)))
return false;
}
Sorry for being nit-picking here. There is a scenario that bb is
pre-header and loop prop is set to (!LOOPS_HAVE_PREHEADERS
LOOPS_HAVE_SIMPLE_LATCHES). Of course, this may not happen anyway.
Yeah, but then we'd have to detect whether this is a preheader
forwarder or a latch forwarder. I doubt it happens right now
so I thought it doesn't matter to do it like above.
+
return true;
}
*** remove_forwarder_block (basic_block bb)
*** 497,503
set_immediate_dominator (CDI_DOMINATORS, dest, dom);
}
! /* And kill the forwarder block. */
delete_basic_block (bb);
return true;
--- 500,511
set_immediate_dominator (CDI_DOMINATORS, dest, dom);
}
! /* And kill the forwarder block, but first adjust its parent loop
! latch info as otherwise the cfg hook has a hard time not to
! kill the loop. */
! if (current_loops
!bb-loop_father-latch == bb)
! bb-loop_father-latch = dest;
delete_basic_block (bb);
By this code, do you mean to prevent cfgcleanup from
removing/rebuilding the loop struct?
Yes. It prevents triggering cfghooks.c:
void
delete_basic_block (basic_block bb)
{
...
/* If we remove the header or the latch of a loop, mark the loop for
removal by setting its header and latch to NULL. */
if (loop-latch == bb
|| loop-header == bb)
{
loop-header = NULL;
loop-latch = NULL;
loops_state_set (LOOPS_NEED_FIXUP);
generally delete_basic_block has too little context to work out
anything more specific than the above (so it's a very bad tool ;))
Well, it can't. From what I observed, it is pass_ch that modifies the
loop header with some specific control flow graph. Doesn't matter if
the LOOPS_NEED_FIXUP is set before pass_ch, since it calls
loop_optimizer_init to fix loop structure before starting work. In
another word, pass_ch always starts with LOOPS_NEED_FIXUP cleared.
I will do further investigation on pass_ch.
Thanks,
bin
Richard.
--
Best Regards.
Re: c-parser.c replace error() by error_at()
On Wed, Feb 19, 2014 at 07:43:56PM +0530, Prathamesh Kulkarni wrote:
Index: gcc/testsuite/gcc.dg/decl-9.c
===
--- gcc/testsuite/gcc.dg/decl-9.c (revision 207700)
+++ gcc/testsuite/gcc.dg/decl-9.c (working copy)
@@ -30,3 +30,14 @@ void *f3()
return x; /* { dg-bogus 'x' undeclared } */
}
+void
+f4(const foo x) /* { dg-error unknown type name 'foo' } */
+{}
+
+void
+f5(int i; foo x, int i) /* { dg-error unknown type name 'foo' } */
+{}
+
+void
+f6(char c, foo x, ...) /* { dg-error unknown type name 'foo' } */
+{}
I'd omit the 'foo' in dg-error and please create a new testcase for this,
don't reuse decl-9.c.
Otherwise looks good (can't approve though), thanks.
Marek
Re: [AArch64 00/14] Pipeline-independent changes for XGene-1
On Tue, Feb 18, 2014 at 9:09 PM, Philipp Tomsich philipp.toms...@theobroma-systems.com wrote: The following patch-set contains the pipeline-independent changes to gcc to support the APM XGene-1 and contains various enhancements derived from real-world applications and benchmarks running on XGene-1. As the pipeline model has not been fully adapted to the new instruction typing shared between the ARM backend and the AArch64 backend, it is not yet contained in these patches. The most controversial part of these patches will likely consist in the new cost-model, which has intentionally been provided as a hook that intercepts the current cost-model when compiling for XGene-1. Given that the matching/structure of this cost-model is different from the existing implementation, we've chosen to keep this in a separate function for the time being. And please produce Changelog entries for each of the changes. Can I also ask you to confirm that you have a copyright assignment with the FSF on file for contributing these changes ? Ramana Philipp Tomsich (14): Use generic target, if no other default. Add xgene1 core identifier. Retrieve BRANCH_COST from tuning structure. Correct the maximum shift amount for shifted operands. Add AArch64 'prefetch'-pattern. Extend '*tboptabmode1'. Define additional patterns for adds/subs. Define a variant of cmp for the CC_NZ case. Add special cases of zero-extend w/ compare operations. Add movmodecc definition for GPF case. Optimize and(s) patterns for HI/QI operands. Generate 'bics', when only interested in CC_NZ. Initial tuning description for XGene-1 core. Add cost-model for XGene-1. gcc/config/aarch64/aarch64-cores.def | 1 + gcc/config/aarch64/aarch64-protos.h | 2 + gcc/config/aarch64/aarch64-tune.md | 2 +- gcc/config/aarch64/aarch64.c | 922 ++- gcc/config/aarch64/aarch64.h | 10 +- gcc/config/aarch64/aarch64.md| 246 +- gcc/config/aarch64/iterators.md | 2 + gcc/config/arm/types.md | 2 + 8 files changed, 1172 insertions(+), 15 deletions(-) -- 1.9.0
[Ada] Do not perform expansion of generics even in GNATprove mode
In GNATprove mode for formal verification, some treatment typically only done during expansion needs to be performed on the tree, but it should not be applied inside generics. Otherwise, this breaks the name resolution mechanism for genetic instances. This completes a previous similar fix. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-02-19 Yannick Moy m...@adacore.com * expander.adb (Expand): Do nothing inside generics. * sem_aggr.adb (Aggregate_Constraint_Checks): Do nothing inside generics. Index: sem_aggr.adb === --- sem_aggr.adb(revision 207879) +++ sem_aggr.adb(working copy) @@ -459,7 +459,9 @@ -- added in the tree, so that the formal verification can rely on those -- to be present. - if not (Expander_Active or GNATprove_Mode) or In_Spec_Expression then + if not Expander_Active +and (Inside_A_Generic or not Full_Analysis or not GNATprove_Mode) + then return; end if; Index: expander.adb === --- expander.adb(revision 207879) +++ expander.adb(working copy) @@ -90,7 +90,8 @@ -- analysis, in which case Full_Analysis = True or a pre-analysis in -- which case Full_Analysis = False. See the spec of Sem for more info -- on this. Additionally, the GNATprove_Mode flag indicates that a light - -- expansion for formal verification should be used. + -- expansion for formal verification should be used. This expansion is + -- never done inside generics. -- The second reason for the Expander_Active flag to be False is that -- we are performing a pre-analysis. During pre-analysis all expansion @@ -108,7 +109,9 @@ -- given that the expansion actions that would normally process it will -- not take place. This prevents cascaded errors due to stack mismatch. - if not (Expander_Active or (Full_Analysis and GNATprove_Mode)) then + if not Expander_Active +and (Inside_A_Generic or not Full_Analysis or not GNATprove_Mode) + then Set_Analyzed (N, Full_Analysis); if Serious_Errors_Detected 0 and then Scope_Is_Transient then
[PATCH ARM] Fix PR60264 (ICE in dwarf2out_frame_debug_adjust_cfa) part 2
Hello,
This patch is a followup of
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01042.html
If fixes a bunch of ICEs for the testsuite ran with
--target_board=arm-sim/\{-mapcs-frame\}, noticed on a reference branch
for testing the former patch.
One of the strange issue I had to deal with, for instance with
./gcc.c-torture/compile/991202-1.c, is that the epilogue emitted the
CFA notes in the following order:
(set/f (reg:SI 12 ip)
(plus:SI (reg:SI 12 ip)
(const_int 16 [0x10])))
(set/f (reg:DF 32 s16)
(mem/c:DF (reg:SI 12 ip) [3 S8 A64]))
(set/f (reg:DF 34 s18)
(mem/c:DF (plus:SI (reg:SI 12 ip)
(const_int 8 [0x8])) [3 S8 A64]))
]) /home/bruelc/tmp/991202-1.c:18 347
{*vfp_pop_multiple_with_writeback}
(expr_list:REG_UNUSED (reg:SI 12 ip)
(expr_list:REG_CFA_ADJUST_CFA (set (reg:SI 12 ip)
(plus:SI (reg:SI 12 ip)
(const_int 16 [0x10])))
(expr_list:REG_CFA_DEF_CFA (reg/f:SI 11 fp)
(expr_list:REG_CFA_RESTORE (reg:DF 34 s18)
(expr_list:REG_CFA_RESTORE (reg:DF 32 s16)
(nil)))
but shrink-wrapping duplicates it as
(insn/f:TI 140 137 171 (parallel [
(set/f (reg:SI 12 ip)
(plus:SI (reg:SI 12 ip)
(const_int 16 [0x10])))
(set/f (reg:DF 32 s16)
(mem/c:DF (reg:SI 12 ip) [3 S8 A64]))
(set/f (reg:DF 34 s18)
(mem/c:DF (plus:SI (reg:SI 12 ip)
(const_int 8 [0x8])) [3 S8 A64]))
]) /home/bruelc/tmp/991202-1.c:18 347
{*vfp_pop_multiple_with_writeback}
(expr_list:REG_UNUSED (reg:SI 12 ip)
(expr_list:REG_CFA_RESTORE (reg:DF 32 s16)
(expr_list:REG_CFA_RESTORE (reg:DF 34 s18)
(expr_list:REG_CFA_DEF_CFA (reg/f:SI 11 fp)
(expr_list:REG_CFA_ADJUST_CFA (set (reg:SI 12 ip)
(plus:SI (reg:SI 12 ip)
(const_int 16 [0x10])))
(nil)))
Since the CFA_RESTORE order is inverted with CFA_DEF_CFA, cur_cfa-reg
was set with IP instead of FP
I fixed this by not emitting the CFA_ADJUST_CFA in this case, since it's
not needed anyway as we have:
fldmfddip!, {d8-d9}@ 140*vfp_pop_multiple_with_writeback
subsp, fp, #12@ 142
ldmfdsp, {fp, sp, pc}@ 143
so after @140 cur_cfa can't be IP.
Regression tested for for armv7-a
--target_board=arm-sim/\{,-mapcs-frame\}. Fixes a large number of tests
OK for trunk ?
Many thanks
--- config/arm/arm.c 2014-02-19 15:28:34.0 +0100
+++ /work1/bruel/superh_elf/gnu_trunk.devs/gcc/gcc/config/arm/arm.c 2014-02-19 14:30:44.0 +0100
@@ -19911,10 +19911,14 @@
/* Make sure cfa doesn't leave with IP_REGNUM. */
if (TARGET_VFP REGNO (base_reg) == IP_REGNUM)
-add_reg_note (par, REG_CFA_DEF_CFA, hard_frame_pointer_rtx);
+{
+ RTX_FRAME_RELATED_P (par) = 1;
+ add_reg_note (par, REG_CFA_DEF_CFA, hard_frame_pointer_rtx);
+}
+ else
+arm_add_cfa_adjust_cfa_note (par, 2 * UNITS_PER_WORD * num_regs,
+ base_reg, base_reg);
- arm_add_cfa_adjust_cfa_note (par, 2 * UNITS_PER_WORD * num_regs,
- base_reg, base_reg);
}
@@ -27109,8 +27113,8 @@
if (saved_size 0)
{
rtx insn;
- floats_from_frame += saved_size;
- insn = emit_insn (gen_addsi3 (gen_rtx_REG (SImode, IP_REGNUM),
+ floats_from_frame += saved_size;
+ insn = emit_insn (gen_addsi3 (gen_rtx_REG (SImode, IP_REGNUM),
hard_frame_pointer_rtx,
GEN_INT (-floats_from_frame)));
RTX_FRAME_RELATED_P (insn) = 1;
@@ -27192,7 +27196,9 @@
insn = emit_insn (gen_addsi3 (stack_pointer_rtx,
hard_frame_pointer_rtx,
GEN_INT (- 4 * num_regs)));
- RTX_FRAME_RELATED_P (insn) = 1;
+
+ arm_add_cfa_adjust_cfa_note (insn, - 4 * num_regs,
+ stack_pointer_rtx, hard_frame_pointer_rtx);
}
arm_emit_multi_reg_pop (saved_regs_mask);
[Ada] Duplicate projects due to symbolic links
When the same projec is imported by several projects in the project tree through different paths that includes symbolic links, the Project Manager may reported an error indicating that two different projects have the same name. This is corrected by this patch. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-02-19 Vincent Celier cel...@adacore.com * prj-part.adb (Parse_Single_Project): Use the fully resolved project path, with all symbolic links resolved, to check if the same project is imported with a different unresolved path. * prj-tree.ads (Project_Name_And_Node): Component Canonical_Path changed to Resolved_Path to reflect that all symbolic links are resolved. Index: prj-part.adb === --- prj-part.adb(revision 207879) +++ prj-part.adb(working copy) @@ -1126,8 +1126,8 @@ if Project_Qualifier_Of (Imported, In_Tree) = Aggregate then Error_Msg_Name_1 := Name_Id (Path_Name_Of (Imported, In_Tree)); - Error_Msg -(Flags, cannot import aggregate project %%, Token_Ptr); + Error_Msg + (Flags, cannot import aggregate project %%, Token_Ptr); exit; end if; @@ -1280,6 +1280,7 @@ Normed_Path_Name: Path_Name_Type; Canonical_Path_Name : Path_Name_Type; + Resolved_Path_Name : Path_Name_Type; Project_Directory : Path_Name_Type; Project_Scan_State : Saved_Project_Scan_State; Source_Index: Source_File_Index; @@ -1329,6 +1330,20 @@ Name_Len := Canonical_Path'Length; Name_Buffer (1 .. Name_Len) := Canonical_Path; Canonical_Path_Name := Name_Find; + + if Opt.Follow_Links_For_Files then +Resolved_Path_Name := Canonical_Path_Name; + + else +Name_Len := 0; +Add_Str_To_Name_Buffer + (Normalize_Pathname + (Canonical_Path, + Resolve_Links = True, + Case_Sensitive = False)); +Resolved_Path_Name := Name_Find; + end if; + end; if Has_Circular_Dependencies @@ -1351,7 +1366,7 @@ while A_Project_Name_And_Node /= Tree_Private_Part.No_Project_Name_And_Node loop - if A_Project_Name_And_Node.Canonical_Path = Canonical_Path_Name then + if A_Project_Name_And_Node.Resolved_Path = Resolved_Path_Name then if Extended then if A_Project_Name_And_Node.Extended then @@ -1773,6 +1788,17 @@ if Present (Extended_Project) then + if Project_Qualifier_Of (Extended_Project, In_Tree) = + Aggregate + then +Error_Msg_Name_1 := + Name_Id (Path_Name_Of (Extended_Project, In_Tree)); +Error_Msg + (Env.Flags, + cannot extend aggregate project %%, + Location_Of (Project, In_Tree)); + end if; + -- A project that extends an extending-all project is -- also an extending-all project. @@ -1987,7 +2013,7 @@ E = (Name = Name_Of_Project, Display_Name = Display_Name_Of_Project, Node = Project, - Canonical_Path = Canonical_Path_Name, + Resolved_Path = Resolved_Path_Name, Extended = Extended, From_Extended = From_Extended /= None, Proj_Qualifier = Project_Qualifier_Of (Project, In_Tree))); Index: prj-tree.adb === --- prj-tree.adb(revision 207893) +++ prj-tree.adb(working copy) @@ -2922,7 +2922,7 @@ Prj.Tree.Tree_Private_Part.Project_Name_And_Node' (Name = Name, Display_Name = Name, - Canonical_Path = No_Path, + Resolved_Path = No_Path, Node = Project, Extended = False, From_Extended = False, Index: prj-tree.ads === --- prj-tree.ads(revision 207879) +++ prj-tree.ads(working copy) @@ -1469,7 +1469,7 @@ Node : Project_Node_Id; -- Node of the project in table Project_Nodes - Canonical_Path : Path_Name_Type; + Resolved_Path : Path_Name_Type; -- Resolved and canonical path of a real project file. -- No_Name in case of virtual projects. @@ -1488,7 +1488,7 @@ (Name = No_Name, Display_Name = No_Name,
[PATCH] Fix up preprocessing of #pragma GCC ivdep (PR c++/60267)
Hi!
In #pragma GCC ivdep there is nothing the preprocessor should care about,
thus there is no reason to register it when doing just -E (and, otherwise
we'd have to handle PRAGMA_IVDEP in pragma lookups).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2014-02-19 Jakub Jelinek ja...@redhat.com
PR c++/60267
* c-pragma.c (init_pragma): Don't call cpp_register_deferred_pragma
for PRAGMA_IVDEP if flag_preprocess_only.
* gcc.dg/pr60267.c: New test.
--- gcc/c-family/c-pragma.c.jj 2014-02-12 17:46:22.0 +0100
+++ gcc/c-family/c-pragma.c 2014-02-19 09:49:08.410079037 +0100
@@ -1392,8 +1392,9 @@ init_pragma (void)
cpp_register_deferred_pragma (parse_in, GCC, pch_preprocess,
PRAGMA_GCC_PCH_PREPROCESS, false, false);
- cpp_register_deferred_pragma (parse_in, GCC, ivdep, PRAGMA_IVDEP, false,
- false);
+ if (!flag_preprocess_only)
+cpp_register_deferred_pragma (parse_in, GCC, ivdep, PRAGMA_IVDEP,
false,
+ false);
#ifdef HANDLE_PRAGMA_PACK_WITH_EXPANSION
c_register_pragma_with_expansion (0, pack, handle_pragma_pack);
#else
--- gcc/testsuite/gcc.dg/pr60267.c.jj 2014-02-19 09:57:15.083327458 +0100
+++ gcc/testsuite/gcc.dg/pr60267.c 2014-02-19 09:57:51.383122054 +0100
@@ -0,0 +1,14 @@
+/* PR c++/60267 */
+/* { dg-do compile } */
+/* { dg-options -O2 -save-temps } */
+
+void
+foo (int *a, int *b, int *c)
+{
+ int i;
+#pragma GCC ivdep
+ for (i = 0; i 64; i++)
+a[i] = b[i] * c[i];
+}
+
+/* { dg-final { cleanup-saved-temps } } */
Jakub
