[Bug testsuite/59442] movapd tests fail if built with -fstack-protector-strong/all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59442 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Thu Dec 12 08:00:22 2013 New Revision: 205921 URL: http://gcc.gnu.org/viewcvs?rev=205921root=gccview=rev Log: Backport from mainline 2013-12-12 Ryan Mansfield rmansfi...@qnx.com PR testsuite/59442 * gcc.target/i386/sse2-movapd-1.c: Fix alignment attributes. * gcc.target/i386/sse2-movapd-2.c: Likewise. * gcc.target/i386/avx-vmovapd-256-1.c: Likewise. * gcc.target/i386/avx-vmovapd-256-2.c: Likewise. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx-vmovapd-256-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/avx-vmovapd-256-2.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/sse2-movapd-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/sse2-movapd-2.c
[Bug testsuite/59442] movapd tests fail if built with -fstack-protector-strong/all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59442 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-12/msg00977.htm ||l Resolution|--- |FIXED Target Milestone|--- |4.7.4 --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- Fixed.
[Bug target/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #10 from Roland Stigge stigge at antcom dot de --- Please apply this patch only to 4.8.0 for now. The trunk needs some additional care, I'm working on this separately and will open a separate bug when it's ready. Would be nice if you could have a look at powerpc-linux-gnuspe anyway, though. ;-)
[Bug preprocessor/8270] [4.7/4.8/4.9 Regression] back-slash white space newline with comments, no warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270 --- Comment #49 from GoWhoopee at yahoo dot com --- I've read all the comments and all those on linked forums and I have no idea how you struggle with this! If a compiler changes backslash space into backslash newline and consequently deletes the newline it is changing the meaning of the code! All other development environments people here have used don't do this and gcc shouldn't! Here's an example of code your compiler changes: #define HIGH_SPEED_TURRET // \ #define SAFETY_LOCKED_ON// - Critical Configuration #define NEVER_PRIME_MISSILE // / The programmer put backslash space and the syntax highlighter correctly showed the safety was locked on. Sleep well.
[Bug c++/59480] New: Missing error diagnostic: friend declaration specifying a default argument must be a definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480
Bug ID: 59480
Summary: Missing error diagnostic: friend declaration
specifying a default argument must be a definition
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
The following code compiles with GCC with g++ -Wall -Werror -std=c++11
-pedantic:
class test {
friend int bar(int = true);
};
However, with Clang++ it is rejected with:
error: friend declaration specifying a default argument must be a definition
In N3337, one finds at the end of the paragraph 8.3.6.4 [dcl.fct.default]: If
a friend declaration specifies a default argument expression, that declaration
shall be a definition and shall be the only declaration of the function or
function template in the translation unit.
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- See also http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#136
[Bug libgomp/59467] copyprivate in the fortran testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59467 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Dec 12 08:52:06 2013 New Revision: 205922 URL: http://gcc.gnu.org/viewcvs?rev=205922root=gccview=rev Log: PR libgomp/59467 * gimplify.c (omp_check_private): Add copyprivate argument, if it is true, don't check omp_privatize_by_reference. (gimplify_scan_omp_clauses): For OMP_CLAUSE_COPYPRIVATE verify decl is private in outer context. Adjust omp_check_private caller. * gfortran.dg/gomp/pr59467.f90: New test. * c-c++-common/gomp/pr59467.c: New test. * testsuite/libgomp.fortran/crayptr2.f90: Add private (d) clause to !$omp parallel. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr59467.c trunk/gcc/testsuite/gfortran.dg/gomp/pr59467.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.fortran/crayptr2.f90
[Bug libgomp/59467] copyprivate in the fortran testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59467 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Dec 12 08:57:22 2013 New Revision: 205923 URL: http://gcc.gnu.org/viewcvs?rev=205923root=gccview=rev Log: PR libgomp/59467 * gimplify.c (omp_check_private): Add copyprivate argument, if it is true, don't check omp_privatize_by_reference. (gimplify_scan_omp_clauses): For OMP_CLAUSE_COPYPRIVATE verify decl is private in outer context. Adjust omp_check_private caller. * gfortran.dg/gomp/pr59467.f90: New test. * c-c++-common/gomp/pr59467.c: New test. * testsuite/libgomp.fortran/crayptr2.f90: Add private (d) clause to !$omp parallel. Added: branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/gomp/pr59467.c branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/gomp/pr59467.f90 Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/gimplify.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/libgomp/ChangeLog branches/gcc-4_8-branch/libgomp/testsuite/libgomp.fortran/crayptr2.f90
[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31425 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31425action=edit gcc49-pr59470.patch Untested TER changes I've meant. I believe that for gimple_assign_single_p (stmt) the current code pretty much matches the pre-r205709 code (assuming refs_may_alias_p_1 argument order doesn't matter), perhaps with some inspection of assignment expansion code it could be improved to only the gimple_assign_rhs1 (stmt) == use case (if the lhs and rhs of assignment expressions are evaluated always before the actual assignment, the problematic case would be if for assignments that require multiple stores we'd evaluate the expressions after any of the stores), but that is not a regression from that patch. For calls and inline asm it is IMHO desirable to avoid TER only when we really need, both to potentially generate better code or code that LRA doesn't have to fix up that much, and for 4.8 branch also to decrease the amount of code generation changes to decrease risks.
[Bug libgomp/59467] copyprivate in the fortran testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59467 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed for 4.8+, thanks for the report.
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 --- Comment #31 from Igor Zamyatin izamyatin at gmail dot com --- The problem is that there is a performance regression on i686 for Coremark test
[Bug c++/59475] gcc with flag -O1 fails to find template specialization when there is default one.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59475
--- Comment #5 from Akela1101 akela1101 at gmail dot com ---
I see...
So, at -O1 in main.o the function is inline, and in A.o it has outer
implementation. At -O0 in both TU, not inline function is using.
The thing was not template specialization, but processing inline functions.
Sorry, I didn't know linker even had no warnings like multiple definition for
inline functions, e.g.:
TU 1:
int foo() { return 1; }
TU 2:
inline int foo() { return 2; }
[Bug c++/59481] New: late-specified return type using a parameter pack doesn't work with a recursive function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59481
Bug ID: 59481
Summary: late-specified return type using a parameter pack
doesn't work with a recursive function template
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test snippet:
templatetypename T
int func (T) { return 0; }
templatetypename T, typename... Ts
auto func (T t, Ts... ts) - decltype (func (ts...))
// - decltype (func ((Ts)ts...))
// ^ workaround
{
return funcTs... (ts...);
}
int
main (int argc, char *argv[])
{
func (1, 2);
}
This gives
edoceo4.cpp: In substitution of ‘templateclass T, class ... Ts decltype
(func(func::ts ...)) func(T, Ts ...) [with T = int; Ts = {}]’:
edoceo4.cpp:9:28: required from ‘decltype (func(func::ts ...)) func(T, Ts
...) [with T = int; Ts = {int}; decltype (func(func::ts ...)) = int]’
edoceo4.cpp:15:13: required from here
edoceo4.cpp:5:51: error: expansion pattern ‘#‘nontype_argument_pack’ not
supported by dump_expr#expression error’ contains no argument packs
auto func (T t, Ts... ts) - decltype (func (ts...))
^
The dump_expr diagnostic is certainly suspicious. Clang 3.4 accepts the
code. Another user reports that 4.6 with --c++0x accepts the code too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37729 may be related, but
the case is not identical, and that one has been fixed.
In a similar but not identical fashion,
templatetypename T
int func (T) { return 0; }
templatetypename T, typename... Ts
auto func (T t, Ts... ts) - decltype (func (ts...));
templatetypename T, typename... Ts
auto func (T t, Ts... ts) - decltype (func (ts...))
{
return func (ts...);
}
int
main (int argc, char *argv[])
{
func (1,2,3);
}
doesn't compile, it produces
edoceo6.cpp: In function ‘int main(int, char**)’:
edoceo6.cpp:16:14: error: no matching function for call to ‘func(int, int,
int)’
func (1,2,3);
^
edoceo6.cpp:16:14: note: candidates are:
edoceo6.cpp:2:5: note: templateclass T int func(T)
int func (T) { return 0; }
^
edoceo6.cpp:2:5: note: template argument deduction/substitution failed:
edoceo6.cpp:16:14: note: candidate expects 1 argument, 3 provided
func (1,2,3);
^
edoceo6.cpp:8:6: note: templateclass T, class ... Ts decltype (func(func::ts
...)) func(T, Ts ...)
auto func (T t, Ts... ts) - decltype (func (ts...))
^
edoceo6.cpp:8:6: note: template argument deduction/substitution failed:
edoceo6.cpp: In substitution of ‘templateclass T, class ... Ts decltype
(func(func::ts ...)) func(T, Ts ...) [with T = int; Ts = {int, int}]’:
edoceo6.cpp:16:14: required from here
edoceo6.cpp:5:51: error: no matching function for call to ‘func(int, int)’
auto func (T t, Ts... ts) - decltype (func (ts...));
^
edoceo6.cpp:5:51: note: candidate is:
edoceo6.cpp:2:5: note: templateclass T int func(T)
int func (T) { return 0; }
^
edoceo6.cpp:2:5: note: template argument deduction/substitution failed:
edoceo6.cpp:5:51: note: candidate expects 1 argument, 2 provided
auto func (T t, Ts... ts) - decltype (func (ts...));
^
Clang 3.4 again accepts the code.
[Bug c++/59482] New: A friend class cannot inherit a private class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59482
Bug ID: 59482
Summary: A friend class cannot inherit a private class
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test:
struct aa {
friend struct cc;
private:
struct bb {};
};
struct cc : aa::bb {};
Output:
ville.cpp:1:47: error: ‘struct aa::bb’ is private
struct aa { friend struct cc; private: struct bb {}; }; struct cc : aa::bb {};
^
ville.cpp:1:73: error: within this context
struct aa { friend struct cc; private: struct bb {}; }; struct cc : aa::bb {};
^
Clang 3.4 accepts the code.
[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31426 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31426action=edit gcc48-pr59470-test.patch Runtime testcase that shows the LRA problem.
[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- The #c11 fix has been successfully bootstrapped/regtested on x86_64-linux and i686-linux on trunk (--enable-checking=yes,rtl) and on 4.8 branch (also both targets, though regtest is still pending there).
[Bug c++/59483] New: A nested lambda fails to find a protected name with qualified name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59483
Bug ID: 59483
Summary: A nested lambda fails to find a protected name with
qualified name
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test:
struct X {
protected:
int i;
};
struct Y: X {
void f() {
[]{ X::i = 3; }(); } // #1
};
Output:
eelis.cpp: In lambda function:
eelis.cpp:3:7: error: ‘int X::i’ is protected
int i;
^
eelis.cpp:8:13: error: within this context
[]{ X::i = 3; }(); }
^
Removing X:: from #1 makes it work. Clang 3.4 accepts the code either
with X:: or without it.
[Bug c++/58627] [4.9 Regression] crash during compilation of boost testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Dec 12 13:35:21 2013 New Revision: 205927 URL: http://gcc.gnu.org/viewcvs?rev=205927root=gccview=rev Log: PR c++/58627 * call.c (add_template_candidate_real): Don't call ggc_free on targs. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c
[Bug c++/58627] [4.9 Regression] crash during compilation of boost testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug libstdc++/59436] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436 Bug 59436 depends on bug 58627, which changed state. Bug 58627 Summary: [4.9 Regression] crash during compilation of boost testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr --- I fixed the reported problem and posted new patch at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01159.html Apology that I missed java in bootstrap for previous patch. This version passes bootstrap and test for c,c++,lto,fortran,java,go,objc,obj_c++ on x86_64. Well, it has been a long time without libjava breaking bootstrap! I am not sure if the java case is covered by bootstrap, or other applications. If it's in other application, could anyone help verifying that the issue is addressed on apple-darwin? I have bootstrapped end regtested revision 205924 with the patch on x86_64-apple-darwin13 without any problem.
[Bug fortran/59484] New: execute_command_line doesn't play with environment variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59484 Bug ID: 59484 Summary: execute_command_line doesn't play with environment variables Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: demarchie at web dot de Please compile: program test implicit none character(len=11) :: cmdmsg,str integer :: exitstat,cmdstat,status,length logical :: wait wait = .true. cmdmsg = ok call execute_command_line(export newvar='some text') print *,result 1:, exitstat, cmdstat, cmdmsg call get_environment_variable(newvar,str,length,status) print *,1: ,str,length,status print *,expected:,some text,9,0; print *, call execute_command_line(read -n5 myvar, wait, exitstat, cmdstat, cmdmsg) print *,result 2:, exitstat, cmdstat, cmdmsg call get_environment_variable(myvar,str,length,status) print *,2:,str,length,status call execute_command_line(myvar='text', wait, exitstat, cmdstat, cmdmsg) print *,; print *,result 3:, exitstat, cmdstat, cmdmsg call get_environment_variable(myvar,str,length,status) print *,3:,str,length,status print *,expected:,text,4,0 end program test Now try in bash: export myvar=not good ./a.out (type great) Output is (gfortran-4.8.2): execute 1: -1073743632 -1073742765 ok get 1: 0 1 expected:some text 9 0 great execute 2: 0 0 ok get 2:not good8 0 expected:great5 0 execute 3: 0 0 ok get 3:not good8 0 expected:text 4 0 * /sw/bin/gfortran -v -save-temps test.f90 Angesteuert: /sw/bin/gfortran -mmacosx-version-min=10.4 -v -save-temps test.f90 -l gfortran -shared-libgcc Es werden eingebaute Spezifikationen verwendet. COLLECT_GCC=/sw/bin/gfortran COLLECT_LTO_WRAPPER=/sw/lib/gcc4.8/libexec/gcc/powerpc-apple-darwin8.11.0/4.8.2/lto-wrapper Ziel: powerpc-apple-darwin8.11.0 Konfiguriert mit: ../gcc-4.8.2/configure --prefix=/sw AS=odas AS_FOR_TARGET=odas NM_FOR_TARGET=odnm LD_FOR_TARGET=odld AR_FOR_TARGET=odar LIPO_FOR_TARGET=odlipo OBJDUMP_FOR_TARGET=odobjdump RANLIB_FOR_TARGET=odranlib STRIP_FOR_TARGET=odstrip --prefix=/sw/lib/gcc4.8 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=release --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8 --with-dwarf2 --disable-libjava-multilib --disable-libquadmath Thread-Modell: posix gcc-Version 4.8.2 (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-v' '-save-temps' '-shared-libgcc' /sw/lib/gcc4.8/libexec/gcc/powerpc-apple-darwin8.11.0/4.8.2/f951 test.f90 -fPIC -quiet -dumpbase test.f90 -mmacosx-version-min=10.4 -auxbase test -version -fintrinsic-modules-path /sw/lib/gcc4.8/lib/gcc/powerpc-apple-darwin8.11.0/4.8.2/finclude -o test.s GNU Fortran (GCC) Version 4.8.2 (powerpc-apple-darwin8.11.0) kompiliert von GNU-C-Version 4.8.2, GMP-Version 5.1.3, MPFR-Version 3.1.2, MPC-Version 1.0.1. GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) Version 4.8.2 (powerpc-apple-darwin8.11.0) kompiliert von GNU-C-Version 4.8.2, GMP-Version 5.1.3, MPFR-Version 3.1.2, MPC-Version 1.0.1. GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-v' '-save-temps' '-shared-libgcc' as -arch ppc -o test.o test.s Lesen der Spezifikationen von /sw/lib/gcc4.8/lib/gcc/powerpc-apple-darwin8.11.0/4.8.2/../../../libgfortran.spec Spezifikation wird von lib nach liborig umbenannt COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-v' '-save-temps' '-shared-libgcc' COMPILER_PATH=/sw/lib/gcc4.8/libexec/gcc/powerpc-apple-darwin8.11.0/4.8.2/:/sw/lib/gcc4.8/libexec/gcc/powerpc-apple-darwin8.11.0/4.8.2/:/sw/lib/gcc4.8/libexec/gcc/powerpc-apple-darwin8.11.0/:/sw/lib/gcc4.8/lib/gcc/powerpc-apple-darwin8.11.0/4.8.2/:/sw/lib/gcc4.8/lib/gcc/powerpc-apple-darwin8.11.0/ LIBRARY_PATH=/sw/lib/gcc4.8/lib/gcc/powerpc-apple-darwin8.11.0/4.8.2/:/sw/lib/gcc4.8/lib/gcc/powerpc-apple-darwin8.11.0/4.8.2/../../../:/usr/lib/ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-v' '-save-temps' '-shared-libgcc' /sw/lib/gcc4.8/libexec/gcc/powerpc-apple-darwin8.11.0/4.8.2/collect2 -dynamic -arch ppc -macosx_version_min 10.4 -multiply_defined suppress -weak_reference_mismatches non-weak -o a.out -lcrt1.o /sw/lib/gcc4.8/lib/gcc/powerpc-apple-darwin8.11.0/4.8.2/crt3.o -L/sw/lib/gcc4.8/lib/gcc/powerpc-apple-darwin8.11.0/4.8.2 -L/sw/lib/gcc4.8/lib/gcc/powerpc-apple-darwin8.11.0/4.8.2/../../.. test.o -lgfortran
[Bug fortran/59484] execute_command_line doesn't play with environment variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59484 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Reinhold Straub from comment #0) Please compile: program test implicit none character(len=11) :: cmdmsg,str integer :: exitstat,cmdstat,status,length logical :: wait wait = .true. cmdmsg = ok call execute_command_line(export newvar='some text') print *,result 1:, exitstat, cmdstat, cmdmsg call get_environment_variable(newvar,str,length,status) print *,1: ,str,length,status print *,expected:,some text,9,0; print *, Looks like an invalid program to me. exitstat, cmdstat, and cmdmsg are undefined in the 1st print statement. execute_command_line(command) executes the 'command' in a child process. You've managed to export newvar in the child's environment. By the time you use get_environment_variable, the child process has completed and more importantly it has not changed its parent environment. If you want to change the parent's environment, you'll most likely need to use ISO C interop and the setenv function from the C lib.
[Bug c/59485] New: may_alias attribute ignored in internal references while defining aggregate types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59485
Bug ID: 59485
Summary: may_alias attribute ignored in internal references
while defining aggregate types
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: soltys at ziu dot info
Note, I first asked about it on gcc-help, though got no responsens. This does
look like a bug - though obviously I'm not sure if it really should be
considered as such.
Anyway, consider following piece of code:
struct __attribute__((may_alias)) tag_si {
int y;
};
struct __attribute__((may_alias)) tag_s {
int x;
struct tag_si *pi;
struct tag_s *p;
};
int main(void)
{
struct tag_s test = {0};
struct tag_si **ppi;
struct tag_s **pp;
ppi = test.pi; /* ok */
pp = test.p;/* will generate warning */
return 0;
}
The possible problem with the above example, is that pp assignment will cause
compiler to emit:
test.c: In function 'main':
test.c:18:12: warning: assignment from incompatible pointer type [enabled by
default]
pp = test.p;
^
At the same time analogous ppi assignment gives no issues. The only difference
between tag_si and tag_s is that the former is defined first outside and
then referenced in subsequent definition - while the latter is referenced
during its definition - and then it forgets about may_alias attribute (thus
pp = test.p gives warrning).
I tried to workaround it with preceeding struct forward declaration, e.g.
struct __attribute__((may_alias)) tag_s;
struct __attribute__((may_alias)) tag_s { ..
But this approach has no effect either.
The only workaround for that I found is extra typedef with may_alias and type
cast, e.g.:
typedef struct tag_s *tag_t_pa __attribute__((may_alias));
tag_t_pa *pp;
pp = (tag_t_pa *)test.p;
[Bug preprocessor/8270] [4.7/4.8/4.9 Regression] back-slash white space newline with comments, no warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #50 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to Andrew Pinski from comment #48) (In reply to GoWhoopee from comment #47) Please reconsider and stop gcc from changing our code without our permission. It is not changing your code at all. Read comment #39 to understand this issue at full understanding of the standard. I'm looking at N1570 section 5.1.1.2 Translation phases. Phase 1 only maps multibyte characters and trigraphs, Backslash-space-newline is neither so should be preserved as-is to phase 2. The splicing in phase 2 then shouldn't occur because of the space. Or am I missing something?
[Bug c/52991] attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 roger pack rogerdpack at gmail dot com changed: What|Removed |Added CC||rogerdpack at gmail dot com --- Comment #15 from roger pack rogerdpack at gmail dot com --- So is the problem here that -mms-bitfields became the default, which caused difficulties, or that -mms-bitfields is broken? (if the latter, does using gcc_struct everywhere cause the right behavior?) Sorry I'm a bit clueless here. Thanks!
[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 --- Comment #18 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #13) Strange. From my limited testing, it does fix the regressions. I can fire off now full scratch rpm builds with your patch. Sorry. My bad. I did not rebuild the library (I rebuilt only compiler) when I tested it. In general, the probability of this bug is quite tiny so many conditions must come up for this. That is why we found it only recently. Thanks for working on it, Jakub. Your analysis helped me a lot. You can commit it into gcc-4.8 and gcc-4.9.
[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Vladimir Makarov from comment #18) (In reply to Jakub Jelinek from comment #13) Strange. From my limited testing, it does fix the regressions. I can fire off now full scratch rpm builds with your patch. Sorry. My bad. I did not rebuild the library (I rebuilt only compiler) when I tested it. In general, the probability of this bug is quite tiny so many conditions must come up for this. That is why we found it only recently. Thanks for working on it, Jakub. Your analysis helped me a lot. You can commit it into gcc-4.8 and gcc-4.9. Regtest finished on i686-linux/4.8 and looks fine, x86_64-linux/4.8 is still pending.
[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 --- Comment #20 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Thu Dec 12 15:48:23 2013 New Revision: 205929 URL: http://gcc.gnu.org/viewcvs?rev=205929root=gccview=rev Log: 2013-12-12 Vladimir Makarov vmaka...@redhat.com PR middle-end/59470 * lra-coalesce.c (lra_coalesce): Invalidate inheritance pseudo values if necessary. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/lra-coalesce.c
[Bug c/52991] attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 --- Comment #16 from Kai Tietz ktietz at gcc dot gnu.org --- ms-bitfield is broken regarding pack-attribute and align-attribute. Later is the cause why suggested patch is just half of the story.
[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 --- Comment #21 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Thu Dec 12 15:51:49 2013 New Revision: 205930 URL: http://gcc.gnu.org/viewcvs?rev=205930root=gccview=rev Log: 2013-12-12 Vladimir Makarov vmaka...@redhat.com PR middle-end/59470 * lra-coalesce.c (lra_coalesce): Invalidate inheritance pseudo values if necessary. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-coalesce.c
[Bug c++/59255] [4.8/4.9 Regression] Segmentation fault with std::function and -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255
--- Comment #3 from mark at jarv dot in ---
I notice that lookup_stmt_eh_lp(icall_stmt) at value-prof.c:1272 returns -1.
Elsewhere in the code (tree-eh.c:2208), I see lp_nr = 0 as a guard against
further EH processing.
At gimple-pretty-print.c:1881, I see that a negative lp_nr is pretty-printed as
([MNT %d], -lp_nr). Further searching around suggests that MNT might mean
must not throw.
Notably, we're in a destructor in C++11 here, and I guess C++11 destructors are
more often noexcept than in C++98. From
http://stackoverflow.com/q/15721544/228142:
'12.4/3: A declaration of a destructor that does not have an
exception-specification is implicitly considered to have the same
exception-specification as an implicit declaration (15.4). i.e. a destructor
is only noexcept(true) if all the members and bases have a noexcept
destructor.'
Could the correct fix be as simple as:
--- value-prof.c.orig2013-12-12 10:09:23.148929000 -0500
+++ value-prof.c2013-12-12 10:57:33.32998 -0500
@@ -1270,7 +1270,7 @@ gimple_ic (gimple icall_stmt, struct cgr
/* Build an EH edge for the direct call if necessary. */
lp_nr = lookup_stmt_eh_lp (icall_stmt);
- if (lp_nr != 0
+ if (lp_nr 0
stmt_could_throw_p (dcall_stmt))
{
edge e_eh, e;
This certainly removes the ICE, but I don't know that I can vouch for its
safety from the perspective of preserving correctness.
[Bug c++/59255] [4.8/4.9 Regression] Segmentation fault with std::function and -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255 --- Comment #4 from Mark Jarvin mark at jarv dot in --- I think the other relevant text from the C++11 standard is available here: http://stackoverflow.com/q/13041715/228142 An implicitly declared special member function (Clause 12) shall have an exception-specification. If f is an implicitly declared default constructor, copy constructor, move constructor, destructor, copy assignment operator, or move assignment operator, its implicit exception-specification specifies the type-id T if and only if T is allowed by the exception-specification of a function directly invoked by f’s implicit definition; f shall allow all exceptions if any function it directly invokes allows all exceptions, and f shall allow no exceptions if every function it directly invokes allows no exceptions. I guess I'm trying to build the case that it makes sense that icall_bb has no EH successor because it's a must-not-throw block, and it's a must-not-throw block in this specific case because it's a destructor with -std=c++11 and its members are (I'm guessing) all must-not-throw. The bug amounts to the code not correctly handling must-not-throw statements. If you buy that argument, I think there might be other places in GCC that aren't handling it either. For example, cfgexpand.c:2313 simply checks that lp_nr != 0. Likewise cgraph.c:1084, tree-cfg.c:4709, tree-eh.c:3029, maybe others.
[Bug c++/59255] [4.8/4.9 Regression] Segmentation fault with std::function and -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255 --- Comment #5 from Mark Jarvin mark at jarv dot in --- Hmm... seems like it's already fixed in the trunk: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=201859 It doesn't seem to have been ported to 4.8. http://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_8-branch/gcc/value-prof.c?view=log
[Bug c/59486] New: math functions take more cycles after running any Intel AVX function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59486 Bug ID: 59486 Summary: math functions take more cycles after running any Intel AVX function Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kayan4096 at gmail dot com Created attachment 31427 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31427action=edit the .i file when using any AVX256 instruction, the AVX upper state becomes dirty, which results in a performance hit to all legacy library calls. This is documented in the Intel Optimization Manual. gcc should clean the YMM register after using AVX. for the attached foo.i the result we get are: round res 3197 total cycles 224725952 CPI 22 round res 3197 total cycles 1900864520 CPI 190 while the expected results are: round res 3197 total cycles 224725952 CPI 22 round res 3197 total cycles 224725952 CPI 22 This is also described here: http://stackoverflow.com/questions/20545539/math-functions-takes-more-cycles-after-running-any-intel-avx-function gcc -v -save-temps -Wall -mavx -lm foo.c output: Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-mavx' '-mtune=generic' /usr/libexec/gcc/x86_64-redhat-linux/4.4.6/cc1 -E -quiet -v foo.c -mavx -mtune=generic -Wall -fpch-preprocess -o foo.i ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.4.6/include-fixed ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../x86_64-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/x86_64-redhat-linux/4.4.6/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-mavx' '-mtune=generic' /usr/libexec/gcc/x86_64-redhat-linux/4.4.6/cc1 -fpreprocessed foo.i -quiet -dumpbase foo.c -mavx -mtune=generic -auxbase foo -Wall -version -o foo.s GNU C (GCC) version 4.4.6 20110731 (Red Hat 4.4.6-3) (x86_64-redhat-linux) compiled by GNU C version 4.4.6 20110731 (Red Hat 4.4.6-3), GMP version 4.3.1, MPFR version 2.4.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 11bca756726d0c8e79657fd5bb53575a COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-mavx' '-mtune=generic' as -V -Qy -msse2avx -o foo.o foo.s GNU assembler version 2.20.51.0.2 (x86_64-redhat-linux) using BFD version version 2.20.51.0.2-5.28.el6 20091009 COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.4.6/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.6/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/:/usr/lib/gcc/x86_64-redhat-linux/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.6/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/:/usr/lib/gcc/x86_64-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.4.6/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-mavx' '-mtune=generic' /usr/libexec/gcc/x86_64-redhat-linux/4.4.6/collect2 --eh-frame-hdr --build-id -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.4.6/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.4.6 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.6 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../.. -lm foo.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.4.6/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crtn.o
[Bug target/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #11 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Thu, Dec 12, 2013 at 08:11:23AM +, stigge at antcom dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #10 from Roland Stigge stigge at antcom dot de --- Please apply this patch only to 4.8.0 for now. The trunk needs some additional care, I'm working on this separately and will open a separate bug when it's ready. Would be nice if you could have a look at powerpc-linux-gnuspe anyway, though. ;-) Is there any way I can test powerpc-linux-gnuspe on a power7 running Linux? Right now, I can only do visual code inspection of the .s file.
[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904 Laurent Rineau Laurent.Rineau__gcc at normalesup dot org changed: What|Removed |Added CC||Laurent.Rineau__gcc@normale ||sup.org --- Comment #5 from Laurent Rineau Laurent.Rineau__gcc at normalesup dot org --- With the following gcc version: gcc (GCC) 4.8.2 20131017 (Red Hat 4.8.2-1) I have a similar result: $ gcc -c -Wstrict-overflow -O2 v.i v.i: In function ‘wait_reading_process_output’: v.i:14:6: warning: assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow] if (nfds 0) ^ That diagnostic seems right, according to the documentation of -Wstrict-overflow.
[Bug fortran/59484] execute_command_line doesn't play with environment variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59484
--- Comment #2 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
On Thu, Dec 12, 2013 at 02:27:19PM +, kargl at gcc dot gnu.org wrote:
--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Reinhold Straub from comment #0)
Please compile:
program test
implicit none
character(len=11) :: cmdmsg,str
integer :: exitstat,cmdstat,status,length
logical :: wait
wait = .true.
cmdmsg = ok
call execute_command_line(export newvar='some text')
print *,result 1:, exitstat, cmdstat, cmdmsg
call get_environment_variable(newvar,str,length,status)
print *,1: ,str,length,status
print *,expected:,some text,9,0; print *,
Looks like an invalid program to me. exitstat, cmdstat, and cmdmsg
are undefined in the 1st print statement.
Actually, cmdmsg is defined. exitstat and cmdstat are not defined.
execute_command_line(command) executes the 'command' in a child
process. You've managed to export newvar in the child's environment.
By the time you use get_environment_variable, the child process has
completed and more importantly it has not changed its parent
environment.
If you want to change the parent's environment, you'll most likely
need to use ISO C interop and the setenv function from the C lib.
If you want to change the environment of the parent you can do
program foo
use iso_c_binding
implicit none
integer status
character(len=20) var
interface
function putenv(str) bind(c,name=putenv)
use iso_c_binding
integer(c_int) putenv
character(len=1,kind=c_char) str
end function putenv
end interface
status = putenv('OHMY=Farmer tan' // C_NULL_CHAR)
print '(A,I0)', 'status = ', status
call get_environment_variable('OHMY', var)
print '(A)', trim(var)
end program foo
gfortran -o z foo.f90
./z
status = 0
Farmer tan
[Bug c/59486] math functions take more cycles after running any Intel AVX function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59486 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Use -mvzeroupper option.
[Bug target/57807] Compile failure with __builtin_ia32_unpcklpd with -masm=intel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57807 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Uroš Bizjak ubizjak at gmail dot com --- Assuming fixed.
[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Dec 12 17:55:44 2013 New Revision: 205934 URL: http://gcc.gnu.org/viewcvs?rev=205934root=gccview=rev Log: PR middle-end/59470 * g++.dg/opt/pr59470.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr59470.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Dec 12 17:56:51 2013 New Revision: 205935 URL: http://gcc.gnu.org/viewcvs?rev=205935root=gccview=rev Log: PR middle-end/59470 * g++.dg/opt/pr59470.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/opt/pr59470.C Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #4 from algrant at acm dot org ---
So using g++,
#include atomic
int f1(std::atomicint const *p, std::atomicint const *q)
{
int flag = p-load(std::memory_order_consume);
return flag ? (q + flag - flag)-load(std::memory_order_relaxed) : 0;
}
demonstrates the same lack of ordering. You suggest that this might
be a problem with the atomic built-ins - and yes, if this had been a
load-acquire, it would be a problem with the built-in not introducing a
barrier or using a load-acquire instruction. But for a load-consume on
this architecture, no barrier is necessary to separate the load-consume
from a load that is address-dependent on it. The programmer wrote a
dependency but the compiler lost track of it.
It's not necessary to demonstrate failure - there's an architectural
race condition here. Even if it doesn't fail now there's no guarantee
it will never fail on future more aggressively reordering cores.
[Bug rtl-optimization/56339] [4.8 Regression]: Suboptimal register allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Summary|[4.8/4.9 Regression]: |[4.8 Regression]: |Suboptimal register |Suboptimal register |allocation |allocation --- Comment #17 from Uroš Bizjak ubizjak at gmail dot com --- gcc-4.9 now generates: f: addsd %xmm2, %xmm0 ret The problem is fixed in 4.9, reconfirmed on 4.8 branch.
[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904 --- Comment #6 from eggert at gnu dot org --- That diagnostic seems right, according to the documentation of -Wstrict-overflow. The diagnostic is right only in the sense that it is correctly reporting that GCC does not deduce that signed overflow cannot possibly occur in this function. It is not right in the common sense that a programmer would ordinarily want, i.e., that the program may have a bug because signed overflow might lead to undefined behavior. (Surely the diagnostic is supposed to be for the benefit of programmers trying to find potential bugs in their programs, not for the benefit of GCC maintainers trying to explain how GCC works internally. :-)
[Bug target/51743] [ia64] Many gcc.dg/torture/vshuf*.c tests FAIL with -O2 -mbig-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51743 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- Probably not a bug.
[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51681 Bug 51681 depends on bug 51743, which changed state. Bug 51743 Summary: [ia64] Many gcc.dg/torture/vshuf*.c tests FAIL with -O2 -mbig-endian http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51743 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904 --- Comment #7 from Laurent Rineau Laurent.Rineau__gcc at normalesup dot org --- In the test case, nfds cannot overflow, because of two reasons: - nfds is only incremented from 0, and -fstrict-overflow allows gcc to suppose it will not overflow, - the number of iterations of the loop cannot allow nfds to overflow, even without -fstrict-overflow. Gcc warns that the test (nfds 0) is useless, because of -fstrict-overflow. The developer has two solutions: - remove that test, - or compile with -fno-strict-overflow.
[Bug tree-optimization/59487] New: [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487 Bug ID: 59487 Summary: [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: burnus at gcc dot gnu.org, Ganesh.Gopalasubramanian at amd dot com, rguenth at gcc dot gnu.org When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826 (Core i7 at 2.8Ghz): [Book15] lin/test% /opt/gcc/gcc4.9p-202828/bin/gfortran -Ofast -fwhole-program rnflow.f90 [Book15] lin/test% time a.out /dev/null 18.244u 0.020s 0:18.26 100.0%0+0k 3+1io 0pf+0w [Book15] lin/test% /opt/gcc/gcc4.9p-202825/bin/gfortran -Ofast -fwhole-program rnflow.f90 [Book15] lin/test% time a.out /dev/null 13.022u 0.024s 0:13.04 100.0%0+0k 4+1io 0pf+0w [Book15] lin/test% gfcc -Ofast -fwhole-program rnflow.f90 [Book15] lin/test% time a.out /dev/null 18.533u 0.036s 0:18.58 99.8%0+0k 0+0io 45pf+0w [Book15] lin/test% gfcc -Ofast rnflow.f90 [Book15] lin/test% time a.out /dev/null 13.059u 0.020s 0:13.08 99.9%0+0k 0+0io 0pf+0w [Book15] lin/test% gfc -Ofast -fwhole-program rnflow.f90 [Book15] lin/test% time a.out /dev/null 12.940u 0.028s 0:12.97 99.9%0+0k 0+0io 14pf+0w gfcc is r205891 and gfc r205924 with the patch for pr58721 at http://gcc.gnu.org/ml/fortran/2013-12/msg00069.html which fixes also this slowdown (the slowdown is ~20% on a Core2Duo at 2.5Ghz). This has been noticed in the last comment of pr58464.
[Bug tree-optimization/58464] [4.9 Regression] Crashes with SIGSEGV (infinite recursion in phi_translate)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58464 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- Seems the fix is regressing rnflow of pb11. Confirmed. I have opened pr59487.
[Bug libgomp/58756] FAIL: libgomp.c/pr58392.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58756 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11, ||alpha-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-12 CC||ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Also fails on alpha [1]. Breakpoint 3, main () at pr58392.c:52 52 abort (); (gdb) p foo (32 * 32, 32) $9 = 1984 It looks that the problem is in foo, if I comment out the call to foo, testcase runs OK. [1] http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg01114.html
[Bug fortran/59488] New: l[OpenMP] named constant in parallel construct lead to not specified in enclosing parallel error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59488 Bug ID: 59488 Summary: l[OpenMP] named constant in parallel construct lead to not specified in enclosing parallel error. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org I'm not sure if this is a valid error or not. I saw the issue raised in comp.lang.fortran. https://groups.google.com/forum/#!topic/comp.lang.fortran/VKhoAm8m9KE with all versions of gfortran, one gets gfc47 -o c -fopenmp foo.f90 foo.f90: In function 'foo': foo.f90:17:0: error: 'nlcdtypes' not specified in enclosing parallel foo.f90:14:0: error: enclosing parallel for program foo implicit none integer, parameter :: ncols = 100, nrows = 200, nnlcd = 2 integer, parameter :: nlcdtypes(nnlcd) = (/ 11, 12 /) integer :: ibuf(ncols,nrows), icnt(ncols,nrows), c, r, k integer, external :: find1 icnt = 0 ibuf = 17 !$omp parallel do !$omp default( none ), !$omp shared( icnt, ibuf ), !$omp private( r, c, k ) do r = 1, nrows do c = 1, ncols k = find1(ibuf(c,r), nnlcd, nlcdtypes) end do end do end program foo This may be related to pr 36556. If I remove the default(none) clause, the code compiles.
[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904 --- Comment #8 from eggert at gnu dot org --- On 12/12/2013 10:19 AM, Laurent.Rineau__gcc at normalesup dot org wrote: The developer has two solutions: - remove that test, - or compile with -fno-strict-overflow. Sure, and because of this problem, GNU Emacs has chosen #2, that is, Emacs doesn't use -Wstrict-overflow any more. (Removing the test would unnecessarily complicate Emacs, since the test is needed on some platforms that are conditionally compiled away in this stripped-down example.) A goal of -Wstrict-overflow, at least at the 1 level, is to not generate false alarms, so that it's generally useful in real programs. This bug report gives one example where the goal is not being met. Emacs currently has a half dozen or so such examples of this (please see below for what the current Emacs bzr trunk would output, if we enabled this warning) and I thought that the GCC developers would find it useful to see one of them. If you're not interested, that's OK too; Emacs will continue to not use -Wstrict-overflow. In file included from dispnew.c:26:0: dispnew.c: In function ‘update_window’: lisp.h:749:30: warning: assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow] return num lower ? lower : num = upper ? num : upper; dispnew.c: In function ‘update_frame_1’: dispnew.c:4490:19: warning: assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow] pause_p = 0 i i FRAME_LINES (f) - 1; fileio.c: In function ‘Finsert_file_contents’: fileio.c:3630:11: warning: assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow] if (nread 0) ^ fileio.c:3632:16: warning: assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow] else if (nread 0) ^ eval.c: In function ‘backtrace_eval_unrewind’: eval.c:3496:3: warning: assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow] for (; distance 0; distance--) ^ intervals.c: In function ‘offset_intervals’: intervals.c:1364:6: warning: assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow] if (length == TOTAL_LENGTH (tree)) ^ intervals.c:1379:9: warning: assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow] while (left_to_delete 0) ^
[Bug fortran/59440] [4.9 Regression] ICE in force_decl_die, at dwarf2out.c:20111 with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59440 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Thu Dec 12 19:41:11 2013 New Revision: 205939 URL: http://gcc.gnu.org/viewcvs?rev=205939root=gccview=rev Log: 2013-12-12 Tobias Burnus bur...@net-b.de PR fortran/59440 * trans-decl.c (generate_namelist_decl): Ensure debug DIE is created by setting DECL_IGNORED_P to 0. 2013-12-12 Tobias Burnus bur...@net-b.de PR fortran/59440 * gfortran.dg/namelist_83.f90: New. * gfortran.dg/namelist_83_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/namelist_83.f90 trunk/gcc/testsuite/gfortran.dg/namelist_83_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug other/59489] New: docs mentions that -fwrapv mandatory with java, but not go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59489 Bug ID: 59489 Summary: docs mentions that -fwrapv mandatory with java, but not go Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: shawn at churchofgit dot com the man page: -fwrapv This option instructs the compiler to assume that signed arithmetic overflow of addition, subtraction and multiplication wraps around using twos-complement representation. This flag enables some optimizations and disables others. This option is enabled by default for the Java front end, as required by the Java language specification. -fwrapv is also mandated by go specification http://golang.org/ref/spec
[Bug fortran/59488] [OpenMP] named constant in parallel construct leads to not specified in enclosing parallel error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59488 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||openmp CC||burnus at gcc dot gnu.org, ||jakub at gcc dot gnu.org Summary|l[OpenMP] named constant in |[OpenMP] named constant in |parallel construct lead to |parallel construct leads to |not specified in enclosing |not specified in enclosing |parallel error.|parallel error. --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- From the original report: works fine with OpenMP Intel, Sun, Absoft, and PathScale. Remark:Internally, integer, parameter :: nlcdtypes(nnlcd) = (/ 11, 12 /) has a dual nature: It is known to the compiler (at least the FE) as compile time constant and, thus, can be compile-time folded [esp. when used as scalar]. On the other hand, it is generated as static variable (marked as TREE_READONLY). [In case of module parameters the static variable is only in the translation unit of the module]. Maybe something like the following could be the right approach? diff --git a/gcc/gimplify.c b/gcc/gimplify.c index 1ca847a..286f1e8 100644 --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -5632,4 +5632,8 @@ omp_notice_variable (struct gimplify_omp_ctx *ctx, tree decl, bool in_code) goto do_outer; + /* Array-valued Fortran named constant can reach here. */ + if (TREE_READONLY (lang_hooks.decls.omp_report_decl (decl))) +goto do_outer; + /* ??? Some compiler-generated variables (like SAVE_EXPRs) could be remapped firstprivate instead of shared. To some extent this is
[Bug fortran/59440] [4.9 Regression] ICE in force_decl_die, at dwarf2out.c:20111 with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59440 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED! Thanks for the report and quick feedback!
[Bug libgomp/58756] FAIL: libgomp.c/pr58392.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58756
--- Comment #2 from Uroš Bizjak ubizjak at gmail dot com ---
Some unscientific printf debugging yields following runtime difference:
foo (int a, int b)
{
int j, c = 0;
#pragma omp parallel for reduction(+: c)
for (j = 0; j a; j += b)
{
int l;
#pragma omp simd reduction(+: c)
for (l = 0; l b; ++l)
c += d[j + l];
printf (%i\n, c);
}
printf (tot %i\n, c);
return c;
}
alpha:
$ ./a.out
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
496
tot 1984
Aborted
Alpha spawned 3 new threads (as reported by gdb), so 4 * 496 = 1984.
x86_64:
$ ./pr58392.exe
496
992
1488
496
992
1488
496
992
496
992
1488
496
992
1488
496
992
1488
496
992
496
992
1488
496
992
496
992
1488
496
992
496
992
1488
tot 15872
[Bug libgomp/58756] FAIL: libgomp.c/pr58392.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58756 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- Adding omp_get_thrad_num to the printf: $ ./a.out 3 496 3 496 2 496 2 496 2 496 2 496 2 496 2 496 2 496 2 496 3 496 3 496 3 496 3 496 3 496 3 496 1 496 1 496 1 496 1 496 1 496 1 496 0 496 0 496 0 496 0 496 0 496 0 496 0 496 0 496 1 496 1 496 tot 1984 Aborted So, the summing variable in the outer loop is not increased.
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 --- Comment #32 from Jeffrey A. Law law at redhat dot com --- Without a testcase that is representative of the issue, there's nothing I can do.
[Bug target/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #12 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Thu, Dec 12, 2013 at 12:22:13AM +, meissner at linux dot vnet.ibm.com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #9 from Michael Meissner meissner at linux dot vnet.ibm.com --- On Wed, Dec 11, 2013 at 04:37:20PM +, dje at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #8 from David Edelsohn dje at gcc dot gnu.org --- Mike, can you apply the patch to the 4.8 branch? Thanks, David Note, the patch no longer applies to the trunk due to adding a PTImode case. I'll test both gcc 4.8/trunk with the patch for both. Sorry for breaking this, and went unresponsive. I tested this patch lifted from the bugzilla, and it does fix the problem for GCC 4.8. I'm also including the appropriate patch for GCC 4.9 (different due to the surrounding code being different). While there are other problems with SPE in GCC 4.9, I feel this patch is safe to apply. I have bootstraped the patch on a power7 running linux powerpc64 and there were no regressions between the unpatched gcc 4.8 and the build with the patch attached. I have verified that the bug is fixed when I build a SPE compiler with the patch attached for the GCC 4.8 patch. I have also bootstraped the GCC 4.9 patch on a power7 running linux powerpc64. As I write this message, I haven't done the make check regression test, but I will do that shortly. Are these patches ok to apply? I can apply just the 4.8 patch or both the 4.8 and 4.9 patches. 2013-12-12 Roland Stigge sti...@antcom.de Michael Meissner meiss...@linux.vnet.ibm.com * config/rs6000/rs6000.c (rs6000_legitimate_offset_address_p): Only check TFmode for SPE constants. Don't check TImode or TDmode.
[Bug target/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #13 from Michael Meissner meissner at linux dot vnet.ibm.com --- Created attachment 31429 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31429action=edit pr57386.patch01-gcc49
[Bug libgomp/58756] FAIL: libgomp.c/pr58392.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58756 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Sounds like omp-low.c bug, this is reproduceable even on i?86/x86_64 with safelen(1) clause on the #pragma omp simd in foo function. Will look at it tomorrow.
[Bug c++/59482] A friend class cannot inherit a private nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59482
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com ---
A friend function can access the private class, thus
void f();
struct B {
friend void f();
private:
struct C {};};
void f() {
struct D : B::C{};
}
Some analysis follows:
I investigated this a bit. The right place seemed to be enforce_access
in search.c, and that then ends up in accessible_p. From there we go
to friend_accessible_p, which returns false. The problem is that
the current_scope() in accessible_p is NAMESPACE_DECL,
and we should perhaps already be in a class scope, since we're dealing
with the base-clause. Now that we get NAMESPACE_DECL, there
are no befriended_classes for it.
Then again, it's probably not that simple. I guess we shouldn't
willy-nilly make the compiler think it's in a class scope when
dealing with a base-clause, so that lookup doesn't look into the class yet.
Any guidance as to what now? would be appreciated.
I'll dump the backtrace how we get to current_scope, hope that helps.
(I must admit I stand at least _some chance_ of figuring things out
with a debugger with my puny gcc skills, but not much of a chance...)
If you need any trees to be printed, I can certainly provide them.
#0 current_scope () at ../../gcc/cp/search.c:526
#1 0x006be0c5 in accessible_p (type=0x71af64e0,
decl=0x71ae8b80, consider_local_p=optimized out) at
../../gcc/cp/search.c:873
#2 0x00540e0d in enforce_access (basetype_path=optimized
out, decl=0x71ae8b80, diag_decl=0x71ae8b80, complain=3) at
../../gcc/cp/call.c:5753
#3 0x006c72a0 in perform_or_defer_access_check
(binfo=0x71ae8b80, decl=0x71ae8b80, diag_decl=0x719b5000,
complain=0) at ../../gcc/cp/semantics.c:340
#4 0x00641b2f in cp_parser_lookup_name
(parser=parser@entry=0x71afb000, name=name@entry=0x71afad68,
tag_type=tag_type@entry=typename_type,
is_template=is_template@entry=false,
is_namespace=is_namespace@entry=false, check_dependency=optimized
out, ambiguous_decls=ambiguous_decls@entry=0x7fffd708,
name_location=91) at ../../gcc/cp/parser.c:22155
#5 0x006626d9 in cp_parser_class_name
(parser=parser@entry=0x71afb000, typename_keyword_p=optimized
out, template_keyword_p=optimized out,
tag_type=tag_type@entry=typename_type,
check_dependency_p=check_dependency_p@entry=true,
class_head_p=class_head_p@entry=false,
is_declaration=is_declaration@entry=true) at
../../gcc/cp/parser.c:19023
#6 0x0064b89d in cp_parser_base_specifier
(parser=0x71afb000) at ../../gcc/cp/parser.c:20747
#7 cp_parser_base_clause (parser=0x71afb000) at
../../gcc/cp/parser.c:20577
#8 cp_parser_class_head (nested_name_specifier_p=synthetic pointer,
parser=0x71afb000) at ../../gcc/cp/parser.c:19824
#9 cp_parser_class_specifier_1 (parser=0x71afb000) at
../../gcc/cp/parser.c:19119
#10 cp_parser_class_specifier (parser=0x71afb000) at
../../gcc/cp/parser.c:19401
#11 cp_parser_type_specifier (parser=parser@entry=0x71afb000,
flags=flags@entry=1, decl_specs=decl_specs@entry=0x7fffd8e0,
is_declaration=is_declaration@entry=true,
declares_class_or_enum=declares_class_or_enum@entry=0x7fffd85c,
is_cv_qualifier=is_cv_qualifier@entry=0x7fffd85b) at
../../gcc/cp/parser.c:14292
#12 0x00662ba0 in cp_parser_decl_specifier_seq
(parser=parser@entry=0x71afb000, flags=flags@entry=1,
decl_specs=decl_specs@entry=0x7fffd8e0,
declares_class_or_enum=declares_class_or_enum@entry=0x7fffd8dc) at
../../gcc/cp/parser.c:11537
#13 0x0066972a in cp_parser_simple_declaration
(parser=parser@entry=0x71afb000,
function_definition_allowed_p=function_definition_allowed_p@entry=true,
maybe_range_for_decl=maybe_range_for_decl@entry=0x0) at
../../gcc/cp/parser.c:11127
#14 0x0064d2a4 in cp_parser_block_declaration
(parser=0x71afb000, statement_p=optimized out) at
../../gcc/cp/parser.c:11076
#15 0x00673fa4 in cp_parser_declaration
(parser=parser@entry=0x71afb000) at ../../gcc/cp/parser.c:10973
#16 0x00672c99 in cp_parser_declaration_seq_opt
(parser=parser@entry=0x71afb000) at ../../gcc/cp/parser.c:10859
#17 0x0067458b in cp_parser_translation_unit
(parser=0x71afb000) at ../../gcc/cp/parser.c:4018
#18 c_parse_file () at ../../gcc/cp/parser.c:31322
#19 0x00796444 in c_common_parse_file () at
../../gcc/c-family/c-opts.c:1056
#20 0x00b46fd6 in compile_file () at ../../gcc/toplev.c:547
#21 0x00b48f98 in do_compile () at ../../gcc/toplev.c:1887
#22 toplev_main (argc=31, argv=0x7fffdc18) at ../../gcc/toplev.c:1963
#23 0x0030a0421735 in __libc_start_main (main=0x53d970 main(int,
char**), argc=31, ubp_av=0x7fffdc18, init=optimized out,
fini=optimized out, rtld_fini=optimized out,
stack_end=0x7fffdc08) at libc-start.c:226
#24 0x0053d9f1 in _start ()
(gdb)
[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897
--- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org ---
Issue is related to option -fasynchronous-unwind-tables option. Better said to
option -fasynchronous-unwind-tables without -funwind-tables.
Following sample can demonstrate issue pretty well:
'#include intrin.h
int a;'
By compiling test by '$ x86_64-w64-mingw32-gcc -S -o t.s t_xmmintrin.c -O2
-fasynchronous-unwind-tables' I can reproduce the fentry message.
By removing option -fasynchronous-unwind-tables, or adding -funwind-tables
option message won't be displayed.
By following patch for me the issue is solved:
Index: i386.c
===
--- i386.c (Revision 205859)
+++ i386.c (Arbeitskopie)
@@ -3698,6 +3698,10 @@
{
if (opts-x_optimize = 1 !opts_set-x_flag_omit_frame_pointer)
opts-x_flag_omit_frame_pointer = !USE_X86_64_FRAME_POINTER;
+ if (opts-x_flag_asynchronous_unwind_tables
+ !opts_set-x_flag_unwind_tables
+ TARGET_64BIT_MS_ABI)
+ opts-x_flag_unwind_tables = 1;
if (opts-x_flag_asynchronous_unwind_tables == 2)
opts-x_flag_unwind_tables
= opts-x_flag_asynchronous_unwind_tables = 1;
I will apply this patch to trunk soon, if there are no objections.
[Bug tree-optimization/56572] GCC generates non-optimal transactional code when inlining nested transaction.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56572 --- Comment #7 from Aldy Hernandez aldyh at gcc dot gnu.org --- Well, we could tweak the inliner cost model, thus causing the early inliner to inline the nested transactions earlier. With the attached patch, f() gets inlined into g() early enough so that pass_ipa_tm sees the nested transaction before the uninstrumented path has been added. So with this patch, we could twiddle IPA tm to remove nested transactions without it handling the unnecessarily complex uninstrumented/instrumented code paths. However, it seems to me that the proper IPA inliner may add other (possibly nested) transactions, which will have us back to square one by tmmark time (??). This sounds like a good start, and if we find that the latter IPA inliner creates other unnecessary nested transactions (in other test cases), we could bite the bullet and do the whole thing in tmmark, handling both uninstrumented and instrumented code paths. Waddaya think? diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c index f42ade02..1cb9e58 100644 --- a/gcc/tree-inline.c +++ b/gcc/tree-inline.c @@ -3969,7 +3969,7 @@ init_inline_once (void) eni_size_weights.target_builtin_call_cost = 1; eni_size_weights.div_mod_cost = 1; eni_size_weights.omp_cost = 40; - eni_size_weights.tm_cost = 10; + eni_size_weights.tm_cost = 2; eni_size_weights.time_based = false; eni_size_weights.return_cost = 1;
[Bug fortran/59440] [4.9 Regression] ICE in force_decl_die, at dwarf2out.c:20111 with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59440 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Harald Anlauf anlauf at gmx dot de --- (In reply to Tobias Burnus from comment #5) FIXED! Thanks for the report and quick feedback! Tobias, here's another case where it crashes again: % cat gfcbug127.f90 module gfcbug127 implicit none type t integer :: grid = 0 end type t contains subroutine read_nml (nnml, s) integer, intent(in) :: nnml type(t), intent(out) :: s integer :: grid call read_nml_type_2 s% grid = grid contains subroutine read_nml_type_2 namelist /N/ grid read (nnml, nml=N) end subroutine read_nml_type_2 end subroutine read_nml end module gfcbug127 % /opt/gcc/4.9/bin/gfortran -c gfcbug127.f90 -g gfcbug127.f90: In function 'read_nml_type_2': gfcbug127.f90:17:0: internal compiler error: in force_decl_die, at dwarf2out.c:20111 end subroutine read_nml_type_2 ^ 0x83eb334 force_decl_die ../../trunk/gcc/dwarf2out.c:20111 0x83eb87e gen_namelist_decl ../../trunk/gcc/dwarf2out.c:20632 0x83e9547 gen_decl_die ../../trunk/gcc/dwarf2out.c:20435 0x83fd4b5 decls_for_scope ../../trunk/gcc/dwarf2out.c:19969 0x83e31dc gen_subprogram_die ../../trunk/gcc/dwarf2out.c:18354 0x83e9b99 gen_decl_die ../../trunk/gcc/dwarf2out.c:20336 0x83eb0ce dwarf2out_function_decl ../../trunk/gcc/dwarf2out.c:20776 0x8454f92 rest_of_handle_final ../../trunk/gcc/final.c:4469 0x8454f92 execute ../../trunk/gcc/final.c:4513
[Bug ada/55946] wrong tools used for build of gnattools [native-cross]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55946 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Thu Dec 12 22:50:07 2013 New Revision: 205945 URL: http://gcc.gnu.org/viewcvs?rev=205945root=gccview=rev Log: PR ada/55946 gnattools/ * Makefile.in (host): Define. (host_alias): Likewise. (TOOLS_FLAGS_TO_PASS_RE): Add LDFLAGS. (GNATMAKE_FOR_HOST): Define. (GNATLINK_FOR_HOST): Likewise. (GNATBIND_FOR_HOST): Likewise. (GNATLS_FOR_HOST): Likewise. (RTS_DIR): Move around and use GNATLS_FOR_HOST. (TOOLS_FLAGS_TO_PASS_CROSS): Use the other *_HOST variables. gcc/ada/ * gcc-interface/Make-lang.in (ada/doctools/xgnatugn): Use gnatmake. * gcc-interface/Makefile.in (GCC_LINK): Add LDFLAGS. (../../gnatmake): Remove LDFLAGS. (../../gnatlink): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Make-lang.in trunk/gcc/ada/gcc-interface/Makefile.in trunk/gnattools/ChangeLog trunk/gnattools/Makefile.in
[Bug ada/55946] wrong tools used for build of gnattools [native-cross]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55946 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Thu Dec 12 22:53:43 2013 New Revision: 205947 URL: http://gcc.gnu.org/viewcvs?rev=205947root=gccview=rev Log: PR ada/55946 gnattools/ * Makefile.in (host): Define. (host_alias): Likewise. (TOOLS_FLAGS_TO_PASS_RE): Add LDFLAGS. (GNATMAKE_FOR_HOST): Define. (GNATLINK_FOR_HOST): Likewise. (GNATBIND_FOR_HOST): Likewise. (GNATLS_FOR_HOST): Likewise. (RTS_DIR): Move around and use GNATLS_FOR_HOST. (TOOLS_FLAGS_TO_PASS_CROSS): Use the other *_HOST variables. gcc/ada/ * gcc-interface/Make-lang.in (ada/doctools/xgnatugn): Use gnatmake. * gcc-interface/Makefile.in (GCC_LINK): Add LDFLAGS. (../../gnatmake): Remove LDFLAGS. (../../gnatlink): Likewise. Modified: branches/gcc-4_8-branch/gcc/ada/ChangeLog branches/gcc-4_8-branch/gcc/ada/gcc-interface/Make-lang.in branches/gcc-4_8-branch/gcc/ada/gcc-interface/Makefile.in branches/gcc-4_8-branch/gnattools/ChangeLog branches/gcc-4_8-branch/gnattools/Makefile.in
[Bug ada/55946] wrong tools used for build of gnattools [native-cross]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55946 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.3 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org --- This should be fixed now. Note that the violation of No_Implicit_Dynamic_Code comes from the misconfiguration of the host compiler: you need to add the required bits to ada/gcc-interface/Makefile.in for an aarch64-based target.
[Bug tree-optimization/59149] diagnose_tm_1 calls flags_from_decl_or_type on an ADDR_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59149 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-12 CC||aldyh at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org --- Mine. Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01209.html
[Bug target/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 --- Comment #14 from Roland Stigge stigge at antcom dot de --- Yes, both patches are good, thanks. :-) I currently can't give you developer's access to one of my e500v2 machines. But I hope I can provide it for the future. Will tell you directly when it's ready at some point. You would need the hardware for testing because all other power*s are incompatible.
[Bug other/59490] New: [4.9 Regression] cilk-plus failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59490 Bug ID: 59490 Summary: [4.9 Regression] cilk-plus failure Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com On Linux/ia32, GCC r205902 configured with --with-arch=corei7 --with-cpu=corei7 FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -g -O2 -fcilkplus -L/export/gnu/import/git/gcc-test-intel64corei7/bld/x86_64-unknown-linux-gnu/32/libcilkrts/.libs execution test FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -g -O3 -fcilkplus -L/export/gnu/import/git/gcc-test-intel64corei7/bld/x86_64-unknown-linux-gnu/32/libcilkrts/.libs execution test FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -O1 -fcilkplus -L/export/gnu/import/git/gcc-test-intel64corei7/bld/x86_64-unknown-linux-gnu/32/libcilkrts/.libs execution test FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -O2 -fcilkplus -L/export/gnu/import/git/gcc-test-intel64corei7/bld/x86_64-unknown-linux-gnu/32/libcilkrts/.libs execution test FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -O3 -fcilkplus -L/export/gnu/import/git/gcc-test-intel64corei7/bld/x86_64-unknown-linux-gnu/32/libcilkrts/.libs execution test
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #18 from bin.cheng amker.cheng at gmail dot com --- Hi Dominique d'Humieres, Thanks for verifying it.
[Bug other/59490] [4.9 Regression] cilk-plus failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59490
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-12-13
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com ---
To reproduce:
# make check-c++ RUNTESTFLAGS=--target_board='unix{-m32\ -march=corei7}'
cilk-plus.exp=catch_exc.cc
...
FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -O1 -fcilkplus
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libcilkrts/.libs
execution test
FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -O2 -fcilkplus
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libcilkrts/.libs
execution test
FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -O3 -fcilkplus
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libcilkrts/.libs
execution test
FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -g -O2 -fcilkplus
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libcilkrts/.libs
execution test
FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -g -O3 -fcilkplus
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libcilkrts/.libs
execution test
[Bug other/59490] [4.9 Regression] cilk-plus failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59490
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
Just -mtune=corei7:
make check-c++ RUNTESTFLAGS=--target_board='unix{-m32\ -mtune=corei7}'
cilk-plus.exp=catch_exc.cc
is sufficient to reproduce.
[Bug c++/58954] [4.8/4.9 Regression] accessing a private member function in decltype of a friend class causes access control error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58954 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 c++/58954] [4.8/4.9 Regression] accessing a private member function in decltype of a friend class causes access control error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58954 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Dec 13 03:58:48 2013 New Revision: 205952 URL: http://gcc.gnu.org/viewcvs?rev=205952root=gccview=rev Log: PR c++/58954 * pt.c (resolve_overloaded_unification): Use instantiate_template. Added: trunk/gcc/testsuite/g++.dg/cpp0x/access02.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/58954] [4.8/4.9 Regression] accessing a private member function in decltype of a friend class causes access control error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58954 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Dec 13 03:59:10 2013 New Revision: 205954 URL: http://gcc.gnu.org/viewcvs?rev=205954root=gccview=rev Log: PR c++/58954 * pt.c (resolve_overloaded_unification): Discard access checks. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/access02.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/pt.c
[Bug middle-end/53623] [4.7/4.8/4.9 Regression] sign extension is effectively split into two x86-64 instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53623 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #8 from Jeffrey A. Law law at redhat dot com --- Jakub, I'm playing with some of your ideas from c#5. It's actually not a bad approach to fixing this problem. Presumably in the REGNO != REGNO case, if we were to allow it, the requirement that there be a single reaching def is so that we don't end up with different destination registers in the different reaching defs. Right? It also makes updating marginally easier as there's only one def to fixup. I don't offhand recall a good way to test that the extension under consideration dominates all the others. Can't they be in arbitrary blocks and locations within the blocks? And all the others presumably means other users of the original memory load, right? What did you have in mind for testing this? We definitely want to change the destination of the load to use the other register and emit a copy from the other register to the load's original destination. That insn needs to be emitted immediately after the defining insn. And yes, the hard register propagation pass should propagate away the copy most of the time. Anyway, it's showing enough promise that I'll keep poking.
[Bug fortran/59440] [4.9 Regression] ICE in force_decl_die, at dwarf2out.c:20111 with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59440 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||openmp --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org --- Also the following variant fails, where the NAMELIST and the grid variable are in the same subroutine - and only the NML read is in the internal subroutine. module gfcbug127 implicit none type t integer :: grid = 0 end type t contains subroutine read_nml (nnml, s) integer, intent(in) :: nnml type(t), intent(out) :: s integer :: grid namelist /N/ grid call read_nml_type_2 s%grid = grid contains subroutine read_nml_type_2 read (nnml, nml=N) end subroutine read_nml_type_2 end subroutine read_nml end module gfcbug127
