[Bug gcov-profile/44728] gcov chokes when "." is present in DIR argument to -o flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44728 maybe524 changed: What|Removed |Added CC||xiaowen.huangg at gmail dot ||com --- Comment #2 from maybe524 2012-10-13 08:02:46 UTC --- ？？
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #16 from Simon Baldwin 2012-10-13 08:08:30 UTC --- (In reply to comment #15) > ... > This has not been the case since 2007, even though it appears to make a lot of > sense... I noticed the same thing while investigating this. write_symbol1 visits every node and writes all unwritten ones, marking them written. Because writing a node may add new nodes, write_symbol1's caller iterates it until no more writes occur. Before reporting the issue I tried several speculative solutions, with no real success. I experimented with the two-step mechanism you mention, but could not convince myself that it would solve the problem. A full tree built before really writing any node still seemed to leave something ordered by (unpredictable) pointer and with integer "tags" that are partially a function of the pointers they represent. I'm not quite seeing how your patch fixes this; it orders writes by tag *within* write_symbol1 calls, but not *across* them. It is hard to reproduce this problem at all. I see it in only one of multiple gcc configurations. It is also hard to evaluate possible solutions -- adding a failed "non-solution" can change the relationship between pointers enough to make the symptoms disappear while not solving the actual problem.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #17 from Ollie Wild 2012-10-13 08:08:49 UTC --- I'm on vacation until Mon, Oct. 15. For compiler related questions, please email c-compiler-t...@google.com. If you need to contact a manager, please email lp-m...@google.com. Thanks, Ollie
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #18 from Joost VandeVondele 2012-10-13 08:13:14 UTC --- (In reply to comment #14) > Created attachment 28425 [details] > Patch for testing thanks... now repeated CP2K compiles give identical '.mod's, and of course also omp_lib.mod is fixed. This will very much improve the user experience for those working on large code bases. since you're using C++, I guess a backport to older branches is out of question
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #19 from Tobias Schlüter 2012-10-13 08:31:39 UTC --- Simon, I don't think the 'integer's are functions of the pointers once you process the symbols in a defined order. The non-determinism was caused by traversing the pointer_info tree based on the non-deterministic pointers. With the patch, the tree is copied to a map sorted by the integers. In the first iteration of write_symbol1 these are given by the traversal of the namespace, which is deterministic. Since we now process these symbols in a deterministic order, the integers of the symbols added during each iteration are also deterministic. I might be missing something, of course. Joost, it wouldn't be much work to implement the same thing using GFC_BBT instead of a std::map. It would require a typedef and one would have to cleanup the tree manually, but if fixing old versions of gcc is valuable, I can do it. I might have to do this anyway, as I don't know if gfortran maintainers like C++isms (even though in this particular case it's probably non-controversial).
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #20 from Simon Baldwin 2012-10-13 09:26:35 UTC --- (In reply to comment #19) > ...Since we now process these symbols in a deterministic order, > the integers of the symbols added during each iteration are also > deterministic. Thanks for the note and the fix. I guess my worry is that the order tags are assigned to symbols is a function of pointer ordering. I see the issue with what look like anonymous symbols, but can't convince myself it couldn't occur with something less anonymous. Suppose two anonymous symbols 'X' differentiated only by their addresses 101 and 102. After tagging there are two X's, call them X1 and X2, that will produce two lines that are identical apart from tag. Ordering by tag makes the order the same even if you reverse their addresses. However, two named symbols 'A' and 'B' at 101 and 102 will become A1 and B2 and produce two lines that differ in both tag and other fields, written in tag order as A first and B second. If you reverse their addresses the tags are assigned differently, A2 and B1. Here B has the smaller tag and so is written before A. At this stage though, I'm out of my depth on fortran, so it may well be that I'm the one missing something.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #21 from Tobias Schlüter 2012-10-13 09:32:10 UTC --- Hm, I don't know about anonymous symbols. If they exist and end up in modules (which I honestly don't know), I would hope that they would obtain their number from some counter, which should still be deterministic as it would be incremented as code and symbols are processed (which is hopefully all deterministic). My idea would be: submit the patch (maybe a non-C++ version as explained above), if the bug ever re-appears we'll need a more invasive solution.
[Bug fortran/54917] [4.7/4.8 Regression] [OOP] TRANSFER on polymorphic variable causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54917 --- Comment #4 from janus at gcc dot gnu.org 2012-10-13 10:01:00 UTC --- (In reply to comment #3) > It could be r177486 or 177486? Not sure. (Note: Both revisions you quote are the same.) Anyway, I can confirm that at least the ICE with -Wsurprising is a regression in 4.7 and trunk, which does not appear with 4.5 and 4.6: ! The following causes an ICE if -Wsurprising is on. subroutine test_routine1(arg) implicit none type test_type integer :: test_comp end type class(test_type) :: arg integer :: i i = transfer(arg, 1) end subroutine
[Bug fortran/54917] [4.7/4.8 Regression] [OOP] TRANSFER on polymorphic variable causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54917 --- Comment #5 from janus at gcc dot gnu.org 2012-10-13 10:05:13 UTC --- However, the other ICE (which does not require -Wsurprising) appears with all gfortran versions I tried from 4.5 to trunk: subroutine test_routine2(arg) implicit none type test_type integer :: test_comp end type test_type class(test_type) :: arg class(test_type), allocatable :: copy copy = transfer(1,arg) end subroutine
[Bug fortran/54917] [4.7/4.8 Regression] [OOP] TRANSFER on polymorphic variable causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54917 --- Comment #6 from Dominique d'Humieres 2012-10-13 10:12:28 UTC --- > > It could be r177486 or 177486? > > Not sure. (Note: Both revisions you quote are the same.) Oops! (never copy and paste after midnight.) r177486 or r177527 (see pr50004). Note the "could"; I am not sure either, but it looks the most likely in the set of patches for the time period. If my guess is right, the patchlet in comment #1 makes sense.
[Bug rtl-optimization/54919] New: [4.6/4.7/4.8 Regression] gcc.dg/torture/pr54877.c FAILs with -fvariable-expansion-in-unroller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54919 Bug #: 54919 Summary: [4.6/4.7/4.8 Regression] gcc.dg/torture/pr54877.c FAILs with -fvariable-expansion-in-unroller Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28439 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28439 preprocessed source Output: $ gcc -O2 -ffast-math -funroll-loops -fvariable-expansion-in-unroller testcase.c $ ./a.out Aborted What happens is that foo() returns -63 instead of -64. .L15: movapdxmm0, xmm2# d, tmp71 subeax, 8# D.1761, subsdxmm0, xmm1# d, tmp69 subsdxmm0, xmm1# d, tmp69 subsdxmm0, xmm1# d, tmp69 1==>movapdxmm2, xmm0# tmp71, d 2==>subsdxmm2, xmm1# tmp71, tmp69 jne.L15#, 3==>addsdxmm0, xmm2# d, tmp71 cvttsd2siedx, xmm0# D.1762, d In each loop, 4 is subtracted, and finally, the sum is multiplied by 2 at (3). The problem is that when (3) is executed, xmm2==-32 and xmm0==-31 ; so the final sum is -63. If (1) and (2) are swapped (and (2) uses xmm0 instead of xmm2), the code works fine: .L15: movapdxmm0, xmm2# d, tmp71 subeax, 8# D.1761, subsdxmm0, xmm1# d, tmp69 subsdxmm0, xmm1# d, tmp69 subsdxmm0, xmm1# d, tmp69 2==>subsdxmm0, xmm1# tmp71, tmp69 1==>movapdxmm2, xmm0# tmp71, d jne.L15#, 3==>addsdxmm0, xmm2# d, tmp71 cvttsd2siedx, xmm0# D.1762, d Note foo() is inlined into main(), so the change has to be done in main() (or the noinline attribute has to be added). Tested revisions: r192420 - fail 4.7 r191640 - fail 4.6 r191640 - fail 4.5 r191640 - fail 4.4 r191640 - OK
[Bug rtl-optimization/54919] [4.6/4.7/4.8 Regression] gcc.dg/torture/pr54877.c FAILs with -fvariable-expansion-in-unroller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54919 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-13 AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Steven Bosscher 2012-10-13 10:38:51 UTC --- I'll have a look.
[Bug bootstrap/54834] bootstrap fails when building libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 Tobias Schlüter changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #6 from Tobias Schlüter 2012-10-13 10:41:44 UTC --- I'm opening this again, as I find the same problem again after updating my git tree, so it's not due to some changed dependencies in the libbacktrace merge: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -funwind-tables -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -c ../../libbacktrace/state.c -o state.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -funwind-tables -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -c ../../libbacktrace/simple.c -o simple.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -funwind-tables -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -c ../../libbacktrace/backtrace.c -o backtrace.o In file included from ../../libbacktrace/backtrace.c:35: ../gcc/include/unwind.h:48: error: unknown machine mode 'unwind_word' In file included from ../../libbacktrace/simple.c:35: ../gcc/include/unwind.h:48: error: unknown machine mode 'unwind_word' ../gcc/include/unwind.h:49: error: unknown machine mode 'unwind_word' ../gcc/include/unwind.h:49: error: unknown machine mode 'unwind_word' In file included from ../../libbacktrace/simple.c:35: ../gcc/include/unwind.h:252:4: error: #error "__SIZEOF_LONG__ macro not defined" ../gcc/include/unwind.h:256:4: error: #error "__SIZEOF_POINTER__ macro not defined" In file included from ../../libbacktrace/backtrace.c:35: ../gcc/include/unwind.h:252:4: error: #error "__SIZEOF_LONG__ macro not defined" ../gcc/include/unwind.h:256:4: error: #error "__SIZEOF_POINTER__ macro not defined" make[4]: *** [simple.lo] Error 1 make[4]: *** Waiting for unfinished jobs make[4]: *** [backtrace.lo] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-stage1-libbacktrace] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 I could fix this by deleting all occurences of unwind.h in the build tree. I therefore assume that some dependencies are broken.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #22 from Tobias Schlüter 2012-10-13 11:29:41 UTC --- Created attachment 28440 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28440 patch that doesn't use c++ Here's a patch that works essentially the same way, but doesn't use C++. It's about 50 lines longer than the other patch and produces identical module files in the small examples. It's not yet ready for submission, as I haven't yet added all the necessary comments, also maybe some variables could be named better, but I would do this if you think it's worthy fixing this on the old branches as well. I would then submit the C++ patch for the trunk and the C version for the older branches.
[Bug middle-end/54885] [4.8 Regression] lto/profiledbootstrap broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54885 Steven Bosscher changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-13 Component|lto |middle-end AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Steven Bosscher 2012-10-13 11:53:09 UTC --- Issue is in df-problems.c's reaching-and-live definitions problem. Which is my wrong-doing.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #23 from Joost VandeVondele 2012-10-13 12:28:12 UTC --- (In reply to comment #22) > Created attachment 28440 [details] > patch that doesn't use c++ I've tested the patch with (an older version of) the 4.7 branch, and it works fine for CP2K.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #24 from Joost VandeVondele 2012-10-13 12:45:11 UTC --- (In reply to comment #23) > I've tested the patch with (an older version of) the 4.7 branch, and it works > fine for CP2K. it doesn't apply cleanly to 4.6, so no testing there unfortunately.
[Bug fortran/54917] [4.7/4.8 Regression] [OOP] TRANSFER on polymorphic variable causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54917 --- Comment #7 from janus at gcc dot gnu.org 2012-10-13 13:08:11 UTC --- (In reply to comment #6) > r177486 or r177527 (see pr50004). Out of these two, I'd rather guess for the latter (but this is not more than a guess). Anyway, I think whatever revision caused the regression probably just 'uncovered' the fact that TRANSFER does not handle polymorphics.
[Bug c++/54913] [4.8 Regression] '#'indirect_ref' not supported by dump_decl#' is not a member of 'E'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54913 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Jonathan Wakely 2012-10-13 13:35:23 UTC --- d0b4bf064cc775c510f804bee8394067530cc2bb is the first bad commit commit d0b4bf064cc775c510f804bee8394067530cc2bb Author: jason Date: Fri Aug 31 02:50:18 2012 + * semantics.c (finish_qualified_id_expr): Handle building up a non-dependent SCOPE_REF here. (finish_id_expression): Not here. * error.c (dump_decl) [SCOPE_REF]: Only pass TFF_UNQUALIFIED_NAME. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@190829 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug tree-optimization/54920] New: [4.8 Regression] segfault in tree-ssa-pre.c during Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54920
Bug #: 54920
Summary: [4.8 Regression] segfault in tree-ssa-pre.c during
Firefox build
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de
insert_into_preds_of_block (block=0x72dba1f8, block@entry=0x76665dd0,
exprnum=, avail=0x72dba1f8)
at /home/markus/gcc/gcc/tree-ssa-pre.c:3085
3085 FOR_EACH_EDGE (pred, ei, block->preds)
(gdb) bt
#0 insert_into_preds_of_block (block=0x72dba1f8,
block@entry=0x76665dd0, exprnum=, avail=0x72dba1f8)
at /home/markus/gcc/gcc/tree-ssa-pre.c:3085
#1 0x009a760e in do_regular_insertion (block=,
dom=) at /home/markus/gcc/gcc/tree-ssa-pre.c:3385
#2 insert_aux (block=block@entry=0x76665dd0) at
/home/markus/gcc/gcc/tree-ssa-pre.c:3599
#3 0x009a7008 in insert_aux (block=block@entry=0x7516bb60) at
/home/markus/gcc/gcc/tree-ssa-pre.c:3609
#4 0x009a7008 in insert_aux (block=block@entry=0x766884e0) at
/home/markus/gcc/gcc/tree-ssa-pre.c:3609
#5 0x009a7008 in insert_aux (block=block@entry=0x76665750) at
/home/markus/gcc/gcc/tree-ssa-pre.c:3609
#6 0x009a7008 in insert_aux (block=block@entry=0x766654e0) at
/home/markus/gcc/gcc/tree-ssa-pre.c:3609
#7 0x009a7008 in insert_aux (block=) at
/home/markus/gcc/gcc/tree-ssa-pre.c:3609
#8 0x009a8b9b in insert () at /home/markus/gcc/gcc/tree-ssa-pre.c:3632
#9 do_pre () at /home/markus/gcc/gcc/tree-ssa-pre.c:4707
#10 do_pre () at /home/markus/gcc/gcc/tree-ssa-pre.c:4660
#11 0x007e927a in execute_one_pass (pass=pass@entry=0x112cdc0) at
/home/markus/gcc/gcc/passes.c:2320
markus@x4 src % cat test.i
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16)));
int a;
__m128i b;
void
fn1 ()
{
while (1)
b = (__m128i) (__v8hi)
{
a, 0, 0, 0, 0, 0
};
}
markus@x4 src % gcc -c -O2 test.i
test.i: In function ‘fn1’:
test.i:7:1: internal compiler error: Segmentation fault
fn1 ()
^
linux-vdso.so.1: No such file or directory
0x88d3ef crash_signal
/home/markus/gcc/gcc/toplev.c:335
inconsistent DWARF line number info
0x9a3ee7 insert_into_preds_of_block
/home/markus/gcc/gcc/tree-ssa-pre.c:3092
0x9a760d do_regular_insertion
/home/markus/gcc/gcc/tree-ssa-pre.c:3385
0x9a760d insert_aux
/home/markus/gcc/gcc/tree-ssa-pre.c:3599
0x9a7007 insert_aux
/home/markus/gcc/gcc/tree-ssa-pre.c:3609
0x9a7007 insert_aux
/home/markus/gcc/gcc/tree-ssa-pre.c:3609
0x9a8b9a insert
/home/markus/gcc/gcc/tree-ssa-pre.c:3632
0x9a8b9a do_pre
/home/markus/gcc/gcc/tree-ssa-pre.c:4707
0x9a8b9a do_pre
/home/markus/gcc/gcc/tree-ssa-pre.c:4660
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug target/54902] [4.7 Regression], ICE (segfault) building on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54902 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson 2012-10-13 15:39:25 UTC --- I can reproduce the ICE with gcc-4.7.2 on armv5tel-linux-gnueabi, sparc64-linux -m32, x86_64-linux -m32, and m68k-linux. I haven't checked any other targets. The ICE stopped on trunk with Richard B's "Make gsi_remove return whether EH cleanup is required" patch in r186159: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00202.html http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00108.html Backporting r186159 and the follow-up fix in r186164 to gcc-4.7.2 eliminates the ICE there for the four targets mentioned above. The description of Richard's patch makes it sound more like a cleanup than a bug fix, so I'm not sure if it actually fixes the bug or just masks it.
[Bug middle-end/54921] New: [4.8 Regression] wrong code with -Os -fno-omit-frame-pointer -fsched2-use-superblocks -fstack-protector -ftree-slp-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54921
Bug #: 54921
Summary: [4.8 Regression] wrong code with -Os
-fno-omit-frame-pointer -fsched2-use-superblocks
-fstack-protector -ftree-slp-vectorize
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Created attachment 28441
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28441
reduced testcase
Output:
$ gcc -Os -fno-omit-frame-pointer -fsched2-use-superblocks -fstack-protector
-ftree-slp-vectorize testcase.c
$ ./a.out
Aborted
(gdb) p a
$1 = {a = 1, b = '\000' }
(gdb) p b
$2 = {a = 2, b = '\000' }
Tested revisions:
r192420 - fail
4.7 r191640 - OK
[Bug target/54841] Bad optimization on stack fill before call on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54841 Richard Earnshaw changed: What|Removed |Added Target||arm Status|UNCONFIRMED |WAITING Last reconfirmed||2012-10-13 Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw 2012-10-13 15:54:53 UTC --- GCC already has optimizations to do this. We need a testcase to find out why it might not be working as expected.
[Bug target/54892] [4.7 Regression], ICE in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54892 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2012-10-13 16:03:37 UTC --- I can reproduce the ICE with g++ 4.8-20121007 and 4.7-20121006, on arm-linux-gnueabi with -march=armv7-a; with -march=armv6 or armv5te it doesn't ICE. The preprocessed source doesn't compile with g++ 4.6 so I can't check there.
[Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 & ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829 --- Comment #5 from Richard Earnshaw 2012-10-13 16:04:55 UTC --- The result of the comparison is used in more than one instruction, so combine cannot safely rework the branch instructions that follow to ensure that the result of the subtract is used correctly. In fact, on ARM there is no branch instruction that can be used for "> 0" as a side effect of a subtract. To get the desired effect the code would have to be completely re-arranged to factor out the "< 0" (bmi) and then "== 0" (beq) cases first.
[Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 & ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829 --- Comment #6 from Richard Earnshaw 2012-10-13 16:18:03 UTC --- Note also that flag setting behaviour of the PPC instruction essentially is a comparison of the result against zero. On ARM the flags are set as if the two input operands were compared; that's not the same as comparing the result with zero.
[Bug rtl-optimization/54919] [4.6/4.7/4.8 Regression] gcc.dg/torture/pr54877.c FAILs with -fvariable-expansion-in-unroller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54919
--- Comment #2 from Steven Bosscher 2012-10-13
16:38:14 UTC ---
At the ".178r.loop2_invariant" dump:
5 r61:SI=0x40 # 64
6 r62:DF=[`*.LC0'] # 0.0
34 r68:DF=[`*.LC1'] # 1.0e+0
L16:
11 r62:DF=r62:DF-r68:DF
12 {r61:SI=r61:SI-0x1;clobber flags:CC;}
13 flags:CCZ=cmp(r61:SI,0)
14 pc={(flags:CCZ==0)?L19:pc}
# {implicit: pc=L16}
L19:
21 r67:SI=fix(r62:DF)
26 ax:SI=r67:SI
29 use ax:SI
Clearly the above loop iterates 64 times. But in the next pass
(".180r.loop2_unroll") the iterations estimate is not 64:
;; *** Considering loop 1 for complete peeling ***
;; Considering peeling once rolling loop
...
Loop 1 is simple:
simple exit 3 -> 5
number of iterations: (const_int 63 [0x3f])
upper bound: 63
realistic bound: 63
;; Unable to prove that the loop rolls exactly once
;; Considering peeling completely
;; Not peeling loop completely, rolls too much (63 iterations > 16 [maximum
peelings])
;; *** Considering loop 1 ***
;; Considering unrolling loop with constant number of iterations
;; max_unroll 8 (8 copies, initial 8).
;; Decided to unroll the constant times rolling loop, 7 times.
But with the wrong iteration estimate, the unrolled loop size is wrong.
[Bug c++/54913] [4.8 Regression] qualified lookup in ctor of class template fails to find static member of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54913
Jonathan Wakely changed:
What|Removed |Added
Summary|[4.8 Regression]|[4.8 Regression] qualified
|'#'indirect_ref' not|lookup in ctor of class
|supported by|template fails to find
|dump_decl#' is not a member of |type
|'E' |
--- Comment #5 from Jonathan Wakely 2012-10-13
17:17:37 UTC ---
Reduced:
struct E
{
static const int& e;
};
template
struct R
{
R() { E::e; }
};
R r;
The error goes away unless:
- E::e is a reference
- R is a template
- the lookup is in a constructor
[Bug c++/54922] New: [C++11][DR 1359] constexpr constructors require initialization of all union members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922
Bug #: 54922
Summary: [C++11][DR 1359] constexpr constructors require
initialization of all union members
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
gcc 4.8.0 20120930 (experimental) compiled with the flags
-Wall -pedantic -std=c++11
rejects the following code:
//
lass nullable_int
{
bool init_;
union {
unsigned char for_value_init;
int value_;
};
public:
constexpr nullable_int() : init_(false), for_value_init() {}
};
//
"main.cpp||In constructor 'constexpr nullable_int::nullable_int()':|
main.cpp|9|error: uninitialized member 'nullable_int::' in
'constexpr' constructor|"
This prevents a very reasonable use-case, namely the creation of a literal type
that contains an anonymous union member.
[Bug rtl-optimization/54919] [4.6/4.7/4.8 Regression] gcc.dg/torture/pr54877.c FAILs with -fvariable-expansion-in-unroller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54919 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka 2012-10-13 18:06:29 UTC --- I think the dump is right. Number of iterations as defined by loop infrastructure is number of execution of loopback edges. For loop after loop header copying has one iteration fewer than one would naturaly assume. The dump seems right - the constant unrolling unrolls 8x that it reports as 7 peelings (that means "produce 7 extra copies of body")
[Bug gcov-profile/44728] gcov chokes when "." is present in DIR argument to -o flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44728 --- Comment #3 from Andreas Schwab 2012-10-13 18:41:14 UTC --- Author: schwab Date: Sat Oct 13 18:41:08 2012 New Revision: 192425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192425 Log: PR gcov-profile/44728 * gcov.c (create_file_names): When stripping extension only look at base name. Modified: trunk/gcc/ChangeLog trunk/gcc/gcov.c
[Bug gcov-profile/44728] gcov chokes when "." is present in DIR argument to -o flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44728 Andreas Schwab changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Andreas Schwab 2012-10-13 18:43:29 UTC --- Fixed.
[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186789
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54404
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.0
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
||med.uc.edu
--- Comment #1 from Jack Howarth 2012-10-13
19:27:40 UTC ---
Below is a trace through current gcc trunk for the failure of...
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++98 (test for errors, line 21)
at -m32 with darwin.c built at -O0 for debugging purposes.
# gdb
/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../cc1plus
...
(gdb) break darwin.c:3310
...
(gdb) r -quiet -nostdinc++ -v -I
/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/include/x86_64-apple-darwin12.2.0
-I
/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/include
-I /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/libstdc++-v3/libsupc++
-I
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/libstdc++-v3/include/backward
-I
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/libstdc++-v3/testsuite/util
-imultilib i386 -iprefix
/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin12.2.0/4.8.0/
-isystem
/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../include
-isystem
/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../include-fixed
-D__DYNAMIC__
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/gcc/testsuite/g++.dg/other/darwin-cfstring1.C
-fPIC -quiet -dumpbase darwin-cfstring1.C -mmacosx-version-min=10.8.2
-mconstant-cfstrings -m32 -mtune=core2 -auxbase-strip darwin-cfstring1.s
-std=gnu++98 -version -fno-diagnostics-show-caret -fmessage-length=0 -o
darwin-cfstring1.s
...
Breakpoint 1, darwin_build_constant_cfstring (str=0x10104dbc0) at
../../gcc-4.8-20121011/gcc/config/darwin.c:3316
3316 if (!str)
(gdb) c
Continuing.
Current language: auto; currently c++
Breakpoint 1, darwin_build_constant_cfstring (str=0x10104ddc0) at
../../gcc-4.8-20121011/gcc/config/darwin.c:3316
3316 if (!str)
(gdb) s
3322 STRIP_NOPS (str);
(gdb)
tree_strip_nop_conversions (exp=0x10104ddc0) at
../../gcc-4.8-20121011/gcc/tree.c:11254
11254{
(gdb)
11204 if (!CONVERT_EXPR_P (exp)
(gdb)
4047 char const __c = TREE_CODE_CLASS (TREE_CODE (__t));
(gdb)
4048 if (!IS_EXPR_CODE_CLASS (__c))
(gdb)
4092 if (VL_EXP_CLASS_P (node))
(gdb)
4095return TREE_CODE_LENGTH (TREE_CODE (node));
(gdb)
4127 if (__i < 0 || __i >= TREE_OPERAND_LENGTH (__u))
(gdb)
11207 if (TREE_OPERAND (exp, 0) == error_mark_node)
(gdb)
3995 if (tree_contains_struct[TREE_CODE(__t)][__s] != 1)
(gdb)
4092 if (VL_EXP_CLASS_P (node))
(gdb)
11210 outer_type = TREE_TYPE (exp);
(gdb)
4092 if (VL_EXP_CLASS_P (node))
(gdb)
4095return TREE_CODE_LENGTH (TREE_CODE (node));
(gdb)
4127 if (__i < 0 || __i >= TREE_OPERAND_LENGTH (__u))
(gdb)
3785 if (tree_contains_struct[TREE_CODE(__t)][__s] != 1)
(gdb)
11211 inner_type = TREE_TYPE (TREE_OPERAND (exp, 0));
(gdb)
11213 if (!inner_type)
(gdb)
11219 || POINTER_TYPE_P (outer_type)
(gdb)
11221 && (INTEGRAL_TYPE_P (inner_type)
(gdb)
11222 || POINTER_TYPE_P (inner_type)
(gdb)
11221 && (INTEGRAL_TYPE_P (inner_type)
(gdb)
3794 if (TREE_CODE_CLASS (TREE_CODE(__t)) != __class)
(gdb)
11224return TYPE_PRECISION (outer_type) == TYPE_PRECISION (inner_type);
(gdb)
3794 if (TREE_CODE_CLASS (TREE_CODE(__t)) != __class)
(gdb)
11224return TYPE_PRECISION (outer_type) == TYPE_PRECISION (inner_type);
(gdb)
11255 while (tree_nop_conversion (exp))
(gdb)
3839 char const __c = TREE_CODE_CLASS (TREE_CODE (__t));
(gdb)
3840 if (!IS_EXPR_CODE_CLASS (__c))
(gdb)
4092 if (VL_EXP_CLASS_P (node))
(gdb)
4095return TREE_CODE_LENGTH (TREE_CODE (node));
(gdb)
4106 if (__i < 0 || __i >= TREE_OPERAND_LENGTH (__u))
(gdb)
11256exp = TREE_OPERAND (exp, 0);
(gdb)
11204 if (!CONVERT_EXPR_P (exp)
(gdb)
11205 && TREE_CODE (exp) != NON_LVALUE_EXPR)
(gdb)
11258}
(gdb)
darwin_build_constant_cfstring (str=0x1429c1e40) at
../../gcc-4.8-20121011/gcc/config/darwin.c:3324
3324 if (TREE_CODE (str) == ADDR_EXPR)
(gdb)
3327 if (TREE_CODE (str) != STRING_CST)
(gdb)
3329 error ("CFString literal expression is not a string constant");
(gdb)
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121011/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:
In function ‘int main()’:
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-201
[Bug rtl-optimization/54871] [4.8 regression] gfortran.dg/vector_subscript_1.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54871 --- Comment #5 from Eric Botcazou 2012-10-13 20:22:18 UTC --- Author: ebotcazou Date: Sat Oct 13 20:22:07 2012 New Revision: 192426 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192426 Log: PR rtl-optimization/54871 * loop-iv.c (simplify_using_initial_values): When scanning previous basic blocks, prune the recorded conditions if the current insn was not used to make a replacement. * loop-unroll.c (decide_unroll_constant_iterations): Clean up message. (unroll_loop_constant_iterations): Clarify head comment. (decide_unroll_runtime_iterations): Clean up message. (unroll_loop_runtime_iterations): Clarify head comment. (decide_peel_simple): Clean up message. (peel_loop_simple): Clarify head comment. (decide_unroll_stupid): Clean up message. (unroll_loop_stupid): Clarify head comment. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c trunk/gcc/loop-unroll.c
[Bug rtl-optimization/54871] [4.8 regression] gfortran.dg/vector_subscript_1.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54871 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Eric Botcazou 2012-10-13 20:30:40 UTC --- This should work now.
[Bug c++/54922] [C++11][DR 1359] constexpr constructors require initialization of all union members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922
--- Comment #1 from Daniel Krügler
2012-10-13 20:54:14 UTC ---
(In reply to comment #0)
Some copy'n-paste error occurred while attempting to format the code example.
The correct code under investigation was:
//
class nullable_int
{
bool init_;
union {
unsigned char for_value_init;
int value_;
};
public:
constexpr nullable_int() : init_(false), for_value_init() {}
};
//
[Bug fortran/54870] [4.8 regression] gfortran.dg/array_constructor_4.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54870 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-13 Summary|gfortran.dg/array_construct |[4.8 regression] |or_4.f90 FAILs |gfortran.dg/array_construct ||or_4.f90 FAILs Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou 2012-10-13 21:33:44 UTC --- Confirmed.
[Bug target/54892] [4.7 Regression], ICE in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54892 --- Comment #2 from Mikael Pettersson 2012-10-13 21:35:21 UTC --- The ICE started with Richard Henderson's "[ARM] Convert to atomic optabs" patch in r183050: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00288.html http://gcc.gnu.org/ml/gcc-cvs/2012-01/msg00290.html
[Bug rtl-optimization/54919] [4.6/4.7/4.8 Regression] gcc.dg/torture/pr54877.c FAILs with -fvariable-expansion-in-unroller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54919 --- Comment #4 from Steven Bosscher 2012-10-13 21:51:15 UTC --- Created attachment 28442 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28442 Perform replacement in REG_EQUAL notes too
[Bug fortran/54917] [4.7/4.8 Regression] [OOP] TRANSFER on polymorphic variable causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54917
--- Comment #8 from janus at gcc dot gnu.org 2012-10-13 21:52:39 UTC ---
The following fixes the ICE(s) on comment 5 ...
Index: gcc/fortran/target-memory.c
===
--- gcc/fortran/target-memory.c(revision 192392)
+++ gcc/fortran/target-memory.c(working copy)
@@ -121,6 +121,7 @@ gfc_target_expr_size (gfc_expr *e)
case BT_HOLLERITH:
return e->representation.length;
case BT_DERIVED:
+case BT_CLASS:
{
/* Determine type size without clobbering the typespec for ISO C
binding types. */
@@ -572,6 +573,9 @@ gfc_target_interpret_expr (unsigned char *buffer,
gfc_interpret_character (buffer, buffer_size, result);
break;
+case BT_CLASS:
+ result->ts = result->ts.u.derived->components->ts;
+ /* Fall through. */
case BT_DERIVED:
result->representation.length =
gfc_interpret_derived (buffer, buffer_size, result);
... which is then rejected with:
copy = transfer(1,arg)
1
Error: Variable must not be polymorphic in intrinsic assignment at (1) - check
that there is a matching specific subroutine for '=' operator
Intrinsic assignment to polymorphic variables is an F08 feature, which is not
yet implemented in gfortran, cf. PR 43366.
[Bug fortran/54870] [4.8 regression] gfortran.dg/array_constructor_4.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54870
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #3 from Eric Botcazou 2012-10-13
22:06:12 UTC ---
Created attachment 28443
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28443
Reduced testcase
The dse2 dump reads:
dse: local deletions = 0, global deletions = 1, spill deletions = 0
starting the processing of deferred insns
deleting insn with uid = 25.
ending the processing of deferred insns
but the memory location stored to
(insn 25 27 154 2 (set (mem/c:SI (plus:DI (reg/f:DI 30 %fp)
(const_int 2039 [0x7f7])) [6 A.1+16 S4 A64])
(reg:SI 1 %g1 [136])) array_constructor_4.f90:4 61 {*movsi_insn}
(nil))
is read by a subsequent call to memcpy.
[Bug fortran/54923] New: Internal unit I/O error when using -malign-double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54923 Bug #: 54923 Summary: Internal unit I/O error when using -malign-double Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: gnu@gishpuppy.com Reading from of integer from character string fails with Fortran runtime error: Internal unit I/O error when compiling with -malign-double. Background: This occurred when using the usual getarg(1,arg) construct and linking against FFTW3, which requires data alignment. Minimal example: ___ PROGRAM readtest IMPLICIT NONE CHARACTER*8 arg INTEGER inputarg arg=" 1 " READ(arg,*) inputarg PRINT *,"Argument supplied was: ", inputarg RETURN END ___ Compiling with gfortran without data alignment yields the expected result. Compiling with -malign-double in the compiler options yields runtime error. Thank you.
[Bug lto/50293] -flto fails if GCC is installed in directory with space in path name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50293 --- Comment #2 from Cody Schafer 2012-10-14 00:58:44 UTC --- I've just run into the same issue with gcc 4.7.2 (using the binary here: http://www.makehackvoid.com/sites/default/files/MHV_AVR_Tools_20121007.exe ) Disabling LTO allows the link to complete.
[Bug fortran/54923] Internal unit I/O error when using -malign-double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54923 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||INVALID --- Comment #1 from kargl at gcc dot gnu.org 2012-10-14 02:52:50 UTC --- You need to compile all libraries with -malign-double. This includes libgfortran.
[Bug fortran/54923] Internal unit I/O error when using -malign-double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54923 Dominique d'Humieres changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Dominique d'Humieres 2012-10-14 04:35:34 UTC --- > You need to compile all libraries with -malign-double. > This includes libgfortran. For a more detailed explanation you may look at pr31696 or pr45724 (also pr29562). *** This bug has been marked as a duplicate of bug 31696 ***
[Bug fortran/31696] -malign-double trashes fortran format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31696 Dominique d'Humieres changed: What|Removed |Added CC||gnu.0kn at gishpuppy dot ||com --- Comment #7 from Dominique d'Humieres 2012-10-14 04:35:34 UTC --- *** Bug 54923 has been marked as a duplicate of this bug. ***
[Bug target/54404] [4.8 Regression] *cfstring* failures for (obj-c|g)++ on *-apple-darwin* after revision 186789
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54404
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-10-14
Ever Confirmed|0 |1
--- Comment #2 from Dominique d'Humieres 2012-10-14
05:51:59 UTC ---
> This is a follow up of pr53283 for the remaining failures of some *cfstring*
> tests on *-apple-darwin* after revision 186789: ...
This was an over simplification of the problem. On x86_64-apple-darwin10
revision 186789 introduced an ICE
g++.dg/other/darwin-cfstring1.C:13:80: internal compiler error: in
ix86_expand_builtin, at config/i386/i386.c:30398
fixed between revisions 189336 and 189490 (likely 189391). The errors reported
in comment #0 appeared only after the ICE has been fixed.
On powerpc-apple-darwin9 the failures appeared between revisions 186440 (OK)
and 187171 (failures).
For the test g++.dg/other/darwin-cfstring1.C, the error changed between
revisions 186788 and 189490 from
/opt/gcc/work/gcc/testsuite/g++.dg/other/darwin-cfstring1.C: In function 'int
main()':
/opt/gcc/work/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:21:20: error:
CFString literal expression is not a string constant
/opt/gcc/work/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:22:20: error:
CFString literal expression is not a string constant
to
/opt/gcc/work/gcc/testsuite/g++.dg/other/darwin-cfstring1.C: In function 'int
main()':
/opt/gcc/work/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:13:79: error:
CFString literal expression is not a string constant
/opt/gcc/work/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:21:20: note: in
expansion of macro 'CFSTR'
/opt/gcc/work/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:13:79: error:
CFString literal expression is not a string constant
/opt/gcc/work/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:22:20: note: in
expansion of macro 'CFSTR'
The following patch adjusts the errors/notes to the present pattern while
hopefully retaining the intent of the original test
--- ../_clean/gcc/testsuite/g++.dg/other/darwin-cfstring1.C2010-10-23
22:17:07.0 +0200
+++ gcc/testsuite/g++.dg/other/darwin-cfstring1.C2012-10-13
23:54:37.0 +0200
@@ -10,7 +10,7 @@
#ifdef __CONSTANT_CFSTRINGS__
#undef CFSTR
-#define CFSTR(STR) ((CFStringRef) __builtin___CFStringMakeConstantString
(STR))
+#define CFSTR(STR) ((CFStringRef) __builtin___CFStringMakeConstantString
(STR)) /* { dg-error "CFString literal expression is not a string constant" }
*/
#endif
extern int cond;
@@ -18,8 +18,8 @@ extern const char *func(void);
int main(void) {
CFStringRef s1 = CFSTR("Str1");
- CFStringRef s2 = CFSTR(cond? "Str2": "Str3"); /* { dg-error "CFString
literal expression is not a string constant" } */
- CFStringRef s3 = CFSTR(func()); /* { dg-error "CFString literal expression
is not a string constant" } */
+ CFStringRef s2 = CFSTR(cond? "Str2": "Str3"); /* { dg-message "note: in
expansion of macro 'CFSTR'" } */
+ CFStringRef s3 = CFSTR(func()); /* { dg-message "note: in expansion of
macro 'CFSTR'" } */
return 0;
}
The situation for the test obj-c++.dg/strings/const-cfstring-2.mm is more
puzzling. The failures appeared in the same revision frame and is due to the
fact that the lines
CFStringRef s4 = CFSTR("\222 - Non-ASCII literal"); /* { dg-warning
"non-ASCII character in CFString literal" } */
CFStringRef s5 = CFSTR("Non-ASCII (\222) literal"); /* { dg-warning
"non-ASCII character in CFString literal" } */
...
CFStringRef s7 = CFSTR("Embedded \0NUL"); /* { dg-warning "embedded NUL in
CFString literal" } */
CFStringRef s8 = CFSTR("Embedded NUL\0"); /* { dg-warning "embedded NUL in
CFString literal" } */
do not give the expected warnings, while the lines
NSString *s3 = @"Non-ASCII literal - \222"; /* { dg-warning
"non-ASCII character in CFString literal" } */
NSString *s6 = @"\0Embedded NUL"; /* { dg-warning "embedded NUL in
CFString literal" } */
do: the NSString lines work as expected, but the CFStringRef one don't.
