[Bug bootstrap/61797] New: [4.10 regression] 'bool decl_in_symtab_p(const_tree)' defined but not used error breaks x86_64-linux bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61797 Bug ID: 61797 Summary: [4.10 regression] 'bool decl_in_symtab_p(const_tree)' defined but not used error breaks x86_64-linux bootstrap Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mikpelinux at gmail dot com Attempting to bootstrap gcc-4.10-20140713 (r212499) on x86_64-linux fails with: /mnt/scratch/objdir410/./prev-gcc/xg++ -B/mnt/scratch/objdir410/./prev-gcc/ -B/mnt/scratch/install410/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/mnt/scratch/objdir410/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/mnt/scratch/objdir410/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/mnt/scratch/objdir410/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/mnt/scratch/objdir410/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/mnt/scratch/gcc-4.10-20140713/libstdc++-v3/libsupc++ -L/mnt/scratch/objdir410/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/mnt/scratch/objdir410/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -DIN_GCC_FRONTEND -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -Ic -I/mnt/scratch/gcc-4.10-20140713/gcc -I/mnt/scratch/gcc-4.10-20140713/gcc/c -I/mnt/scratch/gcc-4.10-20140713/gcc/../include -I/mnt/scratch/gcc-4.10-20140713/gcc/../libcpp/include -I/home/mikpe/pkgs/linux-x86_64/gmp-5.1.3/include -I/home/mikpe/pkgs/linux-x86_64/mpfr-3.1.2/include -I/home/mikpe/pkgs/linux-x86_64/mpc-1.0.2/include -I/mnt/scratch/gcc-4.10-20140713/gcc/../libdecnumber -I/mnt/scratch/gcc-4.10-20140713/gcc/../libdecnumber/bid -I../libdecnumber -I/mnt/scratch/gcc-4.10-20140713/gcc/../libbacktrace-o c/c-decl.o -MT c/c-decl.o -MMD -MP -MF c/.deps/c-decl.TPo /mnt/scratch/gcc-4.10-20140713/gcc/c/c-decl.c In file included from /mnt/scratch/gcc-4.10-20140713/gcc/c/c-decl.c:59:0: /mnt/scratch/gcc-4.10-20140713/gcc/cgraph.h:1158:1: error: 'bool decl_in_symtab_p(const_tree)' defined but not used [-Werror=unused-function] decl_in_symtab_p (const_tree decl) ^ cc1plus: all warnings being treated as errors make[3]: *** [c/c-decl.o] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir410/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir410' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir410' make: *** [bootstrap] Error 2 The previous weekly snapshot, 4.10-20140706 (r212315) bootstrapped fine. Configuration options: /mnt/scratch/gcc-4.10-20140713/configure --prefix=/mnt/scratch/install410 --with-gmp=/home/mikpe/pkgs/linux-x86_64/gmp-5.1.3 --with-mpfr=/home/mikpe/pkgs/linux-x86_64/mpfr-3.1.2 --with-mpc=/home/mikpe/pkgs/linux-x86_64/mpc-1.0.2 --disable-plugin --disable-lto --disable-nls --enable-threads=posix --enable-checking=release --disable-libmudflap --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go Now trying to continue with a manual hack to silence the above error...
[Bug bootstrap/61797] [4.10 regression] 'bool decl_in_symtab_p(const_tree)' defined but not used error breaks x86_64-linux bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61797 --- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com --- decl_in_symtab_p is used under #ifdef ENABLE_CHECKING by symtab_get_node (also in craph.h), and unconditionally by fold-const.c:tree_single_nonzero_warnv_p. Sticking an __attribute__((__used__)) on decl_in_symtab_p allows bootstrap to continue, until it hits build/genmodes: config/i386/i386-modes.def:25: (TF) field format must not be set build/genmodes: config/i386/i386-modes.def:24: (XF) field format must not be set build/genmodes: machmode.def:203: (DF) field format must not be set build/genmodes: machmode.def:202: (SF) field format must not be set build/genmodes: machmode.def:244: (TD) field format must not be set build/genmodes: machmode.def:243: (DD) field format must not be set build/genmodes: machmode.def:242: (SD) field format must not be set make[3]: *** [s-modes-m] Error 1 in stage 3, i.e. PR61757.
[Bug target/61656] Undefined behavior in classify_argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61656 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Jul 14 07:31:57 2014 New Revision: 212509 URL: https://gcc.gnu.org/viewcvs?rev=212509root=gccview=rev Log: PR target/61656 * config/i386/i386.c (classify_argument): Don't merge classes above number of words. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug middle-end/61294] [4.9 Regression] erroneous memset used with constant zero length parameter warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61294 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Jul 14 07:36:39 2014 New Revision: 212510 URL: https://gcc.gnu.org/viewcvs?rev=212510root=gccview=rev Log: PR middle-end/61294 gcc/c-family/ * c.opt (Wmemset-transposed-args): New warning. gcc/c/ * c-parser.c (c_parser_expr_list): Add new argument literal_zero_mask. If non-NULL, call c_parser_check_literal_zero. (c_parser_check_literal_zero): New function. (c_parser_postfix_expression_after_primary): Adjust c_parser_expr_list caller, handle -Wmemset-transposed-args. gcc/cp/ * cp-tree.h (LITERAL_ZERO_P): Define. * parser.c (cp_parser_parenthesized_expression_list): Add want_literal_zero_p argument, if true, for literal zeros insert INTEGER_CSTs with LITERAL_ZERO_P flag set. (cp_parser_postfix_expression): Adjust cp_parser_parenthesized_expression_list caller, handle -Wmemset-transposed-args. (literal_zeros): New variable. gcc/ * doc/invoke.texi (-Wmemset-transposed-args): Document. gcc/testsuite/ * c-c++-common/Wmemset-transposed-args1.c: New test. * c-c++-common/Wmemset-transposed-args2.c: New test. * g++.dg/warn/Wmemset-transposed-args-1.C: New test. Added: trunk/gcc/testsuite/c-c++-common/Wmemset-transposed-args1.c trunk/gcc/testsuite/c-c++-common/Wmemset-transposed-args2.c trunk/gcc/testsuite/g++.dg/warn/Wmemset-transposed-args-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #23 from Richard Biener rguenth at gcc dot gnu.org ---
The first interesting difference is that for
bb 14:
_793 = ASSERT_EXPR _73, _73 != 18;
switch (_793) default: L32, case 0: L26, case 1: L27, case 2: L28,
case 3: L29, case 4 ... 9: L28, case 10 ... 11: L30, case 12 ... 17:
L31
L28:
we record an equality instead of a range:
@@ -17655,13 +17655,7 @@
BB #19
EDGE 14-19 14 [14.3%] (EXECUTABLE)
- PREDICATE: _73 ge_expr 2
-
- switch (_73) default: L32, case 0: L26, case 1: L27, case 2:
L28, case 3: L29, case 4 ... 9: L28, case 10 ... 11: L30, case 12 ...
17: L31
-
- BB #19
- EDGE 14-19 14 [14.3%] (EXECUTABLE)
- PREDICATE: _73 le_expr 9
+ PREDICATE: _73 eq_expr 2
@@ -19815,9 +19806,8 @@
goto bb 28;
L28:
- _792 = ASSERT_EXPR _794, _794 = 2;
- _793 = ASSERT_EXPR _792, _792 = 9;
- _77 = _793 + 4294967288;
+ _792 = ASSERT_EXPR _793, _793 == 2;
+ _77 = _792 + 4294967288;
_78 = _77 1;
_79 = (requirement) _78;
validate_mode (m_780, 2, 0, 1, 1, _79);
that's of course bogus, happens via find_switch_asserts where for correctly
sorted ci vector we fail to pick up CASE_HIGH of cast 4...9.
We miscompile the loop
/* Skip labels until the last of the group. */
do {
++idx;
} while (idx n cbb == ci[idx].bb);
to
0x00b6a492 +3074: mov%eax,%r14d
0x00b6a495 +3077: lea0x1(%r14),%r15d
= 0x00b6a499 +3081: cmp%r15,%rcx
0x00b6a49c +3084: mov%r15,%rax
0x00b6a49f +3087: ja 0xb6a492
find_assert_locations_1(basic_block, sbitmap)+3074
that is, we simply increment idx until it is equal to n and then use
CASE_HIGH of the last case label in the vector which is the default
label (and thus does not have CASE_HIGH nor CASE_LOW).
The following testcase derived from that is miscompiled on trunk at -O2:
extern void abort (void);
struct X { void *p; int res; } a[32];
int foo (unsigned i, unsigned n, void *q)
{
if (i + 1 n q == a[i + 1].p)
{
do {
++i;
} while (i n q == a[i].p);
--i;
return a[i].res;
}
}
int main ()
{
int x;
a[0].p = x;
a[1].p = x;
a[1].res = 1;
a[2].p = (void *)0;
a[2].res = 0;
if (foo (0, 3, x) != 1)
abort ();
return 0;
}
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #24 from Richard Biener rguenth at gcc dot gnu.org ---
w/o missing return:
extern void abort (void);
struct X { void *p; int res; } a[32];
int foo (unsigned i, unsigned n, void *q)
{
if (i + 1 n q == a[i + 1].p)
{
do {
++i;
} while (i n q == a[i].p);
--i;
return a[i].res;
}
else
return a[i].res;
}
int main ()
{
int x;
a[0].p = x;
a[0].res = -1;
a[1].p = x;
a[1].res = 1;
a[2].p = (void *)0;
a[2].res = 0;
if (foo (0, 3, x) != 1)
abort ();
return 0;
}
passes when disabling both DOM passes.
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 --- Comment #25 from Richard Biener rguenth at gcc dot gnu.org --- Hmm, reverting the record_equality change that is supposed to fix the unrelated testsuite fallout fixes the testcase ...
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #26 from Richard Biener rguenth at gcc dot gnu.org ---
DOM first rotates the loop by threading the entry over the first part of
the conditional, producing
if (i + 1 n q == a[i + 1].p)
{
++i;
do
{
if (q != a[i].p)
break;
++i;
if (i = n)
break;
}
while (1);
the 2nd DOM pass then tries to complete the rotate but manages to record
two threadings that are incompatible:
Threaded jump 6 -- 12 to 13
Jump threading proved probability of edge 12-4 too small (it is 5114, should
be 1).
Threaded jump 7 -- 12 to 14
the 2nd one over the loop entry would be ok, completing the rotate. But
the first one is odd - and I can't see why we register it:
Optimizing block #6
1 COND 1 = n_4(D) ge_expr i_12
1 COND 1 = n_4(D) ne_expr i_12
1 COND 1 = n_4(D) gt_expr i_12
1 COND 0 = n_4(D) le_expr i_12
Optimizing statement pretmp_11 = a[i_12].p;
LKUP STMT pretmp_11 = a[i_12].p
pretmp_11 = a[i_12].p;
2 STMT pretmp_11 = a[i_12].p
pretmp_11 = a[i_12].p;
Registering jump thread: (6, 12) incoming edge; (12, 4) normal;
STMT pretmp_11 = a[i_12].p
pretmp_11 = a[i_12].p;
COND 0 = n_4(D) le_expr i_12
COND 1 = n_4(D) gt_expr i_12
COND 1 = n_4(D) ne_expr i_12
COND 1 = n_4(D) ge_expr i_12
bb6 is just
bb 6:
pretmp_11 = a[i_12].p;
and its single predecessor
bb 4:
i_12 = i_9 + 1;
if (n_4(D) i_12)
goto bb 6;
else
goto bb 5;
with the record_equality change we now record q_8(D) == prephitmp_16
instead of the other way around:
Optimizing block #4
0 COPY q_8(D) = prephitmp_16
1 COND 1 = q_8(D) le_expr prephitmp_16
1 COND 1 = q_8(D) ge_expr prephitmp_16
1 COND 1 = q_8(D) eq_expr prephitmp_16
1 COND 0 = q_8(D) ne_expr prephitmp_16
but when threading over the backedge this doesn't get invalidated.
So this canonicalization happens to be a correctness issue (by accident?
Jeff?)
[Bug libgomp/61798] New: OpenMP exit code 155, profiling related?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61798 Bug ID: 61798 Summary: OpenMP exit code 155, profiling related? Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: kessler at iag dot uni-stuttgart.de CC: jakub at gcc dot gnu.org I have got an OpenMP program (written in C++) up and running. However, when running my test suite of 43 cases for profiling (with -pg, it's CFD flow solver running in batch mode), some (usually 2-3) cases fail with an exit code of 155 -after- full completion of my code (that is, after return 0; in main). This only happens if several codes run in parallel on the same machine (this capability of the test script is from before the OpenMP parallelisation effort), and even then not always, and with varying cases, so I am quite confident it is not primarily a bug in my code. From scanning the output I have seen a message from the shell, apparently catching a SIGPROF, which seems reasonable as I have profiling enabled, but probably should not propagate outside the executable. I have never seen this problem with profiling in non-OpenMP mode. Unfortunately I can not share my code, but I think it is not related to the user code anyway, but perhaps some race condition in the interaction between profiling and OpenMP at program exit? Thanks for shedding some light on this bizarre situation. Ciao, Manuel
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #12 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
I disagree with Tobias' reading: it seems to me that the single-variable common
block should be interoperable with both the single-common C struct and C
variable.
The Intel compiler makes both cases work:
[fx@kelvin tmp]$ cat a.f90
program test
use iso_c_binding
integer(c_int) :: i
common /a/ i
bind(c) :: /a/
interface
subroutine foo() bind(c)
end subroutine
end interface
i = 42
print *, i
call foo()
print *, i
end program test
[fx@kelvin tmp]$ cat a1.c
extern int a;
void foo (void) { a = -1; }
[fx@kelvin tmp]$ cat a2.c
extern struct { int i; } a;
void foo (void) { a.i = -1; }
[fx@kelvin tmp]$ icc -c a1.c ifort a.f90 a1.o ./a.out
42
-1
[fx@kelvin tmp]$ icc -c a2.c ifort a.f90 a2.o ./a.out
42
-1
I believe we should do so too. And if I understand correctly what Richard said,
this means relaxing the LTO type rules, is that right?
[Bug bootstrap/61797] [4.10 regression] 'bool decl_in_symtab_p(const_tree)' defined but not used error breaks x86_64-linux bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61797 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Fixed by r212511.
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-14 Ever confirmed|0 |1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- I think we now need very very recent ISL (use of 0.11 is also broken this way but still accepted by configure and documented as working).
[Bug c++/60608] Template argument problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60608 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- I'm going to save some debugging notes, mostly about non-variadic vs variadic. First one: the tsubst in fn_type_unification: fntype = tsubst (TREE_TYPE (fn), explicit_targs, complain | tf_partial, NULL_TREE); working on TREE_TYPE (fn) which has uses_template_parms true, returns a fntype which has uses_template_parms false in the non-variadic case, still true in the variadic case. Note that later uses_template_parms matters at the beginning of unify_one_argument.
[Bug gcov-profile/61790] [4.10 Regression] gcov-tool.c uses atoll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61790 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-14 Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #13 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 14 Jul 2014, fxcoudert at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #12 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org
---
I disagree with Tobias' reading: it seems to me that the single-variable
common
block should be interoperable with both the single-common C struct and C
variable.
The Intel compiler makes both cases work:
[fx@kelvin tmp]$ cat a.f90
program test
use iso_c_binding
integer(c_int) :: i
common /a/ i
bind(c) :: /a/
interface
subroutine foo() bind(c)
end subroutine
end interface
i = 42
print *, i
call foo()
print *, i
end program test
[fx@kelvin tmp]$ cat a1.c
extern int a;
void foo (void) { a = -1; }
[fx@kelvin tmp]$ cat a2.c
extern struct { int i; } a;
void foo (void) { a.i = -1; }
[fx@kelvin tmp]$ icc -c a1.c ifort a.f90 a1.o ./a.out
42
-1
[fx@kelvin tmp]$ icc -c a2.c ifort a.f90 a2.o ./a.out
42
-1
I believe we should do so too. And if I understand correctly what Richard
said,
this means relaxing the LTO type rules, is that right?
Yes (to get rid of the warning and to avoid eventual wrong-code bugs).
Does it need to inter-operate with
extern struct { struct { int i; } a; } a;
? Or
extern union { int i; } a;
?
[Bug bootstrap/61631] [4.10 regression] ICE unwind-dw2.c:1639:5: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61631 Dmitry G. Dyachenko dimhen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dmitry G. Dyachenko dimhen at gmail dot com --- fixed r212428
[Bug tree-optimization/61783] [4.10 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61783 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-14 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug web/61782] always_inline incorrectly documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2014-07-14
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
?
@item always_inline
@cindex @code{always_inline} function attribute
Generally, functions are not inlined unless optimization is specified.
For functions declared inline, this attribute inlines the function even
if no optimization level is specified.
what exactly is unclear about this? even if no optimization level is
specified
The implemented behavior is that always_inline forces inlining of the function
under all circumstances and it is an error if the function cannot be inlined.
[Bug fortran/61780] [4.8/4.9 Regression] Wrong code when shifting elements of a multidimensional array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.10.0 Target Milestone|--- |4.8.4 Summary|[4.8/4.9/4.10 Regression] |[4.8/4.9 Regression] Wrong |Wrong code when shifting|code when shifting elements |elements of a |of a multidimensional array |multidimensional array | Known to fail|4.10.0 |
[Bug tree-optimization/61787] wrong code at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61787 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-14 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Duplicate of 61757. I'm adding more testcases there.
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #14 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #13)
Does it need to inter-operate with
extern struct { struct { int i; } a; } a;
No, I don't read anything in the standard that would allow this.
extern union { int i; } a;
No, per F2008 15.3.4 ¶3: There is no Fortran type that is interoperable with a
C union type.
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #27 from Richard Biener rguenth at gcc dot gnu.org --- Fixed. (IMHO latent jump threading bug still present)
[Bug tree-optimization/61787] wrong code at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61787 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/61783] [4.10 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61783 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Should be fixed now.
[Bug tree-optimization/61783] [4.10 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61783 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jul 14 10:50:46 2014 New Revision: 212513 URL: https://gcc.gnu.org/viewcvs?rev=212513root=gccview=rev Log: 2014-07-14 Richard Biener rguent...@suse.de PR tree-optimization/61757 PR tree-optimization/61783 PR tree-optimization/61787 * tree-ssa-dom.c (record_equality): Revert canonicalization change and add comment. (propagate_rhs_into_lhs): Revert previous fix, removing loop depth restriction again. * gcc.dg/torture/pr61757.c: New testcase. * gcc.dg/torture/pr61787.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61757.c trunk/gcc/testsuite/gcc.dg/torture/pr61787.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dom.c
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 --- Comment #28 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jul 14 10:50:46 2014 New Revision: 212513 URL: https://gcc.gnu.org/viewcvs?rev=212513root=gccview=rev Log: 2014-07-14 Richard Biener rguent...@suse.de PR tree-optimization/61757 PR tree-optimization/61783 PR tree-optimization/61787 * tree-ssa-dom.c (record_equality): Revert canonicalization change and add comment. (propagate_rhs_into_lhs): Revert previous fix, removing loop depth restriction again. * gcc.dg/torture/pr61757.c: New testcase. * gcc.dg/torture/pr61787.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61757.c trunk/gcc/testsuite/gcc.dg/torture/pr61787.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dom.c
[Bug tree-optimization/61787] wrong code at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61787 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jul 14 10:50:46 2014 New Revision: 212513 URL: https://gcc.gnu.org/viewcvs?rev=212513root=gccview=rev Log: 2014-07-14 Richard Biener rguent...@suse.de PR tree-optimization/61757 PR tree-optimization/61783 PR tree-optimization/61787 * tree-ssa-dom.c (record_equality): Revert canonicalization change and add comment. (propagate_rhs_into_lhs): Revert previous fix, removing loop depth restriction again. * gcc.dg/torture/pr61757.c: New testcase. * gcc.dg/torture/pr61787.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61757.c trunk/gcc/testsuite/gcc.dg/torture/pr61787.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dom.c
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org ---
Ok, the warning is implemented with checking gimple type compatibility in
lto/lto-symtab.c:
if (!types_compatible_p (TREE_TYPE (prevailing-decl),
TREE_TYPE (decl)))
diagnosed_p |= warning_at (DECL_SOURCE_LOCATION (decl), 0,
type of %qD does not match original
declaration, decl);
I'm not sure it is wise to drop the outermost single-element struct type
from all types during compute of canonical types.
We can adjust gimple_get_alias_set to at least assign the same alias
sets to such struct and its element, but that doesn't cure the warning
(obviously). At least that avoids generating wrong code... like with
@@ -2307,6 +2308,27 @@ gimple_get_alias_set (tree t)
|| t == unsigned_char_type_node)
return 0;
+ /* For C, Fortran interoperability assign the same alias-set to
+ a record with a single element as that element. */
+ if (TREE_CODE (t) == RECORD_TYPE)
+{
+ tree f = NULL_TREE;
+ for (tree fld = TYPE_FIELDS (t); fld != NULL_TREE; fld = TREE_CHAIN
(fld))
+ {
+ if (TREE_CODE (fld) != FIELD_DECL)
+ continue;
+ if (f == NULL_TREE)
+ f = fld;
+ else
+ {
+ f = NULL_TREE;
+ break;
+ }
+ }
+ if (f)
+ return get_alias_set (TREE_TYPE (f));
+}
+
/* Allow aliasing between signed and unsigned variants of the same
but I'm sure we don't want to call get_alias_set on all globals during
WPA phase (Where the warning is emitted).
Humm. We can special-case that case in lto-symtab.c of course.
Btw, what kind of single-elements can I expect? I suppose they can
be arbitrary (so aggregate as well)?
[Bug lto/61786] wrong code by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61786 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Both testcases confirmed as fixed with the PR61757 fix. I'll add the testcases.
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227 --- Comment #16 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Richard Biener from comment #15) Btw, what kind of single-elements can I expect? I suppose they can be arbitrary (so aggregate as well)? From the Fortran/C interop side, we can get anything that is itself C/Fortran interoperable. So that is POD of various types (integers, floating-points and complexes, bool and char), pointer types, structs of those and arrays.
[Bug lto/61786] wrong code by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61786 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jul 14 11:22:34 2014 New Revision: 212515 URL: https://gcc.gnu.org/viewcvs?rev=212515root=gccview=rev Log: 2014-07-14 Richard Biener rguent...@suse.de PR tree-optimization/61786 * gcc.dg/torture/pr61786.c: New testcase. * gcc.dg/lto/pr61786_0.c: Likewise. * gcc.dg/lto/pr61786_1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/lto/pr61786_0.c trunk/gcc/testsuite/gcc.dg/lto/pr61786_1.c trunk/gcc/testsuite/gcc.dg/torture/pr61786.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Francois-Xavier Coudert from comment #12) I disagree with Tobias' reading: it seems to me that the single-variable common block should be interoperable with both the single-common C struct and C variable. Well, Bill Long of Cray seems to agree with my interpretation, cf. http://mailman.j3-fortran.org/pipermail/j3/2010-February/003358.html The Intel compiler makes both cases work: Well, it also works with gfortran - the question is only whether it works by chance or by purpose. If it works by chance and is invalid LTO is not required to support it.
[Bug c/61779] gcc -Og fails with impossible constraint on legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2014-07-14
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
f ()
{
int iftmp.0_1;
bb 2:
bb 3:
bb 4:
# iftmp.0_1 = PHI 1(3)
__asm__ __volatile__(.pushsection .note.stapsdt,?,note
.4byte 992f-991f,994f-993f,3
.asciz %n0@%1
: : _SDT_S1 n iftmp.0_1, _SDT_A1 nor 0);
goto bb 3;
Huh. At -O0 we have the constant 1 propagated. From folding builtins
we get
_7 = 0;
if (_7 == 0)
goto bb 5;
else
goto bb 4;
bb 4:
bb 5:
# iftmp.0_1 = PHI 1(3), -1(4)
and copyprop then produces
bb 4:
# iftmp.0_1 = PHI 1(3)
because copyprop does
Visiting statement:
if (_7 == 0)
No interesting values produced.
Adding Destination of edge (3 - 5) to worklist
Adding Destination of edge (3 - 4) to worklist
err. Since copyprop also copy-propagates constants copy_prop_visit_cond_stmt
should try harder.
Mine.
[Bug rtl-optimization/61799] New: [4.6/4.7 regression][ia64] r165240 caused GDB stops with SIGTRAP at 0 address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799 Bug ID: 61799 Summary: [4.6/4.7 regression][ia64] r165240 caused GDB stops with SIGTRAP at 0 address Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: emeric.maschino at gmail dot com With current ia64 stable GCC (4.6 on Debian/ia64, 4.7 on Gentoo/ia64), trying to debug a program with GDB immediately ends with: (gdb) run Starting program: /usr/bin/bogus-program Program received signal SIGTRAP, Trace/breakpoint trap. 0x in ?? () (gdb) Originally incorrectly reported on Debian BTS against the Linux kernel (as depending on kernel versions, GDB was running fine or not) [1], I've later discovered that, for a given kernel version, GDB was running fine or not depending on the kernel configuration (simply changing a component from being compiled in-kernel vs. as a module could trigger this issue) [2]. So kernel version wasn't the cause. GCC optimizations were also incorrectly reported as playing a role there [3], as depending on optimization settings, GDB may run fine or not. This lead to Ben Hutchings reporting on the behalf of Will Deacon that gcc's code generation for ia64 has regressed in 4.6 or earlier [4]. So, carefully looking again at the broken kernels, I've indeed noticed that this issue first appears with kernels compiled with GCC = 4.6, as alluded to earlier by Stephan Schreiber [5]. So, having a working environment with a GCC 4.5.4-compiled kernel and a broken one with the same kernel but compiled with GCC 4.6.3, I ran git bisect on GCC's git mirror and located the bad commit to be revision 165240 [6], that aimed to fix PR/rtl-opt/33721 [7]. Not being a GCC developper nor an ia64 guru, I'm now stuck here. So please let me know how I can help further. Thanks, Émeric [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576 [2] https://lists.debian.org/debian-ia64/2013/09/msg00024.html [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576#131 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576#116 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576#10 [6] https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=165240 [7] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33721
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #18 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Francois-Xavier Coudert from comment #14)
(In reply to rguent...@suse.de from comment #13)
Does it need to inter-operate with
extern struct { struct { int i; } a; } a;
No, I don't read anything in the standard that would allow this.
By your argument,
int i;
and
struct { int i; } a;
are interoperable. By this argument, one can also claim that it applies to
struct { struct { int i; } a; } a;
At least I fail to see a difference between the single and the nested struct.
Otherwise, I stand to what I wrote before: I think the standard does not demand
the interoperability.
There are surely programs out there which do assume for a scalar variable in a
common block that it interoperates with int and others which assume that it
interoperates with struct { int i; }. Thus, one might decide that one wants
to support both versions with LTO. But one shouldn't do so by arguing with the
Fortran standard.
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #19 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 14 Jul 2014, burnus at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Francois-Xavier Coudert from comment #12)
I disagree with Tobias' reading: it seems to me that the single-variable
common block should be interoperable with both the single-common C struct
and C variable.
Well, Bill Long of Cray seems to agree with my interpretation, cf.
http://mailman.j3-fortran.org/pipermail/j3/2010-February/003358.html
But that answer suggests we get it wrong (currenty interoperating
with the C struct { int i; } works and with the plain decl it
doesn't). The answer specifically doesn't say that only (1)
is valid.
The Intel compiler makes both cases work:
Well, it also works with gfortran - the question is only whether it works by
chance or by purpose. If it works by chance and is invalid LTO is not required
to support it.
Currently it works by chance because without LTO the compiler doesn't
see both sides. With LTO it notices there is an inconsistency that
with a clever testcase will result in wrong code (make a fortran
subroutine that assigns sth to the variable, call it from the
C main after its assignment of 42, read the var again in main
and see it optimized to '42' in case the fortran function call is
inlined)
[Bug rtl-optimization/61799] [4.6/4.7 regression][ia64] r165240 caused GDB stops with SIGTRAP at 0 address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||ia64-*-* Status|UNCONFIRMED |WAITING Last reconfirmed||2014-07-14 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Please try at least GCC 4.8 - both 4.6 and 4.7 are no longer supported.
[Bug tree-optimization/59611] std::copy performs worse than naive implementation when copying a single known byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Verified that the 61473 fix fixed this as well.
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #20 from Tobias Schlüter tobi at gcc dot gnu.org ---
Let's please not invent new semantics. There are two things to distinguish:
1) legacy code, where no interoperability semantics were defined
2) new code, where the semantics are defined
I don't know much about 2), but I do know that the recommendation back in the
days was that a common block is represented by a struct, and everybody knew
that the layout of a struct with a single variable is the same as for the
variable itself. I don't think anybody was silly enough to nest structs around
their variable.
Unfortunately, this is still not entirely simple. Fortran allows accessing the
same memory by different names which may have different types: what do you do
with
INTEGER A, B, C
COMMON /D/ E(3)
REAL E
EQUIVALENCE (E(1),A), (E(2),B), (E(3),C)
?
Or, to make things even more annoying
DOUBLE PRECISON X
INTEGER I(2)
EQUIVALENCE (X, I(1))
COMMON /annoying/ X
?
There's one more problem: Fortran's TYPE, the equivalent of the struct {}, was
defined in Fortran 90 -- before the interoperability stuff. So the question is
what to do with common block that contain a single TYPE variable.
Until I started writing this, I tought well, just allow this struct vs. single
variable only for single-valued, scalar contents of the common block, but my
second example showed me that this wouldn't work -- after all is the common
content scalar (one double) or array-valued (two ints)?
Now, since we're talking about legacy stuff and we don't want to invent new
language rules, I think we can restrict ourselves to supporting the simplest
case: a single INTEGER, REAL or DOUBLE PRECISION ignoring possible
EQUIVALENCES, but I don't know if this is easily achieved on the LTO side.
Going further is not worth it, it's not like there are heaps of bug reports
about this problem.
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #21 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #18)
By your argument,
int i;
and
struct { int i; } a;
are interoperable.
No. The standard only defines interoperability as a one-to-one mapping between
one Fortran entity and one C entity.
An extern int i and integer(int_c) :: i are interoperable. By the standard,
a common block with i as single variable is interoperable with extern struct {
int i; } a; or int i; (where the question is whether or is exclusive or
not).
But I don't see how you can expand that to mean that the common block is
interoperable with struct { struct { int i; } a; } a; by a simple reading of
the standard. There are, in my reading, 2 or 3 (with the same or as before)
entities interoperable with this nested struct:
- a derived type containing a derived type containing integer(int_c) :: i
- a common containing the dt containing the dt
- a common containing a derived type containing integer(int_c) :: i
Otherwise, I stand to what I wrote before: I think the standard does not
demand the interoperability.
Let's raise a formal interp, then.
[Bug fortran/61780] [4.8/4.9 Regression] Wrong code when shifting elements of a multidimensional array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780 --- Comment #6 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com --- Dear Richie, Thanks for doing that. I was going to do 4.8 as soon as I had a moment and would have changed the summary then. As it happens, I was distracted by other activities (rewiring the kitchen). Cheers Paul On 14 July 2014 12:42, rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.10.0 Target Milestone|--- |4.8.4 Summary|[4.8/4.9/4.10 Regression] |[4.8/4.9 Regression] Wrong |Wrong code when shifting|code when shifting elements |elements of a |of a multidimensional array |multidimensional array | Known to fail|4.10.0 | -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug ipa/61800] New: [4.10 Regression] ICE: Segmentation fault during Firefox build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61800
Bug ID: 61800
Summary: [4.10 Regression] ICE: Segmentation fault during
Firefox build
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
markus@x4 http % /var/tmp/gcc_test/usr/local/bin/c++ -o TunnelUtils.o -c
-I../../../dist/stl_wrappers -I../../../dist/system_wrappers -include
/var/tmp/mozilla-central/config
/gcc_hidden.h -DOS_POSIX=1 -DOS_LINUX=1 -DMOZ_GLUE_IN_PROGRAM
-DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DSTATIC_EXPORTABLE_JS_API
-DNO_NSPR_10_SUPPORT -I/var/tmp/mozilla-central
/netwerk/protocol/http -I. -I/var/tmp/mozilla-central/ipc/chromium/src
-I/var/tmp/mozilla-central/ipc/glue
-I/var/tmp/mozilla-central/netwerk/protocol/http/../../base/src -I/
var/tmp/mozilla-central/content/base/src
-I/var/tmp/moz-build-dir/ipc/ipdl/_ipdlheaders -I../../../dist/include
-I/usr/include/nspr -I/usr/include/nss -I/var/tmp/moz-build-
dir/dist/include -I/usr/include/pixman-1-fPIC -DMOZILLA_CLIENT -include
../../../mozilla-config.h -MD -MP -MF .deps/TunnelUtils.o.pp -Wall
-Wpointer-arith -Woverloade
d-virtual -Werror=return-type -Werror=int-to-pointer-cast -Wtype-limits
-Wempty-body -Wsign-compare -Wno-invalid-offsetof -Wcast-align
-fno-semantic-interposition -ffunction-
sections -fdata-sections -fno-exceptions -fno-strict-aliasing -fno-rtti
-fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED
-O3 -fomit-frame-point
er /var/tmp/mozilla-central/netwerk/protocol/http/TunnelUtils.cpp
In file included from
/var/tmp/mozilla-central/ipc/chromium/src/base/message_loop.h:19:0,
from ../../../dist/include/mozilla/ipc/MessageLink.h:12,
from ../../../dist/include/mozilla/ipc/ProtocolUtils.h:22,
from
/var/tmp/moz-build-dir/ipc/ipdl/_ipdlheaders/mozilla/net/PNecko.h:16,
from
/var/tmp/moz-build-dir/ipc/ipdl/_ipdlheaders/mozilla/net/PNeckoChild.h:9,
from ../../../dist/include/mozilla/net/NeckoChild.h:11,
from
/var/tmp/mozilla-central/netwerk/protocol/http/HttpLog.h:42,
from
/var/tmp/mozilla-central/netwerk/protocol/http/TunnelUtils.cpp:8:
/var/tmp/mozilla-central/ipc/chromium/src/base/task.h:27:7: internal compiler
error: Segmentation fault
class CancelableTask : public Task {
^
0xb87bff crash_signal
../../gcc/gcc/toplev.c:337
0x9f4e46 tree_check
../../gcc/gcc/tree.h:2730
0x9f4e46 decl_maybe_in_construction_p(tree_node*, tree_node*,
gimple_statement_base*, tree_node*)
../../gcc/gcc/ipa-devirt.c:1974
0x9f5dd1 get_polymorphic_call_info(tree_node*, tree_node*, tree_node**, long*,
ipa_polymorphic_call_context*, gimple_statement_base*)
../../gcc/gcc/ipa-devirt.c:2176
0x845414 cgraph_create_indirect_edge(cgraph_node*, gimple_statement_base*, int,
long, int)
../../gcc/gcc/cgraph.c:970
0x84e1c1 cgraph_clone_edge(cgraph_edge*, cgraph_node*, gimple_statement_base*,
unsigned int, long, int, bool)
../../gcc/gcc/cgraphclones.c:139
0x84ed8e cgraph_clone_node(cgraph_node*, tree_node*, long, int, bool,
veccgraph_edge*, va_heap, vl_ptr, bool, cgraph_node*, bitmap_head*)
../../gcc/gcc/cgraphclones.c:473
0x10acc2e clone_inlined_nodes(cgraph_edge*, bool, bool, int*, int)
../../gcc/gcc/ipa-inline-transform.c:188
0x10acf67 inline_call(cgraph_edge*, bool, veccgraph_edge*, va_heap, vl_ptr*,
int*, bool, bool*)
../../gcc/gcc/ipa-inline-transform.c:275
0x10a916e inline_small_functions
../../gcc/gcc/ipa-inline.c:1814
0x10a916e ipa_inline
../../gcc/gcc/ipa-inline.c:2185
0x10a916e execute
../../gcc/gcc/ipa-inline.c:2545
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.
Probably started with r212304. Reducing.
[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
--- Comment #22 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #19)
Well, Bill Long of Cray seems to agree with my interpretation, cf.
http://mailman.j3-fortran.org/pipermail/j3/2010-February/003358.html
But that answer suggests we get it wrong (currenty interoperating
with the C struct { int i; } works and with the plain decl it
doesn't). The answer specifically doesn't say that only (1)
is valid.
As I stumbled over it again (and missed what I wrote 5 years ago in comment 0):
One also needs to distinguish between common blocks with and without BIND(C).
The Fortran standard only defines interoperability with C with Fortran 2003's C
binding (BIND(C)). Thus, external int i interoperates with
use iso_fortran_env, only: c_int
integer(c_int) :: j
common /i/ j
bind(C) :: /i/
and for this construct, struct {int i} does not have to interoperate with it
according to the standard. If the front-end produces the wrong code in this
case, one can simply fix it. Seems as if we have to do this, including the
output DWARF.
[By the way, I assume that there is essentially no code out there, which uses
BIND(C) with COMMON: Either it is pre-Fortran-2003 code - or it uses modules
where one avoids all those issues with COMMON and either has integer, bind(C)
:: i or type(t), bind(C) :: i and no ambiguity.]
The other case is legacy code: There, programs can make the wildest assumptions
what C code should interoperable with Fortran. See also T.S.'s comment 20.
Seems as if a simple struct was the most common assumption - with a nonstruct
being effectively interoperable with a one-variable struct; hence, also the
latter seems to be used.
[Bug c/61779] gcc -Og fails with impossible constraint on legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jul 14 13:52:38 2014 New Revision: 212521 URL: https://gcc.gnu.org/viewcvs?rev=212521root=gccview=rev Log: 2014-07-14 Richard Biener rguent...@suse.de PR tree-optimization/61779 * tree-ssa-copy.c (copy_prop_visit_cond_stmt): Always try simplifying a condition. * gcc.dg/tree-ssa/ssa-copyprop-2.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-copyprop-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-copy.c
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #17 from Uroš Bizjak ubizjak at gmail dot com --- Fixed for 4.10.
[Bug ipa/61800] [4.10 Regression] ICE: Segmentation fault during Firefox build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61800
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.10.0
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 http % cat TunnelUtils.ii
#pragma GCC visibility push(hidden)
#pragma GCC visibility push(default)
typedef unsigned int uint32_t;
#pragma GCC visibility pop
typedef enum class tag_nsresult : uint32_t
{
NS_OK = 0,
} nsresult;
typedef int nsIID;
class A
{
public:
virtual nsresult operator()(const nsIID , void **) const = 0;
};
template class T class B
{
public:
typedef T element_type;
B (const A p1)
{
uint32_t __trans_tmp_1;
void *newRawPtr;
__trans_tmp_1
= NS_FAILED_impl (p1 ((T::template DT, void::kIID), newRawPtr));
}
};
class F : public A
{
virtual nsresult operator()(const nsIID p1, void **) const;
};
class G
{
public:
template typename T, typename U struct D;
};
template typename T struct G::DG, T
{
static const nsIID kIID __attribute__ ((visibility (hidden)));
};
class H : public G
{
virtual nsresult CloseWithStatus (nsresult p1);
};
inline uint32_t NS_FAILED_impl (nsresult p1) {}
inline const F do_QueryReferent (G *p1, nsresult *p2 = 0) {}
nsresult H::CloseWithStatus (nsresult p1)
{
BG baseTrans (do_QueryReferent (0));
return CloseWithStatus (nsresult::NS_OK);
}
markus@x4 http % /var/tmp/gcc_test/usr/local/bin/c++ -c -O3 -std=c++11
TunnelUtils.ii
TunnelUtils.ii:53:1: internal compiler error: Segmentation fault
}
^
0xb87bff crash_signal
../../gcc/gcc/toplev.c:337
0x9f4e46 tree_check
../../gcc/gcc/tree.h:2730
0x9f4e46 decl_maybe_in_construction_p(tree_node*, tree_node*,
gimple_statement_base*, tree_node*)
../../gcc/gcc/ipa-devirt.c:1974
0x9f5dd1 get_polymorphic_call_info(tree_node*, tree_node*, tree_node**, long*,
ipa_polymorphic_call_context*, gimple_statement_base*)
../../gcc/gcc/ipa-devirt.c:2176
0x845414 cgraph_create_indirect_edge(cgraph_node*, gimple_statement_base*, int,
long, int)
../../gcc/gcc/cgraph.c:970
0x84e1c1 cgraph_clone_edge(cgraph_edge*, cgraph_node*, gimple_statement_base*,
unsigned int, long, int, bool)
../../gcc/gcc/cgraphclones.c:139
0x84ed8e cgraph_clone_node(cgraph_node*, tree_node*, long, int, bool,
veccgraph_edge*, va_heap, vl_ptr, bool, cgraph_node*, bitmap_head*)
../../gcc/gcc/cgraphclones.c:473
0x10a97a2 recursive_inlining
../../gcc/gcc/ipa-inline.c:1388
0x10a97a2 inline_small_functions
../../gcc/gcc/ipa-inline.c:1768
0x10a97a2 ipa_inline
../../gcc/gcc/ipa-inline.c:2185
0x10a97a2 execute
../../gcc/gcc/ipa-inline.c:2545
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 fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- The following code program p call ss0() end program p subroutine ss0 CHARACTER(3), save :: ZTYP(3) DATA ZTYP /'XXX','YYY','ZZZ'/ write(*,600,IOSTAT=iosa) 'AAA',0.0,ZTYP 600 FORMAT(A3,1PE13.5,A3) print *, print *, 'iostat =', iosa end subroutine ss0 outputs AAA 0.0E+00XXX YYY iostat =5006 Is the printing of 'YYY' supposed to happen?
[Bug lto/61802] New: AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 Bug ID: 61802 Summary: AArch64 execute.exp failures with LTO after r212467 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org After r212467 Author: hubicka hubicka@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Jul 11 17:43:44 2014 + * vapool.c: Include tree-ssa-alias.h, gimple.h and lto-streamer.h (varpool_get_constructor): New function. (varpool_ctor_useable_for_folding_p): Break out from ... (ctor_for_folding): ... here; use varpool_get_constructor. (varpool_assemble_decl): Likewise. * lto-streamer.h (struct output_block): Turn cgraph_node to symbol filed. (lto_input_variable_constructor): Declare. * ipa-visibility.c (function_and_variable_visibility): Use varpool_get_constructor. * cgraph.h (varpool_get_constructor): Declare. (varpool_ctor_useable_for_folding_p): New function. * lto-streamer-out.c (get_symbol_initial_value): Take encoder parameter; return error_mark_node for non-trivial constructors. (lto_write_tree_1, DFS_write_tree): UPdate use of get_symbol_initial_value. (output_function): Update initialization of symbol. (output_constructor): New function. (copy_function): Rename to .. (copy_function_or_variable): ... this one; handle vars too. (lto_output): Output variable sections. * lto-streamer-in.c (input_constructor): New function. (lto_read_body): Rename from ... (lto_read_body_or_constructor): ... this one; handle vars too. (lto_input_variable_constructor): New function. * ipa-prop.c (ipa_prop_write_jump_functions, ipa_prop_write_all_agg_replacement): Update. * lto-cgraph.c (compute_ltrans_boundary): Use it. (output_cgraph_opt_summary): Set symbol to NULL. * lto-partition.c (add_references_to_partition): Use varpool_ctor_useable_for_folding_p. * lto.c (lto_read_in_decl_state): Update sanity check. I'm seeing a number of failures in gcc.c-torture/execute/ on the -flto variants, including: FAIL: gcc.c-torture/execute/2422-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/2422-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/20001013-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/20001013-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/2003-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/2003-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/20020615-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/20020615-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/20040805-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/20040805-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/20050929-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/20050929-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/20071210-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/20071210-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/20081117-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/20081117-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/20120427-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/20120427-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/20120919-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/20120919-1.c execution, -O2 -flto FAIL: gcc.c-torture/execute/921113-1.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/921113-1.c execution, -O2 -flto
[Bug rtl-optimization/61801] New: sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
Bug ID: 61801
Summary: sched2 miscompiles syscall sequence with -g
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target: i?86-*-*
Created attachment 33118
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33118action=edit
testcase from glibc trunk
gcc-4.8 -S bug-887141_pthread_create.i -m32 -std=gnu99 -fgnu89-inline -O2
-fmerge-all-constants -frounding-math -fPIC -mpreferred-stack-boundary=4
-fverbose-asm -da -fdump-tree-all -g
sched2 moves the load from 20(%esp) up across the spill.
__nptl_setxid:
...
.LBB347:
.loc 1 1174 0
movl80(%esp), %eax # cmdp, tmp189
movl20(%esp), %esi # %sfp, result bogus location
.LVL184:
movl(%eax), %eax# cmdp_33(D)-syscall_no,
cmdp_33(D)-syscall_no
movl%eax, 20(%esp) # cmdp_33(D)-syscall_no, %sfp
.LVL185:
movl80(%esp), %eax # cmdp, tmp191
movl4(%eax), %edi # cmdp_33(D)-id, cmdp_33(D)-id
movl8(%eax), %ecx # cmdp_33(D)-id, cmdp_33(D)-id
movl12(%eax), %edx # cmdp_33(D)-id, cmdp_33(D)-id
moved from here
movl%esi, %eax # result, result
#APP
# 1174 allocatestack.c 1
xchgl %ebx, %edi
int $0x80
xchgl %edi, %ebx
before sched2 everything looks ok (apart from odd
debug-insn with asm):
(code_label 308 344 309 40 194 [1 uses])
(note 309 308 531 40 [bb 40] NOTE_INSN_BASIC_BLOCK)
(insn 531 309 310 40 (set (reg:SI 0 ax [189])
(mem/f/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50])) [4 cmdp+0 S4 A32])) allocatestack.c:1174
89 {*movsi_internal}
(nil))
(insn 310 531 532 40 (set (reg:SI 0 ax [orig:137 cmdp_33(D)-syscall_no ]
[137])
(mem:SI (reg:SI 0 ax [189]) [2 cmdp_33(D)-syscall_no+0 S4 A32]))
allocatestack.c:1174 89 {*movsi_internal}
(nil))
(insn 532 310 533 40 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 20 [0x14])) [54 %sfp+-12 S4 A32])
(reg:SI 0 ax [orig:137 cmdp_33(D)-syscall_no ] [137]))
allocatestack.c:1174 89 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 0 ax [orig:137 cmdp_33(D)-syscall_no ] [137])
(nil)))
(insn 533 532 311 40 (set (reg:SI 0 ax [191])
(mem/f/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 80 [0x50])) [4 cmdp+0 S4 A32])) allocatestack.c:1174
89 {*movsi_internal}
(nil))
(insn 311 533 312 40 (set (reg:SI 5 di [orig:138 cmdp_33(D)-id ] [138])
(mem:SI (plus:SI (reg:SI 0 ax [191])
(const_int 4 [0x4])) [5 cmdp_33(D)-id+0 S4 A32]))
allocatestack.c:1174 89 {*movsi_internal}
(nil))
(insn 312 311 313 40 (set (reg:SI 2 cx [orig:139 cmdp_33(D)-id+4 ] [139])
(mem:SI (plus:SI (reg:SI 0 ax [192])
(const_int 8 [0x8])) [5 cmdp_33(D)-id+4 S4 A32]))
allocatestack.c:1174 89 {*movsi_internal}
(nil))
(insn 313 312 314 40 (set (reg:SI 1 dx [orig:140 cmdp_33(D)-id+8 ] [140])
(mem:SI (plus:SI (reg:SI 0 ax [193])
(const_int 12 [0xc])) [5 cmdp_33(D)-id+8 S4 A32]))
allocatestack.c:1174 89 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 0 ax [193])
(nil)))
(note 314 313 316 40 NOTE_INSN_DELETED)
(debug_insn 316 314 477 40 (var_location:SI resultvar (asm_operands/v:SI
(xchgl %%ebx, %%edi
int $0x80
xchgl %%edi, %%ebx
) (=a) 0 [
(mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 20 [0x14])) [54 %sfp+-12 S4 A32])
(reg:SI 5 di [orig:138 cmdp_33(D)-id ] [138])
(reg:SI 2 cx [orig:139 cmdp_33(D)-id+4 ] [139])
(reg:SI 1 dx [orig:140 cmdp_33(D)-id+8 ] [140])
]
[
(asm_input:SI (0) (null):0)
(asm_input:SI (D) (null):0)
(asm_input:SI (c) (null):0)
(asm_input:SI (d) (null):0)
]
[] allocatestack.c:1174)) allocatestack.c:1174 -1
(nil))
(insn 477 316 536 40 (set (reg/v:SI 4 si [orig:60 result ] [60])
(mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 20 [0x14])) [54 %sfp+-12 S4 A32]))
allocatestack.c:1174 89 {*movsi_internal}
(nil))
(insn 536 477 317 40 (set (reg/v:SI 0 ax [orig:60 result ] [60])
(reg/v:SI 4 si [orig:60 result ] [60])) allocatestack.c:1174 89
{*movsi_internal}
(expr_list:REG_DEAD (reg/v:SI 4 si [orig:60 result ] [60])
(nil)))
(insn 317 536 537 40 (parallel [
(set (reg/v:SI 0 ax [orig:60 result ] [60])
(asm_operands/v:SI (xchgl %%ebx, %%edi
int $0x80
xchgl %%edi, %%ebx
[Bug preprocessor/44317] ,##__VA_ARGS__ comma not eaten with -std=c++0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-14 Ever confirmed|0 |1 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Confirmed. Perhaps the locations are added after the warning is emitted. Or the incorrect location is passed to the warning. Needs further debugging.
[Bug preprocessor/44317] ,##__VA_ARGS__ comma not eaten with -std=c++0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317 --- Comment #6 from emsr at gcc dot gnu.org --- Created attachment 33119 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33119action=edit Patch to pedwarn. This doesn't have the right column pointed out. Also, the message (and that given by clang) is, in my opinion, obscure. At least this starts the ball rolling.
[Bug web/61782] always_inline incorrectly documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782 --- Comment #2 from Daniel Santos daniel.santos at pobox dot com --- Hmm, I suppose I wasn't considering that interpretation of the language. Your clarification helps though, and actually sounds pretty good: always_inline forces inlining of the function under all circumstances and it is an error if the function cannot be inlined. I know that I am not the only person who has read the original language and interpreted it as marking the function inline-able, even if if inlining (-finline-functions) isn't enabled, yet still subject to other considerations for a determination as to rather or not the function body is actually inlined, (i.e., the inline insn count). So can we get some clarification similar to the language you used above?
[Bug c++/60608] Template argument problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60608 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.10.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug c/61803] New: error reports macro location first, but should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803
Bug ID: 61803
Summary: error reports macro location first, but should not
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
This is not really a C-specific bug but I wasn't sure
where else to file it.
Consider this source:
#define Nil ((int *) 0)
double *fun(void)
{
return Nil;
}
Now compile:
barimba. gcc --syntax-only q.c
q.c: In function ‘fun’:
q.c:1:13: warning: return from incompatible pointer type
[-Wincompatible-pointer-types]
#define Nil ((int *) 0)
^
q.c:5:10: note: in expansion of macro ‘Nil’
return Nil;
^
I think the warning and the note should be switched here.
Some tools -- e.g., emacs -- prioritize different output from the
compiler differently. By default emacs' next-error will take one
to the errors and warnings, but skip the notes. This seems
reasonable enough to me. However, for the above output, this means
skipping the spot that is probably the cause of the error.
I think instead it would be better to emit the warning at the final
location and then print the macro definition information as notes.
[Bug fortran/56218] [OOP] Segfault with allocatable intent(out) derived type argument having allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56218 --- Comment #4 from Rich Townsend townsend at astro dot wisc.edu --- Seems to work fine on 4.10 (20140710).
[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
Alexander Monakov amonakov at gcc dot gnu.org changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #25 from Alexander Monakov amonakov at gcc dot gnu.org ---
I have tried to bootstrap and regtest the patch (to be attached) that reflects
the latest comments on the mailing list (except the concern raised by Jan about
C++ optimization). Unfortunately the patch regresses the following simple C++
testcase, not folding the conditional access to the constant (even at -O3), but
not emitting the constant either and thus causing an undefined reference at
link time. Uncommenting the commented line allows folding but also emits the
definition of the static member, increasing .rodata size.
It seems odd to me that decl_replaceable_p(z::cst) is true, and that for
instance TREE_PUBLIC(z::cst) is true. Any help here please?
struct z {
static const int cst = 1;
};
// const int z::cst;
int foo(int cond)
{
return cond ? z::cst : 0;
}
[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added Attachment #32830|0 |1 is obsolete|| --- Comment #26 from Alexander Monakov amonakov at gcc dot gnu.org --- Created attachment 33120 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33120action=edit updated patch
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 --- Comment #29 from Pat Haugen pthaugen at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #21) (In reply to Pat Haugen from comment #19) So in the case where MIN_INT32 is passed (sign extended), the upper 32 bits are '1' so r212352 returns a value of 63 whereas prior revisions returned a value of 31. When called with r3=8000 the new code returns -1 as far as I can see? The new code is doing a logical shift right of the full 64-bit reg, which will require 63 shifts for the value in the reg to become zero. And it should be called with 8000 instead; does the caller not have a prototype in scope? No, there is no prototype, which is really the problem because it should be passed zero-extended as you say in which case either of the code sequences would work. I tried the benchmark after the patch went in, and it is back to generating the rldicl insn and the benchmark passes.
[Bug other/61796] gcc arm hardfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61796 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org --- I think you need to mention the options you passed to configure. Does not --with-float=hard work? I'd also expect a target triplet arm-openwrt-linux-gnueabihf (note the hf) to get the right defaults, maybe even as the preferred means. I'd *not* expect the right thing to happen just passing CFLAGS_FOR_TARGET to make.
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- Its not really a glitch. In this case reversion has occurred so i can only approximate where in the string the error occured. I can improve on it with: offset = fmt-reversion_ok ? fmt-format_string_len + 2: dtp-format_len - fmt-format_string_len; I don't think I can do better for now. Of course we want diagnostics to be helpful, but they can not be perfect. I would suggest we commit the patch for now. What about the following? if (f != NULL) -fmt-format_string = f-source; +fmt-format_string_len = strrchr (f-source, ')') - f-source[0] + 1; It is clumsy, but it does the trick. If accepted, I can write a test case for it.
[Bug c++/61803] error reports macro location first, but should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-14 CC||manu at gcc dot gnu.org Component|c |c++ Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Tom Tromey from comment #0) This is not really a C-specific bug but I wasn't sure where else to file it. I would suggest file it against C++, just because there are more regular contributors to C++ (Jason and Paolo) than to C (only Joseph and not nearly as regular). In C++, we get: test.c:1:23: error: cannot convert ‘int*’ to ‘double*’ in return #define Nil ((int *) 0) ^ test.c:5:10: note: in expansion of macro ‘Nil’ return Nil; ^ It is strange that it points to the closing parenthesis. I think instead it would be better to emit the warning at the final location and then print the macro definition information as notes. In this case yes, but this is not always the case: See PR5252. Perhaps this should be configurable per diagnostic, with the most common case being the default. The default of Clang is the opposite of GCC, for this very reason: test.c:5:10: error: cannot initialize return object of type 'double *' with an rvalue of type 'int *' return Nil; ^~~ test.c:1:13: note: expanded from macro 'Nil' #define Nil ((int *) 0) ^~~
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #30 from Jeffrey A. Law law at redhat dot com --- Richi -- in response to your question in c#26. I'll be looking at a handful of DOM issues while in transit to the Cauldron. That'll include another evaluation of whether or not we want to thread across back edges at all. Invalidation of equivalences after traversing a backedge has been extremely problematical and I really question it's value in the real world.
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org ---
(In reply to dhowe...@redhat.com from comment #1)
Thanks for reporting, I'll take this. (I don't autotest cris-linux not
crisv32-linux; they aren't in general use anymore.)
I needed the following change to gcc (courtesy of Nick Clifton) to get
cris-gcc to build at all, even without libgcc:
Index: gcc/config.gcc
===
--- gcc/config.gcc
+++ gcc/config.gcc
@@ -1130,7 +1130,7 @@
crisv32-*-linux* | cris-*-linux*)
tm_file=dbxelf.h elfos.h ${tm_file} gnu-user.h linux.h glibc-stdint.h
cris/linux.h
# We need to avoid using t-linux, so override default tmake_file
- tmake_file=cris/t-cris cris/t-linux t-slibgcc t-linux
+ tmake_file=${tmake_file} cris/t-cris cris/t-linux t-slibgcc
extra_options=${extra_options} cris/linux.opt
case $target in
cris-*-*)
Obvious breakages (for obvious reasons with obvious correct results) is covered
by the obviousness rule and thus free to commit for anyone (including you).
In fact, this typo (missing prepending of ${tmake_file}), supposedly introduced
at the time of some general config-revision, is shared with several targets.
JFTR:
This behaviour can be produced with the SVNREV 212237 (2014-07-02) gcc-4.9.0
compiler tarball plus one patch and then the following config:
[...]
No need for specific options besides --target nor special paths given target
binutils in the PATH; you should set that instead. (Sadly, no specific
options with the exception of sysroot / build-sysroot options unless hoops are
jumped through, but I hope to fix that one day for all cross-targets.) Also, a
multitude of options like this magnitude is a red flag. (Your cross-build
setup is flawed, but I doubt that's the root of the build problem.)
Anyway, I've added a reduced libgcc2.i that causes the error to occur.
Thanks.
I don't think it'll help because you need the intermediate-stage compiler
binaries also.
Incorrect. This is a *cross-compiler*. Even if it was a native build, failing
building the first stage libgcc build makes the stageness issue moot. :)
libgcc is built with:
make -C cris-linux-gnu tooldir=/usr all-target-libgcc
I'd expect make all-target-libgcc to Just Work.
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 --- Comment #31 from rguenther at suse dot de rguenther at suse dot de --- On July 14, 2014 8:57:31 PM CEST, law at redhat dot com gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #30 from Jeffrey A. Law law at redhat dot com --- Richi -- in response to your question in c#26. I'll be looking at a handful of DOM issues while in transit to the Cauldron. That'll include another evaluation of whether or not we want to thread across back edges at all. Invalidation of equivalences after traversing a backedge has been extremely problematical and I really question it's value in the real world. For the case that triggered the miscompile it was useful. BTW, we do have exactly all information necessary to invalidate with the dom walker unwind stack. It just needs to be made somewhat more accessible, no?
[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757 --- Comment #32 from Jeffrey A. Law law at redhat dot com --- No, we don't have that information available in any reasonable form. That's one of the things I need to investigate. One of the possibilities is to flip things on their side a bit. The old code started recording equivalences it might need to invalidate when it traversed the backedge. Part of the problem with that scheme is some of the equivalences were already recorded by tree-ssa-dom.c, independent of the threading bits. We didn't have a way to find or invalidate those equivalences. One of the things I want to look at is whether or not we can start recording when we process a PHI with arguments that are the targets of backedges. I haven't prototyped any code around that and I'm not sure if we'll have a reasonable separation between DOM and the threading code, but that's the first thing I want to look at once I deal with Teresa's changes.
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org ---
(In reply to Hans-Peter Nilsson from comment #3)
(In reply to dhowe...@redhat.com from comment #1)
Index: gcc/config.gcc
===
--- gcc/config.gcc
+++ gcc/config.gcc
@@ -1130,7 +1130,7 @@
crisv32-*-linux* | cris-*-linux*)
tm_file=dbxelf.h elfos.h ${tm_file} gnu-user.h linux.h glibc-stdint.h
cris/linux.h
# We need to avoid using t-linux, so override default tmake_file
- tmake_file=cris/t-cris cris/t-linux t-slibgcc t-linux
+ tmake_file=${tmake_file} cris/t-cris cris/t-linux t-slibgcc
Obvious breakages (for obvious reasons with obvious correct results) is
covered by the obviousness rule and thus free to commit for anyone
(including you).
Except it's only obvious in the absence of a comment explaining the
exception. Doh! So, there's another issue and that patch is incorrect (do
*not* apply it). Also, I don't remember what aspects of t-linux needs
avoiding. Looking into it...
[Bug target/61794] internal error: unrecognizable insn, from avx512 extract instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61794 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-14 CC||kyukhin at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 Severity|major |normal --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Confirmed, adding CC.
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr ---
A little bit less clumsy
if (f != NULL)
-fmt-format_string = f-source;
+fmt-format_string_len = strrchr (f-source, ')') - f-source + 1;
I don't understand why
+fmt-format_string_len = strchr (f-source, '\0') - f-source;
is not working. With the following instrumentation
if (f != NULL)
{
fmt-format_string_len = strrchr (f-source, ')') - f-source + 1;
if (strchr (f-source, '\0')-strrchr (f-source, ')')1)
printf(pos 0 =%x, pos ) =%x\n,strchr (f-source, '\0'),strrchr
(f-source, ')'));
}
I get
pos 0 =c2c048c0, pos ) =c2c048b1
At line 8 of file pr61632_1_db_5.f90 (unit = 6, file = 'stdout')
Fortran runtime error: Expected REAL for item 2 in formatted transfer, got
CHARACTER
(A3,1PE13.5,2(A3))
^
for
program p
call ss()
end program p
subroutine ss
CHARACTER(3), save :: ZTYP(4)
DATA ZTYP /'WWW','XXX','YYY','ZZZ'/
write(*,600) 'AAA','BBB',0.0,ZTYP
600 FORMAT(A3,1PE13.5,2(A3))
end subroutine ss
Any idea?
[Bug other/61796] gcc arm hardfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61796 Luka Perkov luka.perkov at sartura dot hr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Luka Perkov luka.perkov at sartura dot hr --- Comment from Hans-Peter fixed the issue.
[Bug other/61796] gcc arm hardfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61796 --- Comment #3 from Luka Perkov luka.perkov at sartura dot hr --- Hi Hans-Peter, (In reply to Hans-Peter Nilsson from comment #1) I think you need to mention the options you passed to configure. Does not --with-float=hard work? I'd also expect a target triplet arm-openwrt-linux-gnueabihf (note the hf) to get the right defaults, maybe even as the preferred means. I'd *not* expect the right thing to happen just passing CFLAGS_FOR_TARGET to make. You were right, to configure was not passed --with-float=hard. Doing that fixed the problem I was seeing. Thank you. Luka
[Bug c++/61445] [4.10 Regression][C++11] ice in instantiate_decl at cp/pt.c:19770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61445 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/61445] [4.10 Regression][C++11] ice in instantiate_decl at cp/pt.c:19770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61445 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jul 14 20:39:35 2014 New Revision: 212524 URL: https://gcc.gnu.org/viewcvs?rev=212524root=gccview=rev Log: PR c++/61445 PR c++/56947 * pt.c (instantiate_decl): Don't check defer_ok for local class members. Added: trunk/gcc/testsuite/g++.dg/template/local9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/56947] [4.7 Regression] Bogus 'XX' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56947 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jul 14 20:39:35 2014 New Revision: 212524 URL: https://gcc.gnu.org/viewcvs?rev=212524root=gccview=rev Log: PR c++/61445 PR c++/56947 * pt.c (instantiate_decl): Don't check defer_ok for local class members. Added: trunk/gcc/testsuite/g++.dg/template/local9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/61623] [4.10 Regression] ICE: verify_symtab failed: Two symbols with same comdat_group are not linked by the same_comdat_group list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61623 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libfortran/60324] Handle arbitrarily long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324 Rich Townsend townsend at astro dot wisc.edu changed: What|Removed |Added CC||townsend at astro dot wisc.edu --- Comment #6 from Rich Townsend townsend at astro dot wisc.edu --- This change introduces a dependency on strndup -- which, alas, is absent from libSystem in OS X 10.6 (Snow Leopard), although later releases of OS X include it. This isn't a problem per se, as it appears that an internal strndup will be built if a system one can't be found. Howver, today, I've run into the problem that when I build gcc/gfortran (trunk) on 10.9, I can't then use the compiler on 10.6 due to the reference in libgfortran (and perhaps elsewhere) to the (missing) system strndup. Any suggestions for workarounds? Can I hack libgfortran/configure.ac to force the internal strndup to be used? cheers, Rich
[Bug rtl-optimization/38603] [4.8/4.9/4.10 Regression] reload inheritance mucks up LOAD_EXTEND_OP transformations done by combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38603 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME Target Milestone|4.8.4 |4.10.0 --- Comment #10 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (Not even) with the current moral equivalent of the attached MMIX IRA_COVER_CLASSES patch, i.e. just excluding the fake MMIX_ARG_POINTER_REGNUM from SYSTEM_REGS (as all IRA_COVER_CLASSES macros are obsoleted and forbidden as defined by the first part), do I see any change in test-results at r212486. Specifically, gcc.c-torture/execute/20040709-1.c does not fail. Hence, I'm closing this. Though, the issue is likely just hidden.
[Bug c++/61804] New: rejects-valid if parenthesized temporary is incremented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61804
Bug ID: 61804
Summary: rejects-valid if parenthesized temporary is
incremented
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Related to PR56239, GCC rejects valid on this:
struct T { void operator++(int); };
void f() { (T())++; }
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2014-7-15 --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Confirmed the observation at r212508, with the patch in the attachment in the next comment.
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Created attachment 33121 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33121action=edit Patch to config.gcc Correct patch to config.gcc required to actually build the compiler proper.
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #7 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to dhowe...@redhat.com from comment #0) BTW, Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://bugzilla.redhat.com/bugzilla/ for instructions. The bug is not reproducible, so it is likely a hardware or OS problem. I'm also very intrigued by that last line - I can reproduce it quite easily. This is a RH local patch in your host gcc (by Jakub, IIRC) to help users re-running the actual ICEing command adding -save-temps. I'm guessing it has a bug and accidentally drops some option required to reproduce the ICE...
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #13 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- This: +fmt-format_string_len = strrchr (f-source, ')') - f-source + 1; Is taking the difference between two string pointers, ie memory addresses This: printf(pos 0 =%x, pos ) =%x\n,strchr (f-source, '\0'),strrchr (f-source, ')')); Is printing the value of the pointers, the addresses. Are you expecting something different?
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 --- Comment #14 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #10) --- snip --- Is the printing of 'YYY' supposed to happen? Its sort of like Steve said earlier. The coder is choosing to ignore an error condition so anything gfortran does is valid. In this case the output got wriiten to buffer before the error occurred. You are bypassing all of the normal error handling when you do this. The buffer got flushed. Its not worth the time to change any of it really. The program should exit, its invalid.
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #8 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to dhowe...@redhat.com from comment #0) ../../../gcc-4.9.0-20140702/libgcc/libgcc2.c: In function ‘__subvsi3’: ../../../gcc-4.9.0-20140702/libgcc/libgcc2.c:122:1: error: unrecognizable insn: } ^ (call_insn 27 26 28 7 (parallel [ (call (mem:QI (symbol_ref:SI (abort) [flags 0x41] function_decl 0x7f5784e05d00 abort) [0 __builtin_abort S1 A8]) This symbol_ref must be wrapped inside a CONST by the middle-end. Something changed such that that doesn't happen anymore; that's the bug. Unless this was a deliberate general change in representation, which I doubt. Still investigating...
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #9 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Hans-Peter Nilsson from comment #8) This symbol_ref must be wrapped inside a CONST by the middle-end. Uh, strike that, I'm hallucinating.
[Bug libstdc++/61720] std::regex_search matches incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61720 --- Comment #1 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Tue Jul 15 04:28:51 2014 New Revision: 212539 URL: https://gcc.gnu.org/viewcvs?rev=212539root=gccview=rev Log: PR libstdc++/61720 * include/bits/regex_executor.tcc (_Executor::_M_main_dispatch): Clear match queue for next use. * testsuite/28_regex/algorithms/regex_search/61720.cc: New file. Added: trunk/libstdc++-v3/testsuite/28_regex/algorithms/regex_search/61720.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex_executor.tcc
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org --- What is the kernel version? There has been some recent (this year) fixes inside the kernel for futex. Though I admit I have seen this just recently when debugging a program where I did next over a pthread_mutex_unlock call.
