[Bug target/55461] _mm_loadu_si128 generates wrong instruction on 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55461 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-11-25 08:59:13 UTC --- This is by design, movups is one byte shorter than movupd.
[Bug c++/55405] ICE with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55405 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 2012-11-25 11:11:35 UTC --- The ICE at -O3 was first silenced for 4.7 by r171450: http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00874.html, when Richard Biener added an FRE pass after early SRA. At that point the ICE still occurs with -O3 -fno-tree-fre. The ICE at -O3 -fno-tree-fre was then silenced for 4.7 by r181014: http://gcc.gnu.org/ml/gcc-cvs/2011-11/msg00300.html, a missed-optimization patch. The ICE before r181014 occurs because except.c:emit_to_new_bb_before is called on an insn whose BLOCK_FOR_INSN is NULL, but that NULL pointer is unconditionally dereferenced causing a SEGV. I don't see a sane way of handling that locally.
[Bug tree-optimization/55405] ICE with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55405 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Component|c++ |tree-optimization --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-25 11:31:50 UTC --- Ok, let's change the Component to something more sensible, anyway.
[Bug libquadmath/55462] New: [4.8 Regression] FAIL: gfortran.dg/quad_2.f90 -O* execution test after revision 193770
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55462 Bug #: 55462 Summary: [4.8 Regression] FAIL: gfortran.dg/quad_2.f90 -O* execution test after revision 193770 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: bur...@gcc.gnu.org, h...@gcc.gnu.org After revision 193770, the test gfortran.dg/quad_2.f90 fails at runtime. As shown by the following reduced test, this is due to a difference between the last ULP for read and write. program test_qp use iso_fortran_env, only: real_kinds implicit none integer, parameter :: QP = real_kinds(ubound(real_kinds,dim=1)) real(qp) :: fp2, fp4 character(len=80) :: str4 fp2 = sqrt (2.0_qp) write (str4,'(g0)') fp2 read (str4, *) fp4 print *, fp2, fp4, (fp4-fp2)/epsilon(fp2) if (fp2 /= fp4) call abort() end program test_qp The output is 1.41421356237309504880168872420969798 1.41421356237309504880168872420969779 -1.000
[Bug libstdc++/55463] New: Result of std::mem_fn doesn't accept rvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55463
Bug #: 55463
Summary: Result of std::mem_fn doesn't accept rvalues
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lucdan...@free.fr
Created attachment 28769
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28769
Reproducible testcase
$ g++-snapshot --version
g++-snapshot (Debian 20120915-1) 4.8.0 20120915 (experimental) [trunk revision
191353
The following program doesn't compile:
#include functional
#include memory
// or can be std::unique_ptr as well
templatetypename T using Ptr = std::unique_ptrT;
struct foo { void bar() {} };
int main()
{
Ptrfoo p { new foo };
// This is fine
std::mem_fn(foo::bar)(p);
// This isn't
std::mem_fn(foo::bar)(std::move(p));
}
As far as I can tell, that's because _Mem_fn_Res (_Class::*)(_ArgTypes...)
has an operator() that only accepts _Tp for smart pointers.
[Bug libstdc++/55463] Result of std::mem_fn doesn't accept rvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55463
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-11-25
AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.8.0
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-25
13:45:14 UTC ---
This also fails:
std::mem_fn(foo::bar)( foo{} );
The fix is pretty simple.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #29 from Janne Blomqvist jb at gcc dot gnu.org 2012-11-25 15:08:24 UTC --- (In reply to comment #28) (In reply to comment #27) (In reply to comment #26) Is this caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=180701 ? Maybe we need to remember if we have a special file after all, or just ignore the error on the truncate. IMHO the correct fix is to not seek and/or truncate the file unless the Fortran semantics require it; that way libgfortran does not need to care whether the file is special or not. As explained in #c23, special files are special in different ways (also different on different OS'es), and trying to enumerate all the ways in which they are special is bound to fail. I think Tobias comment #c24 pinpoints the place which needs to be fixed, but unfortunately I haven't had time to look into it. Well, we need to make sure that the (very basic) program program main character*10 x open(10,file=foo.dat) write (10,'(A)') '' write (10,'(A)') '' close (10) open(10,file=foo.dat) write (10,'(A)') '' close (10) open(10,file=foo.dat) 100 continue read (10,'(A)',end=200) x write (*,'(A)') x goto 100 200 continue close(10,status=delete) end continues to work as expected: That probably means truncating on close and rewind. I'm not sure about truncation being necessary here, actually. Where we do need to truncate is 1) Following a write in access='sequential' mode, when we are not at the end of the file (that is, we have opened an existing file and are at the beginning, we have previously used rewind/backspace or such). This might also apply to formatted writes in access='stream' mode, need to check the standard. 2) Executing an ENDFILE statement. 3) Opening a file with status='replace' (actually, probably not, as a sensible implementation would be to open() with O_TRUNC instead of a separate ftruncate() call following open(), and while I'm too lazy to look it up right now I'm quite sure this is exactly what we already do) I think the current code goes wrong with pipes because as they are reported to be of size 0, it is undefined whether we're at the beginning, middle, or end of the file, and hence we have made some arbitrary choice, and hit_eof() think's we're not at the end, and tries to truncate. Perhaps we need something more sophisticated such as some need_to_truncate_after_next_write flag which is set and tested at appropriate places..
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-25 AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Janne Blomqvist jb at gcc dot gnu.org 2012-11-25 15:10:07 UTC --- I have a patch, just need to clean it up a bit and test.
[Bug rtl-optimization/55464] New: lra chooses alternatives with empty register classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55464 Bug #: 55464 Summary: lra chooses alternatives with empty register classes Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org lra chooses instruction alternatives with empty register classes, which causes it to reload the reload over and over again, till it eventually bails out with: conftest.c:7:2: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
[Bug rtl-optimization/55464] lra chooses alternatives with empty register classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55464 --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-25 15:15:41 UTC --- Created attachment 28770 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28770 Synopsys Designware ARC port
[Bug rtl-optimization/55464] lra chooses alternatives with empty register classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55464 --- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-25 15:17:09 UTC --- Created attachment 28771 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28771 Synopsys Designware ARC port configuration
[Bug rtl-optimization/55464] lra chooses alternatives with empty register classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55464 --- Comment #3 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-25 15:21:15 UTC --- Created attachment 28772 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28772 testcase options used were: -fpreprocessed conftest.i -quiet -dumpbase conftest.c -mcpu=ARC600 -auxbase conftest -version -fexceptions -o conftest.s
[Bug rtl-optimization/55464] lra chooses alternatives with empty register classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55464 --- Comment #4 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-25 15:37:49 UTC --- (In reply to comment #1) Created attachment 28770 [details] Synopsys Designware ARC port Without the patch for the TARGET_ADJUST_INSN_LENGTH / TARGET_INSN_LENGTH_PARAMETERS hooks, you neeed to change the #if 0 in arc.c:7680 to #if 1
[Bug lto/55284] [4.8 Regression] ICE in read_cgraph_and_symbols, at lto/lto.c:2944 (when -MMD is passed)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55284 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug libquadmath/55462] [4.8 Regression] FAIL: gfortran.dg/quad_2.f90 -O* execution test after revision 193770
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55462 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55395 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/55381] [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55381 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/55276] [4.8 regression] ppc: callee-saved vector registers not preserved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55276 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/55438] [4.8 Regression]: tmpdir-gcc.dg-struct-layout-1/t001 - t028, gcc.c-torture/execute/991118-1.c, gcc.c-torture/execute/bf64-1.c, ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55438 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/55127] [4.8 regression] Incorrect dependent scope error with partial specialization of non-type parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55127 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug other/54691] [4.8 Regression] --enable-checking=valgrind doesn't build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54691 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug rtl-optimization/55458] [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1212 with -fPIC -m32 and simple asm volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55458 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug other/54814] [4.8 Regression] ICE: unable to find a register to spill in class 'R0_REG'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54814 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/54699] [4.8 Regression] [SH] gfortran.dg/class_array_9.f03 ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54699 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c/55273] [4.8.0 regression] ICE in iv_number_of_iterations, at loop-iv.c:2819
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55273 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug debug/54731] [4.8 regression] arm-elf/arm-eabisim crosses fails in make-check due to undefined LFE references: corrupt debug_line tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54731 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/55433] [4.8 Regression] ICE on excessive reloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55433 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/55172] [4.7/4.8 Regression] [OOP] ICE on invalid: gfc_variable_attr(): Bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55172 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3
[Bug libstdc++/55043] [4.7/4.8 Regression] issue with nesting unordered_map containing unique_ptr into vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55043 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3
[Bug c++/54744] [4.7/4.8 Regression] internal compiler error: Segmentation fault, by dependent base, member typedef and ctor-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54744 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3
[Bug other/55181] [4.7/4.8 Regression] Expensive shift loop where a bit-testing instruction could be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3
[Bug c++/54801] [4.7/4.8 Regression] static variables constructed with lambda params inside member functions cause undefined errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54801 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3
[Bug tree-optimization/55286] [4.7/4.8 Regression] Bytemark ASSIGNMENT 4% - 10% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55286 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3
[Bug c/54896] [4.7/4.8 Regression] Some optimization slowness with GCC 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54896 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3
[Bug target/55171] [4.7/4.8 Regression] incorrect virtual thunk on mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55171 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3
[Bug fortran/54940] [4.6/4.7/4.8 Regression] ICE in gfc_build_intrinsic_call, at fortran/expr.c:4609
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54940 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug target/55033] [4.6/4.7/4.8 Regression] PowerPC section type conflict error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug fortran/54730] [4.6/4.7/4.8 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54730 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug fortran/30146] Redefining do-variable in excecution cycle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-25 17:24:14 UTC --- Author: tkoenig Date: Sun Nov 25 17:24:09 2012 New Revision: 193793 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193793 Log: 2012-11-25 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/30146 * frontend-passes.c (doloop_warn): New function. (doloop_list): New static variable. (doloop_size): New static variable. (doloop_level): New static variable. (gfc_run_passes): Call doloop_warn. (doloop_code): New function. (doloop_function): New function. (gfc_code_walker): Keep track of DO level. 2012-11-25 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/30146 * gfortran.dg/do_check_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/do_check_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug lto/54795] [4.8 Regression] LTO miscompiled external array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Component|bootstrap |lto --- Comment #22 from H.J. Lu hjl.tools at gmail dot com 2012-11-25 17:55:21 UTC --- This is caused by revision 191466: http://gcc.gnu.org/ml/gcc-cvs/2012-09/msg00623.html
[Bug target/55461] _mm_loadu_si128 generates wrong instruction on 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55461 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2012-11-25 18:07:49 UTC --- That's a design not matching the hardware then -- read up on reformatting penalties. Also the way the rule in the md file is written it more looks like a bug to me. It seems to try to figure out the right type, and it works most of the time, just sometimes it fails.
[Bug target/55454] [PPC] unaligned memory accesses do not work correctly for vector extensions when using altivec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55454 --- Comment #2 from Siarhei Siamashka siarhei.siamashka at gmail dot com 2012-11-25 18:18:16 UTC --- (In reply to comment #1) Besides from whether the testcase is valid According to http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html packed - This attribute, attached to struct or union type definition, specifies that each member (other than zero-width bit-fields) of the structure or union is placed to minimize the memory required. When attached to an enum definition, it indicates that the smallest integral type should be used. Is it safe to assume that the size of this foo struct is always expected to be 17 bytes in the testcase? If yes, then it must be safe to use any alignment for this struct because an array of foo will have elements with addresses at any possible alignments. As such, any memory location can be safely casted to foo* and used. Is there anything wrong with these assumptions? But in fact what I want is just to somehow tell gcc that I'm going to write this vector data type at an unaligned memory location. For example, x86 SSE2 and ARM NEON have unaligned load/store instructions. PPC Altivec can't do it easily, but that's a headache for GCC and the application developer (me) should not care. After all, if running out of options, one can always use memcpy(buffer + 10, a, sizeof(*a)); instead of ((foo *)(buffer + 9))-data = *a; The performance goes down the toilet though. Which would be in fact an acceptable solution for PPC, but x86 and ARM can definitely do much better. 4.8 should do a better job here. Thanks, I'll check GCC 4.8 a bit later.
[Bug fortran/55465] New: Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 Bug #: 55465 Summary: Name collision in C binding (calling C from Fortran) Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fmarti...@gmv.com The following compile error is generated. Maybe not a bug but is passes through the Intel compiler and I cannot see the reason why it would not compile. Essentially I am trying to use the binding to call from Fortran the same C function in two different ways. The interface sql_set_env_attr has two implementations, one sql_set_env_attr_int where the parameter value is passed as c_int and another one sql_set_env_attr_ptr where the parameter value is passed as c_ptr. In any case the message is somewhat misleading as it identifies the name of the binding SQLSetEnvAttr as global body and as interface body. Compilation diagnostics follow: m_odbc_if.f90:168.4: function sql_set_env_attr_ptr( input_handle, 1 m_odbc_if.f90:153.4: function sql_set_env_attr_int( input_handle, 2 Error: Binding label 'SQLSetEnvAttr' in interface body at (1) collides with the global entity 'SQLSetEnvAttr' at (2) make: *** [/home/fmmf/pulsar/Linux/Debug/obj/m_odbc_if.o] Error 1
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 --- Comment #1 from Fran Martinez Fadrique fmartinez at gmv dot com 2012-11-25 18:19:56 UTC --- Created attachment 28773 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28773 Supporting file to compile the main source for the report
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 --- Comment #2 from Fran Martinez Fadrique fmartinez at gmv dot com 2012-11-25 18:21:36 UTC --- Created attachment 28774 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28774 The main file where the problem is encountered
[Bug fortran/30146] Redefining do-variable in excecution cycle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution||FIXED --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-25 18:29:00 UTC --- I think this can be counted as fixed with the addition of -fcheck=do and the recent fixes for INTENT(OUT) and INTENT(INOUT) dummy arguments. Please reopen if you think othrwise.
[Bug target/55461] _mm_loadu_si128 generates wrong instruction on 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55461 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-11-25 18:48:25 UTC --- (In reply to comment #2) That's a design not matching the hardware then -- read up on reformatting penalties. Also the way the rule in the md file is written it more looks like a bug to me. It seems to try to figure out the right type, and it works most of the time, just sometimes it fails. You are right, there is a bug in the way TARGET_SSE_TYPELESS_STORES due to recent load/store split, but it doesn't change the fact that -Os forces movups. Do not use -Os if you care about performance.
[Bug target/55461] _mm_loadu_si128 generates wrong instruction on 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55461 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org 2012-11-25 19:15:36 UTC --- Ok fair enough. Yes -O2 seems to DTRT. The penalty for doing this can be large on some older CPUs of course. I chose -Os because -O2 made a mess out of the loop. Just one more on my list to avoid -Os.
[Bug target/55454] [PPC] unaligned memory accesses do not work correctly for vector extensions when using altivec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55454 --- Comment #3 from Siarhei Siamashka siarhei.siamashka at gmail dot com 2012-11-25 19:32:02 UTC --- Also fails with GCC trunk (gcc version 4.8.0 20120518 (experimental)) The disassembly listing for init_buffer function: init_buffer: 0:7d 80 42 a6 mfvrsave r12 4:94 21 ff e0 stwur1,-32(r1) 8:91 81 00 1c stw r12,28(r1) c:65 8c 80 00 orisr12,r12,32768 10:7d 80 43 a6 mtvrsave r12 14:3d 40 00 00 lis r10,0 18:7c 00 18 ce lvx v0,r0,r3 1c:39 20 00 0a li r9,10 20:39 4a 00 00 addir10,r10,0 24:7c 0a 49 ce stvxv0,r10,r9 Here it happily tries to use STVX instruction. And using this instruction just silently aligns the address down to 16 byte boundary, effectively doing the write at buffer[0] instead of buffer[10]. 28:81 81 00 1c lwz r12,28(r1) 2c:7d 80 43 a6 mtvrsave r12 30:38 21 00 20 addir1,r1,32 34:4e 80 00 20 blr And by the way, the memcpy workaround mentioned above is also broken in GCC 4.8, because it tries to be clever and generates exactly the same code relying on STVX :) With GCC 4.7.2, at least memcpy variant used to work correctly: init_buffer: 0:3d 40 00 00 lis r10,0 4:80 a3 00 00 lwz r5,0(r3) 8:80 c3 00 04 lwz r6,4(r3) c:80 e3 00 08 lwz r7,8(r3) 10:39 2a 00 0a addir9,r10,10 14:81 03 00 0c lwz r8,12(r3) 18:90 aa 00 0a stw r5,10(r10) 1c:90 c9 00 04 stw r6,4(r9) 20:90 e9 00 08 stw r7,8(r9) 24:91 09 00 0c stw r8,12(r9) 28:4e 80 00 20 blr
[Bug testsuite/55429] new UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55429 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-25 19:57:28 UTC --- I suspect this issue existed from the original commit of... r193445 | jason | 2012-11-12 12:51:26 -0500 (Mon, 12 Nov 2012) | 1 line * include/std/complex (real, imag): Add ABI tag in C++11 mode. which introduced the 26_numerics/complex/abi_tag.cc testcase. This particular commit is difficult to test on darwin because it occurred while the darwin bootstrap was broken from the introduction of libsanitizer.
[Bug libquadmath/55462] [4.8 Regression] FAIL: gfortran.dg/quad_2.f90 -O* execution test after revision 193770
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55462 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-25 19:59:11 UTC --- Author: burnus Date: Sun Nov 25 19:59:07 2012 New Revision: 193796 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193796 Log: 2012-11-25 Tobias Burnus bur...@net-b.de PR libquadmath/55462 * strtod/strtod_l.c (round_and_return): Use HAVE_FENV_H instead of nonexisting HAVE_GET_ROUNDING_MODE. Modified: trunk/libquadmath/ChangeLog trunk/libquadmath/strtod/strtod_l.c
[Bug libquadmath/55462] [4.8 Regression] FAIL: gfortran.dg/quad_2.f90 -O* execution test after revision 193770
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55462 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-25 20:02:46 UTC --- FIXED. At least on systems which have fenv.h and thus fegetround(). If they don't one might end up using - for READ - round to zero/round down instead of round nearest which was use for WRITE.
[Bug c++/55460] Template-dependent name is not looked up at instantiation point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55460 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-25 20:46:06 UTC --- Andrew is right, the standard says: In an expression of the form: postfix-expression ( expression-listopt) where the postfix-expression is an unqualified-id, the unqualified-id denotes a dependent name if [...] Since my::filter is not an unqualified-id it is not a dependent name, so the usual lookup rules apply and only names declared before the template definition can be found.
[Bug testsuite/55429] new UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55429
--- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-25
20:57:08 UTC ---
Looking at this on current gcc trunk under x86_64-apple-darwin12 using...
cd darwin_objdir/x86_64-apple-darwin11.4.2/libstdc++-v3
make -k check RUNTESTFLAGS=--debug
I see in dbg.log...
PASS: 26_numerics/complex/51083.cc execution test
extra_tool_flags are:
-std=c++11
Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/g++
-shared-libgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc
-nostdinc++
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/libstdc++-v3/src
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/libstdc++-v3/src/.libs
-B/sw/lib/gcc4.8/x86_64-apple-darwin11.4.2/bin/
-B/sw/lib/gcc4.8/x86_64-apple-darwin11.4.2/lib/ -isystem
/sw/lib/gcc4.8/x86_64-apple-darwin11.4.2/include -isystem
/sw/lib/gcc4.8/x86_64-apple-darwin11.4.2/sys-include
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-g -O2 -DLOCALEDIR=. -nostdinc++
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/libstdc++-v3/include/x86_64-apple-darwin11.4.2
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/libstdc++-v3/include
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121124/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121124/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121124/libstdc++-v3/testsuite/util
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121124/libstdc++-v3/testsuite/26_numerics/complex/abi_tag.cc
-std=c++11 -S -o abi_tag.s(timeout = 600)
spawn /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/g++
-shared-libgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc
-nostdinc++
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/libstdc++-v3/src
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/libstdc++-v3/src/.libs
-B/sw/lib/gcc4.8/x86_64-apple-darwin11.4.2/bin/
-B/sw/lib/gcc4.8/x86_64-apple-darwin11.4.2/lib/ -isystem
/sw/lib/gcc4.8/x86_64-apple-darwin11.4.2/include -isystem
/sw/lib/gcc4.8/x86_64-apple-darwin11.4.2/sys-include
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-g -O2 -DLOCALEDIR=. -nostdinc++
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/libstdc++-v3/include/x86_64-apple-darwin11.4.2
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/libstdc++-v3/include
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121124/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121124/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121124/libstdc++-v3/testsuite/util
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121124/libstdc++-v3/testsuite/26_numerics/complex/abi_tag.cc
-std=c++11 -S -o abi_tag.s^M
using master pty /dev/ptyp0
parent: waiting for sync byte^M
parent: telling child to go ahead^M
parent: now unsynchronized from child^M
spawn: returns {77330}^M
^M
expect: does (spawn_id exp7) match regular expression .+? no^M
expect: read eof^M
expect: set expect_out(spawn_id) exp7^M
expect: set expect_out(buffer) ^M
PASS: 26_numerics/complex/abi_tag.cc (test for excess errors)
20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist
UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler
_ZNKSt7complexIfE4realB5cxx11Ev
20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist
UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler
_ZNKSt7complexIdE4realB5cxx11Ev
20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist
UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler
_ZNKSt7complexI[eg]E4realB5cxx11Ev
20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist
UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler
_ZNKSt7complexIiE4realB5cxx11Ev
20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist
UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler
_ZNKSt7complexIfE4imagB5cxx11Ev
20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist
UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler
_ZNKSt7complexIdE4imagB5cxx11Ev
20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist
UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler
[Bug middle-end/55381] [4.8 Regression]: build fails on cris-elf building libgfortran with host-gcc-4.4, ICE compiling matmul_i1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55381 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #10 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-25 21:01:27 UTC --- (In reply to comment #9) Revision r193667 seems to have fixed this, not unexpectedly. ...so I just went ahead and closed this PR.
[Bug target/55454] [PPC] unaligned memory accesses do not work correctly for vector extensions when using altivec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55454 --- Comment #4 from Siarhei Siamashka siarhei.siamashka at gmail dot com 2012-11-25 21:16:53 UTC --- (In reply to comment #3) Also fails with GCC trunk (gcc version 4.8.0 20120518 (experimental)) ^^ Sorry, I accidentally compiled GCC from the stale old directory. The recent trunk 4.8.0 20121120 (experimental) has memcpy issue fixed. Still the STVX problem is there: init_buffer: 0:7c 00 18 ce lvx v0,r0,r3 4:3d 40 00 00 lis r10,0 8:39 20 00 0a li r9,10 c:39 4a 00 00 addir10,r10,0 10:7c 0a 49 ce stvxv0,r10,r9 14:4e 80 00 20 blr
[Bug other/54691] [4.8 Regression] --enable-checking=valgrind doesn't build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54691 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2012-11-25 22:15:22 UTC --- This patch: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01973.html works.
[Bug lto/54795] [4.8 Regression] LTO miscompiled external array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 --- Comment #23 from H.J. Lu hjl.tools at gmail dot com 2012-11-25 22:36:48 UTC --- Another problem with revision 191466 is we lost debug info on cl_options. With revision 191465, I got (gdb) whatis cl_options type = const struct cl_option [1221] (gdb) After revision 191466, I got (gdb) whatis cl_option type = cl_option (gdb)
[Bug lto/54795] [4.8 Regression] LTO miscompiled external array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 --- Comment #24 from H.J. Lu hjl.tools at gmail dot com 2012-11-25 22:39:57 UTC --- (In reply to comment #23) Another problem with revision 191466 is we lost debug info on cl_options. With revision 191465, I got (gdb) whatis cl_options type = const struct cl_option [1221] (gdb) After revision 191466, I got (gdb) whatis cl_option type = cl_option (gdb) It was (gdb) whatis cl_options type = data variable, no debug info (gdb) whatis cl_enums type = data variable, no debug info (gdb) whatis cl_enums_count type = data variable, no debug info (gdb)
[Bug lto/55466] New: [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466 Bug #: 55466 Summary: [4.8 Regression] Revision 191466 destroyed DWARF debug info Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: hubi...@gcc.gnu.org On Linux/x86-64, after revision 191466: http://gcc.gnu.org/ml/gcc-cvs/2012-09/msg00623.html GCC configured with --enable-bootstrap --with-build-config=bootstrap-lto lost debug info on data: gnu-mic-2:pts/4[441] gdb gcc/cc1 GNU gdb (GDB) 7.5.50.20121119-cvs Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /export/project/git/gcc-regression-bootstrap/master/191466/bld/gcc/cc1...done. (gdb) whatis global_options type = data variable, no debug info (gdb) whatis cl_options type = data variable, no debug info (gdb) whatis cl_enums type = data variable, no debug info (gdb) whatis cl_enums_count type = data variable, no debug info (gdb) whatis global_options_set type = data variable, no debug info (gdb) whatis sched_max_luid type = data variable, no debug info (gdb)
[Bug debug/55467] New: Wrong value for optimized debug, variants of gcc.dg/guality/pr36728-1.c and gcc.dg/guality/pr36728-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 Bug #: 55467 Summary: Wrong value for optimized debug, variants of gcc.dg/guality/pr36728-1.c and gcc.dg/guality/pr36728-2.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org While adjusting gcc.dg/guality/pr36728-1.c and -2.c for PR55030 (as suggested in http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01542.html), the test-cases started to fail with the wrong kind of failure: the gdb session showed wrong values instead of values being optimized-out, which is the expected fallback for shortcomings in gcc related to optimization and debug. Attached will be two such variants; I hope a single PR is sufficient for the both of them.
[Bug debug/55467] Wrong value for optimized debug, variants of gcc.dg/guality/pr36728-1.c and gcc.dg/guality/pr36728-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-26 00:30:10 UTC --- Created attachment 28775 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28775 gcc.dg/guality/pr55467-2.c Here's pr55467-2.c, a variant of gcc.dg/guality/pr36728-2.c, actually gcc.dg/guality/pr36728-2.c with the patch from http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01542.html. It fails at least at r193349, r193583 and r193777 as follows (well, for the two first mentioned, you'll see ERROR as explained and fixed in http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01998.html): Running /home/hp/gcctop/tmp/nbasg/gcc/gcc/testsuite/gcc.dg/guality/guality.exp ... FAIL: gcc.dg/guality/pr55467-2.c -O2 line 14 y == 2 FAIL: gcc.dg/guality/pr55467-2.c -O3 -fomit-frame-pointer line 14 y == 2 FAIL: gcc.dg/guality/pr55467-2.c -O3 -g line 14 y == 2 FAIL: gcc.dg/guality/pr55467-2.c -Os line 14 y == 2 FAIL: gcc.dg/guality/pr55467-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 14 y == 2 FAIL: gcc.dg/guality/pr55467-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 14 y == 2 In gcc.log, you'll see that gdb reads some different value, like 0, 1, or -23360.
[Bug debug/55467] Wrong value for optimized debug, variants of gcc.dg/guality/pr36728-1.c and gcc.dg/guality/pr36728-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-linux --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-26 00:31:28 UTC --- Right, target is x86_64-linux with -m32 or i686-linux.
[Bug lto/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P3 Last reconfirmed|2012-03-21 00:00:00 |2012-11-24 0:00 Component|middle-end |lto Version|4.8.0 |4.7.2 Target Milestone|4.8.0 |3.0.x
[Bug ada/52110] s-osinte.ads:447:09: clockid_t conflicts with declaration at line 194
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |3.3.1 --- Comment #9 from John David Anglin danglin at gcc dot gnu.org 2012-11-26 00:47:46 UTC --- Forgot about this... Retested recently and pragma Volatile caused a compilation issue. Plan to commit the patch add-hpux10-patch.txt if there are no additional suggestions.
[Bug debug/55467] Wrong value for optimized debug, variants of gcc.dg/guality/pr36728-1.c and gcc.dg/guality/pr36728-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467 --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-26 01:01:08 UTC --- Created attachment 28776 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28776 gcc.dg/guality/pr55467-1.c Here's pr55467-1.c, another variant of gcc.dg/guality/pr36728-2.c which *also* fails at least at r193349, r193583 and r193777 as follows, both with *and* without -m32. The only difference to pr55467-2.c is that x[0] isn't used after the second asm (in which it is an input and output operand). The problem is that x[0] is displayed as 0 rather than 25 or optimized out. Running /home/hp/gcctop/tmp/nbasg/gcc/gcc/testsuite/gcc.dg/guality/guality.exp ... FAIL: gcc.dg/guality/pr55467-1.c -O1 line 14 *x == (char) 25 FAIL: gcc.dg/guality/pr55467-1.c -O2 line 14 *x == (char) 25 FAIL: gcc.dg/guality/pr55467-1.c -O3 -fomit-frame-pointer line 14 *x == (char) 25 FAIL: gcc.dg/guality/pr55467-1.c -O3 -g line 14 *x == (char) 25 FAIL: gcc.dg/guality/pr55467-1.c -Os line 14 *x == (char) 25 FAIL: gcc.dg/guality/pr55467-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 14 *x == (char) 25 FAIL: gcc.dg/guality/pr55467-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 14 *x == (char) 25
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results)::function(std::functionvoid (std::__regex::_Patte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #25 from David Edelsohn dje at gcc dot gnu.org 2012-11-26 02:50:22 UTC --- The instantiations definitely should be in libstdc++-v3/src/c++11/regex.cc in the GCC 4.7 release branch.
[Bug middle-end/55030] [4.8 Regression]: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os (et al)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55030 --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-26 03:22:19 UTC --- Author: hp Date: Mon Nov 26 03:22:15 2012 New Revision: 193802 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193802 Log: PR middle-end/55030 * builtins.c (expand_builtin_setjmp_receiver): Update comment regarding purpose of blockage. * emit-rtl.c [!HAVE_blockage] (gen_blockage): Similarly for the head comment. * rtlanal.c (volatile_insn_p): Ditto. * doc/md.texi (blockage): Update similarly. Change wording to require one of two forms, rather than implying a wider choice. * cse.c (cse_insn): Where checking for blocking insns, use volatile_insn_p instead of manual check for volatile ASM. * dse.c (scan_insn): Ditto. * cselib.c (cselib_process_insn): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/cse.c trunk/gcc/cselib.c trunk/gcc/doc/md.texi trunk/gcc/dse.c trunk/gcc/emit-rtl.c trunk/gcc/rtlanal.c
[Bug middle-end/55030] [4.8 Regression]: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os (et al)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55030 --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-26 03:26:00 UTC --- Author: hp Date: Mon Nov 26 03:25:57 2012 New Revision: 193803 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193803 Log: PR middle-end/55030 * gcc.dg/guality/pr36728-1.c, gcc.dg/guality/pr36728-2.c (foo): Don't use volatile asms, use plain asms. Where the output value for the asm is unused, write a global variable. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/guality/pr36728-1.c trunk/gcc/testsuite/gcc.dg/guality/pr36728-2.c
[Bug c/53662] Cannot build static gcc on i686 linux gnu with -m64 support.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53662 Leif Leonhardy bugfeed at online dot de changed: What|Removed |Added CC||bugfeed at online dot de --- Comment #4 from Leif Leonhardy bugfeed at online dot de 2012-11-26 04:01:07 UTC --- (In reply to comment #2) (In reply to comment #1) That means you need a 64-bit capable binutils. Just a guess, but you might need to use --target=x86_64-unknown-linux-gnu to make a cross compiler for x86_64, which will be multilib-capable by default. To do that you'll need a 64-bit binutils and 64-bit glibc. This should really be dealt with on the gcc-help mailing list, I don't think it's a bug. Sorry, I meant that this might be bug in gcc bootstrap stage. As I said, I have compiled binutils with --enable-multilib ... I could try --enable-64-bit-bfd tough. That's not what you /could try/, that's what you *have to* do... ;-) I.e., configure binutils with '--enable-64-bit-bfd --enable-targets=all' (e.g.), otherwise the built 'gas' bails out on '--64'. -leif P.S.: I'm currently trying to build a multilib GCC 4.7.2 on a Pentium4 (a.k.a. i786), i.e., x86 system. Build goes fine until libquadmath's 'configure' tries to *run* executables built with '-m64' (which of courseTM cannot work). No idea why it's attempting that -- probably because host==build==target==pentium4-linux-gnu and it doesn't notice that we're cross-compiling in the 64/ directory. The other libs built just fine (e.g. libssp).
[Bug c++/55468] New: Label value to incorrect destination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55468 Bug #: 55468 Summary: Label value to incorrect destination Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: martin.gira...@gmail.com This is a case of a label pointing to the wrong line. It is clear from looking at the disassembly that the value of said label is bogus. Look around line 31452. The sigtrap label points to line 31458. Instead, the sigtrap label gives the address of line 31448, four lines above instead of six lines below. In the disassembly, one can see a movl instruction writing the address as a function argument onto the stack, and said address is unmistakably the WSTOPSIG macro four lines prior. As a result, the executable loops indefinitely upon reaching this area, whereas it should be skipping the next block instead.
[Bug c++/55468] Label value to incorrect destination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55468 --- Comment #1 from martin.girard5 at gmail dot com 2012-11-26 06:29:52 UTC --- Created attachment 28777 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28777 The preprocessed output
[Bug c/55428] -mms-bitfields hides -mno-align-double option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55428 --- Comment #3 from Andreas Kasberger kasberger at heidenhain dot de 2012-11-26 06:38:28 UTC --- It is not working with gcc 4.6.2 or 4.7. I tried an old compiler gcc 3.4.3 and the behavior was correct(In reply to comment #1) Possibly related to PR52991 (-mms-bitfields breaks attribute((packed))). I tested both versions as well and same behavior I tried an old compiler gcc 3.4.3 and the behavior was correct.
[Bug c++/55468] Label value to incorrect destination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55468 --- Comment #2 from martin.girard5 at gmail dot com 2012-11-26 06:39:35 UTC --- COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.7.2 20120920 [gcc-4_7-branch revision 191568] (SUSE Linux) COLLECT_GCC_OPTIONS='-o' 'test' '-v' '-save-temps' '-std=c++11' '-I' '../include' '-march=pentium4' '-mtune=native' '-mfpmath=sse' '-m32' '-static-libgcc' '-Wno-invalid-offsetof' '-Wno-overflow' '-Wno-pointer-arith' '-Wno-unused-function' '-Wno-attributes' '-fno-threadsafe-statics'
[Bug c/55428] -mms-bitfields hides -mno-align-double option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55428 --- Comment #4 from Andreas Kasberger kasberger at heidenhain dot de 2012-11-26 07:21:51 UTC --- (In reply to comment #2) Hmm, it seems that for ms-bitfields the default-field-alignment overrides all field-local alignments. I wouldn't assume that __attribute__((packed)) is directly related to this issue, but of course it is close to it. For the packed-case the issue seems to be that it isn't used for the fields, but for the last element in struct/union. Btw the testcase works nice, if you use in front a #pragma pack(4). I was also noticing the option f-pack-struct=4 will let the example running fine. Hmmthe option -mno-align-double is doing the alignment on one word boundary (In reply to comment #3) It is not working with gcc 4.6.2 or 4.7. I tried an old compiler gcc 3.4.3 and the behavior was correct(In reply to comment #1) Possibly related to PR52991 (-mms-bitfields breaks attribute((packed))). I tested both versions as well and same behavior I tried an old compiler gcc 3.4.3 and the behavior was correct. (In reply to comment #2) Hmm, it seems that for ms-bitfields the default-field-alignment overrides all field-local alignments. I wouldn't assume that __attribute__((packed)) is directly related to this issue, but of course it is close to it. For the packed-case the issue seems to be that it isn't used for the fields, but for the last element in struct/union. Btw the testcase works nice, if you use in front a #pragma pack(4). Yes, you are are right. I noticed that a -fpack-struct=4 doing it correctly. Hmm... -mno-align-double documentation says -malign-double -mno-align-double Control whether GCC aligns double, long double, and long long variables on a two word boundary or a one word boundary. Aligning double variables on a two word boundary will produce code that runs somewhat faster on a Pentium at the expense of more memory. So what I understand is that -mno-align-double will do the boundary on one word boundary. -fpack-struct=4 documentation says -fpack-struct[=n] Without a value specified, pack all structure members together without holes. When a value is specified (which must be a small power of two), pack structure members according to this value, representing the maximum alignment (that is, objects with default alignment requirements larger than this are output potentially unaligned at the next fitting location. In this case this would mean I would do the alignment on a double word boundary. The ms compiler option /zp4 will also do the alignment on double word boundary. documentation: The command-line option /Zp (Struct Member Alignment) sets the packsize to n, in which n can be 1, 2, 4, 8, or 16, and in which 8 is the default. Now I'm totally confused. I will try to find out more and come back
[Bug fortran/55469] New: memory leak on read with istat.ne.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469 Bug #: 55469 Summary: memory leak on read with istat.ne.0 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch The following testcase leads to memory leaks with gfortran 4.5/4.6/4.7/4.8 (as found by valgrind) 4.1 seems not to leak (but has a couple of warnings). REAL :: z INTEGER :: istat CHARACTER(LEN=3) :: t t=NVE READ (UNIT=t,FMT=*,IOSTAT=istat) z END note that istat.NE.0 in this case. ==37422== 300 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==37422==at 0x4A057F4: calloc (vg_replace_malloc.c:593) ==37422==by 0x4C298FF: _gfortrani_xcalloc (memory.c:56) ==37422==by 0x4CE2A82: l_push_char.isra.2 (list_read.c:641) ==37422==by 0x4CE3223: read_real (list_read.c:1634) ==37422==by 0x4CE504E: _gfortrani_list_formatted_read (list_read.c:1895)
