[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51654 Mathias Gaunard changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Mathias Gaunard --- Works with 8.3, was apparently fixed at some point.
[Bug c++/90489] Attributes no longer allowed in lambdas with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90489
--- Comment #1 from Mathias Gaunard ---
Possibly related,
Both
auto const f = [](int) [[gnu::always_inline]] -> int { return 0; };
and
auto const f = [](int) [[gnu::always_inline]] { return 0; };
also fail with GCC 9.1, but work with GCC 8.2.
says:
:1:50: warning: attribute ignored [-Wattributes]
1 | auto const f = [](int) [[gnu::always_inline]] -> int { return 0; };
| ^~~
:1:50: note: an attribute that appertains to a type-specifier is
ignored
[Bug c++/90489] New: Attributes no longer allowed in lambdas with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90489
Bug ID: 90489
Summary: Attributes no longer allowed in lambdas with trailing
return type
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mathias at gaunard dot com
Target Milestone: ---
As of GCC 8.2, the following code is well-formed:
auto const f = [](int) __attribute__((always_inline)) -> int { return 0; };
With GCC 9.1, it fails to compile.
Note however that the following remains valid:
auto const f = [](int) __attribute__((always_inline)) { return 0; };
So it looks like there is some bad interaction in the parsing between
attributes and the late return type.
[Bug c++/80667] New: [c++1z] ice segfault on partial specialization with non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80667
Bug ID: 80667
Summary: [c++1z] ice segfault on partial specialization with
non-type template parameter
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mathias at gaunard dot com
Target Milestone: ---
Building the following code with std=c++1z
#include
template
struct traits
{
static constexpr T const_min = 0;
};
template
class Impl;
template
struct Impl<T, std::integral_constant<T, MaxValue>>
{
};
template
struct Impl<T, std::integral_constant<T, traits::const_min>>
{
};
Impl> foo()
{
return {};
}
gives
test.cpp: In function ‘Impl > foo()’:
test.cpp:22:67: internal compiler error: Segmentation fault
Impl> foo()
^
0xb118ef crash_signal
../../gcc-src/gcc/toplev.c:337
0x61b925 unify
../../gcc-src/gcc/cp/pt.c:20292
0x61c8d1 unify
../../gcc-src/gcc/cp/pt.c:20573
0x61c319 unify
../../gcc-src/gcc/cp/pt.c:20764
0x61c4d7 unify
../../gcc-src/gcc/cp/pt.c:20843
0x61c319 unify
../../gcc-src/gcc/cp/pt.c:20764
0x61d971 get_partial_spec_bindings
../../gcc-src/gcc/cp/pt.c:21561
0x61db83 more_specialized_partial_spec
../../gcc-src/gcc/cp/pt.c:21436
0x61ddd9 most_specialized_partial_spec
../../gcc-src/gcc/cp/pt.c:21856
0x62e66b instantiate_class_template_1
../../gcc-src/gcc/cp/pt.c:10230
0x62e66b instantiate_class_template(tree_node*)
../../gcc-src/gcc/cp/pt.c:10798
0x691e75 complete_type(tree_node*)
../../gcc-src/gcc/cp/typeck.c:133
0x5ecffc check_function_type
../../gcc-src/gcc/cp/decl.c:14662
0x5ecffc start_preparsed_function(tree_node*, tree_node*, int)
../../gcc-src/gcc/cp/decl.c:14883
0x6000f3 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../gcc-src/gcc/cp/decl.c:15199
0x686c97 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-src/gcc/cp/parser.c:26129
0x686c97 cp_parser_init_declarator
../../gcc-src/gcc/cp/parser.c:19159
0x68796d cp_parser_simple_declaration
../../gcc-src/gcc/cp/parser.c:12777
0x688575 cp_parser_block_declaration
../../gcc-src/gcc/cp/parser.c:12602
0x666ec4 cp_parser_declaration
../../gcc-src/gcc/cp/parser.c:12500
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Works fine without std=c++1z, alternatively a workaround is to add a cast in
the second partial specialization.
[Bug c++/80642] New: lambdas made constexpr in cases where they don't satisfy the requirements for it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80642
Bug ID: 80642
Summary: lambdas made constexpr in cases where they don't
satisfy the requirements for it
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mathias at gaunard dot com
Target Milestone: ---
Since C++17, lambdas are automatically constexpr whenever they can.
It seems however that GCC 7.1 tries to make lambdas constexpr in cases where it
actually can not.
Testcase, built with -std=c++1z
#include
int main()
{
[](auto&& i)
{
if(i)
{
std::array<char, 4> array;
return i + array.size();
}
return i;
}(std::size_t(0));
}
Expected behaviour: everything compiles fine
What I get instead:
test.cpp: In instantiation of ‘main()::<lambda(auto:1&&)> [with auto:1 = long
unsigned int]’:
test.cpp:13:21: required from here
test.cpp:9:33: error: uninitialized variable ‘array’ in ‘constexpr’ function
std::array<char, 4> array;
^
In file included from test.cpp:1:0:
/usr/local/gcc-7.1.0/include/c++/7.1.0/array:94:12: note: ‘struct
std::array<char, 4>’ has no user-provided default constructor
struct array
^
/usr/local/gcc-7.1.0/include/c++/7.1.0/array:110:56: note: and the
implicitly-defined constructor does not initialize ‘char std::array<char,
4>::_M_elems [4]’
typename _AT_Type::_Type _M_elems;
^~~~
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525 --- Comment #18 from Mathias Gaunard mathias at gaunard dot com --- I'm not competent enough to make my own builds of GCC with patches, and I unfortunately do not have much time to contribute to this either. If someone can give me binaries for debian x86-64 I can do some tests though.
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 --- Comment #11 from Mathias Gaunard mathias at gaunard dot com --- 4.8.1 is still affected by this. I wouldn't say it's NOTABUG if a new diagnostic feature enabled by default increases memory consumption by 50%, even when no diagnostic is emitted. I cannot easily give a test case; the problem being preprocessor-related, the issues disappear once preprocessed. The code incriminated includes hundreds of files (if not more), split in about 20 different include directories. Those files contain templates instantiated hundreds of times each, and their body is generated by macros which may end up creating lines that are thousands of characters long.
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 --- Comment #12 from Mathias Gaunard mathias at gaunard dot com --- This may be considered a duplicate of #53525, though that bug is more focused on performance than memory usage.
[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525 Mathias Gaunard mathias at gaunard dot com changed: What|Removed |Added CC||mathias at gaunard dot com --- Comment #16 from Mathias Gaunard mathias at gaunard dot com --- I opened bug #56746 a while ago which is somewhat related to this. ftrack-macro-expansion is causing 50% increased memory usage in my case (C++ code with heavy usage of macros and templates). Please also consider memory usage and not just performance.
[Bug target/57057] New: Bad optimization on x86 for minps and maxps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57057 Bug #: 57057 Summary: Bad optimization on x86 for minps and maxps Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@gaunard.com When optimization -O1 or greater is enabled, minps and maxps will incorrectly deal with nan values. icc gives the correct result. See the attached C testcase, with -O0 it displays the correct result: res1 = (1.00 1.00 1.00 1.00) res2 = (-nan -nan -nan -nan) res3 = (1.00 1.00 1.00 1.00) res4 = (-nan -nan -nan -nan) With -O1 it displays res1 = (1.00 1.00 1.00 1.00) res2 = (1.00 1.00 1.00 1.00) res3 = (-nan -nan -nan -nan) res4 = (-nan -nan -nan -nan) The same also happens with the double-precision and AVX variants.
[Bug target/57057] Bad optimization on x86 for minps and maxps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57057 --- Comment #1 from Mathias Gaunard mathias at gaunard dot com 2013-04-24 16:42:23 UTC --- Created attachment 29931 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29931 bad optimisation testcase
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 --- Comment #7 from Mathias Gaunard mathias at gaunard dot com 2013-03-28 10:39:53 UTC --- Using either -save-temps or -ftrack-macro-expansion=0-ftrack-macro-expansion=0 removes the memory hog. Compiling the preprocessed source does not cause increased memory usage. So it seems the macro expansion tracking is what's causing a lot of extra memory usage here.
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 --- Comment #2 from Mathias Gaunard mathias at gaunard dot com 2013-03-27 11:04:08 UTC --- The preprocessed file is 7 megabytes, which exceeds what I can attach here. I do not think it is practical to reduce it with automatic tools. Would it be ok to provide it as-is? The flags used are -fno-strict-aliasing -Wall -Wno-unused -Wno-delete-non-virtual-dtor -mxop -fabi-version=4 -O2.-O2
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 --- Comment #5 from Mathias Gaunard mathias at gaunard dot com 2013-03-27 16:41:16 UTC --- While trying to isolate the problem, I have observed that the problem does not occur if -save-temps is used. While using -save-temps does not change anything with GCC 4.7, using it does reduce memory usage significantly with GCC 4.8. Did something change with regards to the way temporary files are handled?
[Bug c++/56746] New: 4.8 regression: increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 Bug #: 56746 Summary: 4.8 regression: increased memory usage when compiling C++ Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@gaunard.com On my C++ project I have observed significant increased memory usage between GCC 4.6/4.7 and 4.8. Unfortunately I do not have a testcase, but compiling the test core.utility.functions.whereij.unit of my template-heavy project NT2 (https://github.com/MetaScale/nt2) gives the following results: g++-4.7 User time (seconds): 155.76 System time (seconds): 4.62 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 2:40.58 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 2781396 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 121 Minor (reclaiming a frame) page faults: 726987 Voluntary context switches: 288 Involuntary context switches: 547 Swaps: 0 File system inputs: 31104 File system outputs: 15320 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 g++-4.8 User time (seconds): 155.13 System time (seconds): 6.50 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 2:41.68 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 3972292 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 1048923 Voluntary context switches: 11 Involuntary context switches: 576 Swaps: 0 File system inputs: 0 File system outputs: 12368 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 So it goes from 2.65GB to 3.79GB. Details of the versions used below. $ g++-4.7 -v Using built-in specs. COLLECT_GCC=g++-4.7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) $ g++-4.8 -v Using built-in specs. COLLECT_GCC=g++-4.8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.0-1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.0 (Debian 4.8.0-1)
[Bug target/55184] [4.6 Regression] Invalid codegen with vectors and casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55184 Mathias Gaunard mathias at gaunard dot com changed: What|Removed |Added Attachment #28600|0 |1 is obsolete|| --- Comment #3 from Mathias Gaunard mathias at gaunard dot com 2012-11-04 17:58:30 UTC --- Created attachment 28614 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28614 Fixed testcase
[Bug target/55184] [4.6 Regression] Invalid codegen with vectors and casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55184 --- Comment #4 from Mathias Gaunard mathias at gaunard dot com 2012-11-04 18:01:27 UTC --- Sorry, I edited the file in between and ended up uploading the wrong test case. Below is the result on my machine with the fixed testcase. $ gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -dumpmachine x86_64-linux-gnu $ gcc test.c -o test ./test 1 (should be 1) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 1 (should be 1) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) $ gcc -O1 test.c -o test ./test 1 (should be 1) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 1) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0)
[Bug target/55184] New: Invalid codegen with vectors and casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55184 Bug #: 55184 Summary: Invalid codegen with vectors and casts Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@gaunard.com Created attachment 28600 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28600 Testcase On x86-64, when 128-bit vectors of long or unsigned long are aliased, an invalid optimization seems to occur and causes only the first element of the vector to be modified. Output is correct when compiled without optimization, but fails with -O1 or greater. Usage of -fno-strict-aliasing doesn't change anything. The problem doesn't seem to appear in the 4.4, 4.5 and 4.7 series. Nevertheless I'd like to know all the cases it affects and whether there is a workaround.
[Bug target/55184] [4.6 Regression] Invalid codegen with vectors and casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55184 --- Comment #1 from Mathias Gaunard mathias at gaunard dot com 2012-11-03 00:29:47 UTC --- Problem seems to occur with i686 as well but only if SSE2 is enabled (you'll need to replace 'long' by 'long long' for this in the testcase)
[Bug other/54436] New: Compiling some regular C++ code gives assembler '700415 shortened to 255' warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54436 Bug #: 54436 Summary: Compiling some regular C++ code gives assembler '700415 shortened to 255' warning Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@gaunard.com Created attachment 28110 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28110 automatically reduced testcase When I compile the attached C++ code with GCC 4.7 and GNU as 2.22 with -O1, I get the following message: $ g++ -O1 -c reversebits.ii /tmp/cchfvrG0.s: Assembler messages: /tmp/cchfvrG0.s:40: Warning: 700415 shortened to 255 I do not think it is normal that GCC does not report any problem while the assembler does. The attached testcase was unfortunately automatically reduced from a large code base, so it isn't very readable. Sorry about that. I also do not know what is the right component, so putting in 'other' for now.
[Bug target/54436] [4.7/4.8 Regression] Compiling some regular C++ code gives assembler '700415 shortened to 255' warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54436 --- Comment #3 from Mathias Gaunard mathias at gaunard dot com 2012-09-01 01:23:04 UTC --- While a warning is emitted, is the code in the end still valid or is that a miscompilation?
[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800 --- Comment #6 from Mathias Gaunard mathias at gaunard dot com 2012-08-14 10:53:07 UTC --- I've had this happen with 4.7.1 without any may_alias involved. Why is this bug still marked 'waiting'? Are more testcases necessary?
[Bug target/51654] New: C++ preprocessor bug with -maltivec and typedefs involving 'vector'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51654
Bug #: 51654
Summary: C++ preprocessor bug with -maltivec and typedefs
involving 'vector'
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: math...@gaunard.com
The following C++ code
templateclass T
struct test
{
typedef T::vector vector;
};
when preprocessed using the following command
g++ -maltivec -E test.cpp
generates the following output:
templateclass T
struct test
{
typedef T::vector;
};
Expected output should be the file unchanged.
In particular, this prevents from using significant parts of the Boost C++
libraries with AltiVec enabled.
I'm not sure which is the best place to affect this bug (c++, preprocessor,
target), feel free to move it.
Affecting to target because it seems similar to bug #39558.
[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51654
--- Comment #1 from Mathias Gaunard mathias at gaunard dot com 2011-12-22
15:16:18 UTC ---
Excuse the typo, the above code should have been
templateclass T
struct test
{
typedef typename T::vector vector;
};
to be valid C++ code.
The vector bit is incorrectly removed in both cases though.
[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51654 --- Comment #3 from Mathias Gaunard mathias at gaunard dot com 2011-12-22 15:54:20 UTC --- The workarounds #undef vector or compiling with -Dvector=vector seem to work. But shouldn't this not be necessary when altivec.h is not included?
[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51654 --- Comment #5 from Mathias Gaunard mathias at gaunard dot com 2011-12-22 18:48:36 UTC --- gaunard@emeria:~$ g++-4.6 -v Using built-in specs. COLLECT_GCC=g++-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-linux-gnu/4.6.0/lto-wrapper Target: powerpc-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6-20101220-1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --enable-secureplt --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu Thread model: posix gcc version 4.6.0 20101220 (experimental) [trunk revision 168097] (Ubuntu/Linaro 4.6-20101220-1)
[Bug target/50396] SSE division by zero generates incorrect code with optimizations enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50396 --- Comment #1 from Mathias Gaunard mathias at gaunard dot com 2011-10-20 08:58:19 UTC --- This bug has stayed as unconfirmed for a while. Is there anything that I could do to help?
[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800 --- Comment #3 from Mathias Gaunard mathias at gaunard dot com 2011-10-20 20:07:24 UTC --- Created attachment 25562 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25562 Reduced testcase Original testcase reduced using automated delta tools
[Bug c++/50800] New: Internal compiler error in finish_member_declarations, possibly related to may_alias attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800 Bug #: 50800 Summary: Internal compiler error in finish_member_declarations, possibly related to may_alias attribute Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@gaunard.com The attached preprocessed testcase results in an internal compiler error: /home/gaunard/dev/boost/trunk/boost/type_traits/detail/cv_traits_impl.hpp:36:1: internal compiler error: in finish_member_declaration, at cp/semantics.c:2559 This seems to be tied to the use of the may_alias attribute.
[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800 --- Comment #1 from Mathias Gaunard mathias at gaunard dot com 2011-10-19 18:20:06 UTC --- Testcase is here (couldn't attach it due to bugzilla size restrictions): http://mathias.gaunard.com/data/ice_finish_member_declaration.cpp
[Bug c++/50495] New: Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495
Bug #: 50495
Summary: Optimize exact matches in overload resolution
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: math...@gaunard.com
Overload resolution in GCC (and in C++ in general) is quite slow, and I would
like to suggest the following enhancement: look-up (in constant or logarithmic
time) for exact matches first, then perform regular overload resolution if
necessary.
The idea is that
struct id_0 {};
void f(id_0);
struct id_1;
void f(id_1) {};
...
and then calling
f(id_x());
should be as fast as
void f_0();
void f_1();
...
and then calling
f_x();
Now if this could be made to work for things like
struct h0 {};
struct h1 : h0 {};
struct id_0 {};
templateclass T void f(id_0, h0T);
templateclass T void f(id_0, h1T);
to reduce the set of possible overloads to 2 early (templates inserted to make
it non-absolutely orderable), that would be perfect.
According to my benchmarks, resolving a function with an exact match on the
first argument among 1,000 tags with 10 overloads each takes 30s, while with
1,000 differently named functions of 10 overloads each it takes 100ms.
[Bug c++/50495] Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495 --- Comment #2 from Mathias Gaunard mathias at gaunard dot com 2011-09-23 15:46:50 UTC --- Would you happen to have a reference to those changes or discussed improvements? I'm not testing with a very recent GCC.
[Bug c++/50495] Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495 --- Comment #5 from Mathias Gaunard mathias at gaunard dot com 2011-09-23 16:38:11 UTC --- clang was already 50% faster in my tests, so I guess that will put gcc 4.7 on par with it.
[Bug c++/50495] Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495 --- Comment #7 from Mathias Gaunard mathias at gaunard dot com 2011-09-23 17:56:48 UTC --- Created attachment 25349 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25349 Python script to generate C++ files with many overloads Syntax is ./generate.py [use single function for everything (1 or 0)] [number of function tags] [number of overloads per function tag] [inheritance depth for the arguments (must be higher than number of overloads per function tag)] [arity of the functions]
[Bug c++/50495] Optimize exact matches in overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50495 --- Comment #8 from Mathias Gaunard mathias at gaunard dot com 2011-09-23 17:58:41 UTC --- Created attachment 25350 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25350 Bash script to more easily drive python script Same usage as generate.py, but doesn't take the first argument
[Bug target/50396] New: SSE division by zero generates incorrect code with optimizations enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50396 Bug #: 50396 Summary: SSE division by zero generates incorrect code with optimizations enabled Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@gaunard.com Created attachment 25273 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25273 divide by zero example The attached C code, written using SSE intrinsics, prints -nan when no optimizations are used (as expected) and 0 otherwise. It seems constant folding of the divps instruction doesn't do the right thing. It works correctly when the first argument is non-zero though (including minus zero).
