[Bug tree-optimization/58508] [Missed-Optimization] Redundant vector load of actual loop invariant in loop body.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #4 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Hi, the test case is failing on a i686-pc-linux-gnu. Reason: by default the -msse2 is not enabled. If I add -msse2 to dg_options the test passes. Regards Bernd.
[Bug other/33426] Support of #pragma ivdep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33426 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Sun Oct 27 07:40:31 2013 New Revision: 204102 URL: http://gcc.gnu.org/viewcvs?rev=204102root=gccview=rev Log: 2013-10-27 Tobias Burnus bur...@net-b.de gcc/c/ PR other/33426 * c-parser.c (c_parser_while_statement, * c_parser_while_statement, c_parser_pragma): Add GCC ivdep support to 'do' and 'while'. (c_parser_statement_after_labels): Update calls. gcc/testsuite/ PR other/33426 * gcc.dg/vect/vect-ivdep-2.c: New. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-ivdep-2.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58893] New: [4.8, 4.9 Regression] command-line:0:0: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58893
Bug ID: 58893
Summary: [4.8, 4.9 Regression] command-line:0:0: internal
compiler error: Segmentation fault
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
Came across this strange segfault:
~ % c++ -include ./gcc_hidden.h -include xxx.h -w -march=native
-fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x
-I/usr/include/cairo -pthread -I/usr/include/pango-1.0 -I/usr/include/harfbuzz
-I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/freetype2
-I/usr/include/freetype2 -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer
minimal.cpp
command-line:0:0: internal compiler error: Segmentation fault
gdb shows:
0x00d36791 in linemap_macro_map_lookup(line_maps*, unsigned int) ()
(gdb) bt
#0 0x00d36791 in linemap_macro_map_lookup(line_maps*, unsigned int) ()
#1 0x00d374f5 in linemap_resolve_location(line_maps*, unsigned int,
location_resolution_kind, line_map const**) ()
#2 0x0074f5b6 in diagnostic_report_current_module(diagnostic_context*,
unsigned int) ()
#3 0x004d6c50 in cp_diagnostic_starter(diagnostic_context*,
diagnostic_info*) ()
#4 0x00dfc97b in diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) ()
#5 0x00867319 in c_cpp_error(cpp_reader*, int, int, unsigned int,
unsigned int, char const*, __va_list_tag (*) [1]) ()
#6 0x00753a0f in cpp_diagnostic(cpp_reader*, int, int, char const*,
__va_list_tag (*) [1]) ()
#7 0x00753aa3 in cpp_error(cpp_reader*, int, char const*, ...) ()
#8 0x00e01280 in _cpp_find_file ()
#9 0x00e01d3e in _cpp_stack_include ()
#10 0x0087414f in push_command_line_include() ()
#11 0x00d36306 in _cpp_lex_token ()
#12 0x00d3a655 in cpp_get_token_with_location(cpp_reader*, unsigned
int*) ()
#13 0x008734a1 in c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) ()
#14 0x00d4ea93 in c_parse_file() ()
#15 0x00d67477 in c_common_parse_file() ()
#16 0x00da7003 in compile_file() ()
#17 0x00da7aba in toplev_main(int, char**) ()
#18 0x77772a6e in __libc_start_main () from /lib/libc.so.6
#19 0x00d4117a in _start ()
~ % cat gcc_hidden.h
#pragma GCC visibility push(hidden)
~ % cat minimal.cpp
int main () {}
~ %
And xxx.h doesn't exist.
4.7.3 is fine. 4.8 and 4.9 segfault.
[Bug c++/58893] [4.8, 4.9 Regression] command-line:0:0: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58893 --- Comment #1 from octoploid at yandex dot com --- gcc with debug info shows: command-line:0:0: internal compiler error: Segmentation fault 0x90321f crash_signal ../../gcc/gcc/toplev.c:335 0xd54c15 linemap_macro_map_lookup ../../gcc/libcpp/line-map.c:718 0xd54c15 linemap_lookup(line_maps*, unsigned int) ../../gcc/libcpp/line-map.c:643 0xd54ecc linemap_macro_loc_to_def_point ../../gcc/libcpp/line-map.c:1134 0xd54ecc linemap_resolve_location(line_maps*, unsigned int, location_resolution_kind, line_map const**) ../../gcc/libcpp/line-map.c:1263 0xd3e47d diagnostic_report_current_module(diagnostic_context*, unsigned int) ../../gcc/gcc/diagnostic.c:511 0x5728cd cp_diagnostic_starter ../../gcc/gcc/cp/error.c:3024 0xd3f0c1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/gcc/diagnostic.c:791 0x634b14 c_cpp_error(cpp_reader*, int, int, unsigned int, unsigned int, char const*, __va_list_tag (*) [1]) ../../gcc/gcc/c-family/c-common.c:9607 0xd49148 cpp_diagnostic ../../gcc/libcpp/errors.c:63 0xd49296 cpp_error(cpp_reader*, int, char const*, ...) ../../gcc/libcpp/errors.c:78 0xd4e652 _cpp_find_file ../../gcc/libcpp/files.c:571 0xd4ebed _cpp_stack_include ../../gcc/libcpp/files.c:993 0x6448b5 push_command_line_include ../../gcc/gcc/c-family/c-opts.c:1361 0xd50e25 _cpp_get_fresh_line ../../gcc/libcpp/lex.c:2121 0xd52e86 _cpp_get_fresh_line ../../gcc/libcpp/lex.c:2091 0xd52e86 _cpp_lex_direct ../../gcc/libcpp/lex.c:2168 0xd53d0b _cpp_lex_token ../../gcc/libcpp/lex.c:2042 0xd582f7 cpp_get_token_1 ../../gcc/libcpp/macro.c:2355 0x64250c c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) ../../gcc/gcc/c-family/c-lex.c:300 Please submit a full bug report, Program received signal SIGSEGV, Segmentation fault. [Switching to process 18268] 0x00d54e5f in linemap_resolve_location (set=0x77ff8000, loc=4294959819, lrk=lrk@entry=LRK_MACRO_DEFINITION_LOCATION, map=map@entry=0x7fffd2d8) at ../../gcc/libcpp/line-map.c:1242 1242loc = set-location_adhoc_data_map.data[loc MAX_SOURCE_LOCATION].locus; (gdb) bt #0 0x00d54e5f in linemap_resolve_location (set=0x77ff8000, loc=4294959819, lrk=lrk@entry=LRK_MACRO_DEFINITION_LOCATION, map=map@entry=0x7fffd2d8) at ../../gcc/libcpp/line-map.c:1242 #1 0x00d3e47e in diagnostic_report_current_module (context=context@entry=0x132bca0 global_diagnostic_context, where=optimized out) at ../../gcc/gcc/diagnostic.c:511 #2 0x005728ce in cp_diagnostic_starter (context=0x132bca0 global_diagnostic_context, diagnostic=0x7fffd400) at ../../gcc/gcc/cp/error.c:3024 #3 0x00d3f0c2 in diagnostic_report_diagnostic (context=0x132bca0 global_diagnostic_context, diagnostic=diagnostic@entry=0x7fffd400) at ../../gcc/gcc/diagnostic.c:791 #4 0x00634b15 in c_cpp_error (pfile=pfile@entry=0x13783b0, level=level@entry=6, reason=reason@entry=0, location=optimized out, location@entry=4294959819, column_override=column_override@entry=0, msg=optimized out, ap=ap@entry=0x7fffd4c8) at ../../gcc/gcc/c-family/c-common.c:9607 #5 0x00d49149 in cpp_diagnostic (pfile=0x13783b0, level=6, reason=reason@entry=0, msgid=msgid@entry=0xd9f9dc %s: %s, ap=ap@entry=0x7fffd4c8) at ../../gcc/libcpp/errors.c:63 #6 0x00d49297 in cpp_error (pfile=optimized out, level=optimized out, msgid=msgid@entry=0xd9f9dc %s: %s) at ../../gcc/libcpp/errors.c:78 #7 0x00d4974c in cpp_errno (pfile=optimized out, level=optimized out, msgid=optimized out) at ../../gcc/libcpp/errors.c:236 #8 0x00d4e653 in _cpp_find_file (pfile=pfile@entry=0x13783b0, fname=fname@entry=0x7fffe2e3 xxx.h, start_dir=0x1354970, fake=fake@entry=false, angle_brackets=angle_brackets@entry=0, implicit_preinclude=implicit_preinclude@entry=false) at ../../gcc/libcpp/files.c:571 #9 0x00d4ebee in _cpp_stack_include (pfile=0x13783b0, fname=0x7fffe2e3 xxx.h, angle_brackets=angle_brackets@entry=0, type=type@entry=IT_CMDLINE) at ../../gcc/libcpp/files.c:993 #10 0x00d4f11c in cpp_push_include (pfile=optimized out, fname=optimized out) at ../../gcc/libcpp/files.c:1432 #11 0x006448b6 in push_command_line_include () at ../../gcc/gcc/c-family/c-opts.c:1361 #12 0x00d50e26 in _cpp_get_fresh_line (pfile=pfile@entry=0x13783b0) at ../../gcc/libcpp/lex.c:2121 #13 0x00d52e87 in _cpp_get_fresh_line (pfile=0x13783b0) at ../../gcc/libcpp/lex.c:2091 #14 _cpp_lex_direct (pfile=pfile@entry=0x13783b0) at ../../gcc/libcpp/lex.c:2168 #15 0x00d53d0c in _cpp_lex_token (pfile=0x13783b0) at ../../gcc/libcpp/lex.c:2042 #16 0x00d582f8 in cpp_get_token_1 (pfile=0x13783b0, location=location@entry=0x7fffd928) at ../../gcc/libcpp/macro.c:2355 #17
[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #8 from David Binderman dcb314 at hotmail dot com --- Seems to be newly broken. 20131023 ok, 20131027 not, as follows htslib.c: In function ‘x_escape_http’: htslib.c:3804:7: internal compiler error: in operator[], at vec.h:827 0xb8fa27 vecoperand_entry*, va_heap, vl_embed::operator[](unsigned int) ../../src/trunk/gcc/vec.h:827 0xb91572 vecoperand_entry*, va_heap, vl_embed::operator[](unsigned int) ../../src/trunk/gcc/tree.h:2792 0xb91572 vecoperand_entry*, va_heap, vl_ptr::operator[](unsigned int) ../../src/trunk/gcc/vec.h:1256 0xb91572 update_ops ../../src/trunk/gcc/tree-ssa-reassoc.c:2619 0xbf maybe_optimize_range_tests ../../src/trunk/gcc/tree-ssa-reassoc.c:2907 0xbf reassociate_bb ../../src/trunk/gcc/tree-ssa-reassoc.c:4325 0xb98eb7 reassociate_bb ../../src/trunk/gcc/tree-ssa-reassoc.c:4482 0xb9b7ab do_reassoc ../../src/trunk/gcc/tree-ssa-reassoc.c:4515 0xb9b7ab execute_reassoc ../../src/trunk/gcc/tree-ssa-reassoc.c:4597 0xb9b7ab execute ../../src/trunk/gcc/tree-ssa-reassoc.c:4639 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/52933] SH Target: Use div0s for integer sign comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52933
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
The div0s insn can also be used to do floating point sign comparisons. For
example:
bool test3 (float x, float y)
{
return __builtin_signbitf (x) ^ __builtin_signbitf (y);
}
currently compiles to:
fldsfr4,fpul
sts fpul,r2
fldsfr5,fpul
sts fpul,r3
mov.l .L7,r1
and r1,r2
and r3,r1
cmp/eq r1,r2
movtr0
rts
xor #1,r0
.L8:
.align 2
.L7:
.long -2147483648
better:
fldsfr4,fpul
sts fpul,r2
fldsfr5,fpul
sts fpul,r3
div0s r2,r3
rts
movtr0
The same goes for negated result value of the sign comparison:
bool test3_1 (float x, float y)
{
return !(__builtin_signbitf (x) ^ __builtin_signbitf (y));
}
Currently compiles to:
fldsfr4,fpul
sts fpul,r2
fldsfr5,fpul
sts fpul,r3
mov.l .L11,r1
and r1,r2
and r3,r1
cmp/eq r1,r2
rts
movtr0
.L12:
.align 2
.L11:
.long -2147483648
better:
fldsfr4,fpul
sts fpul,r2
fldsfr5,fpul
sts fpul,r3
div0s r2,r3
mov #-1,r0// on SH2A should use movrt
rts
negcr0,r0
[Bug c++/58894] New: C++11 lambda doesn't take const variable by reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58894
Bug ID: 58894
Summary: C++11 lambda doesn't take const variable by reference
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: abyss.7 at gmail dot com
Trying to compile this code:
===
const int a = 1;
auto lambda = []() {
a;
};
lambda();
===
g++ gives error: lvalue required as unary ‘’ operand
[Bug target/58895] New: [SH] improve handling of signbit result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58895
Bug ID: 58895
Summary: [SH] improve handling of signbit result
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The handling of the result of the floating point signbit functions could be
improved in the following cases.
#include cmath
bool test0_OK (float x)
{
return !std::signbit (x);
}
-m4-single -m4 -O2:
fldsfr4,fpul
sts fpul,r1
cmp/pz r1
rts
movtr0
--
bool test1_NG (float x)
{
return std::signbit (x);
}
-m4-single -m4 -O2:
fldsfr4,fpul
sts fpul,r1
cmp/pz r1
movtr0
rts
xor #1,r0
better:
fldsfr4,fpul
sts fpul,r1
shllr1
rts
movtr1,r0
--
void test2_OK (float x, int* y)
{
y[0] = !std::signbit (x);
}
-m4-single -m4 -O2:
fldsfr4,fpul
sts fpul,r1
cmp/pz r1
movtr1
rts
mov.l r1,@r4
--
void test3_NG (float x, int* y)
{
// c++11 std::signbit returns a bool
y[0] = std::signbit (x);
}
-m4-single -m4 -O2:
fldsfr4,fpul
sts fpul,r1
cmp/pz r1
mov #-1,r1
negcr1,r1
rts
mov.l r1,@r4
better:
fldsfr4,fpul
sts fpul,r2
shllr2
movtr1
rts
mov.l r1,@r4
--
void test4_NG (float x, int* y)
{
// c99 signbit macro and corresponding built-in return
// zero or non-zero integer, i.e. MSB of x.
y[0] = __builtin_signbitf (x);
}
-m4-single -m4 -O2:
fldsfr4,fpul
sts fpul,r2
mov.l .L7,r1
and r2,r1
rts
mov.l r1,@r4
.L8:
.align 2
.L7:
.long-2147483648
possible alternative without 32 bit constant.
smaller size, but probably slower.
fldsfr4,fpul
sts fpul,r2
shllr2
movtr1
rotcr r1
rts
mov.l r1,@r4
[Bug ada/58891] Bug box when using limited with, between parent and child packages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58891 --- Comment #2 from Luke A. Guest laguest at archeia dot com --- Discovered that this is incorrect code as I can only access types in a limited with. But the compiler should still produce an error not a bug box.
[Bug ada/58891] Bug box when using limited with, between parent and child packages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58891 Luke A. Guest laguest at archeia dot com changed: What|Removed |Added Severity|blocker |enhancement --- Comment #3 from Luke A. Guest laguest at archeia dot com --- Enhancement request.
[Bug c++/58894] C++11 lambda doesn't take const variable by reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58894
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com ---
The code - as written - is invalid. Here is a valid form of this:
//-
int main() {
const int a = 1;
auto lambda = []() {
a;
};
lambda();
}
//--
It still produces the mentioned diagnostics even in gcc 4.9.0 20131026
(experimental). It doesn't seem to be a regression, I can track it down back to
gcc 4.5.4
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #27 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 31097 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31097action=edit Patch to add -Wfloat-conversion option against trunk with new testcase and detailed warnings This uses a detailed warnings in the testcase. I am not sure if this is a good idea or not since it might get invalidated if the types change. It bootstraps and the new testcase works on x86_64-unknown-linux-gnu
[Bug preprocessor/58887] Allow recursion in varadic macros?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887 --- Comment #2 from Max TenEyck Woodbury mtewoodbury at gmail dot com --- Eventually, that is where this will go, but the committee is MUCH more receptive of suggestions that have an implementation that people have had a chance to play with. GCC is one of the platforms where new ideas get tested. So, I believe it needs to be considered here. While I have not had news group access in recent years, I did watch and made comments on the committee's action for more than a decade and it is implemented extensions that get taken most seriously.
[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687 --- Comment #6 from Max TenEyck Woodbury mtewoodbury at gmail dot com --- (In reply to Andrew Pinski from comment #5) Simply to make identification host independent. The fact that my projects are stored on '/VOL10' on one of my machines and '/DATA0.2' This sounds like a bug in how you are compiling the sources. Also there are options inside GDB to transpose paths to the path on your machine. It is precisely because the identification varies with the way to file name is passed to the compiler that makes setting __FILE__ desirable. The compiler invocation details are not always under the developer's control. Tools like 'make', 'autoconf' and 'automake' dictate the forms. So, I have fairly strong objections to calling it an external procedural BUG. The issue REALLY is that __LINE__ gets messed up; leave discussions of how the compiler is invoked out of it.
[Bug c++/58894] C++11 lambda doesn't take const variable by reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58894 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-27 Blocks||54367 Ever confirmed|0 |1
[Bug preprocessor/58887] Allow recursion in variadic macros?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- We take the view that the preprocessor is deliberately meant to be limited and overly complicated features in it would be contrary to the spirit of C. Of course if they are introduced in the standard we need to implement them, but otherwise this proposed feature seems inappropriate.
[Bug c++/58868] [4.9 Regression] ICE: in count_type_elements, at expr.c:5495 with -std=gnu++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58868
Trevor Saunders tsaunders at mozilla dot com changed:
What|Removed |Added
CC||tsaunders at mozilla dot com
--- Comment #4 from Trevor Saunders tsaunders at mozilla dot com ---
enum ID {
PLACES
};
struct Histograms {
const ID foo;
the enum isn't actually needed, I can reproduce with
static struct {
const int type;
} const cnvNameType[] = {
{ 1 }
};
Fairly recent, comes from building firefox aurora with gcc trunk
to be pedantic it is in icu, and presumably if you just build that you get this
crash too.
[Bug c++/58896] New: Incorrect handling of a private nested type of a template specialization in the main template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58896
Bug ID: 58896
Summary: Incorrect handling of a private nested type of a
template specialization in the main 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
This code compiles without any problem:
templatetypename class Obj;
template class Objvoid {
struct secret{};
};
templatetypename T class Obj {
Objvoid::secret m;
};
int main()
{
Objint obj;
}
It's as if the main template somehow manages to be a friend of its
specialization. When the nested name is a typedef, it's diagnosed:
templatetypename class Obj;
template class Objvoid {
typedef int secret;
};
templatetypename T class Obj {
Objvoid::secret m;
};
int main()
{
Objint obj;
}
This results in
edoceo.cpp: In instantiation of ‘class Objint’:
edoceo.cpp:11:12: required from here
edoceo.cpp:3:15: error: ‘typedef int Objvoid::secret’ is private
typedef int secret;
^
edoceo.cpp:6:14: error: within this context
Objvoid::secret m;
^
[Bug target/58792] [4.9 Regression] ICE at mode-switching.c:421 when compiling clang lib/AST/MicrosoftCXXABI.cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58792 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #9) libstdc++-v3/libsupc++/eh_terminate.cc: In function ‘void (* std::set_terminate(std::terminate_handler))()’: libstdc++-v3/libsupc++/eh_terminate.cc:85:1: internal compiler error: in create_pre_exit, at mode-switching.c:422 If this is with today's compiler, then this is PR58679. Fixed by revert [1] and actually a duplicate of PR58679. [1]http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02237.html *** This bug has been marked as a duplicate of bug 58679 ***
[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||mustrumr97 at gmail dot com --- Comment #13 from Uroš Bizjak ubizjak at gmail dot com --- *** Bug 58792 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679 --- Comment #14 from uros at gcc dot gnu.org --- Author: uros Date: Sun Oct 27 20:32:29 2013 New Revision: 204109 URL: http://gcc.gnu.org/viewcvs?rev=204109root=gccview=rev Log: PR target/58679 * gcc.target/i386/pr58679-1.c: New test. * gcc.target/i386/pr58679-2.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/i386/pr58679-1.c trunk/gcc/testsuite/gcc.target/i386/pr58679-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/58679] [4.9 regression] ICE in create_pre_exit, at mode-switching.c:421 with -mavx after r202915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58679 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Uroš Bizjak ubizjak at gmail dot com --- Fixed by the revert. The first problem, reported in Comment #0 was actually due to missing registers in ix86_function_value_regno_p, so multi-register output was not properly detected. This problem was fixed by [1]. The second problem was indeed due to missing output value copy, where the copy insn was removed as useless move insn. This problem was fixed by a revert. I have committed a couple of testcases that cover both issues. [1] http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01606.html
[Bug target/58897] New: Improve 128/64 division
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58897
Bug ID: 58897
Summary: Improve 128/64 division
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: x86_64-linux-gnu
typedef unsigned __int128 ui;
ui f(ui a, unsigned long b){
return a/b;
}
is compiled to a library call to __udivti3, which is implemented as a rather
long loop. However, it seems to me that 2 calls to divq should do it (and
sometimes only 1 if we have range information on the result).
Ideally the following would eventually compile to just mul+div, but that's
probably too complicated for now.
unsigned long prod(unsigned long a, unsigned long b, unsigned long m){
if (a = m || b = m) __builtin_unreachable ();
return ((unsigned __int128) a * b) % m;
}
[Bug preprocessor/58887] Allow recursion in variadic macros?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887 --- Comment #4 from Max TenEyck Woodbury mtewoodbury at gmail dot com --- (In reply to jos...@codesourcery.com from comment #3) We take the view that the preprocessor is deliberately meant to be limited and overly complicated features in it would be contrary to the spirit of C. Of course if they are introduced in the standard we need to implement them, but otherwise this proposed feature seems inappropriate. That has not always stopped you all in the past, but that is really neither here nor there and you use the royal 'we' to boot... Speak for yourself. (ignore that; I'm in a sour mood and you just pushed one of my hot buttons.) Where option 1 may be a little complicated to implement, option 2, while less effective, is a real simple addition: define __VA_ARG_COUNT__ (or maybe __VA_ARGC__) with the same kind of restrictions that apply to __VA_ARGS__. See also Bug 33877.
[Bug preprocessor/58887] Allow recursion in variadic macros?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887 --- Comment #5 from Max TenEyck Woodbury mtewoodbury at gmail dot com --- (In reply to jos...@codesourcery.com from comment #3) We take the view that the preprocessor is deliberately meant to be limited and overly complicated features in it would be contrary to the spirit of C. Of course if they are introduced in the standard we need to implement them, but otherwise this proposed feature seems inappropriate. That has not always stopped you all in the past, but that is really neither here nor there and you use the royal 'we' to boot... Speak for yourself. (ignore that; I'm in a sour mood and you just pushed one of my hot buttons.) Where option 1 may be a little complicated to implement, option 2, while less effective, is a real simple addition: define __VA_ARG_COUNT__ (or maybe __VA_ARGC__) with the same kind of restrictions that apply to __VA_ARGS__. See also Bug 33877.
[Bug target/58623] lack of ldp/stp optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58623 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-28 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Confirmed.
[Bug c++/58898] New: Adding default template argument causes to class template compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58898
Bug ID: 58898
Summary: Adding default template argument causes to class
template compile error
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: evgeny.panasyuk at gmail dot com
Following code fails to compile on GCC 4.8.1, but compiles OK and Clang 3.4 and
MSVC2010.
Live demo: http://coliru.stacked-crooked.com/a/5fa616a7f18e2485
/***/
template typename = int
struct Foo
{
Foo()
{
int t(int()); // Error
}
};
int main()
{
int t(int()); // OK
Foo a; // Error
}
/***/
main.cpp: In constructor 'Foo template-parameter-1-1 ::Foo()':
main.cpp:6:20: error: default argument for template parameter for class
enclosing 'int t(int (*)())'
int t(int()); // Error
^
main.cpp: In function 'int main()':
main.cpp:13:9: error: wrong number of template arguments (0, should be 1)
Foo a; // Error
^
main.cpp:2:8: error: provided for 'templateclass struct Foo'
struct Foo
^
main.cpp:13:12: error: invalid type in declaration before ';' token
Foo a; // Error
^
/***/
But following code compiles OK.
Live demo: http://coliru.stacked-crooked.com/a/3e6c7f85f2ee5615
template typename
struct Foo
{
Foo()
{
int t(int()); // OK
}
};
int main()
{
int t(int()); // OK
Fooint a; // OK
}
/***/
Original case was in StackOverflow Question:
http://stackoverflow.com/questions/19625314/inheriting-from-a-class-template-with-a-default-argument/19625343#19625343
[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect Vectorizing an unaligned access 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56865 --- Comment #8 from Bill Schmidt wschmidt at gcc dot gnu.org --- vect-96.c is still broken per http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02115.html. FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect Vectorizing an unaligned access 1 FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect Alignment of access forced using peeling 1
[Bug c++/58899] New: g++ seg faulted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58899 Bug ID: 58899 Summary: g++ seg faulted Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jsligh at umich dot edu Created attachment 31098 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31098action=edit The code I was compiling when g++ seg faulted. Just compiling my program for an undergrad computer science course when I get the following error message: g++: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Wasn't a problem until I compressed my code into a tar file (uploaded).
[Bug other/58900] New: parsing bug: undefined reference for libraries, specified before source files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58900
Bug ID: 58900
Summary: parsing bug: undefined reference for libraries,
specified before source files
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: nick87720z at gmail dot com
Just an example. I have simple hand-written makefile, which builds executable
with one line. These commands will fail:
$ gcc ${common_flags} ${GTK_FLAGS} -o file_loader file_loader.c
file_loader_callbacks.c
$ gcc -o file_loader ${common_flags} ${GTK_FLAGS} file_loader.c
file_loader_callbacks.c
And only this works:
$ gcc -o file_loader file_loader.c file_loader_callbacks.c ${common_flags}
${GTK_FLAGS}
Strongest trick is that it breaks automatic rules from working (when you just
specify standard things like CC,CFLAGS,LDFLAGS and specify targets with
requirements, not specifying exact commands for each target).
Versions.
OS - ubuntu 12.04. Specified version is gcc-4.8 (Ubuntu 4.8.1-2ubuntu1~12.04)
4.8.1. But it also happens with
* gcc-4.6 (Ubuntu/Linaro 4.6.4-1ubuntu1~12.04) 4.6.4
* gcc-4.7 (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3 (this i have set default
for now)
[Bug other/58900] parsing bug: undefined reference for libraries, specified before source files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58900
--- Comment #1 from nick87720z at gmail dot com ---
Posting exact makefile, which leads to this error:
/ Makefile ===\
include_flags = ../misc
common_flags = -O0 -g3 -ggdb3 -std=gnu99 -I${include_flags}
CFLAGS = ${common_flags} `pkg-config --cflags gtk+-2.0`
LDFLAGS = ${common_flags} `pkg-config --libs gtk+-2.0`
all: file_loader
file_loader: file_loader.c file_loader_callbacks.c
\ Makefile ===/
$ make
cc -O0 -g3 -ggdb3 -std=gnu99 -I `pkg-config --cflags gtk+-2.0` -O0 -g3 -ggdb3
-std=gnu99 -I `pkg-config --libs gtk+-2.0` file_loader.c
file_loader_callbacks.c -o file_loader
/tmp/cchQVCEN.o: In function `setup_menu':
/home/nick87720z/dev/lfhde/file_loader.c:15: undefined reference to
`gtk_menu_shell_get_type'
/home/nick87720z/dev/lfhde/file_loader.c:15: undefined reference to
`gtk_menu_bar_new'
/home/nick87720z/dev/lfhde/file_loader.c:15: undefined reference to
`g_type_check_instance_cast'
everything from
gtk2-related stuff
[Bug other/58900] parsing bug: undefined reference for libraries, specified before source files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58900 --- Comment #2 from nick87720z at gmail dot com --- Changing file_loader dependencies to object files doesn't solve problem. After two successful compilation commands final gcc command, linking executable, gives same error.
