[Bug c/55336] New: Feature request : message output format XML
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55336 Bug #: 55336 Summary: Feature request : message output format XML Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: clemens1...@web.de Every compiler has its own error output format. It would be better for IDE's if all would have the same error message output syntax. Benefits: - easier parsing for all developmetn environments - compount errors can be handelt together like Exanmple: error index=0 id=W0004711 !# index starting from zero text file=myfile.cpp line=12345wrong number of arguments in function xyz/text text file=myfile2 line=54321error occurs at this position/text /error In this example you can see how it is possible to connect errors together.
[Bug middle-end/55336] Feature request : message output format XML
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55336 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-15 08:08:31 UTC --- I doubt this will be implemented. The format for GCC's warning and errors are simple to parse as of right now. In fact GCC will never have an id to the warning/error message.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #39 from Alexander Potapenko glider at google dot com 2012-11-15 08:18:01 UTC --- I agree with Kostya that no major changes to mach_override are necessary because we are really going to dump it. However minor fixes required for ASan in GCC to work on Darwin right now should be perfectly ok. As there currently are issues blocking the dynamic ASan runtime (e.g. https://code.google.com/p/address-sanitizer/issues/detail?id=124), and we still depend on CoreFoundation I can't promise that we'll get rid of mach_override before the GCC 4.8 release.
[Bug middle-end/55336] Feature request : message output format XML
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55336 --- Comment #2 from Clemens clemens1509 at web dot de 2012-11-15 08:24:41 UTC --- (In reply to comment #1) I doubt this will be implemented. The format for GCC's warning and errors are simple to parse as of right now. In fact GCC will never have an id to the warning/error message. The idea is not to make parsing more simple, just make parsing common to *all* compiler. The second idea is that error messages could be connected together. This is right now only possible of parser know the semantic of an msg. It can no be determined from message format itself.
[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55325 --- Comment #13 from Uros Bizjak ubizjak at gmail dot com 2012-11-15 08:26:11 UTC --- (In reply to comment #10) Probably due to the fact that x86_64 defines TARGET_C_MODE_FOR_SUFFIX that declares support for non-standard 'q' and 'w' suffixes. There is a small group of targets that declare this define: Patch for this problem is at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01198.html
[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55325 --- Comment #14 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-15 08:44:05 UTC --- (In reply to comment #13) [1] http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01198.html Thanks. Note that pa handles 'q'.
[Bug c++/55337] New: [4.8 Regression] ICE tree check: expected sizeof_expr, have alignof_expr in cp_tree_equal, at cp/tree.c:2608
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55337
Bug #: 55337
Summary: [4.8 Regression] ICE tree check: expected sizeof_expr,
have alignof_expr in cp_tree_equal, at cp/tree.c:2608
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de
markus@x4 tmp % cat test.ii
templateint struct A;
templatetypename Type struct B
{
static A__alignof__(Type) b;
};
templatetypename Type A__alignof__(Type) BType::b;
markus@x4 tmp % c++ -c test.ii
test.ii:6:44: internal compiler error: tree check: expected sizeof_expr, have
alignof_expr in cp_tree_equal, at cp/tree.c:2613
templatetypename Type A__alignof__(Type) BType::b;
^
0xc3d0da tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/markus/gcc/gcc/tree.c:8954
0x674dde tree_check
/home/markus/gcc/gcc/tree.h:3686
0x674dde cp_tree_equal(tree_node*, tree_node*)
/home/markus/gcc/gcc/cp/tree.c:2613
0x521b54 template_args_equal
/home/markus/gcc/gcc/cp/pt.c:6797
0x52211d comp_template_args_with_info
/home/markus/gcc/gcc/cp/pt.c:6824
0x522204 comp_template_args
/home/markus/gcc/gcc/cp/pt.c:6842
0x522204 eq_specializations
/home/markus/gcc/gcc/cp/pt.c:1471
0xf77c7c htab_find_with_hash
/home/markus/gcc/libiberty/hashtab.c:606
0x55aa38 lookup_template_class_1
/home/markus/gcc/gcc/cp/pt.c:7252
0x55aa38 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/markus/gcc/gcc/cp/pt.c:7522
0x64d212 finish_template_type(tree_node*, tree_node*, int)
/home/markus/gcc/gcc/cp/semantics.c:2794
0x5e6c28 cp_parser_template_id
/home/markus/gcc/gcc/cp/parser.c:12705
0x5e6ff6 cp_parser_class_name
/home/markus/gcc/gcc/cp/parser.c:18089
0x5dc0db cp_parser_qualifying_entity
/home/markus/gcc/gcc/cp/parser.c:5264
0x5dc0db cp_parser_nested_name_specifier_opt
/home/markus/gcc/gcc/cp/parser.c:4995
0x5e7a07 cp_parser_constructor_declarator_p
/home/markus/gcc/gcc/cp/parser.c:21391
0x5e7a07 cp_parser_decl_specifier_seq
/home/markus/gcc/gcc/cp/parser.c:10878
0x5eb907 cp_parser_single_declaration
/home/markus/gcc/gcc/cp/parser.c:21876
0x5ee786 cp_parser_template_declaration_after_export
/home/markus/gcc/gcc/cp/parser.c:21761
0x5f6899 cp_parser_declaration
/home/markus/gcc/gcc/cp/parser.c:10302
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.
[Bug c++/55337] [4.8 Regression] ICE tree check: expected sizeof_expr, have alignof_expr in cp_tree_equal, at cp/tree.c:2608
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55337 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-15 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug c++/55337] [4.8 Regression] ICE tree check: expected sizeof_expr, have alignof_expr in cp_tree_equal, at cp/tree.c:2608
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55337 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 #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-15 10:04:19 UTC --- Created attachment 28696 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28696 gcc48-pr55337.patch Untested fix.
[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test rnflow degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 --- Comment #15 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-15 10:27:49 UTC --- Path posted at http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01222.html Can we figure out why the vectorization still does not happen?
[Bug target/55332] [4.8 Regression] libsanitizer breaks build on hpux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55332 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-15 10:38:26 UTC --- It doesn't break bootstrap any longer, configure.tgt should enable it solely on i?86/x86_64-linux right now.
[Bug other/19165] (Natural) language independent error / warning classification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||clemens1509 at web dot de --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-15 10:39:35 UTC --- *** Bug 55336 has been marked as a duplicate of this bug. ***
[Bug middle-end/55336] Feature request : message output format XML
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55336 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||DUPLICATE --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-15 10:39:35 UTC --- Hi Clemens, What IDE? I already implemented a prototype patch for this in PR 19165, and there was zero interest from any IDE people. I honestly believe that if you don't have interested people with the access and the time to integrate this into a major IDE (Eclipse, Kdevelop, Emacs), then it will be a wasted effort. In any case, nobody currently working on GCC has the time or the interest to work on such a feature, so you would need to start contributing to GCC or hire someone to implement it. *** This bug has been marked as a duplicate of bug 19165 ***
[Bug rtl-optimization/55330] [4.8 Regression] ICE: Maximum number of LRA constraint passes is achieved (15) on gfortran.dg/actual_array_constructor_1.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55330 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-15 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test rnflow degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 --- Comment #16 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-15 10:52:13 UTC --- OK, 4.7 vectorize two loops in the function in cptrf2 loop at ../a.f90:3538 if (nxtr 4) then kerr = 1 do ixtr = 1, nxtr - 1 ixtrt (ixtr) = ixtr + 1 enddo goto 9000 endif and loop at ../a.f90:3530 ixtrt = 0 The second loop is recognized as memset by mainline, so it remains to figure out what is wrong with the first loop. It is unrolled: Analyzing # of iterations of loop 9 exit condition [1, + , 1](no_overflow) != ival2_27 + -1 bounds on difference of bases: 0 ... 1 result: # of iterations (unsigned int) ival2_27 + 4294967294, bounded by 1 Loop 9 iterates at most 1 times. Estimating sizes for loop 9 BB: 8, after_exit: 0 size: 0 _38 = (integer(kind=8)) ixtr_12; Induction variable computation will be folded away. size: 1 _39 = _38 + -1; Induction variable computation will be folded away. size: 1 ixtr_40 = ixtr_12 + 1; Induction variable computation will be folded away. size: 1 *ixtrt_33(D)[_39] = ixtr_40; size: 2 if (ixtr_12 == _37) Exit condition will be eliminated in last copy. BB: 79, after_exit: 1 size: 5-2, last_iteration: 5-4 Loop size: 5 Estimated size after unrolling: 2 Unrolled loop 9 completely (duplicated 1 times). I do not quite see why it iterates at most once, but if seems to work. So I would say that it is good idea to unroll rather than vectorize. Is the slowdown still reproducing with my patch?
Re: [Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed
Note though that this is not an assert. It just emits a message to stderr. Do you think a better error message is appropriate? I'm not sure the some data files may have been removed is an accurate description of the issue. Perhaps something like Profile data file mismatch may indicate corrupt profile data? Well, we should figure out why sum_all starts to diverge. If we had problems mixing cc1 and cc1plus executions, we should get mismatches in number of counters. What happens after the miscompare? Honza
[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051 --- Comment #24 from Jan Hubicka hubicka at ucw dot cz 2012-11-15 10:56:53 UTC --- Note though that this is not an assert. It just emits a message to stderr. Do you think a better error message is appropriate? I'm not sure the some data files may have been removed is an accurate description of the issue. Perhaps something like Profile data file mismatch may indicate corrupt profile data? Well, we should figure out why sum_all starts to diverge. If we had problems mixing cc1 and cc1plus executions, we should get mismatches in number of counters. What happens after the miscompare? Honza
[Bug c++/55338] New: Incorrectly reported error in type name hiding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55338
Bug #: 55338
Summary: Incorrectly reported error in type name hiding
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: piotr.wyder...@gmail.com
The following snippet:
class A {};
class B : public A {
typedef A super;
public:
class X {};
};
class C : public B {
typedef B super;
class X : public super::X {
typedef super::X super;
};
};
compiles without a warning on Comeau and MSVC, but GCC (4.6.1 and
4.7.1) failes with the following message:
$ gcc -c bug.cpp
bug.cpp:18:24: error: declaration of ‘typedef class B::X C::X::super’
[-fpermissive]
bug.cpp:14:14: error: changes meaning of ‘super’ from ‘typedef class B
C::super’ [-fpermissive]
To my understanding of the Standard Comeau is right and GCC is wrong here.
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-15 11:07:10 UTC --- I think the problem is that we somehow make MEM_REF to be base...
[Bug c++/55339] New: Generated code hangs with -O2 on Linux ppc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55339 Bug #: 55339 Summary: Generated code hangs with -O2 on Linux ppc Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: anton.kati...@gmail.com Please find attached a test program and _compile.sh to compile it. _compile.sh produces 2 output files: test-O2.bin and test-O1.bin, compiled with -O2 and -O1 respectively. test-O1.bin works just fine: $ ./test-O1.bin entering... exception caught, as expected OK $ test-O1.bin hangs: $ ./test-O2.bin entering... hangs forever at this point... $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/opt/gcc-4.7.2/libexec/gcc/powerpc64-unknown-linux-gnu/4.7.2/lto-wrapper Target: powerpc64-unknown-linux-gnu Configured with: ../gcc-4.7.2/configure --prefix=/opt/gcc-4.7.2 --enable-threads=posix --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --enable-languages=c,c++ --enable-multilib Thread model: posix gcc version 4.7.2 (GCC) $ uname -a Linux localhost.localdomain 2.6.29-3.ydl61.3 #1 SMP Thu Jun 25 12:22:41 EDT 2009 ppc64 ppc64 ppc64 GNU/Linux
[Bug tree-optimization/55329] [4.8 Regression] ICE: internal compiler error: in operator[], at vec.h:487 with -O -fno-guess-branch-probability -fnon-call-exceptions --param=early-inlining-insns=111
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55329 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-15 11:26:25 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=193157 but looks unrelated to the ICE, so probably it has been just latent before.
[Bug c++/55339] Generated code hangs with -O2 on Linux ppc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55339
--- Comment #1 from anton.katilin at gmail dot com 2012-11-15 11:28:32 UTC ---
Compile with:
-
export PATH=/opt/gcc-4.7.2/bin:$PATH
g++ -m32 -fPIC -O2 *.cpp -o test-O2.bin
g++ -m32 -fPIC -O1 *.cpp -o test-O1.bin
Please find the source code of the test below.
-
Test.cpp
-
#include stdio.h
#include Foo.h
int main() {
try {
printf(entering...\n);
fflush(stdout);
YS(-1); // will throw exception
printf(must never reach\n);
}
catch (int) {
printf(exception caught, as expected\n);
}
printf(OK\n);
return 0;
}
-
Foo.h
-
#pragma once
void foo();
void checkPositive(int);
class YS {
public:
YS(int capacity) {
checkPositive(capacity);
}
~YS() {
foo();
}
};
void throwException(const YS);
-
Foo.cpp
-
#include Foo.h
void foo() {
}
void checkPositive(int v) {
if (v = 0) {
throwException(10);
}
}
void throwException(const YS) {
throw int(1);
}
[Bug tree-optimization/55329] [4.8 Regression] ICE: internal compiler error: in operator[], at vec.h:487 with -O -fno-guess-branch-probability -fnon-call-exceptions --param=early-inlining-insns=111
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55329 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-15 11:29:24 UTC --- Yep, it does not seem inliner related bug...
[Bug c++/55339] C++ code compiled with -O2 on Linux ppc hangs in runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55339 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Severity|critical|normal
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-11-15
Ever Confirmed|0 |1
--- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-15
11:42:21 UTC ---
OK, it is not base_address, but base_object
Creating dr for MEM[(real(kind=8)[4] *)x + 58071104B][0]
analyze_innermost: success.
base_address: x
offset from base address: 0
constant offset from base address: 58071104
step: 0
aligned to: 128
base_object: MEM[(real(kind=8)[4] *)x + 58071104B]
Access function 0: 0
I do not see why we need to keep the base object to be offsetted.
While it is first time I see the code, i think it is trying to look for
MEM_REFs and remember the fact that after putting it to 0 the offset may go
across the type boundry, since we changed the type via MEM_REF. For
non-envolving mem-refs this however is not a problem.
I am testing the following that simply removes the constant from MEM_REF
Index: tree-data-ref.c
===
--- tree-data-ref.c(revision 193503)
+++ tree-data-ref.c(working copy)
@@ -922,6 +922,16 @@ dr_analyze_indices (struct data_referenc
DR_UNCONSTRAINED_BASE (dr) = true;
VEC_safe_push (tree, heap, access_fns, access_fn);
}
+ else
+{
+ if (!integer_zerop (TREE_OPERAND (ref, 1)))
+ref = fold_build2_loc (EXPR_LOCATION (ref),
+ MEM_REF, TREE_TYPE (ref),
+ op,
+ build_int_cst (TREE_TYPE (TREE_OPERAND (ref,
+ 1)),
+ 0));
+}
}
else if (DECL_P (ref))
{
[Bug middle-end/55331] [4.6/4.7/4.8 Regression] ICE: SIGSEGV in substitute_and_fold with -O2 -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55331
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-11-15
11:52:43 UTC ---
Hand-reduced testcase for -O2 -fno-tree-fre
struct A {};
void
foo (A *p, bool x)
{
A a;
char *e = (char *) (a + 1);
if (x)
__builtin_memmove (p, a, e - (char *) a);
}
[Bug middle-end/55331] [4.6/4.7/4.8 Regression] ICE: SIGSEGV in substitute_and_fold with -O2 -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55331 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-11-15 12:00:21 UTC --- Created attachment 28697 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28697 gcc48-pr55331.patch Untested fix.
[Bug target/44578] GCC generates MMX instructions but fails to generate emms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Known to work|| --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-15 12:06:34 UTC --- Using mmX as global registers variables is a user bug if you ever call something that might be using FPU stack, because the registers can't be preserved across that. Don't do that.
[Bug middle-end/55331] [4.6/4.7/4.8 Regression] ICE: SIGSEGV in substitute_and_fold with -O2 -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55331 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug c++/55340] New: Invalid maybe unitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55340 Bug #: 55340 Summary: Invalid maybe unitialized warning Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jwillem...@remedy.nl Created attachment 28698 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28698 gzip with both preprocessed files We have in some of our tests a warning that a variable may be used unitialized, but we have validated that this is not the case (as far as we could tell). We tried to reduce our code to a minimum, but the strange thing is that when we remove some not related code, the warning is gone. Attached 2 preprocessed files, t.cpp t2.cpp, compile using: g++ --std=c++0x -fno-strict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden -O3 -ggdb -m64 -pthread -Wall -W -Wpointer-arith -pipe -D_GNU_SOURCE-c t.cpp When compiling t.cpp we get: In file included from testC.cpp:26:0: testC.h: In member function ‘void Test::union_union::swap(Test::union_union)’: testC.h:764:3: warning: ‘*((void*)( intermediate)+8).Test::unionType::disc_’ may be used uninitialized in this function [-Wmaybe-uninitialized] testC.h:1325:27: note: ‘*((void*)( intermediate)+8).Test::unionType::disc_’ was declared here When compiling t2.cpp there is no warning. If you check the diff between t.cpp and t2.cpp you will see that the code that triggers the warning is still there. We have reduced the code to the point that removal of any type would not trigger the warning.
[Bug fortran/55341] New: address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Bug #: 55341
Summary: address-sanitizer and Fortran
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
Hardly a bug, rather a feature... it seems '-faddress-sanitizer' works with
Fortran seemingly out-of-the-box. Great!
could it be documented a being for c/c++/Fortran ?
Both these testcases work ('fail') as expected:
PROGRAM TEST_ASAN_01
INTEGER :: A(10)
i=-1
A(i)=0
END PROGRAM
PROGRAM TEST_ASAN_02
INTEGER, POINTER :: x1,x2,x3
ALLOCATE(X1)
X2=X1
DEALLOCATE(X1)
X2=0
END PROGRAM
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #40 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-15 13:46:32 UTC --- (In reply to comment #39) I agree with Kostya that no major changes to mach_override are necessary because we are really going to dump it. However minor fixes required for ASan in GCC to work on Darwin right now should be perfectly ok. As there currently are issues blocking the dynamic ASan runtime (e.g. https://code.google.com/p/address-sanitizer/issues/detail?id=124), and we still depend on CoreFoundation I can't promise that we'll get rid of mach_override before the GCC 4.8 release. Now that you have committed the patch from comment 29 to upstream compiler-rt... http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155989.html can we at least get missing mach_override/mach_override.h and mach_override/mach_override.c files imported into the asan branch, if not gcc trunk, as well as the approved patch from... http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01119.html so that we can start building libsanitizer on intel darwin? Thanks in advance for any help on these issues.
[Bug target/55332] [4.8 Regression] libsanitizer breaks build on hpux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55332 --- Comment #2 from dave.anglin at bell dot net 2012-11-15 13:47:24 UTC --- On 15-Nov-12, at 5:38 AM, jakub at gcc dot gnu.org wrote: It doesn't break bootstrap any longer, configure.tgt should enable it solely on i?86/x86_64-linux right now. I have a patch which enables build on hppa-linux but it's unclear whether the library works. -- John David Anglindave.ang...@bell.net
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289
--- Comment #41 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-15
13:51:11 UTC ---
I will also post a small patch to gcc-patches to allow darwin to automatically
pass the required linker flags on the link spec in darwin.h...
ndex: gcc/config/darwin.h
===
--- gcc/config/darwin.h(revision 193503)
+++ gcc/config/darwin.h(working copy)
@@ -180,6 +180,8 @@ extern GTY(()) int darwin_ms_struct;
%{L*} %(link_libgcc) %o
%{fprofile-arcs|fprofile-generate*|coverage:-lgcov} \
%{fopenmp|ftree-parallelize-loops=*: \
%{static|static-libgcc|static-libstdc++|static-libgfortran: libgomp.a%s;
: -lgomp } } \
+%{faddress-sanitizer: \
+ %{static|static-libgcc|static-libstdc++|static-libgfortran: -framework
CoreFoundation libasan.a%s; : -framework CoreFoundation -lasan } } \
%{fgnu-tm: \
%{static|static-libgcc|static-libstdc++|static-libgfortran: libitm.a%s;
: -litm } } \
%{!nostdlib:%{!nodefaultlibs:\
It works fine for the dynamic linkage although we do seem to have an issue with
the static libasan.a that will require a new PR to be opened...
% gcc-fsf-4.8 -faddress-sanitizer -O1 -fno-omit-frame-pointer -static-libgcc
-g -o use-after-free use-after-free.c
Undefined symbols for architecture x86_64:
___cxa_throw, referenced from:
__asan::InitializeAsanInterceptors() in
libasan.a(asan_interceptors.o)
(maybe you meant: __interception::real___cxa_throw, _wrap___cxa_throw )
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
However I don't see that as a blocker to getting libsanitizer building on intel
darwin.
[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 --- Comment #14 from dodji at seketeli dot org dodji at seketeli dot org 2012-11-15 13:52:18 UTC --- mattyclarkson at gmail dot com gcc-bugzi...@gcc.gnu.org a écrit: @Dodji, thanks for fixing this :) You are welcome. Sorry for the delay. What release will this be in? 4.8.1? As Jon said, 4.8.0. Cheers.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-11-15 14:02:47 UTC --- Trying -faddress-sanitizer on CP2K leads to the following failure: cat bug.f90 MODULE qs_environment_types TYPE rt_prop_type INTEGER,DIMENSION(:,:),ALLOCATABLE:: orders END TYPE rt_prop_type TYPE qs_environment_type TYPE(rt_prop_type),POINTER:: rtp END TYPE qs_environment_type CONTAINS SUBROUTINE set_qs_env(qs_env,rtp) TYPE(qs_environment_type), POINTER:: qs_env TYPE(rt_prop_type), OPTIONAL, POINTER :: rtp IF (PRESENT(rtp)) qs_env%rtp=rtp END SUBROUTINE set_qs_env END MODULE qs_environment_types gfortran -O0 -faddress-sanitizer bug.f90 bug.f90: In function ‘set_qs_env’: bug.f90:9:0: error: type mismatch in binary expression SUBROUTINE set_qs_env(qs_env,rtp) ^ unsigned long integer(kind=8) unsigned long _182 = _181 - 1; bug.f90:9:0: error: type mismatch in binary expression unsigned long integer(kind=8) unsigned long _206 = _205 - 1; bug.f90:9:0: internal compiler error: verify_gimple failed 0x9a47ac verify_gimple_in_cfg(function*) ../../gcc/gcc/tree-cfg.c:4728 0x8dad97 execute_function_todo ../../gcc/gcc/passes.c:1979 0x8db75d execute_todo ../../gcc/gcc/passes.c:2008 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.
[Bug bootstrap/53300] [4.8 Regression] AIX bootstrap related to varpool patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53300 --- Comment #19 from David Edelsohn dje at gcc dot gnu.org 2012-11-15 14:04:10 UTC --- The problem still is present, but when I asked Honza about the status on IRC, he seemed to say the work-around patch was the correct fix -- that this behavior is expected.
[Bug other/55304] libsanitizer can't be used with GCC autoconf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55304
Igor Zamyatin izamyatin at gmail dot com changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #7 from Igor Zamyatin izamyatin at gmail dot com 2012-11-15
14:09:09 UTC ---
That's strange but on x86 I see
CDPATH=${ZSH_VERSION+.}: cd ../../../libsanitizer /bin/sh
/export/users/izamyati/tmp_gcc/missing --run aclocal-1.11 -I .. -I ../config
configure.ac:5: error: Please use exactly Autoconf 2.64 instead of 2.68.
../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:5: the top level
autom4te: m4 failed with exit status: 1
aclocal-1.11: autom4te failed with exit status: 1
make[2]: *** [../../../libsanitizer/aclocal.m4] Error 1
during build for following configuration
../configure --disable-bootstrap --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --with-fpmath=sse
--enable-languages=c,c++,fortran
My head is at r193515.
Did I miss anything?
[Bug other/55304] libsanitizer can't be used with GCC autoconf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55304
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2012-11-15 14:11:54
UTC ---
(In reply to comment #7)
That's strange but on x86 I see
CDPATH=${ZSH_VERSION+.}: cd ../../../libsanitizer /bin/sh
/export/users/izamyati/tmp_gcc/missing --run aclocal-1.11 -I .. -I ../config
configure.ac:5: error: Please use exactly Autoconf 2.64 instead of 2.68.
../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:5: the top level
autom4te: m4 failed with exit status: 1
aclocal-1.11: autom4te failed with exit status: 1
make[2]: *** [../../../libsanitizer/aclocal.m4] Error 1
during build for following configuration
../configure --disable-bootstrap --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --with-fpmath=sse
--enable-languages=c,c++,fortran
My head is at r193515.
Did I miss anything?
You must run
# ./contrib/gcc_update --touch
[Bug c++/55340] Invalid maybe unitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55340 --- Comment #1 from Johnny Willemsen jwillemsen at remedy dot nl 2012-11-15 14:17:38 UTC --- Lowering optimization from -O3 to -O2 removes the warning
[Bug other/55304] libsanitizer can't be used with GCC autoconf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55304 --- Comment #9 from Igor Zamyatin izamyatin at gmail dot com 2012-11-15 14:25:42 UTC --- Thanks, this helped
[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051 --- Comment #25 from Teresa Johnson tejohnson at google dot com 2012-11-15 14:34:10 UTC --- On Thu, Nov 15, 2012 at 2:56 AM, hubicka at ucw dot cz gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051 --- Comment #24 from Jan Hubicka hubicka at ucw dot cz 2012-11-15 10:56:53 UTC --- Note though that this is not an assert. It just emits a message to stderr. Do you think a better error message is appropriate? I'm not sure the some data files may have been removed is an accurate description of the issue. Perhaps something like Profile data file mismatch may indicate corrupt profile data? Well, we should figure out why sum_all starts to diverge. If we had problems mixing cc1 and cc1plus executions, we should get mismatches in number of counters. Right, it doesn't appear to be different executables since the number of counters is identical. I'll instrument it and see if I can figure out why they diverge. What happens after the miscompare? A flag is set so that the error is emitted at most once per merge, and then we continue on with the merge and ignore it. Basically what it is doing is saving the first merged summary (for the first object file's gcda we merge into), and then for each additional object file that gets its counters merged the resulting program summary is compared against the saved program summary. But only if the number of runs is the same as the saved summary. This could happen if the gcda files are walked in a different order during updates (i.e. the gcov_list is in a different order for different processes of the same executable), but I am not sure if that can happen. Teresa Honza -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug c++/55339] C++ code compiled with -O2 on Linux ppc hangs in runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55339 --- Comment #2 from anton.katilin at gmail dot com 2012-11-15 14:35:12 UTC --- An update: There is no problem when linking statically, i.e. if we do g++ -m32 -fPIC -O2 *.cpp -static-libstdc++ -static-libgcc -o test-O2.bin instead of g++ -m32 -fPIC -O2 *.cpp -o test-O2.bin
[Bug c++/55275] abi_tag attribute doesn't work on explicit specializations of class templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55275 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2012-11-15 14:48:41 UTC --- Fixed.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #42 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-15 15:03:53 UTC --- Jack, Thanks for the patch in comment #37. I had to do some minor surgery to adjust it to revision 193528, but otherwise it worked as expected for both -m32 and -m64 even with gfortran. I think it should go to trunk as an experimental feature (see pr55341).
[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test rnflow degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-15 15:07:33 UTC --- Is the slowdown still reproducing with my patch? Most of it (if not all) is gone with the patch: 23.96s with '-fprotect-parens -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program -flto' compared to 23.37s with '-fprotect-parens -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program -flto -fno-tree-loop-if-convert'.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #43 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-15 15:12:31 UTC --- Posted updated patch to adjust for bit-rot from the libsanitizer multilib support checkin and add required spec handling to gcc/config/darwin.h. Ignore my previous comment about the static build failing. This was a glitch in my fink packaging where I deleted the libstdc++.la from dependency_libs= in libasan.la. So we have no issues with using libasan.a. http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01251.html
[Bug rtl-optimization/55342] New: [LRA,x86] Non-optimal code for simple loop with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55342
Bug #: 55342
Summary: [LRA,x86] Non-optimal code for simple loop with LRA
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ysrum...@gmail.com
Target: x86
For a simple test-case we got -15% regression with LRA on x86 in 32-bit mode.
The test-case is
#define byte unsigned char
#define MIN(a, b) ((a) (b)?(b):(a))
void convert_image(byte *in, byte *out, int size) {
int i;
byte * read = in,
* write = out;
for(i = 0; i size; i++) {
byte r = *read++;
byte g = *read++;
byte b = *read++;
byte c, m, y, k, tmp;
c = 255 - r;
m = 255 - g;
y = 255 - b;
if (c m)
k = MIN (c, y);
else
k = MIN (m, y);
*write++ = c - k;
*write++ = m - k;
*write++ = y - k;
*write++ = k;
}
}
The essential part of assembly is (it is correspondent to write-part of loop):
without LRA
.L4:
movl%esi, %ecx
addl$4, %eax
subl%ecx, %ebx
movzbl3(%esp), %ecx
movb%bl, -4(%eax)
movl%esi, %ebx
subl%ebx, %edx
movb%dl, -2(%eax)
subl%ebx, %ecx
movb%cl, -3(%eax)
cmpl%ebp, 4(%esp)
movb%bl, -1(%eax)
je.L1
with LRA
.L4:
movl%esi, %eax
subl%eax, %ebx
movl28(%esp), %eax
movb%bl, (%eax)
movl%esi, %eax
subl%eax, %ecx
movl28(%esp), %eax
movb%cl, 1(%eax)
movl%esi, %eax
subl%eax, %edx
movl28(%esp), %eax
movb%dl, 2(%eax)
addl$4, %eax
movl%eax, 28(%esp)
movl28(%esp), %ecx
movl%esi, %eax
cmpl%ebp, (%esp)
movb%al, -1(%ecx)
je.L1
I also wonder why additional moves are required to perform subtraction:
movl %esi, %eax
subl %eax, %ebx
whereas only one instruction is required:
subl %esi, %ebx.
I assume that this part is not related to LRA.
[Bug other/19165] (Natural) language independent error / warning classification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165 --- Comment #14 from Clemens clemens1509 at web dot de 2012-11-15 15:32:11 UTC --- As describt in duplication Bug 55336 I would extend the xml for compound messages p.e. a warning/error which points to 2 source positions like member initialisation and member position. In fact it is only one bug, but gcc displays more.
[Bug c++/54903] [4.8 Regression] Auto + static in-class constant initialization not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54903 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2012-11-15 16:12:03 UTC --- Author: jason Date: Thu Nov 15 16:11:56 2012 New Revision: 193535 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193535 Log: PR c++/54903 * decl2.c (mark_used): Don't complain about auto in templates. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto36.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c
[Bug tree-optimization/55286] [4.7/4.8 Regression] Bytemark ASSIGNMENT 4% - 10% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55286 --- Comment #2 from wbrana wbrana at gmail dot com 2012-11-15 16:12:57 UTC --- Created attachment 28699 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28699 function Assignment without 175752
[Bug tree-optimization/55286] [4.7/4.8 Regression] Bytemark ASSIGNMENT 4% - 10% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55286 --- Comment #3 from wbrana wbrana at gmail dot com 2012-11-15 16:16:05 UTC --- Created attachment 28700 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28700 function Assignment with 175752 according to gprof Assignment is called 1574 times without 175752 1449 times with 175752
[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55325 --- Comment #15 from Uros Bizjak ubizjak at gmail dot com 2012-11-15 16:23:51 UTC --- (In reply to comment #14) (In reply to comment #13) [1] http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01198.html Thanks. Note that pa handles 'q'. So, let's auto-detect support for non-standard suffixes in patch v2 [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01263.html
[Bug tree-optimization/55329] [4.8 Regression] ICE: internal compiler error: in operator[], at vec.h:487 with -O -fno-guess-branch-probability -fnon-call-exceptions --param=early-inlining-insns=111
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55329 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 #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-15 16:31:10 UTC --- Created attachment 28701 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28701 gcc48-pr55329.patch Untested fix. The problem is that clearing bits in a bitmap while it is being iterated using EXECUTE_IF_SET_IN_BITMAP is dangerous and can't work reliably, in this case the bitmap contained just a single bit, that got cleared and replaced by a smaller bit (the clearing removed the only bitmap_element, setting reused it with different index (smaller) with higher bits set in it). In gimple_purge_all_dead_eh_edges it is just a few extra instructions to process the forwarder blocks (it quickly finds out that they don't have any EDGE_EH edges and does nothing for them), so IMHO it doesn't matter much if we don't clear those bits. On the other side, if there could be multiple forwarder blocks, we might risk we don't handle them correctly, as they could have bb's with lower indexes as successors.
[Bug rtl-optimization/55342] [LRA,x86] Non-optimal code for simple loop with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55342 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||ubizjak at gmail dot com, ||vmakarov at redhat dot com Target Milestone|--- |4.8.0
[Bug c++/54903] [4.8 Regression] Auto + static in-class constant initialization not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54903 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2012-11-15 16:47:45 UTC --- Fixed.
[Bug fortran/55343] New: Renamed C_PTR entities are not treated as equivalent types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55343 Bug #: 55343 Summary: Renamed C_PTR entities are not treated as equivalent types. Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: juno.kr...@nih.gov When the intrinsic C_PTR type is accessed via a local name, it is no longer treated as equivalent to the C_PTR type under either the original name or any other different local name. Example code: (test_rename.f90) - module my_mod implicit none type int_type integer :: i end type int_type end module my_mod program main use iso_c_binding, only: C_void_ptr=C_ptr, C_string_ptr=C_ptr use my_mod, only: i1_type=int_type, i2_type=int_type implicit none type(C_string_ptr) :: p_string type(C_void_ptr) :: p_void type (i1_type) :: i1 type (i2_type) :: i2 p_void = p_string i1 = i2 end program main --- Result: $ gfortran -c test_rename.f90 test_rename.f90:15.11: p_void = p_string 1 Error: Can't convert TYPE(c_string_ptr) to TYPE(c_void_ptr) at (1) I included a user defined derived type to illustrate that the equivalence of renamed entities in that case works as expected. This used to work in Gnu fortran, but I don't know what version I was using at that time. (For comparison: Intel compilers handle it correctly. The latest Sun/Oracle works when assigning from C_PTR to a renamed entity, but not the other way around.)
[Bug tree-optimization/54619] GCC aborts during compilation with '-O2 -mips16'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54619 --- Comment #3 from vries at gcc dot gnu.org 2012-11-15 16:50:04 UTC --- Author: vries Date: Thu Nov 15 16:49:45 2012 New Revision: 193537 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193537 Log: 2012-11-15 Tom de Vries t...@codesourcery.com PR tree-optimization/54619 * tree-ssa-loop-ivopts.c (get_use_type): New function. (get_computation_at): Use get_use_type. (get_computation_cost_at): Declare and set mem_mode. Use mem_mode. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug tree-optimization/54619] GCC aborts during compilation with '-O2 -mips16'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54619 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | --- Comment #4 from vries at gcc dot gnu.org 2012-11-15 16:55:13 UTC --- Patch checked in, resolving as fixed.
[Bug tree-optimization/55286] [4.7/4.8 Regression] Bytemark ASSIGNMENT 4% - 10% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55286 --- Comment #4 from wbrana wbrana at gmail dot com 2012-11-15 17:01:22 UTC --- Bytemark source code http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz
[Bug target/44578] GCC generates MMX instructions but fails to generate emms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578
--- Comment #6 from kl4yfd at gmail dot com 2012-11-15 17:05:16 UTC ---
(In reply to comment #5)
Using mmX as global registers variables is a user bug if you ever call
something that might be using FPU stack, because the registers can't be
preserved across that. Don't do that.
When running x86 in protected mode, you are right. User-error.
This is not for an error within the binary, rather an issue with the processor
state left-over after executable is finished.
For those of us not running in a protected mode / OS environment, ending a
binary execution that calls mmX instructions and does not issue emms leaves the
FPU essentially disabled.
One should never have to manually insert the opcodes 0F 77 into the binary for
proper inter-binary execution in a non-protected mode x86 environment and the
FPU being enabled should be the default assumption.
The example file is only to show that gcc has 3 bugs in its current mmx
handling:
- will auto-generate mmX opcodes, then not auto-generate the emms OP.
- mmX opcodes were generated without the -mmmx flag.
- when -mmmx flag is used, emms OP is not inserted by default before return.
OK. Why not?
-- Implementing this would be a great catch-all solution for many problems
associated with drivers, embedded, or the compiler using mmx
OPs/registers/inline-asm then not inserting an emms OP before returning.
^^ this will probably require some discussion ^^
If GCC is going to allow neat-features like global register variables, then it
needs to be checked to ensure they are properly used.
--
- This is part of the fix (mostly real code...)
- Also a similar check is needed whereever something that generates mmX OPs is
used. (like scoped mmX register variables) etc
- This does not address the fact that no emms is generated. That should be
covered by the catch-all -mmmx flag usage auto-inserts emms opcode @ binary
end.
-- If that ends up being the solution.
=== From gcc/varasm.c | line:1209 | gcc 4.7.2 ===
/* First detect errors in declaring global registers. */
if (reg_number == -1)
error (register name not specified for %q+D, decl);
/// New PsuedoCode
else if (MMX_REGNO_P(reg_number) ) {
if ( !(-mmmx) )
error (mmx register usage requires -mmmx flag for %q+D,
decl);
if ( !(-mfpmath=sse) )
error (mmx register usage requires -mfpmath=sse flag for
%q+D, decl);
///
}
else if (reg_number 0)
error (invalid register name for %q+D, decl);
else if (mode == BLKmode)
error (data type of %q+D isn%'t suitable for a register,
decl);
[Bug middle-end/55321] [4.8 regression] Ada bootstrap failure on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55321 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Component|bootstrap |middle-end --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-15 17:36:27 UTC --- Are you really sure about the 20121028 date?
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #44 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-15 17:53:40 UTC --- Posted the final revision of the patch that now properly handles static linkage options with -faddress-sanitizer... http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01285.html For example... % gcc-fsf-4.8 -faddress-sanitizer -O1 -fno-omit-frame-pointer -g -static-libstdc++ -o use-after-free use-after-free.c % otool -L ./use-after-free ./use-after-free: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.12.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /sw/lib/gcc4.8/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) links in libstdc++.a while... % gcc-fsf-4.8 -faddress-sanitizer -O1 -fno-omit-frame-pointer -g -static-libgcc -o use-after-free use-after-free.c % otool -L ./use-after-free ./use-after-free: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.12.0) /sw/lib/gcc4.8/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) links libstdc++.dylib. The standard linkage with... % gcc-fsf-4.8 -faddress-sanitizer -O1 -fno-omit-frame-pointer -g -o use-after-free use-after-free.c % otool -L ./use-after-free ./use-after-free: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.12.0) /sw/lib/gcc4.8/lib/libasan.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /sw/lib/gcc4.8/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) doesn't need to be directly linked against libstdc++ because libasan.0.dylib already is... % otool -L /sw/lib/gcc4.8/lib/libasan.0.dylib /sw/lib/gcc4.8/lib/libasan.0.dylib: /sw/lib/gcc4.8/lib/libasan.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/gcc4.8/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /sw/lib/gcc4.8/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #45 from Iain Sandoe iains at gcc dot gnu.org 2012-11-15 17:58:21 UTC --- (In reply to comment #35) Is that certain to be soon enough Not 100%. I am just warning you. apologies for not much input to this - somewhat tied up with other things. will the new version (did I read somewhere, library interposing?) support the older versions of Darwin/OSX (10.5, 10.6) ? (if not, then there's a place for the existing method).
[Bug target/55344] New: Cross compiling for alpha-linux fails because signal.h doesn't exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55344 Bug #: 55344 Summary: Cross compiling for alpha-linux fails because signal.h doesn't exist Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@danny.cz Created attachment 28702 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28702 fix cross build Cross compiling libgcc for alpha-linux fails because signal.h included from libgcc/config/alpha/linux-unwind.h doesn't exist /builddir/build/BUILD/gcc-4.7.2-20121114-aarch64/alpha-linux-gnu/./gcc/xgcc -B/builddir/build/BUILD/gcc-4.7.2-20121114-aarch64/alpha-linux-gnu/./gcc/ -B/usr/alpha-linux-gnu/bin/ -B/usr/alpha-linux-gnu/lib/ -isystem /usr/alpha-linux-gnu/include -isystem /usr/alpha-linux-gnu/sys-include-g -O2 -mieee -O2 -g -O2 -mieee -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mieee -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fPIC -mieee -I. -I. -I../.././gcc -I../../../gcc-4.7.2-20121114-aarch64/libgcc -I../../../gcc-4.7.2-20121114-aarch64/libgcc/. -I../../../gcc-4.7.2-20121114-aarch64/libgcc/../gcc -I../../../gcc-4.7.2-20121114-aarch64/libgcc/../include -DHAVE_CC_TLS -o unwind-c.o -MT unwind-c.o -MD -MP -MF unwind-c.dep -fexceptions -c ../../../gcc-4.7.2-20121114-aarch64/libgcc/unwind-c.c In file included from ../../../gcc-4.7.2-20121114-aarch64/libgcc/unwind-dw2.c:376:0: ./md-unwind-support.h:28:20: fatal error: signal.h: No such file or directory compilation terminated.
[Bug target/55339] C++ code compiled with -O2 on Linux ppc hangs in runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55339 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||powerpc-linux-gnu Component|c++ |target --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-15 18:06:08 UTC --- --disable-libunwind-exceptions Why did you do that? Though it should not matter for PPC.
[Bug fortran/55345] New: ICE with abstract interface type with use-renamed local names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55345 Bug #: 55345 Summary: ICE with abstract interface type with use-renamed local names Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: juno.kr...@nih.gov If an abstract interface type is renamed in the USE statement, and one of those names includes the original name, an ICE can occur. Example code (bug.f90): -- module mod1 abstract interface subroutine func_t() end subroutine func_t end interface end module mod1 module bug use mod1, func_t=func_t, func1_t=func_t end module bug -- Result: $ gfortran -c bug2.f90 bug.f90:8:0: internal compiler error: in gfc_trans_use_stmts, at fortran/trans-decl.c:3886 Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. If the two USE statements are switched, no ICE occurs. It also succeeds if the rename statements are within an ONLY list.
[Bug c/55322] Suggestion: Warn suspicious usage of arrays of structures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55322 --- Comment #2 from Wolf stilgarwolf at gmail dot com 2012-11-15 18:23:51 UTC --- I know it's legal, but it may be suspicious, like many other legal statements which are, optionally, warned. Anyway, such optional warning may be helpful.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #46 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-15 18:28:44 UTC --- (In reply to comment #45) (In reply to comment #35) Is that certain to be soon enough Not 100%. I am just warning you. apologies for not much input to this - somewhat tied up with other things. will the new version (did I read somewhere, library interposing?) support the older versions of Darwin/OSX (10.5, 10.6) ? (if not, then there's a place for the existing method). See... http://code.google.com/p/address-sanitizer/issues/detail?id=64 The interpose example code works fine here under 10.6.8.
[Bug middle-end/55321] [4.8 regression] Ada bootstrap failure on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55321 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2012-11-15 18:47:31 UTC --- (In reply to comment #2) Are you really sure about the 20121028 date? Yes, 4.8-20121012 aka r192660 built fine, 20121104 and 2012 failed; unfortunately I don't have the 20121104 build log any more so I can't check exactly how it failed. Do you want me to run a bisection?
[Bug middle-end/55321] [4.8 regression] Ada bootstrap failure on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55321 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-15 18:56:21 UTC --- Yes, 4.8-20121012 aka r192660 built fine, 20121104 and 2012 failed; unfortunately I don't have the 20121104 build log any more so I can't check exactly how it failed. The reduced testcase fails with the 20121027 sources for me. Do you want me to run a bisection? That's probably superfluous, I have a reasonable fix.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #47 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-15 19:09:00 UTC --- (In reply to comment #46) (In reply to comment #45) (In reply to comment #35) Is that certain to be soon enough Not 100%. I am just warning you. apologies for not much input to this - somewhat tied up with other things. will the new version (did I read somewhere, library interposing?) support the older versions of Darwin/OSX (10.5, 10.6) ? (if not, then there's a place for the existing method). See... http://code.google.com/p/address-sanitizer/issues/detail?id=64 The interpose example code works fine here under 10.6.8. The interpose example code also works fine under 10.5.8 on a dual G5.
[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #48 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-15 19:19:06 UTC --- As proof that the current mach_override.h and mach_override.c from current compiler-rt svn are reasonable to use for gcc 4.8.0, I compiled the complete Polyhedron 2005 benchmark with... gfortran-fsf-4.8 -O1 -g -fno-omit-frame-pointer -faddress-sanitizer %n.f90 -o %n and gfortran-fsf-4.8 -O3 -funroll-loops -ffast-math -g -fno-omit-frame-pointer -faddress-sanitizer %n.f90 -o %n and in both cases each benchmark runs without any error output from mach_override.c.
[Bug other/48983] No diagnostic message about no space left on device with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48983 --- Comment #3 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2012-11-15 19:26:38 UTC --- And this is not particularly useful: lto1: fatal error: short write.
[Bug rtl-optimization/55346] New: var-tracking generates incomplete/inaccurate debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55346 Bug #: 55346 Summary: var-tracking generates incomplete/inaccurate debug info Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ea...@eagercon.com Created attachment 28703 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28703 Test program Var-tracking is does not record the lifetime of variables allocated to registers correctly, resulting in gdb displaying the variable as optimized out when it is live. I've confirmed this problem on x86 and arm. The test case is a loop which parses command line options, indexed by integer variable argno. When compiled with -g -O2, argno is allocated to rbx, which is never reused. The DWARF location list which is generated from NOTE_INSN_VAR_LOCATION insns, shows disjoint allocations for argno, omitting PC ranges where the variable is live in rbx. The DWARF location list has argno as literal 1 beyond the instruction where it is allocated to rbx. Argno is defined as rbx starts several instructions after it is allocated and ends premature. Var-tracking inserts a NOTE_INSN_VAR_LOCATION for argno as const int 1 at the start of the BB #2, but one is not inserted when argno is allocated to rbx later in BB #2. One is generated later, in BB #5. Var-tracking inserts a (nil) NOTE_INSN_VAR_LOCATION for argno after BB #3 (branch to epilogue), although argno is live and is used in BB #4, immediately following BB #3. Either this should not be generated or another NOTE_INSN_VAR_LOCATION for argno should be generated at the start of BB #4.
[Bug rtl-optimization/55346] var-tracking generates incomplete/inaccurate debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55346 --- Comment #1 from Michael Eager eager at eagercon dot com 2012-11-15 19:53:53 UTC --- Created attachment 28704 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28704 Disassembly and location list
[Bug fortran/55345] ICE with abstract interface type with use-renamed local names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55345 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-15 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-15 20:04:19 UTC --- Confirmed for 4.6.3. The ICE has been fixed for 4.7 between revisions 183001 (2012-01-09, ICE) and 183091 (2012-01-11, OK). Revision 183010 seems a good candidate for the fix. The last comment for pr51578 says: FIXED on the trunk (GCC 4.7). Too big for backporting [esp. as no one has reported the bug/regression for years]. So please update your gfortran to 4.7.2.
[Bug c++/55325] [4.8 Regression]: g++.dg/cpp0x/constexpr-complex.C excess errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55325 --- Comment #16 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-15 20:06:32 UTC --- (In reply to comment #15) So, let's auto-detect support for non-standard suffixes in patch v2 [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01263.html JFTR, I see there's a v3: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01291.html Nice. Thanks.
[Bug other/48983] No diagnostic message about no space left on device with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48983 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-15 20:23:43 UTC --- Other gnu projects use gnulib functions to handle these: http://lists.gnu.org/archive/html/bug-findutils/2005-01/msg00033.html Perhaps GCC should start using more of gnulib?
[Bug other/54279] [4.8 Regression] first stage build with g++ fails with . as the first component of $PATH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54279 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-15 20:29:12 UTC --- (In reply to comment #5) libmudflap has the similar issue. Actually the libmudflap is fixed by fixing libstdc++. Anyways I have a full fix now. I am retesting it again.
[Bug bootstrap/53866] [4.8 Regression] lto-bootstrap failed at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53866 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2012-11-15 20:31:18 UTC --- Revision gave 193535: /export/gnu/import/git/gcc/gcc/c/c-parser.c: In function \u2018c_parser_postfix_expression_after_primary(c_parser*, unsigned int, c_expr)\u2019: /export/gnu/import/git/gcc/gcc/c/c-parser.c:6917:16: error: \u2018origtypes\u2019 may be used uninitialized in this function [-Werror=maybe-uninitialized] origtypes);
[Bug c++/55347] New: Specialized member of class template prevents visibility setting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55347
Bug #: 55347
Summary: Specialized member of class template prevents
visibility setting
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@mit.edu
Compiling this code:
--- cut here ---
templatetypename T
class A
{
void func() {}
};
//#pragma GCC visibility push(default) -- no effect
template void Aint::func() {} // This causes a problem
template class __attribute__((visibility(default))) Aint;
//#pragma GCC visibility pop
--- cut here ---
results in:
template_visibility.cc:10:55: warning: type attributes ignored after type is
already defined [-Wattributes]
The emitted code ends up hidden.
This is a minor issue in C++98 (I'm not sure why you'd want to do this), but
it's an actual problem in C++11: extern templates behave the same way.
I think that gcc's behavior is consistent, but there should be a way to
override the visibility of a particular class template specialization *without
instantiating/defining it*, then specialize a member, then instantiate the
template.
[Bug rtl-optimization/55346] var-tracking generates incomplete/inaccurate debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55346 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-11-15 21:42:34 UTC --- Which gcc version exactly (svn rev or date) you were using? I can't reproduce this on x86_64-linux with current trunk and -g -O2. 268: Abbrev Number: 4 (DW_TAG_variable) 69 DW_AT_name: (indirect string, offset: 0x74): argno 6d DW_AT_decl_file : 1 6e DW_AT_decl_line : 4 6f DW_AT_type: 0x124 73 DW_AT_location: 0x98(location list) ... 0098 00400420 00400437 (DW_OP_lit1; DW_OP_stack_value) 0098 00400437 00400483 (DW_OP_reg3 (rbx)) 0098 00400483 00400488 (DW_OP_breg3 (rbx): -1; DW_OP_stack_value) 0098 00400488 00400491 (DW_OP_reg3 (rbx)) 0098 0040049f 004004cc (DW_OP_reg3 (rbx)) 0098 End of list The only gap in there is in between 491 and 49f, and that is the epilogue: 400491: 0f 1f 80 00 00 00 00nopl 0x0(%rax) 400498: 5b pop%rbx 400499: 5d pop%rbp 40049a: 31 c0 xor%eax,%eax 40049c: 41 5c pop%r12 40049e: c3 retq 40049f: 90 nop I can reproduce it with r192900 though, so I bet this is a dup of PR54693 (which after all was your testcase).
[Bug target/54829] bad optimization: sub followed by cmp w/ zero (x86 ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829 --- Comment #7 from Daniel Santos daniel.santos at pobox dot com 2012-11-15 21:56:02 UTC --- First off, I apologize for my late response here. (In reply to comment #5) I'm going to respond a little backwards.. In fact, on ARM there is no branch instruction that can be used for 0 as a side effect of a subtract. To get the desired effect the code would have to be completely re-arranged to factor out the 0 (bmi) and then == 0 (beq) cases first. I'm not an ARM programmer, but I'm looking at my reference book and it would appear that BGT would perform a branch of greater than for signed comparison and and BHI for unsigned comparison. Again, convert the subtraction into a comparison (subtract, but discard the result) and branch based upon the flags (for signed numbers): cmpr0, r1 bgt.L1 bne.L2 ;handle equality here Alternately, if the code to execute for each condition will not change the result flags, then the use of condition instructions could replace the branches. In this example there is no need to check for equality because the previous two branch instructions eliminate all other possibilities. The reason that my C code example above does *not* check for equality is that it is the least likely condition and can be determined by eliminating the two most likely conditions (negative or positive and not equal). The result of the comparison is used in more than one instruction, so combine cannot safely rework the branch instructions that follow to ensure that the result of the subtract is used correctly. I suppose I'm going to have to learn the gcc internals. It will probably be good for me anyway. However, If what you say is correct, then the *problem* lies at a higher level than the combine, but it does not invalidate the problem its self. Where do we make the decision that a result can be discarded? That would seem to be where the cause of this problem lies. So to break it down more accurately, if all of these conditions are true: 1.) we perform an integral subtraction, 2.) and every use of the result can be replaced with fewer instructions that use the CPU flags that were changed by the subtraction instead of the result its self, 3.) and no instructions between the subtraction and the last use of its result modify those flags then we should replace the subtract operation with a compare and use the CPU flags instead. I am not aware of any case, when both a and b are of the same signed integral type, where (a - b) 0 and (a - b) 0 cannot be replaced with a b and a b, respectively.
[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #13 from Peter Bergner bergner at gcc dot gnu.org 2012-11-15 22:32:22 UTC --- I'm seeing the same purge_dead_edges ICE on powerpc64-linux: /home/bergner/gcc/gcc-fsf-mainline-base/gcc/testsuite/gcc.dg/torture/pr51106-2.c:13:1: internal compiler error: in purge_dead_edges, at cfgrtl.c:2733 0x10242d27 purge_dead_edges(basic_block_def*) /home/bergner/gcc/gcc-fsf-mainline-base/gcc/cfgrtl.c:2733 0x103bf8e3 instantiate_virtual_regs_in_insn /home/bergner/gcc/gcc-fsf-mainline-base/gcc/function.c:1744 0x103bf8e3 instantiate_virtual_regs /home/bergner/gcc/gcc-fsf-mainline-base/gcc/function.c:1922 Please submit a full bug report,
[Bug rtl-optimization/55346] var-tracking generates incomplete/inaccurate debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55346 --- Comment #3 from Michael Eager eager at eagercon dot com 2012-11-15 22:36:58 UTC --- Top of tree as of Oct 20, 2012. I'll update and verify. On 11/15/2012 01:42 PM, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55346 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-11-15 21:42:34 UTC --- Which gcc version exactly (svn rev or date) you were using? I can't reproduce this on x86_64-linux with current trunk and -g -O2. 268: Abbrev Number: 4 (DW_TAG_variable) 69 DW_AT_name: (indirect string, offset: 0x74): argno 6d DW_AT_decl_file : 1 6e DW_AT_decl_line : 4 6f DW_AT_type: 0x124 73 DW_AT_location: 0x98(location list) ... 0098 00400420 00400437 (DW_OP_lit1; DW_OP_stack_value) 0098 00400437 00400483 (DW_OP_reg3 (rbx)) 0098 00400483 00400488 (DW_OP_breg3 (rbx): -1; DW_OP_stack_value) 0098 00400488 00400491 (DW_OP_reg3 (rbx)) 0098 0040049f 004004cc (DW_OP_reg3 (rbx)) 0098 End of list The only gap in there is in between 491 and 49f, and that is the epilogue: 400491: 0f 1f 80 00 00 00 00nopl 0x0(%rax) 400498: 5b pop%rbx 400499: 5d pop%rbp 40049a: 31 c0 xor%eax,%eax 40049c: 41 5c pop%r12 40049e: c3 retq 40049f: 90 nop I can reproduce it with r192900 though, so I bet this is a dup of PR54693 (which after all was your testcase).
[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #26 from Teresa Johnson tejohnson at google dot com 2012-11-15
22:42:12 UTC ---
On Thu, Nov 15, 2012 at 6:33 AM, Teresa Johnson tejohn...@google.com wrote:
On Thu, Nov 15, 2012 at 2:56 AM, hubicka at ucw dot cz
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #24 from Jan Hubicka hubicka at ucw dot cz 2012-11-15
10:56:53 UTC ---
Note though that this is not an assert. It just emits a message to
stderr. Do you think a better error message is appropriate? I'm not
sure the some data files may have been removed is an accurate
description of the issue. Perhaps something like Profile data file
mismatch may indicate corrupt profile data?
Well, we should figure out why sum_all starts to diverge. If we had
problems mixing cc1 and cc1plus executions, we should get mismatches in
number of counters.
Right, it doesn't appear to be different executables since the number of
counters is identical. I'll instrument it and see if I can figure out why
they diverge.
What happens after the miscompare?
A flag is set so that the error is emitted at most once per merge, and then
we continue on with the merge and ignore it. Basically what it is doing is
saving the first merged summary (for the first object file's gcda we merge
into), and then for each additional object file that gets its counters
merged the resulting program summary is compared against the saved program
summary. But only if the number of runs is the same as the saved summary.
This could happen if the gcda files are walked in a different order during
updates (i.e. the gcov_list is in a different order for different processes
of the same executable), but I am not sure if that can happen.
It appears that this is what is happening, and I think it makes sense
that it can.
We're essentially doing this:
/* Now merge each file. */
for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr-next)
{
// Open existing gcda file for gi_ptr
// Find program summary corresponding to this executable - save in prg
// Merge execution counts for each function
// Merge program summary
// - If this is the first merged file for this execution,
save merged summary in all_prg
// - Otherwise if #runs the same in prg and all_prg,
print error message if prg != all_prg.
// Write merged gcda
}
I found that in a couple cases, we printed the error message for
libcpp/directives.gcda, where the saved all_prg summary was from
gcc/gcc.gcda.
I then instrumented the code so that each time we merge into one of
these 2 gcda files I emit the pids, the number of runs, the number of
counters and the merged sum_all. Comparing the results from all the
merges to these two gcda files I see that most of the time the merges
proceed in the same order, but there are a few cases where the order
is different, resulting in a different sum_all with the same number of
runs, and then things go back to normal and the sum_all matches again.
E.g., here is one place where things get out of order briefly,
resulting in one of the error messages being printed:
...
pid 28432 ppid 28429 Merging summary for
/home/tejohnson/extra/gcc_trunk_3_obj/gcc/gcc.gcda with runs 254 num
13193 sum_all 17058327
pid 28437 ppid 28365 Merging summary for
/home/tejohnson/extra/gcc_trunk_3_obj/gcc/gcc.gcda with runs 255 num
13193 sum_all 17064832
pid 28439 ppid 28367 Merging summary for
/home/tejohnson/extra/gcc_trunk_3_obj/gcc/gcc.gcda with runs 256 num
13193 sum_all 17071340
pid 28440 ppid 28436 Merging summary for
/home/tejohnson/extra/gcc_trunk_3_obj/gcc/gcc.gcda with runs 257 num
13193 sum_all 17177525
...
vs
...
pid 28432 ppid 28429 Merging summary for
/home/tejohnson/extra/gcc_trunk_3_obj/libcpp/directives.gcda with runs
254 num 13193 sum_all 17058327
pid 28439 ppid 28367 Merging summary for
/home/tejohnson/extra/gcc_trunk_3_obj/libcpp/directives.gcda with runs
255 num 13193 sum_all 17064835
pid 28437 ppid 28365 Merging summary for
/home/tejohnson/extra/gcc_trunk_3_obj/libcpp/directives.gcda with runs
256 num 13193 sum_all 17071340
pid 28440 ppid 28436 Merging summary for
/home/tejohnson/extra/gcc_trunk_3_obj/libcpp/directives.gcda with runs
257 num 13193 sum_all 17177525
...
Notice the middle two pids are flipped, resulting in the sum_all being
different after run 255, and back to the same after run 256.
I believe this could happen if pids 28437 and 28439 finished
near-simultaneously, waited for the lock for gcc.gcda, and 28437 won
first, but then by some luck of timing they subsequently both
attempted to open directives.gcda at around the same time and 28439
happened to win the lock in the fcntl loop first.
I believe it is also possible for object files to be in different
orders in the
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #87 from Peter Bergner bergner at gcc dot gnu.org 2012-11-15 22:46:23 UTC --- I noticed this same error on the pr45586*.f90 test cases, but the reduced test case in Comment #86 ICEs for me too on powerpc64-linux.
[Bug c++/55348] New: Problem in tree-ssa-pre.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55348 Bug #: 55348 Summary: Problem in tree-ssa-pre.c Classification: Unclassified Product: gcc Version: 4.8.0 URL: https://github.com/openlink/virtuoso-opensource Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: suffolk...@verizon.net Host: 2.6.32-279.14.1.el6.centos.plus.x86_64 Target: 2.6.32-279.14.1.el6.centos.plus.x86_64 Created attachment 28705 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28705 Failing preprocessed code Output: anon@localhost:372|virtuoso gcc -DHAVE_CONFIG_H -I. -I../../libsrc/Dk -fno-strict-aliasing -O2 -Wall -DNDEBUG -DPOINTER_64 -I/home/anon/src/virtuoso-opensource/libsrc/Xml.new -DOPENSSL_NO_KRB5 -Dlinux -D_GNU_SOURCE -DFILE64 -D_LARGEFILE64_SOURCE -I../../libsrc -I../../libsrc/Dk -I../../libsrc/Wi -I../../libsrc/odbcsdk/include -I../../libsrc/plugin -I../../libsrc/langfunc -DBUILD_THREAD_MODEL=\-t\ -DSHARED_OBJECT -g -O2 -MT libvirtuoso_t_la-viunix.lo -MD -MP -MF -v -fwrapv -Wextra .deps/libvirtuoso_t_la-viunix.Tpo -c viunix.c -o libvirtuoso_t_la-viunix.o viunix.c: In function ‘sigh_do_action’: viunix.c:235:21: warning: unused parameter ‘is_asynchronous’ [-Wunused-parameter] sigh_do_action (int is_asynchronous) ^ viunix.c: At top level: viunix.c:283:1: warning: ‘sigh_report_and_forget’ defined but not used [-Wunused-function] sigh_report_and_forget (int sig) ^ viunix.c: In function ‘VirtuosoServerMain’: viunix.c:559:1: internal compiler error: in compute_antic, at tree-ssa-pre.c:2511 VirtuosoServerMain (int argc, char **argv) ^ 0x9ea778 compute_antic ../.././gcc/tree-ssa-pre.c:2511 0x9ecac1 do_pre ../.././gcc/tree-ssa-pre.c:4709 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. anon@localhost:373|virtuosogcc -v 18:30:39:12-11-15 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++,fortran,java,lto,objc --no-create --no-recursion Thread model: posix gcc version 4.8.0 20121104 (experimental) (GCC) anon@localhost:374|virtuosouname -a 18:30:40:12-11-15 Linux localhost.localdomain 2.6.32-279.14.1.el6.centos.plus.x86_64 #1 SMP Wed Nov 7 00:40:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[Bug rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #14 from Pat Haugen pthaugen at gcc dot gnu.org 2012-11-16 00:11:40 UTC --- Can this be closed? Working fine on powerpc64.
[Bug bootstrap/54795] [4.8 Regression] Random profiledbootstrap failure with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-11-16 00:34:07 UTC --- Revision 193543 gave: lto1: internal compiler error: Segmentation fault 0xb37547 crash_signal ../../src-trunk/gcc/toplev.c:334 0x6c0763 resolve_addr_in_expr ../../src-trunk/gcc/dwarf2out.c:22440 0x6eb6e2 resolve_addr ../../src-trunk/gcc/dwarf2out.c:22636 0x6eb77b resolve_addr ../../src-trunk/gcc/dwarf2out.c:22687 0x6eb77b resolve_addr ../../src-trunk/gcc/dwarf2out.c:22687 0x6eb77b resolve_addr ../../src-trunk/gcc/dwarf2out.c:22687 0x6eb77b resolve_addr ../../src-trunk/gcc/dwarf2out.c:22687 0x6eb77b resolve_addr ../../src-trunk/gcc/dwarf2out.c:22687 0x6eb77b resolve_addr ../../src-trunk/gcc/dwarf2out.c:22687 0x6eb77b resolve_addr ../../src-trunk/gcc/dwarf2out.c:22687 0x6ec76b dwarf2out_finish ../../src-trunk/gcc/dwarf2out.c:23309 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[7]: *** [/tmp/ccAUJBBj.ltrans24.ltrans.o] Error 1 make[7]: *** Waiting for unfinished jobs 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[6]: *** [cc1plus] Error 1
[Bug c++/55348] Problem in tree-ssa-pre.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55348 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-11-16 Ever Confirmed|0 |1 --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2012-11-16 00:34:26 UTC --- Probably a dup of bug 55191. Please try a newer revision of the trunk, a checkout later than 2012-11-08.
[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 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|normal |blocker
[Bug debug/53860] [4.8 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6254 with -fkeep-inline-functions -fdebug-types-section -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53860 Siddhesh Poyarekar siddhesh at redhat dot com changed: What|Removed |Added CC||siddhesh at redhat dot com --- Comment #2 from Siddhesh Poyarekar siddhesh at redhat dot com 2012-11-16 03:00:28 UTC --- (In reply to comment #1) It is caused by revision 188621: http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00531.html This was reverted with r189311, so the ICE is not reproducible anymore.
[Bug lto/54728] [4.8 regression] ICE in input_gimple_stmt, at gimple-streamer-in.c:254
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54728
--- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-16
03:36:35 UTC ---
here is the most reduced testcase.
cat foo1.cc EOF
templatetypename _CharT struct basic_string
{
struct _Rep {_CharT* _M_refdata() throw() { return 0; }};
_CharT * dst;
static _Rep _S_empty_rep();
basic_string() : dst(_S_empty_rep()._M_refdata()) { }
};
extern template class basic_stringchar;
struct basic_ostringstream{
basic_stringchar _M_stringbuf;
};
basic_ostringstream foo1;
EOF
sed s/foo1/foo2/ foo1.cc foo2.cc
g++ -Wfatal-errors t1.cc t2.cc -fpic -flto -c
g++ -Wfatal-errors t1.o t2.o -shared -flto -o t.so -flto-partition=none
In member function ‘_M_refdata’:
lto1: internal compiler error: in input_gimple_stmt, at
gimple-streamer-in.c:255
0xc565b6 input_gimple_stmt
[Bug c/55349] New: arm-linux-androideabi-gcc-4.6: Internal compiler error compiling libpng in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55349 Bug #: 55349 Summary: arm-linux-androideabi-gcc-4.6: Internal compiler error compiling libpng in debug mode Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ibenrun...@gmail.com Firstly: ndk-build doesn't give output of which version of gcc it is using but looking in the toolchains folder I checked the version number of what I believe it is running: arm-linux-androideabi-gcc-4.6 (GCC) 4.6 20120106 (prerelease) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Here is information regarding the issue, which should be enough to reproduce the problem: Please describe the problem in detail, with the following information (if applicable) Host OS:Linux NDK tools version: tested with android-ndk-r8b and android-ndk-r8c STEPS TO REPRODUCE: (Tested using android-ndk-r8b and android-ndk-r8c, libpng 1.2.38 and 1.5.13) 1.Setup simple NDK dev environment with libpng 1.5.13 2.run NDK_DEBUG=1 ndk-build 3.build will fail EXPECTED RESULTS: For libpng to compile successfully (which it does when NDK_DEBUG is set to 0) OBSERVED RESULTS: Compile thumb : png = pngrtran.c jni/png/pngrtran.c: In function 'png_do_rgb_to_gray': jni/png/pngrtran.c:3418:1: internal compiler error: in reload, at reload1.c:1061 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make: *** [obj/local/armeabi/objs-debug/png/pngrtran.o] Error 1 ^It is therefore reasonable to conclude that this is a bug within NDK or perhaps the version of GCC it is using.
[Bug c/55349] arm-linux-androideabi-gcc-4.6: Internal compiler error compiling libpng in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55349 --- Comment #1 from Ben Clapp ibenrunnin at gmail dot com 2012-11-16 03:44:38 UTC --- ADDITIONAL INFORMATION: I've hunted around Google for a good while, this is what I could find on the subject (virtually no information of worth): http://grokbase.com/t/gg/android-ndk/128b4k8wmm/ndk-r8b-debug-bild-does-not-link-anymore http://stackoverflow.com/questions/11980870/error-on-building-android-ndk-assets/12234953#comment16414063_12234953 https://groups.google.com/forum/#!msg/android-ndk/n4RIOhx9f4Y/oOWF4nUxMPAJ http://stackoverflow.com/questions/13042825/libpng-ndk-build-internal-compiler-error-in-debug-mode http://sourceforge.net/mailarchive/message.php?msg_id=30009240 http://timecubepuzzle.blogspot.com/2012/05/development-on-android-ndk-gluing-c.html?showComment=1347158980877#c6889341856998289570 possible similar issue involving Visual Studio??? http://stackoverflow.com/questions/12933309/linker-error-unresolved-external-symbol-imp-iob-func-in-libpng-lib
[Bug c/55349] arm-linux-androideabi-gcc-4.6: Internal compiler error compiling libpng in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55349 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-16 03:46:48 UTC --- http://code.google.com/p/android/issues/detail?id=20862
[Bug target/55349] arm-linux-androideabi-gcc-4.6: Internal compiler error compiling libpng in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55349 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||MOVED --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-16 03:51:29 UTC --- You should report this to google rather than here. Google should have changed the bug reporting url when they configured gcc. You should also try a new version of GCC since this was a prerelease from January.
[Bug c/55349] arm-linux-androideabi-gcc-4.6: Internal compiler error compiling libpng in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55349 Ben Clapp ibenrunnin at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|target |c Resolution|MOVED | --- Comment #4 from Ben Clapp ibenrunnin at gmail dot com 2012-11-16 03:55:49 UTC --- Ok, I had already submitted a bug to Google: http://code.google.com/p/android/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Summary%20Starsgroupby=sort=id=39787 This is the version of GCC packaged with the latest ndk, r8c, which was literally just released two days ago. Anyway, I'll go searching for a more recent pre-release, thanks for the tip.
