[Bug target/57847] Compile ARM linux kernel with configuration of SLUB allocator, kernel failed to boot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57847 --- Comment #3 from Mikael Pettersson --- There was a known problem in the Linux kernel on ARM with gcc-4.7+ due to one of the mem* procedures (likely memset or memcpy) being written in such a way that its return value didn't follow normal specs, but gcc-4.7+ optimizes based on those specs, so the kernel broke. This is supposed to have been fixed sometime in the Linux 3.x series.
[Bug driver/57784] GCC inadvertedly truncates source text
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57784 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #3 from Joost VandeVondele --- (In reply to Marc Glisse from comment #2) > Uh, what's wrong about using a heuristic and refusing to compile when the > name of the output file ends in .c, .C, .cc, .f90, etc (possibly unless some > -fweird-output-name is also passed) and the file already exists? I would also be strongly in favor of such a simple heuristic... it is really a common error that has bitten more than one user, including myself.
[Bug rtl-optimization/57829] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57829 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Jul 8 08:11:08 2013 New Revision: 200768 URL: http://gcc.gnu.org/viewcvs?rev=200768&root=gcc&view=rev Log: PR rtl-optimization/57829 * simplify-rtx.c (simplify_binary_operation_1) : Ensure that mask bits outside of mode are just sign-extension from mode to HWI. * gcc.c-torture/execute/pr57829.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57829.c Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog Author: jakub Date: Mon Jul 8 08:15:01 2013 New Revision: 200770 URL: http://gcc.gnu.org/viewcvs?rev=200770&root=gcc&view=rev Log: PR rtl-optimization/57829 * simplify-rtx.c (simplify_binary_operation_1) : Ensure that mask bits outside of mode are just sign-extension from mode to HWI. * gcc.c-torture/execute/pr57829.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57829.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/simplify-rtx.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog Author: jakub Date: Mon Jul 8 08:17:35 2013 New Revision: 200773 URL: http://gcc.gnu.org/viewcvs?rev=200773&root=gcc&view=rev Log: PR rtl-optimization/57829 * simplify-rtx.c (simplify_binary_operation_1) : Ensure that mask bits outside of mode are just sign-extension from mode to HWI. * gcc.c-torture/execute/pr57829.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/pr57829.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/simplify-rtx.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/57786] wasted work in distribute_notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57786 Eric Botcazou changed: What|Removed |Added Component|middle-end |rtl-optimization Summary|Wasted work in |wasted work in |distribute_notes() |distribute_notes --- Comment #3 from Eric Botcazou --- Recategorizing.
[Bug target/57819] Suboptimal shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57819 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Jul 8 08:48:40 2013 New Revision: 200775 URL: http://gcc.gnu.org/viewcvs?rev=200775&root=gcc&view=rev Log: PR target/57819 * simplify-rtx.c (simplify_unary_operation_1) : Simplify (zero_extend:SI (subreg:QI (and:SI (reg:SI) (const_int 63)) 0)). * combine.c (make_extraction): Create ZERO_EXTEND or SIGN_EXTEND using simplify_gen_unary instead of gen_rtx_*_EXTEND. * config/i386/i386.md (*jcc_bt_1): New define_insn_and_split. * gcc.target/i386/pr57819.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr57819.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/config/i386/i386.md trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
[Bug target/57807] Compile failure with __builtin_ia32_unpcklpd with -masm=intel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57807 Uroš Bizjak changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-07/msg00225.htm ||l Target Milestone|--- |4.9.0 --- Comment #4 from Uroš Bizjak --- (In reply to jleahy+gcc from comment #3) > I'll test this on Monday and get back to you. Extensive changes [1] have been committed to current mainline (4.9). However, they won't be backported to release branches (they are not regressions). I will leave this PR open fow a while, please report any remaining -masm=intel issues with current mainline (4.9) here. [1] http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00225.html
[Bug rtl-optimization/57786] wasted work in distribute_notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57786 --- Comment #4 from Eric Botcazou --- Author: ebotcazou Date: Mon Jul 8 09:05:38 2013 New Revision: 200776 URL: http://gcc.gnu.org/viewcvs?rev=200776&root=gcc&view=rev Log: PR rtl-optimization/57786 * combine.c (distribute_notes) : Change all_used to bool and break out of the loop when it is set to false. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
[Bug rtl-optimization/57786] wasted work in distribute_notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57786 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #5 from Eric Botcazou --- Patch applied.
[Bug target/57848] internal compiler error on build with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson --- Reproducible with a 4.9 cross to x86_64-w64-mingw32. Started with r200349, but that may simply have triggered a latent problem.
[Bug target/57848] internal compiler error on build with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #3 from Mikael Pettersson --- Created attachment 30475 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30475&action=edit reduced test case
[Bug translation/57850] New: Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 Bug ID: 57850 Summary: Option -fdump-translation-unit not working Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: aponomarenko at rosalab dot ru Hi, The -fdump-translation-unit option of the GCC compiler was broken in 4.8.1 (relative to 4.7.1). Steps to reproduce: 1. Create any header file file.h 2. g++ -fdump-translation-unit file.h g++ 4.7.1 dumps test.h.001t.tu, but g++ 4.8.1 does nothing. May be this bug can be fixed like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55164 ? Thank you.
[Bug libgcc/57851] New: [patch] unwinding via signal trampoline for kfreebsd*-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57851 Bug ID: 57851 Summary: [patch] unwinding via signal trampoline for kfreebsd*-gnu Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: Petr.Salinger at seznam dot cz Created attachment 30476 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30476&action=edit proposed patch Please add support for unwinding through signal handler for GNU/kFreeBSD. The attached patch is tested on GNU/kFreeBSD, both 32-bit and 64-bit. The i386/freebsd-unwind.h is probably also suitable for plain FreeBSD.
[Bug fortran/57469] Erroneous warning for unused dummy arguments used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57469 --- Comment #4 from Tobias Burnus --- Author: burnus Date: Mon Jul 8 12:15:11 2013 New Revision: 200785 URL: http://gcc.gnu.org/viewcvs?rev=200785&root=gcc&view=rev Log: 2013-07-08 Tobias Burnus PR fortran/57469 * trans-decl.c (generate_local_decl): Don't warn that a dummy is unused, when it is in a namelist. 2013-07-08 Tobias Burnus PR fortran/57469 * gfortran.dg/warn_unused_dummy_argument_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57469] Erroneous warning for unused dummy arguments used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57469 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Burnus --- FIXED on the trunk (4.9). Thanks for the report!
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 kpet at free dot fr changed: What|Removed |Added CC||kpet at free dot fr --- Comment #5 from kpet at free dot fr --- I encounter a similar problem when building pixman.
[Bug fortran/56342] MATMUL with PARAMETER: Simplification usually doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56342 --- Comment #1 from Tobias Burnus --- Another example: http://gcc.gnu.org/ml/fortran/2013-07/msg5.html - Here, the SUM is not simplified.
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 --- Comment #6 from Markus Trippelsdorf --- (In reply to Jan Hubicka from comment #3) > Hmm, > the problem here is that we output errors after early inlining always now, > while previously we did > only when some other inlining happened in the function (adding extra early > inlinable function > to the testcase should reproduce the error message on early GCC releases). > We can fix by outputting always inline errors only after real inliner was > run (when optimizing) > but then such testcases won't compile at -O0 that is uncool too. I"m not sure if I understand you correctly, but the test-case compiles just fine at -O0. So outputting the always inline errors only after the real inliner was run should fix the issue. No?
[Bug rtl-optimization/55221] [regression] gcc-4.6-20121102/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER' undeclared here (not in a fnction)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55221 Anton Shterenlikht changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.6.4 |4.6.3 Resolution|--- |WORKSFORME --- Comment #5 from Anton Shterenlikht --- On FreeBSD 10.0-CURRENT #5 r252055, with ports tree at r322480, I can built lang/gcc, which is now 4.6: # gcc46 --version gcc46 (FreeBSD Ports Collection) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # pkg info -xo gcc-4.6 gcc-4.6.3 lang/gcc # This is with Gerald's patch: # cat /usr/ports/lang/gcc/files/patch-unwind-ia64.h 2010-09-12 Gerald Pfeifer PR target/45650 * config/ia64/unwind-ia64.h: Do not mark _Unwind_FindTableEntry hidden on FreeBSD. Index: gcc/config/ia64/unwind-ia64.h === --- gcc/config/ia64/unwind-ia64.h (revision 164211) +++ gcc/config/ia64/unwind-ia64.h (working copy) @@ -40,4 +40,7 @@ extern struct unw_table_entry * _Unwind_FindTableEntry (void *pc, unsigned long *segment_base, unsigned long *gp, struct unw_table_entry *ent) - __attribute__ ((__visibility__ ("hidden"))); +#ifndef __FreeBSD__ + __attribute__ ((__visibility__ ("hidden"))) +#endif +; # I think it was fixed due to recent binutil fixes. Since 4.7, 4.8, 4.9 all build fine on this platform, I'm no longer interested in 4.6.4. I'm therefore closing this PR.
[Bug fortran/57785] [4.7/4.8/4.9 Regression] DOT_PRODUCT error with constant complex array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57785 --- Comment #3 from Tobias Burnus --- Author: burnus Date: Mon Jul 8 13:48:19 2013 New Revision: 200786 URL: http://gcc.gnu.org/viewcvs?rev=200786&root=gcc&view=rev Log: 2013-07-08 Tobias Burnus PR fortran/57785 * simplify.c (compute_dot_product): Complex conjugate for dot_product. (gfc_simplify_dot_product, gfc_simplify_matmul): Update call. 2013-07-08 Tobias Burnus PR fortran/57785 * gfortran.dg/dot_product_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/dot_product_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/57850] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 Andrew Pinski changed: What|Removed |Added Component|translation |c++ Severity|critical|normal --- Comment #1 from Andrew Pinski --- I bet we no longer go through the code for dumping while doing precompiled headers .
[Bug target/57232] wcstol.c:213:1: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57232 Jon Beniston changed: What|Removed |Added CC||jon at beniston dot com --- Comment #10 from Jon Beniston --- A similar problem is seen in the LM32 port: http://gcc.gnu.org/ml/gcc/2013-03/msg00317.html It appeared for that in GCC 4.8.0 and is still in GCC 4.8.1.
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448 --- Comment #17 from Janis Johnson --- Paolo, I don't remember, but assume I didn't uncover anything else that was interesting.
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448 --- Comment #18 from Paolo Carlini --- So, are you still actively working on it? (I'm asking because the bug is assigned to you) Do you think it's still an issue today?
[Bug target/57232] wcstol.c:213:1: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57232 Jon Beniston changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #11 from Jon Beniston --- Adding Nick Clifton to the CC list. It seems the bug was known about a while back: http://gcc.gnu.org/ml/gcc/2012-10/msg00314.html Any luck with this Nick?
[Bug c++/57850] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 --- Comment #2 from Paolo Carlini --- See also PR2778 (!) If there is no interest in maintaining the option we should probably remove / deprecate it. Seriously.
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448 Paolo Carlini changed: What|Removed |Added CC||dje.gcc at gmail dot com --- Comment #19 from Paolo Carlini --- Adding David as powerpc expert.
[Bug target/57232] wcstol.c:213:1: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57232 --- Comment #12 from Jon Beniston --- This looks like it might be similar to bug 57636, which has the same ICE on the cr16 port. Suggestion there is that it was introduced in trunk@188870: 2012-06-21 Alexandre Oliva PR debug/53671 PR debug/49888 * var-tracking.c (vt_initialize): Record initial offset between arg pointer and stack pointer.
[Bug target/57636] cr16: ICE while building libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57636 Jon Beniston changed: What|Removed |Added CC||jon at beniston dot com --- Comment #2 from Jon Beniston --- This looks similar to bug 57232 which is the same ICE on the RX and LM32 ports.
[Bug fortran/50554] INQUIRE cannot redefine DO index (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50554 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus --- Author: burnus Date: Mon Jul 8 16:13:57 2013 New Revision: 200790 URL: http://gcc.gnu.org/viewcvs?rev=200790&root=gcc&view=rev Log: 2013-07-08 Tobias Burnus PR fortran/50554 * io.c (match_inquire_element): Add missing do-var check. 2013-07-08 Tobias Burnus PR fortran/50554 * gfortran.dg/do_check_9.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/do_check_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50554] INQUIRE cannot redefine DO index (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50554 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tobias Burnus --- FIXED on the trunk (4.9). Thanks for the report - and sorry for taking nearly two years to fix it.
[Bug fortran/57843] Polymorphic assignment for derived type is resolved with parent's generic instead of its own
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57843 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- (In reply to John from comment #0) > The code below does not do what's expected when compiled with gfortran-4.9 > (i.e., to print "this is right" instead of "what am I doing here?" every > time the polymorphic assignment is invoked, and also printing the assigned > values at the end, instead of the default ones. I get the same result with Cray's ftn 8.1.8. (Except that it prints "1 @� 0, 0." at the end - instead of "1 0 0."; that's most likely uninitialized memory, possibly a bug in the crayftn compiler [or something else].) > Maybe I still don't understand the semantics behind Fortran 2003+'s > type-bound assignment (so I apologize in advance if this is not a bug), but > it seems to me that the assign_itemType procedure is being used for > assignment, even though it doesn't satisfy the requirement of exact type for > the "right" argument ---is polymorphism being resolved at compile time even > for dynamic cases? I believe the generic resolution (assignment, operator but also "generic") is done at the compile time - which gives type bound procedure ("procedure :: name"). The only run-time component is whether the type-bound procedure of the basic type or of the extended type is called. I have to admit that I haven't yet studied the test case to see whether there is a problem or not.
[Bug libgcc/57851] [patch] unwinding via signal trampoline for kfreebsd*-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57851 --- Comment #1 from Uroš Bizjak --- (In reply to Petr.Salinger from comment #0) > Created attachment 30476 [details] > proposed patch > > Please add support for unwinding through signal handler for GNU/kFreeBSD. > > The attached patch is tested on GNU/kFreeBSD, both 32-bit and 64-bit. > The i386/freebsd-unwind.h is probably also suitable for plain FreeBSD. Please post the patch to gcc-patches@ mailing list.
[Bug target/57844] avr-unknown-elf libstdc++v3 build causes internal compiler error: in extract_insn, at recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57844 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-08 CC||gjl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org Target Milestone|--- |4.8.2 Ever confirmed|0 |1 --- Comment #1 from Georg-Johann Lay --- Here is a smaller test case: void g (char*); void f (void) { char b[128]; g (b); } Compile with $ avr-gcc foo.c -c -msp8 foo.c: In function 'f': foo.c:7:1: error: unrecognizable insn: } ^ (insn/f 16 15 17 (set (reg:QI 28 r28) (plus:QI (reg:QI 28 r28) (const_int 128 [0x80]))) foo.c:5 -1 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:HI 28 r28) (plus:HI (reg/f:HI 28 r28) (const_int -128 [0xff80]))) (nil))) foo.c:7:1: internal compiler error: in insn_default_length, at config/avr/avr.md:448 foo.c:7:1: internal compiler error: Segmentation fault Problem is that 128 is not QI, should be -128. --enable-libstdcxx vs. building libstdc++v3 is a different issue.
[Bug target/57848] internal compiler error on build with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #4 from Mikael Pettersson --- The reduced test case also ICEs 4.8-20130704, 4.7-20130706, and 4.6-20130405 (haven't checked older versions yet).
[Bug fortran/57834] [4.9 Regression] C_F_POINTER (only with -std=): accepts only explicit- and assumed-size arrays for FPTR when SHAPE is present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57834 --- Comment #2 from Tobias Burnus --- Author: burnus Date: Mon Jul 8 19:05:16 2013 New Revision: 200794 URL: http://gcc.gnu.org/viewcvs?rev=200794&root=gcc&view=rev Log: 2013-07-08 Tobias Burnus PR fortran/57834 * check.c (is_c_interoperable): Add special case for * c_f_pointer. (explicit-size, gfc_check_c_f_pointer, gfc_check_c_loc): Update call. 2013-07-08 Tobias Burnus PR fortran/57834 * gfortran.dg/c_f_pointer_tests_8.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57834] [4.9 Regression] C_F_POINTER (only with -std=): accepts only explicit- and assumed-size arrays for FPTR when SHAPE is present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57834 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED on the trunk (4.9). Thanks for the report!
[Bug testsuite/57591] gcc-4.8 libbacktrace btest failure on Linux ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57591 --- Comment #2 from acrux --- same failure with gcc-4.8-20130704
[Bug fortran/57785] [4.7/4.8/4.9 Regression] DOT_PRODUCT error with constant complex array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57785 --- Comment #4 from Tobias Burnus --- Author: burnus Date: Mon Jul 8 19:10:32 2013 New Revision: 200795 URL: http://gcc.gnu.org/viewcvs?rev=200795&root=gcc&view=rev Log: 2013-07-08 Tobias Burnus PR fortran/57785 * simplify.c (compute_dot_product): Complex conjugate for dot_product. (gfc_simplify_dot_product, gfc_simplify_matmul): Update call. 2013-07-08 Tobias Burnus PR fortran/57785 * gfortran.dg/dot_product_2.f90: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/dot_product_2.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/simplify.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/57785] [4.7/4.8/4.9 Regression] DOT_PRODUCT error with constant complex array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57785 --- Comment #5 from Tobias Burnus --- Author: burnus Date: Mon Jul 8 19:12:08 2013 New Revision: 200796 URL: http://gcc.gnu.org/viewcvs?rev=200796&root=gcc&view=rev Log: 2013-07-08 Tobias Burnus PR fortran/57785 * simplify.c (compute_dot_product): Complex conjugate for dot_product. (gfc_simplify_dot_product, gfc_simplify_matmul): Update call. 2013-07-08 Tobias Burnus PR fortran/57785 * gfortran.dg/dot_product_2.f90: New. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/dot_product_2.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/simplify.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/57785] [4.7/4.8/4.9 Regression] DOT_PRODUCT error with constant complex array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57785 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tobias Burnus --- FIXED on the trunk (4.9) and on both maintained branched (4.7 and 4.9). Thanks for the report - and sorry for the bug!
[Bug plugins/57852] New: lib/plugin-support.exp incorrectly sets PLUGINCC to compilers in prev-gcc breaks testing on lean bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57852 Bug ID: 57852 Summary: lib/plugin-support.exp incorrectly sets PLUGINCC to compilers in prev-gcc breaks testing on lean bootstrap Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu After switching my normal gcc48 packaging build to use lean bootstraps, I noticed a number of test suite failures like... FAIL: gcc.dg/plugin/selfassign.c compilation FAIL: gcc.dg/plugin/ggcplug.c compilation FAIL: gcc.dg/plugin/one_time_plugin.c compilation FAIL: gcc.dg/plugin/start_unit_plugin.c compilation FAIL: gcc.dg/plugin/finish_unit_plugin.c compilation this is due to PLUGIN_CC being set to the compilers in the prev-gcc subdirectory rather than those in the gcc subdirectory as seen from one of the failing tests.. Executing on build: /sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/./prev-gcc/xg++ -B/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.8/x86_64-apple-darwin13.0.0/bin/ -nostdinc++ -B/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/libsupc++/.libs -I/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/include/x86_64-apple-darwin13.0.0 -I/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/include -I/sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/libstdc++-v3/libsupc++ -L/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/libsupc++/.libs -g -O2 /sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/gcc/testsuite/gcc.dg/plugin/selfassign.c -I. -I/sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/gcc/testsuite -I/sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/gcc/testsuite/../../gcc -I/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/gcc/testsuite/gcc/../../../gcc -I/sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/gcc/testsuite/../../include -I/sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/gcc/testsuite/../../libcpp/include -I/sw/include -I/sw/include -I/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/gcc/testsuite/gcc/../../../intl -O -DIN_GCC -fPIC -shared -undefined dynamic_lookup -o selfassign.so (timeout = 300) set_ld_library_path_env_vars: ld_library_path=:/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/gcc:/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/.libs FAIL: gcc.dg/plugin/selfassign.c compilation Please set PLUGIN_CC to the final build of the compilers in the gcc subdirectory.
[Bug target/57232] wcstol.c:213:1: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57232 Jon Beniston changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #13 from Jon Beniston --- Hi Alexandre, I've added you to this bug as it seems to have been caused by this patch you made: http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/var-tracking.c?r1=188869&r2=188870 I've got no idea what this code does, but if I removed it, the ICE disappears on LM32. If you think it is a backend problem, rather than this code, it would be helpful if you could give some guidance as to what needs changing, as it seems three targets currently have this problem. Thanks.
[Bug c/57853] New: pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Bug ID: 57853 Summary: pointer arithmetic on arrays Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: brodhow at all2easy dot net This C code: #include int main() { char *arr [2][3]={{"as","df","ce"},{"me","yu","we"}}; char *arr2 = NULL; puts(*arr[0]);//works fine puts(*arr[1]);//works fine printf("%c\n",*++arr[0][0]);//works fine and prints s printf("%s\n", *arr[0]); int i = 0, j = 0; for (i=0; i<2; ++i) for (j=0; j<3; ++j) printf("%s ", arr[i][j]); printf("\n"); } outputs: as me s s s df ce me yu we where the 'a' in "as" (arr[0]) is being wiped out! After the "printf("%c\n",*++arr[0][0]);" statement! Or, the string arr's head is being reassigned to the new value after the "*++arr[0][0]" operation which is 's'! the output should be: as me s as as df ce me yu we where the 'a' in "as" is present, afterwards! The pointer arithmetic here to get 's' to output is producing this side effect of wiping out the 'a' in "as", arr[0]. Is "*++arr[0][0]" valid for getting 's' in "as"? If so, then this side effect is happening! For real in any legacy C code with similar syntax! When said C code is recompiled by the current gcc compiler! Note that g++ does the same thing here too, on this code.
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #1 from Howard Brodale --- gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- ++arr[0][0] Does: (arr[0][0] += 1) So it increments the char pointer so instead of pointing to &"as"[0], it points to &"as"[1].
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Howard Brodale changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Howard Brodale --- ++arr[0][0] does work for printing out the second character 's'. But, then that pointer arithmetic operation has the side effect of wiping out the 'a' from "as". Because when for (i=0; i<2; ++i) for (j=0; j<3; ++j) printf("%s ", arr[i][j]); runs, it just prints 's' for where "as" should be. The 'a' is now gone or destroyed by the previous ++arr[0][0] operation. Wgen that "++" is removed then "as" prints from those for loops after where the printf with the "++" was. So, this bug is not invalid! And, is not resolved!
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- (In reply to Howard Brodale from comment #3) > ++arr[0][0] does work for printing out the second character 's'. ++arr[0][0] increments arr[0][0] like you said. It changes the value of what is contained in arr[0][0] .
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Howard Brodale changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Howard Brodale --- "*arr[0][0] += 1" generates a segmentation fault when run. That is not vaild to get 's' to output.
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #6 from Howard Brodale --- "*++arr[0][0]" is not supposed to change the array arr! It is supposed to take the source, change it for later use and leave the source unchanged! That the way pointer arithmetic works. It never has changed the source ever, until now. Where "as" is still supposed to output we get only 's' now.
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #7 from Howard Brodale --- we get only 's' in a subsequent printf that runs after that "++" statements. >From that next printf "as" should aappear but, it has been changed to only 's', by the "++" operation!
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Andrew Pinski --- >"*++arr[0][0]" is not supposed to change the array arr! At this point I am going to say you don't know C and should ask on a C mailing list learning C. *++arr[0][0] does the following: ++arr[0][0] And then deferences that value (which turns into 's'). If you only want (arr[0][0])[1] then use that or *(arr[0][0]+1) rather than ++.
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448 David Edelsohn changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #20 from David Edelsohn --- I don't think that Janis is working on this PR any more. I'm not sure if the examples still are valid C++. unsigned char m1:17; warning: width of 'bc::m1' exceeds its type [enabled by default] unsigned char m1 :17; ^ The testcase do not fail with GCC 4.7.2 and GCC 4.8.1.
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448 --- Comment #21 from Janis Johnson --- I'm definitely not working on the bug anymore, and would have to do a lot of work (better left to experts) to figure out if the test is valid. Please assign it to someone else, or at least unassign it from me (or tell me how to do that). If the functionality really mattered to the submitter he would have spoken up again.
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WORKSFORME --- Comment #22 from Paolo Carlini --- Thanks. Let's close this then.
[Bug c++/57854] New: Would like to have a warning for virtual overrides without C++11 "override" keyword
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57854 Bug ID: 57854 Summary: Would like to have a warning for virtual overrides without C++11 "override" keyword Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: thiago at kde dot org I would like a new (optional) warning that would point out every C++ virtual override that is done without the C++11 keyword that indicates an override. By necessity, this warning would only be permitted in C++11 mode. The keyword was added so that developers would let the compiler know when an override is intended. However, the [[base_check]] attribute was dropped from C++11 prior to standardisation, so there's no way (currently) to ask the compiler to let us know which classes are doing overrides without the keyword. This warning should be printed in the otherwise perfectly correct code: struct Base { virtual void v(); }; struct Derived: Base { virtual void v(); // warning happens here }; This warning should not be in -Wall. It should be in -Weffc++. I'll leave it up to you whether it's in -Wextra.
[Bug libitm/57855] New: passing unsafe function as transaction_safe function pointer does not generate error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57855 Bug ID: 57855 Summary: passing unsafe function as transaction_safe function pointer does not generate error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm Assignee: unassigned at gcc dot gnu.org Reporter: spear at cse dot lehigh.edu The following code should be rejected, but is not: #include // typedef of a function pointer that is transaction_safe typedef void (*ADD_STAT)(const char *key, const int klen, const char *val, const int vlen, const void *cookie) __attribute__((transaction_safe)); // function that uses a transaction to call a function that is supposed to be // safe void bar(ADD_STAT f) { __transaction_atomic { f(NULL, 0, NULL, 0, NULL); } } // this function is not safe, and is not annotated as being safe void my_func(const char *key, const int klen, const char *val, const int vlen, const void *cookie) { printf("Hello World\n"); } // uh-oh! I can pass my_func to bar, and it doesn't break! int main() { bar(my_func); } Compilation: gcc -std=gnu11 -DHAVE_CONFIG_H -DNDEBUG -g -O2 -pthread -fgnu-tm -MD -MP -o demo demo.c The issue here is that my_func is not transaction_safe, but when my_func is passed to bar, which expects a transaction_safe function as its first parameter, the compiler does not reject the code. It appears as though the transaction_safe attribute in the typedef is being ignored when determining if my_func is the correct type to be passed to bar, but not when determining if my_func can be called from within bar's transaction.
[Bug libitm/57855] passing unsafe function as transaction_safe function pointer does not generate error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57855 --- Comment #1 from Mike Spear --- PS: error seems to have been around for a while, and is certainly present in trunk revision 200806
[Bug c/57856] New: for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 Bug ID: 57856 Summary: for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gang.chen at asianux dot com Created attachment 30477 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30477&action=edit Related disassemble code. For Linux kernel source code "mm/vmscan.c", function putback_lru_page(), version is next-20130621. Gcc assumes "lru == LRU_UNEVICTABLE" instead of report warnings (uninitializing lru). I got gcc source code from svn, "configure && make && make install". [root@gchenlinux linux-next]# which gcc /usr/local/bin/gcc [root@gchenlinux linux-next]# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure Thread model: posix gcc version 4.9.0 20130704 (experimental) (GCC) The related source code: 580 void putback_lru_page(struct page *page) 581 { 582 int lru; 583 int was_unevictable = PageUnevictable(page); 584 585 VM_BUG_ON(PageLRU(page)); 586 587 redo: 588 ClearPageUnevictable(page); 589 590 if (page_evictable(page)) { 591 /* 592 * For evictable pages, we can use the cache. 593 * In event of a race, worst case is we end up with an 594 * unevictable page on [in]active list. 595 * We know how to handle that. 596 */ 597 lru_cache_add(page); 598 } else { 599 /* 600 * Put unevictable pages directly on zone's unevictable 601 * list. 602 */ 603 lru = LRU_UNEVICTABLE; 604 add_page_to_unevictable_list(page); 605 /* 606 * When racing with an mlock or AS_UNEVICTABLE clearing 607 * (page is unlocked) make sure that if the other thread 608 * does not observe our setting of PG_lru and fails 609 * isolation/check_move_unevictable_pages, 610 * we see PG_mlocked/AS_UNEVICTABLE cleared below and move 611 * the page back to the evictable list. 612 * 613 * The other side is TestClearPageMlocked() or shmem_lock(). 614 */ 615 smp_mb(); 616 } 617 618 /* 619 * page's status can change while we move it among lru. If an evictable 620 * page is on unevictable list, it never be freed. To avoid that, 621 * check after we added it to the list, again. 622 */ 623 if (lru == LRU_UNEVICTABLE && page_evictable(page)) { 624 if (!isolate_lru_page(page)) { 625 put_page(page); 626 goto redo; 627 } 628 /* This means someone else dropped this page from LRU 629 * So, it will be freed or putback to LRU again. There is 630 * nothing to do here. 631 */ 632 } 633 634 if (was_unevictable && lru != LRU_UNEVICTABLE) 635 count_vm_event(UNEVICTABLE_PGRESCUED); 636 else if (!was_unevictable && lru == LRU_UNEVICTABLE) 637 count_vm_event(UNEVICTABLE_PGCULLED); 638 639 put_page(page); /* drop ref from isolate */ 640 } /* * Related disassemble code: * make defconfig under x86_64 PC. * make menuconfig (choose "Automount devtmpfs at /dev..." and KGDB) * make V=1 EXTRA_CFLAGS=-W (not find related warnings, ref warn.log in attachment) * objdump -d vmlinux > vmlinux.S * vi vmlinux.S * * The issue is: compiler assumes "lru == LRU_UNEVICTABLE" instead of report warnings (uninitializing lru) */ 810f3d20 : 810f3d20: 55 push %rbp 810f3d21: 48 89 e5mov%rsp,%rbp 810f3d24: 41 55 push %r13 810f3d26: 41 54 push %r12 810f3d28: 4c 8d 67 02 lea0x2(%rdi),%r12 ; for ClearPageUnevictable(page); 810f3d2c: 53 push %rbx 810f3d2d: 4c 8b 2fmov(%rdi),%r13 ; was_unevictable = PageUnevictable(page); 810f3d30: 48 89 fbmov%rdi,%rbx 810f3d33: 49 c1 ed 14 shr$0x14,%r13 810f3d37: 41 83 e5 01 and$0x1,%r13d 810f3d3b: eb 2
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 --- Comment #1 from Andrew Pinski --- I think this is a dup of another bug.
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 Chen Gang changed: What|Removed |Added CC||gang.chen at asianux dot com --- Comment #2 from Chen Gang --- Created attachment 30478 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30478&action=edit Compiling command(use red hat 4.7.2 as a demo), it's same for gcc 4.9.0 compiling from source code.
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 --- Comment #3 from Chen Gang --- Created attachment 30479 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30479&action=edit The related warnings, not find uninitailized warning for lru.
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 --- Comment #4 from Chen Gang --- Created attachment 30480 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30480&action=edit This attachment is for gcc 4.9.0 from compiling source code (sorry, the original disassembly code is for red hat 4.7.2)
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 --- Comment #5 from Chen Gang --- (In reply to Andrew Pinski from comment #1) > I think this is a dup of another bug. Firstly, thank you reply as soon as possible. Could you provide the related Bug number ? Thanks.
[Bug c++/57857] New: argument of decltype used by no return value warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57857 Bug ID: 57857 Summary: argument of decltype used by no return value warning Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: potswa at mac dot com The following program complains that "declval() must not be used!" in a static assertion if -Wall is passed. But declval() is only present in the unevaluated context of a decltype specifier. The issue seems to be linked to the generation of the warning message. But the warning message will be present without the static_assert if the function has more than one exit point, such as if(0) throw; or if(0) return; (the latter using -fpermissive). #include template auto foo() -> decltype(std::declval() + std::declval()); template decltype(foo()) bar(T) { // if ( 0 ) throw; } int main() { bar(1); }
[Bug c++/57857] argument of decltype used by no return value warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57857 --- Comment #1 from David Krauss --- Narrowing down the cause, the statement { 0; } silences the error but { void(0); } does not.
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Howard Brodale changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #9 from Howard Brodale --- (In reply to Andrew Pinski from comment #8) > >"*++arr[0][0]" is not supposed to change the array arr! > > At this point I am going to say you don't know C and should ask on a C > mailing list learning C. > > *++arr[0][0] does the following: > ++arr[0][0] > And then deferences that value (which turns into 's'). > > > If you only want (arr[0][0])[1] then use that or *(arr[0][0]+1) rather than > ++. That is not the issue. With "*++arr[0][0]" we want to see 's'. The problem is after that "++" operation when we want to output the array arr's values again that the arr[0][0] is no longer "as" but, only "s" now. That is seen in the nested for loops, after the "++" operation, above. When the "++" operation is removed then in the for loops, a[0][0] is "as"; in the for loop's printf. You are not looking at the for loops printf()! With the "++" operstion then, the printf() in the for loops outputs "s" for where "as" was. This means that a[0][0] is being treated as a Left Hand value of an equal sign where a[0][0]++ value is now the right hand side of that equal sign. Where a[0][0] is being set equal to "s" now. This process has never existed before in C when doing pointer arithmetic (++) on array elements and such. Where performing ++ptr would not just result in the next datatype's value normally. But, here a --ptr would then render the initial value, again. Or, where *ptr remained unchanged, itself. Millions of lines of legacy C code has this same pointer arithmetic in the expectation that it does not change the value that the pointer points to, for later reference. Or, ++prt does not change the value that a[0][0] is but, here "++" is changing what a[0] is, later. Before, a[0] is set to "as" in the for loop's printf after where "++" was, above. After the "++" operation is added, a[0] is now being set to just "s" or the 'a' has been wiped out, lost or destroyed. As seen in the later printf, in the for loops. So, see what the for loop's printf outputs for a[0][0] ("as") without the "++" operation above. Then, add "++" and see what the same for loop's printf outputs ("s"). That value in the array was changed by the pointer arithmetic! Or, ++ptr is not equivalent to ptr = ++pter! But, that is whats happening here! As seen in the for loop's printf for array arr! Do you agree that ++ptr is not equivalent to ptr = ++pter? If not then you don't see that that this is whats very wrong here! Pointer arithmetic does not make the value a pointer points to a Left Hand side value, in this equality expression! No such equality expression should exist here!
[Bug c++/57550] [4.8/4.9 Regression] bogus "error ... is private"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57550 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.8.2 --- Comment #4 from Jason Merrill --- Fixed for 4.8.2/4.9
[Bug c++/57831] [4.7/4.8/4.9 Regression] pointer to member function inaccessible through using statement (or ICE)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57831 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/57658] [4.9 Regression] ICE in tsubst_copy, at cp/pt.c:12213
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57658 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #10 from Howard Brodale --- Should we expect to see "as" in the for loop's printf, for arr[0][0]? YES! And, we do when the pointer arithmetic is NOT being done, above. But, something changed arr[0] to "s" only! What did that? Did I change arr[0] like where I specified arr[0] = "s";? NO! But, something did! Should the C code set arr[0] = "s"? NO! But, it did set a[0] to "s", only! Thats whats happening, erroneously! For when we output array arr again or later or after the pointer arithmetic operation is shown THEN, only "s" appears where "as" used to be! And, also for every where else a[0] is being printed! After the pointer arithmetic operation. This "s" problemm is being shown in the for loop's printf and every where else a[0] is being outputed, AFTER the "++" operation. Where another "++" is not! But, "a" is still not showing up, AFTER the initial "++" operation. Look at all the subsequent printfs, AFTER the "++" operation. Where "as" used to be now only "s" is being outputed. Do you see where the issue is first appearing? Then, by what C code statement the issue is being done by? Though "*++arr[0][0]" does output 's' (correctly); something else is being done that should not be done! Setting *arr[0] EQUAL TO "s"! Which is wrong!
[Bug fortran/50554] INQUIRE cannot redefine DO index (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50554 --- Comment #5 from Vittorio Zecca --- No problem, it was low priority and with easy workaround. gfortran has much much improved from first time I looked at it around 2005. Keep up the good work!
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Andrew Pinski --- ++v mean pre-increment v. That means store the incremented v back into v. If you don't understand that, then I cannot help you. Please stop opening an already closed bug. This is not the correct forum to learn C, please take this discussion somewhere else.
[Bug c++/57751] [4.7/4.8/4.9 Regression] ICE in cxx_eval_indirect_ref, at cp/semantics.c:7648
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57751 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/57545] [4.7/4.8/4.9 Regression] Generation of debug symbols leads to internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57545 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/57532] [4.8/4.9 regression] operator& broken when used on rvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57532 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 Howard Brodale changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #12 from Howard Brodale --- "store the incremented v back into v" is not quite right either. The pointer arithmetic "*++arr[0][0]" is incrementing the head pointer of the string array element one char past 'a' and not actually storing the shortened string back in there. If it was storing the shortened string there then the 'a' would be lost or written over which it is not. printf("%c\n",*++arr[0][0]);//works fine and prints s printf("%c\n",*--arr[0][0]);//works fine does print a as me s <- the 1st "++"; incrementing past 'a' a <- the first "--"; dcrementing back to 'a' as <- "as" prints now as expected as df ce me yu we <- and here again, too, "as" is showing as expected. Take out the "--" operation and these "as"s will be "s"s. 'a' is not lost nor written over by any storing back into v, here or no storing is going on. Just pointer that array arr gets moved over to point at the next character. char *arr2 = "this is a test\n"; int len_arr2 = 0; len_arr2 = strlen(++arr2); printf("length of arr2 is %i\n", len_arr2); printf("%c\n", *arr2--); len_arr2 = strlen(arr2); printf("length of arr2 is %i\n", len_arr2); puts(arr2); outputs: length of arr2 is 14 <- "++"; moving past the 't', one character less in string his is a test <- 't' is missing now length of arr2 is 15 <- "--"; moving back over the 't', one character more this is a test <- 't' is back now; if storing in v happened then 't' would've been lost and would be not recoverable. Now, I have also recovered more knowledge about pointer arithmentic, with character strings. 'a' is not being destoyed or lost in the original context. Its just being ignored.
[Bug c++/57437] [4.7/4.8/4.9 Regression] C++11: mutable lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org