[Bug c/49467] Enhancement: Intrinsic to read CARRY and OVERFLOW flags (where applicable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49467 Martin von Gagern Martin.vGagern at gmx dot net changed: What|Removed |Added CC||Martin.vGagern at gmx dot net --- Comment #2 from Martin von Gagern Martin.vGagern at gmx dot net --- Perhaps bug #59708 is a better candidate for this issue here than bug #48580, particularly in the light of bug #48580 comment #18 and #19. Can someone change the resolution of this here to duplicate that instead?
[Bug c/59708] clang-compatible checked arithmetic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 Martin von Gagern Martin.vGagern at gmx dot net changed: What|Removed |Added CC||Martin.vGagern at gmx dot net --- Comment #7 from Martin von Gagern Martin.vGagern at gmx dot net --- I really like this request, thanks! Cross references: bug #49467 asked for access to carry, and got duped to bug #48580 which originally was about detecting and optimizing certain idioms which may be used to detect overflow within the limits of the language standard. I'd say bug #49467 might be better off duped to this one here instead.
[Bug middle-end/48580] missed optimization: integer overflow checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 --- Comment #21 from Martin von Gagern Martin.vGagern at gmx dot net --- (In reply to myself from comment #15) (In reply to comment #7) […] built-in operations where you can just say multiply two (signed) values, check whether the result fits in 31-bit unsigned and set an overflow flag accordingly. Would be easier to read, easier to maintain, and less difficult to detect. Sounds like an overall win. I'm very much in favor of builtins like these. I'd rather make the overflow indicator the return value, and transfer the result to a location indicated via a pointer. Cross reference: bug #59708 is going in this direction, motivated by a precedence set by clang. (In reply to Zack Weinberg from comment #18) I just want the code in the original bug report to be optimized. I suggested duping bug #49467 there instead, in which case this issue here could return to the originally requested goal of detecting idioms without relying on builtins.
[Bug c/59708] clang-compatible checked arithmetic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- I rather not have builtins as you can write portable C code that detects overflow just fine. GCC could have internal functions if needed which are used when converting the pattern for detecting overflow.
[Bug c/59708] clang-compatible checked arithmetic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 --- Comment #9 from Martin von Gagern Martin.vGagern at gmx dot net --- (In reply to Andrew Pinski from comment #8) I rather not have builtins as you can write portable C code that detects overflow just fine. GCC could have internal functions if needed which are used when converting the pattern for detecting overflow. Then it sounds as if bug #48580 should cater for your needs. Although bug #48580 comment #7 raised the concern that there appears to be no commonly established pattern, therefore detecting such patterns would become difficult. http://stackoverflow.com/q/199333/1468366 also discusses overflow detection patterns, and the current highest-voted answer is a performance nightmare. But better solutions seem impossible due to the fact that according to (at least some version of) the language specs, signed overflow leads to undefined behavior, so the overflow has to be detected before the operation is performed. If you want to prove me wrong, answer bug #48580 comment #5 with your favorite pattern and show examples to support that this is in reasonably wide-spread use. I believe that builtins would be easier to read and easier to maintain. To me, this sounds like an overall win, albeit at the cost of portability. But with this proposal here we'd at least have compatibility with clang. In any case, I don't think there is a reason against supporting both, a builtin and a pattern detection. I consider the former far more realistic in the forseeable future, and the latter can build on that internally.
[Bug c++/62243] New: Non-typename template argument behaviour in loop (unsigned int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62243
Bug ID: 62243
Summary: Non-typename template argument behaviour in loop
(unsigned int)
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bjodah at gmail dot com
I have come across something that puzzles me quite a bit, consider this small
program:
#include iostream
template int w
void f(){
for (int i=-1*static_castint(w); i = w; ++i)
std::cout i std::endl;
}
int main()
{
f3();
return 0;
}
which generates as expected output -3 to 2.
However changing the type of the non-type template argument to unsigned int,
i.e. `template unsigned int w` makes the program skip the loop. (g++ 4.8.2
clang++ 3.4)
Is this a bug in the compiler or is it the expected behaviour?
[Bug middle-end/62242] ICE in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-24 CC||Joost.VandeVondele at mat dot ethz ||.ch Component|fortran |middle-end Summary|ICE with character function |ICE in expand_expr_real_1 |in expression | Ever confirmed|0 |1 Known to fail||4.6.0, 4.7.0, 4.8.0, 4.9.0, ||5.0 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- confirmed with current trunk and 4.6 - 4.9 module gfbug contains pure function UpperCase(string) result(upper) character(*), intent(IN) :: string character(LEN(string)) :: upper do i = 1, LEN_TRIM(upper) enddo end function pure function isNotElementOf(scalar, array) result(status) logical :: status character(*), intent(IN) :: scalar, array(:) status = .NOT. ANY(UpperCase(scalar) == [(UpperCase(array(i)), i = 1, SIZE(array))]) end function end module gfbug This ICE is actually not in the Fortran Frontend, but rather some later pass 0x7f93fd expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:9497 0x7016f0 expand_normal ../../gcc/gcc/expr.h:458 0x7016f0 precompute_register_parameters ../../gcc/gcc/calls.c:831 0x7016f0 expand_call(tree_node*, rtx_def*, int) ../../gcc/gcc/calls.c:3012 0x7f892e expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10385 0x804d50 store_expr(tree_node*, rtx_def*, int, bool) ../../gcc/gcc/expr.c:5318 0x807b9a expand_assignment(tree_node*, tree_node*, bool) ../../gcc/gcc/expr.c:5104 0x711800 expand_call_stmt ../../gcc/gcc/cfgexpand.c:2316 0x711800 expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3213 0x711800 expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3371 0x7174f7 expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5210 0x71919a execute ../../gcc/gcc/cfgexpand.c:5816
[Bug c++/62243] Non-typename template argument behaviour in loop (unsigned int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62243 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- i = w if I and w are int then the compare is done in int but if w is unsigned int, then it is done in unsigned int so (unsigned int)-3 is always greater than 3.
[Bug c++/62243] Non-typename template argument behaviour in loop (unsigned int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62243 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- Please always compile your programs with -Wall, it would have told you what was wrong.
[Bug c++/62243] Non-typename template argument behaviour in loop (unsigned int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62243 --- Comment #3 from Bjoern Dahlgren bjodah at gmail dot com --- Will do. Sorry for this and thank you.
[Bug c++/62244] New: Function parameter should be in scope in its own default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62244 Bug ID: 62244 Summary: Function parameter should be in scope in its own default argument Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zeratul976 at hotmail dot com Consider the following code: int a; void f(int a = a); GCC accepts this code, and name lookup for the 'a' in the default argument finds the global variable 'a' (as suggested by the fact that if the global variable 'a' is commented out, GCC now gives error: 'a' was not declared in this scope). I believe this in incorrect. During name lookup for the 'a' in the default argument, the parameter 'a' should already be in scope, since [basic.scope.pdecl]/p1 says that The point of declaration for a name is immediately after its complete declarator and before its initializer (if any). Once name lookup finds the parameter, the program should then be ill-formed, because [dcl.fct.default]/p9 says parameters of a function shall not be used in a default argument. Note that GCC has the correct behaviour when a later parameter's default argument references an earlier parameter: int a; void f(int a, int b = a); // error: local variable 'a' may not appear in this context The incorrect behaviour only occurs when a parameter's own default argument references the parameter. Note that clang rejects the first example with error: default argument references parameter 'a'.
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #28 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- actually, minloc/maxloc are also Fortran intrinsics, and while expanded inline, don't vectorize either. The following testcase runs 5x faster with ifort than with gfortran: INTEGER FUNCTION ana(a) REAL :: a(1024) ana=maxloc(a,1) END FUNCTION INTEGER :: NRUN=100 REAL :: a(1024) INTEGER :: ana,I a=(/(I,I=1,1024)/) DO I=1,NRUN j=j+ana(a) ENDDO WRITE(6,*) NRUN,j,ana(a) END ifort -fast -no-ipo -fno-inline-functions t.f90 ; time ./a.out 100 1024001024 real0m0.233s user0m0.228s sys0m0.004s gfortran -Ofast -fno-inline-functions t.f90 ; time ./a.out 100 1024001024 real0m1.193s user0m1.188s sys0m0.000s
[Bug libstdc++/62169] map iterators under _GLIBCXX_DEBUG diverge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- It's not an option IMHO. See http://www.stroustrup.com/SCARY.pdf for the benefits of the current design. Those benefits outweigh the advantage of having non-portable code diagnosed. Debug iterators can't be SCARY because they have a pointer back to their patent container so have to depend on the exact type.
[Bug libstdc++/62169] map iterators under _GLIBCXX_DEBUG diverge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #6) they have a pointer back to their patent container s/patent/parent/ As for solving the problem of switching containers, use a typedef for the container, or auto for the iterator. It doesn't need to be solved by the compiler.
[Bug target/61996] [SH] -musermode conflicts with -matomic-model=soft-imask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61996 --- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sun Aug 24 10:46:25 2014 New Revision: 214406 URL: https://gcc.gnu.org/viewcvs?rev=214406root=gccview=rev Log: gcc/ PR target/61996 * config/sh/sh.opt (musermode): Allow negative form. * config/sh/sh.c (sh_option_override): Disable TARGET_USERMODE for targets that don't support it. * doc/invoke.texi (SH Options): Rename sh-*-linux* to sh*-*-linux*. Document -mno-usermode option. gcc/testsuite PR target/61996 * gcc.target/sh/pr61996.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr61996.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug target/61996] [SH] -musermode conflicts with -matomic-model=soft-imask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61996 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sun Aug 24 10:52:58 2014 New Revision: 214407 URL: https://gcc.gnu.org/viewcvs?rev=214407root=gccview=rev Log: gcc/ Backport from mainline 2014-08-24 Oleg Endo olege...@gcc.gnu.org PR target/61996 * config/sh/sh.opt (musermode): Allow negative form. * config/sh/sh.c (sh_option_override): Disable TARGET_USERMODE for targets that don't support it. * doc/invoke.texi (SH Options): Rename sh-*-linux* to sh*-*-linux*. Document -mno-usermode option. gcc/testsuite Backport from mainline 2014-08-24 Oleg Endo olege...@gcc.gnu.org PR target/61996 * gcc.target/sh/pr61996.c: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/sh/pr61996.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sh/sh.c branches/gcc-4_9-branch/gcc/config/sh/sh.opt branches/gcc-4_9-branch/gcc/doc/invoke.texi branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug fortran/62245] New: gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245 Bug ID: 62245 Summary: gfortran miscompiles int() on mips Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jtaylor.debian at googlemail dot com gfortran miscompiles int() for negative overflows leading to a build timeout of python-scipy, see #756905 below a testcase, according to https://gcc.gnu.org/onlinedocs/gfortran/INT.html the result should be -2147483648 (sid_mips-dchroot)jtaylor@gabrielli:~$ apt-cache policy gfortran gfortran: Installed: 4:4.9.1-1 Candidate: 4:4.9.1-1 Version table: *** 4:4.9.1-1 0 500 http://mirror-ubc.debian.org/debian/ sid/main mips Packages 100 /var/lib/dpkg/status (sid_mips-dchroot)jtaylor@gabrielli:~$ cat test.f90 program add implicit none real a,b,s read *, a print *, ' is ' , int(a) stop end (sid_mips-dchroot)jtaylor@gabrielli:~$ gfortran test.f90 (sid_mips-dchroot)jtaylor@gabrielli:~$ ./a.out -1e99 is 2147483647 Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_OVERFLOW_FLAG
[Bug fortran/62246] New: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62246 Bug ID: 62246 Summary: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch The following testcase generates an ICE, it has been reduced from PR62242, which seems to trigger a bug in the middle end, maybe it is related : cat bug.f90 module gfbug INTERFACE pure function UpperCase(string) result(upper) character(*), intent(IN) :: string character(LEN(string)) :: upper end function END INTERFACE contains pure function isNotElementOf(array) result(status) logical :: status character(*), intent(IN) :: array(:) status = ANY(a==(/UpperCase(array(1))/)) end function end module gfbug gfortran -fdump-tree-original bug.f90 bug.f90:12:0: status = ANY(a==(/UpperCase(array(1))/)) ^ internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1313 0x660e64 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/gcc/fortran/trans-decl.c:1313 0x692d75 gfc_conv_intrinsic_len ../../gcc/gcc/fortran/trans-intrinsic.c:5303 0x692d75 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/gcc/fortran/trans-intrinsic.c:7708 0x67a042 gfc_conv_function_expr ../../gcc/gcc/fortran/trans-expr.c:5618 0x66fd23 gfc_conv_expr_val(gfc_se*, gfc_expr*) ../../gcc/gcc/fortran/trans-expr.c:6426 0x66fdc8 gfc_conv_expr_type(gfc_se*, gfc_expr*, tree_node*) ../../gcc/gcc/fortran/trans-expr.c:6440 0x64d83b gfc_add_loop_ss_code ../../gcc/gcc/fortran/trans-array.c:2562 0x64e083 gfc_conv_loop_setup(gfc_loopinfo*, locus*) ../../gcc/gcc/fortran/trans-array.c:4692 0x67d4c9 gfc_conv_intrinsic_anyall ../../gcc/gcc/fortran/trans-intrinsic.c:3201 0x69185d gfc_conv_intrinsic_anyall ../../gcc/gcc/fortran/trans-intrinsic.c:3173 0x69185d gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/gcc/fortran/trans-intrinsic.c:7453 0x67a042 gfc_conv_function_expr ../../gcc/gcc/fortran/trans-expr.c:5618 0x66e28a gfc_trans_assignment_1 ../../gcc/gcc/fortran/trans-expr.c:8077 0x63aa15 trans_code ../../gcc/gcc/fortran/trans.c:1639
[Bug middle-end/62242] ICE in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Further reduced: cat bug.f90.orig module gfbug contains pure function UpperCase(string) result(upper) character(*), intent(IN) :: string character(LEN(string)) :: upper upper=string end function pure function isNotElementOf(array) result(status) logical :: status character(*), intent(IN) :: array(:) status = ANY(a==(/UpperCase(array(1))/)) end function end module gfbug which yields the same segfault. A differently reduced testcase, however, yield a FE segfault and has been added as PR62246.
[Bug target/61996] [SH] -musermode conflicts with -matomic-model=soft-imask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61996 --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sun Aug 24 11:15:37 2014 New Revision: 214408 URL: https://gcc.gnu.org/viewcvs?rev=214408root=gccview=rev Log: gcc/ Backport from mainline 2014-08-24 Oleg Endo olege...@gcc.gnu.org PR target/61996 * config/sh/sh.opt (musermode): Allow negative form. * config/sh/sh.c (sh_option_override): Disable TARGET_USERMODE for targets that don't support it. * doc/invoke.texi (SH Options): Rename sh-*-linux* to sh*-*-linux*. Document -mno-usermode option. gcc/testsuite Backport from mainline 2014-08-24 Oleg Endo olege...@gcc.gnu.org PR target/61996 * gcc.target/sh/pr61996.c: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/sh/pr61996.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/sh/sh.c branches/gcc-4_8-branch/gcc/config/sh/sh.opt branches/gcc-4_8-branch/gcc/doc/invoke.texi branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/61996] [SH] -musermode conflicts with -matomic-model=soft-imask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61996 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org --- Fixed on 4.8, 4.9 and trunk.
[Bug fortran/62245] gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245 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 --- well, the docs as well as the standard assume there that all numbers are representable. Note that some compilers (ifort) won't even read -1e99 in a real, as this exceeds the range of the real, and abort at the read statement. The behavior on x86 is just following what the hardware does, for example CVTTSS2SI, and will yield : If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (8000H) is returned.
[Bug fortran/62245] gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245 --- Comment #2 from Julian Taylor jtaylor.debian at googlemail dot com --- mips is the only architecture with this behavior, all others behave as documented. Shouldn't that be reason enough to change mips? if not please document the exception on mips.
[Bug fortran/62245] gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Julian Taylor from comment #2) mips is the only architecture with this behavior, all others behave as documented. Shouldn't that be reason enough to change mips? if not please document the exception on mips. Not quite, for example on x86 (additionally writing a): ./a.out 1e99 is Infinity -2147483648 (note sign). It is just undefined behavior. I assume mips results are correct if the input real fits the range of the integer ?
[Bug fortran/62245] gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245 --- Comment #4 from Julian Taylor jtaylor.debian at googlemail dot com --- no x86 behaves as documented, the documentation states the sign is retained. You can debate on what largest integer means here, it could be -1 as -2147483648 but as positive inputs give -2147483647 I think x86 output is as intended.
[Bug fortran/62245] gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245 --- Comment #5 from Julian Taylor jtaylor.debian at googlemail dot com --- oh I overlooked you put in positive input, thats strange then the documentation should be updated that its undefined behavior.
[Bug fortran/62245] gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Julian Taylor from comment #5) oh I overlooked you put in positive input, thats strange then the documentation should be updated that its undefined behavior. I think the docs are OK, as they follow literally the standard, and neither the standard nor the gfortran docs usually point out undefined behavior. So I'll close the report as invalid. Thanks nevertheless.
[Bug fortran/62245] gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245 --- Comment #7 from Julian Taylor jtaylor.debian at googlemail dot com --- But the docs indicate that there is no undefined behavior. As I interpret them the result of int() is always well defined. If the documentation would not state what happens in the case of overflow it would be fine to not mention it, but as is one has to know the standard to know that this part of the documentation is wrong.
[Bug fortran/62245] gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Julian Taylor from comment #7) But the docs indicate that there is no undefined behavior. As I interpret them the result of int() is always well defined. If the documentation would not state what happens in the case of overflow it would be fine to not mention it, but as is one has to know the standard to know that this part of the documentation is wrong. I'll submit a patchlet to clarify the wording in the docs (the issue is the use of range vs magnitude, which suggests defining behavior in the case of overflow).
[Bug fortran/62245] gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245 --- Comment #9 from Julian Taylor jtaylor.debian at googlemail dot com --- thanks, please also clarify/remove the sentence about the sign as the result sign is not the sign of the input as indicated by the docs.
[Bug fortran/62245] gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Julian Taylor from comment #9)
thanks, please also clarify/remove the sentence about the sign as the result
sign is not the sign of the input as indicated by the docs.
it will now include:
The result is undefined if it can not be represented as an @code{INTEGER} of
the given @code{KIND}.
which is explicit.
[Bug middle-end/62247] New: [5.0 Regression] FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62247 Bug ID: 62247 Summary: [5.0 Regression] FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/test/gnu/gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/abi/ anon3.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11 .11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backwa rd -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++98 -pedantic-errors -Wno-long-long -S -o anon3.s(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/test/gnu/gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/abi/anon3.C -fno- diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++98 -pedantic-errors -Wno-long-long -S -o anon3.s PASS: g++.dg/abi/anon3.C -std=c++98 (test for excess errors)PASS: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)?[ \t]_?_ ZN4Heya4blahEvFAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)?[ \t]_?_ZTI4HeyaPASS: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)?[ \t]_?_ZTV4HeyaPASS: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)?[ \t]_?_ZN4Heya1A1fEv FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)?[ \t]_?_ZTIN4Heya1AE PASS: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)?[ \t]_?_ZTVN4Heya1AE Similar fail: FAIL: g++.dg/abi/rtti3.C -std=c++98 scan-assembler .weak[ \t]_?_ZTSPP1A
[Bug fortran/62245] gfortran miscompiles int() on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #11 from kargl at gcc dot gnu.org --- (In reply to Julian Taylor from comment #7) But the docs indicate that there is no undefined behavior. As I interpret them the result of int() is always well defined. If the documentation would not state what happens in the case of overflow it would be fine to not mention it, but as is one has to know the standard to know that this part of the documentation is wrong. The standard states (13.7.1) A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters, unless the intrinsic module IEEE ARITHMETIC (clause 14) is accessible and there is support for an infnite or a NaN result, as appropriate. a = +-1e99 is outside of the representable range of INTEGER, so by calling INT(a), your program is nonconforming. gfortran can do anything and the result is valid.
[Bug c++/61825] [5 regression] g++.dg/cpp0x/static_assert9.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61825 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #2 from John David Anglin danglin at gcc dot gnu.org --- Also seen on hppa2.0w-hp-hpux11.11.
[Bug other/62210] download_prerequisites does not download into current directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62210 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Segher Boessenkool segher at gcc dot gnu.org --- -nd is the default if not using -r. Something seems to be amiss with your installation of wget?
[Bug other/62248] New: Configure error with --with-fpu=fp-armv8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62248 Bug ID: 62248 Summary: Configure error with --with-fpu=fp-armv8 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: amanieu at gmail dot com There seems to be a typo in gcc/config.gcc:3531: | fpv4-sp-d16 | neon-vfpv4 | fp-arm-v8 | neon-fp-armv8 \ fp-arm-v8 should be fp-armv8, matching the -mfpu option name.
[Bug lto/62249] New: Spurious FORTIFY_SOURCE warning with -flto, poll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62249
Bug ID: 62249
Summary: Spurious FORTIFY_SOURCE warning with -flto, poll
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
Created attachment 33388
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33388action=edit
test case (compile on recent glibc system)
Compile the attached program on a recent-glibc system with -D_FORTIFY_SOURCE=2
-O2 -flto and you get a spurious warning:
$ gcc -flto -O2 -D_FORTIFY_SOURCE=2 test.c
In function ‘__poll_alias’,
inlined from ‘main’ at test.c:17:9:
/usr/include/x86_64-linux-gnu/bits/poll2.h:41:2: warning: call to
‘__poll_chk_warn’ declared with attribute warning: poll called with fds buffer
too small file nfds entries
return __poll_chk (__fds, __nfds, __timeout, __bos (__fds));
$ gcc -fwhole-program -O2 -D_FORTIFY_SOURCE=2 test.c
$
Inspection of bits/poll2.h leads me to believe that the glibc folks expect this
construct ...
__fortify_function int
poll (struct pollfd *__fds, nfds_t __nfds, int __timeout)
{
if (__bos (__fds) != (__SIZE_TYPE__) -1)
{
if (! __builtin_constant_p (__nfds))
return __poll_chk (__fds, __nfds, __timeout, __bos (__fds));
else if (__bos (__fds) / sizeof (*__fds) __nfds)
return __poll_chk_warn (__fds, __nfds, __timeout, __bos (__fds));
}
return __poll_alias (__fds, __nfds, __timeout);
}
... to have the dead arm of the inner 'if' eliminated (one of them must be
dead, because the condition is a call to __builtin_constant_p) before warnings
are issued.
[Bug libfortran/62250] New: FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62250 Bug ID: 62250 Summary: FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa2. 0w-hp-hpux11.11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarr ay/alloc_comp_1.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -fcoarray=lib -O2 -lcaf_single -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./li bgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -B/test/gnu/gc c/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11 /./libquadmath/.libs -lm-o ./alloc_comp_1.exe(timeout = 300)spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/test/gnu/gcc /objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray/alloc_comp _1.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -fcoarray=lib -O2 - lcaf_single -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/ test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -B/test/gnu/gcc/objdir/hppa2.0w-h p-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./l ibquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.lib s -lm -o ./alloc_comp_1.exe /usr/ccs/bin/ld: Unsatisfied symbols: __atomic_fetch_and_4 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o)) (code) __atomic_compare_exchange_4 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o)) (code) __atomic_fetch_xor_4 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o)) (code) __atomic_fetch_add_4 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o)) (code) __atomic_fetch_or_4 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o)) (code) collect2: error: ld returned 1 exit status Similar fails: FAIL: gfortran.dg/coarray/allocate_errgmsg.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/atomic_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/atomic_2.f90 -fcoarray=single -O2 FAIL: gfortran.dg/coarray/atomic_2.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/codimension.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/coindexed_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/collectives_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/collectives_2.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/dummy_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/get_array.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/image_index_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/image_index_2.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/image_index_3.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/lib_realloc_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/lock_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/move_alloc_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/poly_run_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/poly_run_2.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/poly_run_3.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/registering_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/scalar_alloc_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/scalar_alloc_2.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/send_array.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/sendget_array.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/subobject_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/sync_1.f90 -fcoarray=lib -O2 -lcaf_single FAIL: gfortran.dg/coarray/sync_3.f90
[Bug testsuite/62028] Power64/Linux: FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62028 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-24 CC||segher at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/61298] redundant compare instructions for powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61298 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-24 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Segher Boessenkool segher at gcc dot gnu.org --- This problem goes away (or is hidden) when we also have cstoresi4 for TARGET_POWERPC64. I have a patch for that.
[Bug target/62251] New: [5.0 Regression] FAIL: gfortran.dg/quad_2.f90 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62251 Bug ID: 62251 Summary: [5.0 Regression] FAIL: gfortran.dg/quad_2.f90 execution test Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/quad_2.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never-O0 -pedantic-errors -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test /gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir /hppa2.0w-hp-hpux11.11/./libgfortran/.libs -B/test/gnu/gcc/objdir/hppa2.0w-hp-hp ux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libqu admath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs - lm-o ./quad_2.exe(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/quad_2.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -pedantic-errors -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -lm -o ./quad_2.exePASS: gfortran.dg/quad_2.f90 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc spawn [open ...] Program aborted. Backtrace: #0 0xC1B3A79F FAIL: gfortran.dg/quad_2.f90 -O0 execution test Revision 214122 was OK.
[Bug lto/62249] Spurious FORTIFY_SOURCE warning with -flto, poll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62249 --- Comment #1 from Zack Weinberg zackw at panix dot com --- Created attachment 33389 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33389action=edit Delta-minimized self-contained test case Requires no headers anymore. Delta-minimization revealed something interesting: int __poll_chk (struct pollfd *, unsigned, int, unsigned); int __poll_chk_warn (struct pollfd *, unsigned, int, unsigned) __asm__ (__poll_chk) __attribute__ ((__warning__ (poll called with fds buffer too small))); The __asm__(__poll_chk) annotation is essential; if it's removed the bug goes away. I don't know anything about the guts of LTO, but to me that suggests a bug in its unification of function decls, rather than a bug in dead-code removal.
[Bug lto/62249] Spurious FORTIFY_SOURCE warning with -flto, poll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62249 --- Comment #2 from Zack Weinberg zackw at panix dot com --- Incidentally, yes, the test case is based on a real program.
[Bug plugins/62252] New: a callback to event PLUGIN_FINISH_TYPE segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62252
Bug ID: 62252
Summary: a callback to event PLUGIN_FINISH_TYPE segfaults
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: klemen.jan.enova at gmail dot com
The following plugin is a reduced version of
testsuite/g++.dg/plugin/dumb_plugin.c.
I tested it with
- the ubuntu binary version of gcc-4.9
- ubuntu binary version of gcc-4.8 (g++-4.8 (Ubuntu 4.8.2-19ubuntu1) 4.8.2)
- the compiled version of gcc-4.9 taken from the 4.9 release
(https://github.com/gcc-mirror/gcc/releases/tag/gcc-4_9_0-release)
All tests segfault.
---
kje@kje:~$ uname -a
Linux kje 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13 15:45:27 UTC 2014 x86_64
x86_64 x86_64 GNU/Linux
kje@kje:~/example$ cat example.c
#include gcc-plugin.h
//#include stdlib.h
#include config.h
#include system.h
#include coretypes.h
#include tree.h
#include tree-pass.h
#include intl.h
#include toplev.h
#include diagnostic.h
#include context.h
int plugin_is_GPL_compatible;
void
handle_struct (void *event_data, void *data)
{
tree type = (tree) event_data;
warning(0, G_(Process struct %s),
IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type;
}
int
plugin_init (struct plugin_name_args *plugin_info,
struct plugin_gcc_version *version)
{
register_callback (example, PLUGIN_FINISH_TYPE, handle_struct, NULL);
return 0;
}
kje@kje:~/example$ cat example_test.c
struct S {
int x;
};
int main(void)
{
struct S s;
s.x = 5;
return 0;
}
kje@kje:~/example$ g++-4.9 --version
g++-4.9 (Ubuntu 4.9.1-3ubuntu2~14.04.1) 4.9.1
Copyright (C) 2014 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.
kje@kje:~/example$ g++-4.9 -fPIC -g
-I/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include -c example.c
kje@kje:~/example$ g++-4.9 -fPIC -g
-I/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include -shared
example.o -o example_plugin.so
kje@kje:~/example$ g++-4.9 -fplugin=./example_plugin.so example_test.c
example_test.c:3:1: warning: Process struct S
};
^
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_TYPE | example
example_test.c: In function ‘int main()’:
example_test.c:7:9: internal compiler error: Segmentation fault
struct S s;
^
0x7f1d3226c780 handle_struct(void*, void*)
/home/kje/example/example.c:20
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
---
If I use g++ compiled from (configure with --enable-languagues=c,c++) the
github repository 4.9 release, I get the whole call stack:
---
kje@kje:~/example$ g++ --version
g++ (GCC) 4.9.0
Copyright (C) 2014 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.
kje@kje:~/example$ g++ -fplugin=./example_plugin.so example_test.c
example_test.c:3:1: warning: Process struct S
};
^
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_TYPE | example
example_test.c: In function ‘int main()’:
example_test.c:7:9: internal compiler error: Segmentation fault
struct S s;
^
0x98cc2f crash_signal
../../../gcc4.9/gcc/toplev.c:337
0x7f520d010780 handle_struct(void*, void*)
/home/kje/example/example.c:20
0x8fb0b9 invoke_plugin_callbacks_full(int, void*)
../../../gcc4.9/gcc/plugin.c:542
0x5e82b5 invoke_plugin_callbacks
../../../gcc4.9/gcc/plugin.h:59
0x5e82b5 cp_parser_type_specifier
../../../gcc4.9/gcc/cp/parser.c:14338
0x5fdbb0 cp_parser_decl_specifier_seq
../../../gcc4.9/gcc/cp/parser.c:11573
0x602e79 cp_parser_simple_declaration
../../../gcc4.9/gcc/cp/parser.c:11163
0x5ea903 cp_parser_block_declaration
../../../gcc4.9/gcc/cp/parser.c:2
0x5eb961 cp_parser_declaration_statement
../../../gcc4.9/gcc/cp/parser.c:10759
0x5ebf9b cp_parser_statement
../../../gcc4.9/gcc/cp/parser.c:9492
0x5ecdc9 cp_parser_statement_seq_opt
../../../gcc4.9/gcc/cp/parser.c:9770
0x5ecf06 cp_parser_compound_statement
../../../gcc4.9/gcc/cp/parser.c:9724
0x5fb7d3 cp_parser_function_body
../../../gcc4.9/gcc/cp/parser.c:18751
0x5fb7d3 cp_parser_ctor_initializer_opt_and_function_body
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-24 Ever confirmed|0 |1
[Bug c/59708] clang-compatible checked arithmetic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||noloader at gmail dot com --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 49467 has been marked as a duplicate of this bug. ***
[Bug c/49467] Enhancement: Intrinsic to read CARRY and OVERFLOW flags (where applicable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49467 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** This bug has been marked as a duplicate of bug 59708 ***
[Bug target/62253] New: gcc incorrectly mixes direct atomic instructions with calls to atomic library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62253 Bug ID: 62253 Summary: gcc incorrectly mixes direct atomic instructions with calls to atomic library Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mikulas at artax dot karlin.mff.cuni.cz Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu Created attachment 33390 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33390action=edit a test case for broken atomicity on 386. Compile with -O3 -m32 -march=i386 The 386 processor lacks some atomic instructions, thus they must be emulated using calls to a library. The library is supposed to take a lock (possibly hashed by the address or the atomic variable), perform the operation non-atomically, and drop the lock. However, for some atomic operations, gcc still generates atomic instructions, even on 386 (lock add, lock sub, lock or, lock and, lock xor, lock inc, lock dec, xchg). The problem is that when these instructions race with the library implementation, they break atomicity. For example, to emulate cmpxchg, the library takes the lock, reads the value, compares the value, writes the new value, drops the lock. If this sequence races with directly generated lock add instruction, atomicity is broken, because the lock add instruction can be executed between the read and write in the cmpxchg library implementation. To maintain atomicity, gcc must for each data type either always use atomic instructions or always use calls to the library. It must not mix atomic instructions and library calls. To see the bug, compile the attached file with -O3 -m32 -march=i386 . You see that functions test1, test3, test5 generate direct atomic instructions and functions test2 and test4 generate calls to the library. When these functions race with each other, atomicity is not guaranteed.
[Bug plugins/62252] a callback to event PLUGIN_FINISH_TYPE segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62252 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-24 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- It seems it is your plugin crashing. Have you tried debugging why it crashes? 0x7f520d010780 handle_struct(void*, void*) /home/kje/example/example.c:20 0x8fb0b9 invoke_plugin_callbacks_full(int, void*)
[Bug target/62253] gcc incorrectly mixes direct atomic instructions with calls to atomic library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62253 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Iirc lib atomic on x86 uses the atomic instructions for 32bit and not the pthread implemention. Also if you have xchng, you can do all functions using that one without using the pthread implemention.
[Bug plugins/62252] a callback to event PLUGIN_FINISH_TYPE segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62252 --- Comment #2 from klemen.jan.enova at gmail dot com --- TREE_CODE(type) returns an ERROR_MARK. So, (tree) event_data must not alias with a tree. This plugin is from https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/g%2B%2B.dg/plugin/dumb_plugin.c. There are no checks there, it just assumes it is a type represented as a tree.
[Bug fortran/60774] f951: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60774
--- Comment #5 from Bud Davis bdavis at gcc dot gnu.org ---
Index: gcc/gcc/fortran/parse.c
===
--- gcc/gcc/fortran/parse.c(revision 214408)
+++ gcc/gcc/fortran/parse.c(working copy)
@@ -868,8 +868,6 @@
{
gfc_warning_now (Ignoring statement label in empty statement
at %L, label_locus);
- gfc_free_st_label (gfc_statement_label);
- gfc_statement_label = NULL;
return ST_NONE;
}
}
Looks very promising.
[Bug plugins/62252] a callback to event PLUGIN_FINISH_TYPE segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62252
--- Comment #3 from klemen.jan.enova at gmail dot com ---
It works on gcc, though.
in gcc/c/c-parser.c:
if (!typespec_ok)
goto out;
invoke_plugin_callbacks (PLUGIN_FINISH_TYPE, t.spec);
declspecs_add_type (loc, specs, t);
in gcc/cp/parser.c:
type_spec = cp_parser_class_specifier (parser);
invoke_plugin_callbacks (PLUGIN_FINISH_TYPE, type_spec);
/* If that worked, we're done. */
if (cp_parser_parse_definitely (parser))
{
if (declares_class_or_enum)
*declares_class_or_enum = 2;
if (decl_specs)
cp_parser_set_decl_spec_type (decl_specs,
type_spec,
token,
/*type_definition_p=*/true);
return type_spec;
}
I see a pattern. The call to invoke_plugin_callbacks() should probably be
before something_that_adds_the_type_to_decl_spec(). Also, there is a test in
both cases (typespec_ok VS cp_parser_parse_definitely). I will try to compile
gcc with this patch, and see what comes out.
[Bug c++/62227] Templated move not elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62227 James Dennett james.dennett at gmail dot com changed: What|Removed |Added CC||james.dennett at gmail dot com --- Comment #2 from James Dennett james.dennett at gmail dot com --- A template cannot be a move constructor I'm with you so far. and so it is not legal to elide it. I don't think that's the case (or at least, I'm not aware of any wording saying so). C++98 effectively said so, but C++03/11/14 don't, AFAICS. Elision applies to copying/moving, not just to copy/move constructors, and a template can be used for copying or moving. The standard isn't very clear on this though.
[Bug c++/62227] Templated move not elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62227 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- C++11 says When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor... which only applies to copy constructors or move constructors. But the current draft says even if the constructor selected for the copy/move operation So it does seem that elision is now allowed when the relevant constructor is a template.
[Bug c++/62227] Templated move not elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62227 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#535 changed that wording
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111 --- Comment #16 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Mon Aug 25 00:37:51 2014 New Revision: 214413 URL: https://gcc.gnu.org/viewcvs?rev=214413root=gccview=rev Log: PR target/62111 * config/sh/predicates.md (general_extend_operand): Disable TRUNCATE before reload completes. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/predicates.md
[Bug plugins/59335] Plugin doesn't build on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 Terry Guo terry.guo at arm dot com changed: What|Removed |Added CC||terry.guo at arm dot com --- Comment #27 from Terry Guo terry.guo at arm dot com --- It seems we have one more file missed when build plugin with latest trunk: install-native/lib/gcc/arm-none-eabi/5.0.0/plugin/include/tree-core.h:24:22: fatal error: hash-set.h: No such file or directory.
[Bug plugins/59335] Plugin doesn't build on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 Joey Ye joey.ye at arm dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #28 from Joey Ye joey.ye at arm dot com --- Reopened as a new missing header is reported
