[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631 --- Comment #17 from Igor Zamyatin izamyatin at gmail dot com 2012-12-10 08:02:54 UTC --- (In reply to comment #15) But, double checking dwarf2out.c reveals that we could indeed emit the notes after BARRIER instead if there is any. So I'm leaning towards this patch. Atom bootstrap is ok with this patch
[Bug fortran/55636] [4.8 Regression] Fortran name mangling collides with user namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-10 08:12:39 UTC --- See thread starting at http://gcc.gnu.org/ml/fortran/2012-10/msg6.html
[Bug fortran/55636] [4.8 Regression] Fortran name mangling collides with user namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-10 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 08:38:08 UTC --- P1 as it is a build failure.
[Bug libfortran/55601] libgfortran build fails with --disable-libquadmath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55601 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-10 08:41:36 UTC --- Hmm, seemingly, the check ignores --disable-libquadmath-support by only testing for C's __float support, cf. libgfortran/acinclude.m4's LIBGFOR_CHECK_FLOAT128. gfortran itself is checked via libgfortran/acinclude.m4's LIBGFOR_WORKING_GFORTRAN. One probably should augment the C test by a Fortran REAL(16) test. Additionally, one could directly honour --disable-libquadmath-support, which I think is also passed to libgfortran's configure. Regarding the --disable-libquadmath combined with --enable-libquadmath-support: Some warning would be useful, but the question is how to trigger it.
[Bug tree-optimization/55629] Missed value numbering to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55629 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 08:50:12 UTC --- I know that there is a duplicate of this bug, at least for a simpler testcase ... but I can't find it right now. The issue is that SCCVN does not do PHI-translation, that is, bb 2: if (c_3(D) != 0) goto bb 3; else goto bb 4; bb 3: a_4 = 3; b_5 = 2; goto bb 5; bb 4: a_6 = 2; b_7 = 3; bb 5: # a_1 = PHI 3(3), 2(4) # b_2 = PHI 2(3), 3(4) _8 = a_1 + b_2; SCCVN would need to lookup a_1 and b_2 on both incoming edges when it tries to simplify a_1 + b_2, match up the results and if equal register the simplification. I'm not sure that handling this case (which would certainly be possible) is worth the cost it has on all expressions that do _not_ simplify that way. (of course we can see whether the value-numbers for a_1/b_2 do have has_constants set). Time for a value-number missed-optimization meta bug, there are quite some special cases that we do not handle.
[Bug fortran/55636] [4.8 Regression] Fortran name mangling collides with user namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636 --- Comment #3 from janus at gcc dot gnu.org 2012-12-10 08:51:19 UTC --- A patch was posted here: http://gcc.gnu.org/ml/fortran/2012-10/msg00028.html
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-10 08:57:04 UTC --- Can you pin-point which version causes the regression? BIT_SIZE(m) is (correctly) 64 while ma is (wrongly) 0. And NOT returns the bitwise Boolean inverse of I. Can you run the following code? It matches the failing code but contains some debugging printout. Can you also try kind=4? That seems to work while kind=8 seems to fail. integer(kind=8) m, ma ma = 0 m = 0 print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma m = not(m) print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma do while ( (m.ne.0) .and. (ma.lt.127) ) ma = ma + 1 m = ishft(m,-1) print '(m =,i21,z17,, ma=,i2,z13)', m, m, ma, ma end do print *, BIT_SIZE(m), ma if (BIT_SIZE(m) /= ma) error stop end
[Bug c++/55635] Deallocation function (operator delete) not called when destructor throws exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55635 --- Comment #2 from Kerrek SB joedoefawnbuck at googlemail dot com 2012-12-10 09:08:46 UTC --- Interesting, thank you! The bug remains, however, both with -std=c++11 and noexcept(false), and with -std=c++98 and throw(int). Also, with noexcept(false) GCC will *not* call terminate()...
[Bug c++/55635] Deallocation function (operator delete) not called when destructor throws exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55635 --- Comment #3 from Kerrek SB joedoefawnbuck at googlemail dot com 2012-12-10 09:10:25 UTC --- (Sorry, I meant *without* noexcept(false).)
[Bug target/55146] jumptables with byte entries produce wrong code with -Os/-O2 for SH-1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55146 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2012-12-10 09:15:15 UTC --- (In reply to comment #0) Created attachment 28580 [details] testcase C file Switch statement with enough cases inside is translated to jumptable. If the offsets are small enough, byte entries are used. If there is odd number of cases this implies padding byte (since all SH instructions are 2 byte wide). In the corner case this padding byte can cause the offset to switch from positive to negative since move.b instruction used to fetch jumptable entry sign extends the byte. This bug is very old and dates back at least to 4.0.3 days. See attachment. When compiled with sh-elf-gcc -Os -c test-jens.c -o sh-test.o it produces wrong jumping code. http://pastebin.com/ZgJK3bgS has slightly commented disassembly to point out what I mean. The workaround is to decrease MIN_OFFSET by one for byte case in gcc/config/sh/sh.h . This is not a proper fix though. Thanks for reporting this. Could you please attach the file that you had on pastebin? The link seems dead.
[Bug fortran/55636] [4.8 Regression] Fortran name mangling collides with user namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10
09:39:31 UTC ---
It could use something similar to what tree-emutls.c uses:
+#if !defined (NO_DOT_IN_LABEL)
+# define GFC_STRING_LENGTH_SEPARATOR .
+#elif !defined (NO_DOLLAR_IN_LABEL)
+# define GFC_STRING_LENGTH_SEPARATOR $
+#else
+# define GFC_STRING_LENGTH_SEPARATOR _
+#endif
- if (sym-module)
+ if (sym-attr.save || sym-ns-proc_name-attr.flavor == FL_MODULE)
+{
+ if (sym-module)
+name = gfc_get_string (_F GFC_STRING_LENGTH_SEPARATOR
%s_MOD_%s, sym-module, sym-name);
+ else
+name = gfc_get_string (_F GFC_STRING_LENGTH_SEPARATOR %s,
sym-name);
+}
+ else if (sym-module)
[Bug target/55634] ARM: gcc vector extensions: storing vector to unaligned memory location does not use VST1.8 NEON instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55634 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 09:40:59 UTC --- Issue with the movmisalign instructions. They seem to take only a limited set of modes, in particular not the mode that is requested.
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.8.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 09:42:58 UTC --- If only -Os fails then it's (liekly) not a frontend issue. Leaving P3 for the moment.
[Bug middle-end/55630] [4.8 Regression] FAIL: g++.dg/pr48660.C -std=c++98 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55630 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1 Target Milestone|--- |4.8.0
[Bug c++/55624] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55624 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 09:44:34 UTC --- (In reply to comment #2) gcc: internal compiler error: Killed (program cc1plus) Also means the program was killed by the kernel because out of memory. And -DBOOST_SPIRIT_THREADSAFE hints at the usual incredibly memory-hungry spirit... Get more memory.
[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 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-10 09:45:45 UTC --- Reduced test case: module m implicit none type t character :: str(11) end type t interface char module procedure char_auto end interface char contains pure function char_auto (string) result (char_string) type(t), intent(in) :: string character(LEN=size(string%str)) :: char_string integer :: i_char forall(i_char = 1:size(string%str)) char_string(i_char:i_char) = string%str(i_char) end forall end function char_auto elemental subroutine split_CH (string, set) type(t), intent(inout) :: string character(LEN=*), intent(in):: set integer :: i do i = 1, min(len(set),size(string%str)) string%str(i) = set(i:i) end do end subroutine split_CH end module m use m type(t) :: mdt, mdt2(2),setdt mdt%str = ['H', 'e', 'l', 'l', 'o', ' ', 'W','o', 'r', 'l', 'd'] mdt2 = [ mdt, mdt ] setdt%str = ['F', 'o', 'r', 't', 'r', 'a', 'n','R', 'u', 'l', 'z'] call split_CH(mdt2, char(setdt)) print '(11a)', mdt2(1)%str print '(11a)', mdt2(2)%str if (any (mdt2(1)%str /= setdt%str)) call abort () if (any (mdt2(2)%str /= setdt%str)) call abort () end
[Bug middle-end/55623] [ARM] GCC should not prefer long dependency chains, they inhibit performance on superscalar processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55623 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 09:47:42 UTC --- You can also adjust --param tree-reassoc-width or have the target implement the sched.reassociation_width target hook (for the default).
[Bug tree-optimization/55107] [4.7/4.8 Regression] GCC in an infinite loop in PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55107
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10
09:50:51 UTC ---
Mine. We don't stop insertion:
Starting insert iteration 3362
Found partial redundancy for expression {nop_expr,d_33} (0024)
Skipping insertion of phi for partial redundancy: Looks like an induction
variable
Inserted pretmp_3451 = (unsigned short) d_25;
in predecessor 19
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Starting insert iteration 3363
Found partial redundancy for expression {nop_expr,d_33} (0024)
Skipping insertion of phi for partial redundancy: Looks like an induction
variable
Inserted pretmp_3452 = (unsigned short) d_25;
in predecessor 19
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Found fully redundant value
Starting insert iteration 3364
Found partial redundancy for expression {nop_expr,d_33} (0024)
...
[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55619 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 --- Comment #32 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 09:53:13 UTC --- Author: ktietz Date: Mon Dec 10 09:53:08 2012 New Revision: 194348 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194348 Log: PR target/53912 * print-tree.c (print_node): Cast from pointer via uintptr_t. Modified: trunk/gcc/ChangeLog trunk/gcc/print-tree.c
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 --- Comment #33 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 09:54:20 UTC --- Author: ktietz Date: Mon Dec 10 09:54:16 2012 New Revision: 194349 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194349 Log: PR target/53912 * print-tree.c (print_node): Cast from pointer via uintptr_t. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/print-tree.c
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 --- Comment #34 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 09:57:06 UTC --- Author: ktietz Date: Mon Dec 10 09:57:02 2012 New Revision: 194350 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194350 Log: PR target/53912 * stmt.c (compute_cases_per_edge): Cast from pointer via intptr_t. (expand_case): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/stmt.c
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #35 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 10:01:24 UTC --- Fixed on trunk and 4.7 branch
[Bug bootstrap/45050] build with --enable-build-with-cxx fails on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45050 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||WORKSFORME --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 10:23:56 UTC --- Can't reproduce this. This looks for me like a broken build-setup. strsignal is part of libiberty, and getpagesize, too.
[Bug c++/55635] Deallocation function (operator delete) not called when destructor throws exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55635 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-10 10:37:29 UTC --- G++ 4.7 doesn't call terminate because it doesn't implement http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1123, but trunk does.
[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55619
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10
10:51:21 UTC ---
From what I can see, the C++ FE always did what it does now, i.e. even in only
m inputs fold the const value into its initializer. GCC up to 3.2 was
supporting pushing constants into constant pool without a warning, 3.3/3.4
emitted a deprecation warning on that
warning: use of memory input without lvalue in asm operand 0 is deprecated
and finally from 4.0 onwards this is a hard error.
In this light, the user inline asm could be considered invalid.
Perhaps the C++ FE could be changed, in finish_asm_stmt:
constraint = TREE_STRING_POINTER (TREE_VALUE (TREE_PURPOSE (t)));
operand = decay_conversion (TREE_VALUE (t), tf_warning_or_error);
/* If the type of the operand hasn't been determined (e.g.,
because it involves an overloaded function), then issue
an error message. There's no context available to
resolve the overloading. */
if (TREE_TYPE (operand) == unknown_type_node)
{
error (type of asm operand %qE could not be determined,
TREE_VALUE (t));
operand = error_mark_node;
}
if (parse_input_constraint (constraint, i, ninputs, noutputs, 0,
oconstraints, allows_mem, allows_reg))
{
/* If the operand is going to end up in memory,
mark it addressable. */
if (!allows_reg allows_mem)
{
/* Strip the nops as we allow this case. FIXME, this really
should be rejected or made deprecated. */
STRIP_NOPS (operand);
if (!cxx_mark_addressable (operand))
operand = error_mark_node;
}
}
else
operand = error_mark_node;
perhaps parse_input_constraint could be done before decay_conversion (and just
remember its return value in a bool), if it returned true and !allows_reg
allows_mem, we would need to use some other *_conversion instead of
decay_conversion that wouldn't fold it into a constant and thus make something
originally potentially addressable into something non-addressable.
No idea what function would that be though. Worst case parse it as if it was
surrounded by implicit and then dereference the result? That could generate
different and less clear diagnostics though.
[Bug rtl-optimization/55092] [4.8 Regression] LRA aggravates var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55092 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10 10:53:50 UTC --- I believe on that testcase it was because without LRA the function didn't use a frame pointer, while with LRA for some reason it does.
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10 10:56:51 UTC --- (In reply to comment #16) Not on Solaris/SPARC, unfortunately: there are still compilations in the libgo testsuite that take more than a day, which with PR go/54507 effectivly breaks unattended Solaris/SPARC bootstraps since they take insanely long. Which exact testcase? Can you pin-point it to a single *.go source file compilation rather than several as the libgo testsuite usually compiles? Can you see what all files would need to be attached to make it reproduceable using cross-compiler from say x86_64-linux? I bet some *.gox files would be needed...
[Bug bootstrap/54128] [4.8 Regression] GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54128 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10 10:57:53 UTC --- Alex, any opinions here?
[Bug c++/49372] Temporaries evaluated for arguments of a default constructors of array elements not destructed properly (?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 11:06:49 UTC --- This testcase seems to produce for trunk, 4.7, and 4.6 the output CCDD, which is proper as constructor of B is called by the array-constructor. Btw you will need option -std=c++11 on trunk to get this test compile without issues.
[Bug bootstrap/53208] build failure on mingw native internal compiler error: Segmentation fau lt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53208 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||WONTFIX --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 11:16:47 UTC --- Sorry gcc version 4.4.x isn't anymore maintained. For more modern gcc versions this issue isn't reproducable.
[Bug libgcj/50895] Build failure in jni.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50895 --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 11:21:04 UTC --- A question about this build-failure. Were you using posix-threading model for 4.6 ?
[Bug target/55014] ICE: Segmentation fault while compiling complex_io.cc on x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55014 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 11:28:43 UTC --- Re-tested this testcase. Seems to be fixed with current trunk. With older revision it failed as described. I close this as worksforme.
[Bug target/38269] Segmentation fault in main_block_label when using -fno-unit-at-a-time and precompiled headers containing inline functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38269 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Known to fail|| --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 11:31:19 UTC --- The 4.3 gcc version is no longer maintained. As this issue was fixed already with 4.4 I close this bug as wontfix
[Bug fortran/55638] New: Wrongly accepts INTENT + VALUE - and wrongly requires it for PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55638 Bug #: 55638 Summary: Wrongly accepts INTENT + VALUE - and wrongly requires it for PURE Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid, rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT (INOUT), INTENT(OUT), POINTER, or VOLATILE attributes. (F2008) C1276 The specification-part of a pure function subprogram shall specify that all its nonpointer dummy data objects have the INTENT (IN) or the VALUE attribute. However, gfortran allows to combine INTENT with VALUE. Additionally, for PURE (and PURE ELEMENTAL) procedures, it even requires the INTENT besides the VALUE. Namely: elemental subroutine foo(x,y) 1 Error: Argument 'y' of elemental procedure 'foo' at (1) must have its INTENT specified elemental subroutine foo(x,y) integer, intent(inout) :: x !integer, VALUE, INTENT(in) :: y integer, VALUE :: y x = y end subroutine 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
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.6.4
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-10
11:43:34 UTC ---
In trans-expr.c's gfc_conv_procedure_call, one calls:
3997else if (se-ss se-ss-info-useflags)
3998 {
...
4007if (ss-dimen 0 e-expr_type == EXPR_VARIABLE
4008 ss-info-data.array.ref == NULL)
...
4016else
4017 gfc_conv_expr_reference (parmse, e);
* * *
Even shorter example. Note the VALUE attribute (cf. PR55638 for the wrong
INTENT(IN)):
integer :: A(3)
call foo(a, f())
print *, a
contains
elemental subroutine foo(x,y)
integer, intent(inout) :: x
integer, VALUE, intent(in) :: y
x = y
end subroutine foo
function f()
integer :: f
f = 42
end function f
end
[Bug preprocessor/55602] Does not generate Error message for redefined macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55602
--- Comment #2 from Jeff Guo guojiufu at gmail dot com 2012-12-10 11:57:57
UTC ---
-pedantic-errors is helpful if the redefined macros not guarded by #pragma GCC
system_header
--a.h --
#pragma GCC system_header
#define A 1
#define A 2
-a.c
#include a.h
int main(){
return A;
}
[Bug preprocessor/55602] Does not generate Error message for redefined macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55602 --- Comment #3 from Jeff Guo guojiufu at gmail dot com 2012-12-10 11:59:07 UTC --- Above case is still no error message reported even with -pedantic-errors
[Bug preprocessor/55602] Does not generate Error message for redefined macros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55602 Jeff Guo guojiufu at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED Resolution|INVALID |WONTFIX --- Comment #4 from Jeff Guo guojiufu at gmail dot com 2012-12-10 12:02:29 UTC --- may GCC report error message for redefined macro if -pedantic-errors specified for system headers?
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10 12:10:41 UTC --- Is this slower compared to pre-r186530 gfortran, or just from the r186530 through 187339? I think before that change on this testcase we've vectorized just 25 loops, not 28 loops as now, and supposedly the loops for which the r187340 change is a problem are only those that weren't vectorized before at all. If the latter, then this wouldn't be a regression. Is there an easy way to detect if peeling could turn a simple_iv vectorized load into non-!simple_iv? Michael, do you plan to work on this?
[Bug tree-optimization/55107] [4.7/4.8 Regression] GCC in an infinite loop in PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55107
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Depends on||55629
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10
12:13:54 UTC ---
The issue is shown by:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 194345)
+++ tree-ssa-pre.c (working copy)
@@ -867,6 +867,8 @@ bitmap_set_replace_value (bitmap_set_t s
return;
}
}
+
+ gcc_unreachable ();
}
that is, we have a value in NEW_SETS,
(gdb) call debug_bitmap_set (set)
debug[0] := { prephitmp_61 (0036), prephitmp_74 (0056), prephitmp_29 (0057),
prephitmp_62 (0046), prephitmp_6 (0047), prephitmp_73 (0029) }
(gdb) p lookfor
$1 = 29
that is not in value_expressions:
0029[0] := { d.7_35 (0029), {nop_expr,d_25} (0029),
{mem_ref0B,addr_expra}@.MEM_36 (0029), prephitmp_83 (0029) }
That happens because we re-set prephitmp_73's value from its original 37
to 29 in do_regular_insertion but do not adjust value_expressions.
In fact,
/* If all edges produce the same value and that value is
an invariant, then the PHI has the same value on all
edges. Note this. */
else if (!cant_insert all_same eprime
(edoubleprime-kind == CONSTANT
|| edoubleprime-kind == NAME)
!value_id_constant_p (val))
{
unsigned int j;
bitmap_iterator bi;
bitmap exprset = value_expressions[val];
unsigned int new_val = get_expr_value_id (edoubleprime);
EXECUTE_IF_SET_IN_BITMAP (exprset, 0, j, bi)
{
pre_expr expr = expression_for_id (j);
if (expr-kind == NAME)
{
vn_ssa_aux_t info = VN_INFO (PRE_EXPR_NAME (expr));
/* Just reset the value id and valnum so it is
the same as the constant we have discovered. */
if (edoubleprime-kind == CONSTANT)
{
info-valnum = PRE_EXPR_CONSTANT (edoubleprime);
pre_stats.constified++;
}
else
info-valnum = VN_INFO (PRE_EXPR_NAME
(edoubleprime))-valnum;
info-value_id = new_val;
}
}
looks like a hack that while adjusting all existing name(!)
expressions for a value it does not adjust bitmap sets. What it seems to
try to do is unify two value-ids after-the-fact.
We cannot get this right this way. We simply have to perform PHI
insertion to merge the values.
The above is a hack around the inability of the value-numbering to handle
this case (see PR55629). But it's not a sustainable solution as this
bug shows ...
I have a patch.
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 --- Comment #5 from rguenther at suse dot de rguenther at suse dot de 2012-12-10 12:26:21 UTC --- On Mon, 10 Dec 2012, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10 12:10:41 UTC --- Is this slower compared to pre-r186530 gfortran, or just from the r186530 through 187339? I think before that change on this testcase we've vectorized just 25 loops, not 28 loops as now, and supposedly the loops for which the r187340 change is a problem are only those that weren't vectorized before at all. If the latter, then this wouldn't be a regression. Is there an easy way to detect if peeling could turn a simple_iv vectorized load into non-!simple_iv? See my this could be done differently now comment - you should be able to re-use the original SCEV result, thus the non-simple_iv case should never pop up late. Richard.
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475 gretay at gcc dot gnu.org changed: What|Removed |Added CC||gretay at gcc dot gnu.org --- Comment #16 from gretay at gcc dot gnu.org 2012-12-10 12:29:02 UTC --- On arm-none-eabi: FAIL-PASS: 25_algorithms/stable_sort/49559.cc (test for excess errors). This test passes now (since 2012-12-07), likely fixed by the patches for PR55395. FAIL-PASS: 20_util/tuple/creation_functions/tie2.cc (test for excess errors) This test has already been fixed before and passing since 2012-11-05. Do these tests also pass on powerpc64-unknown-linux-gnu? Thanks, Greta
[Bug libgcj/50895] Build failure in jni.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50895 --- Comment #5 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2012-12-10 12:32:36 UTC --- (In reply to comment #4) A question about this build-failure. Were you using posix-threading model for 4.6 ? It's been a while, but I believe the 4.6 was normal win32 threading.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-10 12:37:00 UTC --- I'm wondering, is asan not supposed to print out a backtrace with file names and line numbers... right now (trunk of today) I get a trace with just addresses, I somehow have the feeling this was different in an earlier version : gfortran -g -fsanitize=address asan_test.f90 ; ./a.out = ==19529== ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fff503d6a98 at pc 0x400922 bp 0x7fff503d6a60 sp 0x7fff503d6a58 WRITE of size 4 at 0x7fff503d6a98 thread T0 #0 0x400921 (/data/vjoost/gnu/bugs/a.out+0x400921) #1 0x400942 (/data/vjoost/gnu/bugs/a.out+0x400942) #2 0x400978 (/data/vjoost/gnu/bugs/a.out+0x400978) #3 0x351661ecdc (/lib64/libc-2.12.so+0x1ecdc) Address 0x7fff503d6a98 is located at offset 24 in frame test_asan_01 of T0's stack: This frame has 1 object(s): [32, 72) 'a'
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-10 12:43:42 UTC --- Now, compilation seems to go fine, but I'm not figuring out how to do it properly so it works at run time. I have: gfortran -g -fsanitize=thread -fPIE PR55561.f90 ./a.out FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x40 0x7cf0) FATAL: Make sure to compile with -fPIE and to link with -pie. next try yields gfortran -g -fsanitize=thread -fPIC -Wl,-pie PR55561.f90 /data/vjoost/gnu/binutils-2.22/install/bin/ld: error: /usr/lib/../lib64/crt1.o: requires unsupported dynamic reloc 11; recompile with -fPIC /data/vjoost/gnu/binutils-2.22/install/bin/ld: error: /data/vjoost/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtbegin.o: requires dynamic R_X86_64_32 reloc against '__TMC_END__' which may overflow at runtime; recompile with -fPIC Is there something wrong in the way I configured gcc or do I need a different command line ? ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --enable-lto --disable-bootstrap
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 Kostya Serebryany kcc at gcc dot gnu.org changed: What|Removed |Added CC||kcc at gcc dot gnu.org --- Comment #8 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-10 12:45:37 UTC --- Joost: http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#Call_stack
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-10 12:46:56 UTC --- (In reply to comment #7) Now, compilation seems to go fine, but I'm not figuring out how to do it properly so it works at run time. I have: gfortran -g -fsanitize=thread -fPIE PR55561.f90 ./a.out FATAL: ThreadSanitizer can not mmap the shadow memory (something is mapped at 0x40 0x7cf0) FATAL: Make sure to compile with -fPIE and to link with -pie. next try yields gfortran -g -fsanitize=thread -fPIC -Wl,-pie PR55561.f90 Try: gfortran -g -fsanitize=thread -fPIC -pie PR55561.f90 The driver changes the startup files when -pie is passed.
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-10 12:53:22 UTC --- (In reply to comment #8) gfortran -g -fsanitize=thread -fPIC -pie PR55561.f90 Thanks! yields the proper warning as expected.. gfortran -g -fopenmp -fsanitize=thread -fPIC -pie PR55561.f90 ; ./a.out == WARNING: ThreadSanitizer: data race (pid=26592) Read of size 4 at 0x7fff74e67d6c by main thread: #0 MAIN__._omp_fn.0 PR55561.f90:0 (exe+0x0fff) #1 MAIN__ PR55561.f90:0 (exe+0x0e79) #2 main ??:0 (exe+0x0f75) Previous write of size 4 at 0x7fff74e67d6c by thread 1: #0 MAIN__._omp_fn.0 PR55561.f90:0 (exe+0x1020) #1 gomp_thread_start /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:116 (libgomp.so.1+0x8449) Thread 1 (tid=26593, running) created at: #0 pthread_create ??:0 (libtsan.so.0+0x0001be6c) #1 gomp_team_start /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:440 (libgomp.so.1+0x89f5) #2 main ??:0 (exe+0x0f75) ==
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #10 from Dmitry Vyukov dvyukov at google dot com 2012-12-10 12:57:01 UTC --- (In reply to comment #9) (In reply to comment #8) gfortran -g -fsanitize=thread -fPIC -pie PR55561.f90 Thanks! yields the proper warning as expected.. gfortran -g -fopenmp -fsanitize=thread -fPIC -pie PR55561.f90 ; ./a.out == WARNING: ThreadSanitizer: data race (pid=26592) Read of size 4 at 0x7fff74e67d6c by main thread: #0 MAIN__._omp_fn.0 PR55561.f90:0 (exe+0x0fff) #1 MAIN__ PR55561.f90:0 (exe+0x0e79) #2 main ??:0 (exe+0x0f75) Previous write of size 4 at 0x7fff74e67d6c by thread 1: #0 MAIN__._omp_fn.0 PR55561.f90:0 (exe+0x1020) #1 gomp_thread_start /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:116 (libgomp.so.1+0x8449) Thread 1 (tid=26593, running) created at: #0 pthread_create ??:0 (libtsan.so.0+0x0001be6c) #1 gomp_team_start /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:440 (libgomp.so.1+0x89f5) #2 main ??:0 (exe+0x0f75) == Is is a correct report? Or false positive?
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-10 12:59:09 UTC --- (In reply to comment #10) Is is a correct report? Or false positive? This is a correct report for the testcase in comment #0 (as J is shared between threads).
[Bug c++/49372] Temporaries evaluated for arguments of a default constructors of array elements not destructed properly (?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-10 13:14:56 UTC --- Kai, I don't think anyone disputes that B's constructor is called, the question is why 12.2/4 doesn't apply.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-10 13:19:24 UTC --- (In reply to comment #8) Joost: http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#Call_stack No luck, even with -fno-omit-frame-pointer and the python script : rm -f ./a.out ; gfortran -g -O0 -fsanitize=address -fno-omit-frame-pointer asan_test.f90 ; ./a.out | python ./asan_symbolize.py = ==43068== ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fff7a574fb8 at pc 0x400922 bp 0x7fff7a574f80 sp 0x7fff7a574f78 WRITE of size 4 at 0x7fff7a574fb8 thread T0 #0 0x400921 (/data/vjoost/gnu/bugs/a.out+0x400921) #1 0x400942 (/data/vjoost/gnu/bugs/a.out+0x400942) #2 0x400978 (/data/vjoost/gnu/bugs/a.out+0x400978) #3 0x351661ecdc (/lib64/libc-2.12.so+0x1ecdc) Address 0x7fff7a574fb8 is located at offset 24 in frame test_asan_01 of T0's stack: This frame has 1 object(s): [32, 72) 'a' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) Shadow byte and word: 0x1fffef4ae9f7: f1
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #10 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-10 13:20:51 UTC --- ./a.out | python ./asan_symbolize.py It should be ./a.out 21 | python ./asan_symbolize.py
[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds (also seen at -O3 bootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 13:23:17 UTC --- Created attachment 28911 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28911 prototype patch The pattern we have is bb 6: _36 = i_33 + 1; _37 = a[i_33]; a[_36] = _37; i_39 = i_33 + 4294967295; if (i_33 != 0) goto bb 7; else goto bb 11; bb 7: _42 = i_39 + 1; _43 = a[i_39]; a[_42] = _43; and eventually adding an assert in bb7 that i_39 != 1 would help. But the only thing we try to add extra asserts for is stuff in the definition chain of comparison operands ... this OTOH is for stuff that uses comparison operands and live on the edge. Prototype patch attached, fixes comment#8 at least.
[Bug c++/55639] New: Partial nested template specialization leads to segmentation fault of g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55639 Bug #: 55639 Summary: Partial nested template specialization leads to segmentation fault of g++ Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@nopw.de Created attachment 28912 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28912 test case that cause g++ to exit with segmenation fault When I compile the attached C++ file g++ finishes with a segmentation fault. The problem might lie in the partial nested template specialization. If I either remove the surrounding class (and defined the struct in the global namespace) or if I remove the template specialization the error goes away. Compiler version: g++-4.7 (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2 Call: g++-4.7 -Wall -std=c++11 -o test template_specialization.cc
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-10 13:26:31 UTC --- (In reply to comment #10) ./a.out | python ./asan_symbolize.py It should be ./a.out 21 | python ./asan_symbolize.py not good yet, line numbers are 0. Also happens for a C testcase. Also addr2line seems not happy: addr2line -e ./a.out 0x400921 ??:0 gfortran -g -O0 -fsanitize=address -fno-omit-frame-pointer asan_test.f90 ; ./a.out 21 | python ./asan_symbolize.py = ==45957== ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fff9752bdd8 at pc 0x400922 bp 0x7fff9752bda0 sp 0x7fff9752bd98 WRITE of size 4 at 0x7fff9752bdd8 thread T0 #0 0x400921 in test_asan_01_ ??:0 #1 0x400942 in MAIN__ asan_test.f90:0 #2 0x400978 in main ??:0 #3 0x351661ecdc in ?? ??:0 Address 0x7fff9752bdd8 is located at offset 24 in frame test_asan_01 of T0's stack:
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #12 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-10 13:28:12 UTC --- Does pure addr2line work?
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 --- Comment #3 from dave.anglin at bell dot net 2012-12-10 13:31:31 UTC --- On 10-Dec-12, at 3:57 AM, burnus at gcc dot gnu.org wrote: Can you pin-point which version causes the regression? At this point, I onnly know the test didn't fail in early September. BIT_SIZE(m) is (correctly) 64 while ma is (wrongly) 0. And NOT returns the bitwise Boolean inverse of I. Can you run the following code? It matches the failing code but contains some debugging printout. Can you also try kind=4? That seems to work while kind=8 seems to fail. integer(kind=8) m, ma ma = 0 m = 0 print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma m = not(m) print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma do while ( (m.ne.0) .and. (ma.lt.127) ) ma = ma + 1 m = ishft(m,-1) print '(m =,i21,z17,, ma=,i2,z13)', m, m, ma, ma end do print *, BIT_SIZE(m), ma if (BIT_SIZE(m) /= ma) error stop end Here are the results from hppa-unknown-linux-gnu which also fails. kind=8: m =00 ma= 00 m = -1 ma= 00 m = 9223372036854775807 7FFF, ma= 11 m = 4611686018427387903 3FFF, ma= 22 m = 2305843009213693951 1FFF, ma= 33 m = 1152921504606846975 FFF, ma= 44 m = 576460752303423487 7FF, ma= 55 m = 288230376151711743 3FF, ma= 66 m = 144115188075855871 1FF, ma= 77 m =72057594037927935 FF, ma= 88 m =36028797018963967 7F, ma= 99 m =18014398509481983 3F, ma=10A m = 9007199254740991 1F, ma=11B m = 4503599627370495F, ma=12C m = 22517998136852477, ma=13D m = 11258999068426233, ma=14E m = 5629499534213111, ma=15F m = 281474976710655 , ma=16 10 m = 140737488355327 7FFF, ma=17 11 m = 70368744177663 3FFF, ma=18 12 m = 35184372088831 1FFF, ma=19 13 m = 17592186044415 FFF, ma=20 14 m =8796093022207 7FF, ma=21 15 m =4398046511103 3FF, ma=22 16 m =219902321 1FF, ma=23 17 m =1099511627775 FF, ma=24 18 m = 549755813887 7F, ma=25 19 m = 274877906943 3F, ma=26 1A m = 137438953471 1F, ma=27 1B m = 68719476735F, ma=28 1C m = 343597383677, ma=29 1D m = 171798691833, ma=30 1E m = 85899345911, ma=31 1F m = 4294967295 , ma=32 20 m = 2147483647 7FFF, ma=33 21 m = 1073741823 3FFF, ma=34 22 m =536870911 1FFF, ma=35 23 m =268435455 FFF, ma=36 24 m =134217727 7FF, ma=37 25 m = 67108863 3FF, ma=38 26 m = 33554431 1FF, ma=39 27 m = 16777215 FF, ma=40 28 m = 8388607 7F, ma=41 29 m = 4194303 3F, ma=42 2A m = 2097151 1F, ma=43 2B m = 1048575F, ma=44 2C m = 5242877, ma=45 2D m = 2621433, ma=46 2E m = 1310711, ma=47 2F m =65535 , ma=48 30 m =32767 7FFF, ma=49 31 m =16383 3FFF, ma=50 32 m = 8191 1FFF, ma=51 33 m = 4095 FFF, ma=52 34 m = 2047 7FF, ma=53 35 m = 1023 3FF, ma=54 36 m = 511 1FF, ma=55 37 m = 255 FF, ma=56 38 m = 127 7F, ma=57 39 m = 63 3F, ma=58 3A m = 31 1F, ma=59 3B m =
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-10 13:33:12 UTC --- (In reply to comment #12) Does pure addr2line work? No, the following (-gdwarf-3) does work: gfortran -gdwarf-3 -O0 -fsanitize=address -fno-omit-frame-pointer asan_test.f90 ; ./a.out 21 | python ./asan_symbolize.py I guess the binutils is not quite up-to-date, I'm using a relatively recent 2.22 addr2line --version GNU addr2line (GNU Binutils) 2.22
[Bug c++/55639] Partial nested template specialization leads to segmentation fault of g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55639 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-10 13:40:18 UTC --- The issue is the 'template' keyword in: SomeClassnumber::template FunE, 0 without it, the code is accepted (ICC also accepts it). I'm pretty sure this is a Dup of another issue we already have in Bugzilla.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10 13:41:16 UTC --- (In reply to comment #11) ./a.out | python ./asan_symbolize.py I = ==45957== ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fff9752bdd8 at pc 0x400922 bp 0x7fff9752bda0 sp 0x7fff9752bd98 WRITE of size 4 at 0x7fff9752bdd8 thread T0 #0 0x400921 in test_asan_01_ ??:0 #1 0x400942 in MAIN__ asan_test.f90:0 #2 0x400978 in main ??:0 #3 0x351661ecdc in ?? ??:0 Address 0x7fff9752bdd8 is located at offset 24 in frame test_asan_01 of T0's stack: That means your addr2line is too old. You need at least addr2line with http://sourceware.org/ml/binutils-cvs/2012-04/msg00119.html changes to cope with GCC 4.8 emitted DWARF 4.
[Bug c++/49372] Temporaries evaluated for arguments of a default constructors of array elements not destructed properly (?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2012-12-10 Resolution|INVALID | Ever Confirmed|0 |1 --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 13:42:30 UTC --- (In reply to comment #3) Kai, I don't think anyone disputes that B's constructor is called, the question is why 12.2/4 doesn't apply. Well, we have here 5.2.2 which says A function call is a postfix expression followed by parentheses containing a possibly empty, comma-separated list of expressions which constitute the arguments to the function. But we don't have here an explicit function-call. And an implicit call is not an expression, hence, not a part of any full expression, and so we don't have a sequence-point. Not sure if specification intended it differently, but by its current wording I would assume that current implementation is right. But indeed 12.4 seems to be violated here. There are two contexts in which temporaries are destroyed at a different point than the end of the fullexpression. The first context is when a default constructor is called to initialize an element of an array. If the constructor has one or more default arguments, the destruction of every temporary created in a default argument expression is sequenced before the construction of the next array element, if any. So there is an antagonism in spec. I will reopen it. sorry, didn't read about 12.4
[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds (also seen at -O3 bootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 13:50:15 UTC --- For the testcase in comment#1 we have Found new range for len_10: [1, 7] Visiting statement: len_17 = MIN_EXPR len_10, len_11(D); Found new range for len_17: [0, +INF] which should have been [0, 7] I think. That fixes the testcase from comment#1.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #15 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-10 13:56:02 UTC --- (In reply to comment #14) That means your addr2line is too old. OK, with binutils 2.23.1 things work as expected. In particular: gfortran -g -O0 -fsanitize=address asan_test.f90 ; ./a.out 21 | python ./asan_symbolize.py = ==35214== ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fff37dfe8b8 at pc 0x400922 bp 0x7fff37dfe880 sp 0x7fff37dfe878 WRITE of size 4 at 0x7fff37dfe8b8 thread T0 #0 0x400921 in test_asan_01_ /data/vjoost/gnu/bugs/asan_test.f90:4 #1 0x400942 in MAIN__ /data/vjoost/gnu/bugs/asan_test.f90:7 #2 0x400978 in main /data/vjoost/gnu/bugs/asan_test.f90:8 #3 0x351661ecdc in ?? ??:0
[Bug tree-optimization/55107] [4.7/4.8 Regression] GCC in an infinite loop in PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55107 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 14:00:39 UTC --- Author: rguenth Date: Mon Dec 10 14:00:25 2012 New Revision: 194358 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194358 Log: 2012-12-10 Richard Biener rguent...@suse.de PR tree-optimization/55107 * tree-ssa-pre.c (struct pre_stats): Remove constified field. (bitmap_set_replace_value): Add gcc_unreachable. (do_regular_insertion): Re-write all_same handling. Insert an assignment instead of a PHI in this case. (eliminate_bb): Record availability also for SSA names defined by a constant. (do_pre): Do not record constified events. (execute_fre): Likewise. * gcc.dg/torture/pr55107.c: New testcase. * gcc.dg/tree-ssa/ssa-pre-5.c: Adjust. Added: trunk/gcc/testsuite/gcc.dg/torture/pr55107.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-5.c trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/55107] [4.7 Regression] GCC in an infinite loop in PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55107 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression] GCC in |[4.7 Regression] GCC in an |an infinite loop in PRE |infinite loop in PRE Known to fail|4.8.0 | --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 14:01:33 UTC --- Fixed on trunk sofar.
[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds (also seen at -O3 bootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079
--- Comment #13 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10
14:14:07 UTC ---
(In reply to comment #9)
This is reduced testcase from gcov.c
int a[8];
int
t (void)
{
int ix = 0;
int k;
int b = 0;
int curr = 0;
for (k = 0; k 2; k++)
{
b = ix * 32;
curr = a[ix++];
if (!(ix = 8))
See below.
abort ();
while (curr)
{
b = ix * 32;
curr = a[ix++];
if (!(ix = 8))
This is a test after the fact. For ix == 8 we will still enter the
next loop iteration (GCC can't know anything about 'curr') and thus
access a[8] which is out-of-bounds.
Fixing the tests to test 8 instead fixes the warnings.
This testcase is invalid.
abort ();
}
}
return curr + b;
}
jan@linux-e0ml:~/trunk/build/gcc ./xgcc -B ./ -O2 -fprofile-use t.c
-Warray-bounds -S -S -fdump-tree-cunroll-details -fdump-tree-all-details
t.c: In function ‘t’:
t.c:14:2: warning: incompatible implicit declaration of built-in function
‘abort’ [enabled by default]
abort ();
^
t.c:25:1: note: file /home/jan/trunk/build/gcc/t.gcda not found, execution
counts estimated
}
^
t.c:19:15: warning: array subscript is above array bounds [-Warray-bounds]
curr = a[ix++];
^
t.c:19:15: warning: array subscript is above array bounds [-Warray-bounds]
Obivously here unroller does not know that bv_ix is at least 1
[Bug c++/55639] Partial nested template specialization leads to segmentation fault of g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55639
Michael Veksler veksler at il dot ibm.com changed:
What|Removed |Added
CC||veksler at il dot ibm.com
--- Comment #2 from Michael Veksler veksler at il dot ibm.com 2012-12-10
14:18:07 UTC ---
I have a possibly similar test case (can someone confirm if my case is a DUP?).
--- t.cpp --
template typename T
struct A {
template int a
struct B;
};
template typename T
struct AT::template B0 {
int foo();
};
end --
$ /opt/gcc4.7.2/bin/g++ t.cpp
t.cpp:8:23: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$/opt/gcc4.7.2/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/opt/gcc4.7.2/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc4.7.2/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.2/configure --prefix=/opt/gcc4.7.2
Thread model: posix
gcc version 4.7.2 (GCC)
[Bug c++/55639] Partial nested template specialization leads to segmentation fault of g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55639 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-10 14:23:16 UTC --- It is, it is.
[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 --- Comment #10 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-12-10 14:33:29 UTC --- (In reply to comment #9) Created attachment 28900 [details] Candidate patch Try this. It works. There are no more spill in class 'R0_REG' ICEs wozj your patch (atop trunk 194354)
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466 --- Comment #11 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-12-10 14:44:00 UTC --- Author: hjl Date: Mon Dec 10 14:43:54 2012 New Revision: 194359 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194359 Log: Record the global variables if WPA isn't enabled PR lto/55466 * lto-symtab.c (lto_symtab_merge_decls_1): Don't record the prevailing variable. * lto.c (lto_register_var_decl_in_symtab): Don't record static variables. (lto_main): Record the global variables if WPA isn't enabled. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-symtab.c trunk/gcc/lto/lto.c
[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55619
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10
14:48:00 UTC ---
Created attachment 28913
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28913
gcc48-pr55619.patch
Here is (untested) patch I had in mind. But perhaps we'd need to also change
the C FE, because with this patch we no longer error on e.g.
void
f ()
{
int x[4];
__asm volatile ( : : m (x));
}
in C++, but still error out on it in C. On the C side perhaps we should drop
the convert_p argument to c_parser_asm_operands, not do any conversion nor
c_fully_fold in there and instead do it in build_asm_stmt.
[Bug bootstrap/55640] New: --with-build-config=bootstrap-lto doesn't work with go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55640 Bug #: 55640 Summary: --with-build-config=bootstrap-lto doesn't work with go Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, when GCC was configured with --enable-bootstrap --with-build-config=bootstrap-lto --enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go I got lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:3985 0x629ad9 add_AT_specification /export/gnu/import/git/gcc/gcc/dwarf2out.c:3985 0x64dabb gen_variable_die /export/gnu/import/git/gcc/gcc/dwarf2out.c:18327 0x65336b gen_decl_die /export/gnu/import/git/gcc/gcc/dwarf2out.c:20033 0x653fcd dwarf2out_decl(tree_node*) /export/gnu/import/git/gcc/gcc/dwarf2out.c:20348 0x6535f9 dwarf2out_global_decl /export/gnu/import/git/gcc/gcc/dwarf2out.c:20083 0x997703 emit_debug_global_declarations(tree_node**, int) /export/gnu/import/git/gcc/gcc/toplev.c:530 0x521aaa lto_write_globals /export/gnu/import/git/gcc/gcc/lto/lto-lang.c:1067 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. make[6]: *** [/tmp/cc3yYR7d.ltrans4.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make[5]: *** [go1] Error 1
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #12 from Dmitry Vyukov dvyukov at google dot com 2012-12-10
15:07:11 UTC ---
(In reply to comment #11)
(In reply to comment #10)
Is is a correct report? Or false positive?
This is a correct report for the testcase in comment #0 (as J is shared
between
threads).
That's great that gcc tsan works for Fortran/OpenMP out of the box!
However, most likely Fortran/OpenMP will require some special handling to
produce better reports and catch more bugs (ThreadSanitizer reasons about
synchronization on pthread level, and not on OpenMP level). We won't have spare
cycles for that in near future.
I am working on ThreadSanitizer tasking API, I would appreciate if you review
it and comment on whether it will fit Fortran/OpenMP model (the work is
currently in very early what if stage).
The is the proposed public API:
// The tasking API is intended for programs that use finer-grained tasks
// on top of threads. For such programs ThreadSanitizer can produce
// bad reports (namely, thread creation stack is useless), and catch less
// bugs because it does not understand task boundaries.
// The tasking API allows programs to annotate tasks to solve both problems.
// The API is intended to be flexible enough to support standard C++ tasks,
// OpenMP tasks as well as custom tasks. It's also intended to be
// non-intrusive as possible to be used merely as annotations in existing code.
// Creation of a task.
// TASK is an arbitrary pointer that uniquely identifies the task.
// ThreadSanitizer stores any required internal info offline.
// FLAGS see below.
void __tsan_task_create(void *task, unsigned flags);
// Destruction of a task, frees all associated resources.
// After that the TASK pointer can be reused for another task.
void __tsan_task_destroy(void *task);
// Denotes beginning of execution of the TASK.
// When the function returns ThreadSanitizer effectively switches
// to another thread context associated with the task.
// Returns TASK. This is needed because re-reading it even from stack variable
// can result in a data race with the worker thread (since we are already in
the
// task context).
// Tasks can be recursive, but must be strictly nested.
void* __tsan_task_begin(void *task);
// Denotes end of execution of the TASK.
// When the function returns ThreadSanitizer effectively switches
// back to worker thread context.
void __tsan_task_end(void *task);
// If set, ThreadSanitizer uses separate thread context for task execution.
// If not set, ThreadSanitizer can not detect any new data races but still
// produces better reports (namely, task creation stack). A user may not want
// to set in two cases:
// 1. If task executor executes tasks in single thread (and that is the part
//of public contract).
// 2. If ThreadSanitizer produces false postives, but a user still wants
//to take advantage of better reports.
const unsigned __TSAN_TASK_FLAG_SYNC = 1 0;
// Denotes that the task is periodic, i.e. can be executed several times
// (intended for periodic timer tasks and IO rediness notifications).
// If set, then __tsan_task_begin()/__tsan_task_end() can be called several
// times. After the last execution the task must be explicitly destroyed with
// __tsan_task_destroy().
const unsigned __TSAN_TASK_FLAG_PERIODIC = 1 1;
// Usage examples:
/*
1. Non-prdiodic task:
void ThreadPool::Add(Task *t) {
__tsan_task_create(t, __TSAN_TASK_FLAG_SYNC);
mutex_.lock();
queue_.push_back(t);
mutex_.unlock();
}
void ThreadPool::WorkerThread() {
for (;;) {
mutex_.lock();
while (queue_.empty())
convvar_.wait(mutex_);
Task *t = queue_.pop_front();
mutex_.unlock();
t = __tsan_task_begin(t);
t-Execute();
__tsan_task_end(t);
__tsan_task_destroy(t);
delete t;
}
}
This is semantically equivalent to:
void ThreadPool::Add(Task *t) {
pthread_create(t-thread_, 0, Task::Execute, t);
}
2. Priodic task:
void ThreadPool::AddPeriodic(Task *t) {
__tsan_task_create(t, __TSAN_TASK_FLAG_SYNC | __TSAN_TASK_FLAG_PERIODIC);
AddPeriodicImpl(t, t-Period());
}
void ThreadPool::WorkerThread() {
for (;;) {
Task* t = CheckPeriodicTasks();
if (t) {
t = __tsan_task_begin(t);
t-Execute();
__tsan_task_end(t);
AddPeriodicImpl(t, t-Period());
}
...
}
}
void ThreadPool::CancelPeriodic(Task *t) {
CancelPeriodicImpl(t);
__tsan_task_destroy(t);
delete t;
}
This is semantically equivalent to:
void ThreadPool::Add(Task *t) {
pthread_create(t-thread_, 0, ExecutePeriodic, t);
}
void *ExecutePeriodic(Task *t) {
while (!t-Cancelled()) {
sleep(t-Period());
t-Execute();
}
}
void ThreadPool::CancelPeriodic(Task *t) {
t-SetCancelled();
pthread_join(t-thread_, 0);
delete t;
}
*/
[Bug c/52991] attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-12-10
Ever Confirmed|0 |1
--- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-10 15:13:37
UTC ---
Yes, there is an issue about record/union attribute packed for ms_struct.
The following patch is fixing that for me, I just do regression-testing.
Index: stor-layout.c
===
--- stor-layout.c(Revision 194356)
+++ stor-layout.c(Arbeitskopie)
@@ -756,7 +756,10 @@ start_record_layout (tree t)
/* If the type has a minimum specified alignment (via an attribute
declaration, for example) use it -- otherwise, start with a
one-byte alignment. */
- rli-record_align = MAX (BITS_PER_UNIT, TYPE_ALIGN (t));
+ if (TYPE_PACKED (t))
+rli-record_align = BITS_PER_UNIT;
+ else
+rli-record_align = MAX (BITS_PER_UNIT, TYPE_ALIGN (t));
rli-unpacked_align = rli-record_align;
rli-offset_align = MAX (rli-record_align, BIGGEST_ALIGNMENT);
@@ -952,15 +955,20 @@ update_alignment_for_field (record_layout_info rli
meaningless. */
if (targetm.ms_bitfield_layout_p (rli-t))
{
+ if (rli-t TYPE_PACKED (rli-t)
+ (is_bitfield || !DECL_PACKED (field)
+ || DECL_SIZE (field) == NULL_TREE
+ || !integer_zerop (DECL_SIZE (field
+desired_align = BITS_PER_UNIT;
/* Here, the alignment of the underlying type of a bitfield can
affect the alignment of a record; even a zero-sized field
can do this. The alignment should be to the alignment of
the type, except that for zero-size bitfields this only
applies if there was an immediately prior, nonzero-size
bitfield. (That's the way it is, experimentally.) */
- if ((!is_bitfield !DECL_PACKED (field))
- || ((DECL_SIZE (field) == NULL_TREE
- || !integer_zerop (DECL_SIZE (field)))
+ else if ((!is_bitfield !DECL_PACKED (field))
+ || ((DECL_SIZE (field) == NULL_TREE
+ || !integer_zerop (DECL_SIZE (field)))
? !DECL_PACKED (field)
: (rli-prev_field
DECL_BIT_FIELD_TYPE (rli-prev_field)
@@ -1414,7 +1422,13 @@ place_field (record_layout_info rli, tree field)
}
/* Now align (conventionally) for the new type. */
- type_align = TYPE_ALIGN (TREE_TYPE (field));
+ if (!TYPE_PACKED (rli-t))
+{
+ type_align = TYPE_ALIGN (TREE_TYPE (field));
+ if (DECL_PACKED (field))
+type_align = MIN (type_align, BITS_PER_UNIT);
+
+}
if (maximum_field_alignment != 0)
type_align = MIN (type_align, maximum_field_alignment);
[Bug lto/55605] FAIL: gcc.c-torture/execute/builtins/20010124-1.c compilation, -O2 -flto -flto-partition=none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55605 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2012-12-10 15:17:19 UTC --- Fixed.
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10 15:33:38 UTC --- (In reply to comment #4) Hmm, this does not help. The problem is indeed that we are not able to figure out that the accesses into subarrays of X are mutually independent. Martin, Michael, I think you are more familiar with MEM_REF, can you take a look? Well, the accesses are lowered to like (compute_affine_dependence stmt_a: _21 = MEM[(real(kind=8)[0:D.1986] *)x + 20247552B][_20]; stmt_b: _23 = MEM[(real(kind=8)[0:D.1983] *)x][_20]; ) - dependence analysis failed this lowering of x.u vs. x.v (just guessing) does't mix well with array-based accesses. That is, we cannot translate this kind of accesses to independently indexed dimensions as dependence analysis likes to have. Another issue is that the number of iterations is not constant but 190: === get_loop_niters ===Analyzing # of iterations of loop 2 exit condition [2, + , 1](no_overflow) != _2 + -1 bounds on difference of bases: 0 ... 2147483644 result: # of iterations (unsigned int) _2 + 4294967293, bounded by 2147483644 so we cannot see that in the above case _20 would not run over to the other sub-array of x. The only way to retain this knowledge is not to lower the high-level form x.u and x.v but to keep it (which in the end won't help because we cannot reconstruct x.u[_20] or x.v[_20] in any valid way). Or to retain restrict information - which means _not_ doing IPA-CP. So, if you can from (compute_affine_dependence stmt_a: _21 = MEM[(real(kind=8)[0:D.1986] *)x + 20247552B][_20]; stmt_b: _23 = MEM[(real(kind=8)[0:D.1983] *)x][_20]; ) - dependence analysis failed prove that the base addresses (MEM[(real(kind=8)[0:D.1986] *)x + 20247552B] and MEM[(real(kind=8)[0:D.1983] *)x]) are different objects then initialize_data_dependence_relation can compute the dependence and all would be fine. refs_may_alias_p would be the thing to fix to make them not alias (as you can see the arrays have unknown upper bounds, so it's not possible to prove they are not the same).
[Bug bootstrap/55640] --with-build-config=bootstrap-lto doesn't work with go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55640 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.8.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-12-10 15:37:32 UTC --- Fixed as of revision 194359.
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-10 15:55:50 UTC --- (In reply to comment #12) That's great that gcc tsan works for Fortran/OpenMP out of the box! I'm afraid it yields false positives. Something like this is supposed to be OK OMP-wise (and gives the right result in 1 repetitions) but produces warnings. cat test.f90 INTEGER, PARAMETER :: N=10 INTEGER :: data(N) !$OMP PARALLEL DO DO j=1,N data(j)=j ENDDO !$OMP PARALLEL DO DO j=N,1,-1 data(j)=data(j)-j ENDDO IF (ANY(data.NE.0)) CALL abort() END gfortran -fsanitize=thread -O1 -g -fopenmp -fPIC -pie test.f90 ; ./a.out == WARNING: ThreadSanitizer: data race (pid=18871) However, most likely Fortran/OpenMP will require some special handling to produce better reports and catch more bugs (ThreadSanitizer reasons about synchronization on pthread level, and not on OpenMP level). We won't have spare cycles for that in near future. I am working on ThreadSanitizer tasking API, I would appreciate if you review it and comment on whether it will fit Fortran/OpenMP model (the work is currently in very early what if stage). I'm sure there are knowledgeable people reading the gcc list... posting this text there seems like a good idea.
[Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds (also seen at -O3 bootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079
--- Comment #14 from Jan Hubicka hubicka at ucw dot cz 2012-12-10 16:26:40
UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079
--- Comment #13 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10
14:14:07 UTC ---
(In reply to comment #9)
This is reduced testcase from gcov.c
int a[8];
int
t (void)
{
int ix = 0;
int k;
int b = 0;
int curr = 0;
for (k = 0; k 2; k++)
{
b = ix * 32;
curr = a[ix++];
if (!(ix = 8))
See below.
abort ();
while (curr)
{
b = ix * 32;
curr = a[ix++];
if (!(ix = 8))
This is a test after the fact. For ix == 8 we will still enter the
next loop iteration (GCC can't know anything about 'curr') and thus
access a[8] which is out-of-bounds.
Fixing the tests to test 8 instead fixes the warnings.
This testcase is invalid.
I fixed that in GCOV sources already, but it depends on the definition of
invalidness. In general construct like ix = some_constant may come from some
unrelated stuff (macro expansion) and may be fully redundant in sane and valid
program. In that case waring after unrolling some_constant times there will be
out of bound access (without explicitely saying that unrolling is needed) is
undesirable IMO. The loop has other exit that takes care of the proper bound.
Honza
[Bug debug/55641] New: debug info for the type of a reference declared with a typedef has spurious 'const'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 Bug #: 55641 Summary: debug info for the type of a reference declared with a typedef has spurious 'const' Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: dblai...@gmail.com Example code: typedef int foo; int x; foo f(x); under gdb run whatis f and the answer is const foo when it should be plain foo (if you skip the typedef the answer is correctly int not int const or any similarly strange mismatch) Found in the GDB 7.5 test suite ( gdb.python/lib-types.exp ) - this is positively tested for, but so far as I can imagine that's by accident, not intent.
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10 16:29:10 UTC --- The test is really large, I guess it would be useful if you could try to reduce the testcase as long as it still fails that BIT_SIZE(integer(8)) test. Or can you step through the interesting part of the testcase and see where things go wrong? I've eyeballed the *.final assembly of the ma computation and it looks ok to me. ldi 0,%r19 ldi 0,%r20 ldi 126,%r31 ldi -1,%r28 ldi -1,%r29 L$0032: copy %r19,%r21 copy %r20,%r22 addi 1,%r20,%r20 addc %r19,%r0,%r19 comiclr,= 0,%r21,%r0 b,n L$0029 comib, 0,%r21,L$0050 or %r28,%r29,%r23 comclr,= %r31,%r22,%r0 b,n L$0029 L$0050: comib,=,n 0,%r23,L$0029 shd %r28,%r29,1,%r21 extru %r28,30,31,%r22 copy %r21,%r29 b L$0032 copy %r22,%r28 L$0029: stw %r21,-240(%r30) ldo -240(%r30),%r25 ldi 20,%r23 stw %r22,-236(%r30) is the assembly I get for the interesting part. So, if you have the same, can you step through this and see why you get 0 in %r21/%r22?
[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 --- Comment #1 from David Blaikie dblaikie at gmail dot com 2012-12-10 16:29:47 UTC --- Oh, and, tellingly, GCC (7.5) emits a DW_TAG_const_type in the DWARF data that Clang does not emit, which seems to be the relevant difference here.
[Bug lto/55466] [4.8 Regression] Revision 191466 destroyed DWARF debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2012-12-10 16:39:40 UTC --- Fixed.
[Bug c++/49372] Temporaries evaluated for arguments of a default constructors of array elements not destructed properly (?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49372 --- Comment #5 from Johannes Schaub schaub.johannes at googlemail dot com 2012-12-10 16:42:59 UTC --- (In reply to comment #4) (In reply to comment #3) Kai, I don't think anyone disputes that B's constructor is called, the question is why 12.2/4 doesn't apply. Well, we have here 5.2.2 which says A function call is a postfix expression followed by parentheses containing a possibly empty, comma-separated list of expressions which constitute the arguments to the function. But we don't have here an explicit function-call. And an implicit call is not an expression, hence, not a part of any full expression, and so we don't have a sequence-point. Not sure if specification intended it differently, but by its current wording I would assume that current implementation is right. See 1.9p10. The implicit function call is considered to be an expression.
[Bug ada/55243] STAMP variable is not defined in t-avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243 --- Comment #11 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-12-10 17:00:50 UTC --- (In reply to comment #10) I don't know anything about the gnat build system and when I build avr-gcc I configure for C/C++. What's odd is that even if GCC is only configured for C/C++, I get messages about a missing gnatls. For example, running make in the gcc subdirectory of build prints $build/gcc make /bin/sh: gnatls: command not found The build itself works fine but that message is confusing and shows that something is wrong with the gnat build system. gnat stuff should not be needed of the compiler is not configured for ada, should it? Probably, but if nobody really investigates, nothing will ever be fixed. $(build)/gcc/Makefile reads: # per-language makefile fragments ifneq ($(LANG_MAKEFRAGS),) include $(LANG_MAKEFRAGS) endif # target and host overrides must follow the per-language makefile fragments # so they can override or augment language-specific variables # target overrides ifneq ($(tmake_file),) include $(tmake_file) endif LANG_MAKEFRAGS contains $(srcdir)/ada/gcc-interface/Make-lang.in which in turn contains: # put the host RTS dir first in the PATH to hide the default runtime # files that are among the sources RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib ))) which means gnatls is called no matter if it exists or not. (In reply to comment #6) The GNAT tools are for the host, they have nothing to do with multilibs. How come the s-avr-mlib Makefile rule gets invoked here? The Makefile includes $(tmake_file) and thus $(srcdir)/gcc/config/avr/t-multilib which is auto-generated and needs $(STAMP) to build. AFAIK make resolves its includes before it starts building the targets.
[Bug sanitizer/55482] gfortran.dg/class_array_7.f03 execution failures with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55482 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Target|x86_64-apple-darwin12 |x86_64-apple-darwin12,x86_6 ||4-unknown-linux-gnu Host|x86_64-apple-darwin12 |x86_64-apple-darwin12,x86_6 ||4-unknown-linux-gnu Build|x86_64-apple-darwin12 |x86_64-apple-darwin12,x86_6 ||4-unknown-linux-gnu --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-10 17:14:57 UTC --- Also seen on x86_64 Fedora 15.
[Bug target/28586] thowing exception before main() leads to crash on AIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target|powerpc-aix |powerpc-ibm-aix Last reconfirmed|2006-08-03 18:48:29 |2012-12-10 18:48:29 Host||powerpc-ibm-aix Build||powerpc-ibm-aix --- Comment #2 from David Edelsohn dje at gcc dot gnu.org 2012-12-10 17:17:07 UTC --- This probably is related to static constructors of dependent libraries not running before constructors in the application because it is trying to throw an exception from a static constructor.
[Bug middle-end/55642] New: [4.8 Regression] Invalid thumb code generated (thumb conditional instruction should be in IT block)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55642 Bug #: 55642 Summary: [4.8 Regression] Invalid thumb code generated (thumb conditional instruction should be in IT block) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernhard.rosenkran...@linaro.org Created attachment 28914 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28914 Test case (not yet reduced) Building the attached preprocessed code with -std=gnu++11 -O2 -mthumb -mcpu=cortex-a9 results in errors from the assembler: [bero@localhost grouper-4.2.1-gcc-4.8 (master)]$ /opt/android-toolchain-trunk/bin/arm-linux-androideabi-g++ -std=gnu++11 -o ARMAsmParser.o -O2 -mthumb -mcpu=cortex-a9 -c ARMAsmParser.i /tmp/ccKYPdeC.s: Assembler messages: /tmp/ccKYPdeC.s:7949: Error: thumb conditional instruction should be in IT block -- `subne r2,r2,r3,asr#31' /tmp/ccKYPdeC.s:21058: Error: thumb conditional instruction should be in IT block -- `subne r2,r2,r3,asr#31'
[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-10 17:24:15 UTC --- Which version of GCC? (there is no 7.5)
[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-10 Version|unknown |4.7.2 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-10 17:42:56 UTC --- confirmed with various versions from 4.1 to 4.7
[Bug rtl-optimization/55193] [4.8 Regression] ICE in in simplify_const_unary_operation, at simplify-rtx.c:1659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55193 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10 17:44:57 UTC --- Can't be reproduced starting with http://gcc.gnu.org/viewcvs?root=gccview=revrev=193157 (made latent on this testcase), but if I revert the patch I can reproduce it easily. The bug is in lra-constraints.c, loc_equivalence_change_p really doesn't work well on DEBUG_INSNs.
[Bug rtl-optimization/55193] [4.8 Regression] ICE in in simplify_const_unary_operation, at simplify-rtx.c:1659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55193 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-10 17:53:01 UTC --- Created attachment 28915 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28915 gcc48-pr55193.patch Untested fix. For changes to DEBUG_INSNs, generally simplify_replace_fn_rtx is the best thing, it takes care of simplifying everything that is needed, both for the cases where something changes from non-VOIDmode into VOIDmode (then simplification is required; e.g. as on this testcase (zero_extend:DI (reg:SI eax) 0) where eax is replaced by (const_int 0)), and a nice thing to have otherwise.
[Bug ada/55243] STAMP variable is not defined in t-avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-10 18:00:20 UTC --- LANG_MAKEFRAGS contains $(srcdir)/ada/gcc-interface/Make-lang.in which in turn contains: # put the host RTS dir first in the PATH to hide the default runtime # files that are among the sources RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib ))) which means gnatls is called no matter if it exists or not. OK, thanks for investigating. Tentative patch for ada/ to be attached. The Makefile includes $(tmake_file) and thus $(srcdir)/gcc/config/avr/t-multilib which is auto-generated and needs $(STAMP) to build. AFAIK make resolves its includes before it starts building the targets. So t-multilib is autogenerated in the source tree during the build???
[Bug ada/55243] STAMP variable is not defined in t-avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243 --- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-10 18:02:19 UTC --- Created attachment 28916 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28916 Tentative fix for gnatls issue To be applied in the ada/ source directory.
[Bug other/54324] [4.8 Regression] GCC install document does not list minimum required g++ version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||aldyh at gcc dot gnu.org AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-10 18:11:13 UTC --- I'll investigate a bit further.
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 --- Comment #14 from Zdenek Dvorak rakdver at gcc dot gnu.org 2012-12-10 18:19:07 UTC --- This is a problem in rewrite_use_nonlinear_expr, which should leave the statement defining the biv untouched (as suggested in the comment at its beginning) but does not. Investigating further...
[Bug sanitizer/55484] gfortran.dg/realloc_on_assign_5.f03 execution failures with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55484 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Target|x86_64-apple-darwin12 |x86_64-apple-darwin12,x86_6 ||4-unknown-linux-gnu Host|x86_64-apple-darwin12 |x86_64-apple-darwin12,x86_6 ||4-unknown-linux-gnu Build|x86_64-apple-darwin12 |x86_64-apple-darwin12,x86_6 ||4-unknown-linux-gnu --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-10 18:20:47 UTC --- Also seen on x86_64 Fedora 15.
[Bug ada/55243] STAMP variable is not defined in t-avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243 --- Comment #14 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-12-10 18:25:19 UTC --- (In reply to comment #12) So t-multilib is autogenerated in the source tree during the build??? Jepp. Top $(srcdir)/gcc/config/avr/t-multilib reads: # Auto-generated Makefile Snip # Generated by: ./gcc/config/avr/genmultilib.awk # Generated from : ./gcc/config/avr/avr-mcus.def # Used by : tmake_file from Makefile and genmultilib Rationale is that avr-gcc supports an, IMHO, insane number of -mmcu=device. In order to keep various parts of the compiler in sync, some bits are auto-generated, amongst them documentation, t-multilib and .opt parts. Procedure is a move-if-change scheme, i.e. the auto-generated files are in the repository and the procedure to build them is similar to building configure from configure.ac and then putting both configure.ac /and/ configure into the repo. However, the auto-build runs automatically and thus needs some tools, namely $(SHELL), $(AWK), $(CC_FOR_BUILD), $(RUN_GEN) and $(STAMP).
