[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #56 from Richard Biener --- (In reply to rguent...@suse.de from comment #55) > On July 17, 2014 6:13:14 PM CEST, "thopre01 at gcc dot gnu.org" > wrote: > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 > > > >--- Comment #53 from thopre01 at gcc dot gnu.org --- > >(In reply to thopre01 from comment #52) > >> (In reply to Eric Botcazou from comment #51) > >> > > >> > TARGET_MEM_REF is supposed to be a valid memory access for the > >target though > >> > and, by definition, an unaligned access is not valid for a strict > >alignment > >> > target (unless you have a movmisalign pattern), so the problem is > >the > >> > TARGET_MEM_REF. > >> > >> So we just need to identify what changes the MEM_REF that bswap > >introduce > >> into a TARGET_MEM_REF without taking alignment into account. > >> > >> After bswap it's only a MEM_REF: > >> > >> load_dst_215 = MEM[(unsigned char *)load_src_277]; > > > >So it changes from a MEM_REF to a TARGET_MEM_REF in ivopts from a quick > >grep. I > >don't know how much this system but I can take a look after Cauldron > >where does > >this happen and bring the right person into this discussion. > > You need to fix may_be_unaligned (or similar) in ivopts. So actually that function now looks completely sane (thanks Eric). So I still need preprocessed source and a target triplet to configure a cross for. There must be missing may_be_unaligned_p calls in IVOPTs.
[Bug ipa/61885] New: [4.10 Regression] ICE: in types_same_for_odr, at ipa-devirt.c:383 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61885 Bug ID: 61885 Summary: [4.10 Regression] ICE: in types_same_for_odr, at ipa-devirt.c:383 with LTO Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: d.g.gorbachev at gmail dot com CC: hubicka at gcc dot gnu.org Target: i686-pc-linux-gnu Created attachment 33175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33175&action=edit Testcase GCC 4.10.0 20140720 (experimental). $ gcc -flto -nostdlib -shared PR-61885.C In function 'main': lto1: internal compiler error: in types_same_for_odr, at ipa-devirt.c:383 0x83d423a types_same_for_odr(tree_node const*, tree_node const*) ../../gcc-4.10/gcc/ipa-devirt.c:383 0x83d4274 get_class_context ../../gcc-4.10/gcc/ipa-devirt.c:1762 0x83d48b7 contains_type_p ../../gcc-4.10/gcc/ipa-devirt.c:1849 0x83da8d1 get_polymorphic_call_info(tree_node*, tree_node*, tree_node**, long long*, ipa_polymorphic_call_context*, gimple_statement_base*) ../../gcc-4.10/gcc/ipa-devirt.c:2161 0x81ddbbc cgraph_create_indirect_edge(cgraph_node*, gimple_statement_base*, int, long long, int) ../../gcc-4.10/gcc/cgraph.c:970 0x81e173f rebuild_cgraph_edges() ../../gcc-4.10/gcc/cgraphbuild.c:453 Please submit a full bug report, with preprocessed source if appropriate. Appeared in 212128 < r <= 212315.
[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez --- Is this something new? Dodji made some changes recently to the location of built-in tokens.
[Bug lto/61886] New: [4.8/4.9/4.10 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
Bug ID: 61886
Summary: [4.8/4.9/4.10 Regression] LTO breaks fread with
_FORTIFY_SOURCE=2
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Keywords: diagnostic, lto, wrong-code
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Created attachment 33176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33176&action=edit
testcase extracted from cairo test suite
With the attached testcase extracted from the Cairo testsuite (which they build
with -flto ...) you get
> gcc-4.9 create-for-stream.i -O2 -flto -r -nostdlib
In function ‘__fread_alias’,
inlined from ‘test_surface’ at create-for-stream.c:218:9:
/usr/include/bits/stdio2.h:290:2: warning: call to ‘__fread_chk_warn’ declared
with attribute warning: fread called with bigger size * nmemb than length of
destination buffer
return __fread_chk (__ptr, __bos0 (__ptr), __size, __n, __stream);
^
where we mangle compile-time
:
_55 = wc.index;
_77 = __builtin_constant_p (_55);
if (_77 == 0)
goto ;
else
goto ;
:
_78 = _55 | 1;
if (_78 > 4294967295)
goto ;
else
goto ;
:
_79 = __fread_chk (&file_contents, 4096, 1, _55, fp_48);
goto ;
:
if (_55 > 4096)
goto ;
else
goto ;
:
_81 = *__fread_chk (&file_contents, 4096, 1, _55, fp_48);
goto ;
:
_82 = *fread (&file_contents, 1, _55, fp_48);
:
# _83 = PHI <_79(15), _81(17), _82(18)>
into the bogus
:
_49 = wc.index;
_64 = __builtin_constant_p (_49);
if (_64 == 0)
goto ;
else
goto ;
:
_65 = _49 | 1;
if (_65 > 4294967295)
goto ;
else
goto ;
:
_66 = __fread_chk_warn (&file_contents, 4096, 1, _49, fp_43);
goto ;
:
if (_49 > 4096)
goto ;
else
goto ;
:
_67 = __fread_chk_warn (&file_contents, 4096, 1, _49, fp_43);
goto ;
:
_68 = __fread_alias (&file_contents, 1, _49, fp_43);
:
# _69 = PHI <_66(15), _67(17), _68(18)>
somehow messing up the aliases game glibc plays:
extern size_t __fread_chk (void *__restrict __ptr, size_t __ptrlen,
size_t __size, size_t __n,
FILE *__restrict __stream) __wur;
extern size_t __REDIRECT (__fread_alias,
(void *__restrict __ptr, size_t __size,
size_t __n, FILE *__restrict __stream),
fread) __wur;
extern size_t __REDIRECT (__fread_chk_warn,
(void *__restrict __ptr, size_t __ptrlen,
size_t __size, size_t __n,
FILE *__restrict __stream),
__fread_chk)
__wur __warnattr ("fread called with bigger size * nmemb than length "
"of destination buffer");
__fortify_function __wur size_t
fread (void *__restrict __ptr, size_t __size, size_t __n,
FILE *__restrict __stream)
{
if (__bos0 (__ptr) != (size_t) -1)
{
if (!__builtin_constant_p (__size)
|| !__builtin_constant_p (__n)
|| (__size | __n) >= (((size_t) 1) << (8 * sizeof (size_t) / 2)))
return __fread_chk (__ptr, __bos0 (__ptr), __size, __n, __stream);
if (__size * __n > __bos0 (__ptr))
return __fread_chk_warn (__ptr, __bos0 (__ptr), __size, __n, __stream);
}
return __fread_alias (__ptr, __size, __n, __stream);
}
Merging nodes for *__fread_chk. Candidates:
*__fread_chk/98 (__fread_chk_warn) @0x76dc2b80
Type: function
Visibility: undef external public
next sharing asm name: 97
References:
Referring:
Read from file: /tmp/ccu88pge.o
First run: 0
Function flags:
Called by: test_surface/78
Calls:
__fread_chk/97 (__fread_chk) @0x76dc2cf0
Type: function
Visibility: external public
previous sharing asm name: 98
References:
Referring:
Read from file: /tmp/ccu88pge.o
First run: 0
Function flags:
Called by: test_surface/78 (0.00 per call)
After resolution:
*__fread_chk/98 (__fread_chk_warn) @0x76dc2b80
Type: function
Visibility: undef external public
next sharing asm name: 97
References:
Referring:
Read from file: /tmp/ccu88pge.o
First run: 0
Function flags:
Called by: test_surface/78
Calls:
__fread_chk/97 (__fread_chk) @0x76dc2cf0
Type: function
Visibility: external public
previous sharing asm name: 98
References:
Referring:
Read from file: /tmp/ccu88pge.o
First run: 0
Function flags:
Called by: test_surface/78 (0.00 per call)
Calls:
but we obviously shouldn't merge these ...
(I believe we shouldn't drop any aliases at LTO symbol merging time, which
means _not_ merging based on asm-name?)
[Bug lto/61886] [4.8/4.9/4.10 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.4
[Bug lto/61886] [4.8/4.9/4.10 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #1 from Richard Biener --- Btw, it seems that at the point we merge in lto-symtab.c the cgraph nodes are not yet populated. Neither of the two candidates are marked as alias. So maybe the wrong thing already happens earlier, during compile-time and we shouldn't do any symtab merging? at least from symbols originating from the same TU? That is, tree merging already should catch most true equivalencies and cgraph merging shouldn't be symtab-driven? That said, I wonder how to fix things up properly. The following fixes the testcase, not merging the actual symtab intra-TU and retaining decls that have a symtab entry recorded. Index: gcc/lto/lto-symtab.c === --- gcc/lto/lto-symtab.c(revision 212927) +++ gcc/lto/lto-symtab.c(working copy) @@ -575,6 +575,9 @@ lto_symtab_merge_symbols_1 (symtab_node if (!lto_symtab_symbol_p (e)) continue; + /* Do not merge symtab nodes originating from the same TU. */ + if (e->lto_file_data == prevailing->lto_file_data) + continue; cgraph_node *ce = dyn_cast (e); if (ce && !DECL_BUILT_IN (e->decl)) lto_cgraph_replace_node (ce, cgraph (prevailing)); @@ -680,6 +683,12 @@ lto_symtab_prevailing_decl (tree decl) if (TREE_CODE (decl) == FUNCTION_DECL && DECL_BUILT_IN (decl)) return decl; + /* If the decl retained its symtab node then it prevails. This + preserves semantically different decls for the same underlying + symbol, like aliases that have been resolved at compile-time. */ + if (symtab_get_node (decl)) +return decl; + /* Ensure DECL_ASSEMBLER_NAME will not set assembler name. */ gcc_assert (DECL_ASSEMBLER_NAME_SET_P (decl));
[Bug lto/61886] [4.8/4.9/4.10 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
Richard Biener changed:
What|Removed |Added
Known to work||4.7.4
Known to fail||4.10.0, 4.8.3, 4.9.1
--- Comment #2 from Richard Biener ---
I'm testing the patch, testcase:
/* { dg-lto-do link } */
/* { dg-lto-options { { -flto -O2 -Werror } } } */
typedef __SIZE_TYPE__ size_t;
typedef struct _IO_FILE FILE;
extern size_t __fread_chk_warn (void *__restrict __ptr, size_t __ptrlen, size_t
__size, size_t __n, FILE *__restrict __stream) __asm__ ("" "__fread_chk")
__attribute__ ((__warn_unused_result__)) __attribute__((__warning__ ("fread
called with bigger size * nmemb than length " "of destination buffer")));
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) __attribute__ ((__artificial__)) __attribute__
((__warn_unused_result__))
size_t
fread (void *__restrict __ptr, size_t __size, size_t __n,
FILE *__restrict __stream)
{
if (__builtin_object_size (__ptr, 0) != (size_t) -1)
{
if (!__builtin_constant_p (__size)
|| !__builtin_constant_p (__n)
|| (__size | __n) >= (((size_t) 1) << (8 * sizeof (size_t) / 2)))
return __fread_chk (__ptr, __builtin_object_size (__ptr, 0), __size,
__n, __stream);
if (__size * __n > __builtin_object_size (__ptr, 0))
return __fread_chk_warn (__ptr, __builtin_object_size (__ptr, 0),
__size, __n, __stream);
}
}
volatile size_t nmemb;
FILE *fp;
int main ()
{
char file_contents[4096];
/* We shouldn't get this resolved to a call to __fread_chk_warn. */
return fread (file_contents, 1, nmemb, fp);
}
[Bug ipa/61884] [4.10 Regression] g++.dg/ipa/pr61085.C FAILs with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61884 Martin Jambor changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org --- Comment #1 from Martin Jambor --- This has been introduced by Honza's r212304 (introduction of param_type_may_change_p).
[Bug regression/61887] New: vect.exp UNRESOLVED tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61887
Bug ID: 61887
Summary: vect.exp UNRESOLVED tests
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: m.zakirov at samsung dot com
I found that some tests from vect.exp has status UNRESOLVED in cureent compiler
version due to dissynchronization of compiler dumpers and tests check.
Example:
Test bb-slp-10.c awaits for name
bb-slp-10.c.124t.slp
but it gets this
bb-slp-10.c.124t.slp2
Open bb-slp-10.c
Change "slp" to "slp2" in
...
/* { dg-final { scan-tree-dump-times "unsupported alignment in basic block." 1
"slp" { xfail vect_element_align } } } */
/* { dg-final { scan-tree-dump-times "basic block vectorized using SLP" 1 "slp"
{ target vect_element_align } } } */
Test will pass or at least it won't have UNRESOLVED status.
Another UNRESOLVED example vect-105-big-array.c and generaly all tests with
scan-tree-dump-times and -flto option.
-flto makes gcc to create file with name
vect-105-big-array.exe.ltrans0.114t.vect
Which is obviosly not supported too.
Configuration:
/home/mzakirov/proj/gcc_unalign/build.arm.cortex-a15/sources/gcc_1/configure
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=arm-linux-gnueabi --with-interwork --enable-long-long
--enable-languages=c,c++,fortran --enable-shared --with-gnu-as --with-gnu-ld
--with-arch=armv7-a
Run tests:
make -k check RUNTESTFLAGS='vect.exp'
--Marat
[Bug regression/61887] vect.exp UNRESOLVED tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61887 --- Comment #1 from Marat Zakirov --- This issue is suitible for ARM
[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861
--- Comment #5 from Marek Polacek ---
It looks like a pretty old issue. E.g. on
void
foo (void)
{
__FILE__;
"foo";
}
4.8 says:
r.c: In function ‘foo’:
r.c:4:1: warning: statement with no effect [-Wunused-value]
__FILE__;
^
r.c:5:3: warning: statement with no effect [-Wunused-value]
"foo";
^
See how that first caret is off. I have an untested patch that should fix
this.
[Bug lto/61886] [4.8/4.9/4.10 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #3 from Richard Biener --- Fails LTO bootstrap with /abuild/rguenther/obj/./prev-gcc/xg++ -B/abuild/rguenther/obj/./prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/space/rguenther/src/svn/trunk/libstdc++-v3/libsupc++ -L/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/abuild/rguenther/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o build/genhooks \ build/genhooks.o build/errors.o .././libiberty/libiberty.a lto1: internal compiler error: in maybe_add_reference, at symtab.c:613 0x68a129 symtab_node::maybe_add_reference(tree_node*, ipa_ref_use, gimple_statement_base*) /space/rguenther/src/svn/trunk/gcc/symtab.c:613 0x6a16de cgraph_create_virtual_clone(cgraph_node*, vec, vec*, bitmap_head*, char const*) /space/rguenther/src/svn/trunk/gcc/cgraphclones.c:582 0x12ca0e5 create_specialized_node /space/rguenther/src/svn/trunk/gcc/ipa-cp.c:2802 0x12ce757 decide_whether_version_node /space/rguenther/src/svn/trunk/gcc/ipa-cp.c:3556 0x12ce8d3 ipcp_decision_stage /space/rguenther/src/svn/trunk/gcc/ipa-cp.c:3668 0x12cef4d ipcp_driver /space/rguenther/src/svn/trunk/gcc/ipa-cp.c:3714 0x12cefba execute /space/rguenther/src/svn/trunk/gcc/ipa-cp.c:3805
[Bug ipa/61885] [4.10 Regression] ICE: in types_same_for_odr, at ipa-devirt.c:383 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61885 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug ipa/61884] [4.10 Regression] g++.dg/ipa/pr61085.C FAILs with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61884 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug regression/61887] vect.exp UNRESOLVED tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61887 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- That was me, "splitting" slp into slp1 and slp2. I've only able to run the x86 part of the testsuite - any update on the rest is appreciated.
[Bug middle-end/61876] Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-23 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Interestingly my manual page says ERRORS See math_error(7) for information on how to determine whether an error has occurred when calling these functions. The following errors can occur: Domain error: x is a NaN or infinite, or the rounded value is too large An invalid floating-point exception (FE_INVALID) is raised. These functions do not set errno. But C99 specifies only that the functions may raise a 'range error' (as opposed to a domain error). That said - 'errno' handling is a tricky area... Confirmed. The fix is to properly guard the transform, calling a function that the may set errno is wrong-code.
[Bug c/61846] gcc assumes errno might be negative and issues unnecessary warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846 --- Comment #5 from Zbigniew Jędrzejewski-Szmek --- (In reply to Andrew Pinski from comment #4) > C99 also has this requirement. But C89 did not. The warnings are "best effort" anyway. So even if the standards did *not* say that, gcc could skip the warning since existing systems all work this way anyway. I think it could make for a nice optimization, when compiling for C99, but that is not what I'm asking for atm. > >Values for errno are now required to be distinct positive values rather than > > non-zero values. This change is for alignment with the ISO/IEC 9899:1999 > > standard. > > So using -std=gnu99 should allow this to not be unitilaized except GCC has > no way to know you are reading from errno just yet. Wouldn't it be a matter of annotating read() call with the sideffect of "return value >= 0 || errno > 0" ?
[Bug c++/61872] Assigning to "long double" causes memset to be improperly elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61872
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2014-07-23
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed, mine.
int main()
{
long double a;
__builtin_memset(&a, '\0', sizeof(long double));
a = 1.0;
long double b;
__builtin_memset(&b, '\0', sizeof(long double));
b = 1.0;
if (__builtin_memcmp(&a, &b, sizeof(long double)))
__builtin_abort ();
return 0;
}
[Bug target/61872] Assigning to "long double" causes memset to be improperly elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61872 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|ASSIGNED|NEW CC||ebotcazou at gcc dot gnu.org Component|c++ |target Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #2 from Richard Biener --- Err, not exactly mine but the issue is that we have (insn 6 5 7 (set (mem/c:DI (reg:DI 85) [0 MEM[(void *)&a]+0 S8 A128]) (const_int 0 [0])) t.c:5 -1 (nil)) (insn 7 6 0 (set (mem/c:DI (plus:DI (reg:DI 85) (const_int 8 [0x8])) [0 MEM[(void *)&a]+8 S8 A64]) (const_int 0 [0])) t.c:5 -1 (nil)) ... (insn 9 8 0 (set (mem/c:XF (plus:DI (reg/f:DI 78 virtual-stack-vars) (const_int -16 [0xfff0])) [0 a+0 S16 A128]) (float_extend:XF (reg:SF 86))) t.c:6 -1 (nil)) but the actual store via fstpt is _not_ 16 bytes. Thus the XFmode store for some reason got a MEM_SIZE of 16. And RTL DSE only looks at MEM_SIZE. And even the default mode_mem_attrs[XFmode] have 16 bytes size. And mode_size[XFmode] is 16. But FRACTIONAL_FLOAT_MODE (XF, 80, 12, ieee_extended_intel_96_format); ?! Making target dependent for now.
[Bug target/61872] Assigning to "long double" causes memset to be improperly elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61872 --- Comment #3 from Richard Biener --- Old value = 12 '\f' New value = 16 '\020' init_adjust_machine_modes () at insn-modes.c:1069 1066 /* config/i386/i386-modes.def:34 */ 1067 s = TARGET_128BIT_LONG_DOUBLE ? 16 : 12; 1068 mode_size[XFmode] = s; 1069 mode_base_align[XFmode] = s & (~s + 1); /* In ILP32 mode, XFmode has size 12 and alignment 4. In LP64 mode, XFmode has size and alignment 16. */ ADJUST_FLOAT_FORMAT (XF, (TARGET_128BIT_LONG_DOUBLE ? &ieee_extended_intel_128_format : TARGET_96_ROUND_53_LONG_DOUBLE ? &ieee_extended_intel_96_round_53_format : &ieee_extended_intel_96_format)); ok, but with that you need to adjust the insns to actually store 16bits. Target bug.
[Bug c++/61870] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61870 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.7.3 --- Comment #3 from Richard Biener --- Fixed in 4.7.3.
[Bug c++/61867] gcc can't detect obviously false test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61867 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Richard Biener --- Indeed we don't want to warn here. The knowledge is spread across two different statements and that's already too far for this kind of thing. Remember we just "weakened" the transposed memset arg warning to not warn about n = 0; memset (p, 'x', n); but only about memset (p, 'x', 0);
[Bug middle-end/61853] [4.9/4.10 Regression] ICE: SIGSEGV in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61853 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.2 Summary|[4.9,4.10 Regression] ICE: |[4.9/4.10 Regression] ICE: |SIGSEGV in store_field |SIGSEGV in store_field
[Bug ipa/61842] [4.10 Regression]: Firefox start-up SEGFAULT with LTO and O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61842 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug tree-optimization/61839] More optimize opportunity for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61839
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-07-23
Summary|More optimize opportunity |More optimize opportunity
||for VRP
Ever confirmed|0 |1
Known to fail||4.10.0
--- Comment #1 from Richard Biener ---
Confirmed. This is straight-line (A) code vs. if-code (B) that makes the
difference, introduced by fold already:
--- a/t.c.003t.original 2014-07-23 14:48:48.984335370 +0200
+++ b/t.c.003t.original 2014-07-23 14:46:19.224345681 +0200
@@ -11,7 +11,7 @@
int a = -1;
volatile unsigned int b = 1;
int c = 1;
- c = b != 0 ? 486097858 : 972195717;
+ c = a + 972195718 >> (b != 0);
if (c == 486097858)
{
(void) 0;
in the bad case we have
:
b ={v} 1;
b.0_3 ={v} b;
_4 = b.0_3 != 0;
_5 = (int) _4;
c_6 = 972195717 >> _5;
if (c_6 == 486097858)
...
until the very end, not transforming c_6. Note that VRP could do the
missing transform as it knows that _5 is [0, 1] (it has to jump through
the shift - the value-range for the shift itself is too broad).
If written this kind of transform should be applied more generally, not
just for shifts. It basically wants to ask whether a conditional test
can be carried out against another SSA name (and another constant) if
an intermediate compute can be omitted in that case.
[Bug middle-end/61876] Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876 ktkachov at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- > Confirmed. The fix is to properly guard the transform, calling a function > that the may set errno is wrong-code. I can spin a patch for that.
[Bug lto/61886] [4.8/4.9/4.10 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #4 from Richard Biener ---
Fully preprocessed glibc fread stuff (reduced testcase drops main path
and a prototype for __fread_chk):
extern size_t __fread_chk (void *__restrict __ptr, size_t __ptrlen,
size_t __size, size_t __n,
FILE *__restrict __stream) __attribute__ ((__warn_unused_result__));
extern size_t __fread_alias (void *__restrict __ptr, size_t __size, size_t __n,
FILE *__restrict __stream) __asm__ ("" "fread")
__attribute__ ((__warn_unused_result__));
extern size_t __fread_chk_warn (void *__restrict __ptr, size_t __ptrlen, size_t
__size, size_t __n, FILE *__restrict __stream) __asm__ ("" "__fread_chk")
__attribute__ ((__warn_unused_result__)) __attribute__((__warning__
("fread called with bigger size * nmemb than length " "of destination
buffer")))
;
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) __attribute__ ((__artificial__)) __attribute__
((__warn_unused_result__)) size_t
fread (void *__restrict __ptr, size_t __size, size_t __n,
FILE *__restrict __stream)
{
if (__builtin_object_size (__ptr, 0) != (size_t) -1)
{
if (!__builtin_constant_p (__size)
|| !__builtin_constant_p (__n)
|| (__size | __n) >= (((size_t) 1) << (8 * sizeof (size_t) / 2)))
return __fread_chk (__ptr, __builtin_object_size (__ptr, 0), __size, __n,
__stream);
if (__size * __n > __builtin_object_size (__ptr, 0))
return __fread_chk_warn (__ptr, __builtin_object_size (__ptr, 0), __size, __n,
__stream);
}
return __fread_alias (__ptr, __size, __n, __stream);
}
[Bug fortran/61888] New: Wrong results with SIZEOF and assumed-rank arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61888
Bug ID: 61888
Summary: Wrong results with SIZEOF and assumed-rank arrays
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Per https://gcc.gnu.org/onlinedocs/gfortran/SIZEOF.html, SIZEOF is an inquiry
function (and GNU extension); that's in line with C_SIZEOF. However, the code
doesn't reflect this. That's fixed by:
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -2768 +2768 @@ add_functions (void)
- add_sym_1 ("sizeof", GFC_ISYM_SIZEOF, CLASS_IMPURE, ACTUAL_NO, BT_INTEGER,
ii,
+ add_sym_1 ("sizeof", GFC_ISYM_SIZEOF, CLASS_INQUIRY, ACTUAL_NO, BT_INTEGER,
ii,
After doing so, the following test case shows that the size is wrongly
calculated for assumed-rank arrays.
Additionally, one should check whether c_sizeof() should be permitted in this
case. It currently fails with "Error: 'x' argument of 'c_sizeof' intrinsic at
(1) must be an interoperable data entity: Only explicit-size and assumed-size
arrays are interoperable". One has to decipher TS29113 whether those should be
permitted for c_sizeof or not.
use iso_c_binding
implicit none
integer, pointer :: ptr(:)
allocate(ptr(10))
call foo(ptr)
call bar(ptr)
contains
subroutine foo(x)
integer, dimension(:) :: x
print *, sizeof(x) ! Prints EXPECTED: 40
end
subroutine bar(x)
integer, dimension(..) :: x
print *, sizeof(x) ! WRONG: Prints 4
end
end
[Bug preprocessor/61832] [4.10 Regression] r212638 breaks building ncurses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61832 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.10.0 Summary|r212638 breaks building |[4.10 Regression] r212638 |ncurses |breaks building ncurses
[Bug lto/61886] [4.8/4.9/4.10 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-23 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Jan Hubicka --- This is a difficult problem. In early cgraph days GCC code was converted to assume that there are never duplicated declarations of a given symbol. This is precisely what glibc does to keep these duplicates flow through the compilation. It is a long standing bug that we have such duplicate declarations and that we do not reject these as an error or fix internaly. A clear fix would be to make alias from glibc SO for fread_chk and fread_chk_warn that can be used for those two different calls. But without changling glibc's API we need to work out how to introduce the alias internally. We support similar bookeeping for wearkrefs that are "syntactic" aliases resulting in the same assembler name as their target. I suppose we can do the same here, but it is ugly - I would much preffer those hacks to not exist at all. I will try to prepare patch and see how contained it is. Honza
[Bug target/61396] [4.10 regression] ICE in simplify_immed_subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61396 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Segher Boessenkool --- Fixed.
[Bug gcov-profile/61889] New: [4.10 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Bug ID: 61889 Summary: [4.10 Regression] gcov-tool.c uses nftw, ftw.h Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: rai...@emrich-ebersheim.de Bootstrap fails: g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macr os -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-4.10.0/gcc -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-4.10.0/gcc/. -I../../../../../../../opt/devel/gnu/src /gcc-mingw-w64/gcc-4.10.0/gcc/../include -I./../intl -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-4.10.0/gcc/../libcpp/include -I/opt/devel/SCRATCH/tmp.s61dWEwM1g/install/include -I/opt/devel/SCRATCH/tmp.s61dWEwM1g/instal l/include -I/opt/devel/SCRATCH/tmp.s61dWEwM1g/install/include -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-4.10.0/gcc/../libdecnumber -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-4.10.0/gcc/../libdecnumber/ bid -I../libdecnumber -I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-4.10.0/gcc/../libbacktrace -DCLOOG_INT_GMP -I/opt/devel/SCRATCH/tmp.s61dWEwM1g/install/include -I/opt/devel/SCRATCH/tmp.s61dWEwM1g/install/include -o gco v-tool.o -MT gcov-tool.o -MMD -MP -MF ./.deps/gcov-tool.TPo ../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-4.10.0/gcc/gcov-tool.c ../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-4.10.0/gcc/gcov-tool.c:38:17: fatal error: ftw.h: No such file or directory #include ^ compilation terminated. Makefile:1063: recipe for target 'gcov-tool.o' failed make: *** [gcov-tool.o] Error 1 This is not very portable and breaks bootstrap for mingw targets sine nearly two weeks.
[Bug gcov-profile/61889] [4.10 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Richard Biener changed: What|Removed |Added Keywords||build Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-23 CC||xinliangli at gmail dot com Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Please fix (for example by providing nftw from libiberty).
[Bug libgcc/61685] Strange check in bid128_fma.c - rounding_correction()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61685 --- Comment #1 from hjl at gcc dot gnu.org --- Author: hjl Date: Wed Jul 23 14:27:55 2014 New Revision: 212942 URL: https://gcc.gnu.org/viewcvs?rev=212942&root=gcc&view=rev Log: Remove redundant tests PR libgcc/61685 * bid128_fma.c (rounding_correction): Remove redundant tests. Modified: trunk/libgcc/config/libbid/ChangeLog trunk/libgcc/config/libbid/bid128_fma.c
[Bug libgcc/61685] Strange check in bid128_fma.c - rounding_correction()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61685 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #2 from H.J. Lu --- Fixed.
[Bug gcov-profile/61889] [4.10 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #2 from Kai Tietz ---
Yes, issue is here that ftw API is used for cleanup.
...
static int
unlink_profile_dir (const char *path)
{
return nftw(path, unlink_gcda_file, 64, FTW_DEPTH | FTW_PHYS);
}
...
This method isn't present on none glibc-systems. So there should be at least a
header-check (HAVE_FTW_H) be added to gcov-tool.c and to configure.
As Richard mentioned, libiberty would be a good place to add implementation.
[Bug target/55701] Inline some instances of memset for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55701 --- Comment #4 from amker at gcc dot gnu.org --- Author: amker Date: Wed Jul 23 16:02:15 2014 New Revision: 212948 URL: https://gcc.gnu.org/viewcvs?rev=212948&root=gcc&view=rev Log: Revert r212893: PR target/55701 * config/arm/arm.md (setmem): New pattern. * config/arm/arm-protos.h (struct tune_params): New fields. (arm_gen_setmem): New prototype. * config/arm/arm.c (arm_slowmul_tune): Initialize new fields. (arm_fastmul_tune, arm_strongarm_tune, arm_xscale_tune): Ditto. (arm_9e_tune, arm_v6t2_tune, arm_cortex_tune): Ditto. (arm_cortex_a8_tune, arm_cortex_a7_tune): Ditto. (arm_cortex_a15_tune, arm_cortex_a53_tune): Ditto. (arm_cortex_a57_tune, arm_cortex_a5_tune): Ditto. (arm_cortex_a9_tune, arm_cortex_a12_tune): Ditto. (arm_v7m_tune, arm_v6m_tune, arm_fa726te_tune): Ditto. (arm_const_inline_cost): New function. (arm_block_set_max_insns): New function. (arm_block_set_non_vect_profit_p): New function. (arm_block_set_vect_profit_p): New function. (arm_block_set_unaligned_vect): New function. (arm_block_set_aligned_vect): New function. (arm_block_set_unaligned_non_vect): New function. (arm_block_set_aligned_non_vect): New function. (arm_block_set_vect, arm_gen_setmem): New functions. PR target/55701 * gcc.target/arm/memset-inline-1.c: New test. * gcc.target/arm/memset-inline-2.c: New test. * gcc.target/arm/memset-inline-3.c: New test. * gcc.target/arm/memset-inline-4.c: New test. * gcc.target/arm/memset-inline-5.c: New test. * gcc.target/arm/memset-inline-6.c: New test. * gcc.target/arm/memset-inline-7.c: New test. * gcc.target/arm/memset-inline-8.c: New test. * gcc.target/arm/memset-inline-9.c: New test. Revert r212892: * config/arm/arm.c (output_move_neon): Handle REG explicitly. Removed: trunk/gcc/testsuite/gcc.target/arm/memset-inline-1.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-2.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-3.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-4.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-5.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-6.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-7.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-8.c trunk/gcc/testsuite/gcc.target/arm/memset-inline-9.c Modified: trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 --- Comment #9 from Jan Hubicka --- Created attachment 33177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33177&action=edit Proposed patch I guess the problem is that error_mark_node is special cased in varasm to send symbols to BSS for invalid programs. Does the following help?
[Bug libstdc++/61667] setting max_load_factor of unordered_map cause buckets shrink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61667 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org --- Comment #2 from François Dumont --- I just wanted to give a way to shrink unordered containers representation through a rehash call as long as it was Standard compliant, and it is I think. Even the classic copy and swap won't work on this type of container. Having it shrink on call to max_load_factor was also plan but I must confess that in the provided code it is quite inconvenient. An easy workaround is to call m.reserve(20) after the call to max_load_factor. I can change the code to limit the shink behavior to rehash calls or I can change it to do as you propose Jonathan allowing no shrinking except by rebuilding a new instance from an iterator range and then swap.
[Bug ipa/61890] New: [4.10 Regression] g++.dg/ipa/devirt-23.C FAILs with -O2 -fno-devirtualize-speculatively -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61890 Bug ID: 61890 Summary: [4.10 Regression] g++.dg/ipa/devirt-23.C FAILs with -O2 -fno-devirtualize-speculatively -fno-guess-branch-probability Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 33178 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33178&action=edit preprocessed source (g++.dg/ipa/devirt-23.C) Output: $ g++ -O2 -fno-devirtualize-speculatively -fno-guess-branch-probability devirt-23.ii $ ./a.out Aborted Tested revisions: trunk r212932 - FAIL 4_9 r212703 - OK
[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857 --- Comment #6 from Andrew Ayer --- Any word on if this will be fixed in GCC? To summarize, GCC's current behavior is wrong because: * Underflowing after ignoring the requested number of bytes could block forever, breaking applications. * The standard says "characters are extracted until ANY of the following occurs: ... n characters are extracted" (emphasis mine). If ignore() blocks forever after extracting n characters, it's a violation of the standard because it doesn't terminate as is required. * GCC's std::basic_istream::read() implementation does NOT underflow after reading the requested number of bytes (even though the standard uses similar language for read and ignore). This inconsistent behavior is confusing as one would expect read and ignore to behave equivalently. * Other major C++ implementations don't underflow after ignoring the requested number of bytes. (Thanks, Sergey, for checking this.) I wrote about this in greater depth at [1] and also wrote my own non-member ignore() which I'm using in place of basic_istream::ignore() [2] which others may find useful until this bug is fixed. [1] https://www.agwa.name/blog/post/gccs_implementation_of_basicistreamignore_is_broken [2] https://www.agwa.name/blog/post/gccs_implementation_of_basicistreamignore_is_broken/media/ignore.h
[Bug target/61396] [4.10 regression] ICE in simplify_immed_subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61396 --- Comment #7 from Mike Stump --- So when you compose the svn comments, compose them from a cut and paste of sed 20q ChangeLog, exactly. In this case, you did this: rs6000: fix for PR61396 (wide-int fallout) CONSTANT_P is true for more than just all kinds of constant number. This patch undoes that part of the wide-int patches. but the ChangeLog was like this: PR target/61396 * config/rs6000/rs6000.c (paired_expand_vector_init): Only allow constant numbers, not general constants. (rs6000_expand_vector_init): Ditto. You used to do this, but stopped. The problem with how you are doing it is that the svn bugzilla integration actually looks for the PR target/ line and links the change in svn into bugzilla. Without that, no link. Thanks.
[Bug c/61891] New: line-map.c: file "" left but not entered during `cabal install -p haskell-src-exts`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61891 Bug ID: 61891 Summary: line-map.c: file "" left but not entered during `cabal install -p haskell-src-exts` Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andrew.pennebaker at gmail dot com When I install the haskell-src-exts Cabal package, including profiling information, with: $ cabal install -p haskell-src-exts I see an error reported by GCC: line-map.c: file "" left but not entered I spend more of my time in Haskell than C, so I'm not quite sure what's going wrong. Maybe look in the C sources for haskell-src-exts or its dependencies to find the line-map.c file that triggers the error? System: * GHC 7.6.3 * GCC 4.8.2 * Ubuntu 14.04
[Bug c++/61892] New: RVO not occurs with constructor with universal reference arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61892
Bug ID: 61892
Summary: RVO not occurs with constructor with universal
reference arguments
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tower120 at gmail dot com
I'm not sure that this is bug. But this is strange behavior, if you ask me.
LIVE: http://coliru.stacked-crooked.com/a/d11d50f611ed0cee
In the following code:
#include
template
struct C {
template
C(Args&& ... args) {std::cout << "Ctr\n";}// elision occurs without
&&
~C(){std::cout << "Dstr\n";}
//C(C&&) { std::cout << "A move was made.\n"; } // with this and universal
references in ctr, rvo occurs
};
template
auto f(Args ... args) {
int i = 1;
std::cout << "call "<(i, i, i);
}
int main() {
std::cout << "Hello World!\n";
auto obj = f();
}
OUTPUT:
g++ -std=c++1y -O3 -Winline -Wextra -pthread -pedantic-errors main.cpp -lm &&
./a.out
Hello World!
call
Ctr
Ctr
Dstr
Ctr
Dstr
Dstr
=
1) If I have constructor with "universal" references I need to have ANY move
constructor, so rvo happened.
2) Moreover, when rvo not happens, it construct object with a wrong number of
arguments:
http://coliru.stacked-crooked.com/a/e3ce8882c68dbef2
=
P.S.
http://stackoverflow.com/questions/24925137/c-universal-reference-in-constructor-and-return-value-optimization-rvo/24925451#comment38729738_24925137
someone claims that with gcc 4.8.3 this problem not exists. I don't have that
compiler at hand, so I can't check that.
[Bug preprocessor/61891] line-map.c: file "" left but not entered during `cabal install -p haskell-src-exts`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61891 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Can you find out how's gcc invoked? Can you provide (preferably small) preprocessed testcase?
