[Bug middle-end/57845] ICE with -freg-struct-return on Sparc target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- -freg-struct-return isn't supported on the SPARC.
[Bug ada/57849] ICE with Convention = C in Ada 2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57849 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.9.0 Summary|With Convention = C causes |ICE with Convention = C in |Bug box with -gnat2012 |Ada 2012 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Fixed on mainline.
[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 mikpe at it dot uu.se --- 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 Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (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 jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Jul 8 08:11:08 2013 New Revision: 200768 URL: http://gcc.gnu.org/viewcvs?rev=200768root=gccview=rev Log: PR rtl-optimization/57829 * simplify-rtx.c (simplify_binary_operation_1) case IOR: 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=200770root=gccview=rev Log: PR rtl-optimization/57829 * simplify-rtx.c (simplify_binary_operation_1) case IOR: 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=200773root=gccview=rev Log: PR rtl-optimization/57829 * simplify-rtx.c (simplify_binary_operation_1) case IOR: 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 ebotcazou at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org --- Recategorizing.
[Bug target/57819] Suboptimal shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57819 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Jul 8 08:48:40 2013 New Revision: 200775 URL: http://gcc.gnu.org/viewcvs?rev=200775root=gccview=rev Log: PR target/57819 * simplify-rtx.c (simplify_unary_operation_1) case ZERO_EXTEND: 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_btmode_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 ubizjak at gmail dot com 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 ubizjak at gmail dot com --- (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 ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Mon Jul 8 09:05:38 2013 New Revision: 200776 URL: http://gcc.gnu.org/viewcvs?rev=200776root=gccview=rev Log: PR rtl-optimization/57786 * combine.c (distribute_notes) case REG_DEAD: 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 ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- 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 mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- 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 mikpe at it dot uu.se --- Created attachment 30475 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30475action=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=30476action=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 burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jul 8 12:15:11 2013 New Revision: 200785 URL: http://gcc.gnu.org/viewcvs?rev=200785root=gccview=rev Log: 2013-07-08 Tobias Burnus bur...@net-b.de 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 bur...@net-b.de 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 burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- 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 burnus at gcc dot gnu.org --- 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 markus at trippelsdorf dot de --- (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. Im 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 mexas at bristol dot ac.uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.6.4 |4.6.3 Resolution|--- |WORKSFORME --- Comment #5 from Anton Shterenlikht mexas at bristol dot ac.uk --- 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 ger...@pfeifer.com 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 burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jul 8 13:48:19 2013 New Revision: 200786 URL: http://gcc.gnu.org/viewcvs?rev=200786root=gccview=rev Log: 2013-07-08 Tobias Burnus bur...@net-b.de 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 bur...@net-b.de 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 pinskia at gcc dot gnu.org changed: What|Removed |Added Component|translation |c++ Severity|critical|normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- 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 jon at beniston dot com changed: What|Removed |Added CC||jon at beniston dot com --- Comment #10 from Jon Beniston jon at beniston dot com --- 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 janis at gcc dot gnu.org --- 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 paolo.carlini at oracle dot com --- 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 jon at beniston dot com changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #11 from Jon Beniston jon at beniston dot com --- 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 paolo.carlini at oracle dot com --- 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 paolo.carlini at oracle dot com changed: What|Removed |Added CC||dje.gcc at gmail dot com --- Comment #19 from Paolo Carlini paolo.carlini at oracle dot com --- 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 jon at beniston dot com --- 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 aol...@redhat.com 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 jon at beniston dot com changed: What|Removed |Added CC||jon at beniston dot com --- Comment #2 from Jon Beniston jon at beniston dot com --- 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 burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jul 8 16:13:57 2013 New Revision: 200790 URL: http://gcc.gnu.org/viewcvs?rev=200790root=gccview=rev Log: 2013-07-08 Tobias Burnus bur...@net-b.de PR fortran/50554 * io.c (match_inquire_element): Add missing do-var check. 2013-07-08 Tobias Burnus bur...@net-b.de 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 burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- 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 burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- (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 ubizjak at gmail dot com --- (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 gjl at gcc dot gnu.org 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 gjl at gcc dot gnu.org ---
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 mikpe at it dot uu.se --- 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 burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jul 8 19:05:16 2013 New Revision: 200794 URL: http://gcc.gnu.org/viewcvs?rev=200794root=gccview=rev Log: 2013-07-08 Tobias Burnus bur...@net-b.de 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 bur...@net-b.de 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 burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- 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 acrux at linuxmail dot org --- 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 burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jul 8 19:10:32 2013 New Revision: 200795 URL: http://gcc.gnu.org/viewcvs?rev=200795root=gccview=rev Log: 2013-07-08 Tobias Burnus bur...@net-b.de 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 bur...@net-b.de 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 burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jul 8 19:12:08 2013 New Revision: 200796 URL: http://gcc.gnu.org/viewcvs?rev=200796root=gccview=rev Log: 2013-07-08 Tobias Burnus bur...@net-b.de 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 bur...@net-b.de 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 burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- 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 jon at beniston dot com changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #13 from Jon Beniston jon at beniston dot com --- 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=188869r2=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 stdio.h
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; i2; ++i)
for (j=0; j3; ++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 brodhow at all2easy dot net --- 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 pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- ++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 brodhow at all2easy dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Howard Brodale brodhow at all2easy dot net --- ++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; i2; ++i) for (j=0; j3; ++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 pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (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 brodhow at all2easy dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Howard Brodale brodhow at all2easy dot net --- *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 brodhow at all2easy dot net --- *++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 brodhow at all2easy dot net --- 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 pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- *++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 dje at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #20 from David Edelsohn dje at gcc dot gnu.org --- 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 janis at gcc dot gnu.org --- 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 paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WORKSFORME --- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com --- 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 stdio.h
// 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 spear at cse dot lehigh.edu --- 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=30477action=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 putback_lru_page:
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 28
[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 pinskia at gcc dot gnu.org --- 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 gang.chen at asianux dot com changed: What|Removed |Added CC||gang.chen at asianux dot com --- Comment #2 from Chen Gang gang.chen at asianux dot com --- Created attachment 30478 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30478action=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 gang.chen at asianux dot com --- Created attachment 30479 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30479action=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 gang.chen at asianux dot com --- Created attachment 30480 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30480action=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 gang.chen at asianux dot com --- (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 utility
template typename U
auto foo() - decltype(std::declvalU() + std::declvalU());
template typename T
decltype(fooT()) 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 potswa at mac dot com ---
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 brodhow at all2easy dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #9 from Howard Brodale brodhow at all2easy dot net --- (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 jason at gcc dot gnu.org 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 jason at gcc dot gnu.org --- 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 jason at gcc dot gnu.org 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 jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/57853] pointer arithmetic on arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57853 --- Comment #10 from Howard Brodale brodhow at all2easy dot net --- 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 zeccav at gmail dot com --- 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 pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org --- ++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 jason at gcc dot gnu.org 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
