[Bug fortran/38318] moving the allocation of temps out of loops.
--- Comment #2 from jv244 at cam dot ac dot uk 2010-02-21 09:12 --- seemingly being discussed, since useful for tonto http://gcc.gnu.org/ml/fortran/2010-02/msg00157.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- Comment #31 from paolo dot carlini at oracle dot com 2010-02-21 09:51 --- (In reply to comment #30) Wouldn't it be a violation of the one definition rule (ODR), when one translation unit is compiled with -fwrapv and another without? In that case this would be a regression. I don't know if this comes as a surprise to you, but in the library we have *tons* of potential violations of this type, due to command line switches, not just the big cases like debug-mode, but also rtti, exceptions, etc. That said, if people prefer a false value, always, just tell me and let's close this PR because I don't think the compiler is going to change any time soon to warrant a true value irrespective of any command line option ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug fortran/41113] spurious _gfortran_internal_pack
--- Comment #23 from paul dot richard dot thomas at gmail dot com 2010-02-21 10:43 --- Subject: Re: spurious _gfortran_internal_pack I was going to check out the situation for 4.4. However, my inclination is to close it. I'll be working on it tonight. Cheers Paul On Sat, Feb 20, 2010 at 10:51 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #22 from burnus at gcc dot gnu dot org 2010-02-20 21:51 --- Can this PR be closed as FIXED? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113 --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
[Bug fortran/43072] unneeded temporary (s=s+f(a))
--- Comment #6 from paul dot richard dot thomas at gmail dot com 2010-02-21 10:43 --- Subject: Re: unneeded temporary (s=s+f(a)) Same as 41113 - I'll decide what to do tonight - see you on #gfortran? Paul On Sat, Feb 20, 2010 at 10:48 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #5 from burnus at gcc dot gnu dot org 2010-02-20 21:48 --- Can this PR be closed? I think it is fixed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43072 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43072
[Bug fortran/38318] moving the allocation of temps out of loops.
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-21 11:06 --- (In reply to comment #2) seemingly being discussed, since useful for tonto http://gcc.gnu.org/ml/fortran/2010-02/msg00157.html But there: it's unfortunately not possible to avoid the temporary creation without serious data-flow analysis work - too late for the frontend Thus, this seems to be more a middle-end item. Regarding the current timing, I get with ifort -O3 -fast (v 11.1) vs. gfortran -flto -fwhole-program -O3 --fast-math -march=native (today's 4.5) It is also interesting that gfortran is much faster for the optimized version than ifort. gfortran ifort Default [s]: 24.881554 Default [s]: 5.108319 OPT1 [s]: 1.6641045OPT1 [s]: 3.280205 OPT2 [s]: 1.6641045OPT2 [s]: 4.988311 0.000 0.000E+00 real0m28.420sreal0m13.400s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
[Bug c++/43131] New: internal compiler error: tree check expected class �type� have �exceptional�
Seen with gcc 4.4.0: $ gcc temp.cpp -I../.. In file included from temp.cpp:2: ../../gptm/thread_scope_new.h:128: internal compiler error: tree check: expected class type, have exceptional (identifier_node) in constructor_name_full, at cp/name-lookup.c:1777 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-dl/configure Thread model: posix gcc version 4.4.0 20090217 (experimental) (GCC) I don't know, but it might relate to bug 43082. -- Summary: internal compiler error: tree check expected class type have exceptional Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kian dot karas dot dev at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43131
[Bug c++/43131] internal compiler error: tree check expected class �type� have �exceptional�
--- Comment #1 from kian dot karas dot dev at gmail dot com 2010-02-21 12:02 --- Created an attachment (id=19931) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19931action=view) Preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43131
[Bug middle-end/38318] moving the allocation of temps out of loops.
--- Comment #4 from jv244 at cam dot ac dot uk 2010-02-21 12:11 --- (In reply to comment #3) (In reply to comment #2) seemingly being discussed, since useful for tonto http://gcc.gnu.org/ml/fortran/2010-02/msg00157.html But there: it's unfortunately not possible to avoid the temporary creation without serious data-flow analysis work - too late for the frontend Thus, this seems to be more a middle-end item. right, changing component as such. This would actually be much more powerful as a middle-end thing, since it would also capture the case where a programmer would explicitly allocate/deallocate stuff in a loop. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Component|fortran |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
[Bug c++/43131] internal compiler error: tree check expected class �type� have �exceptional�
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-21 12:19 --- I can't reproduce this with the *released* gcc4.4.0 or current gcc-4_4-branch, I get instead: ../../gptm/thread_scope_new.h:128: error: declaration of ~ThreadScopeNew as member of gptm::ThreadScope_NewMessagePolicy, ThreadSupplierPolicy I see you are using a 20090217 pre-release: I would suggest trying again with *current* gcc4.4.x, either from SVN or gcc4.4.3, and in case file a new PR. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.4.0 4.4.3 4.5.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43131
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- Comment #32 from veksler at il dot ibm dot com 2010-02-21 12:44 --- (In reply to comment #31) (In reply to comment #30) Wouldn't it be a violation of the one definition rule (ODR), when one translation unit is compiled with -fwrapv and another without? In that case this would be a regression. I don't know if this comes as a surprise to you, but in the library we have *tons* of potential violations of this type, due to command line switches, not just the big cases like debug-mode, but also rtti, exceptions, etc. That said, if people prefer a false value, always, just tell me and let's close this PR because I don't think the compiler is going to change any time soon to warrant a true value irrespective of any command line option ... If this hazard is so prevalent shouldn't it deserve a separate PR? If a method or function depend on a flag or macro then it can be handled by overloading and specialization without ODR violation. When this hazard is, like in this case, appears in a constant then things are more difficult. An unexpected behavior may be observed when is_modulo is passed by reference, and I don't see what can be done in this case, not in 100% of the scenarios. Even if GCC annotates the two different variants of is_modulo differently, such that there will be two different physical allocations of is_modulo, it will still be possible to get to some misbehavior in weird cases. Oh well... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #41 from dominiq at lps dot ens dot fr 2010-02-21 12:46 --- AFAICT this pr and the side effects have been fixed, hence closing. If someone disagree, please reopen. Thanks all for the work. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug target/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #14 from dominiq at lps dot ens dot fr 2010-02-21 12:47 --- Closing as fixed. Thanks for the patch. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug middle-end/41043] [4.4 Regression] virtual memory exhausted: Cannot allocate memory
--- Comment #11 from dominiq at lps dot ens dot fr 2010-02-21 12:49 --- Any plan to backport the fix to 4.4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
[Bug middle-end/41043] [4.4 Regression] virtual memory exhausted: Cannot allocate memory
--- Comment #12 from rguenther at suse dot de 2010-02-21 12:50 --- Subject: Re: [4.4 Regression] virtual memory exhausted: Cannot allocate memory On Sun, 21 Feb 2010, dominiq at lps dot ens dot fr wrote: --- Comment #11 from dominiq at lps dot ens dot fr 2010-02-21 12:49 --- Any plan to backport the fix to 4.4? Later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- Comment #33 from paolo dot carlini at oracle dot com 2010-02-21 12:53 --- (In reply to comment #32) If this hazard is so prevalent shouldn't it deserve a separate PR? If a method or function depend on a flag or macro then it can be handled by overloading and specialization without ODR violation. It would be closed immediately as WONTFIX, to be clear. There is nothing we can do in the foreseeable future, it's **everywhere** and totally unfixable without breaking ABI and much more than that. When this hazard is, like in this case, appears in a constant then things are more difficult. An unexpected behavior may be observed when is_modulo is passed by reference, and I don't see what can be done in this case, not in 100% of the scenarios. Even if GCC annotates the two different variants of is_modulo differently, such that there will be two different physical allocations of is_modulo, it will still be possible to get to some misbehavior in weird cases. Oh well... I see that I'm not going to work on it. Actually, I'll wait one month or so, and then if I will not get at least one concrete proposal, I will close this one as WONTFIX. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- Comment #34 from rguenth at gcc dot gnu dot org 2010-02-21 13:04 --- (In reply to comment #33) (In reply to comment #32) If this hazard is so prevalent shouldn't it deserve a separate PR? If a method or function depend on a flag or macro then it can be handled by overloading and specialization without ODR violation. It would be closed immediately as WONTFIX, to be clear. There is nothing we can do in the foreseeable future, it's **everywhere** and totally unfixable without breaking ABI and much more than that. When this hazard is, like in this case, appears in a constant then things are more difficult. An unexpected behavior may be observed when is_modulo is passed by reference, and I don't see what can be done in this case, not in 100% of the scenarios. Even if GCC annotates the two different variants of is_modulo differently, such that there will be two different physical allocations of is_modulo, it will still be possible to get to some misbehavior in weird cases. Oh well... I see that I'm not going to work on it. Actually, I'll wait one month or so, and then if I will not get at least one concrete proposal, I will close this one as WONTFIX. Or suspend it. I think this warrants a defect report anyway since I think is_modulo was intended to describe CPU behavior as otherwise defining signed integer overflow as undefined in one piece of the standard and then requiring a sane answer for is_modulo in another part sounds like a conflict of interest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug fortran/35259] -fassociative-math not enabled by default; No option to associate with PAREN_EXPRs
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-21 13:06 --- Subject: Bug 35259 Author: burnus Date: Sun Feb 21 13:06:07 2010 New Revision: 156937 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156937 Log: 2010-02-21 Tobias Burnus bur...@net-b.de PR fortran/35259 * doc/invoke.texi (-fassociative-math): Document that this option is automatically enabled for Fortran. 2010-02-21 Tobias Burnus bur...@net-b.de PR fortran/35259 * gfortran.h (gfc_option_t): New flag -fprotect-parens. * lang.opt: Ditto. * option.c (gfc_init_options,gfc_handle_option): Ditto. * trans-expr.c (gfc_conv_expr_op): Use the flag. * invoke.texi: Document new -fno-protect-parens flag. 2010-02-21 Tobias Burnus bur...@net-b.de PR fortran/35259 * gfortran.dg/reassoc_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/reassoc_5.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35259
[Bug fortran/35259] -fassociative-math not enabled by default; No option to associate with PAREN_EXPRs
--- Comment #7 from burnus at gcc dot gnu dot org 2010-02-21 13:06 --- FIXED on the (4.5) trunk. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35259
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- Comment #35 from veksler at il dot ibm dot com 2010-02-21 13:33 --- (In reply to comment #34) (In reply to comment #33) (In reply to comment #32) If this hazard is so prevalent shouldn't it deserve a separate PR? If a method or function depend on a flag or macro then it can be handled by overloading and specialization without ODR violation. It would be closed immediately as WONTFIX, to be clear. There is nothing we can do in the foreseeable future, it's **everywhere** and totally unfixable without breaking ABI and much more than that. Yes, it is a big task which is probably not worth it, but is it unfixable? Is it possible that these ODR violations will ever be translated to security issues? For example, the data structure is updated in one translation unit in a way that causes memory corruption when accessed by a different definition in a different translation unit? This is all theoretic but as history has shown, theoretic security threats become real - eventually. I see that I'm not going to work on it. Actually, I'll wait one month or so, and then if I will not get at least one concrete proposal, I will close this one as WONTFIX. Or suspend it. I think this warrants a defect report anyway since I think is_modulo was intended to describe CPU behavior as otherwise defining signed integer overflow as undefined in one piece of the standard and then requiring a sane answer for is_modulo in another part sounds like a conflict of interest. Maybe it is better to make things clear, but I am not so sure of the outcome. I think that is_modulo is meaningful only if it is true, otherwise, when false user's code can't rely on any specific behavior. Maybe is_modulo=false is the right answer even for -fwrapv after all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- Comment #36 from rguenther at suse dot de 2010-02-21 13:37 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistent with gcc On Sun, 21 Feb 2010, veksler at il dot ibm dot com wrote: Or suspend it. I think this warrants a defect report anyway since I think is_modulo was intended to describe CPU behavior as otherwise defining signed integer overflow as undefined in one piece of the standard and then requiring a sane answer for is_modulo in another part sounds like a conflict of interest. Maybe it is better to make things clear, but I am not so sure of the outcome. I think that is_modulo is meaningful only if it is true, otherwise, when false user's code can't rely on any specific behavior. Maybe is_modulo=false is the right answer even for -fwrapv after all. Or maybe is_modulo=true has only practical meaning for code that doesn't invoke undefined behavior anyway (like adding two signed integers when the operation will overflow). That also avoids the /-1 and %-1 issues. It really depends on how is_modulo was supposed to be used. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug fortran/36933] unneeded temporary with derived type containing an array as argument
--- Comment #9 from jv244 at cam dot ac dot uk 2010-02-21 14:11 --- (In reply to comment #7) (In reply to comment #3) This could be somewhat similar, I really wonder if this needs a temp: TYPE T1 INTEGER :: a(3) END TYPE T1 TYPE(T1), POINTER :: x,y ALLOCATE(x,y) x%a=y%a END I think one needs a temporary, cf. the following code: integer, pointer :: a(:),b(:) allocate(a(3)) a = [1,2,3] b = a(3:1:-1) a = b print *, a end this is example is different, here a temp can not be avoided. It is different in that a and b have the pointer attribute, while x%a and x%b do not have the pointer attribute (only the parent structure). But still, the example in comment #3 seems tricky enough to defer optimization if you as me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36933
[Bug fortran/36932] unneeded temporary (2x)
--- Comment #14 from jv244 at cam dot ac dot uk 2010-02-21 14:12 --- all fixed -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36932
[Bug fortran/41113] spurious _gfortran_internal_pack
--- Comment #24 from jv244 at cam dot ac dot uk 2010-02-21 14:16 --- (In reply to comment #23) Subject: Re: spurious _gfortran_internal_pack I was going to check out the situation for 4.4. However, my inclination is to close it. I'll be working on it tonight. this is not stuff to backport to a branch like that. I would just close it. In that case I'll leave it to you to close. Cheers Paul On Sat, Feb 20, 2010 at 10:51 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #22 from burnus at gcc dot gnu dot org 2010-02-20 21:51 --- Can this PR be closed as FIXED? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113 --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
[Bug target/27016] [4.3/4.4/4.5 Regression] ARM optimizer produces severely suboptimal code
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-21 14:32 ---
I have played with CSiBE with this patch:
-- 8 -
--- ../../gcc/gcc/config/arm/arm.c 2010-02-12 21:45:29.0 +0100
+++ ../../combined/gcc/config/arm/arm.c 2010-02-21 14:54:23.0 +0100
@@ -7448,7 +7448,7 @@
arm_arm_address_cost (rtx x)
{
enum rtx_code c = GET_CODE (x);
-
+if (1) return 1;
if (c == PRE_INC || c == PRE_DEC || c == POST_INC || c == POST_DEC)
return 0;
if (c == MEM || c == LABEL_REF || c == SYMBOL_REF)
-- 8 -
I tried CSiBE on arm-eabi with -Os -mabi=aapcs-linux (latter flag is required
for mpeg2dec-0.3.1), but I only looked at size because I have no ARM board to
test speed on.
Overall the patch results in smaller code:
textdata bss dec hex filename
3226845 316581 561788 4105214 3ea3fe (TOTALS)unpatched
3226269 316581 561788 4104638 3ea1be (TOTALS)patched
For the individual files the results vary. A more detailed investigation is
necessary to figure out when a patch like the above is a win, and when it is
not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27016
[Bug c/43128] c-c++-common/pr41779.c doesn't work
--- Comment #7 from hjl dot tools at gmail dot com 2010-02-21 15:39 --- It also failed on Linux/x86-64 with -m32: FAIL: c-c++-common/pr41779.c -Wc++-compat (test for warnings, line 30) -- hjl dot tools at gmail dot com changed: What|Removed |Added Last reconfirmed|2010-02-20 10:40:49 |2010-02-21 15:39:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug c/43125] [4.5 Regression] Revision 156907 failed gcc.dg/attr-used.c
-- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |c Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-21 15:51:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43125
[Bug c/43128] c-c++-common/pr41779.c doesn't work
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug fortran/38199] missed optimization: I/O performance
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-02-21 15:59 --- An update. I have a patch developing. Conceptually, it requires handling of separators in list_read.c to be moved to the beginning of each invocation of list_formatted_read_scalar. This avoids trying to eat_spaces or separators after a value is read. This change is actually the right thing to do since it takes code scattered in several places and consolidates it to one place. The result is execution time on the original testcase is reduced to less then .2 seconds. I don't expect significant performance gains in general, though the code should be more maintainable The patch is a bit intrusive, especially in namelist areas, so may be best for 4.6 at this stage. (assuming I get it to work completely at all :) ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
[Bug other/42980] GCC parallel make install failures
--- Comment #5 from rwild at gcc dot gnu dot org 2010-02-21 16:13 --- Thanks for the logs. I don't understand the libiberty installation failure yet. Can you please run the following, and provide the log file and the number of runs needed, in case it provokes a failure? while make -j install-target-libiberty SHELL=/bin/sh -x log-file 21; do echo $((n++)) done Otherwise, you might need to just interrupt this after a while. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980
[Bug c/43128] c-c++-common/pr41779.c doesn't work
--- Comment #8 from hjl dot tools at gmail dot com 2010-02-21 16:15 --- It is C99 and ILP32: [...@gnu-6 gcc]$ ./xgcc -B./ -S /export/gnu/import/git/gcc/gcc/testsuite/c-c++-common/pr41779.c -Wconversion -m32 -std=c99 [...@gnu-6 gcc]$ ./xgcc -B./ -S /export/gnu/import/git/gcc/gcc/testsuite/c-c++-common/pr41779.c -Wconversion -m32 /export/gnu/import/git/gcc/gcc/testsuite/c-c++-common/pr41779.c: In function f5: /export/gnu/import/git/gcc/gcc/testsuite/c-c++-common/pr41779.c:30:3: warning: conversion to float from int may alter its value [...@gnu-6 gcc]$ -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug c/40528] Add a new ifunc attribute
--- Comment #13 from agner at agner dot org 2010-02-21 16:21 --- What is the status of this issue? Is option 3 implemented? Which versions of Linux and binutils support IFUNC? Any plans for BSD and Mac? -- agner at agner dot org changed: What|Removed |Added CC||agner at agner dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
[Bug other/43132] New: installation directory defaults do not match documentation, Coding Standards
Since the update to Autoconf = 2.60, the installation directory defaults do not match the GNU Coding Standards, nor do they match the semantics documented in the manual. The problems are described in more detail in http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00696.html. Opening this bug so that this is not forgotten. -- Summary: installation directory defaults do not match documentation, Coding Standards Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwild at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug web/43133] New: changes.html needs to document configure API changes due to autotools upgrade
The autotools upgrade (specifically, the move to Autoconf = 2.60) changed installation directory variable defaults. This patch http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01598.html would do that, but it is not correct as of now, because of the issues mentioned in PR 43132 and in http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00696.html. -- Summary: changes.html needs to document configure API changes due to autotools upgrade Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwild at gcc dot gnu dot org BugsThisDependsOn: 43132 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43133
[Bug other/43134] New: installation directory defaults do not match documentation, Coding Standards
Since the update to Autoconf = 2.60, the installation directory defaults do not match the GNU Coding Standards, nor do they match the semantics documented in the manual. The problems are described in more detail in http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00696.html. Opening this bug so that this is not forgotten. -- Summary: installation directory defaults do not match documentation, Coding Standards Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwild at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43134
[Bug other/43134] installation directory defaults do not match documentation, Coding Standards
--- Comment #1 from rwild at gcc dot gnu dot org 2010-02-21 16:28 --- sorry for the dupe *** This bug has been marked as a duplicate of 43132 *** -- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43134
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
--- Comment #1 from rwild at gcc dot gnu dot org 2010-02-21 16:28 --- *** Bug 43134 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug web/43133] changes.html needs to document configure API changes due to autotools upgrade
-- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-21 16:28:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43133
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
-- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-21 16:29:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug c/40528] Add a new ifunc attribute
--- Comment #14 from hjl dot tools at gmail dot com 2010-02-21 16:34 --- (In reply to comment #13) What is the status of this issue? It is implemented on ifunc branch. Is option 3 implemented? Yes, on ifunc branch. Which versions of Linux and binutils support IFUNC? You need at least glibc 2.11 and binutils 2.20. Any plans for BSD and Mac? You have to ask BSD and Mac people since IFUNC support needs to be implemented in both binutils and the C library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
--- Comment #9 from hjl dot tools at gmail dot com 2010-02-21 16:46 --- On Linux/ia32, -std=c99 changes silently float to long double and we don't get a warning. It is a regression from gcc 4.4. -- hjl dot tools at gmail dot com changed: What|Removed |Added Known to fail||4.5.0 Known to work||4.4.3 Summary|c-c++-common/pr41779.c |[4.5 Regression] c-c++- |doesn't work|common/pr41779.c doesn't ||work http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
--- Comment #3 from dodji at gcc dot gnu dot org 2010-02-21 16:47 --- Okay Daniel, your POV makes sense to me. Thank you. I am preparing a patch. -- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-11 18:44:13 |2010-02-21 16:47:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
--- Comment #10 from hjl dot tools at gmail dot com 2010-02-21 16:47
---
[...@gnu-6 gcc]$ cat /tmp/x.i
float f5(float x, int y)
{
return x * y;
}
[...@gnu-6 gcc]$ gcc -S /tmp/x.i -Wconversion -m32 -std=c99
/tmp/x.i: In function f5:
/tmp/x.i:3: warning: conversion to float from int may alter its value
[...@gnu-6 gcc]$ ./xgcc -B./ -S /tmp/x.i -Wconversion -m32 -std=c99
[...@gnu-6 gcc]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
--- Comment #11 from manu at gcc dot gnu dot org 2010-02-21 17:25 --- I may have miscompared the bootstrap results to miss this because I do test -m32. Yes, the excess precision stuff changes the common type to long double in build_binary_op in C and -m32 (but not in C++!). Joseph, is this the correct thing to do or a latent bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
--- Comment #2 from rwild at gcc dot gnu dot org 2010-02-21 17:27 ---
I think one way to start addressing this would be to transport an unexpanded
docdir='${datarootdir}/doc/${PACKAGE}'
through to the sub makes (it's fairly irrelevant whether datarootdir is
expanded
in the toplevel or not, ${PACKAGE} is important so that it can vary between the
different components of the tree.
Right now I don't see how to escape this thing properly so it gets through the
toplevel machinery.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
--- Comment #12 from joseph at codesourcery dot com 2010-02-21 17:43 --- Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't work There is a technical bug here, in that the semantics I intended to implement and said I was implementing were that implicit conversions from integers to floating-point types result in a value representable in the new type. It's not the missing warning that's the bug - right now there is a conversion to long double of a value representable in long double, so the lack of warning is in accordance with the semantics implemented. What is a bug is that the semantics implemented as not as intended. That they are not proper excess precision semantics (and remember that no previous release had proper excess precision semantics, so this is barely a regression) relies on such implicit conversions not being operations with floating operands and so not being liable to have excess precision under 5.2.4.2.2 paragraph 8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
--- Comment #13 from manu at gcc dot gnu dot org 2010-02-21 17:57 --- (In reply to comment #12) Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't work Sorry I do not understand completely your answer. Shouldn't we warn at all? If the semantics were implemented as intended, should we warn? Also, the casting to long double seems to be introduced by the float, not by the integer, if I debugged the code correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
--- Comment #14 from hjl dot tools at gmail dot com 2010-02-21 18:00
---
That is true that the previous release didn't have proper excess
precision semantics. But from the user perspective, the previous
release handles
--
float f5(float x, int y)
{
return x * y;
}
--
correctly with -Wconversion -std=c99. For this particular testcase,
gcc 4.5 has a user visible regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- Comment #37 from gdr at integrable-solutions dot net 2010-02-21 18:04 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistent with gcc On Sun, Feb 21, 2010 at 7:04 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: Or suspend it. I think this warrants a defect report anyway since I think is_modulo was intended to describe CPU behavior as otherwise defining signed integer overflow as undefined in one piece of the standard and then requiring a sane answer for is_modulo in another part sounds like a conflict of interest. is_modulo is intended to describe the implementation's choice, not necessarily the CPU behaviour (which the implementation may choose to mask or not.) The issue here is that GCC does not always deliver the CPU behaviour, so it is more a problem with GCC than with the standard. Users who want to make incompatible assumptions about types in the same program deserve what they get. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug c++/42824] [4.5 regression] c++ compilation complains about error: call of overloaded
--- Comment #14 from dodji at gcc dot gnu dot org 2010-02-21 18:07 --- Subject: Bug 42824 Author: dodji Date: Sun Feb 21 18:06:39 2010 New Revision: 156939 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156939 Log: Fix PR c++/42824 gcc/cp/ChangeLog: PR c++/42824 * pt.c (lookup_template_class): Better support of specialization of member of class template implicit instantiation. gcc/testsuite/ChangeLog: PR c++/42824 * g++.dg/template/memclass4.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/memclass4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
--- Comment #15 from joseph at codesourcery dot com 2010-02-21 18:15 --- Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't work On Sun, 21 Feb 2010, manu at gcc dot gnu dot org wrote: Sorry I do not understand completely your answer. Shouldn't we warn at all? If the semantics were implemented as intended, should we warn? With the intended semantics, we should warn; there would be an actual conversion from integer to float there, that could change the value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- Comment #38 from veksler at il dot ibm dot com 2010-02-21 18:20 --- (In reply to comment #37) is_modulo is intended to describe the implementation's choice, not necessarily the CPU behaviour (which the implementation may choose to mask or not.) The issue here is that GCC does not always deliver the CPU behaviour, so it is more a problem with GCC than with the standard. Users who want to make incompatible assumptions about types in the same program deserve what they get. This is not that simple. libstdc++.so is out of user's control, libkde.so (or whatever its name is) is out of user's control. So if -fwrapv affects the definition of is_modulo then: If libstdc++.so is compiled without -fwrapv, then the user can't use -fwrapv without a potential ODR violation. What if libkde.so, which is supplied by a third party, was compiled with -fwrapv, while libsdc++.so was compiled by some sysadmin, accessible through NFS. They must be compiled with exactly the same flags, both out of user's control, otherwise they'll cause an ODR violation. Having is_modulo lie looks not as bad as it initially seemed. At least I have the option to ignore is_modulo altogether without going to the land of undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
--- Comment #16 from manu at gcc dot gnu dot org 2010-02-21 18:25 --- (In reply to comment #15) With the intended semantics, we should warn; there would be an actual conversion from integer to float there, that could change the value. Great. Any hints where could be the problem or fix? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work
--- Comment #17 from joseph at codesourcery dot com 2010-02-21 18:32 --- Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't work On Sun, 21 Feb 2010, manu at gcc dot gnu dot org wrote: --- Comment #16 from manu at gcc dot gnu dot org 2010-02-21 18:25 --- (In reply to comment #15) With the intended semantics, we should warn; there would be an actual conversion from integer to float there, that could change the value. Great. Any hints where could be the problem or fix? Where convert_and_check is called, for (a) conditional expressions and (b) binary operations, to convert two operands to a common type, the conversion is (correctly) to the type with excess precision (possibly long double where the semantic type is narrower, float or double). I would suggest having a c_ep_convert_and_check or similar function that handles excess precision: it would take the result type, the semantic result type (the type that gets used eventually to build an EXCESS_PRECISION_EXPR) and the value to convert. It would just call convert_and_check, ignoring the semantic type, *except* when the operand has integer type *and* the semantic type is non-NULL; in that case, it would first convert to the semantic type them to the result type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- Comment #39 from gdr at integrable-solutions dot net 2010-02-21 18:50 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistent with gcc On Sun, Feb 21, 2010 at 12:20 PM, veksler at il dot ibm dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #38 from veksler at il dot ibm dot com 2010-02-21 18:20 --- (In reply to comment #37) is_modulo is intended to describe the implementation's choice, not necessarily the CPU behaviour (which the implementation may choose to mask or not.) The issue here is that GCC does not always deliver the CPU behaviour, so it is more a problem with GCC than with the standard. Users who want to make incompatible assumptions about types in the same program deserve what they get. This is not that simple. libstdc++.so is out of user's control, libkde.so (or whatever its name is) is out of user's control. Agreed. So if -fwrapv affects the definition of is_modulo then: so the issue then is that you get two people who make incompatible assumptions about the same type for the same program. If that is case, I'm not sure what libstdc++ would have to do. After all, the resulting program is out of the control of libstdc++. If libstdc++.so is compiled without -fwrapv, then the user can't use -fwrapv without a potential ODR violation. agreed. What if libkde.so, which is supplied by a third party, was compiled with -fwrapv, while libsdc++.so was compiled by some sysadmin, accessible through NFS. agreed. They must be compiled with exactly the same flags, both out of user's control, otherwise they'll cause an ODR violation. Having is_modulo lie looks not as bad as it initially seemed. At least I have the option to ignore is_modulo altogether without going to the land of undefined behavior. my conclusion would be that is_modulo is not the right interface to test whether a component in the program was compiled with -fwrapv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug c++/17459] Spurious message when forgetting parentheses on call of member
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-21 19:07 ---
More weirdeness.
// PR c++/17459: Spurious message when forgetting parentheses on call of member
// { dg-do compile }
struct S {
void foo();
void bar() { foo; } // { dg-error statement cannot resolve address of
overloaded function }
// { dg-message note: taking the address of a member function requires the
syntax 'S::foo' { target *-*-* } 5 }
void bar3() { foo; } // { dg-error ISO C.. forbids taking the address }
void * bar2() { return foo; }
};
This testcase produces:
pr17459.C: In member function 'void S::bar()':
pr17459.C:5:19: error: statement cannot resolve address of overloaded function
pr17459.C:5:19: note: taking the address of a member function requires the
syntax 'S::foo'
pr17459.C: In member function 'void S::bar3()':
pr17459.C:7:18: error: ISO C++ forbids taking the address of an unqualified or
parenthesized non-static member function to form a pointer to member function.
Say 'S::f\
oo'
pr17459.C: In member function 'void* S::bar2()':
pr17459.C:8:26: error: argument of type 'void (S::)()' does not match 'void*'
The last one really kills me. It should be the same error as the first one,
isn't it?
Oh, I give up on this one!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17459
[Bug c++/18016] Warn about member variables initialized with itself
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-21 19:17 --- (In reply to comment #5) Is there any chance of activity on this bug? It would be wonderful to have a warning for this case, since these bugs can be extremely annoying to find. -Winit-self is generally broken for C++ (PR 34772). I am not sure what should be solved first. -- manu at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||34772 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18016
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #6 from dodji at gcc dot gnu dot org 2010-02-21 20:19 --- The resolution of PR c++/43036 seems related to array types only. So I don't understand why it fixes this PR. I'd like to investigate a bit further. The test case is too big for me to understand it so I am delta-reducing it and it's taking time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug c++/23510] skip some instantation contexts if there are too many
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-21 21:20 --- Subject: Bug 23510 Author: manu Date: Sun Feb 21 21:20:04 2010 New Revision: 156942 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156942 Log: 2010-02-21 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/23510 cp/ * error.c (print_instantiation_partial_context_line): New. (print_instantiation_partial_context): Print at most 12 contexts, skip the rest with a message. testsuite/ * g++.dg/template/recurse.C: Adjust. * g++.dg/template/pr23510.C: New. Added: trunk/gcc/testsuite/g++.dg/template/pr23510.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/recurse.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23510
[Bug c++/23510] skip some instantation contexts if there are too many
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-21 21:21 --- FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23510
[Bug c/42199] A problem with -maltivec
--- Comment #3 from galtgendo at o2 dot pl 2010-02-21 21:22 --- There's new input in a different Gentoo bug: http://bugs.gentoo.org/show_bug.cgi?id=305333 Apparently in certain conditions on ppc, bool is both defined and undefined. Unless you'll see that as bad code on openjpeg side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42199
[Bug target/33767] GLOBAL_ASM_OP needs to be documented in tm.texi
--- Comment #1 from davek at gcc dot gnu dot org 2010-02-21 22:27 --- just ran into this myself! -- davek at gcc dot gnu dot org changed: What|Removed |Added CC||davek at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-21 22:27:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33767
[Bug target/42994] Status of using both -m32 and -m64 on the same command line
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-21 23:21 --- So this is confirmed, yes? no? Joseph? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994
[Bug tree-optimization/43026] [4.5 Regression][graphite] ICE in sese.c with -fgraphite-identity in 447.dealII
--- Comment #6 from grosser at gcc dot gnu dot org 2010-02-22 00:42 --- I believe this commit introduced the bug: Remove COMPONENT_REF limitation in SCoP detection. 2010-01-08 Sebastian Pop sebastian@amd.com * graphite-scop-detection.c (exclude_component_ref): Removed. (is_simple_operand): Removed. (stmt_simple_for_scop_p): Remove use of is_simple_operand. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/graph...@155738 We allow SCoPs that we cannot handle in the backend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43026
[Bug libstdc++/21321] [4.3/4.4/4.5 regression] mmix-knuth-mmixware 27_io/basic_filebuf/seekpos/12790-3.cc execution test
--- Comment #17 from hp at gcc dot gnu dot org 2010-02-22 01:31 --- (In reply to comment #13) Is this still an issue? To be honest I have no idea if this target is still in good shape or not... Not that this PR is dependent on the shape of the port, but at r156927 it was in unexpectedly good shape, save for the libgcc build issue at http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00856.html (fixed at r156948). Testing has not completed, so the gcc-testresults@ post will have to wait until tomorrow, but testing has progressed far enough for me to see that the issue persists as reported with insignificant differences (one or so less FAIL, source line changed by one). -- hp at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-10-24 00:04:39 |2010-02-22 01:31:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321
[Bug c++/43135] New: Possible bug in name resolution during template instantiation
I'm reporting this against my system compiler (4.1.2 on NetBSD/macppc), but I
can reproduce it using all versions from 3.4 (when two-stage name lookup was
introduced) to 4.4 - which I was able to test on a linux/amd64 machine with a
large collection of compilers installed.
The following code (minimized test case) is rejected with
$ g++ -S bug_p.cpp
bug_p.cpp: In member function 'bool Node::FooOpNode_Op::f() [with _Op = X]':
bug_p.cpp:63: instantiated from here
bug_p.cpp:54: error: cannot call member function 'bool Node::test(int)' without
object
If offending call to test is qualified as Node::test, compiler accepts it
happily.
Yes, I read http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html#Name-lookup
88
struct X {
int i;
};
class Node {
public:
template typename _Op class OpNode;
template typename _Op class FooOpNode;
class FooNode;
Node() {}
virtual ~Node() {}
bool test(int i) { return true; }
virtual bool f() { return true; }
};
template typename _Op
class Node::OpNode
: public Node
{
public:
typedef OpNode_Op OpNodeBase;
_Op op;
OpNode(_Op op) : Node(), op(op) {}
// test call ok here
virtual bool f() { return !test(op.i); }
};
template typename _Op
class Node::FooOpNode
: public OpNode_Op
{
public:
typedef OpNode_Op OpNodeBase;
using OpNodeBase::op;
typedef FooOpNode_Op FooOpNodeBase;
FooOpNode(_Op op) : OpNodeBase(op) {}
// test call marked as error here
// unless qualified as Node::test()
virtual bool f() {
return
// Node::
test(op.i);
}
};
class Node::FooNode
: public FooOpNodeX
{
public:
FooNode(X x) : FooOpNodeBase(x) {}
};
88
--
Summary: Possible bug in name resolution during template
instantiation
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: powerpc--netbsd
GCC host triplet: powerpc--netbsd
GCC target triplet: powerpc--netbsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #1 from uwe at netbsd dot org 2010-02-22 02:51 --- Created an attachment (id=19932) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19932action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #2 from bangerth at gmail dot com 2010-02-22 03:56 --- This is not a bug. Because the base class of Node::OpNode does not depend on template arguments, the members of the base class are visible in Node::OpNode::f(). On the other hand, since the base class of Node::FooOpNode depends on template arguments, the members of the base class are not visible during parsing and before template arguments are substituted. You need to write the call to test as this-test(op.i) W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #3 from uwe at netbsd dot org 2010-02-22 04:08 --- (In reply to comment #2) This is not a bug. Because the base class of Node::OpNode does not depend on template arguments, the members of the base class are visible in Node::OpNode::f(). On the other hand, since the base class of Node::FooOpNode depends on template arguments, the members of the base class are not visible during parsing and before template arguments are substituted. But doesn't this error happens during instantiation as the error message indicates? If definition of Node::FooNode is commented out, the templates themselves are accepted. Also, if the nested classes are un-nested out of Node, the code compiles w/out errors too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #4 from bangerth at gmail dot com 2010-02-22 04:29 ---
(In reply to comment #3)
But doesn't this error happens during instantiation as the error message
indicates? If definition of Node::FooNode is commented out, the templates
themselves are accepted.
What I meant to say is this: during parsing, it doesn't see Node::test as
a member of the base class, but it sees it as a member of the enclosing
class in the same way as S::I::f() in
struct S {
int i;
struct I {
int f() { return i; }
};
}
would see S::i -- since they are both members of the same enclosing class S.
I.e., Node::FooOpNode::f() sees Node::test() as a sibling, not a member
of the base class, and so the call is registered as a function call, not
a call of a member function with this as argument.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #5 from uwe at netbsd dot org 2010-02-22 04:45 --- (In reply to comment #4) What I meant to say is this: during parsing ... So do I get this right (knowing nothing about g++ internals) that in the first phase (during parsing) the call to test is resolved to sibling because it's a dependent name with a declaration in-scope. Then during instantiation time that sibling call is flagged as invalid? What confuses me is that explictly qualifying the offending call as Node::test(op.i) makes it compile correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug c++/43135] Possible bug in name resolution during template instantiation
--- Comment #6 from uwe at netbsd dot org 2010-02-22 04:47 --- (In reply to comment #5) What confuses me is that explictly qualifying the offending call as Node::test(op.i) makes it compile correctly. I mean as far as I understand Node::test should resolve to the same sibling, so your explanation of why the original fails should still be applicable. Yet it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135
[Bug fortran/43072] unneeded temporary (s=s+f(a))
--- Comment #7 from pault at gcc dot gnu dot org 2010-02-22 05:44 --- Subject: Bug 43072 Author: pault Date: Mon Feb 22 05:43:57 2010 New Revision: 156949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156949 Log: 2010-02-22 Paul Thomas pa...@gcc.gnu.org PR fortran/43072 * dependency.c (gfc_full_array_ref_p): Check for contiguous by checking the rest of the dimensions for elements. 2010-02-22 Paul Thomas pa...@gcc.gnu.org PR fortran/43072 * gfortran.dg/internal_pack_6.f90: Number of 'packs' now zero. * gfortran.dg/internal_pack_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/internal_pack_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/internal_pack_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43072
[Bug fortran/41113] spurious _gfortran_internal_pack
--- Comment #25 from pault at gcc dot gnu dot org 2010-02-22 05:45 --- Fixed on trunk. Thanks for reportimg the problems and all the help, Tobias and Joost. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
[Bug fortran/41117] spurious _gfortran_internal_pack (II)
--- Comment #5 from pault at gcc dot gnu dot org 2010-02-22 05:45 --- Fixed on trunk. Thanks for reportimg the problems and all the help, Tobias and Joost. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41117
[Bug fortran/38112] unneeded temporary
--- Comment #3 from pault at gcc dot gnu dot org 2010-02-22 05:48 --- Fixed on trunk. Thanks for reportimg the problem, Joost. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112
[Bug fortran/43136] New: Excess copy-in/copy-out with character argument
After fixing, 43072 and friends, one excess copy-in and copy-out remains, where a substring describes the declared string length. The testcase is in internal_pack_9.f90: subroutine foo2 implicit none external foo character(len=20) :: str(2) = '1234567890' call foo(str(:)(1:20)) ! This is still not fixed. end Paul -- Summary: Excess copy-in/copy-out with character argument Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43136
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Comment #39 from amylaar at gcc dot gnu dot org 2010-02-22 06:04 --- (In reply to comment #38) Maybe this issue migrated into PR31849? Not entirely, PR31849 is tree-optimization, and a lot of auto-increment opportunities are only visible at the rtl level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug libstdc++/21321] [4.3/4.4/4.5 regression] mmix-knuth-mmixware 27_io/basic_filebuf/seekpos/12790-3.cc execution test
--- Comment #18 from hp at gcc dot gnu dot org 2010-02-22 07:05 --- Results at http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02083.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321
