https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
--- Comment #12 from Petr Ovtchenkov ---
> I don't see that,
This is thanks for javascript programmers. View is different with/without
javascript:
resolvedas
FIXED
INVALID
WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
--- Comment #10 from Petr Ovtchenkov ---
This is not for you ;)
But somebody set field "resolved as" to "FIXED". This is not the case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
--- Comment #8 from Petr Ovtchenkov ---
Why this marked as "FIXED"? The problem still present. No changes have been
made.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81964
Petr Ovtchenkov changed:
What|Removed |Added
Attachment #42035|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81964
--- Comment #3 from Petr Ovtchenkov ---
Looks "not a bug".
Standard say (with a bit misoriented words):
27.6.1 Class template istream_iterator [istream.iterator]
1 The class template istream_iterator is an input iterator (27.2.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81857
--- Comment #3 from Petr Ovtchenkov ---
Created attachment 42042
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42042=edit
proposed test for issue
https://gcc.gnu.org/ml/libstdc++/2017-08/msg00036.html
May be worth to add (see issue2471)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81964
--- Comment #2 from Petr Ovtchenkov ---
https://gcc.gnu.org/ml/libstdc++/2017-08/msg00033.html
++
Assignee: unassigned at gcc dot gnu.org
Reporter: abominable-snowman at yandex dot ru
CC: abominable-snowman at yandex dot ru
Target Milestone: ---
CC: abominable-snowman at yandex dot ru
istream_iterator do unexpected read from stream when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81857
--- Comment #2 from Petr Ovtchenkov ---
Related problem: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50119,
commit 1a1dad283 in git's reflection.
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: abominable-snowman at yandex dot ru
Target Milestone: ---
istreambuf_iterator not increment g-pointer of istream, so character will be
extracted twice (or more, under some occasion), so it not work as single-pass
input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81710
Petr Ovtchenkov changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: abominable-snowman at yandex dot ru
Target Milestone: ---
Created attachment 41922
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41922=edit
patch to fix
__res_state is a struct and function. Compi
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: abominable-snowman at yandex dot ru
Target Milestone: ---
Created attachment 41921
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41921=edit
patch to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
--- Comment #5 from Petr Ovtchenkov ---
Created attachment 38537
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38537=edit
patch that fix issue
This changes fix issue for me. But I know nothing what CANADIAN ad-hoc
workaround intended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
--- Comment #4 from Petr Ovtchenkov ---
(In reply to Petr Ovtchenkov from comment #3)
>
> ...
Is following still actual?
# This lets us hard-code the functionality we know we'll have in the cross
# target environment. "Let" is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
--- Comment #3 from Petr Ovtchenkov ---
(In reply to Petr Ovtchenkov from comment #2)
> ...
Mmm, may be this line is origin of problem:
libstdc++-v3/configure:GLIBCXX_INCLUDES="$GLIBCXX_INCLUDES
-I\${includedir}"
(missed ${DESTDIR} in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
--- Comment #2 from Petr Ovtchenkov ---
No, adding
--with-sysroot=/export/staging/ptr/continuous/development/../arm-unknown-linux-gnueabi
\
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: abominable-snowman at yandex dot ru
Target Milestone: ---
gcc: git's tag gcc-6_1_0-release (c441d9e8e0438dcf54274ec7a3539859e94ad201)
Compilation of gcc for foreign target platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52108
--- Comment #2 from Petr Ovtchenkov abominable-snowman at yandex dot ru
2012-04-18 09:09:04 UTC ---
There are opinion, that this is not a bug:
http://llvm.org/bugs/show_bug.cgi?id=12583
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683
Bug #: 52683
Summary: assignment operator not detected
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683
--- Comment #1 from Petr Ovtchenkov abominable-snowman at yandex dot ru
2012-03-23 07:37:57 UTC ---
Created attachment 26965
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26965
test case
test case. -std=gnu++0x required.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683
--- Comment #3 from Petr Ovtchenkov abominable-snowman at yandex dot ru
2012-03-23 13:54:23 UTC ---
W::operator= is an overloaded function, operator=(const W) and
operator=(W)
decltype cannot work, because an overload set is not a type
I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52683
Petr Ovtchenkov abominable-snowman at yandex dot ru changed:
What|Removed |Added
Status|UNCONFIRMED
23 matches
Mail list logo
