--- Comment #4 from tom at kera dot name 2009-08-25 14:48 ---
(In reply to comment #2)
> Why would this be ambiguous? A string literal has type "array of n const char"
> (see 2.13.4/1), so it should go with the array constructor. Do you disagree?
>
> W.
>
Tab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52169
Tomalak Geret'kal changed:
What|Removed |Added
CC| |tom at kera dot name
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52169
--- Comment #2 from Tomalak Geret'kal 2012-02-08
10:45:17 UTC ---
Are you sure it's not just that in_avail is 0? Why should it be -1 here?
i.e. doesn't readsome become a noop when there's nothing to read?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015
Tomalak Geret'kal changed:
What|Removed |Added
CC| |tom at kera dot name
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53984
Tomalak Geret'kal changed:
What|Removed |Added
CC| |tom at kera dot name
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86049
Tomalak Geret'kal changed:
What|Removed |Added
CC| |tom at kera dot name
--- Comme
++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at kera dot name
Target Milestone: ---
See https://stackoverflow.com/q/54147254/560648.
C++17 requires that std::hash be provided. MSVS does, but dev
libstdc++ doesn't (and neither does libc++). This seems to be the case on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88802
--- Comment #1 from Tomalak Geret'kal ---
[unord.hash]/2
> Each specialization of hash is either enabled or disabled, as described
> below. [ Note: Enabled specializations meet the Cpp17Hash requirements, and
> disabled specializations do not.
IRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at kera dot name
Target Milestone: ---
I first raised this on SO (https://stackoverflow.com/q/54237547/560648), on
which I have posted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #4 from Tomalak Geret'kal ---
To be honest I'd expect this in less trivial circumstances too. If, at a given
stage of processing, the only possible paths towards a match all require a
prefix that's already been ruled out, that should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #7 from Tomalak Geret'kal ---
(In reply to Tim Shen from comment #5)
> For the original test case, have you tried regex_match() with "what.*"?
That behaves as I'd expect
(http://quick-bench.com/AKdMnnhA03T1vwfN9sf53xlbD6s).
> Do you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53838
Tomalak Geret'kal changed:
What|Removed |Added
CC| |tom at kera dot name
--- Comme
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at kera dot name
>From http://stackoverflow.com/q/28141403/560648
Reproduction:
/
#include
#include
int main()
{
const int a = 2;
std::functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64791
--- Comment #1 from Tomalak Geret'kal ---
Build error:
/
main.cpp: In instantiation of 'main():: [with auto:1 = int]':
/usr/local/include/c++/4.9.2/functional:2149:71: required by substitution of
'template template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64791
--- Comment #2 from Tomalak Geret'kal ---
Actually, I'm no longer sure that `a` *is* odr-used...
15 matches
Mail list logo
