Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkylheku at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38990
--- Comment #2 from kkylheku at gmail dot com 2009-01-28 16:30 ---
(In reply to comment #1)
> Confirmed.
Thanks. By the way, I started looking at patching this. My suspicions were
confirmed that this is a case of pasting together invalid tokens. The compiler
sees the tok
appear in
cross toolchain.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkylheku at gmail dot com
--- Comment #1 from kkylheku at gmail dot com 2008-02-23 01:35 ---
Created an attachment (id=15210)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15210&action=view)
Patch to gcc/prefix.c for path relocation.
At some point gcc/gcc.c calls the function set_std_prefix
--- Comment #2 from kkylheku at gmail dot com 2008-02-23 01:40 ---
Created an attachment (id=15211)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15211&action=view)
Hack to not have /lib and /usr/ paths in cross-compiler.
I don't know whether this path is right in gen
--- Comment #3 from kkylheku at gmail dot com 2008-02-23 02:18 ---
Oops, I spoke to soon. The no-prefix-search path breaks my final gcc build,
with shared libraries and glibc. When making libgcc_s.so, it can't find the
crti.o module.
What's happening is two problems.
F
--- Comment #5 from kkylheku at gmail dot com 2008-02-23 04:58 ---
(In reply to comment #4)
> [crti.o is] found through multilib os-directory suffixes.
Actually, I'm even more confused, because the breakage I'm seeing is simply
arising from mips64-linux-ld being called
--- Comment #6 from kkylheku at gmail dot com 2008-02-23 05:06 ---
(In reply to comment #5)
> (In reply to comment #4)
> > [crti.o is] found through multilib os-directory suffixes.
> Actually, I'm even more confused, because the breakage I'm seeing is simply
>
--- Comment #7 from kkylheku at gmail dot com 2008-02-23 08:03 ---
Both my patches apply even if Carlos' patches are removed. The crti.o problem
remains.
What's happening is that xgcc actually searches for the crti.o module, and then
passes the full path to crti.o down to c
--- Comment #8 from kkylheku at gmail dot com 2008-02-23 08:54 ---
I ended up doing the symlink trick because quite a bit of the sysroot material
is needed to build everything, like libstdc++. It worked like a charm. And so
now I have a compiler with search paths only in its own tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
Kaz Kylheku changed:
What|Removed |Added
CC||kkylheku at gmail dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Kaz Kylheku changed:
What|Removed |Added
CC||kkylheku at gmail dot com
--- Comment #45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #46 from Kaz Kylheku ---
C pseudocode in light of previous comment:
double abused_fortran_fn(double x, double y, char str[1], int len)
{
if (len != 1)
return abused_fortran_fn(x, y, str, 1); /* full call, not tail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #48 from Kaz Kylheku ---
(In reply to Thomas Koenig from comment #47)
> I see two problems with this suggestion, one minor and one major.
>
> First, there may well be a value > 1 on the stack for a regular
> call, see comment #15.
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
--- Comment #11 from Kaz Kylheku ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to Kaz Kylheku from comment #1)
> > Created attachment 15798 [details]
> > Implements -Wunused-objects warning for C++.
>
> Patches need to be pr
--- Comment #4 from kkylheku at gmail dot com 2009-12-11 02:34 ---
(In reply to comment #3)
> This would have prevented bugs I've dealt with where critical sections where
> not protected:
> {
> lock_guard (mutex);
> // mutex NOT locked here!
> }
> But I&
--- Comment #6 from kkylheku at gmail dot com 2009-12-11 11:57 ---
(In reply to comment #5)
> (In reply to comment #4)
> > > But I'm not convinced that doing this is always a mistake.
> >
> > Since we don't care about the object, we must care about th
--- Comment #1 from kkylheku at gmail dot com 2007-12-14 02:51 ---
Created an attachment (id=14749)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14749&action=view)
Patch for caller used registers in mark_set_resources.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34456
ent: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkylheku at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34456
ncement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkylheku at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
--- Comment #1 from kkylheku at gmail dot com 2008-06-20 19:23 ---
Created an attachment (id=15798)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15798&action=view)
Implements -Wunused-objects warning for C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
--- Comment #2 from kkylheku at gmail dot com 2008-06-20 20:26 ---
I should add that this is different from -Wunused-value, because I want this
warning emitted even if the constructor (or its corresponding destructor) have
side effects.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317
Kaz Kylheku changed:
What|Removed |Added
CC||kkylheku at gmail dot com
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
--- Comment #15 from Kaz Kylheku ---
(In reply to Manuel López-Ibáñez from comment #13)
> (In reply to Kaz Kylheku from comment #11)
> > I deployed that change to large team of developers, and the toolchain with
> > that change went to customers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
--- Comment #16 from Kaz Kylheku ---
(In reply to Andrew Pinski from comment #14)
> C++17 adds nodiscard attribute which can be placed on class/struct types,
> functions, constructors and others and then you get a warning if you ignore
> the valu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
--- Comment #19 from Kaz Kylheku ---
(In reply to Jonathan Wakely from comment #18)
> Was there an earlier submission?
No there wasn't; that's my mistake in my comment.
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kkylheku at gmail dot com
Target Milestone: ---
There seems to be a historic misconception in the development of GCC that the C
standard prohibits extensions. The -Wpedantic/-pedantic options are
unfortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #3 from Kaz Kylheku ---
(In reply to Andrew Pinski from comment #2)
> Actually it is a required diagnostic. See PR 11234 for explanation on how.
> This was changed a little over 20 years ago explictly to reject this because
> it is i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
Kaz Kylheku changed:
What|Removed |Added
CC||kkylheku at gmail dot com
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #7 from Kaz Kylheku ---
Also, it would be useful for the documentation to list all the -W-* options
that are implied by -Wpedantic.
The function/object pointer conversion diagnostics, unfortunately, are tied to
-Wpedantic itself, wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #12 from Kaz Kylheku ---
(In reply to Harald van Dijk from comment #10)
> Sorry, sent my earlier comment too soon.
>
> (In reply to Joseph S. Myers from comment #8)
> > I believe conversions between function and object pointers are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #13 from Kaz Kylheku ---
(In reply to Joseph S. Myers from comment #11)
> I think that simply failing to say whether a value of type X may be
> converted to type Y is clearly enough for it at least to be unspecified
> whether or when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #17 from Kaz Kylheku ---
(In reply to Harald van Dijk from comment #14)
> (In reply to Joseph S. Myers from comment #11)
> > I think that simply failing to say whether a value of type X may be
> > converted to type Y is clearly enoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #19 from Kaz Kylheku ---
(In reply to Harald van Dijk from comment #18)
> (In reply to Kaz Kylheku from comment #17)
> > The standrad does not define the conversion at the *type* level.
> > ...
> > The program is strictly conforming
34 matches
Mail list logo
