[Bug c++/57000] [4.8/4.9 Regression] ICE with -Ofast and -frounding-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57000 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.1 Summary|4.8 Regression?, ICE with |[4.8/4.9 Regression] ICE |-Ofast and -frounding-math |with -Ofast and ||-frounding-math
[Bug c++/57000] [4.8/4.9 Regression] ICE with -Ofast and -frounding-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57000 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-19 07:29:35 UTC --- Created attachment 29901 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29901 pr57000.ii Somewhat reduced testcase (but sitll quite large).
[Bug testsuite/53222] dejagnu trims leading whitespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53222 --- Comment #1 from Shakthi Kannan skannan at redhat dot com 2013-04-19 07:29:43 UTC --- Created attachment 29902 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29902 namespace error after applying patch Can you please provide the version of GCC that you used? I built GCC-4.8.0 (x86_64) after applying the patch and I get the attached errors.
[Bug c++/57000] [4.8/4.9 Regression] ICE with -Ofast and -frounding-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57000 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-19 07:44:54 UTC --- reassoc clearly doesn't adjust the virtual ops, not sure if just on the pow* handling, or everywhere, it expects the math builtin calls to have no vops. As the vops are missing just with -ffast-math, guess this is just about the flag_unsafe_math_operations guarded code, i.e. pow and powi handling. So, either we should give up also if the builtin pow/powi etc. has vops, or request updating of vops if we see any pow* with vops and modify it, or update it ourselves.
[Bug testsuite/53222] dejagnu trims leading whitespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53222 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Severity|normal |trivial --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-19 07:51:14 UTC --- Did you run with -fdiagnostics-show-caret enabled? At the end, it was decided to disable it for the testsuite, so this report is not very important anymore. It would be nice if DejaGNU didn't alter the output, but right now, it doesn't affect us.
[Bug c++/57000] [4.8/4.9 Regression] ICE with -Ofast and -frounding-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57000
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-19
08:03:34 UTC ---
Shorter testcase:
/* PR tree-optimization/57000 */
/* { dg-do compile } */
/* { dg-options -Ofast -frounding-math } */
double baz (double foo, double bar)
{
return foo * foo * foo * foo * bar * bar * bar * bar;
}
[Bug target/56975] [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2013-04-19 08:18:13 UTC --- At what place it freezes? Can you provide a testcase? Are you sure it is really related to the patch? What makes you think that? All in all, what I mean about those questions is that it isn't helpful to tell such statements without even trying to narrow it down to its reason.
[Bug rtl-optimization/56999] [4.8 Regression] LRA caused miscompilation of xulrunner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56999 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-19 08:19:16 UTC --- Author: mpolacek Date: Fri Apr 19 08:18:29 2013 New Revision: 198085 URL: http://gcc.gnu.org/viewcvs?rev=198085root=gccview=rev Log: Backport from mainline 2013-01-08 Steven Bosscher ste...@gcc.gnu.org Jakub Jelinek ja...@redhat.com PR tree-optimization/48189 * predict.c (predict_loops): If max is 0, don't call compare_tree_int. If nitercst is 0, don't predict the exit edge. * gcc.dg/pr48189.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr48189.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/predict.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/56999] [4.8 Regression] LRA caused miscompilation of xulrunner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56999 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-19 08:19:50 UTC --- Damn, wrong PR, sorry.
[Bug tree-optimization/48189] [4.7 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48189 --- Comment #14 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-19 08:20:11 UTC --- Author: mpolacek Date: Fri Apr 19 08:18:29 2013 New Revision: 198085 URL: http://gcc.gnu.org/viewcvs?rev=198085root=gccview=rev Log: Backport from mainline 2013-01-08 Steven Bosscher ste...@gcc.gnu.org Jakub Jelinek ja...@redhat.com PR tree-optimization/48189 * predict.c (predict_loops): If max is 0, don't call compare_tree_int. If nitercst is 0, don't predict the exit edge. * gcc.dg/pr48189.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr48189.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/predict.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/48189] [4.7 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48189 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-19 08:20:34 UTC --- Fixed.
[Bug middle-end/57003] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-04-19 Ever Confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-04-19 08:26:30 UTC --- To narrow down the problem more you can cherry-pick d73df2920c77116fd88e03cd95dd352f16511a3f to after the commit that broke build and continue bi-secting?
[Bug c++/56998] [4.8 Regression] ICE in value_dependent_expression_p, at cp/pt.c:19598
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56998 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.7.3, 4.9.0 Keywords||ice-on-valid-code Last reconfirmed||2013-04-19 Ever Confirmed|0 |1 Summary|[4.8.0] ICE in |[4.8 Regression] ICE in |value_dependent_expression_ |value_dependent_expression_ |p, at cp/pt.c:19598 |p, at cp/pt.c:19598 Target Milestone|--- |4.8.1 Known to fail||4.8.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-04-19 08:29:54 UTC --- Confirmed.
[Bug c++/57000] [4.8/4.9 Regression] ICE with -Ofast and -frounding-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57000 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-04-19 08:30:19 UTC --- Mine.
[Bug c++/56963] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56963 --- Comment #3 from Václav Zeman vhaisman at gmail dot com 2013-04-19 08:54:59 UTC --- I have broken the file on the Google Drive. Here is another copy of the same: https://docs.google.com/file/d/0B-WkLJEfYmSEdTZvdFVRR0E0dEE/edit?usp=sharing
[Bug middle-end/56988] ipa-cp incorrectly propagates a field of an aggregate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56988 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-04/msg01120.htm ||l --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2013-04-19 09:09:26 UTC --- Richi was right. The proper fix is to not ignore by_ref. I have already posted a patch to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01120.html
[Bug target/56944] Better isfinite in some cases?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56944
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
Attachment #29900|0 |1
is obsolete||
--- Comment #4 from Marc Glisse glisse at gcc dot gnu.org 2013-04-19 09:53:42
UTC ---
Created attachment 29903
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29903
(x inf) inf
Slightly improved version of the patch, but there are still issues. Attaching a
log of an IRC discussion, so I don't forget all the nice advice:
marcgHello. I added an optab for __builtin_finite and an expander for x86,
and it seems to work. To avoid hurting the vectorizer, I also did a vector
version, and a builtin and told ix86_builtin_vectorized_function about it, and
it works for float.
marcgFor double, finite takes a double and returns an int, so the
vectorizer tries to find a vector version that takes a V2DF and returns a V4SI,
whereas I added a version that returns V2DI.
richimake sure to also add constant folding
marcg(good point about constant folding, thanks)
marcgHow is the vectorization supposed to work in that case? Should the
vectorizer try V2DI as well?
richiit's not that easy. I think the target should provide a V2SI variant
instead. But of course the vectorizer will ask for V4SI here, so it won't work
either.
richithe vectorizer simply cannot handle this at the moment (multiple types
and calls, in vectorizer speak)
richiit would need to go through vectorizable_conversion-like code
marcgA V2SI variant would be ugly, mixing vector sizes hurts.
richispecial-casing the FP classification builtins
marcgOk, I guess I should avoid adding this special 'finite' implementation
then
richiyou can hande it in vectorizer pattern matching, vectorizing it as it
was before
marcgAh, indeed, I could have a look (though it is only papering over
something, and it is becoming complicated for such a small optimization).
Thanks for the explanations.
richiyes, it would be a hack
jakubmarcg: perhaps pattern recognition for that?
marcgI think pattern recognition in the vectorizer is the hack richi was
talking about? Or do you mean something else?
jakubmarcg: if you find the target has V{2,4}DF - V{2,4}DI finite builtin,
and code uses DF-SI, then rewrite the __builtin_finite call as
__builtin_finitedfdi casted to (int), and the vectorizer will handle the cast
richiof course you then need such a builtin
richialternatively you can teach this to call vectorization
richithat is, look for a vectorized call that preserves the number of
vector elements
richiand do the appropriate widening/shortening
[Bug web/55933] Missing attachment download link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55933 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2013-04-19 Resolution|WORKSFORME | Ever Confirmed|0 |1 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2013-04-19 09:55:38 UTC --- There is no such link in the comment.
[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org 2013-04-19 10:03:55 UTC --- Author: mikael Date: Fri Apr 19 09:58:41 2013 New Revision: 198086 URL: http://gcc.gnu.org/viewcvs?rev=198086root=gccview=rev Log: 2013-04-19 Thomas Koenig tkoe...@gcc.gnu.org Mikael Morin mik...@gcc.gnu.org PR fortran/56872 * frontend-passes.c (copy_walk_reduction_arg): Change argument type to gfc_constructor. If it has an iterator, wrap the copy of its expression in an array constructor with that iterator. Don't special case function expressions. (callback_reduction): Update caller. Don't return early if there is an iterator. 2013-04-19 Thomas Koenig tkoe...@gcc.gnu.org Mikael Morin mik...@gcc.gnu.org PR fortran/56872 * gfortran.dg/array_constructor_45.f90: New test. * gfortran.dg/array_constructor_46.f90: New test. * gfortran.dg/array_constructor_47.f90: New test. * gfortran.dg/array_constructor_40.f90: Adjust number of while loops. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_45.f90 trunk/gcc/testsuite/gfortran.dg/array_constructor_46.f90 trunk/gcc/testsuite/gfortran.dg/array_constructor_47.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/array_constructor_40.f90
[Bug tree-optimization/57000] [4.8 Regression] ICE with -Ofast and -frounding-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57000 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c++ |tree-optimization Known to work||4.7.3, 4.9.0 Summary|[4.8/4.9 Regression] ICE|[4.8 Regression] ICE with |with -Ofast and |-Ofast and -frounding-math |-frounding-math | Known to fail||4.8.0 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-04-19 10:16:09 UTC --- Author: rguenth Date: Fri Apr 19 10:15:15 2013 New Revision: 198087 URL: http://gcc.gnu.org/viewcvs?rev=198087root=gccview=rev Log: 2013-04-19 Richard Biener rguent...@suse.de PR tree-optimization/57000 * tree-ssa-reassoc.c (pass_reassoc): Add TODO_update_ssa_only_virtuals. * gcc.dg/tree-ssa/reassoc-27.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-27.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug rtl-optimization/38026] Miscompilation for CRIS of gfortran.dg/char_result_5.f95 with -fno-gcse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38026 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.3.6 --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2013-04-19 10:18:32 UTC --- (In reply to comment #3) (In reply to comment #2) Sure, it's fill_eager_delay_slots that moved the insn, but it's only acting on a stray REG_DEAD note left over from cprop_hardreg. This is probably fixed by http://gcc.gnu.org/r164458 That might be so, but I can't verify that. :( Unfortunately I forgot to note the exact svn revision at which the test failed, and reverting the 174133 revision (backport to 4.3 documented in PR42775) from revision 175148 and following the to-repeat description does not expose the bug. Hm, I see I mentioned 4.3.3 in this quite old report but as I can't repeat it with a revision near ToT, I believe it's time to retire this PR and close it as WORKSFORME rather than WONTFIX.
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-04/msg01127.htm ||l --- Comment #7 from Janne Blomqvist jb at gcc dot gnu.org 2013-04-19 10:34:20 UTC --- Patch implementing the unbuffered really means buffered but flush after every write idea: http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01127.html
[Bug c/57004] New: False warning: comparison is always true due to limited range of data type [-Wtype-limits]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57004
Bug #: 57004
Summary: False warning: comparison is always true due to
limited range of data type [-Wtype-limits]
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: slava.garbu...@gmail.com
Reproduced with cross linaro-gcc 4.6.3 and FSF 4.7.2 for ARM.
Cannot be reproduced with native GCC 4.6.3 on x86
$ cat test.c
int main() {
char a = 'a';
return (a = 0);
}
$
$ arm-none-linux-gnueabi-gcc test.c -Wextra
test.c: In function 'main':
test.c:3:3: warning: comparison is always true due to limited range of data
type [-Wtype-limits]
$
[Bug other/55793] Compile hog with -gdwarf-4 and -O2 (-fvar-tracking issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55793 --- Comment #3 from Jan Smets jan.sm...@alcatel-lucent.com 2013-04-19 11:57:36 UTC --- Can't confirm since the patch can not be applied to 4.6. (Even though the branch is dead already..)
[Bug tree-optimization/56718] Early inlining prevents type based devirtualization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56718 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org 2013-04-19 12:04:45 UTC --- Author: jamborm Date: Fri Apr 19 12:00:27 2013 New Revision: 198088 URL: http://gcc.gnu.org/viewcvs?rev=198088root=gccview=rev Log: 2013-04-19 Martin Jambor mjam...@suse.cz PR tree-optimization/56718 * ipa-cp.c (ipa_value_from_known_type_jfunc): Moved... * ipa-prop.c (ipa_binfo_from_known_type_jfunc): ...here, renamed and made public. Adjusted all callers. (ipa_intraprocedural_devirtualization): New function. * ipa-prop.h (ipa_binfo_from_known_type_jfunc): Declare. (ipa_intraprocedural_devirtualization): Likewise. * Makefile.in (tree-ssa-pre.o): Add ipa-prop.h to dependencies. testsuite/ * g++.dg/ipa/imm-devirt-1.C: New test. * g++.dg/ipa/imm-devirt-2.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/ipa/imm-devirt-1.C trunk/gcc/testsuite/g++.dg/ipa/imm-devirt-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ipa-cp.c trunk/gcc/ipa-prop.c trunk/gcc/ipa-prop.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug c/57004] False warning: comparison is always true due to limited range of data type [-Wtype-limits]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57004 Dinar Temirbulatov dtemirbulatov at gmail dot com changed: What|Removed |Added CC||dtemirbulatov at gmail dot ||com --- Comment #1 from Dinar Temirbulatov dtemirbulatov at gmail dot com 2013-04-19 12:04:52 UTC --- reproduced this error on trunk with --with-interwork --with-mode=arm --with-fpu=vfpv3 --with-cpu=cortex-a15 --with-tune=cortex-a15 configuration.
[Bug c/57004] False warning: comparison is always true due to limited range of data type [-Wtype-limits]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57004 Julian Taylor jtaylor.debian at gmail dot com changed: What|Removed |Added CC||jtaylor.debian at gmail dot ||com --- Comment #2 from Julian Taylor jtaylor.debian at gmail dot com 2013-04-19 12:41:28 UTC --- you need to use -fsigned-char if your program expects signed chars on a machine which defaults to unsigned chars (like ARM).
[Bug tree-optimization/56982] [4.8 Regression] Bad optimization with setjmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.8/4.9 Regression] Bad|[4.8 Regression] Bad |optimization with setjmp() |optimization with setjmp() --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-04-19 13:40:05 UTC --- Author: rguenth Date: Fri Apr 19 13:39:16 2013 New Revision: 198096 URL: http://gcc.gnu.org/viewcvs?rev=198096root=gccview=rev Log: 2013-04-19 Richard Biener rguent...@suse.de PR tree-optimization/56982 * builtins.def (BUILT_IN_LONGJMP): longjmp is not a leaf function. * gimplify.c (gimplify_call_expr): Notice special calls. (gimplify_modify_expr): Likewise. * tree-cfg.c (make_abnormal_goto_edges): Handle setjmp-like abnormal control flow receivers. (call_can_make_abnormal_goto): Handle cfun-calls_setjmp in the same way as cfun-has_nonlocal_labels. (gimple_purge_dead_abnormal_call_edges): Likewise. (stmt_starts_bb_p): Make setjmp-like abnormal control flow receivers start a basic-block. * gcc.c-torture/execute/pr56982.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr56982.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.def trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug target/56944] Better isfinite in some cases?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56944 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-19 13:43:18 UTC --- For the vectorization, vectorizable_call should handle DF - SI builtin vectorization, see e.g. how on i?86/x86_64 BUILT_IN_IFLOOR is vectorized.
[Bug c++/57005] New: alias template's pseudo-destructor is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57005
Bug #: 57005
Summary: alias template's pseudo-destructor is rejected
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: omawarisan.bokud...@live.jp
g++ -std=c++11 does not allow the following pseudo-destructor call.
template class T
using type = T;
int main()
{
typeint().~typeint();
}
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/user/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/user/gcc-trunk
--disable-bootstrap --disable-multilib --enable-languages=c,c++,fortran
--with-gmp=/home/user/gcc-trunk/src/build/backends
--with-mpfr=/home/user/gcc-trunk/src/build/backends
--with-mpc=/home/user/gcc-trunk/src/build/backends
Thread model: posix
gcc version 4.9.0 20130419 (experimental) (GCC)
[Bug target/56975] [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 --- Comment #8 from gee jojelino at gmail dot com 2013-04-19 14:26:15 UTC --- Created attachment 29904 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29904 Patch for supporting cygwin32's SYSV_ABI proper - Fixed a hunk fail (In reply to comment #7) At what place it freezes? Can you provide a testcase? Are you sure it is really related to the patch? What makes you think that? All in all, what I mean about those questions is that it isn't helpful to tell such statements without even trying to narrow it down to its reason. The attachment 29898 fixed the problem. there is a hunk failure so I uploaded another attachment that workarounds the failure. Thanks!
[Bug target/56944] Better isfinite in some cases?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56944 --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org 2013-04-19 15:11:58 UTC --- (In reply to comment #5) For the vectorization, vectorizable_call should handle DF - SI builtin vectorization, see e.g. how on i?86/x86_64 BUILT_IN_IFLOOR is vectorized. I may try that. For cases where the result of __builtin_finite (really a bool) is immediately used in a condition, that's going to be a waste compared to pretending it returns a DI. However, detecting situations where we have a long l and we use (int) l in an expression where we can remove the cast to int, and making the necessary adjustments seems hard. Maybe restricting to the case where the result is used once, as the first argument of a cond_expr where the other arguments have a wider type would be doable... Another thing worth trying would be to do this new __builtin_finite expansion in the middle-end (same place as currently), and implement whatever is necessary so that the back-end generates the right code from it. Even after the patch for PR 54716, we are still not very good at turning integer logic operations into float logic operations.
[Bug debug/57006] New: extend DWARF to indicate types coming from template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57006
Bug #: 57006
Summary: extend DWARF to indicate types coming from template
parameters
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tro...@gcc.gnu.org
Consider this source:
templatetypename T
struct Q
{
T field1;
int field2;
};
Qint q;
If I compile it I see DWARF like this for the fields:
229: Abbrev Number: 3 (DW_TAG_member)
2a DW_AT_name: (indirect string, offset: 0x0): field1
2e DW_AT_decl_file : 1
2f DW_AT_decl_line : 4
30 DW_AT_type: 0x49
34 DW_AT_data_member_location: 0
235: Abbrev Number: 3 (DW_TAG_member)
36 DW_AT_name: (indirect string, offset: 0x7): field2
3a DW_AT_decl_file : 1
3b DW_AT_decl_line : 5
3c DW_AT_type: 0x49
40 DW_AT_data_member_location: 4
That is, they have the same type.
It would be nice if there were a way to differentiate these two types.
This would make type pretty-printing in gdb give better output.
(It isn't important in a trivial case like this, but I think it is
more important in complicated real-world code.)
One idea I had was to have the DW_AT_type of field1 point to the
DW_TAG_template_type_param field. This would be a small extension to
DWARF, not requiring any new tags or attributes.
[Bug c++/53822] Diagnostic: spell out type in ambiguous call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-19 15:27:28 UTC --- Makes sense to me and must be pretty easy to implement.
[Bug c/53924] unhelpful diagnostic in invalid declaration list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53924 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-19 Ever Confirmed|0 |1 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-19 16:15:18 UTC --- I think this is confirmed, but there doesn't seem to be much activity in the C FE anymore. The C++ parser is still not as good as Clang: test.c:2:18: error: expected initializer before ‘cdecl’ tree klass, tree cdecl, class_array_type; ^
[Bug c++/54311] Info about default template arguments in instantiation backtrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54311 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-19 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-19 16:21:54 UTC --- That would be an improvement yes. This is what Clang++ gives: test.cc:6:39: error: no type named 'type' in 'Aint' typename U = typename AT::type ~~~^~~~ test.cc:11:3: note: in instantiation of default argument for 'Bint' required here Bint b; ^~ which seems to me even better than what you propose.
[Bug c++/54377] Consider default arguments in wrong number of template arguments diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54377
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-04-19
CC||manu at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-19
16:32:56 UTC ---
Or say:
test.cpp: In function 'int main()':
test.cpp:6:12: error: wrong number of template arguments (1, should be at least
2)
fooint f;
^
test.cpp:2:8: note: provided for 'templateclass, class, class=void,
class=void struct foo'
struct foo {};
^
that is, make the second message a note, mention the minimum, fix the location
to point to foo, show the default arguments in the declaration.
I would guess that counting how many are non-default is easier, but someone
will have to provide a patch.
[Bug c++/54948] template unnecessarily displayed as A template-parameter-1-1 not AT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54948 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-19 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-19 16:39:45 UTC --- I think there are other bugs about printing template-parameter-1-1. I don't see why the pretty-printer may ever need to print such a thing.
[Bug c++/56289] Bad location for unused value warning with comma operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56289 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-19 CC||manu at gcc dot gnu.org Summary|Bad unused value warning|Bad location for unused |with comma operator |value warning with comma ||operator Ever Confirmed|0 |1 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-19 16:49:44 UTC --- The location could be better but it is pretty close for C++: test.c:4:14: warning: right operand of comma operator has no effect [-Wunused-value] (void) x, y; /* warning: right operand of comma operator has no effect ^ But the C FE is pretty awful: test.c:4:3: warning: statement with no effect [-Wunused-value] (void) x, y; /* warning: right operand of comma operator has no effect ^ Clang: test.c:4:13: warning: expression result unused [-Wunused-value] (void) x, y; /* warning: right operand of comma operator has no effect ^
[Bug c/57004] False warning: comparison is always true due to limited range of data type [-Wtype-limits]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57004 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2013-04-19 16:49:59 UTC --- Arm's EABI says char defaults to unsigned. This is different from x86's ABI Note ARM-linux defaults to signed though.
[Bug c++/11582] Odd error message with dynamically sized template arg printing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11582 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-19 17:13:38 UTC --- The '[(((sizetype)anonymous) + 1)]' is just awful. If we don't know the actual type there, that is int [size()], then we should just print 'int []' or 'int [size_t]' or something similar to denote a VLA. Surprisingly, Clang++ is even more confused: test.cc:6:3: error: no matching function for call to 'f' f( buf ) ; ^ test.cc:2:28: note: candidate template ignored: could not match 'int' against 'int' template int N void f(int ()[N]); ^ test.cc:13:3: error: no matching function for call to 'f' f( buf ) ; ^ test.cc:2:28: note: candidate template ignored: could not match 'int' against 'int' template int N void f(int ()[N]); ^
[Bug target/56412] [4.8] libtool: cygpath: command not found for mingw32 host
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56412 --- Comment #5 from nightstrike nightstrike at gmail dot com 2013-04-19 17:46:37 UTC --- CYGPATH_W gets set correctly, but libtool seems to ignore it.
[Bug target/56975] [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 --- Comment #9 from Dave Korn davek at gcc dot gnu.org 2013-04-19 18:18:19 UTC --- Kai's patch applied cleanly for me vs. Revision: 197992 and allowed my failed build to proceed as far as stage 3 where it failed on libjava (known issue). I'm going to rerun the build from clean and try some tests.
[Bug target/57009] New: Select best typed instruction for scalar bitwise operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57009
Bug #: 57009
Summary: Select best typed instruction for scalar bitwise
operations
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
Hello,
I purposedly took almost the same title as PR 54716, because this is the same
issue, but for scalars. Consider this code:
union A { double d; unsigned long long i; };
bool f(double a, double b, double c){
A x, y, z;
x.d = a * a;
y.d = b * b;
z.i = x.i y.i;
return z.d c;
}
which compiles to:
mulsd%xmm0, %xmm0
mulsd%xmm1, %xmm1
movq%xmm0, %rax
movq%xmm1, %rdx
andq%rdx, %rax
movq%rax, %xmm0
ucomisd%xmm0, %xmm2
seta%al
when using andpd would save 3 movq. Note that for vectors, we get nicer code
thanks to Jakub's patch:
mulpd%xmm1, %xmm1
mulpd%xmm0, %xmm0
andpd%xmm1, %xmm0
cmpltpd%xmm2, %xmm0
It would be nice to extend that code to scalars (including the case where one
of the arguments is a constant).
I hit this while experimenting for PR 56944.
[Bug fortran/45424] F2008: Add is_contiguous intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424 Sean Santos quantheory at gmail dot com changed: What|Removed |Added CC||quantheory at gmail dot com --- Comment #3 from Sean Santos quantheory at gmail dot com 2013-04-19 21:12:06 UTC --- A naive interpretation of the standard suggests that in the case a), is_contiguous should return .true., because the standard doesn't say anything about strides here, only about the ordering of the elements. (Of course strides matter for simply contiguous things, but that's different.) Case b) seems to be the same. In case f), since scalars can be associated with assumed-rank entities that have the contiguous attribute, it wouldn't make much sense to return .false. in this case.
[Bug libstdc++/57010] New: priority_queue calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57010
Bug #: 57010
Summary: priority_queue calls self-move-assignment operator
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: phil...@fb.com
#include iostream
#include queue
struct A {
A() { }
A(const A) = default;
A operator=(const A) = default;
A(A) = default;
A operator=(A a) {
if (this == a) {
std::cerr ?! std::endl;
}
return *this;
}
bool operator(const A) const {
return false;
}
};
int main() {
std::priority_queueA q;
q.push(A());
q.pop(); // prints '?!'
return 0;
}
std::priority_queue calls self-move-assignment when pop() the last element.
Verified in gcc-4.6.2 and gcc-4.7.1.
[Bug c++/57011] New: Compiling _GLIBCXX_CONCEPT_CHECKS rejects vectorunique_ptrfoo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57011
Bug #: 57011
Summary: Compiling _GLIBCXX_CONCEPT_CHECKS rejects
vectorunique_ptrfoo
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h.ch...@suremail.info
I read about _GLIBCXX_CONCEPT_CHECKS on
http://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_compile_checks.html
(it mentions that the upcoming C++ standard contains concepts, which did not
happen with C++11, so it is probably wrong) and tried to test it with test.cc:
#include memory
#include vector
int main() { std::vectorstd::unique_ptrint F; }
Compiled with `g++ -std=c++11 -D_GLIBCXX_CONCEPT_CHECKS test.cc` it fails,
though. :-(
[Bug rtl-optimization/38026] Miscompilation for CRIS of gfortran.dg/char_result_5.f95 with -fno-gcse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38026 --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2013-04-20 01:54:59 UTC --- (In reply to comment #4) I can't repeat it with a revision near ToT, I tested using r175148 on the 4.3-branch, in case it was unclear.
[Bug target/56263] [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.8.1 |4.8.0 --- Comment #10 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-04-20 05:10:59 UTC --- Done, see -Waddr-space-convert.
