[Bug rtl-optimization/55747] Extra registers are saved in functions that only call noreturn functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55747 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-06 CC||hp at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Hans-Peter Nilsson 2013-01-06 08:26:11 UTC --- Similarly observed for cris-elf with -O2, r194929, JFTR. If this changes, some attribute markup should be added to keep return-addresses for noreturn functions, for sake of stack-traces. Also return-addresses need to be generally kept when -fexceptions and similar are in effect, as noreturn functions can still throw.
[Bug target/55712] cpuinfo.c doesn't compile for x86-64 with medium memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55712 --- Comment #9 from uros at gcc dot gnu.org 2013-01-06 08:45:48 UTC --- Author: uros Date: Sun Jan 6 08:45:43 2013 New Revision: 194937 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194937 Log: Backport from mainline 2013-01-03 Uros Bizjak PR target/55712 * config/i386/i386-c.c (ix86_target_macros_internal): Depending on selected code model, define __code_mode_small__, __code_model_medium__, __code_model_large__, __code_model_32__ or __code_model_kernel__. * config/i386/cpuid.h (__cpuid, __cpuid_count) [__i386__]: Prefix xchg temporary register with %k. Declare temporary register as early clobbered. [__x86_64__]: For medium and large code models, preserve %rbx register. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/cpuid.h branches/gcc-4_7-branch/gcc/config/i386/i386-c.c
[Bug target/55712] cpuinfo.c doesn't compile for x86-64 with medium memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55712 Uros Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2012-12/msg01391.htm |atches/2012-12/msg01484.htm |l |l Resolution||FIXED Target Milestone|4.8.0 |4.7.3 --- Comment #10 from Uros Bizjak 2013-01-06 09:15:43 UTC --- Fixed.
[Bug c++/55885] New: Modulo operator crashes for int and long variables if they have minimal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55885
Bug #: 55885
Summary: Modulo operator crashes for int and long variables if
they have minimal value
Classification: Unclassified
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: klaus.wie...@endolandia.de
Error description in source file
-
Compiled with
-
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658)
(LLVM build 2336.11.00) on MAC OS X Version 10.7.5 (Lion)
-
Result of gcc -v:
-
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~67/src/configure
--disable-checking --enable-werror
--prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++
--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin11
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~67/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
-
Compiler and linker output
-
make all
Building file: ../src/iotest.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -Wextra -c -fmessage-length=0 -MMD -MP -MF"src/iotest.d"
-MT"src/iotest.d" -o "src/iotest.o" "../src/iotest.cpp"
Finished building: ../src/iotest.cpp
Building target: iotest
Invoking: MacOS X C++ Linker
g++ -o "iotest" ./src/iotest.o
Finished building target: iotest
-
Compiling with options -fno-strict-aliasing -fwrapv does not make a difference
-
file: iotest.cpp
-
#include
#include
// Assumption: If a is a signed variable, then a % -1 should always be 0
//
// okif myType is of type char or short
// fails if myType is of type int or long
int main() {
typedef int myType;
myType c;
myType a = std::numeric_limits::min();
intb = -1;
// always ok
c = a % -1;
std::cout << a << ", " << b << ", " << c << std::endl;
// signals EXC ARITHMETIC:Arithmetic exception
// if myType is int or is long
c = a % b;
std:: cout << a << ", " << b << ", " << c << std::endl;
return 0;
}
[Bug c++/55885] Modulo operator crashes for int and long variables if they have minimal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55885 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab 2013-01-06 11:01:33 UTC --- INT_MIN % -1 is undefined due to overflow. -fwrapv has no effect on division operations.
[Bug libstdc++/52015] std::to_string does not work under MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 --- Comment #22 from Jonathan Wakely 2013-01-06 11:31:03 UTC --- OS wasn't the right term, but you need to update mingw32-w64 to a recent version from trunk. That requirement is not suitable for a release branch.
[Bug c++/55885] Modulo operator crashes for int and long variables if they have minimal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55885 --- Comment #2 from kwieder at polytechnic dot edu.na 2013-01-06 12:14:16 UTC --- Thanks for the quick response. Why is INT_MIN % -1 ok and why is int b = -1; INT_MIN % b not ok. I"m well aware of INT_MIN / -1 is overflowing. If your are using a division for the % operator, which you probably do, then INT_MIN % -1 should also crash. Regards, Klaus On Jan 6, 2013, at 1:01 PM, sch...@linux-m68k.org wrote: > if they have minimal value > > Date: Sun, 06 Jan 2013 11:01:33 + > > X-Bugzilla-Reason: Reporter > > X-Bugzilla-Type: changed > > X-Bugzilla-Watch-Reason: None > > X-Bugzilla-Product: gcc > > X-Bugzilla-Component: c++ > > X-Bugzilla-Keywords: > > X-Bugzilla-Severity: normal > > X-Bugzilla-Who: sch...@linux-m68k.org > > X-Bugzilla-Status: RESOLVED > > X-Bugzilla-Priority: P3 > > X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org > > X-Bugzilla-Target-Milestone: --- > > X-Bugzilla-Changed-Fields: Status Resolution > > Message-ID: > > In-Reply-To: > > References: > > X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ > > Auto-Submitted: auto-generated > > Content-Type: text/plain; charset="UTF-8" > > MIME-Version: 1.0 > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55885 > > > > Andreas Schwab changed: > > > > What|Removed |Added > > > > Status|UNCONFIRMED |RESOLVED > > Resolution||INVALID > > > > --- Comment #1 from Andreas Schwab 2013-01-06 > 11:01:33 UTC --- > > INT_MIN % -1 is undefined due to overflow. -fwrapv has no effect on division > > operations. > > > > -- > > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > > --- You are receiving this mail because: --- > > You reported the bug.
[Bug c++/55885] Modulo operator crashes for int and long variables if they have minimal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55885 --- Comment #3 from Jonathan Wakely 2013-01-06 12:26:13 UTC --- Are you asking why undefined behaviour doesn't have consistent results? http://c-faq.com/ansi/experiment.html
[Bug fortran/54678] second call to get_environment_variable gives valgrind warning with 8-byte integers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54678 --- Comment #3 from Tobias Burnus 2013-01-06 12:43:49 UTC --- Author: burnus Date: Sun Jan 6 12:43:45 2013 New Revision: 194948 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194948 Log: 2013-01-06 Tobias Burnus PR fortran/54678 * intrinsics/env.c (get_environment_variable_i8): Don't use uninitialized variable. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/env.c
[Bug c++/55885] Modulo operator crashes for int and long variables if they have minimal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55885 --- Comment #4 from kwieder at polytechnic dot edu.na 2013-01-06 12:44:42 UTC --- Hi Jonathan, According to the the standard C++ implementation (a % -b) <==> (a % b), therefore (INT_MIN % -1) <==> (INT_MIN %1) == 0 Neither INT_MIN % -1 nor INT_MIN %1 require a division, therefore there should be no undefined behaviour in the first place. Regards, Klaus On Jan 6, 2013, at 2:26 PM, redi at gcc dot gnu.org wrote: --- Comment #3 from Jonathan Wakely 2013-01-06 12:26:13 UTC --- Are you asking why undefined behaviour doesn't have consistent results?
[Bug fortran/54678] second call to get_environment_variable gives valgrind warning with 8-byte integers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54678 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Tobias Burnus 2013-01-06 12:46:16 UTC --- FIXED on the trunk (4.8). Thanks for the report - and sorry for the delay. Thomas: Thanks for the reminder.
[Bug rtl-optimization/55845] [4.8 Regression] 454.calculix miscompares with -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper for test data run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55845
Uros Bizjak changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #9 from Uros Bizjak 2013-01-06 13:23:54
UTC ---
It is try_head_merge_bb that moves unspec_volatile to the wrong place. However,
the core of the problem lies in can_move_insns_accross, which does not
special-case unspec_volatiles.
The untested df-problems.c patch that fixes the failing testcase:
--cut here--
Index: df-problems.c
===
--- df-problems.c (revision 194945)
+++ df-problems.c (working copy)
@@ -3916,6 +3916,10 @@ can_move_insns_across (rtx from, rtx to, rtx acros
break;
if (NONDEBUG_INSN_P (insn))
{
+ /* Do not move unspec_volatile insns. */
+ if (GET_CODE (PATTERN (insn)) == UNSPEC_VOLATILE)
+ break;
+
if (may_trap_or_fault_p (PATTERN (insn))
&& (trapping_insns_in_across || other_branch_live != NULL))
break;
--cut here--
Adding Paolo B. to CC.
[Bug bootstrap/55886] New: gcc/configure.ac problems lead to GCC 4.7.2 not building for x86_64-pc-mingw64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55886 Bug #: 55886 Summary: gcc/configure.ac problems lead to GCC 4.7.2 not building for x86_64-pc-mingw64 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: devuran...@gmx.net gcc/configure.ac contains several checks for mingw hosts, which are tied to mingw32 instead of generic mingw. This might lead to problems when crosscompiling a x86_64-pc-mingw64 compiler. Possibly problematic lines in gcc-4.7.2/gcc/configure.ac: case $host in 1453: *-*-mingw32*) use_cxa_atexit=yes case $host_os in 1656: win32 | pe | cygwin* | mingw32* | uwin*) if test "x$enable_win32_registry" != xno; then [case $target_os in 2565: win32 | pe | cygwin* | mingw32* | uwin*) # Need to check that we generated the correct relocation for the case $target_os in 3604: cygwin* | pe | mingw32* | interix*) # Recent binutils allows the three-operand form of ".comm" on PE. This They should probably use mingw* instead of mingw32*. At least the last one (gcc/configure.ac:3604) is wrong and leads to HAVE_GAS_ALIGNED_COMM being undefined for mingw64, which makes gcc/options.c (autogenerated file) fail to compile: options.c:952:3: error: ‘HAVE_GAS_ALIGNED_COMM’ undeclared here (not in a function) See also: https://bugs.gentoo.org/show_bug.cgi?id=447708
[Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #16 from Tobias Burnus 2013-01-06 14:13:15 UTC --- Close as FIXED (in the 4.7 trunk; hence, in the 4.7.0 release.) The fix was committed on 2011-04-29 for the trunk (i.e. 4.7). As there was no activity for almost two years and as it is no regression, I don't think we will ever port it back to 4.6.
[Bug fortran/55887] New: [OOP][F2008] ICE with CLASS and data-target pointer association in (default) initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887 Bug #: 55887 Summary: [OOP][F2008] ICE with CLASS and data-target pointer association in (default) initialization Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Blocks: 45290, 51076 Follow up to PR 55763 comment 14/15. For CLASS(t) and CLASS(*), gfortran ICEs for pointer default initializers/ initializers which point to a data target instead of NULL. Example: type t end type t type(t), target :: x class(*), pointer :: ptr2 => x if (same_type_as (ptr2, x) .neqv. .TRUE.) call abort() end That's a Fortran 2008 feature. (Cf. also PR51076, PR45290 and PR50410 comment 9.)
[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #15 from Tobias Burnus 2013-01-06 14:56:34 UTC --- For another test case - using CLASS(*) - see PR 55763 comment 0 (last example); see also the analysis to that example in PR 55763 comment 6.
[Bug libstdc++/55594] [4.8 Regression] -Wa,-nH incorrectly added to compile line of all targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55594 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek 2013-01-06 15:10:01 UTC --- So, can we restrict the -Wa,-nH check to *-*-solaris*, or do also say -Wa,-V or whatever with Solaris as prints version and scan its output?
[Bug tree-optimization/55888] New: ICE in in bitmap_set_replace_value, at tree-ssa-pre.c:867
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55888 Bug #: 55888 Summary: ICE in in bitmap_set_replace_value, at tree-ssa-pre.c:867 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com Using gcc version 4.8.0 20130106 (experimental) [trunk revision 194948] (GCC) $ ./xgcc -B. -O2 ~/ice.i -m32 -c /home/ryan/ice.i: In function ‘protobuf_c_message_pack’: /home/ryan/ice.i:103:1: internal compiler error: in bitmap_set_replace_value, at tree-ssa-pre.c:867 protobuf_c_message_pack (const ProtobufCMessage * message, uint8_t * out) ^ 0xa0644b bitmap_set_replace_value ../../gcc/tree-ssa-pre.c:867 0xa0644b bitmap_value_replace_in_set ../../gcc/tree-ssa-pre.c:887 0xa0771a phi_translate_set ../../gcc/tree-ssa-pre.c:1821 0xa0822d defer_or_phi_translate_block ../../gcc/tree-ssa-pre.c:2116 0xa0822d compute_antic_aux ../../gcc/tree-ssa-pre.c:2178 0xa0822d compute_antic ../../gcc/tree-ssa-pre.c:2495 0xa0b679 do_pre ../../gcc/tree-ssa-pre.c:4723 0xa0b679 do_pre ../../gcc/tree-ssa-pre.c:4693 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. Looks like it was introduced at rev194906 http://gcc.gnu.org/viewcvs?view=revision&revision=194906
[Bug tree-optimization/55888] ICE in in bitmap_set_replace_value, at tree-ssa-pre.c:867
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55888 --- Comment #1 from Ryan Mansfield 2013-01-06 15:17:56 UTC --- Created attachment 29088 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29088 preprocessed src Preprocessed source
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 --- Comment #21 from Tobias Burnus 2013-01-06 15:33:24 UTC --- (In reply to comment #6) > To the last test case of comment 0: I mentioned this example in the array-descriptor/subpointer PR 40737 to make sure it is not forgotten. (In reply to comment #14) > The following valid code gives an ICE: > class(*), pointer :: ptr2 => x That's now PR 55887. For the diagnostic part, see patch http://gcc.gnu.org/ml/fortran/2013-01/msg00025.html (In reply to comment #19) > Great! I extended the example from comment #10 to find: > class(myobj) :: this > select type (this) > type is (integer) Thanks for reporting the ICE on invalid code; I submitted a patch for this at http://gcc.gnu.org/ml/fortran/2013-01/msg00046.html
[Bug libstdc++/55594] [4.8 Regression] -Wa,-nH incorrectly added to compile line of all targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55594 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-01-06 15:42:03 UTC --- > --- Comment #4 from Jakub Jelinek 2013-01-06 > 15:10:01 UTC --- > So, can we restrict the -Wa,-nH check to *-*-solaris*, or do also say -Wa,-V > or whatever with Solaris as prints version and scan its output? I plan to restrict the check to Solaris. I'll try to come up with something later today. Rainer
[Bug fortran/45836] [OOP] Type Bound Procedure Error - Type Mismatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45836 --- Comment #3 from Mikael Morin 2013-01-06 15:50:23 UTC --- Author: mikael Date: Sun Jan 6 15:50:09 2013 New Revision: 194949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194949 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/use_23.f90 trunk/gcc/testsuite/gfortran.dg/use_24.f90 trunk/gcc/testsuite/gfortran.dg/use_25.f90 trunk/gcc/testsuite/gfortran.dg/use_26.f90 trunk/gcc/testsuite/gfortran.dg/use_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769 --- Comment #36 from Mikael Morin 2013-01-06 15:50:19 UTC --- Author: mikael Date: Sun Jan 6 15:50:09 2013 New Revision: 194949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194949 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/use_23.f90 trunk/gcc/testsuite/gfortran.dg/use_24.f90 trunk/gcc/testsuite/gfortran.dg/use_25.f90 trunk/gcc/testsuite/gfortran.dg/use_26.f90 trunk/gcc/testsuite/gfortran.dg/use_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/45900] [OOP] Static TBP resolved incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45900 --- Comment #4 from Mikael Morin 2013-01-06 15:50:24 UTC --- Author: mikael Date: Sun Jan 6 15:50:09 2013 New Revision: 194949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194949 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/use_23.f90 trunk/gcc/testsuite/gfortran.dg/use_24.f90 trunk/gcc/testsuite/gfortran.dg/use_25.f90 trunk/gcc/testsuite/gfortran.dg/use_26.f90 trunk/gcc/testsuite/gfortran.dg/use_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55845] [4.8 Regression] 454.calculix miscompares with -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper for test data run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55845 Uros Bizjak changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-01/msg00252.htm ||l --- Comment #10 from Uros Bizjak 2013-01-06 15:50:49 UTC --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00252.html
[Bug tree-optimization/55888] [4.8 regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:867
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55888 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-06 CC||ebotcazou at gcc dot ||gnu.org Version|unknown |4.8.0 Target Milestone|--- |4.8.0 Summary|ICE in in |[4.8 regression] ICE in |bitmap_set_replace_value, |bitmap_set_replace_value, |at tree-ssa-pre.c:867 |at tree-ssa-pre.c:867 Ever Confirmed|0 |1 Severity|normal |major --- Comment #2 from Eric Botcazou 2013-01-06 17:59:31 UTC --- I have it on SQLite.
[Bug fortran/55618] [4.6/4.7/4.8 Regression] Failures with ISO_Varying_String test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55618
--- Comment #4 from Paul Thomas 2013-01-06 18:48:07
UTC ---
Created attachment 29089
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29089
modified version of one of the failing tests
Confirmed
This is a failure of the scalarizer, which is why I have bumped up its
importance.
The final invocation of SPLIT, from within a scalarizer loop, is passing the
character argument CHAR(set) as a pointer to a pointer.
Replacing this call with one to a contained function foo (see attachment),
results in success for 'choice' 0 or 2 (explicit loop or passing VST, rather
than character)
subroutine foo (choice)
integer :: choice
if (choice == 1) then
CALL SPLIT(strar,wrdar,CHAR(set),separ)
else if (choice == 2) then
CALL SPLIT(strar,wrdar,set,separ)
else
DO i=1,ndim
DO j=1,ndim
CALL SPLIT(strar(i,j),wrdar(i,j),CHAR(set),separ(i,j))
end do
end do
end if
end subroutine
The code produced by this appears below and is the reason for my assertion that
this is a scalarizer problem. I suspect from inspection that VST30/31 fail for
the same reason.
I have added Mikael in copy, hoping that his more recent exposure to the
scalarizer will help identify the root cause more quickly.
Cheers
Paul
foo (integer(kind=4) & restrict choice)
{
if (*choice == 1)
{
{
character(kind=1)[1:MAX_EXPR ] * D.2020;
void * restrict D.2018;
integer(kind=4) D.2017;
character(kind=1)[1:MAX_EXPR ] * pstr.26;
integer(kind=4) D.2015;
struct varying_string * D.2014;
D.2014 = &set;
D.2015 = len_ (D.2014);
D.2017 = MAX_EXPR * 64;
D.2018 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
D.2017, 1>);
pstr.26 = (character(kind=1)[1:MAX_EXPR ] *) D.2018;
char_auto (pstr.26, MAX_EXPR , D.2014);
D.2020 = pstr.26;
{
integer(kind=8) S.27;
S.27 = 1;
while (1)
{
if (S.27 > 2) goto L.10;
{
integer(kind=8) D.2025;
integer(kind=8) D.2024;
integer(kind=8) D.2023;
integer(kind=8) S.28;
D.2023 = S.27 * 2 + -3;
D.2024 = S.27 * 2 + -3;
D.2025 = S.27 * 2 + -3;
S.28 = 1;
while (1)
{
if (S.28 > 2) goto L.9;
split_ch (&strar[S.28 + D.2023], &wrdar[S.28 + D.2024],
&D.2020, &separ[S.28 + D.2025], 0B, MAX_EXPR );
S.28 = S.28 + 1;
}
L.9:;
}
S.27 = S.27 + 1;
}
L.10:;
}
{
void * D.2019;
D.2019 = (void *) pstr.26;
if (D.2019 != 0B)
{
__builtin_free (D.2019);
}
}
}
}
else
{
if (*choice == 2)
{
{
struct varying_string D.2029;
D.2029 = set;
{
integer(kind=8) S.29;
S.29 = 1;
while (1)
{
if (S.29 > 2) goto L.12;
{
integer(kind=8) D.2034;
integer(kind=8) D.2033;
integer(kind=8) D.2032;
integer(kind=8) S.30;
D.2032 = S.29 * 2 + -3;
D.2033 = S.29 * 2 + -3;
D.2034 = S.29 * 2 + -3;
S.30 = 1;
while (1)
{
if (S.30 > 2) goto L.11;
split_vs (&strar[S.30 + D.2032], &wrdar[S.30 + D.2033],
&D.2029, &separ[S.30 + D.2034], 0B);
S.30 = S.30 + 1;
}
L.11:;
}
S.29 = S.29 + 1;
}
L.12:;
}
}
}
else
{
i = 1;
if (i <= 2)
{
while (1)
{
{
logical(kind=4) D.2049;
j = 1;
if (j <= 2)
{
while (1)
{
{
logical(kind=4) D.2048;
{
void * restrict D.2046;
integer(kind=4) D.2045;
character(kind=1)[1:MAX_EXPR ] *
pstr.31;
integer(kind=4) D.2043;
struct varying_string * D.2042;
D.2
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #10 from Jerry DeLisle 2013-01-06 18:51:07 UTC --- This bug appears to be unrelated to the other two namelist bugs. It is related to not seeing the ending '/' marker. I have more testing to go before submitting a patch. The initial fix is to catch it in the do loop inside list_read.c at about line 2812. I still need to confirm if the reads are actually correct.
[Bug middle-end/55889] New: [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 Bug #: 55889 Summary: [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org An ICE has appeared for target POWER when compiling testsuite/gcc.dg/tree-prof/pr50907.c $ /tmp/20130104/gcc/xgcc -B/tmp/20130104/gcc/ /nasfarm/dje/src/src/gcc/testsuite/gcc.dg/tree-prof/pr50907.c -fno-diagnostics-show-caret -O -freorder-blocks-and-partition -fschedule-insns -fselective-scheduling -fpic -pthread -fprofile-generate -D_PROFILE_GENERATE -lm -o /tmp/20130104/gcc/testsuite/gcc/pr50907.x01 /nasfarm/dje/src/src/gcc/testsuite/gcc.dg/tree-prof/pr45354.c: In function 'test_ifelse2': /nasfarm/dje/src/src/gcc/testsuite/gcc.dg/tree-prof/pr45354.c:23:1: internal compiler error: in move_op_ascend, at sel-sched.c:6153
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 David Edelsohn changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2013-01-06 Ever Confirmed|0 |1 Target Milestone|--- |4.8.0 --- Comment #1 from David Edelsohn 2013-01-06 18:56:31 UTC --- Confirmed.
[Bug libstdc++/55594] [4.8 Regression] -Wa,-nH incorrectly added to compile line of all targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55594 --- Comment #6 from Rainer Orth 2013-01-06 20:23:40 UTC --- Created attachment 29090 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29090 proposed patch David, could you please try the attached patch? I've tested it so far with c++-only bootstraps on x86_64-unknown-linux-gnu (verifying that the -nH test is gone from libstdc++-v3 config.log and HWCAP_FLAGS is empty) and i386-pc-solaris2.10 with Sun as (where the -nH test is performed and HWCAP_FLAGS is set as expected). Sorry it took me so long to get back to this. Rainer
[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig 2013-01-06 20:56:20 UTC --- The problem is that gfc_get_sym_tree is asked to get "size", but that is not available in the current namespace. The ICE goes away if "intrinsic:: size" is added. We could simply remove the assert, but that would be a bad idea in case the user specifies something called "size" for something else. So, we need to generate a different name, like in the frontend optimization pass, where we use __internal_foo for an intrinsic named foo.
[Bug fortran/55618] [4.6/4.7/4.8 Regression] Failures with ISO_Varying_String test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55618 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-06 AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #5 from Paul Thomas 2013-01-06 21:12:31 UTC --- Created attachment 29091 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29091 Tentative patch for the PR This appears to do the job. It fixes all the iso_varying_string failures and regtests. I will have to develop a suitable testcase, check all the side wrinkles and find out where the bug was introduced. Should be able to submit tomorrow night. Paul
[Bug c/55890] New: calling a builtin func through a cast triggers an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55890
Bug #: 55890
Summary: calling a builtin func through a cast triggers an ICE
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vap...@gentoo.org
Target: x86_64-linux-gnu
$ cat test.i
extern void *memmove(void *, void *, long unsigned int);
typedef int (*_TEST_fun_) ();
static _TEST_fun_ i = (_TEST_fun_) memmove;
main() { i(); }
$ gcc-4.7.2 -O1 -c test.i
test.i: In function ‘main’:
test.i:4:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852
--- Comment #6 from Thomas Koenig 2013-01-06
21:59:13 UTC ---
This patch works (not regression-tested yet), but the method
using the state variable seems hackish and error-prone.
What do you think?
Index: expr.c
===
--- expr.c (Revision 194850)
+++ expr.c (Arbeitskopie)
@@ -4623,7 +4623,8 @@
want to add arguments but with a NULL-expression. */
gfc_expr*
-gfc_build_intrinsic_call (const char* name, locus where, unsigned numarg, ...)
+gfc_build_intrinsic_call (const char* name, const char *symtree_name,
+ locus where, unsigned numarg, ...)
{
gfc_expr* result;
gfc_actual_arglist* atail;
@@ -4641,11 +4642,17 @@
result->value.function.name = name;
result->value.function.isym = isym;
- result->symtree = gfc_find_symtree (gfc_current_ns->sym_root, name);
- gcc_assert (result->symtree
- && (result->symtree->n.sym->attr.flavor == FL_PROCEDURE
- || result->symtree->n.sym->attr.flavor == FL_UNKNOWN));
+ if (symtree_name == NULL)
+{
+ result->symtree = gfc_find_symtree (gfc_current_ns->sym_root, name);
+ gcc_assert (result->symtree &&
+ (result->symtree->n.sym->attr.flavor == FL_PROCEDURE
+ || result->symtree->n.sym->attr.flavor == FL_UNKNOWN));
+}
+ else
+gfc_get_sym_tree (symtree_name, gfc_current_ns, &result->symtree, true);
+
va_start (ap, numarg);
atail = NULL;
for (i = 0; i < numarg; ++i)
Index: simplify.c
===
--- simplify.c (Revision 194850)
+++ simplify.c (Arbeitskopie)
@@ -33,6 +33,7 @@
gfc_expr gfc_bad_expr;
+bool artificial_call = false;
/* Note that 'simplification' is not just transforming expressions.
For functions that are not simplified at compile time, range
@@ -3248,7 +3249,10 @@
gfc_expr* dim = result;
mpz_set_si (dim->value.integer, d);
+ artificial_call = true;
result = gfc_simplify_size (array, dim, kind);
+ artificial_call = false;
+
gfc_free_expr (dim);
if (!result)
goto returnNull;
@@ -5512,7 +5516,10 @@
{
mpz_set_ui (e->value.integer, n + 1);
+ artificial_call = true;
f = gfc_simplify_size (source, e, NULL);
+ artificial_call = false;
+
gfc_free_expr (e);
if (f == NULL)
{
@@ -5584,11 +5591,18 @@
/* Otherwise, we build a new SIZE call. This is hopefully at least
simpler than the original one. */
if (!simplified)
- simplified = gfc_build_intrinsic_call ("size", array->where, 3,
- gfc_copy_expr (replacement),
- gfc_copy_expr (dim),
- gfc_copy_expr (kind));
+ {
+ const char *symtree_name;
+ if (artificial_call)
+ symtree_name = "__internal_size";
+ else
+ symtree_name = NULL;
+ simplified = gfc_build_intrinsic_call ("size", symtree_name,
array->where, 3,
+gfc_copy_expr (replacement),
+gfc_copy_expr (dim),
+gfc_copy_expr (kind));
+ }
return simplified;
}
Index: gfortran.h
===
--- gfortran.h (Revision 194850)
+++ gfortran.h (Arbeitskopie)
@@ -2797,7 +2797,8 @@
bool gfc_has_ultimate_allocatable (gfc_expr *);
bool gfc_has_ultimate_pointer (gfc_expr *);
-gfc_expr* gfc_build_intrinsic_call (const char*, locus, unsigned, ...);
+gfc_expr* gfc_build_intrinsic_call (const char*, const char *, locus,
+ unsigned, ...);
gfc_try gfc_check_vardef_context (gfc_expr*, bool, bool, bool, const char*);
[Bug libstdc++/55872] Crash issue with RTLD_DEEPBIND usage with stdc++ library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55872 --- Comment #3 from Yogesh Gaur 2013-01-07 00:12:26 UTC --- (In reply to comment #2) > GCC 4.4 is no longer maintained or supported. > > Unles you can reproduce the problem with a current release of GCC (which I > can't) then nothing is going to happen. > Hello Jonathan, I tried on GCC 4.6.4 also and still getting this issue on there, I didn't have any more latest copy of GCC with me. > N.B. compiling main.cpp with -fPIC seems to fix the problem anyway. Can you please explain that why it should work with -fPIE, I am able to work it using -fPIE while making my executable. Please note that we should never use -fPIC with executable it will break prelink, if Thread Local Storage is used.
[Bug libstdc++/55728] std::bad_function_call has misleading what() result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55728 --- Comment #7 from Jonathan Wakely 2013-01-07 00:50:25 UTC --- Author: redi Date: Mon Jan 7 00:50:16 2013 New Revision: 194958 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194958 Log: PR libstdc++/55847 * src/c++11/shared_ptr.cc (bad_weak_ptr::what()): Correct string. * testsuite/20_util/shared_ptr/cons/weak_ptr_expired.cc: Verify string. PR libstdc++/55728 * include/std/functional (bad_function_call::what()): Declare. * src/c++11/functional.cc (bad_function_call::what()): Define. * config/abi/pre/gnu.ver (bad_function_call::what()): Export. * testsuite/20_util/bad_function_call/what.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/bad_function_call/what.cc - copied, changed from r194957, trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/weak_ptr_expired.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/std/functional trunk/libstdc++-v3/src/c++11/functional.cc trunk/libstdc++-v3/src/c++11/shared_ptr.cc trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/weak_ptr_expired.cc
[Bug libstdc++/55847] mistake bad_weak_ptr::what() message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55847 --- Comment #1 from Jonathan Wakely 2013-01-07 00:50:23 UTC --- Author: redi Date: Mon Jan 7 00:50:16 2013 New Revision: 194958 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194958 Log: PR libstdc++/55847 * src/c++11/shared_ptr.cc (bad_weak_ptr::what()): Correct string. * testsuite/20_util/shared_ptr/cons/weak_ptr_expired.cc: Verify string. PR libstdc++/55728 * include/std/functional (bad_function_call::what()): Declare. * src/c++11/functional.cc (bad_function_call::what()): Define. * config/abi/pre/gnu.ver (bad_function_call::what()): Export. * testsuite/20_util/bad_function_call/what.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/bad_function_call/what.cc - copied, changed from r194957, trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/weak_ptr_expired.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/std/functional trunk/libstdc++-v3/src/c++11/functional.cc trunk/libstdc++-v3/src/c++11/shared_ptr.cc trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/weak_ptr_expired.cc
[Bug libstdc++/55728] std::bad_function_call has misleading what() result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55728 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #8 from Jonathan Wakely 2013-01-07 00:53:26 UTC --- fixed for 4.8
[Bug libstdc++/55847] mistake bad_weak_ptr::what() message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55847 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Jonathan Wakely 2013-01-07 00:53:33 UTC --- fixed for 4.8
[Bug fortran/55891] New: Problem with shared library and EQUIVALENCE on darwin 11.4.2 x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55891 Bug #: 55891 Summary: Problem with shared library and EQUIVALENCE on darwin 11.4.2 x86_64 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: brtn...@hdfgroup.org On a x86_64 system with Darwin Kernel Version 11.4.2, and if you use to compile the programs: gfortran -shared -fPIC mod.f90 -o lib.so gfortran -fPIC main.f90 lib.so The main program does not receive the values from the module (i.e. the print statement will print 0,0). It works if you use a static library. main.f90: PROGRAM main USE LIB2 IMPLICIT NONE CALL f() PRINT*,i,j END PROGRAM main mod.f90: MODULE LIB2 INTEGER i INTEGER :: j EQUIVALENCE (j, i) CONTAINS SUBROUTINE f() IMPLICIT NONE j = 40 END SUBROUTINE f END MODULE LIB2 nm lib.so 0f9a T ___lib2_MOD_f 0f94 t __dyld_func_lookup 1010 S _lib2.eq.0_ U dyld_stub_binder 0f80 t dyld_stub_binding_helper
[Bug c++/53900] [regression] Too optimistic on a alignment assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900 --- Comment #6 from Andrew Pinski 2013-01-07 04:25:38 UTC --- > __attribute__((aligned(16))) float array[4]; Explicitly says the array is aligned to 16 bytes which means it is undefined by the C/C++ standard what happens if you a pointer to the struct which contains this array. As this pointer will always be aligned by definition of the struct (and any other use of it is undefined), then by definition std::ptrdiff_t(array) will always have the lower 8bits be zero.
[Bug c/55892] New: Bogus compiler warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55892 Bug #: 55892 Summary: Bogus compiler warning Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: sworddrag...@aol.com Created attachment 29092 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29092 Example code In the attachments is the example file for this bug report. Compiling it with "gcc -O3 -Wall -Wextra -o /dev/null -pedantic test.c" will result in a warning: In file included from /usr/include/stdio.h:937:0, from test.c:2: In function 'fgets', inlined from 'main' at test.c:17:11: /usr/include/x86_64-linux-gnu/bits/stdio2.h:261:2: warning: call to '__fgets_chk_warn' declared with attribute warning: fgets called with bigger size than length of destination buffer [enabled by default] There are 2 potential errors on this behavior: - If the warning triggers on line 33 it should also be triggered on all 4 lines. - In this code the limit of fgets can never exceed a length of 8. The compiler thinks because read_limit can be 2147483647 (INT32_MAX) limit in fgets can it be too (which as already said can never happen in this code). Removing the 3 lines which assign INT32_MAX removes the compiler warning. I have a suggestion for a solution: - Like conditional return values the compiler could check if the code has a fixed construct which makes it possible to calculate if the limit will be exceeded (this would match on the example code and trigger no compiler warnings). If the code has a dynamic construct which makes it not possible to calculate if the limit would be exceeded a comiler warning is thrown.
[Bug c++/55893] New: C++11: runtime segfault with static const object with virtual destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55893 Bug #: 55893 Summary: C++11: runtime segfault with static const object with virtual destructor Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: f.heckenb...@fh-soft.de Created attachment 29093 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29093 Test case
[Bug c++/55893] C++11: runtime segfault with static const object with virtual destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55893 --- Comment #1 from Frank Heckenbach 2013-01-07 07:21:01 UTC --- Submitted to early. Here's the description: The attached test case segfault at runtime: % g++-4.7 -std=c++11 bug.cpp && ./a.out Segmentation fault As far as I can see, that's because tmp is allocated in read-only storage, but the destructor tries to write to it to update the vtable pointer. It only happens in C++11 mode.
[Bug c/55892] Bogus compiler warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55892 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2013-01-07 07:34:25 UTC --- First off you also need -D_FORTIFY_SOURCE and a newish glibc headers. Second I think this warning is correct. Take a line which is 16 characters long. The first time at beginning of the loop, limit: 8; readlimit: 8. The next time, limit:0 readlimit: 0. The next time limit: (unsigned long)(-8) readlimit: INT32_MAX Warn because readlimit > 1024. The reason why the first call to fgetsl does not warn is because it does not get inlined as it is not hot. The second is also the same reason as the first but also the code for fgets cannot figure out the size of the variable, buffer. The last has the same issue as second minus the inline issue. The trunk gives a very good warning message of the point of the inline function happens too: In file included from /usr/include/stdio.h:910:0, from t67.c:2: In function ‘fgets’, inlined from ‘fgetsl.constprop.0’ at t67.c:17:11, inlined from ‘main’ at t67.c:33:14: /usr/include/bits/stdio2.h:253:2: warning: call to ‘__fgets_chk_warn’ declared with attribute warning: fgets called with bigger size than length of destination buffer [enabled by default] return __fgets_chk_warn (__s, __bos (__s), __n, __stream); ^
[Bug c++/55893] C++11: runtime segfault with static const object with virtual destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55893 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-07 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2013-01-07 07:40:21 UTC --- Confirmed, also fails on the trunk. .section.rodata .align 8 .type_ZZ4mainE3tmp, @object .size_ZZ4mainE3tmp, 8 _ZZ4mainE3tmp: .quad_ZTV3foo+16 .weak_ZTI3foo
