[Bug fortran/57711] Fortran 4.7.2/4.8.1 error: constraints for functions parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- First, you have a *serious* bug in JAC/DUMMY_JAC: Namely, in DUMMY_JAC you have: double precision, intent(inout) :: RPAR(:) integer, intent(inout) :: IPAR(:) (Those have ASSUMED-SHAPE arrays) And in JAC: DOUBLE PRECISION, INTENT(INOUT) :: RPAR(*) INTEGER, INTENT(INOUT) :: IPAR(*) (And those are ASSUMED-SIZE arrays.) But for procedures declarations and its interface declarations, either both or neither has to use assumed-shape arrays. The compilers passes (internally) arguments quite differently - thus (unless the compiler detects it) it will cause problems at run time. Secondly and regrading gfortran: * For some reasons, it compiles with GCC 4.7 if one calls D_VODE instead of VODE. * The error message for generic matching should be better (cf. PR40276). When checking the interface of dummy procedure, it should be possible to give always an error.
[Bug tree-optimization/57718] New: ICE in execute_todo, passes.c:2002 at -O3 (both -m32 -m64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57718
Bug ID: 57718
Summary: ICE in execute_todo, passes.c:2002 at -O3 (both -m32
-m64)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
With current gcc trunk on x86_64-linux, the following code causes an ICE when
compiled at -O3 (both -m32 and -m64). This is a regression from 4.8.x.
It may be related to 57592.
$ gcc-trunk -v
gcc version 4.9.0 20130625 (experimental) [trunk revision 200388] (GCC)
$ gcc-trunk -O2 -c reduced.c
$ gcc-4.8 -O3 -c reduced.c
$ gcc-trunk -O3 -c reduced.c
reduced.c: In function ‘foo’:
reduced.c:3:6: internal compiler error: Segmentation fault
void foo ()
^
0x7d729f crash_signal
../../gcc-trunk/gcc/toplev.c:333
0x7ff31b ssa_default_def(function*, tree_node*)
../../gcc-trunk/gcc/tree-dfa.c:314
0x7ff5e0 get_or_create_ssa_default_def(function*, tree_node*)
../../gcc-trunk/gcc/tree-dfa.c:362
0x8187fa get_reaching_def
../../gcc-trunk/gcc/tree-into-ssa.c:1184
0x81e96b maybe_replace_use
../../gcc-trunk/gcc/tree-into-ssa.c:1784
0x81e96b rewrite_update_stmt
../../gcc-trunk/gcc/tree-into-ssa.c:1967
0x81e96b rewrite_update_enter_block
../../gcc-trunk/gcc/tree-into-ssa.c:2136
0xb3801a walk_dominator_tree(dom_walk_data*, basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:210
0x817503 rewrite_blocks
../../gcc-trunk/gcc/tree-into-ssa.c:2216
0x81dc1e update_ssa(unsigned int)
../../gcc-trunk/gcc/tree-into-ssa.c:3303
0x74a3db execute_function_todo
../../gcc-trunk/gcc/passes.c:1942
0x74ab7e execute_todo
../../gcc-trunk/gcc/passes.c:2002
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.
--
int a, b, c, d, e, f;
void foo ()
{
int g;
for (;;) {
f = 0;
for (; f = 1; f++) {
a = 0;
for (; a = 4; a++)
b |= a = g;
if (d)
continue;
e = 0;
}
c = bar () b;
}
}
[Bug tree-optimization/57719] New: wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719
Bug ID: 57719
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Current gcc trunk (and gcc-4.8) produces wrong code for the following testcase
on x86_64-linux when compiled at -O3 in both 32-bit and 64-bit modes. This is a
regression from 4.7.x.
$ gcc-trunk -v
gcc version 4.9.0 20130625 (experimental) [trunk revision 200388] (GCC)
$ gcc-trunk -O2 reduced.c
$ a.out
1
$ gcc-4.7 -O3 reduced.c
$ a.out
1
$ gcc-4.8 -O3 reduced.c
$ a.out
0
$ gcc-trunk -O3 reduced.c
$ a.out
0
-
int printf (const char *, ...);
int u;
int a, b, c[2], d, *e, f, g;
int fn2 ()
{
int t[1];
int i;
i = 0;
for (; i 1; i++)
t[i] = 0;
for (d = 0; d; d = 1) {
int *s[1] = {t[0]};
g = a = *s[0];
}
f = g;
return 1;
}
void fn1 ()
{
for (; b 2; b++) {
int *p = u;
*p = 0;
*p = fn2();
e = c[b];
*e = 0;
}
}
int
main ()
{
fn1 ();
printf (%d\n, u);
return 0;
}
[Bug c++/57720] New: [C++11]Crash when Delegating Constructors throw exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57720
Bug ID: 57720
Summary: [C++11]Crash when Delegating Constructors throw
exceptions
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: liweifriends at gmail dot com
System type:
windows server 2012 + mingw-build (64 bit)
source code:
#include iostream
#include stdexcept
using namespace std;
class DCExcept
{
public:
DCExcept(double d)
try : DCExcept()
{
coutRun the body.endl;
}
catch(...)
{
coutCaught exception.endl;
}
private:
DCExcept()
{
throw runtime_error(error);
}
};
int main()
{
DCExcept a(1.2);
return 0;
}
build cmd:
g++.exe -Wall -fexceptions -g -std=c++11-c d:\CPPLearn\main.cpp -o
obj\Debug\main.o
g++.exe -o bin\Debug\CPPLearn.exe obj\Debug\main.o
run cmd:
CPPLearn.exe
compiler output:
Caught exception.
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
[Bug libstdc++/57716] std::thread does not compile with vectorint as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57716 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Resolution|WONTFIX |INVALID
[Bug target/57637] Miscompare on 178.galgel in SPEC2000 on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637 --- Comment #7 from zhenqiang.chen at linaro dot org --- Created attachment 30364 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30364action=edit update patch Please try the updated patch. Local tests: x86-64 and pandaboard bootstrap OK.
[Bug fortran/57711] Accepts non-matching invalid dummy procedure as actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid, diagnostic Status|WAITING |NEW Summary|Fortran 4.7.2/4.8.1 error: |Accepts non-matching |constraints for functions |invalid dummy procedure as |parameters |actual argument --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #2) * For some reasons, it compiles with GCC 4.7 if one calls D_VODE instead of VODE. Ditto with GCC 4.9. - ACCEPTS-INVALID bug (For the test case: Change call vode( to call d_vode( in either the linked code - or in the second test case of the patch below.) * The error message for generic matching should be better (cf. PR40276). See patch at http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html
[Bug preprocessor/57714] Newline rendered incorrectly in output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
I think what happens is that the preprocessor is trying to avoid breaking up a
valid token like in:
void foo(void) {re\
turn;
}
It would be an improvement if it ignored the \ between valid tokens boundaries
even if there is no whitespace, but I think there is not going to be anyone
sufficiently bothered to fix this ever. So unless you want to give it a try,
let's leave this bug report closed.
I added a note to the FAQ.
[Bug preprocessor/57714] Newline rendered incorrectly in output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714 --- Comment #10 from David Krauss potswa at mac dot com --- I don't plan on fixing this in GCC, but I did implement the feature today in my own preprocessor, http://code.google.com/p/c-plus/source/list . It does require a handshake between phases 2 and 3, because a token divided over two lines needs to go into the earlier line, and then the extra newlines are flushed once the token is complete. But a newline inside a whitespace token is not postponed. OK, on to bigger and better things :)
[Bug tree-optimization/57719] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-26
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.8.2
Summary|wrong code at -O3 on|[4.8/4.9 Regression] wrong
|x86_64-linux-gnu|code at -O3 on
||x86_64-linux-gnu
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
int u, a, b, c[2], d, *e, f, g;
int
foo (void)
{
int t[1], i;
for (i = 0; i 1; i++)
t[i] = 0;
for (d = 0; d; d = 1)
{
int *s[1] = { t[0] };
g = a = *s[0];
}
f = g;
return 1;
}
void
bar (void)
{
for (; b 2; b++)
{
int *p = u;
*p = 0;
*p = foo ();
e = c[b];
*e = 0;
}
}
int
main ()
{
bar ();
if (u != 1)
__builtin_abort ();
return 0;
}
Started with r196174. t is discovered unused during dce1 pass, but since
r196174 we no longer remove unused vars, which results in a t ={v} {CLOBBER};
stmt being kept inside of the loop and that for some reason affects lim1
decisions (something to investigate, potential code quality issue).
Anyway, sccp dump still looks good wrt. writes into u; already dse1 removes
the first u = 0; stmt, because it is redundant with following u = 1; in another
bb, but it keeps around u = 0; for the second iteration, so we first enter the
bb with u = 1; from there jump to bb with u = 0;, and from there go to the u =
1; bb back and finally goto exit. In ldist it is already broken, so looks like
a ldist bug to me.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Allan McRae from comment #19) That patch works. With -imacros foo.h: LC_ENTER foo.c LC_RENAME command-line LC_ENTER foo.h LC_LEAVE 0x0 LC_ENTER /usr/include/stdc-predef.h LC_LEAVE 0x0 LC_RENAME foo.c - correct output LC_LEAVE 0x0 All other combinations of -include/-imacros/-ffreestanding/no foo.h all are unchanged as expected. Great! I am certainly too busy at the moment to go through all the steps of the contribution process for this. The patch needs to be fully bootstrapped with the latest trunk, an appropriate testcase needs to be created, plus run the full regression testsuite and compare the results with the regression results of the unpatched trunk and check that no new failures appear. Then, it has to be submitted to gcc-patches with a GNU Changelog. If you are really interested in fixing this, you should just take the lead. Feel free to modify the patch as you need. The patch is anyway too small to require any kind of legal assignment, but if they ask for it, you can always say I wrote it. I have an assignment in place with the FSF. When submitting to gcc-patches, CC js...@gcc.gnu.org. You can also see in the svn log or svn blame who wrote the -imacro code and CC him/her as well. (You can also CC me).
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Once you are in trunk, you can ask the release managers to backport it to the GCC 4.8 branch.
[Bug c++/57712] GCC fails to to match out-of-line template member function definition with declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57712 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-26 Ever confirmed|0 |1
[Bug target/57637] Miscompare on 178.galgel in SPEC2000 on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637 --- Comment #8 from ktkachov at gcc dot gnu.org --- (In reply to zhenqiang.chen from comment #7) Created attachment 30364 [details] update patch Please try the updated patch. Local tests: x86-64 and pandaboard bootstrap This fixes the segfault in SPEC on arm for me. Is there a way to produce a testsuite testcase for this regression? The benchmark where this occurs is a large chunk of Fortran, not sure how easy it is to reduce it.
[Bug c/57474] [4.9 Regression] FAIL: c-c++-common/cilk-plus/AN/sec_implicit2?.c -fcilkplus (internal compiler error) on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57474 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR has been fixed between revisions 199449 and 199650. Closing.
[Bug fortran/57721] New: wrong error message with bounds checking.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57721 Bug ID: 57721 Summary: wrong error message with bounds checking. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch The following testcase: cat test.f90 TYPE data INTEGER :: x(10) END TYPE TYPE data_areas TYPE(data) :: y(10) END TYPE TYPE(data_areas) :: z(10) integer, volatile :: i,j,k i=1 ; j=1 ; k=11 z(i)%y(j)%x(k)=0 END gfortran -fbounds-check test.f90 ; ./a.out At line 13 of file test.f90 Fortran runtime error: Index '11' of dimension 1 of array 'z' above upper bound of 10 detects the out-of-bounds access, but mentions the incorrect 'z' instead of the correct 'x'
[Bug c++/57720] [C++11]Crash when Delegating Constructors throw exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57720
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
This has nothing to do with delegating constructors, constructor try-blocks
cannot swallow exceptions, they are always rethrown at the end of the catch
block. You get the same exception here:
DCExcept(double d)
try
{
coutRun the body.endl;
throw 1;
}
catch(...)
{
coutCaught exception.endl;
}
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #3 from etherice scottbaldwin at gmail dot com --- Status is still unconfirmed... How long does it typically take to confirm a bug?
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Until someone analyses it and convinces themselves it's a bug. Not providing a complete testcase doesn't help. Code missing headers, even standard ones, is not complete, and certainly doesn't compile out of the box because I need to add headers. http://gcc.gnu.org/bugs/ clearly says not to leave headers out, why should I have to figure out which headers you failed to include in the testcase to analyse your bug report?
[Bug translation/57722] New: Floating point problems when building with no-sse and no-mmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57722
Bug ID: 57722
Summary: Floating point problems when building with no-sse and
no-mmx
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: boris at dolgov dot name
Hi!
I want to prevent gcc from generating code with xmm registers on 64bit system.
I use -mno-sse and -mno-mmx flags to achieve this.
But when the program is compiled using these flags, some strange problems
appear:
$ cat vect.c
#include stdio.h
int main()
{
double x1, y1, x2, y2, r0;
scanf(%lf%lf%lf%lf, x1, y1, x2, y2);
r0 = x1*y2 - x2*y1;
printf(%.10lf %d\n, r0, (int)(r0 == 0));
return 0;
}
$ gcc -o vect0 vect.c -Wall -Wextra
$ gcc -mno-mmx -mno-sse -o vect1 vect.c -Wall -Wextra
$ echo 1 0 0 1 | ./vect0
1.00 0
$ echo 1 0 0 1 | ./vect1
0.00 0
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.7.2 (GCC)
What is the problem?
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- N.B. Clang trunk aborts on Daniel's testcase and your first one.
[Bug fortran/57721] wrong error message with bounds checking.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57721 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-26 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed. I also see the same thing with 4.4.
[Bug fortran/57721] wrong error message with bounds checking.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57721 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Duplicate of the old PR 29800. *** This bug has been marked as a duplicate of bug 29800 ***
[Bug fortran/29800] -fbounds-check: For derived types, write not also compound name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- *** Bug 57721 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/57723] New: Missed optimization: recursion around empty function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723 Bug ID: 57723 Summary: Missed optimization: recursion around empty function Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: petschy at gmail dot com Background: freeing nodes of a tree allocated with custom allocators. One of the allocators can't free individual pointers, so free() is NOP in that case (the whole pool will be freed at once when the allocator is destroyed). With this allocator, the whole recursive traversal can be eliminated in theory. Examining the disasm of the generated code revealed that gcc unfolds the recursion many levels, just to do the unneeded node traversal; the actual call to the empty free() fn is eliminated. In the test case, loop() does a simple linear traversal of the linked nodes. The pointers are not volatile, and are only read, so there should not be any side effects. Why can't the compiler optimize away the whole loop? Clang does a somewhat better job, the recursion is optimized away, and one function is completely reduced to NOP (free_all2()), but the others still have the node traversal loop. Tried with gcc 4.6, 4.7.3, 4.9.0 with the same results. g++-4.9.0 -v: Using built-in specs. COLLECT_GCC=g++-4.9.0 COLLECT_LTO_WRAPPER=/home/usr-local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ --program-suffix=-4.9.0 Thread model: posix gcc version 4.9.0 20130626 (experimental) (GCC) commit 944f42fc29289812416f34d7b0c497ee79065396 command line: g++-4.9.0 -std=c++11 -O3 -Wall 20130626-free_node.cpp Regards, Peter
[Bug tree-optimization/57723] Missed optimization: recursion around empty function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723 --- Comment #1 from petschy at gmail dot com --- Created attachment 30365 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30365action=edit test case source
[Bug tree-optimization/57723] Missed optimization: recursion around empty function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723 --- Comment #2 from petschy at gmail dot com --- Created attachment 30366 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30366action=edit gcc amd64 disassembly
[Bug tree-optimization/57723] Missed optimization: recursion around empty function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723 --- Comment #3 from petschy at gmail dot com --- Created attachment 30367 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30367action=edit clang amd64 disassembly
[Bug fortran/29800] -fbounds-check: For derived types, write not also compound name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2007-02-16 16:08:18 |2013-06-26 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- still fails on trunk (4.9). Runable testcase in PR57721
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #6 from etherice scottbaldwin at gmail dot com ---
(In reply to Jonathan Wakely from comment #4)
Until someone analyses it and convinces themselves it's a bug.
Not providing a complete testcase doesn't help. Code missing headers, even
standard ones, is not complete, and certainly doesn't compile out of the
box because I need to add headers. http://gcc.gnu.org/bugs/ clearly says
not to leave headers out, why should I have to figure out which headers you
failed to include in the testcase to analyse your bug report?
1) Did you see the reply from Daniel Krügler? He included a complete example.
2) My example was complete except for needing a couple #includes for iostream
and type_traits. Here it is w/ those includes:
#include type_traits
#include iostream
templatebool BoolVal, char CharVal
struct Foo {};
templatetypename... Ts
struct is_instantiation_of__nontypes
{
templatetemplateTs... class TT, typename T
struct check : std::false_type {};
templatetemplateTs... class TT, Ts... Args
struct checkTT, TTArgs... : std::true_type {};
};
int main() {
using FooInstantiation = Foofalse, 'x';
std::cout ((is_instantiation_of__nontypesbool, char::checkFoo,
FooInstantiation::value) ? yes : no) std::endl;
}
3) clang version 3.3 (trunk 176796) compiles it fine and produces the correct
output of yes, while gcc (all versions) blow up with some variant of:
error: ‘Ts ...’ is not a valid type for a template non-type parameter
struct checkTT, TTArgs... : std::true_type {};
^
error: template argument 2 is invalid
struct checkTT, TTArgs... : std::true_type {};
^
error: type/value mismatch at argument 1 in template parameter list for
‘templateclass ... Ts templatetemplatetemplateTs ...anonymous class
TT, class T templateclass ... Ts templateTs ...anonymous class TT,
class T struct is_instantiation_of__nontypesTs::check’
std::cout ((is_instantiation_of__nontypesbool, char::checkFoo,
FooInstantiation::value) ? yes : no) std::endl;
error: expected a template of type ‘templateclass ... Ts templateTs
...anonymous class TT’, got ‘templatebool BoolVal, char CharVal struct
Foo’
4) Convincing oneself that this is a bug should not be difficult. Section
14.1.15 of the C++11 standard makes it very clear that this code contains a
valid expansion of a non-type template parameter pack declared in a different
template-parameter-list. It even offers a very similar example, taken directly
from § 14.1.15:
templateclass... T struct value_holder {
templateT... Values apply { }; // Values is a non-type template parameter
pack
// and a pack expansion
};
[Bug tree-optimization/57723] Missed optimization: recursion around empty function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723 --- Comment #4 from petschy at gmail dot com --- Ooops, the test case won't perform the freeing completely, since the recursive call is not inside the 'down' traversal loop, so only the first node on the given level would be recursively freed, but this doesn't affect the missed optimization.
[Bug tree-optimization/57723] Missed optimization: recursion around empty function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723 --- Comment #5 from petschy at gmail dot com --- Created attachment 30368 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30368action=edit fixed test case (correct recursive traversal)
[Bug c++/57724] New: wrong error: returning a value from a constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724
Bug ID: 57724
Summary: wrong error: returning a value from a constructor
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joerg.rich...@pdv-fs.de
cat t.cc EOF
void func();
struct A
{
A()
{
return func();
}
};
EOF
gcc t.cc
Produces:
t.cc: In constructor 'A::A()':
t.cc:6:19: error: returning a value from a constructor
I think this should work. (At least clang accepts it.)
[Bug c++/57724] wrong error: returning a value from a constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724 Fanael fanael4 at gmail dot com changed: What|Removed |Added CC||fanael4 at gmail dot com --- Comment #1 from Fanael fanael4 at gmail dot com --- 12.1/12 (C++03) and 12.1/9 (C++11) state: A return statement in the body of a constructor shall not specify a return value. It's a bug in Clang, not in GCC.
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-26 Ever confirmed|0 |1 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to etherice from comment #6) 2) My example was complete except for needing a couple #includes [...] So it was not complete then! This bug has already been confirmed, except for updating the status (see how unhelpful that is?) If five people try to analyse the bug report then five people have to waste their time fixing your testcase because you didn't paste in two little lines which you already had in your version of the code. I think this can be confirmed, but please read the bug submission guidelines next time.
[Bug c++/57724] wrong error: returning a value from a constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724 --- Comment #2 from Jörg Richter joerg.rich...@pdv-fs.de --- You mean the special case for 'void' does not apply in this case? What a pity.
[Bug c++/57724] wrong error: returning a value from a constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- I'm inclined to say this is a Clang bug too. [stmt.return]/3 A return statement with an expression of type void can be used only in functions with a return type of cv void; and constructors do not have any return type, not even void. [class.ctor]/8 A return statement in the body of a constructor shall not specify a return value. That doesn't really help, because a return statement with an expression of type void does not return a value.
[Bug c/57725] New: conflicting language extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725 Bug ID: 57725 Summary: conflicting language extensions Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jbeulich at novell dot com Created attachment 30369 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30369action=edit shared header Both the Arrays of Length Zero and the Structures With No Members extensions conflict with __attribute__((visibility())) (or the respective pragma) when specifying other than the default visibility: Both of the named extensions can result in two distinct objects being at the same address, yet address comparisons for two distinct symbols with non-default visibility generally get optimized with the assumption that they can't be equal. The example files I'm going to attach show further problems in this area: The results here should neither depend on architecture, nor on whether the objects in question have an initializer. Nevertheless the behavior differs between x86 (both 32-bit and 64-bit) and e.g. ia64 or ARM64 (initialized objects, while being of zero size, get allocated at distinct addresses for x86 but not for ia64 and ARM64). Similarly, common data objects (i.e. when there's no initializer) end up without padding for all architectures I tried this for, but at least on x86 objects placed in .bss by the compiler get 1-byte padding added between them. The example code consists of - a shared header, empty.h, - a main source file, empty.c, - two auxiliary source files, empty-bss.c and empty-comm.c. The first source file should be compiled together with either of the two auxiliary files, once with just '-Wall -O2' and another time with '-Wall -O2 -DVISIBILITY=hidden'. The output will vary between the four executables created, even though it should be consistent for all of them.
[Bug c/57725] conflicting language extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725 --- Comment #1 from jbeulich at novell dot com --- Created attachment 30370 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30370action=edit main source
[Bug c/57725] conflicting language extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725 --- Comment #2 from jbeulich at novell dot com --- Created attachment 30371 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30371action=edit auxiliary source (initialized data)
[Bug c/57725] conflicting language extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725 --- Comment #3 from jbeulich at novell dot com --- Created attachment 30372 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30372action=edit auxiliary source (uninitialized data)
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #8 from etherice scottbaldwin at gmail dot com --- (In reply to Jonathan Wakely from comment #7) (In reply to etherice from comment #6) 2) My example was complete except for needing a couple #includes [...] So it was not complete then! This bug has already been confirmed, except for updating the status (see how unhelpful that is?) If five people try to analyse the bug report then five people have to waste their time fixing your testcase because you didn't paste in two little lines which you already had in your version of the code. I think this can be confirmed, but please read the bug submission guidelines next time. Good, and points taken.
[Bug lto/57726] New: LTO verify_flow_info: error: control flow in the middle of basic block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57726 Bug ID: 57726 Summary: LTO verify_flow_info: error: control flow in the middle of basic block Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: marxin.liska at gmail dot com Chrome ltrans3 compilation fails due to: ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c: In function ‘vp8_get_compressed_data’: ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 6 int vp8_set_internal_size(VP8_COMP *cpi, VPX_SCALING horiz_mode, VPX_SCALING vert_mode) ^ ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 6 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 6 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 64 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 73 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 73 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 73 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 73 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 73 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 73 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 73 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 73 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 103 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 103 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 103 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 103 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 103 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 103 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 103 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: error: control flow in the middle of basic block 103 ../../third_party/libvpx/source/libvpx/vp8/encoder/onyx_if.c:5547:0: internal compiler error: verify_flow_info failed 0x568b5d verify_flow_info() ../../gcc/cfghooks.c:260 0x88d734 cleanup_tree_cfg_noloop ../../gcc/tree-cfgcleanup.c:696 0x88d734 cleanup_tree_cfg() ../../gcc/tree-cfgcleanup.c:745 0x7b16c4 execute_function_todo ../../gcc/passes.c:1927 0x7b1fcd execute_todo ../../gcc/passes.c:2002 0x7b3ba9 execute_one_ipa_transform_pass ../../gcc/passes.c:2185 0x7b3ba9 execute_all_ipa_transforms() ../../gcc/passes.c:2215 0x58673e expand_function ../../gcc/cgraphunit.c:1584 0x58841c expand_all_functions ../../gcc/cgraphunit.c:1695 0x58841c compile() ../../gcc/cgraphunit.c:2029 0x50e3f1 lto_main() ../../gcc/lto/lto.c:3872 gcc --version: gcc (GCC) 4.9.0 20130624 (experimental) Link to all ltrans3 dump files: https://docs.google.com/file/d/0B0pisUJ80pO1akhINVR1anpTbDg/edit?usp=sharing Source file is attached. Thanks, Martin
[Bug lto/57726] LTO verify_flow_info: error: control flow in the middle of basic block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57726 --- Comment #1 from Martin Liška marxin.liska at gmail dot com --- Created attachment 30373 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30373action=edit onyx_if.c
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- By the way, much more generally, I'm under the impression that often bug submitters attach way too much importance to the status change unconfirmed - confirmed: I think it would be easy to prove that quite often bugs are fixed when still unconfirmed or that hard bugs are fixed when maintainers actually can do the work (eg, the timeframe when a bug is filed matters much more than its confirmed status to predict whether it will be fixed soon)
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 --- Comment #2 from Martin Liška marxin.liska at gmail dot com --- Created attachment 30374 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30374action=edit syscall.cc
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 --- Comment #3 from Martin Liška marxin.liska at gmail dot com --- Created attachment 30375 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30375action=edit Preprocessed syscall.cc
[Bug fortran/29800] -fbounds-check: For derived types, write not also compound name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- Patch: http://gcc.gnu.org/ml/fortran/2013-06/msg00135.html
[Bug go/57689] [4.8 Regression] ICE (segfault) building libgo on ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57689 --- Comment #1 from Ian Lance Taylor ian at airs dot com --- It's going to be hard for me to solve this using a cross-compiler. I would need a full glibc to get to the point of failure. Can you try building the compiler without optimization to see if you can get a better stack trace?
[Bug tree-optimization/57723] Missed optimization: recursion around empty function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #6 from Michael Matz matz at gcc dot gnu.org --- The loop in loop() isn't removed because it's potentially infinite, and GCC doesn't remove infinite loops by default. Add -funsafe-loop-optimizations to do that (loop() will then become an empty function). The recursion isn't removed because all calls to non-const non-pure functions are deemed necessary. dead code removal could be made to handle this with some trickery. We'd need to not mark recursive calls as inherently necessary at first, but only later if we mark anything in the function except the return statement necessary.
[Bug c/57727] New: RaspberryPi gcc internal compiler error unrecognisable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727 Bug ID: 57727 Summary: RaspberryPi gcc internal compiler error unrecognisable insn Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: themos.tsikas at gmail dot com $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --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-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-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.6.3 (Debian 4.6.3-14+rpi1) $ gcc -O3 -funroll-loops -finline-functions -march=armv6 -mfpu=vfp -mfloat-abi=hard -fsigned-char -c bugbug.c ../src/semintr.c: In function ‘reduce_mul_i8’: ../src/semintr.c:17873:1: error: unrecognizable insn: (insn 2317 2316 2318 224 (set (subreg:SI (reg:DI 715 [ MEM[base: a_265, offset: 0B] ]) 0) (sign_extend:SI (mem:QI (plus:SI (mult:SI (reg/v:SI 196 [ astep ]) (const_int 2 [0x2])) (reg/v/f:SI 290 [ a ])) [0 MEM[base: a_265, offset: 0B]+0 S1 A8]))) ../src/semintr.c:17859 -1 (nil)) ../src/semintr.c:17873:1: internal compiler error: in extract_insn, at recog.c:2109 Please submit a full bug report, with preprocessed source if appropriate.
[Bug c/57727] RaspberryPi gcc internal compiler error unrecognisable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727 --- Comment #1 from Themos Tsikas themos.tsikas at gmail dot com --- Created attachment 30376 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30376action=edit preprocessed source exhibting bug
[Bug fortran/57711] Accepts non-matching invalid dummy procedure as actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711 --- Comment #4 from Dmitry Kabanov kabanovdmitry at gmail dot com --- @Dominique: a) I get the following error: make all gfortran -c vode.f gfortran -c fcns.f90 gfortran -c main.f90 main.f90:8.75: call vode(istate, lambda_fcn, dummy_jac, lambda, x_tmp, x_end, tol, pm) 1 Error: There is no specific subroutine for the generic 'vode' at (1) make: *** [all] Error 1 b) Yes, my collegue can compile the code with gfortran 4.6.3. Unfortunately, he uses different OS - Ubuntu 12.04. However, I think the problem is not connected to OS. c) I reduced vode.f such that it contains only function declaration of function and its arguments. @Tobias: Regarding the bug in JAC/DUMMY_JAC: I think for one-dimensional arrays there is no difference between ASSUMED-SIZE and ASSUMED-SHAPE. Anyway, the code compiles with gfortran 4.6.3. I haven't found in press release of 4.7 any info confirming that gfortran changed its behavior regarding that matter intentionally. Is there any way to list all tasks which were included in some particular version of gfortran?
[Bug lto/57602] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #3 from Igor Zamyatin izamyatin at gmail dot com --- I believe the problem happens because cleanup that was made in http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01644.html sometimes changes field 'analyzed' to 'symbol.definition' but at the same time in other places to 'symbol.analyzed'. It looks like 'symbol.definition' corresponds to the former 'finalized' field not 'analyzed' and 'symbol.definition' are not always the same as 'symbol.analyzed'. I'm attaching the patch (no bootstrap and make check testing though) which fixes this (but not in all places across the compiler, sort of minimum intrusion) and runfails disappeared with these changes. Jan, could you please take a close look since now many x86 32-bit apps built with lto are broken.
[Bug lto/57602] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602 --- Comment #4 from Igor Zamyatin izamyatin at gmail dot com --- Created attachment 30377 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30377action=edit Untested patch that corrects the cleanup
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #10 from etherice scottbaldwin at gmail dot com --- (In reply to Paolo Carlini from comment #9) By the way, much more generally, I'm under the impression that often bug submitters attach way too much importance to the status change unconfirmed - confirmed: I think it would be easy to prove that quite often bugs are fixed when still unconfirmed or that hard bugs are fixed when maintainers actually can do the work (eg, the timeframe when a bug is filed matters much more than its confirmed status to predict whether it will be fixed soon) Isn't it defeating the purpose of having a 'status' field if it's not being used? It seems especially important for the situation you mentioned -- for the hard bugs that take longer to fix, an *initial* status update informs the submitter that the bug report has been reviewed and is on the dev team's radar. Otherwise, it's like the report is never even acknowledge until it's actually fixed, and I imagine most submitters will seek *some* kind of status update eventually.
[Bug fortran/57711] Accepts non-matching invalid dummy procedure as actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Dmitry Kabanov from comment #4) Regarding the bug in JAC/DUMMY_JAC: I think for one-dimensional arrays there is no difference between ASSUMED-SIZE and ASSUMED-SHAPE. That's wrong: - Assumed-size (var(*), var(5,*)) and explicit size (var(2,3), var(n,m) [the latter: automatic arrays]) pass a pointer to the data. - Assumed-shape and deferred-shape (var(:)) [and assumed-rank] pass a pointer to an array descriptor (dope vector), which contains the array bounds - and a pointer to the data. Thus, mixing arrays from the first group with arrays from the second group does not work. Thus, for procedures passed as argument (as your (dummy_)jac) the array type has to be the same. And for normal array arguments, the compiler has to know the interface* - otherwise it assumes that it is in the first group. For array arguments, the compiler automatically converts between the two groups. (* know = its in a MODULE, in an internal procedure (contains) or in an INTERFACE block.) Anyway, the code compiles with gfortran 4.6.3. My point was that they have a different internal representation. Thus, it will fail at run time as soon as you access the array - either by having the wrong value or by crashing. Hence, you really should ensure that DUMMY_JAC and JAC either use both assumed-shape arrays - or both assumed-size/explicit-size. (Mixing the latter is fine in practice [if the compiler doesn't complain], even if it is not permitted by the standard.) If you corrected that bug, it should compile with both GCC 4.6 and GCC 4.7. I haven't found in press release of 4.7 any info confirming that gfortran changed its behavior regarding that matter intentionally. Is there any way to list all tasks which were included in some particular version of gfortran? That change falls into the category bug fix/diagnostic improvement. The release notes only list major, user visible changes: http://gcc.gnu.org/gcc-4.7/changes.html All changes are in the ChangeLog files. For the Fortran front end (w/o library changes), you can find them at http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/fortran/ for the current development version - and for GCC 4.7 at http://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_7-branch/gcc/fortran/
[Bug c++/57728] New: Explicit template instantiation with defaulted method causes missing symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728 Bug ID: 57728 Summary: Explicit template instantiation with defaulted method causes missing symbol Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bmerry at gmail dot com Created attachment 30378 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30378action=edit Minimal test case I don't claim to fully understand all the intricies of C++11, but the following smells fishy to me. I am using a combination of features: 1. The = default syntax to restore implicit constructors/assignments that were otherwise hidden (e.g. default constructor when there are no user-defined constructors), in a templated class. 2. extern template in the header to suppress instantiation of a specific instance, with an explicit instantiation in one translation unit. In some cases (I assume depending on compiler eliding) this causes a link-time error for the defaulted constructor. I have attached a minimal test case. I don't know whether there is supposed to be a symbol or whether the compiler is supposed to inline the default implementation, but currently there is a mismatch. System information: Ubuntu 12.04 with gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04) Output (there's a more detailed log in the attachment with -v -save-temps): g++-4.8 -std=c++11 -c defaulted.cpp g++-4.8 -std=c++11 -c impl.cpp g++-4.8 -std=c++11 -o defaulted defaulted.o impl.o defaulted.o: In function `main': defaulted.cpp:(.text+0x10): undefined reference to `Aint::A()' collect2: error: ld returned 1 exit status make: *** [defaulted] Error 1
[Bug c++/57729] New: Always inline: indirect function call with a yet undetermined callee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729
Bug ID: 57729
Summary: Always inline: indirect function call with a yet
undetermined callee
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin.liska at gmail dot com
Latest firefox could not be compiled due to always inline error.
/ssd/firefox/js/src/jsapi.h: In function ‘js::regexp_exec(JSContext*, unsigned
int, JS::Value*)’:
/ssd/firefox/js/src/builtin/RegExp.cpp:307:1: error: inlining failed in call to
always_inline ‘IsRegExp(JS::Value const)’: indirect function call with a yet
undetermined callee
IsRegExp(const Value v)
^
In file included from /ssd/firefox/js/src/jsprvtd.h:24:0,
from /ssd/firefox/js/src/builtin/RegExp.h:10,
from /ssd/firefox/js/src/builtin/RegExp.cpp:7:
/ssd/firefox/js/src/jsapi.h:707:5: error: called from here
if (Test(thisv))
^
Code snippet:
JS_ALWAYS_INLINE bool
IsRegExp(const Value v)
{
return v.isObject() v.toObject().isRegExpObject();
}
JSBool
js::regexp_exec(JSContext *cx, unsigned argc, Value *vp)
{
CallArgs args = CallArgsFromVp(argc, vp);
return CallNonGenericMethod(cx, IsRegExp, regexp_exec_impl, args);
}
I found out that problematic commit is: 200179.
[Bug c++/57729] Always inline: indirect function call with a yet undetermined callee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729 --- Comment #1 from Martin Liška marxin.liska at gmail dot com --- Created attachment 30379 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30379action=edit RegExp.cpp
[Bug c++/57729] Always inline: indirect function call with a yet undetermined callee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729 --- Comment #2 from Martin Liška marxin.liska at gmail dot com --- Created attachment 30380 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30380action=edit jsapi.h
[Bug c++/57729] Always inline: indirect function call with a yet undetermined callee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot de --- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de --- See Bug 57698.
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to etherice from comment #10) Isn't it defeating the purpose of having a 'status' field if it's not being used? What makes you think it isn't used? Paolo is saying that the difference between UNCONFIRMED and NEW is often irrelevant for the submitter's purposes, that doesn't mean the entire field isn't used. The ASSIGNED and RESOLVED values are obviously not the same as UNCONFIRMED/NEW. It seems especially important for the situation you mentioned -- for the hard bugs that take longer to fix, an *initial* status update informs the submitter that the bug report has been reviewed and is on the dev team's radar. Otherwise, it's like the report is never even acknowledge until it's actually fixed, and I imagine most submitters will seek *some* kind of status update eventually. But there is no dev team so there's no radar for it to meaningfully be on. That's not how GCC works. Confirming the bug means at least one person agrees it's a real bug, and noone else has disagreed strongly enough to say it's INVALID, it doesn't mean it's on anyone's TODO list or a fix is in progress.
[Bug c++/57729] Always inline: indirect function call with a yet undetermined callee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729 Martin Liška marxin.liska at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Martin Liška marxin.liska at gmail dot com --- Duplicate. *** This bug has been marked as a duplicate of bug 57698 ***
[Bug c/57727] RaspberryPi gcc internal compiler error unrecognisable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #2 from ktkachov at gcc dot gnu.org --- Reproduced with GCC 4.6.4. However, this is fixed on all currently maintained versions of GCC, it worked for me with 4.7.4, 4.8.1 and current trunk (4.9). GCC 4.6 is not maintained anymore, please use a more recent release if you can.
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 Martin Liška marxin.liska at gmail dot com changed: What|Removed |Added CC||marxin.liska at gmail dot com --- Comment #4 from Martin Liška marxin.liska at gmail dot com --- *** Bug 57729 has been marked as a duplicate of this bug. ***
[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-26
CC||jason at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
The explicit instantiation declaration suppresses the definition of Aint::A()
in defaulted.o, but the explicit instantiation definition doesn't cause that
symbol to be emitted in impl.o, so when that constructor is not inlined there
is no definition.
As a single file:
templatetypename T
struct A
{
T x;
A() = default;
A(const A other) = delete;
};
extern template class Aint;
int main()
{
Aint a;
}
This compiles with clang but not G++ because Clang doesn't create a reference
to Aint::A() from main(), so it doesn't matter that the explicit
instantiation is not defined in the program.
[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728 --- Comment #2 from Bruce Merry bmerry at gmail dot com --- (In reply to Jonathan Wakely from comment #1) The explicit instantiation declaration suppresses the definition of Aint::A() in defaulted.o, but the explicit instantiation definition doesn't cause that symbol to be emitted in impl.o, so when that constructor is not inlined there is no definition. That's more or less what I figured was happening. Can you clarify whether you think this a GCC bug or just me misunderstanding the language? Thanks.
[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- It's a bug
[Bug c/57727] RaspberryPi gcc internal compiler error unrecognisable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727 --- Comment #3 from Themos Tsikas themos.tsikas at gmail dot com --- (In reply to ktkachov from comment #2) Reproduced with GCC 4.6.4. However, this is fixed on all currently maintained versions of GCC, it worked for me with 4.7.4, 4.8.1 and current trunk (4.9). GCC 4.6 is not maintained anymore, please use a more recent release if you can. Thanks, I will see if a more recent version is available in my distro.
[Bug target/57727] RaspberryPi gcc internal compiler error unrecognisable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |target --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Themos Tsikas from comment #3) Thanks, I will see if a more recent version is available in my distro. You really should have reported the bug directly to the distro as they normally have patches applied on top of GCC and there is no way for us to fix your distro's GCC.
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #12 from etherice scottbaldwin at gmail dot com --- (In reply to Jonathan Wakely from comment #11) (In reply to etherice from comment #10) Isn't it defeating the purpose of having a 'status' field if it's not being used? What makes you think it isn't used? His comment that quite often bugs are fixed when still unconfirmed. In those cases, when it isn't used, the submission isn't even acknowledged until the bug is fixed. Paolo is saying that the difference between UNCONFIRMED and NEW is often irrelevant for the submitter's purposes, that doesn't mean the entire field isn't used. The ASSIGNED and RESOLVED values are obviously not the same as UNCONFIRMED/NEW. The point was more about setting an initial status -- something -- to acknowledge the submission was reviewed. But there is no dev team so there's no radar for it to meaningfully be on. I meant the group of developers maintaining gcc. That's not how GCC works. Confirming the bug means at least one person agrees it's a real bug, and noone else has disagreed strongly enough to say it's INVALID, it doesn't mean it's on anyone's TODO list or a fix is in progress. But you agree that it says *something*, which is better than nothing. It's some kind of acknowledgement to the submitter that the report was reviewed by someone and not just lost in the shuffle. Paulo's observation that often bug submitters attach way too much importance to the status change. I can't speak for everyone, but it sounds like bug submitters eventually become curious about the status of their submissions, after enough time passes.
[Bug libstdc++/57730] New: class/struct mismatch for std::hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57730 Bug ID: 57730 Summary: class/struct mismatch for std::hash Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: d.frey at gmx dot de When compiling with Clang and -Wall -Wextra -Werror, I get an error on a mismatched declaration/definition for std::hash wrt the use of class vs. struct. The problem seems to be an inconsistent friend declaration in /usr/include/c++/4.8/bits/stl_bvector.h in line 523 (at least on my system, Ubuntu 12.04, GCC 4.8.1) where it reads friend class hash; and where it *should* read friend struct hash; which (for me) solves the problem. There might be other places, I did a quick grep on class hash and found 4 occurrences in libstdc++, but I'm not sure how to find all cases or even how to check for this.
[Bug middle-end/14192] Restrict pointers don't help
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192 Chris King colanderman at gmail dot com changed: What|Removed |Added CC||colanderman at gmail dot com --- Comment #14 from Chris King colanderman at gmail dot com --- Only two_restrict_pointers is valid. Sorry, but I still don't get it I agree. None of the above responses clearly explain why one_restrict_pointer does not represent a valid bug. The missed optimization still exists in 4.8.0.
[Bug libstdc++/57730] class/struct mismatch for std::hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57730 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Bug in clang to warn about this because they is perfectly valid standard C++ code.
[Bug target/57727] RaspberryPi gcc internal compiler error unrecognisable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727 --- Comment #5 from Themos Tsikas themos.tsikas at gmail dot com --- (In reply to Andrew Pinski from comment #4) (In reply to Themos Tsikas from comment #3) Thanks, I will see if a more recent version is available in my distro. You really should have reported the bug directly to the distro as they normally have patches applied on top of GCC and there is no way for us to fix your distro's GCC. Then change your compiler's message and I might know how to do the right thing!
[Bug c/57627] -Wsizeof-pointer-memaccess should make an exception for character types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57627
--- Comment #1 from Harald van Dijk harald at gigawatt dot nl ---
I just realised the very similar example
void f4(char *dst, char *src)
{ __builtin_memcpy(dst, src, sizeof(src)); }
void f5(unsigned char *dst, unsigned char *src)
{ __builtin_memcpy(dst, src, sizeof(src)); }
also gets a warning, but in that case, I fully agree with the warning GCC
currently gives. So, to clarify, my request/suggestion is *only* to suppress
the warning for f2 and f3 in my report, and leave the behaviour for these f4
and f5 as it is.
[Bug target/57727] RaspberryPi gcc internal compiler error unrecognisable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Themos Tsikas from comment #5) Then change your compiler's message and I might know how to do the right thing! It is up to the distro to change the message. If the distro does not change the error reporting URL, it is a bug in their configuring of GCC. Actually it points you to the file: file:///usr/share/doc/gcc-4.6/README.Bugs Which you did not read fully.
[Bug target/57727] RaspberryPi gcc internal compiler error unrecognisable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727 --- Comment #7 from Themos Tsikas themos.tsikas at gmail dot com --- I knew this was going to be my fault. Habe a good day sir.
[Bug fortran/46487] Missing memory freeing for functions returning allocatable scalars (allocatable_scalar_5.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46487 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-26 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200429.
[Bug fortran/49588] DATA statement with vector sections rejected (ICE: TODO)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49588 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-26 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200429.
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com --- Curious, I understand, assuming they don't take new as a solid indication that a fix is forthcoming. assigned normally is more reliable for that, still not much more, unless, as I tried to explain, there are other reasons like the bug is a regression, a release is close, etc.
[Bug fortran/29800] -fbounds-check: For derived types, write not also compound name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Wed Jun 26 15:39:25 2013 New Revision: 200425 URL: http://gcc.gnu.org/viewcvs?rev=200425root=gccview=rev Log: 2013-06-26 Tobias Burnus bur...@net-b.de PR fortran/29800 * trans-array.c (gfc_conv_array_ref): Improve out-of-bounds diagnostic message. * trans-array.c (gfc_conv_array_ref): Update prototype. * trans-expr.c (gfc_conv_variable): Update call. 2013-06-26 Tobias Burnus bur...@net-b.de PR fortran/29800 * gfortran.dg/bounds_check_17.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/29800] -fbounds-check: For derived types, write not also compound name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- (Finally) FIXED on the GCC 4.9 trunk.
[Bug fortran/27766] [meta] -fbounds-check related bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766 Bug 27766 depends on bug 29800, which changed state. Bug 29800 Summary: -fbounds-check: For derived types, write not also compound name http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/29800] -fbounds-check: For derived types, write not also compound name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Tobias Burnus from comment #6) (Finally) FIXED on the GCC 4.9 trunk. Thanks!
[Bug middle-end/36041] Speed up builtin_popcountll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #11 from Cristian Rodríguez crrodriguez at opensuse dot org ---
Not to be annoying, but compiling the test case attached to this bug report
with clang 3.3 produces code in where
inline u32 popcount64_1(u64 x) { return __builtin_popcountll(x); }
is over 3 times faster than GCC 4.8.1 in x86_64.
I think GCC could just generate IFUNCS for generic targets , in x86_64 one
function with attribute target popcnt and the other a call to libgcc that at
least matches the clang performance.
[Bug fortran/47803] [F95+] Constant inquiry function rejected in PARAMETER definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47803 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-26 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- The link http://j3-fortran.org/pipermail/j3/2011-February/004197.html is broken. Any news from the committee about this PR?
[Bug fortran/47803] [F95+] Constant inquiry function rejected in PARAMETER definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47803 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING
[Bug fortran/47040] Make error message for empty array constructor more helpful/correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47040 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-26 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still there two years and a half later at revision 200429. What is wrong with the patch in comment #1?
[Bug fortran/47803] [F95+] Constant inquiry function rejected in PARAMETER definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47803 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) The link is broken. Any news from the committee about this PR? Try: http://mailman.j3-fortran.org/pipermail/j3/2011-February/004197.html That's F08/0050. See F2008 Corr. 1 at ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1902.pdf (search for F08/0050). See also ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1875.txt for the latest version (positively balloted in N1877/N1889).
[Bug fortran/47040] Make error message for empty array constructor more helpful/correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47040 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) Still there two years and a half later at revision 200429. What is wrong with the patch in comment #1? Nothing - it just needs to be packaged.
[Bug fortran/47040] Make error message for empty array constructor more helpful/correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47040 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Nothing - it just needs to be packaged. Do you want me to do it?
[Bug c/57725] conflicting language extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com --- I'd say that in the presence of those extensions, it should be considered unspecified whether pointers to distinct objects at the same address compare equal or not.
[Bug libstdc++/57730] class/struct mismatch for std::hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57730 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2013-06-26 Resolution|WONTFIX |--- Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Reopened...
[Bug libstdc++/57730] class/struct mismatch for std::hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57730 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- ... to close as Dup. *** This bug has been marked as a duplicate of bug 56627 ***
[Bug libstdc++/56627] class hash instead of struct hash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||d.frey at gmx dot de --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 57730 has been marked as a duplicate of this bug. ***
[Bug middle-end/36041] Speed up builtin_popcountll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041 --- Comment #12 from Marc Glisse glisse at gcc dot gnu.org --- Created attachment 30381 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30381action=edit IFUNC proof of concept patch Sadly, libgcc is compiled with gcc and not g++ so we can't use the recent multiversioning support with the target attribute and we have to manually set up ifunc. Note that the si/di difference is not a typo, just a wart in the way libgcc is configured. This is just a proof of concept, we'd want to replace also __popcountti2 at least. And most importantly we need to restrict the inclusion of t-ifunc to platforms where ifunc is supported (move it elsewhere in config.host, maybe even include the content of t-ifunc in an existing t-*). There are probably better ways to organize this, putting the generic implementation in libgcc2.c protected by suitable macros (which ones?) so it benefits also darwin/cygwin (no ifunc) and non-x86 platforms. I didn't check the generic code, I just pasted it from one of the comments. If you want this to happen, please work out a patch and post it to gcc-patches (you can start from this one or not), don't wait for others to write one, I won't have more time to spend on this. Don't be too afraid to test the wrong macro, the reviewer will tell you if that is the case.
[Bug c++/57724] wrong error: returning a value from a constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Basing on the analysis provided by Jon + the most recent ICC also rejects the snippet, I think we can safely close the bug.
[Bug middle-end/36041] Speed up builtin_popcountll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041 --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Marc Glisse from comment #12) Created attachment 30381 [details] IFUNC proof of concept patch I think it is a bad idea to use ifunc for such a function as most of the time it is link against statically in most cases. Why can't you compile your code with -march=native for the places where you know you are going to compile and run directly on the same machine?
