[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 --- Comment #11 from Marc Glisse --- (In reply to bredelin from comment #10) > Was this change intentional? See: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01101.html and Paolo's reply.
[Bug middle-end/58711] New: Missing "uninitialized" warning in loop condition (when compiling without optimization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58711
Bug ID: 58711
Summary: Missing "uninitialized" warning in loop condition
(when compiling without optimization)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mimomorin at gmail dot com
In the following code, `cond` is uninitialized in `while (cond)`. However,
the "uninitialized" warning (i.e. "variable 'cond' is uninitialized when used
here")
does not emit when compiling without optimization.
(If we compile it with optimization option, the warning is properly emitted.)
Tested on gcc 4.4-4.8, 4.9 (trunk).
int main(int argc, char* argv[])
{
int cond;
// Missing "uninitialized" warning
while (cond != 0) {
// `(void)` is used to avoid "unused-value" warning
(void)&cond;
}
return 0;
}
Clang has the same issue, but it's fixed recently.
( http://llvm.org/bugs/show_bug.cgi?id=16054 )
[Bug libstdc++/58710] New: HAVE_GETIPINFO is incorrectly set on Mac OS X 10.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58710 Bug ID: 58710 Summary: HAVE_GETIPINFO is incorrectly set on Mac OS X 10.4 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: misty at brew dot sh _Unwind_GetIPInfo isn't available on Mac OS X 10.4 and older. GCC checks for this specific case in several places to ensure it isn't used inappropriately, but there seem to be a few issues that cause it to be used anyway. See #56811 for an example of this. When checking for whether to use the system unwind, configure scripts specifically check for Darwin 8 and older (see, for example, libbacktrace's configure at L11629-11648); when Darwin 8 is encountered it explicitly sets have_unwind_getipinfo to 0 to ensure it won't be used. However, the same configure script also later does an independent check to see if _Unwind_GetIPInfo is available, and this is erroneously reporting that it's available. As a result several libraries, like libbacktrace, try to use _UnwindGetIPInfo and the build fails at the link stage. When I took a look at the config.log, it seems it's compiling using `-c`, so the linker is inhibited: configure:11652: checking for _Unwind_GetIPInfo configure:11667: /usr/local/bin/gcc-4.4 -c -g -Werror-implicit-function-declaration conftest.c >&5 configure:11667: $? = 0 configure:11674: result: yes However, the specific problem on OS X 10.4 is that _Unwind_GetIPInfo isn't exported - and so the test would only fail if the linker was invoked. I've noticed that a few sections of GCC, such as raise-gcc.c, appear to expect that they'll get an incorrect configure value and redefine it themselves: #ifdef __APPLE__ /* On MacOS X, versions older than 10.5 don't export _Unwind_GetIPInfo. */ #undef HAVE_GETIPINFO #if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1050 #define HAVE_GETIPINFO 1 #endif #endif However, this isn't done consistently, which is why other places (like _Unwind_GetIPInfo) still try to use it.
[Bug c++/58700] [4.8/4.9 Regression] ICE declaring static bit-field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58700 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-10-13 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Mine.
[Bug c++/58701] [4.9 Regression] [c++11] ICE initializing member of static union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58701 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-13 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- This is the relevant change: r199455. CC-ing Jason.
[Bug c++/58709] [c++11] Bogus? int vs. scoped enum printf warning when -fabi-version >= 6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58709 --- Comment #2 from Paul Pluzhnikov --- (In reply to Andrew Pinski from comment #1) > I think the warning is correct as it is not promoted to int in the function > call. How is it passed then? I see: movl$0, 4(%esp) movl$.LC0, (%esp) callprintf on ix86, and movl$0, %esi movl$.LC0, %edi callprintf on x86_64. Looks like an "int" to me.
[Bug c++/58709] [c++11] Bogus? int vs. scoped enum printf warning when -fabi-version >= 6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58709 --- Comment #1 from Andrew Pinski --- I think the warning is correct as it is not promoted to int in the function call. This is the same reason why bitfields warn when passing them for printf too.
[Bug c++/58709] New: [c++11] Bogus? int vs. scoped enum printf warning when -fabi-version >= 6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58709
Bug ID: 58709
Summary: [c++11] Bogus? int vs. scoped enum printf warning when
-fabi-version >= 6
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Test:
#include
enum class Foo {
FOO
};
int main()
{
printf("%d\n", Foo::FOO);
}
Using "g++ (GCC) 4.9.0 20131005 (experimental)":
$ g++ -c -std=c++11 -Wformat t.cc
$
$ g++ -c -std=c++11 -Wformat t.cc -fabi-version=6
t.cc:9:26: warning: format ‘%d’ expects argument of type ‘int’, but argument 2
has type ‘Foo’ [-Wformat=]
printf("%d\n", Foo::FOO);
^
From gcc/common.opt:
; 6: The version of the ABI that doesn't promote scoped enums to int and ...
This seems like a bug -- even though the scoped enum is not promoted to an int,
printf warning doesn't seem appropriate here either.
[Bug libstdc++/58605] atomic::atomic() disobeys [atomics.types.operations.req]p4 for types with user-defined default constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58605 --- Comment #4 from Daniel Krügler --- (In reply to Daniel Krügler from comment #3) A new library has been opened: http://cplusplus.github.io/LWG/lwg-active.html#2334
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-12 Ever confirmed|0 |1 --- Comment #20 from Dominique d'Humieres --- Still present at revision 203491 and the patch in comment #14 does not help.
[Bug c++/58708] New: string literal operator templates broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58708 Bug ID: 58708 Summary: string literal operator templates broken Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mustrumr97 at gmail dot com The character type should be unqualified (char32_t instead of const char32_t). Wide character types are broken. U"
[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 bredelin at ucla dot edu changed: What|Removed |Added CC||bredelin at ucla dot edu --- Comment #10 from bredelin at ucla dot edu --- It seems that these changes (see Sep 17th) also made the default constructor explicit. While this does follow the standard, it is the subject of this defect report: http://cplusplus.github.io/LWG/lwg-active.html#2193 Was this change intentional?
[Bug c++/58707] New: [C++11] A greater-than operator in square brackets should not end a template argument list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58707
Bug ID: 58707
Summary: [C++11] A greater-than operator in square brackets
should not end a template argument list
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tuomas.tynkkynen at iki dot fi
Created attachment 30993
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30993&action=edit
The failing code snippet
The following code snippet does not compile on latest GCC trunk:
template class TC { };
constexpr int foo[] = { 42, };
TC 1]> bar;
Actual result:
tmtynkky@e42-7:/tmp$ /dos/gcc-trunk/bin/gcc -xc++ -std=c++11 -pedantic -c -o
/dev/null bracket.cpp
bracket.cpp:3:10: error: template argument 1 is invalid
TC 1]> bar;
^
bracket.cpp:3:12: error: expected unqualified-id before numeric constant
TC 1]> bar;
^
The '>' seems to get parsed as the ending delimiter of the template argument
list, even though it shouldn't since it is nested inside a pair of square
brackets. Clang++ 3.3 correctly accepts this snippet.
(originally discussed on
http://forum.cppgm.org/question/2286/inside-square-brackets-terminates-a-template-argument-list/)
Version information:
gcc version 4.9.0 20131011 (experimental) [trunk revision 203401] (GCC)
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk-source/gcc/configure --enable
languages=c,c++,fortran --enable-checking=release --disable-libmudflap
--disable libstdcxx-pch --enable-libgomp --enable-lto --enable-gold
--with-plugin ld=/usr/bin/gold --with-cloog-include=/usr/include-cloog
--with-cloog lib=/usr/lib64 --prefix=/usr/local/gcc-trunk
[Bug c++/58706] New: ICE with lambda in OpenMP for-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58706
Bug ID: 58706
Summary: ICE with lambda in OpenMP for-loop
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid code snippet (compiled with "-std=c++11 -fopenmp") triggers
an ICE since GCC 4.5.0 (when lambdas were introduced):
===
template void foo()
{
#pragma omp for
for (T i = [](){ return 0; }(); i < 10; ++i)
;
}
void bar()
{
foo();
}
===
bug.cc: In instantiation of 'void foo() [with T = int]':
bug.cc:10:12: required from here
bug.cc:3:9: internal compiler error: Segmentation fault
#pragma omp for
^
0xb15dff crash_signal
../../gcc/gcc/toplev.c:335
0x6cabd2 contains_struct_check
../../gcc/gcc/tree.h:2787
0x6cabd2 finish_omp_for(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node*, tree_node*)
../../gcc/gcc/cp/semantics.c:6321
0x5aae3d tsubst_expr
../../gcc/gcc/cp/pt.c:13596
0x5a9db7 tsubst_expr
../../gcc/gcc/cp/pt.c:13384
0x5a6d69 instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:19603
0x5e4c6f instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:19715
0x6204c6 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4121
Please submit a full bug report, [etc.]
[Bug c++/58705] [4.7/4.8/4.9 Regression] [c++11] ICE with invalid initializer for _Complex variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58705 Volker Reichelt changed: What|Removed |Added Keywords||ice-on-invalid-code Known to work||4.6.0 Target Milestone|--- |4.7.4 Known to fail||4.7.0, 4.8.0, 4.9.0
[Bug c++/58705] New: [4.7/4.8/4.9 Regression] [c++11] ICE with invalid initializer for _Complex variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58705
Bug ID: 58705
Summary: [4.7/4.8/4.9 Regression] [c++11] ICE with invalid
initializer for _Complex variable
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-std=c++11") triggers an ICE
since GCC 4.7.0:
===
_Complex float f = {{}};
===
bug.cc:1:23: internal compiler error: Segmentation fault
_Complex float f = {{}};
^
0xb15dff crash_signal
../../gcc/gcc/toplev.c:335
0x5e6d15 vec::operator[](unsigned int)
../../gcc/gcc/vec.h:827
0x5e6d15 check_narrowing(tree_node*, tree_node*)
../../gcc/gcc/cp/typeck2.c:836
0x55e437 check_initializer
../../gcc/gcc/cp/decl.c:5669
0x570ccc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6356
0x65e7e7 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16633
0x65ff2f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11047
0x643860 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10928
0x66aaae cp_parser_declaration
../../gcc/gcc/cp/parser.c:10825
0x6697ca cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10711
0x66b0e6 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3989
0x66b0e6 c_parse_file()
../../gcc/gcc/cp/parser.c:30962
0x787f73 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #71 from Oleg Endo --- (In reply to Oleg Endo from comment #70) > Author: olegendo > Date: Sat Oct 12 20:47:22 2013 > New Revision: 203492 > The issue raised in comment #59 has been fixed on 4.9. There are some open issues though, which I will try to address in follow up patches: * The helper functions in sh_treg_combine.cc should go into a separate .h + .cc file. This would allow re-using them in other places and eliminate the similar function 'sh_find_set_of_reg' in sh.c * The RTL pass does the treg combine only when there is a conditional branch. It should also handle conditional move insns (-mpretend-cmove). * The function 'try_combine_comparisons' in sh_reg_combine.cc always introduces reg-reg copies. In some cases (DImode comparisons in particular), these reg-reg moves don't get eliminated afterwards before register allocation. The function should check whether creating new pseudos can be avoided by re-using existing regs. The sh_treg_combine RTL pass could probably be backported to 4.8 but seems too intrusive. Instead something like the patch in comment #64 should do, where instead of checking for 'no_labels_between_p' it would probably be better to check if the basic block with the conditional branch has only one predecessor.
[Bug c++/58704] New: [c++11] ICE initializing array member of template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58704
Bug ID: 58704
Summary: [c++11] ICE initializing array member of template
class
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid code snippet (compiled with "-std=c++11") triggers an ICE
since GCC 4.7.0 (when non-static data member initializers were introduced):
=
struct A {};
template struct B
{
A a[1] = {};
};
B b;
=
bug.cc: In constructor 'constexpr B::B()':
bug.cc:3:27: internal compiler error: tree check: expected tree that contains
'common' structure, have 'constructor' in perform_member_init, at cp/init.c:665
template struct B
^
0xd159c7 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:9472
0x6a3e2d contains_struct_check
../../gcc/gcc/tree.h:2788
0x6a3e2d perform_member_init
../../gcc/gcc/cp/init.c:665
0x6a3e2d emit_mem_initializers(tree_node*)
../../gcc/gcc/cp/init.c:1096
0x6acfae synthesize_method(tree_node*)
../../gcc/gcc/cp/method.c:796
0x61e379 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4778
0x54d0b6 build_over_call
../../gcc/gcc/cp/call.c:7116
0x548eae build_new_method_call_1
../../gcc/gcc/cp/call.c:7813
0x548eae build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7883
0x549e22 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7440
0x69eba7 expand_default_init
../../gcc/gcc/cp/init.c:1668
0x69eba7 expand_aggr_init_1
../../gcc/gcc/cp/init.c:1769
0x6a1779 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/init.c:1520
0x55e005 build_aggr_init_full_exprs
../../gcc/gcc/cp/decl.c:5552
0x55e005 check_initializer
../../gcc/gcc/cp/decl.c:5687
0x570ccc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6356
0x65e7e7 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16633
0x65ff2f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11047
0x643860 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10928
0x66aaae cp_parser_declaration
../../gcc/gcc/cp/parser.c:10825
Please submit a full bug report, [etc.]
[Bug c++/58703] [4.9 Regression] ICE with invalid types in OpenMP declare reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58703 Volker Reichelt changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Target Milestone|--- |4.9.0 Known to fail||4.9.0
[Bug testsuite/58645] FAIL: gnat.dg/specs/linker_alias.ads (test for errors, line 6)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645 --- Comment #4 from Eric Botcazou --- > It is not! I was about to open a PR for it: > > On x86_64-apple-darwin(10|12) gnat.dg/specs/linker_section.ads fails, It is, you're confusing 2 different tests here.
[Bug c++/58703] New: [4.9 Regression] ICE with invalid types in OpenMP declare reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58703 Bug ID: 58703 Summary: [4.9 Regression] ICE with invalid types in OpenMP declare reduction clause Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org The following invalid code snippet (compiled with "-fopenmp") triggers an ICE on trunk: #pragma omp declare reduction (+ : char[] : omp_out += omp_in) #pragma omp declare reduction (+ : char() : omp_out += omp_in) bug.cc:1:36: error: function or array type 'char []' in '#pragma omp declare reduction' #pragma omp declare reduction (+ : char[] : omp_out += omp_in) ^ bug.cc:2:36: error: function or array type 'char()' in '#pragma omp declare reduction' #pragma omp declare reduction (+ : char() : omp_out += omp_in) ^ bug.cc:2:63: internal compiler error: in cp_parser_translation_unit, at cp/parser.c:4019 #pragma omp declare reduction (+ : char() : omp_out += omp_in) ^ 0x66b3b0 cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4018 0x66b3b0 c_parse_file() ../../gcc/gcc/cp/parser.c:30962 0x787f73 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1046 Please submit a full bug report, [etc.]
[Bug c++/58702] New: [4.9 Regression] ICE with undeclared variable in OpenMP reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58702
Bug ID: 58702
Summary: [4.9 Regression] ICE with undeclared variable in
OpenMP reduction clause
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-fopenmp") triggers an ICE
on trunk:
=
void foo()
{
x;
#pragma omp parallel for reduction(+:x)
for (int i = 0; i < 10; ++i) ;
}
=
bug.cc: In function 'void foo()':
bug.cc:3:3: error: 'x' was not declared in this scope
x;
^
bug.cc:4:40: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in finish_omp_reduction_clause, at
cp/semantics.c:4966
#pragma omp parallel for reduction(+:x)
^
0xd14f79 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9351
0x6df624 tree_class_check
../../gcc/gcc/tree.h:2797
0x6df624 finish_omp_reduction_clause
../../gcc/gcc/cp/semantics.c:4966
0x6df624 finish_omp_clauses(tree_node*)
../../gcc/gcc/cp/semantics.c:5709
0x634b1e cp_omp_split_clauses
../../gcc/gcc/cp/parser.c:28967
0x66873e cp_parser_omp_for
../../gcc/gcc/cp/parser.c:29079
0x668c4b cp_parser_omp_parallel
../../gcc/gcc/cp/parser.c:29259
0x63f221 cp_parser_omp_construct
../../gcc/gcc/cp/parser.c:30380
0x63f221 cp_parser_pragma
../../gcc/gcc/cp/parser.c:30885
0x64555c cp_parser_statement
../../gcc/gcc/cp/parser.c:9297
0x646342 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9604
0x646486 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9558
0x659b0b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18401
0x659b0b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18437
0x65df0f cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22444
0x65ece2 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22365
0x65ece2 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16412
0x65ff2f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11047
0x643860 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10928
0x66aaae cp_parser_declaration
../../gcc/gcc/cp/parser.c:10825
Please submit a full bug report, [etc.]
The regression was introduced between 2013-10-09 and 2013-10-11.
[Bug c++/58702] [4.9 Regression] ICE with undeclared variable in OpenMP reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58702 Volker Reichelt changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code, openmp Known to work||4.8.0 Target Milestone|--- |4.9.0 Known to fail||4.9.0
[Bug c++/58701] [4.9 Regression] [c++11] ICE initializing member of static union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58701 Volker Reichelt changed: What|Removed |Added Known to work||4.7.0, 4.8.0 Target Milestone|--- |4.9.0 Known to fail||4.9.0
[Bug c++/58701] New: [4.9 Regression] [c++11] ICE initializing member of static union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58701
Bug ID: 58701
Summary: [4.9 Regression] [c++11] ICE initializing member of
static union
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid code snippet (compiled with "-std=c++11") triggers an ICE
on trunk (since at least 4.9.0 20130920):
===
static union
{
union
{
int i = 0;
};
};
===
bug.cc: In constructor 'constexpr::()':
bug.cc:2:1: internal compiler error: tree check: accessed operand 2 of
indirect_ref with 1 operands in build_anon_member_initialization, at
cp/semantics.c:7404
{
^
0xd201a7 tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
../../gcc/gcc/tree.c:9499
0x6d2677 tree_operand_check
../../gcc/gcc/tree.h:3109
0x6d2677 build_anon_member_initialization
../../gcc/gcc/cp/semantics.c:7404
0x6d2677 build_data_member_initialization
../../gcc/gcc/cp/semantics.c:7533
0x6d338d build_constexpr_constructor_member_initializers
../../gcc/gcc/cp/semantics.c:7652
0x6d338d massage_constexpr_body
../../gcc/gcc/cp/semantics.c:7752
0x6da9a3 register_constexpr_fundef(tree_node*, tree_node*)
../../gcc/gcc/cp/semantics.c:7856
0x56ea38 maybe_save_function_definition
../../gcc/gcc/cp/decl.c:13823
0x56ea38 finish_function(int)
../../gcc/gcc/cp/decl.c:13944
0x6acc19 synthesize_method(tree_node*)
../../gcc/gcc/cp/method.c:809
0x61e379 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4778
0x54d0b6 build_over_call
../../gcc/gcc/cp/call.c:7116
0x548eae build_new_method_call_1
../../gcc/gcc/cp/call.c:7813
0x548eae build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7883
0x549e22 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7440
0x69eba7 expand_default_init
../../gcc/gcc/cp/init.c:1668
0x69eba7 expand_aggr_init_1
../../gcc/gcc/cp/init.c:1769
0x6a1779 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/init.c:1520
0x55e005 build_aggr_init_full_exprs
../../gcc/gcc/cp/decl.c:5552
0x55e005 check_initializer
../../gcc/gcc/cp/decl.c:5687
Please submit a full bug report, [etc.]
[Bug c++/58700] [4.8/4.9 Regression] ICE declaring static bit-field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58700 Volker Reichelt changed: What|Removed |Added Keywords||ice-on-invalid-code Known to work||4.7.0 Target Milestone|--- |4.8.2 Known to fail||4.8.0, 4.9.0
[Bug c++/58700] New: [4.8/4.9 Regression] ICE declaring static bit-field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58700
Bug ID: 58700
Summary: [4.8/4.9 Regression] ICE declaring static bit-field
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet triggers an ICE since GCC 4.8.0:
=
struct A
{
static int : 4;
};
=
bug.cc:3:16: internal compiler error: Segmentation fault
static int : 4;
^
0xb15dff crash_signal
../../gcc/gcc/toplev.c:335
0x5831a7 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:10642
0x617fcd grokbitfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
tree_node*)
../../gcc/gcc/cp/decl2.c:1043
0x660ba6 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20031
0x6402c7 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:19726
0x6402c7 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:18970
0x6402c7 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19197
0x6402c7 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14144
0x65924f cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11389
0x65fd89 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10979
0x643860 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10928
0x66aaae cp_parser_declaration
../../gcc/gcc/cp/parser.c:10825
0x6697ca cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10711
0x66b0e6 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3989
0x66b0e6 c_parse_file()
../../gcc/gcc/cp/parser.c:30962
0x787f73 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]
GCC 4.7.x issued a suitable error message instead:
bug.cc:3:16: error: static member '' cannot be a bit-field
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #70 from Oleg Endo --- Author: olegendo Date: Sat Oct 12 20:47:22 2013 New Revision: 203492 URL: http://gcc.gnu.org/viewcvs?rev=203492&root=gcc&view=rev Log: PR target/51244 * config/sh/sh_treg_combine.cc: New SH specific RTL pass. * config.gcc (SH extra_objs): Add sh_ifcvt.o. * config/sh/t-sh (sh_treg_combine.o): New entry. * config/sh/sh.c (sh_fixed_condition_code_regs): New function that implements the target hook TARGET_FIXED_CONDITION_CODE_REGS. (register_sh_passes): New function. Register sh_treg_combine pass. (sh_option_override): Invoke it. (sh_canonicalize_comparison): Handle op0_preserve_value. * sh.md (*cbranch_t"): Do not try to optimize missed test and branch opportunities. Canonicalize branch condition. (nott): Allow only if pseudos can be created for non-SH2A. PR target/51244 * gcc.dg/torture/p51244-21.c: New. * gcc.target/sh/pr51244-20.c: New. * gcc.target/sh/pr51244-20-sh2a.c: New. Added: trunk/gcc/config/sh/sh_treg_combine.cc trunk/gcc/testsuite/gcc.dg/torture/pr51244-21.c trunk/gcc/testsuite/gcc.target/sh/pr51244-20-sh2a.c trunk/gcc/testsuite/gcc.target/sh/pr51244-20.c Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md trunk/gcc/config/sh/t-sh trunk/gcc/testsuite/ChangeLog
[Bug c/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52795 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-12 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed on darwin12 for 4.7, 4.8 and trunk (r203489) only with -m64. In addition I see FAIL: gcc.dg/tree-prof/pr45354.c compilation, -fprofile-use -D_PROFILE_USE FAIL: gcc.dg/tree-prof/pr50907.c compilation, -fprofile-use -D_PROFILE_USE and FAIL: g++.dg/tree-prof/pr57451.C compilation, -fprofile-use
[Bug tree-optimization/46507] std::get and devirtualization on non-automatic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507 Marc Glisse changed: What|Removed |Added Summary|std::tuple missed |std::get and |optimization|devirtualization on ||non-automatic variables --- Comment #5 from Marc Glisse --- I just read this comment in ipa-prop.c: "only for automatically allocated objects but at the moment we devirtualize only these". And indeed, if we define an automatic variable of type A and call arg_tuple_test on it (and that call is inlined), then the call to f is devirtualized. So this is a known limitation of the current devirtualization code. I don't think there is anything we can do at the library level.
[Bug c/52794] gcc.dg/tree-prof/pr52027.c fails on x86_64/i386-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52794 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-12 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed.
[Bug tree-optimization/58698] Spurious "may be used unitialized" warning when compiling with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58698 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Component|c |tree-optimization Known to fail||4.7.0, 4.8.1 --- Comment #5 from Andrew Pinski --- It happens with 4.7.0 also.
[Bug c++/57572] vector operators don't participate in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57572 --- Comment #1 from Marc Glisse --- Created attachment 30992 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30992&action=edit vector-only patch I have had this lying around for a while. IIRC it seemed to work, but it doesn't handle the mixed vector-scalar operations (and maybe it was missing other things as well).
[Bug testsuite/57605] colors break note pruning in the testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57605 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Marc Glisse --- Fixed by Jakub's patch, I assume.
Re: [Bug testsuite/58645] FAIL: gnat.dg/specs/linker_alias.ads (test for errors, line 6)
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645 > > --- Comment #2 from Dominique d'Humieres --- > > Sure, but you can just skip the testcase like on Darwin. > > It is not! I was about to open a PR for it: Actually the new output is as expected since types are now accepted (in addition to objects), I just forgot to update the test after changes made this week, now done. This won't make a difference for this PR though, since the issue is unrelated to this week's changes. Arno
[Bug testsuite/58645] FAIL: gnat.dg/specs/linker_alias.ads (test for errors, line 6)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645 --- Comment #3 from charlet at adacore dot com --- > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645 > > --- Comment #2 from Dominique d'Humieres --- > > Sure, but you can just skip the testcase like on Darwin. > > It is not! I was about to open a PR for it: Actually the new output is as expected since types are now accepted (in addition to objects), I just forgot to update the test after changes made this week, now done. This won't make a difference for this PR though, since the issue is unrelated to this week's changes. Arno
[Bug tree-optimization/55912] missing optimization of x/x and x/std::abs(x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55912 --- Comment #3 from Marc Glisse --- (In reply to Richard Biener from comment #2) > Most of the math builtin folding needs to be re-done at GIMPLE level based > on SSA form. Convenient places are either tree-ssa-forwprop.c or > tree-ssa-math-opts.c (sincos pass which also does power series expansion > now). tree-ssa-reassoc.c seems like a natural place to optimize x*a/x, since it already handles x+a-x.
[Bug testsuite/58645] FAIL: gnat.dg/specs/linker_alias.ads (test for errors, line 6)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645 --- Comment #2 from Dominique d'Humieres --- > Sure, but you can just skip the testcase like on Darwin. It is not! I was about to open a PR for it: On x86_64-apple-darwin(10|12) gnat.dg/specs/linker_section.ads fails, starting between revisions 203285 (OK) and 203395: output is: linker_section.ads:10:38: pragma "Linker_Section" applies only to objects and types gnatmake: "/opt/gcc/work/gcc/testsuite/gnat.dg/specs/linker_section.ads" compilation error Executing on host: /opt/gcc/build_w/gcc/gnatclean -c -q -n linker_section (timeout = 300) spawn /opt/gcc/build_w/gcc/gnatclean -c -q -n linker_section FAIL: gnat.dg/specs/linker_section.ads (test for errors, line 6) PASS: gnat.dg/specs/linker_section.ads (test for errors, line 10) PASS: gnat.dg/specs/linker_section.ads (test for excess errors)
[Bug target/58641] [4.9 Regression] FAIL: gcc.target/i386/pr49002-2.c scan-assembler vmovapd[\t ]*%ymm[0-9]+,[^,]*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58641 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dominique d'Humieres --- According to http://gcc.gnu.org/ml/gcc-regression/2013-10/msg00041.html this has been fixed by revision 203387.
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436 Paolo Carlini changed: What|Removed |Added CC|conradsand.arma at gmail dot com | --- Comment #10 from Paolo Carlini --- Yes, it's redundant, you get all the messages by default being the bug submitter
[Bug target/58690] internal compiler error: in copy_to_mode_reg, at explow.c:641
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58690 --- Comment #2 from hjl at gcc dot gnu.org --- Author: hjl Date: Sat Oct 12 14:55:28 2013 New Revision: 203486 URL: http://gcc.gnu.org/viewcvs?rev=203486&root=gcc&view=rev Log: Truncate x32 DImode TLS address to a SImode register gcc/ PR target/58690 * config/i386/i386.c (ix86_copy_addr_to_reg): New function. (ix86_expand_movmem): Replace copy_addr_to_reg with ix86_copy_addr_to_reg. (ix86_expand_setmem): Likewise. gcc/testsuite/ PR target/58690 * gcc.target/i386/pr58690.c: New test Added: trunk/gcc/testsuite/gcc.target/i386/pr58690.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/58699] New: ARM: emit PLDW instruction for prefetch with write intent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58699 Bug ID: 58699 Summary: ARM: emit PLDW instruction for prefetch with write intent Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mans at mansr dot com Created attachment 30991 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30991&action=edit Emit PLDW instruction for prefetch with write intent __builtin_prefetch(addr, 1) should result in a PLDW instruction on targets with the multiprocessing extension.
[Bug c++/58055] [meta-bug] RVO / NRVO improvements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055 --- Comment #4 from Marc Glisse --- (In reply to Eric Botcazou from comment #3) > You can go farther if the return operation overwrites entirely the anonymous > return object and for example allow returning literals, but I don't know if > this is a realistic case in C++; we allow that in Ada. If we build a local object in the return location and later decide to return another object instead, we need to call the destructor before we overwrite it, and we end up having to decide if shuffling the function calls that way is legal (probably hard). That may be ok when the destructor does nothing (the "literals" you mention?), but my main interest in this optimization in C++ is cases where the copy constructor and the destructor are non-trivial. Is there a clever way to chose which literal variables to put in the return location when there are several candidates (this might require profile information)? I am also wondering if this version restricted to trivial types couldn't be done in the middle-end tree-nrv.c. > In Ada we have little choice but to perform it in the FE, at least for > things like unconstrained array types, because the semantics is lost in the > ME. I was considering a mechanism to tell the middle-end about that semantic, but it does indeed seem simpler to do everything in the front-end.
[Bug tree-optimization/58697] [4.8 Regression] wrong code (segfaults) at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58697 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-12 CC||amacleod at redhat dot com, ||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |4.8.2 Summary|wrong code (segfaults) at |[4.8 Regression] wrong code |-O3 |(segfaults) at -O3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r192219, ended with r203317. The latter is weird, I thought Andrew's patches are just reshuffling of stuff, not changing compiler behavior. In any case, between r203316 and r203317, pre-unswitch dump the IL is the same, unswitching is the first changed dump.
[Bug c++/58055] [meta-bug] RVO / NRVO improvements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- > We currently only apply the NRVO when there is a single variable at the > topmost level of the function body such that all return statements are of > this variable. It seems like a wider characterization of the valid cases > would be when we have an automatic variable whose natural lifetime (from the > declaration to the end of the scope) includes returns only of this variable. You can go farther if the return operation overwrites entirely the anonymous return object and for example allow returning literals, but I don't know if this is a realistic case in C++; we allow that in Ada. > That may be easiest to detect in the front-end. Later, the scope would be > the try block in a try-finally right after a constructor call? In SSA it is > even less obvious. For return statements, we need to look for a call to a > copy constructor before a return statement, again more complicated than in > the FE. Yes, it's definitely easier to use scoping information in the FE. > However, actually performing the optimization in the FE is not trivial. We > want to remove the calls to the destructor of the variable, but not all, > only those associated to a return. In Ada we have little choice but to perform it in the FE, at least for things like unconstrained array types, because the semantics is lost in the ME.
[Bug c++/40365] g++ template expansion bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40365 --- Comment #7 from Oleg Dolomanov --- Sorry guys, it really was the hardware: I wish you could see (I have a picture!), but it was one of the memory chips (one along the 16 on the OCZ 2Gb PC2 6400 5-5-5-18!) falling off - it did take me long time to track this down... And any other things too... So you can discard this for sure. o
[Bug tree-optimization/58696] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58696 --- Comment #1 from Mikael Pettersson --- Broke with r203061, works again with r203463, likely dup of PR58640.
[Bug libgomp/58691] OpenMP 4: Surprising results with OMP_PLACES=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58691 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Sat Oct 12 07:52:15 2013 New Revision: 203479 URL: http://gcc.gnu.org/viewcvs?rev=203479&root=gcc&view=rev Log: PR libgomp/58691 * config/linux/proc.c (gomp_cpuset_popcount): Add unused attribute to check variable. (gomp_init_num_threads): Move i variable declaration into #ifdef CPU_ALLOC_SIZE block. * config/linux/affinity.c (gomp_affinity_init_level): Test gomp_places_list_len == 0 rather than gomp_places_list == 0 when checking for topology reading error. * team.c (gomp_team_start): Don't handle bind == omp_proc_bind_false. * env.c (parse_affinity): Add ignore argument, if true, don't populate gomp_places_list, only parse env var and always return false. (parse_places_var): Likewise. Don't check gomp_global_icv.bind_var. (initialize_env): Always parse OMP_PLACES and GOMP_CPU_AFFINITY env vars, default to OMP_PROC_BIND=true if OMP_PROC_BIND wasn't specified and either of these variables were parsed correctly into a places list. Modified: trunk/libgomp/ChangeLog trunk/libgomp/config/linux/affinity.c trunk/libgomp/config/linux/proc.c trunk/libgomp/env.c trunk/libgomp/team.c
[Bug libgomp/58691] OpenMP 4: Surprising results with OMP_PLACES=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58691
--- Comment #3 from Jakub Jelinek ---
(In reply to Tobias Burnus from comment #2)
> (Note that that will turn an explicit OMP_PROC_BIND=false into true, which
> looks odd - even if I regard it as unlikely that someone wants to have no
> proc-binding while setting OMP_PLACES or GOMP_CPU_AFFINITY:
>
> OMP_PLACES='FALSE' OMP_PLACES='{0:4}' OMP_DISPLAY_ENV=verbose ./a.out 2>&1
> |grep -E 'OMP_PLACES|OMP_PROC_'
> OMP_PROC_BIND = 'TRUE'
> OMP_PLACES = '{0:4}'
That command line doesn't set explicit OMP_PROC_BIND=false, it sets OMP_PLACES
twice, first time to invalid value, but the latter wins.
If you try
OMP_PROC_BIND='FALSE' OMP_PLACES='{0,4}' OMP_DISPLAY_ENV=verbose ./a.out 2>&1
|grep -E 'OMP_PLACES|OMP_PROC_'
you'll see it will print
OMP_PROC_BIND = 'FALSE'
OMP_PLACES = ''
I'll go ahead and commit the patch.
> In addition, some patch like the following could be used. Side remark:
> OMP_PLACES= is not yet documented in libgomp.texi.
>
> --- a/libgomp/libgomp.texi
> +++ b/libgomp/libgomp.texi
> @@ -1272,3 +1272,4 @@ Specifies whether threads may be moved between
> processors. If set to
> @code{TRUE}, OpenMP theads should not be moved, if set to @code{FALSE}
> -they may be moved. If undefined, threads may move between processors.
> +they may be moved. If undefined, threads may move between processors,
> +unless @code{OMP_PLACES} or @code{GOMP_CPU_AFFINITY} is set.
libgomp.texi needs much more updates for OpenMP 4.0, didn't have time for that
yet (if you have spare cycles, any help with that would be appreciated).
Just saying this when not even mentioning the SPREAD, CLOSE, MASTER (and that
in that case it can be a comma separated list) does not move us much further
though.
[Bug libgomp/58691] OpenMP 4: Surprising results with OMP_PLACES=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58691
--- Comment #2 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #1)
> Looks reasonable, bind-var default value is indeed implementation defined and
> setting it to true by default if OMP_PLACES or GOMP_CPU_AFFINITY has been
> parsed into places list is reasonable. So, how does this look like?
Looks good to me.
(Note that that will turn an explicit OMP_PROC_BIND=false into true, which
looks odd - even if I regard it as unlikely that someone wants to have no
proc-binding while setting OMP_PLACES or GOMP_CPU_AFFINITY:
OMP_PLACES='FALSE' OMP_PLACES='{0:4}' OMP_DISPLAY_ENV=verbose ./a.out 2>&1
|grep -E 'OMP_PLACES|OMP_PROC_'
OMP_PROC_BIND = 'TRUE'
OMP_PLACES = '{0:4}'
)
In addition, some patch like the following could be used. Side remark:
OMP_PLACES= is not yet documented in libgomp.texi.
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -1272,3 +1272,4 @@ Specifies whether threads may be moved between
processors. If set to
@code{TRUE}, OpenMP theads should not be moved, if set to @code{FALSE}
-they may be moved. If undefined, threads may move between processors.
+they may be moved. If undefined, threads may move between processors,
+unless @code{OMP_PLACES} or @code{GOMP_CPU_AFFINITY} is set.
