[Bug libstdc++/64441] New: A match_results returns an incorrect sub_match if the sub_match::matched is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441
Bug ID: 64441
Summary: A match_results returns an incorrect sub_match if the
sub_match::matched is false
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34362
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34362&action=edit
g++ -v
Please see the following sample.
== sample code
==
#include
#include
int main()
{
const char s[] = "abc";
const std::regex re("(\\d+)|(\\w+)");
std::cmatch m;
std::regex_search(s, m, re);
std::cout << std::boolalpha;
for (size_t i = 0, n = m.size(); i < n; ++i) {
auto&& sub = m[i];
std::cout << i << ":" << sub.matched << ", str = '" << sub.str() << "',
"
"range = [" << sub.first - s << ", " << sub.second - s << ")" <<
std::endl;
}
}
=
= output =
0:true, str = 'abc', range = [0, 3)
1:false, str = '', range = [-140734305427376, -140734305427376)
2:true, str = 'abc', range = [0, 3)
==
cf. http://melpon.org/wandbox/permlink/SBoMF5UKYYa38Y4N
The C++11 standard 28.10[re.results]/p.4 says, "Otherwise matched is false, and
members first and second point to the end of the sequence that was searched."
So, I think that the output should be
= output =
0:true, str = 'abc', range = [0, 3)
1:false, str = '', range = [3, 3)
2:true, str = 'abc', range = [0, 3)
==
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #8 from Joost VandeVondele --- also in cp2k we use separate calls for getting the count_rate, count_max and count. I think as long as they are the same kind there should be no problem. *8 arguments resolve to the _8 version and *4 to the _4 version. Both versions ideally have different resolution. I would argue that allowing a single call to system_clock to have integer arguments of different kind is somewhat of a bug in the standard, possibly worthy of a compiler warning. In that case, I would resolve return -HUGE,0,0 i.e. system_clock of this version not supported (also allowed by the standard). Actually, the latter seems like a good idea for integer*1 and integer*2 system_clock calls as well, since the current version is non-conforming. > cat test.f90 INTEGER*1 :: count,count_max,count_rate DO CALL SYSTEM_CLOCK(count,count_max,count_rate) write(6,*) count,count_max,count_rate ENDDO END > ./a.out | head -14 -24 -1 -13 -24 -1
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #9 from Joost VandeVondele --- reading the standard, indeed it seems like count_rate can be real as well... same rules here *4 -> _4 *8 -> _8. As a side remark the following generates a slightly outdated error: > cat test.f90 COMPLEX(KIND=4) :: count_rate CALL SYSTEM_CLOCK(count_rate=count_rate) END > gfortran test.f90 test.f90:2:29: CALL SYSTEM_CLOCK(count_rate=count_rate) 1 Error: ‘count_rate’ argument of ‘system_clock’ intrinsic at (1) must be INTEGER should be 'INTEGER or REAL'. count and count_max are still integer.
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #11 from Yuri Rumyantsev --- Created attachment 34363 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34363&action=edit patch to fix issue This patch fixed almost all issues related to operand canonicalization.
[Bug c/64442] New: -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442
Bug ID: 64442
Summary: -O1 modify output of a simple computation with
rounding
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: colin.pitrat+gcc at gmail dot com
When building the following program with -O1, it outputs 85 whereas without -O1
it outputs 84:
#include
#include
int main()
{
double max = 8.03;
double a = 6.01;
double b = 5;
double c = (double)0xFF / (max - b);
int16_t value = (a - b) * c;
printf("Result = %d\n", value);
return 0;
}
The compilation lines I use are really minimal:
- gcc main.c
vs
- gcc -O1 main.c
I tried to find which optimization flag was producing this issue but couldn't
find any !
- I don't have the issue when I don't use -O1 but provide explicitely all (or
any of) -O1 optimization flags (obtained with gcc -Q -O1 --help=optimizers |
grep "\-f" | grep enabled | awk '{ print $1 }' | xargs)
- Among all optimizer flags, I have the same issue only when providing either
-fsingle-precision-constant, -ffloat-store or -fshort-double but those flags
are supposed to be deactivated in -O1
Note that I didn't test -fpack-struct because it didn't build
Regards,
Colin
[Bug c/64440] -Wdiv-by-zero false negative on const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64440 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- (In reply to Chengnian Sun from comment #2) > Thanks for your reply. It seems GCC sometimes does consider "const int" for > other types of warnings (but not for -Wdiv-by-zero). See the following, with > -O3, GCC warns that the left shift count is negative. > I wonder how this happens? The warning is still given by the FE! Nonetheless, clang is able to warn without optimization because it has some constant propagation pass in the FE. GCC does not have such a thing and current developers are not convinced that it is worth it. I think there are several PRs open about this, and it doesn't seem useful to have one PR for each possible warning that could be improved by this.
[Bug c/64442] -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442 --- Comment #1 from Mikael Pettersson --- Are you compiling on 32-bit x86? I can reproduce on m68k, but not on x86_64 (even with -m32) or on ARMv5. I suspect you're seeing the effects of excess precision of the x87 FPU (much like the m68k FPU).
[Bug bootstrap/50139] in-tree GMP/PPL/CLooG is misconfigured
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #4 from Manuel López-Ibáñez --- (In reply to nightstrike from comment #3) > There's other relevant posts, but you get the idea. Anyway, this should > eventually be closed. So be it. Thanks for noticing. (You can probably get a gcc.gnu.org bugzilla account, if you wish so).
[Bug bootstrap/50156] in-tree CLooG is not picked up by toplevel configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156 Bug 50156 depends on bug 50139, which changed state. Bug 50139 Summary: in-tree GMP/PPL/CLooG is misconfigured https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug bootstrap/50156] in-tree CLooG is not picked up by toplevel configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #4 from Manuel López-Ibáñez --- CLooG will be removed in GCC 5.0. If you still think these patches are useful for trunk please re-open the bug. Patches in bugzilla tend to get lost, it is better to send them to gcc-patches@ and ping, ping, ping, ping... until you get someone to review them.
[Bug libstdc++/64443] New: New std::string implementation breaks tests on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443 Bug ID: 64443 Summary: New std::string implementation breaks tests on AArch64. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: belagod at gcc dot gnu.org This commit seems to be breaking libstdc++-v3 runs on AArch64. Author: redi Date: Fri Dec 19 18:16:39 2014 + New std::string implementation. * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_CXX11_ABI): Remove. (GLIBCXX_ENABLE_LIBSTDCXX_DUAL_ABI, GLIBCXX_DEFAULT_ABI): Add. * configure.ac: Use new macros. * configure: Regenerate. * Makefile.in: Regenerate. * doc/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. * include/Makefile.am: Set _GLIBCXX_USE_DUAL_ABI. * include/Makefile.in: Regenerate. * config/abi/pre/gnu.ver: Export symbols related to new std::string. Tighten old patterns to not match new symbols. * config/locale/generic/monetary_members.cc: Guard some definitions to not compile with new ABI. * config/locale/gnu/monetary_members.cc: Likewise. * config/locale/gnu/numeric_members.cc: Prevent double-free. PASS->FAIL: 22_locale/locale/cons/6.cc execution test PASS->FAIL: 22_locale/num_get/get/char/11.cc execution test PASS->FAIL: 22_locale/num_get/get/char/12.cc execution test PASS->FAIL: 22_locale/num_get/get/char/13.cc execution test PASS->FAIL: 22_locale/num_get/get/char/14.cc execution test PASS->FAIL: 22_locale/num_get/get/char/15.cc execution test PASS->FAIL: 22_locale/num_get/get/char/22131.cc execution test PASS->FAIL: 22_locale/num_get/get/char/23953.cc execution test PASS->FAIL: 22_locale/num_get/get/char/37958.cc execution test PASS->FAIL: 22_locale/num_get/get/char/39168.cc execution test PASS->FAIL: 22_locale/num_get/get/wchar_t/11.cc execution test PASS->FAIL: 22_locale/num_get/get/wchar_t/12.cc execution test PASS->FAIL: 22_locale/num_get/get/wchar_t/13.cc execution test PASS->FAIL: 22_locale/num_get/get/wchar_t/14.cc execution test PASS->FAIL: 22_locale/num_get/get/wchar_t/15.cc execution test PASS->FAIL: 22_locale/num_get/get/wchar_t/22131.cc execution test PASS->FAIL: 22_locale/num_get/get/wchar_t/23953.cc execution test PASS->FAIL: 22_locale/num_get/get/wchar_t/37958.cc execution test PASS->FAIL: 22_locale/num_get/get/wchar_t/39168.cc execution test PASS->FAIL: 22_locale/num_put/put/char/11.cc execution test PASS->FAIL: 22_locale/num_put/put/char/23953.cc execution test PASS->FAIL: 22_locale/num_put/put/char/38196.cc execution test PASS->FAIL: 22_locale/num_put/put/wchar_t/11.cc execution test PASS->FAIL: 22_locale/num_put/put/wchar_t/23953.cc execution test PASS->FAIL: 22_locale/num_put/put/wchar_t/38196.cc execution test PASS->FAIL: 22_locale/numpunct/members/char/cache_1.cc execution test PASS->FAIL: 22_locale/numpunct/members/char/cache_2.cc execution test PASS->FAIL: 22_locale/numpunct/members/wchar_t/cache_1.cc execution test PASS->FAIL: 22_locale/numpunct/members/wchar_t/cache_2.cc execution test
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
Uroš Bizjak changed:
What|Removed |Added
Component|target |middle-end
--- Comment #13 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #12)
> Created attachment 34361 [details]
> A new patch
>
> Please try the new patch.
No, this approach is wrong. ix86_fixup_binary_operands should not be used to
legitimize PIC address. The -fpic expansion is already wrong, since it
produces:
;; ivtmp.9_4 = (unsigned long) _37;
(insn 59 58 0 (parallel [
(set (reg:DI 123 [ ivtmp.9 ])
(plus:DI (reg:DI 124 [ D.3980 ])
(symbol_ref:DI ("G") )))
(clobber (reg:CC 17 flags))
]) -1
(nil))
This is similar to:
--cut here--
typedef __SIZE_TYPE__ size_t;
extern char G[8];
char *a (size_t z)
{
return &G[z];
}
--cut here--
Without -fpic, the compiler expands to:
6: {r90:DI=r89:DI+`G';clobber flags:CC;}
Compare this with -fpic expansion:
6: r92:DI=[const(unspec[`G'] 2)]
7: r91:DI=r92:DI
REG_EQUAL `G'
8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}
Looking at the above, it looks the problem is in the middle-end, where symbol
address should be legitimized through ix86_legitimize_address (a.k.a
TARGET_LEGITIMIZE_ADDRESS).
[Bug c/64442] -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442 --- Comment #2 from Colin Pitrat --- Yes I'm building on i686. But I thought -O1 and -O2 were safe optimization that weren't supposed to change the behaviour. Moreover, I'm surprised that providing the list of -f flags -O1 is supposed to enable doesn't allow me to reproduce the issue.
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #14 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to H.J. Lu from comment #12)
> > Created attachment 34361 [details]
> > A new patch
> >
> > Please try the new patch.
>
> No, this approach is wrong. ix86_fixup_binary_operands should not be used to
> legitimize PIC address. The -fpic expansion is already wrong, since it
> produces:
> --cut here--
> typedef __SIZE_TYPE__ size_t;
>
> extern char G[8];
>
> char *a (size_t z)
> {
> return &G[z];
> }
> --cut here--
>
> Without -fpic, the compiler expands to:
>
> 6: {r90:DI=r89:DI+`G';clobber flags:CC;}
>
> Compare this with -fpic expansion:
>
> 6: r92:DI=[const(unspec[`G'] 2)]
> 7: r91:DI=r92:DI
> REG_EQUAL `G'
> 8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}
>
This is generated in the backend:
Starting program: /export/build/gnu/gcc/build-x86_64-linux/gcc/cc1
-fpreprocessed /tmp/x.i -quiet -dumpbase x.i -mtune=generic -march=x86-64
-auxbase x -version -fPIC -o x.s
GNU C11 (GCC) version 5.0.0 20141228 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (GCC) version 5.0.0 20141228 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e92c7e019abbedeeeac36edef3dbfdca
Breakpoint 6, legitimize_pic_address (orig=0x719c8840, reg=0x0)
at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:13565
13565 rtx addr = orig;
(gdb) bt
#0 legitimize_pic_address (orig=0x719c8840, reg=0x0)
at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:13565
#1 0x01082cf2 in ix86_expand_move (mode=DImode,
operands=0x7fffc840)
at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:17311
#2 0x011a2c3f in gen_movdi (operand0=0x719c88b8,
operand1=0x719c8840)
at /export/gnu/import/git/gcc/gcc/config/i386/i386.md:1938
#3 0x0084471f in insn_gen_fn::operator() (
this=0x1a82330 , a0=0x719c88b8, a1=0x719c8840)
at /export/gnu/import/git/gcc/gcc/recog.h:303
#4 0x0091cb20 in emit_move_insn_1 (x=0x719c88b8, y=0x719c8840)
at /export/gnu/import/git/gcc/gcc/expr.c:3529
#5 0x0091cf74 in emit_move_insn (x=0x719c88b8, y=0x719c8840)
at /export/gnu/import/git/gcc/gcc/expr.c:3624
...
(gdb) call debug_rtx (orig)
(symbol_ref:DI ("G") [flags 0x40] )
(gdb)
[Bug libstdc++/64443] New std::string implementation breaks tests on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443 --- Comment #1 from Andrew Pinski --- >This commit seems to be breaking libstdc++-v3 runs on AArch64. Is this under Linux or with newlib?
[Bug ipa/64444] New: [5 Regression] ICE: in inline_merge_summary, at ipa-inline-analysis.c:3611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Bug ID: 6
Summary: [5 Regression] ICE: in inline_merge_summary, at
ipa-inline-analysis.c:3611
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Happens during Firefox LTO build on ppc64:
trippels@gcc2-power8 genrb % < parse.ii
int *k_type_string;
struct
{
int *nameUChars;
} gResourceTypes{ k_type_string };
trippels@gcc2-power8 genrb % < ucol_tok.ii
typedef struct
{
int charsOffset;
} UColParsedToken;
typedef struct
{
UColParsedToken parsedToken;
int source;
int *extraCurrent;
int inRange;
} UColTokenParser;
typedef struct
{
int *subName;
} ucolTokSuboption;
int *suboption_00;
ucolTokSuboption alternateSub{ suboption_00 };
static int
fn1 (UColTokenParser *p1)
{
p1->parsedToken.charsOffset = p1->extraCurrent - &p1->source;
}
void
fn2 (UColTokenParser *p1)
{
if (p1->inRange)
fn1 (p1);
}
trippels@gcc2-power8 genrb % c++ -r -nostdlib -O2 -flto -std=gnu++0x parse.ii
ucol_tok.ii
lto1: internal compiler error: in inline_merge_summary, at
ipa-inline-analysis.c:3611
0x10490b63 inline_merge_summary(cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3611
0x10d0fa4b inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
../../gcc/gcc/ipa-inline-transform.c:326
0x10d07b1b inline_small_functions
../../gcc/gcc/ipa-inline.c:1813
0x10d07b1b ipa_inline
../../gcc/gcc/ipa-inline.c:2185
0x10d07b1b execute
../../gcc/gcc/ipa-inline.c:2558
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
lto-wrapper: fatal error: /home/trippels/gcc_test/usr/local/bin/c++ returned 1
exit status
compilation terminated.
/home/trippels/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug ipa/64444] [5 Regression] ICE: in inline_merge_summary, at ipa-inline-analysis.c:3611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Markus Trippelsdorf changed: What|Removed |Added Target Milestone|--- |5.0 --- Comment #1 from Markus Trippelsdorf --- Started with r219108.
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412 --- Comment #15 from Uroš Bizjak --- (In reply to H.J. Lu from comment #14) > This is generated in the backend: Yes, but the question is, why somehow similar testcase legitimizes the address correctly with -fpic, while the original testcase doesn't.
[Bug c++/64445] New: virtual functions polymorphism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64445 Bug ID: 64445 Summary: virtual functions polymorphism Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nagl46 at web dot de Created attachment 34364 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34364&action=edit example of described bug A base class "base" has two virtual functions virtual void Y( float xx ); virtual void Y( int xx); A new class "ext" that inherits from base class re-implements the function virtual void Y( float xx ); Calling function Y(float) on a pointer "base *" pointing to an ext instance results in a call to "base::Y(int)". I would expect a call to the "ext::Y(float)" function. Is it a bug or is it my mistake? It's the same behavior in gcc 4.7.2 and gcc 5.0.0.
[Bug c++/64445] virtual functions polymorphism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64445 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- int xx = 0; anExt.Y(xx); // calls Y(float) since Y(int) is hidden by ext::Y(float) aBaseP->Y(xx); // calls Y(int) since int is a direct match inside base.
[Bug c++/64446] New: Misleading error message when inheriting from a template class w/o the template params
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64446
Bug ID: 64446
Summary: Misleading error message when inheriting from a
template class w/o the template params
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
When compiling the under code, g++ gives a misleading error message:
$ g++-5.0.0 -Wall 20141230-templ_base.cpp
20141230-templ_base.cpp:7:1: error: expected class-name before ‘{’ token
'Base' is definitely a valid class name.
The problem is that the name given is a class, but it's a template and the
template argument is missing.
However, in the second case, when inheriting from Base2 and only one template
argument is given of the two, the error message is OK: wrong number of template
arguments (1, should be 2).
Something similar would be desirable in the first case, not to waste time
staring at the screen, searching for a typo in the class name and finding none.
Like ' is a template but no template arguments are given'.
$ g++-5.0.0 -v
Using built-in specs.
COLLECT_GCC=g++-5.0.0
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-5.0.0
Thread model: posix
gcc version 5.0.0 20141222 (experimental) (GCC)
4.9 and 4.8 gives the same misleading error message.
8<8<8<8<
template
struct Base
{
};
struct Foo : Base
{ // error: expected class-name before ‘{’ token
};
template
struct Base2
{
};
struct Foo2 : Base2 // OK: wrong number of template arguments (1, should
be 2)
{
};
[Bug c/64442] -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442 --- Comment #3 from Mikael Pettersson --- See PR323 and https://gcc.gnu.org/bugs/#known You could experiment with -ffloat-store, -mpc64, or -msse2 (if your CPU supports SSE2, which it should if it isn't ancient).
[Bug c++/64446] Misleading error message when inheriting from a template class w/o the template params
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64446
--- Comment #1 from petschy at gmail dot com ---
One subtlety:
template
struct Base3
{
};
struct Foo3 : Base3
{
};
In this case complaining about missing template params is probably
inappropriate, since Base3<> is perfectly valid.
So on second thought, the error should be about the missing <> after the class
name.
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #16 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to H.J. Lu from comment #14)
>
> > This is generated in the backend:
>
> Yes, but the question is, why somehow similar testcase legitimizes the
> address correctly with -fpic, while the original testcase doesn't.
My impressions are most of PIC addresses like:
6: r92:DI=[const(unspec[`G'] 2)]
7: r91:DI=r92:DI
REG_EQUAL `G'
8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}
is generated by x86 backend vi ix86_expand_move and x86 backend was never
presented with other opportunities before. X86 backend isn't prepared to
handle some RTL expansions from offload.
[Bug target/64368] [5 Regression] Several libstdc++ test failures on darwin and others after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 --- Comment #12 from Jonathan Wakely --- Apologies, I should read emails more carefully when I'm ill, or not respond at all! I plan to spend time on this later this week. HNY all!
[Bug middle-end/64412] [regression] ICE in offload compiler: in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #17 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #16)
> > > This is generated in the backend:
> >
> > Yes, but the question is, why somehow similar testcase legitimizes the
> > address correctly with -fpic, while the original testcase doesn't.
>
> My impressions are most of PIC addresses like:
>
> 6: r92:DI=[const(unspec[`G'] 2)]
> 7: r91:DI=r92:DI
> REG_EQUAL `G'
> 8: {r90:DI=r89:DI+r91:DI;clobber flags:CC;}
>
> is generated by x86 backend vi ix86_expand_move and x86 backend was never
> presented with other opportunities before. X86 backend isn't prepared to
> handle some RTL expansions from offload.
The x86 backend did survive many years just fine, so I think offload should be
fixed to follow approach that generic middle-end takes. The testcase I posted
expands without problems; in this case middle-end knows that symbol address has
to be moved to a register. It looks like offload bypasses generic expansion
functions (that would magically fix this issue).
[Bug libstdc++/64438] Removing string-conversion requirement causes libstdc++-v3 fails on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438 --- Comment #1 from Jonathan Wakely --- That's strange, it should only affect targets that define _GLIBCXX_HAVE_BROKEN_VSWPRINTF i.e. only mingw What are the full errors in the libstdc++-v3/testsuite/libstdc++.log file?
[Bug libstdc++/64443] New std::string implementation breaks tests on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443 --- Comment #2 from Jonathan Wakely --- Probably the same issue as PR 64368 so it's probably a problem with the non-gnu clocale model.
[Bug c/64442] -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442 Colin Pitrat changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Colin Pitrat --- OK thank you, sorry for the bothering ! In the mean time I also discovered -Og that appeared in gcc 4.8, that provides optimization compatible with debugging and that have the same behavior. This allows me to have the same result with the release and the debug build, which is what was the issue for me. I'm still surprised by the fact that -Og or -O1 seems to be more than just the list of -f flags it activates, as providing only them doesn't trigger this same behaviour. I couldn't find another responsible flag in the difference I found in the output of --help=warnings,target,params,c or common Closing this bug as invalid. Regards, Colin
[Bug ipa/64447] New: [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 Bug ID: 64447 Summary: [5 Regression] FAIL: gcc.dg/vect/slp-9.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz On Linux/ia32, r219108 caused: FAIL: gcc.dg/vect/slp-9.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-9.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 1 FAIL: gcc.dg/vect/slp-9.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-9.c scan-tree-dump-times vect "vectorizing stmts using SLP" 1
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 David Edelsohn changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-30 CC||dje at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 Severity|normal |blocker --- Comment #1 from David Edelsohn --- Confirmed. This causes bootstrap failure on AIX. src/src/libstdc++-v3/src/c++11/system_error.cc:179:1: internal compiler error: in operator[], at vec.h:736 } // namespace ^
[Bug target/63596] Saving of GPR/FPRs for stdarg even though the variable argument is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63596 --- Comment #2 from Jiong Wang --- we are also lack of initialization for va_list_gpr_counter_field and va_list_vpr_counter_field, thus currently the whole tree-stdarg optimization doesn't work for AArch64, and lots of other targets, like arm, sparc, mips etc are lack of this vaarg opt tuning also.
[Bug libstdc++/64438] Removing string-conversion requirement causes libstdc++-v3 fails on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438 --- Comment #2 from Tejas Belagod --- (In reply to Jonathan Wakely from comment #1) > That's strange, it should only affect targets that define > _GLIBCXX_HAVE_BROKEN_VSWPRINTF i.e. only mingw > > What are the full errors in the libstdc++-v3/testsuite/libstdc++.log file? .../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/./gcc/xg++ -shared-libgcc -B.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/./gcc -nostdinc++ -L.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/src -L.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/src/.libs -L.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/libsupc++/.libs -B.../fsf-trunk/builds/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/bin/ -B.../fsf-trunk/builds/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/lib/ -isystem .../fsf-trunk/builds/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/include -isystem .../fsf-trunk/builds/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/sys-include -B.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf -I.../builds/fsf-trunk/fsf-trunk.593/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include -I.../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/libsupc++ -I.../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/include/backward -I.../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/util .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc -std=gnu++11 ./libtestc++.a -specs=aem-ve.specs -lm -mcmodel=small -fPIC -o ./dr1261.exe^M .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc: In function 'void test01()':^M .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc:31:32: error: 'to_string' was not declared in this scope^M const string one(to_string(-2));^M ^^M compiler exited with status 1 output is: .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc: In function 'void test01()':^M .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc:31:32: error: 'to_string' was not declared in this scope^M const string one(to_string(-2));^M ^^M FAIL: 21_strings/basic_string/numeric_conversions/char/dr1261.cc (test for excess errors) Excess errors: .../fsf-trunk/builds/fsf-trunk.593/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc:31:32: error: 'to_string' was not declared in this scope UNRESOLVED: 21_strings/basic_string/numeric_conversions/char/dr1261.cc compilation failed to produce executable extra_tool_flags are: -std=gnu++11
[Bug libstdc++/64443] New std::string implementation breaks tests on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64443 --- Comment #3 from Tejas Belagod --- (In reply to Andrew Pinski from comment #1) > >This commit seems to be breaking libstdc++-v3 runs on AArch64. > > Is this under Linux or with newlib? newlib. When run on a fast-model(simulator) they fail by raising an exception. I'll post more info on the kind of exception rasied when I've investigated a bit more...
[Bug target/53987] [SH] Unnecessary zero-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987 --- Comment #8 from Oleg Endo --- Author: olegendo Date: Tue Dec 30 17:26:18 2014 New Revision: 219110 URL: https://gcc.gnu.org/viewcvs?rev=219110&root=gcc&view=rev Log: gcc/testsuite/ PR target/53987 * gcc.target/sh/pr53987-1.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr53987-1.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/64448] New: New middle-end pattern breaks vector BIF folding on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64448
Bug ID: 64448
Summary: New middle-end pattern breaks vector BIF folding on
AArch64.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: belagod at gcc dot gnu.org
This new pattern
Author: mpolacek
Date: Wed Dec 17 11:48:33 2014 +
PR middle-end/63568
match.pd: Add (x & ~m) | (y & m) -> ((x ^ y) & m) ^ x pattern.
gcc.dg/pr63568.c: New test.
breaks BSL folding to a BIF on AArch64.
Causes this regression:
FAIL: gcc.target/aarch64/vbslq_u64_1.c scan-assembler-times bif\\tv 1
The code now generated is:
vbslq_dummy_u32:
eorv0.16b, v1.16b, v0.16b
andv0.16b, v0.16b, v2.16b
eorv0.16b, v1.16b, v0.16b
ret
.sizevbslq_dummy_u32, .-vbslq_dummy_
instead of:
vbslq_dummy_u32:
bifv0.16b, v1.16b, v2.16b
ret
.sizevbslq_dummy_u32, .-vbslq_dummy_u32
Optimized tree when folding happens:
vbslq_dummy_u32 (uint32x4_t a, uint32x4_t b, uint32x4_t mask)
{
__Uint32x4_t _3;
__Uint32x4_t _4;
__Uint32x4_t _6;
uint32x4_t _7;
:
_3 = mask_1(D) & a_2(D);
_4 = ~mask_1(D);
_6 = _4 & b_5(D);
_7 = _3 | _6;
return _7;
}
Optimized tree where folding does not happen:
vbslq_dummy_u32 (uint32x4_t a, uint32x4_t b, uint32x4_t mask)
{
__Uint32x4_t _3;
__Uint32x4_t _5;
uint32x4_t _6;
:
_3 = b_1(D) ^ a_2(D);
_5 = _3 & mask_4(D);
_6 = b_1(D) ^ _5;
return _6;
}
This will probably need another idiom to be caught by the BSL -> BIF folder.
[Bug target/63596] Saving of GPR/FPRs for stdarg even though the variable argument is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63596 --- Comment #3 from Andrew Pinski --- (In reply to Jiong Wang from comment #2) > we are also lack of initialization for va_list_gpr_counter_field and > va_list_vpr_counter_field, thus currently the whole tree-stdarg optimization > doesn't work for AArch64, and lots of other targets, like arm, sparc, mips > etc are lack of this vaarg opt tuning also. Yes but the two other server targets (x86 and PowerPC) don't lack this optimization.
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #23 from Oleg Endo --- Author: olegendo Date: Tue Dec 30 18:44:27 2014 New Revision: 219111 URL: https://gcc.gnu.org/viewcvs?rev=219111&root=gcc&view=rev Log: gcc/testsuite/ PR target/49263 * gcc.target/sh/pr49263-1.c: New. * gcc.target/sh/pr49263-2.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr49263-1.c trunk/gcc/testsuite/gcc.target/sh/pr49263-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #195 from Manuel López-Ibáñez --- (In reply to Martin von Gagern from comment #193) > Would it make sense to file one bug report per language, marking all of them > as blocking this one here, so we can keep track of progress per language? > I'm particularly interested in C++, but I guess others might care for other > front-ends. Feel free to do just that, specially if you are planning to work on it. This PR has become too long and full of outdated info (and useless comments) to be really useful.
[Bug c/64442] -O1 modify output of a simple computation with rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64442 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- (In reply to Colin Pitrat from comment #4) > In the mean time I also discovered -Og that appeared in gcc 4.8, that > provides optimization compatible with debugging and that have the same > behavior. This allows me to have the same result with the release and the > debug build, which is what was the issue for me. That seems fragile to me, that is, likely to not work for different testcases or compiler versions. The "official" (non-wiki) FAQ for this is seriously lacking info, and it is certainly a bug in many cases that GCC does not implement standard-mandated behavior for excess precission. Fortunately, this is (or should be) fixed for C. See https://gcc.gnu.org/wiki/FAQ#PR323 and the links therein. > I'm still surprised by the fact that -Og or -O1 seems to be more than just > the list of -f flags it activates, as providing only them doesn't trigger > this same behaviour. I couldn't find another responsible flag in the > difference I found in the output of --help=warnings,target,params,c or common https://gcc.gnu.org/wiki/FAQ#optimization-options
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #24 from Oleg Endo --- Author: olegendo Date: Tue Dec 30 19:11:42 2014 New Revision: 219113 URL: https://gcc.gnu.org/viewcvs?rev=219113&root=gcc&view=rev Log: gcc/testsuite/ PR target/49263 * gcc.target/sh/sh.exp (check_effective_target_sh2a): New. * gcc.target/sh/pr49263-3.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr49263-3.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/sh.exp
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Manuel López-Ibáñez changed: What|Removed |Added URL||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=323#c127 --- Comment #196 from Manuel López-Ibáñez --- I believe the latest status of this PR is explained by comment 127. I added this as the URL of the bug for people to find. Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general) is seriously lacking info and outdated. From now on, I'll point people to: https://gcc.gnu.org/wiki/FAQ#PR323
[Bug libstdc++/64438] Removing string-conversion requirement causes libstdc++-v3 fails on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-30 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- Oh, I think I'm just an idiot and shouldn't have changed those tests.
[Bug libstdc++/64449] New: /usr/ccs/bin/ld: Unsatisfied symbols: std::basic_string, std::allocator >::copy(wchar_t*, unsigned long, unsigned long)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64449 Bug ID: 64449 Summary: /usr/ccs/bin/ld: Unsatisfied symbols: std::basic_string, std::allocator >::copy(wchar_t*, unsigned long, unsigned long) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.00 hppa1.1-hp-hpux10.20 Target: hppa2.0w-hp-hpux11.00 hppa1.1-hp-hpux10.20 Build: hppa2.0w-hp-hpux11.00 hppa1.1-hp-hpux10.20 On hppa2.0w-hp-hpux11.00 in stage2, we have the following unsatisfied symbols: /xxx/gnu/gcc/objdir/./prev-gcc/xg++ -B/xxx/gnu/gcc/objdir/./prev-gcc/ -B/opt/gnu /gcc/gcc-5.0/hppa2.0w-hp-hpux11.00/bin/ -nostdinc++ -B/xxx/gnu/gcc/objdir/prev-h ppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs -B/xxx/gnu/gcc/objdir/prev-hppa2.0w- hp-hpux11.00/libstdc++-v3/libsupc++/.libs -I/xxx/gnu/gcc/objdir/prev-hppa2.0w-h p-hpux11.00/libstdc++-v3/include/hppa2.0w-hp-hpux11.00 -I/xxx/gnu/gcc/objdir/pr ev-hppa2.0w-hp-hpux11.00/libstdc++-v3/include -I/xxx/gnu/gcc/gcc/libstdc++-v3/l ibsupc++ -L/xxx/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs -L/xxx/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/libsupc++/.libs -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -W all -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wover loaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-str ings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o c c1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck. o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-array-notation .o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-form at.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c -family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-prin t.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-cilkplus.o c-family/ array-notation-common.o c-family/cilk.o c-family/c-ubsan.o default-c.o \ cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a l ibcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libc pp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../l ibdecnumber/libdecnumber.a -L/opt/gnu/gcc/gmp/lib -lmpc -lmpfr -lgmp -L../zlib -lz /usr/ccs/bin/ld: Unsatisfied symbols: std::basic_string, std::allocator >::copy(wchar_t*, unsigned long, unsigned long) const (first referenced in /xxx /gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs/libstdc++.a(co w-shim_facets.o)) (code) std::__cxx11::basic_string, std::allocator >::copy(wchar_t*, unsigned long, unsigned long) const (first reference d in /xxx/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs/libst dc++.a(cxx11-shim_facets.o)) (code) std::basic_string, std::allocator >::_Rep::_S_empty_rep_storage (first referenced in /xxx/gnu/gcc/objdir/prev-hpp a2.0w-hp-hpux11.00/libstdc++-v3/src/.libs/libstdc++.a(cow-shim_facets.o)) (data) wchar_t* std::basic_string, std::allocator >::_S_construct(wchar_t const*, wchar_t const*, std::a llocator const&, std::forward_iterator_tag) (first referenced in /xxx/g nu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs/libstdc++.a(cow- shim_facets.o)) (code) std::basic_string, std::allocator >::basic_string(wchar_t const*, std::allocator const&) (first referenc ed in /xxx/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.00/libstdc++-v3/src/.libs/libs tdc++.a(cow-shim_facets.o)) (code) collect2: error: ld returned 1 exit status With hppa1.1-hp-hpux10.20, we have: /xxx/gnu/gcc/objdir/./prev-gcc/xg++ -B/xxx/gnu/gcc/objdir/./prev-gcc/ -B/opt/gnu/gcc/gcc-5.0/hppa1.1-hp-hpux10.20/bin/ -nostdinc++ -B/xxx/gnu/gcc/objdir/prev-hp pa1.1-hp-hpux10.20/libstdc++-v3/src/.libs -B/xxx/gnu/gcc/objdir/prev-hppa1.1-hp- hpux10.20/libstdc++-v3/libsupc++/.libs -isystem /xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/include/hppa1.1-hp-hpux10.20 -isystem /xxx/gnu/gcc/ objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/include -isystem /xxx/gnu/gcc/gcc/libstdc++-v3/libsupc++ -L/xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc+ +-v3/src/.libs -L/xxx/gnu/gcc/objdir/prev-hppa1.1-hp-hpux10.20/libstdc++-v3/libsupc++/.libs -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-att ribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 --- Comment #2 from David Edelsohn --- Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> /home/dje/src/src/libstdc++-v3/src/c++98/bitmap_allocator.cc: At global scope: /home/dje/src/src/libstdc++-v3/src/c++98/bitmap_allocator.cc:127:1: internal compiler error: in inline_merge_summary, at ipa-inline-analysis.c:3611 } // namespace ^ #0 _Z11fancy_abortPKciS0_ ( file=0x122ab320 "/home/dje/src/src/gcc/ipa-inline-analysis.c", line=3611, function=0x122ac260 "inline_merge_summary") at /home/dje/src/src/gcc/diagnostic.c:1288 #1 0x10e5ff5c in _Z20inline_merge_summaryP11cgraph_edge (edge=0x70404480) at /home/dje/src/src/gcc/ipa-inline-analysis.c:3611 #2 0x11a26db4 in _Z11inline_callP11cgraph_edgebP3vecIS0_7va_heap6vl_ptrEPibPb (e=0x70404480, update_original=true, new_edges=, overall_size=0x30494f2c <_ipainline.bss_>, update_overall_summary=true, callee_removed=0x0) at /home/dje/src/src/gcc/ipa-inline-transform.c:326 #3 0x10fd7694 in _ZL22inline_small_functionsv () at /home/dje/src/src/gcc/ipa-inline.c:1813 #4 0x10fd8ebc in _ZL10ipa_inlinev () at /home/dje/src/src/gcc/ipa-inline.c:2185 #5 0x10fda344 in _ZN50_GLOBAL__N__Z20speculation_useful_pP11cgraph_edgeb15pass_ipa_inline7executeEP8function (this=0x304cfc28) at /home/dje/src/src/gcc/ipa-inline.c:2558 #6 0x101a4350 in _Z16execute_one_passP8opt_pass (pass=0x304cfc28) at /home/dje/src/src/gcc/passes.c:2311 #7 0x101a5924 in _Z21execute_ipa_pass_listP8opt_pass (pass=0x304cfc28) at /home/dje/src/src/gcc/passes.c:2708 #8 0x10d9f654 in _ZL10ipa_passesv () at /home/dje/src/src/gcc/cgraphunit.c:2124 #9 0x10d9faf8 in _ZN12symbol_table7compileEv (this=0x7000a000) at /home/dje/src/src/gcc/cgraphunit.c:2212 #10 0x10da0074 in _ZN12symbol_table25finalize_compilation_unitEv ( this=0x7000a000) at /home/dje/src/src/gcc/cgraphunit.c:2361 #11 0x106b9078 in _Z28cp_write_global_declarationsv () at /home/dje/src/src/gcc/cp/decl2.c:4742 #12 0x10002ca8 in _ZL12compile_filev () at /home/dje/src/src/gcc/toplev.c:584 #13 0x10006648 in _ZL10do_compilev () at /home/dje/src/src/gcc/toplev.c:2018 #14 0x10006a10 in _ZN6toplev4mainEiPPc (this=0x2ff22ab8, argc=7, argv=0x2ff22b68) at /home/dje/src/src/gcc/toplev.c:2115 #15 0x1740 in main (argc=7, argv=0x2ff22b68) at /home/dje/src/src/gcc/main.c:38
[Bug middle-end/64388] [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 --- Comment #1 from dave.anglin at bell dot net --- On 2014-12-23, at 12:31 PM, hjl.tools at gmail dot com wrote: > On Linux/x86-64, r219037 caused > > FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)" > FAIL: gcc.dg/pr44194-1.c scan-rtl-dump-not final "insn[: ][^\n]*set > \\(mem(?![^\n]*scratch)" The optimization could easily be restored if there was a procedure or target hook to provide a way to determine if a sibcall may read from the frame. On hppa-linux, this would be true if the sibcall arguments were all passed in registers. It might be possible to do this by analyzing the decl. The dse pass avoids looking at call usage information. -- John David Anglindave.ang...@bell.net
[Bug middle-end/64388] [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-30 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- (In reply to dave.anglin from comment #1) > On 2014-12-23, at 12:31 PM, hjl.tools at gmail dot com wrote: > > > On Linux/x86-64, r219037 caused > > > > FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)" > > FAIL: gcc.dg/pr44194-1.c scan-rtl-dump-not final "insn[: ][^\n]*set > > \\(mem(?![^\n]*scratch)" > > The optimization could easily be restored if there was a procedure or target > hook to provide a way > to determine if a sibcall may read from the frame. On hppa-linux, this > would be true if the sibcall > arguments were all passed in registers. It might be possible to do this by > analyzing the decl. Can you add such a hook? Thanks.
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #3 from John David Anglin --- And ICE on hppa2.0w-hp-hpux11.11: libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gc c/objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc+ +-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -L/ test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gn u/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux 11.11/lib/ -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/sys-include -I/test/gnu/gcc/gcc/libst dc++-v3/../libgcc -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/incl ude/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++ -v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-im plicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-s how-location=once -frandom-seed=eh_alloc.lo -g -O2 -c ../../../../gcc/libstdc++- v3/libsupc++/eh_alloc.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o eh_alloc.o ../../../../gcc/libstdc++-v3/libsupc++/eh_alloc.cc:211:1: internal compiler erro r: in inline_merge_summary, at ipa-inline-analysis.c:3611 } ^
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447
--- Comment #4 from Jan Hubicka ---
Hi,
the problem is that estimate_function_body_sizes frees ipa_free_all_node_params
when called late via add_new_function.
the following patch should fix it.
Honza
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c(revision 219108)
+++ ipa-inline-analysis.c(working copy)
@@ -2851,7 +2851,7 @@ estimate_function_body_sizes (struct cgr
{
if (!early)
loop_optimizer_finalize ();
- else
+ else if (!ipa_edge_args_vector)
ipa_free_all_node_params ();
free_dominance_info (CDI_DOMINATORS);
}
[Bug c++/64450] New: Optimize 0>=p-q to q>=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 Bug ID: 64450 Summary: Optimize 0>=p-q to q>=p for char*p,*q; Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at contacts dot eelis.net Created attachment 34365 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34365&action=edit Testcase It was noticed that Boost's iterator_facade incurred a performance penalty (while it should ideally be zero-overhead), which results from the fact that GCC does not optimize 0>=p-q to q>=p for char*p,*q;. See attachment. This probably applies to > and < and <= as well.
[Bug c++/64450] Optimize 0>=p-q to q>=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 Ville Voutilainen changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-30 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug fortran/64416] RFE: Support REAL128 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64416 --- Comment #1 from joseph at codesourcery dot com --- The Procedure Call Standard for the ARM Architecture does not include a 128-bit floating-point type, so if you want to support such a type in GCC for ARM you should first work with arm.e...@arm.com to define the associated ABI and get a new version of AAPCS released. Or you could use AArch64 - AAPCS64 does include such a type.
[Bug tree-optimization/64450] Optimize 0>=p-q to q>=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 --- Comment #1 from Marc Glisse --- See also PR61734, Eric already tried in May.
[Bug tree-optimization/64450] Optimize 0>=p-q to q>=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 --- Comment #2 from Andrew Pinski --- (In reply to Marc Glisse from comment #1) > See also PR61734, Eric already tried in May. Maybe it is easier to handle now with simplify-and-match.
[Bug target/64384] mingw-w64: stdcall function returning an aggregate is incompatible with MS ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384
daniel.c.klauer at web dot de changed:
What|Removed |Added
CC||daniel.c.klauer at web dot de
--- Comment #3 from daniel.c.klauer at web dot de ---
It seems there is a difference between gcc and ms with regards to return in
register for C++ methods (regardless of stdcall/cdecl/thiscall).
Tested with i686-w64-mingw32 gcc 4.9.2 and cl.exe from VS 2010:
struct A {
int field1;
};
struct A getA(void) {
struct A a = {123};
return a;
}
C function: both gcc and ms return in register (struct is small enough), ok.
struct A {
int field1;
};
class Test {
public:
A getA();
};
A Test::getA() {
struct A a = {123};
return a;
}
C++ method: ms returns in temp var on stack (as for big structs), but gcc
returns in register.
The same happens for struct containing two floats (as in the original crash
issue reported on mingw-w64 mailing list).
Maybe (on 32bit) ms never uses return in register for C++ methods with
aggregate result?
[Bug target/64451] New: tic6x-elf: ICE in extract_insn, at recog.c:2202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64451 Bug ID: 64451 Summary: tic6x-elf: ICE in extract_insn, at recog.c:2202 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yselkowi at redhat dot com While building gcc-4.9.2 --target=tic6x-elf with newlib-2.2.0: libtool: compile: /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/tic6x-elf/./gcc/xgcc -B/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/build/tic6x-elf/./gcc/ -B/usr/tic6x-elf/bin/ -B/usr/tic6x-elf/lib/ -isystem /usr/tic6x-elf/include -isystem /usr/tic6x-elf/sys-include -DHAVE_CONFIG_H -I. -I/usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp -Wall -g -ggdb -O2 -pipe -Wimplicit-function-declaration -MT ssp.lo -MD -MP -MF .deps/ssp.Tpo -c /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c -o ssp.o /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c: In function ‘fail.isra.0’: /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c:163:1: error: unrecognizable insn: } ^ (insn 111 110 112 16 (set (mem/v:SI (reg/f:SI 111) [3 MEM[(volatile int *)4294967295B]+0 S4 A8]) (unspec:SI [ (reg:SI 112) ] UNSPEC_MISALIGNED_ACCESS)) /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c:156 -1 (nil)) /usr/src/ports/cross-gcc/cross-gcc-4.9.2-1.x86_64/src/gcc-4.9.2/libssp/ssp.c:163:1: internal compiler error: in extract_insn, at recog.c:2202
[Bug middle-end/64388] [5 Regression] r219037 caused FAIL: gcc.dg/pr44194-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64388 --- Comment #3 from dave.anglin at bell dot net --- Hi H.J., On 2014-12-30, at 3:13 PM, hjl.tools at gmail dot com wrote: > Can you add such a hook? I'm sorry but realistically I don't have the spare time to work on this bug. Dave -- John David Anglindave.ang...@bell.net
[Bug target/64384] mingw-w64: stdcall function returning an aggregate is incompatible with MS ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384 --- Comment #4 from mity --- Daniel, COM interface should be, by definition, language agnostic. COM can be called from C++ as well as from C, and also COM object may be implemented in C++ as well as C. This implies that (at least for stdcall, as COM uses stdcall convention) there shouldn't be any difference between C and C++.
[Bug ipa/64444] [5 Regression] ICE: in inline_merge_summary, at ipa-inline-analysis.c:3611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Markus Trippelsdorf --- Fixed by r219114.
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Markus Trippelsdorf --- Fixed by r219114.
[Bug target/63681] ICE in cfg_layout_initialize, at cfgrtl.c:4233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681 --- Comment #6 from Yaakov Selkowitz --- (In reply to Mikael Pettersson from comment #5) > The ICE on bfin-elf started for 4.9 with r204985, and stopped for 5.0 with > r210683. Backporting r210683 to current 4.9 branch is easy and fixes the > ICE there too. I haven't checked c6x. r210683 fixes this particular issue in 4.9.2 for both bfin-elf and tic6x-elf. (There is another, seemingly unrelated issue with the latter, see bug 64451.) Any chance this could get into 4.9.3?
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- Comment #197 from Vincent Lefèvre --- (In reply to Manuel López-Ibáñez from comment #196) > Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general) > is seriously lacking info and outdated. From now on, I'll point people to: > https://gcc.gnu.org/wiki/FAQ#PR323 Note that this bug was mainly about the excess precision of x87 FPU, though its summary just says "optimized code gives strange floating point results". But the users should be aware that the floating-point results can still depend on the optimization level because this is allowed by the ISO C standard. For instance, if one has code like x*y+z, a FMA can be used or not depending on the target architecture and the optimization level (see also bug 37845 about this), and this can change the results.
[Bug ipa/64447] [5 Regression] FAIL: gcc.dg/vect/slp-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64447 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from H.J. Lu --- I still see: FAIL: gcc.dg/vect/slp-9.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-9.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 1 FAIL: gcc.dg/vect/slp-9.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-9.c scan-tree-dump-times vect "vectorizing stmts using SLP" 1 with r219114: https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg03418.html
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- Comment #198 from Manuel López-Ibáñez --- (In reply to Vincent Lefèvre from comment #197) > (In reply to Manuel López-Ibáñez from comment #196) > > Also, the official FAQ for this (https://gcc.gnu.org/bugs/#nonbugs_general) > > is seriously lacking info and outdated. From now on, I'll point people to: > > https://gcc.gnu.org/wiki/FAQ#PR323 > > Note that this bug was mainly about the excess precision of x87 FPU, though I added your comment to the FAQ but feel welcome to extend it: https://gcc.gnu.org/wiki/FAQ#PR323 What it is also missing is a criteria to distinguish normal behavior from actual GCC bugs (and there are GCC bugs like bug 37845 and others for optimizations that should only be done with ffast-math). Currently, any floating-point issue is likely to end up here.
