https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101268
--- Comment #4 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Christopher Yeleighton from comment #0)
> > (I mean patches are not welcome)
>
> Have you actually tried submitting any? I only see bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51539
--- Comment #5 from Christopher Yeleighton ---
Created attachment 51106
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51106&action=edit
Add Doxygen documentation to items in stl_function.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840
--- Comment #9 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #8)
> Already fixed in r12-1964
>
> You know doxygen output isn't the only way to look at the code, right?
I thought merged commits refresh the published d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101306
Christopher Yeleighton changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97001
--- Comment #3 from Christopher Yeleighton ---
The problem with a module-level @since is that std:: symbols are easiest to
locate in the std namespace (which provides a huge index of everything). Items
that are undocumented (there is a lot of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101268
--- Comment #3 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Christopher Yeleighton from comment #0)
> > (I mean patches are not welcome)
>
> Have you actually tried submitting any? I only see bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101307
--- Comment #1 from Christopher Yeleighton ---
(In reply to Christopher Yeleighton from comment #0)
> 1. Please remove the trailing comma from the title: Variable templates for
> type traits.
The trailing full stop, of course.
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
1. Please remove the trailing comma from the title: Variable templates for type
traits.
2. The general description (is_foovalue) should be (is_foo ::value) (or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840
--- Comment #6 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #3)
> I'm not sure why the comment on the primary template doesn't show up (maybe
> doxygen is only interested in a definition) and adding comments to the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840
--- Comment #5 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #4)
> It shows up in the latest docs:
> https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a03925.
> html
>
> But several other classes do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101306
--- Comment #2 from Christopher Yeleighton ---
(In reply to Christopher Yeleighton from comment #1)
> Interestingly enough, the problem does not affect https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/
> a00209_source.html#l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101306
--- Comment #1 from Christopher Yeleighton ---
Interestingly enough, the problem does not affect https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a00209_source.html#l00060
>. It may be a timing issue—the latter document is w
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
When I navigate to a line anchor like #l02373, the following things happen:
1. The source file opens.
2. The source file scrolls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #14 from Christopher Yeleighton ---
Will you accept an improvement regarding an issue RESOLVED WONTFIX?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #12 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #10)
> Lots of things in our API docs are not in the standard, and lots of things
> in the standard are not in our API docs. If you're trying to use it for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #8 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #6)
> While it would be nice if the libstdc++ API docs were 100% complete and
> described every piece of the library, that is never going to happen. If you
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
Since we have given up on documenting all standard library features we have
implemented (I mean patches are not welcome), we should add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #7 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Christopher Yeleighton from comment #3)
> > It should at least be present on the API page. The standard is not for
> > developers.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #4 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #1)
> It does exactly what the standard says it does. And it's self explanatory.
What is self-explanatory in is_integral_v? It could be "is integral verbo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #3 from Christopher Yeleighton ---
It should at least be present on the API page. The standard is not for
developers.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99909
Christopher Yeleighton changed:
What|Removed |Added
CC||giecrilj at stegny dot 2a.pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96995
--- Comment #6 from Christopher Yeleighton ---
Why wouldn’t locally installed documentation have the API book at the same
relative location?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96995
--- Comment #4 from Christopher Yeleighton ---
Why wouldn’t it work for local documentation?
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
For example, the documentation for std::cbegin[1] should say:
> Minimum dialect: c++14
___
[1] https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01544.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96995
--- Comment #2 from Christopher Yeleighton ---
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/libstdc++/manual/manual/../../api/namespaces.html
> would do the trick.
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
Reading the section "Available Namespaces" [1]:
Actual:
> A complete list of implementation namespaces (including namespace contents)
> is
++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
This flag, combined with out or append should have the effect of (fopen (path,
"wx")). Now that the syntax (fopen (path, "wx")) is standard, there is no
excuse for denying the equi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59687
Christopher Yeleighton changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|F
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59699
--- Comment #1 from Christopher Yeleighton ---
Also, anchor "Effective C++ CD" only, since the anchor does not link to the
example.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Chapter "Support" of The GNU C++ Library Manual
Has:
http://www.awprofessional.com/titles/0-201-92488-9/ >
Let:
http://www.informit.com/store/effective-c-plus-plus-55-specific-ways-to
++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
The section "Implementation Specific Behavior" of The GNU C++ Library Manual
Has:
[18.1]/4 The type of NULL is described here.
Let:
[18.1]/4 The type of NULL is described in Chap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59687
--- Comment #1 from Christopher Yeleighton ---
(In reply to Christopher Yeleighton from comment #0)
> Also inconsistent with the table at filebuf::open that does not mention "x"
> mode to be actually used.
Oops, scratch that, I had "noreplace" in
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
The page "Backwards Compatibility" [1] says:
> For output streams, “nocreate” is probably the default, unless you specify
> std::ios::trunc ?
Probably??? Could you ple
#ad72dc61561f4420b36f9e626b4426433
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Is:
Table 92, adapted here, gives the relation between openmode
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Declared at line 00172 .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52442
--- Comment #3 from Christopher Yeleighton
2012-02-29 23:25:19 UTC ---
(In reply to comment #1)
> You're right, it can't be used like that, but it's not meant to be.
>
> By design temporary_buffer is not copyable, so it's not swappable either.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52442
--- Comment #2 from Christopher Yeleighton
2012-02-29 23:23:34 UTC ---
(In reply to comment #1)
> You're right, it can't be used like that, but it's not meant to be.
>
> By design temporary_buffer is not copyable, so it's not swappable either.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52442
Bug #: 52442
Summary: temporary_buffer does not swap
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317
--- Comment #6 from Christopher Yeleighton
2012-02-20 21:54:11 UTC ---
Created attachment 26707
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26707
updates the FSF address in boilerplate comments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317
Bug #: 52317
Summary: incorrect FSF address
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657
--- Comment #5 from Christopher Yeleighton
2011-12-23 00:45:28 UTC ---
Well, I am astonished at the carelessness of the LWG. If something is plainly
wrong, it should be fixed (which would be trivial in this case) or withdrawn,
not deprecated. D
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657
--- Comment #2 from Christopher Yeleighton
2011-12-22 21:46:58 UTC ---
The standard is obviously wrong.
http://groups.google.com/group/comp.std.c++/browse_thread/thread/de856e5116876ff3/b34116c5e51b1d07?lnk=gst&q=bind1st#b34116c5e51b1d07
>
Repo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657
Bug #: 51657
Summary: bind1st multiplies a pointer
Classification: Unclassified
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
--- Comment #17 from Christopher Yeleighton
2011-12-17 17:05:58 UTC ---
The SGI documentation clarifies all issues well enough indeed. I wonder
whether it would be a good thing to put a reference to SGI in the documentation
index (with a warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
--- Comment #14 from Christopher Yeleighton
2011-12-16 20:31:24 UTC ---
I would rather prefer to be able to use gcc (as a software developer) while not
having the ISO standard, which is 1) unreadable with an unarmed eye, 2) not
free (as in anythi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
--- Comment #12 from Christopher Yeleighton
2011-12-16 18:59:31 UTC ---
Additionally, and also for the default operator form, it is unclear what the
result is when the operator is noncommutative. That is, whether y[n+1] is set
to x[n+1]+y[n] or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
Christopher Yeleighton changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
Christopher Yeleighton changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51539
--- Comment #2 from Christopher Yeleighton
2011-12-13 23:30:49 UTC ---
(In reply to comment #1)
> It returns x*y, which may or may not be the product, the binary operator*
> could
> be overloaded for Tp with a completely different meaning.
The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
Bug #: 51540
Summary: partial_sum (int *, int *, int *, multiplies < int >)
does not use operator +(complex, complex)
Classification: Unclassified
Product: gcc
Version: 4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51539
Bug #: 51539
Summary: multiplies ::operator () undocumented
Classification: Unclassified
Product: gcc
Version: 4.5.1
URL: http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50961
Christopher Yeleighton changed:
What|Removed |Added
CC||giecrilj at stegny dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #8 from Christopher Yeleighton
2011-09-27 22:23:34 UTC ---
> I agree that this would be an improvement, even without clang's selective
> typedef unwrapping. But I have some doubts such a patch will be accepted. I
> was
> told in a co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50501
Bug #: 50501
Summary: Insertion of complex into a stream may fail without
invalidating the stream
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #2 from Christopher Yeleighton
2011-09-21 20:06:42 UTC ---
== Code ==
struct X { int x; };
void trigger (X x []) { x [01] = 0; }
== Result (v4.6) ==
doit.cpp:2:34: error: no match for ‘operator=’ in ‘*(x + 4u) = 0’
But who refere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Christopher Yeleighton changed:
What|Removed |Added
CC||giecrilj at stegny dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #25 from Christopher Yeleighton
2011-08-30 13:51:39 UTC ---
Well, the original documentation now shows up in Konqueror after a little
delay, so the original failure might have been due do a network problem (e.g. a
failed script downlo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #22 from Christopher Yeleighton
2011-08-30 13:10:38 UTC ---
(In reply to comment #21)
> (In reply to comment #20)
> > Please publish your result (just one page will do).
>
> I've deleted it now, you can see for yourself using the (ab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #20 from Christopher Yeleighton
2011-08-22 19:04:50 UTC ---
(In reply to comment #18)
> the konqueror rendering problem is NOT caused by the invalid XHTML.
>
> Using the source code and doxygen config in my doxygen bug report, I chan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #19 from Christopher Yeleighton
2011-08-22 19:03:13 UTC ---
(In reply to comment #16)
> HTML5 specifies exactly how invalid documents must be parsed (to avoid
> security issues with different user-agents parsing the same document
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #13 from Christopher Yeleighton
2011-08-21 21:05:11 UTC ---
(In reply to comment #11)
> Doesn't happen here. Anyway, I still believe that a sensible way to go is
> filing a Bug Report with Doxygen.
Apparently. However, the problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #9 from Christopher Yeleighton
2011-08-21 20:54:33 UTC ---
(In reply to comment #8)
> I don't know which browser you are using, but with Firefox 6 the documentation
> is definitely readable.
Konqueror 4.6
> Also, I don't know if yo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #7 from Christopher Yeleighton
2011-08-21 20:49:10 UTC ---
(In reply to comment #4)
> Bah, in my opinion, if Doxygen otherwise suits our needs we should just keep
> using it and ask users interested in HTML Validator results to file P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #6 from Christopher Yeleighton
2011-08-21 20:45:29 UTC ---
(In reply to comment #3)
> Of course building gcc isn't necessary to run doxygen.
>
I unpacked gcc and I said { make make doc-html-doxygen; }.
Make said "No such target."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #5 from Christopher Yeleighton
2011-08-21 20:41:56 UTC ---
Created attachment 25069
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25069
documentation screen shot
The documentation window contains two frames: the index frame and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #2 from Christopher Yeleighton
2011-08-21 19:33:07 UTC ---
Please tell me if you find the following argument invalid:
1.
It is the responsibility of the library to provide API documentation for the
developers using the library.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
Bug #: 50143
Summary: Doxygen API documentation is invalid
Classification: Unclassified
Product: gcc
Version: 4.5.1
URL: http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754
--- Comment #5 from Christopher Yeleighton
2011-07-15 11:00:28 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Since (x) is uninitialized, so is (x.i).
>
> But what if x.i gets initialized, is x still uninitialized?
If (x.i) den
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754
--- Comment #2 from Christopher Yeleighton
2011-07-15 09:35:42 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > == Expected Results ==
> > foo.c: In function ‘foo’:
> > foo.c:2:?: warning: ‘x’ is used uninitialized in this functi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754
Summary: Let gcc warn about all uninitialized variables
Product: gcc
Version: 4.5.1
URL: https://bugzilla.novell.com/show_bug.cgi?id=705160#c1
Status: UNCONFIRMED
Severity: enhan
71 matches
Mail list logo
