[Bug target/60697] [aarch64] LRA ICE (Segfault) while building 435.gromacs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60697 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Fixed by Vlad's commit on the trunk.
[Bug ipa/60659] [4.9 Regression] ICE in get_polymorphic_call_info, at ipa-devirt.c:1292
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659 --- Comment #5 from Jan Hubicka --- Created attachment 32494 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32494&action=edit Patch I am testing This is patch that makes us to redirect those type inconsistent calls to builtin_unreachable. It seems to match surprisingly often on firefox, so I will try to also test libreoffice's unit tests before comiting.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #205 from Jan Hubicka --- I was looking into this recently, too. Curiously enough, for me clang+LTO was winning but comparing the symbols it seemed that the confiugre scripts picked bit more features at GCC side. I looked briefly on the differences and we can optimize out more vtables which I have patch for pending for next stage1 and optimize out write only global vars. Still the differences may be worth further investigation - clang seems to produce noticeably fewer external relocations, too. This seems like a ABI bug at clang side though. What I use for my firefox builds is --param inline-unit-growth=5. Our -O3 seems bit of overkill for applicatin of fize of Firefox... Honza
[Bug tree-optimization/60712] "restrict" qualifier ignored on local variable or after inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60712 --- Comment #1 from Andrew Pinski --- The inline issue is recorded as 58526.
[Bug c++/60715] Narrowing conversions not caught in non-type template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60715 --- Comment #1 from Jonathan Wakely --- I'm pretty sure there's an existing bug report about this
[Bug c++/60714] comments in template instantiation are interpreted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60714 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- No, the comment is not being interpreted, the thing before the comment is not a valid typename: std::basic_stringbuf::int_type
[Bug c++/60715] New: Narrowing conversions not caught in non-type template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60715 Bug ID: 60715 Summary: Narrowing conversions not caught in non-type template parameters Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: filip.roseen at gmail dot com Created attachment 32493 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32493&action=edit testcase.cpp templatevoid f () {} template void g () {} template struct A {}; int main () { f<1024> (); // ill-formed, `char { 1024 }` is a narrowing conversion, // see [dcl.init.list]p7 g<-123> (); // ill-formed, `unsigned int { -123 }` is a narrowing // conversion, see [dcl.init.list]p7 A<-123> a; // ill-formed, see previous comment } /* In the above we assume `char` is 8 bits */ - [temp.arg.nontype]p1; > A template-argument for a non-type, non-template template > parameeter shall be one of: > > - for a non-type template-aprameter of integral or enumeration > type, a converted constant expression (5.19) of the type of > the template-parameter > > [expr.const]p3; > A converted constant expression of type `T` is an expression, > implicitly converted to a prvalue of type `T`, where the converted > expression is a core constant expression and the implicit > conversion sequence contains only user-defined conversions, > lvalue-to-rvalue conversions (4.1), integral promotions (4.5), and > integral conversions (4.7) other than narrowing conversions > (8.5.4). - [ Note: `gcc` accepts testcase.cpp, while `clang` (correctly) issues the relevant diagnostics. ] [ Note: `gcc` handles overflow conversions for non-type template parameters when used in a class template; ie. it shows a diagnostic for `template struct B {};` instantiated as `B<1024> {};` ]
[Bug target/60039] sh3 optimisation bug with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60039 Kazumoto Kojima changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Kazumoto Kojima --- Fixed.
[Bug target/60039] sh3 optimisation bug with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60039 --- Comment #10 from Kazumoto Kojima --- Author: kkojima Date: Sun Mar 30 23:12:36 2014 New Revision: 208950 URL: http://gcc.gnu.org/viewcvs?rev=208950&root=gcc&view=rev Log: PR target/60039 * config/sh/sh.md (udivsi3_i1): Clobber R1 register. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/sh/sh.md
[Bug c++/60713] New: [4.8/4.9 regression] ICE in iterative_hash_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60713
Bug ID: 60713
Summary: [4.8/4.9 regression] ICE in iterative_hash_expr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/13644122
Reproduces with current trunk (r208944):
g++ -c -std=c++11 t.cc && echo ok
ok
g++ -c -std=c++11 t.cc -O2
t.cc: In member function ‘void x6::x7()’:
t.cc:20:7: internal compiler error: in iterative_hash_expr, at tree.c:7475
});
^
0xd78b9f iterative_hash_expr(tree_node const*, unsigned int)
../../gcc/tree.c:7475
0xd78a22 iterative_hash_expr(tree_node const*, unsigned int)
../../gcc/tree.c:7508
0xd7886b iterative_hash_expr(tree_node const*, unsigned int)
../../gcc/tree.c:7448
0x9abf3c gimplify_hasher::hash(gimple_temp_hash_elt const*)
../../gcc/gimplify.c:8908
0x9abf3c hash_table::find_slot(gimple_temp_hash_elt const*, insert_option)
../../gcc/hash-table.h:505
0x9abf3c lookup_tmp_var
../../gcc/gimplify.c:488
0x9abf3c internal_get_tmp_var
../../gcc/gimplify.c:523
0x9a4bf1 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:8358
0x9af968 gimplify_call_expr
../../gcc/gimplify.c:2375
0x9a5047 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7431
0x9a9996 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5353
0x9a50d2 gimplify_cleanup_point_expr
../../gcc/gimplify.c:5129
0x9a50d2 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7823
0x9a9996 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5353
0x9ab1f9 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:8567
0x9ab7d6 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:8720
0x8393a7 analyze_function
../../gcc/cgraphunit.c:649
0x83a65b analyze_functions
../../gcc/cgraphunit.c:1017
0x83bd55 finalize_compilation_unit()
../../gcc/cgraphunit.c:2320
0x63541e cp_write_global_declarations()
../../gcc/cp/decl2.c:4610
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
/// cut here
template < class x0, class x1, class x2, class x3, class x4 >
int *x5 (x0 *, x2 (x1::*)(x3, x4));
class x6
{
void x7 ();
struct x8
{
int *x9;
};
void x10 (x8);
void x11 (int *, int *);
};
void
x6::x7 ()
{
x10 ({
x5 (this, &x6::x11)
});
}
[Bug target/60034] "invalid expression as operand" in aarch64 inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60034 --- Comment #6 from kugan at gcc dot gnu.org --- Author: kugan Date: Sun Mar 30 22:41:59 2014 New Revision: 208949 URL: http://gcc.gnu.org/viewcvs?rev=208949&root=gcc&view=rev Log: PR target/60034 * aarch64/aarch64.c (aarch64_classify_address): Fix alignment for section anchor. PR target/60034 * gcc.target/aarch64/pr60034.c: New file. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr60034.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug fortran/60661] DO CONCURRENT with MASK: Avoid using a temporary for the mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60661 --- Comment #3 from Thomas Koenig --- We have to be a bit careful about statement like do concurrent(i=1:n, a(i)>sum(a)/n) a(i) = a(i) * 0.5 end do which really have to be before the execution of the loop body itself.
[Bug target/60604] [4.9 Regression] GCC incorrectly compiles s_csinh function on MIPS32 (32bit fp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60604 --- Comment #9 from rsandifo at gcc dot gnu.org --- Created attachment 32491 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32491&action=edit Tentative patch
[Bug target/60604] [4.9 Regression] GCC incorrectly compiles s_csinh function on MIPS32 (32bit fp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60604
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-30
Ever confirmed|0 |1
--- Comment #8 from rsandifo at gcc dot gnu.org
---
The subregs on pseudos seem fine. I think the problem comes when
IRA substitutes $f12 into them. I.e.:
(insn 26 8 27 2 (set (subreg:SI (reg:DF 199 [ D.3267 ]) 0)
(and:SI (subreg:SI (reg/v:DF 205 [ x ]) 0)
(const_int 2147483647 [0x7fff])))
/home/richards/Downloads/reduced.c:25 157 {*andsi3}
(nil))
(insn 27 26 9 2 (set (subreg:SI (reg:DF 199 [ D.3267 ]) 4)
(subreg:SI (reg/v:DF 205 [ x ]) 4))
/home/richards/Downloads/reduced.c:25 286 {*movsi_internal}
(nil))
becomes:
(insn 26 8 27 2 (set (subreg:SI (reg:DF 199 [ D.3267 ]) 0)
(and:SI (subreg:SI (reg:DF 44 $f12) 0)
(const_int 2147483647 [0x7fff])))
/home/richards/Downloads/reduced.c:25 157 {*andsi3}
(nil))
(insn 27 26 9 2 (set (subreg:SI (reg:DF 199 [ D.3267 ]) 4)
(subreg:SI (reg:DF 44 $f12) 4)) /home/richards/Downloads/reduced.c:25
286 {*movsi_internal}
(nil))
These operands would normally be invalid register_operands thanks to:
#ifdef CANNOT_CHANGE_MODE_CLASS
if (REG_P (sub)
&& REGNO (sub) < FIRST_PSEUDO_REGISTER
&& REG_CANNOT_CHANGE_MODE_P (REGNO (sub), GET_MODE (sub), mode)
&& GET_MODE_CLASS (GET_MODE (sub)) != MODE_COMPLEX_INT
&& GET_MODE_CLASS (GET_MODE (sub)) != MODE_COMPLEX_FLOAT
/* LRA can generate some invalid SUBREGS just for matched
operand reload presentation. LRA needs to treat them as
valid. */
&& ! LRA_SUBREG_P (op))
return 0;
#endif
The problem is that general_operand and nonmemory_operand don't check
the same thing.
You could argue that reload should be able to cope correctly with the
"invalid" subregs, and maybe LRA would, but really we shouldn't create
insns that we know are going to need a reload.
The problem is, general_operand, nonmemory_operand and register_operand
all have slightly different ideas what a register operand is. So although
the patch I'm about to attach seems to fix it, it might be too drastic
for this stage.
[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
--- Comment #9 from Jim Michaels ---
it appears from
protected:
/**
* @brief Base constructor.
*
* Only called from derived constructors, and sets up all the
* buffer data to zero, including the pointers described in the
* basic_streambuf class description. Note that, as a result,
* - the class starts with no read nor write positions available,
* - this is not an error
*/
basic_streambuf()
: _M_in_beg(0), _M_in_cur(0), _M_in_end(0),
_M_out_beg(0), _M_out_cur(0), _M_out_end(0),
_M_buf_locale(locale())
{ }
that the streambuf class must be derived from to be used. it doesn't have the
kind of constructor I had hoped. I see no examples anywhere on how to use
streambuf. and I have not done c++ at this level, so I am thinking about giving
up, at least for now. and stackoverflow.com is copyrighted.
why is it SO DIFFICULT to do this?
everyone wants to do unicode streams. I can't do graphic block shade characters
without this (what's shown in the code) for graphs and TUIs.
[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711 --- Comment #8 from Jim Michaels --- by the way, folks on stackoverflow.com have long struggled with this and found no solution.
[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
Jim Michaels changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #7 from Jim Michaels ---
found what I thought was a workaround, the streambuf thing is a constructor in
the basic_ostream class.
#include
#include
#include
#include
#include
#include
#include
#include
#include
typedef std::vector Vu16S;
typedef std::basic_ostringstream,
std::allocator > u16ostringstream;
typedef std::basic_ostringstream,
std::allocator > u32ostringstream;
//typedef std::basic_ostream > u16ostream;
//typedef std::basic_ostream > u32ostream;
std::basic_ostringstream > u16ograph;
std::basic_ostringstream > u32ograph;
typedef std::basic_streambuf >
u16streambuf;
typedef std::basic_streambuf >
u32streambuf;
u16streambuf u16sb;
u32streambuf u32sb;
std::basic_ostream > u16cout(u16sb);
std::basic_ostream > u32cout(u32sb);
//uostream ucout;
//u32ostream u32cout;
Vu16S vu16blockss={u"\u00a0",u"\u2591",u"\u2592",u"\u2593",u"\u2588"};
int main(void) {
uostringstream o16graph;
ograph<::basic_streambuf() [with _CharT = char16_t; _Traits =
std::char_traits]' is protected
basic_streambuf()
^
ostream2a.cpp:20:14: error: within this context
hmm. I could not find a definition/constructor for basic_streambuf.
[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Jonathan Wakely --- This is not a bug in GCC, your code is simply incorrect. std::basic_ostream is only usable as a base class, not the way you're trying to use it. Please find somewhere more suitable to solve your problem, such as http://stackoverflow.com
[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
--- Comment #5 from Jim Michaels ---
not allowed to use a basic_streambuf there either, also says it's protected.
apparently ostream() is protected. I looked, and there is a place that looks
like you can use a treambuf, but I am unable to get it to work.
ostream line 384 where it says
protected:
basic_ostream()
{ this->init(0); }
template
__ostream_type&
_M_insert(_ValueT __v);
};
is where it complains.
tried typedef std::basic_ostream > > uostream;
and got
f:\x86_64-4.9.0-snapshot-20140219-rev207854-win32-sjlj-rt_v4\mingw64\x86_64-w64-mingw32\include\c++\ostream:384:7:
error: 'std::basic_ostream<_CharT, _Traits>::
basic_ostream() [with _CharT = std::basic_streambuf >; _Traits =
std::char_traits > >]' is protected
basic_ostream()
^
ostream2a.cpp:21:12: error: within this context
u32ostream u32cout;
^
and a whole bunch of other errors. I had thought you could simply use the
template >
class basic_ostream;
based definition to create a new a type to instantiate a u16cout or ucout, but
apparently this is not so because of the protected-ness of the method.
there is probably a reason for this, I know of no workaround yet.
[Bug tree-optimization/59617] [vectorizer] ICE in vectorizable_mask_load_store with AVX-512F's gathers enabled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59617 --- Comment #3 from Dominique d'Humieres --- The test gcc.target/i386/avx512f-gather-5.c fails on darwin FAIL: gcc.target/i386/avx512f-gather-5.c scan-assembler gather[^\\n]*zmm There is no 'gather' in the avx512f-gather-5.s file.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug fortran/45129] I/O edit descriptors: Warn if the format field is too small for the E and F edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45129 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug fortran/44292] [libgfortran ABI breakage] Increase internal size of RECL= of the OPEN statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44292 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug fortran/30123] Document INQUIRE, especially UNFORMATTED and FORMATTED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30123 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug fortran/29602] [F2003] I/O specifiers can now be of any kind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29602 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug fortran/28397] Check format mismatches at compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28397 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug fortran/27436] gfortran: Abort compiling if there are insufficient data descriptors in format after reversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27436 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711 --- Comment #4 from Marc Glisse --- uostream ucout; Where did you see in the standard that basic_ostream is default constructible? The only constructor I can find is the explicit one from basic_streambuf*.
[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711 --- Comment #2 from Jim Michaels --- Created attachment 32488 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32488&action=edit corrected ostream2a.cpp source file attached corrected source code. nearly identical errors. In file included from ostream2a.cpp:2:0: f:\x86_64-4.9.0-snapshot-20140219-rev207854-win32-sjlj-rt_v4\mingw64\x86_64-w64-mingw32\include\c++\ostream:384:7: error: 'std::basic_ostream<_CharT, _Traits> basic_ostream() [with _CharT = char16_t; _Traits = std::char_traits]' is protected basic_ostream() ^ ostream2a.cpp:15:10: error: within this context uostream ucout; ^ In file included from ostream2a.cpp:2:0: f:\x86_64-4.9.0-snapshot-20140219-rev207854-win32-sjlj-rt_v4\mingw64\x86_64-w64-mingw32\include\c++\ostream:384:7: error: 'std::basic_ostream<_CharT, _Traits> basic_ostream() [with _CharT = char32_t; _Traits = std::char_traits]' is protected basic_ostream() ^ ostream2a.cpp:16:12: error: within this context u32ostream u32cout; ^
[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
--- Comment #1 from Jim Michaels ---
oops! ignore the
namespace std {
line and the error about missing } I was trying something earlier due to an
earlier error.
because basic_ostream() is protected in the include file ostream, I or anyone
else can't seem to do unicode strings with ostream and sstream?
[Bug libstdc++/60711] New: basic_ostringstream,basic_ostream,u16string,char16_t do not work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
Bug ID: 60711
Summary: basic_ostringstream,basic_ostream,u16string,char16_t
do not work together
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jmichae3 at yahoo dot com
Created attachment 32487
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32487&action=edit
.ii file
#include
#include
#include
#include
#include
#include
#include
#include
namespace std {
typedef std::vector Vu16S;
typedef std::basic_ostringstream >
uostringstream;
typedef std::basic_ostringstream >
u32ostringstream;
typedef std::basic_ostream > uostream;
typedef std::basic_ostream > u32ostream;
/*
In file included from ostream2a.cpp:2:0:
f:\x86_64-4.9.0-snapshot-20140219-rev207854-win32-sjlj-rt_v4\mingw64\x86_64-w64-mingw32\include\c++\ostream:384:7:
error: 'std::basic_ostream<_CharT, _Traits>::
basic_ostream() [with _CharT = char16_t; _Traits = std::char_traits]'
is protected
basic_ostream()
^
ostream2a.cpp:16:10: error: within this context
uostream ucout;
^
In file included from ostream2a.cpp:2:0:
f:\x86_64-4.9.0-snapshot-20140219-rev207854-win32-sjlj-rt_v4\mingw64\x86_64-w64-mingw32\include\c++\ostream:384:7:
error: 'std::basic_ostream<_CharT, _Traits>::
basic_ostream() [with _CharT = char32_t; _Traits = std::char_traits]'
is protected
basic_ostream()
^
ostream2a.cpp:17:12: error: within this context
u32ostream u32cout;
^
ostream2a.cpp:27:1: error: expected '}' at end of input
}
^
I saw this later on and this matched my implementation (but I did not know
about dropping the 16):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2035.pdf
but this doesn't work, even apparently with the microsoft compiler. something
funny with the standard?
so: what is wrong in the first error? I don't understand why something is
protected. somebody said something about
fstream containing the implementation of ostream in gcc (not sure if this is
stil true). apparently, msvc++ has this problem too.
seems like something I ought to be able to do simply, but it just breaks. not
sure why this is protected.
there is no wstring_convert. I grepped for it.
*/
-municode doesn't help.
[Bug ada/60703] System.Address not preelaborable on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eric Botcazou --- Fixed everywhere.
[Bug ada/60703] System.Address not preelaborable on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703 --- Comment #4 from Eric Botcazou --- Author: ebotcazou Date: Sun Mar 30 15:48:48 2014 New Revision: 208947 URL: http://gcc.gnu.org/viewcvs?rev=208947&root=gcc&view=rev Log: PR ada/60703 * system-linux-alpha.ads: Adjust for Ada 2005. * system-linux-mips.ads: Likewise. * system-linux-mips64el.ads: Likewise. * system-linux-mipsel.ads: Likewise. * system-linux-s390.ads: Likewise. * system-linux-s390x.ads: Likewise. * system-linux-sparc.ads: Likewise. * system-linux-sparcv9.ads: Likewise. * system-rtems.ads: Likewise. * system-vxworks-arm.ads: Likewise. Modified: branches/gcc-4_7-branch/gcc/ada/ChangeLog branches/gcc-4_7-branch/gcc/ada/system-linux-alpha.ads branches/gcc-4_7-branch/gcc/ada/system-linux-mips.ads branches/gcc-4_7-branch/gcc/ada/system-linux-mips64el.ads branches/gcc-4_7-branch/gcc/ada/system-linux-mipsel.ads branches/gcc-4_7-branch/gcc/ada/system-linux-s390.ads branches/gcc-4_7-branch/gcc/ada/system-linux-s390x.ads branches/gcc-4_7-branch/gcc/ada/system-linux-sparc.ads branches/gcc-4_7-branch/gcc/ada/system-linux-sparcv9.ads branches/gcc-4_7-branch/gcc/ada/system-rtems.ads branches/gcc-4_7-branch/gcc/ada/system-vxworks-arm.ads
[Bug ada/60703] System.Address not preelaborable on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Sun Mar 30 15:48:19 2014 New Revision: 208946 URL: http://gcc.gnu.org/viewcvs?rev=208946&root=gcc&view=rev Log: PR ada/60703 * system-linux-alpha.ads: Adjust for Ada 2005. * system-linux-mips.ads: Likewise. * system-linux-mips64el.ads: Likewise. * system-linux-mipsel.ads: Likewise. * system-linux-s390.ads: Likewise. * system-linux-s390x.ads: Likewise. * system-linux-sparc.ads: Likewise. * system-linux-sparcv9.ads: Likewise. * system-rtems.ads: Likewise. * system-vxworks-arm.ads: Likewise. Modified: branches/gcc-4_8-branch/gcc/ada/ChangeLog branches/gcc-4_8-branch/gcc/ada/system-linux-alpha.ads branches/gcc-4_8-branch/gcc/ada/system-linux-mips.ads branches/gcc-4_8-branch/gcc/ada/system-linux-mips64el.ads branches/gcc-4_8-branch/gcc/ada/system-linux-mipsel.ads branches/gcc-4_8-branch/gcc/ada/system-linux-s390.ads branches/gcc-4_8-branch/gcc/ada/system-linux-s390x.ads branches/gcc-4_8-branch/gcc/ada/system-linux-sparc.ads branches/gcc-4_8-branch/gcc/ada/system-linux-sparcv9.ads branches/gcc-4_8-branch/gcc/ada/system-rtems.ads branches/gcc-4_8-branch/gcc/ada/system-vxworks-arm.ads
[Bug ada/60703] System.Address not preelaborable on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703 --- Comment #2 from Eric Botcazou --- Author: ebotcazou Date: Sun Mar 30 15:47:43 2014 New Revision: 208945 URL: http://gcc.gnu.org/viewcvs?rev=208945&root=gcc&view=rev Log: PR ada/60703 * system-linux-alpha.ads: Adjust for Ada 2005. * system-linux-mips.ads: Likewise. * system-linux-mips64el.ads: Likewise. * system-linux-mipsel.ads: Likewise. * system-linux-s390.ads: Likewise. * system-linux-s390x.ads: Likewise. * system-linux-sparc.ads: Likewise. * system-linux-sparcv9.ads: Likewise. * system-rtems.ads: Likewise. * system-vxworks-arm.ads: Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/system-linux-alpha.ads trunk/gcc/ada/system-linux-mips.ads trunk/gcc/ada/system-linux-mips64el.ads trunk/gcc/ada/system-linux-mipsel.ads trunk/gcc/ada/system-linux-s390.ads trunk/gcc/ada/system-linux-s390x.ads trunk/gcc/ada/system-linux-sparc.ads trunk/gcc/ada/system-linux-sparcv9.ads trunk/gcc/ada/system-rtems.ads trunk/gcc/ada/system-vxworks-arm.ads
[Bug libstdc++/60710] experimental::optional is using T::operator!=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60710 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-30 Ever confirmed|0 |1
[Bug ada/60703] System.Address not preelaborable on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Target Milestone|--- |4.7.4
[Bug ada/60703] System.Address not preelaborable on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-30 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Indeed, will fix.
[Bug libstdc++/60710] experimental::optional is using T::operator!=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60710 Lars Gullik Bjønnes changed: What|Removed |Added CC||larsbj at gullik dot net --- Comment #1 from Lars Gullik Bjønnes --- Created attachment 32486 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32486&action=edit replace != with !( == ) in optional::operator!=
[Bug libstdc++/60710] New: experimental::optional is using T::operator!=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60710 Bug ID: 60710 Summary: experimental::optional is using T::operator!= Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: larsbj at gullik dot net When looking at n3793 it states that operator!= should be implemented with !(t1 == t2), and not t1 != t2 as the implementation in gcc 4.9 is doing. This is the case for both the operator!= implementations where optional is compared against T. Also since optional should not put requirements on the contained type other than operator== and operator>, operator!= are removed from the tests in the suggested patch.
[Bug c++/60709] New: [C++11]ICE when using a braced-init-list as function argument to initialize a reference to array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60709
Bug ID: 60709
Summary: [C++11]ICE when using a braced-init-list as function
argument to initialize a reference to array
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Minimal case:
template
struct X{};
void f(X(&&)[1])
{}
int main()
{
f({X()});
}
g++ a.cc -std=c++11
a.cc: In function 'int main()':
a.cc:8:15: internal compiler error: Segmentation fault
f({X()});
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Clang++ 3.4 accepted it successfully.
[Bug c++/60708] New: An array temporary causes an ICE in gimplify
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60708
Bug ID: 60708
Summary: An array temporary causes an ICE in gimplify
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test:
template struct mypair {
mypair(T, U) {}
};
template auto my_make_pair(T t, U u)
{
return mypair(t, u);
}
template struct S {
mypair get_pair() noexcept {
return my_make_pair((T*)nullptr, 0);
}
};
static void foo(const mypair (&a)[2]) noexcept { }
int main()
{
S s;
//mypair jones[2]{s.get_pair(), s.get_pair()};
//foo(jones);
foo({s.get_pair(), s.get_pair()});
}
If the commented lines are present, this compiles fine. I don't know why,
because with the code as written, the following explosion happens:
lhcat2.cpp: In function ‘int main()’:
lhcat2.cpp:24:35: internal compiler error: Segmentation fault
foo({s.get_pair(), s.get_pair()});
^
0xb50aff crash_signal
../../gcc/toplev.c:337
0x9b590d gimplify_target_expr
../../gcc/gimplify.c:5255
0x9a2d2c gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7815
0x9ac27d gimplify_addr_expr
../../gcc/gimplify.c:4801
0x9a2935 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7494
0x9acdb8 gimplify_call_expr
../../gcc/gimplify.c:2375
0x9a24c7 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7419
0x9a6e16 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5341
0x9a2552 gimplify_cleanup_point_expr
../../gcc/gimplify.c:5117
0x9a2552 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7811
0x9a6e16 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5341
0x9a2fdb gimplify_statement_list
../../gcc/gimplify.c:1412
0x9a2fdb gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7863
0x9a6e16 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5341
0x9a7b1f gimplify_bind_expr
../../gcc/gimplify.c:1079
0x9a2a0e gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7645
0x9a6e16 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5341
0x9a2fdb gimplify_statement_list
../../gcc/gimplify.c:1412
0x9a2fdb gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7863
0x9a6e16 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5341
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug c++/60705] ill-formed member access in alias template ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60705 --- Comment #2 from Robert Haberlach --- In this case the nested-name-specifier is not dependent upon any template argument. Thank you for the link, i didn't know that report yet.
[Bug c++/60705] ill-formed member access in alias template ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60705 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- I wouldn't say that this is obvious, there exists an open core language issue around this area: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1554 Note that current Clang 3.5 HEAD also accepts the presented code.
[Bug fortran/60576] [4.8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 Mikael Morin changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #16 from Mikael Morin --- (In reply to Dominique d'Humieres from comment #14) > gfortran.dg/assumed_rank_7.f90 still aborts when compiled with > -fsanitize=address as in comment 3. Reopening then.
