http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60127
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #2)
Am I overlooking something basic here?
a) You also can have
DO CONCURRENT(i=1:5, j=1:5)
but your code only handles one variable (by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60705
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60705
--- Comment #2 from Robert Haberlach R.HL at gmx dot net ---
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.
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++
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60710
Bug ID: 60710
Summary: experimental::optionalT is using T::operator!=
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60710
Lars Gullik Bjønnes larsbj at gullik dot net changed:
What|Removed |Added
CC||larsbj at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60710
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703
--- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Author: ebotcazou
Date: Sun Mar 30 15:47:43 2014
New Revision: 208945
URL: http://gcc.gnu.org/viewcvs?rev=208945root=gccview=rev
Log:
PR ada/60703
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703
--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Author: ebotcazou
Date: Sun Mar 30 15:48:19 2014
New Revision: 208946
URL: http://gcc.gnu.org/viewcvs?rev=208946root=gccview=rev
Log:
PR ada/60703
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703
--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Author: ebotcazou
Date: Sun Mar 30 15:48:48 2014
New Revision: 208947
URL: http://gcc.gnu.org/viewcvs?rev=208947root=gccview=rev
Log:
PR ada/60703
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60703
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
--- Comment #1 from Jim Michaels jmichae3 at yahoo dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
--- Comment #2 from Jim Michaels jmichae3 at yahoo dot com ---
Created attachment 32488
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32488action=edit
corrected ostream2a.cpp source file
attached corrected source code.
nearly identical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
--- Comment #4 from Marc Glisse glisse at gcc dot gnu.org ---
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*.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27436
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28397
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29602
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30123
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44292
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45129
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59617
--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
--- Comment #5 from Jim Michaels jmichae3 at yahoo dot com ---
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,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
Jim Michaels jmichae3 at yahoo dot com changed:
What|Removed |Added
Resolution|INVALID |FIXED
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
--- Comment #8 from Jim Michaels jmichae3 at yahoo dot com ---
by the way, folks on stackoverflow.com have long struggled with this and found
no solution.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
--- Comment #9 from Jim Michaels jmichae3 at yahoo dot com ---
it appears from
protected:
/**
* @brief Base constructor.
*
* Only called from derived constructors, and sets up all the
* buffer data to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60604
rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60604
--- Comment #9 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org
---
Created attachment 32491
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32491action=edit
Tentative patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60661
--- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |INVALID
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=208949root=gccview=rev
Log:
PR target/60034
* aarch64/aarch64.c (aarch64_classify_address): Fix
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60039
--- Comment #10 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Author: kkojima
Date: Sun Mar 30 23:12:36 2014
New Revision: 208950
URL: http://gcc.gnu.org/viewcvs?rev=208950root=gccview=rev
Log:
PR target/60039
* config/sh/sh.md
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60039
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60714
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60715
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
I'm pretty sure there's an existing bug report about this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60712
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
The inline issue is recorded as 58526.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #205 from Jan Hubicka hubicka at ucw dot cz ---
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659
--- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org ---
Created attachment 32494
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32494action=edit
Patch I am testing
This is patch that makes us to redirect those type inconsistent calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60697
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
47 matches
Mail list logo
