Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
Target Milestone: ---
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92797
--- Comment #5 from Tim Ruehsen ---
(In reply to ibuclaw from comment #4)
> At what point does the D demangler kick in? It should only attempt to parse
> symbols that begin with '_D'.
There is a reproducer attached. See my initial comment on ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92456
--- Comment #2 from Tim Ruehsen ---
(In reply to Martin Liška from comment #1)
> @Tim: Can you please send the patch to GCC patches mailing list?
It's long ago, but finally found it:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02593.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92797
--- Comment #3 from Tim Ruehsen ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Tim Ruehsen from comment #1)
> > BTW, llvm-cxxfilt does not show this behavior.
>
> Could it because it does not implement the D demangler?
Good poin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92453
--- Comment #3 from Tim Ruehsen ---
(In reply to Christian Biesinger from comment #2)
> Could you send your patch to gcc-patches per
> https://gcc.gnu.org/contribute.html#patches ? Thanks!
I did that some days ago:
https://gcc.gnu.org/ml/gcc-pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92797
--- Comment #1 from Tim Ruehsen ---
BTW, llvm-cxxfilt does not show this behavior.
Priority: P3
Component: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
Target Milestone: ---
Created attachment 47418
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47418&action=edit
700mb output reproducer
c++fi
Component: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
Target Milestone: ---
c++filt
'_ZZ1_DO1z1psp1VEz1VE2On'
takes ~1200s to finish.
Relevant p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92453
--- Comment #1 from Tim Ruehsen ---
Created attachment 47279
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47279&action=edit
Fix write buffer overflow in cplus_demangle()
Correctly calculate the demangled size by using two passes.
: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
Target Milestone: ---
Created attachment 47209
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47209&action=edit
Patch proposal to
: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
Target Milestone: ---
The following code, compiled in libiberty/ causes a write buffer overflow in
cplus_demangle().
### repro1.c ###
#include "../include/demangle.h"
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946
--- Comment #8 from Tim Ruehsen ---
Here is a good blog post about pointer overflow:
https://blog.regehr.org/archives/1395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946
--- Comment #7 from Tim Ruehsen ---
Thanks for the explanations :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91946
--- Comment #2 from Tim Ruehsen ---
Is ssize_t C99 ?
Could you point to the specs so that any reader can verify that ?
And by UB you mean, gcc sometimes gives 0 and sometimes 1 ? Even if it's UB,
the behavior should be consistent.
Since this i
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
Target Milestone: ---
The following code compiled with -m32 (alternatively when on a 32bit system)
shows wrong output with gcc 8.3.0 and gcc 9.2.1. gcc 7.4.0 is not
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
Target Milestone: ---
The command line option '-Werror-implicit-function-declaration' is listed by
`gcc -Q --help=warning[,C]` and also accepted by gcc 4.6 up to 9.1.
But `man gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84883
--- Comment #2 from Tim Ruehsen ---
(In reply to Martin Sebor from comment #1)
> (b) could be implemented in the C/C++ front ends which do have access
> to the algorithm but not to data flow analysis, so the warning there would
> be quite simplis
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
Target Milestone: ---
Created attachment 43669
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43669&action=edit
Small test code
It would be nice to a warning (option) if accid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81598
--- Comment #2 from Tim Ruehsen ---
(In reply to Jakub Jelinek from comment #1)
> This isn't a load, it is a cast, we sanitize just loads from memory.
Hmmm, seems ok if the compiler doesn't warn.
But the sanitizer IMO should trigger.
What if th
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.ruehsen at gmx dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #51 from Tim Ruehsen ---
(In reply to Martin Sebor from comment #50)
> Yes, -Wnull-dereference is only in GCC 6 and later. -Wnonnull is in 5 and
> prior but it does only a superficial job of checking (it only detects null
> pointer c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #42 from Tim Ruehsen ---
(In reply to Jeffrey A. Law from comment #41)
> Actually I think we want the concept of never returns NULL, both as an
> attribute and as a property the compiler can discover by analysis. Given
> that propert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #28 from Tim Ruehsen ---
I far as I can read, not a patch is missing. A review + commit is missing.
How can you ask for more developers (=patches) when the work is ignored ?
Don't get me wrong, I just try to understand how this should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Tim Ruehsen changed:
What|Removed |Added
CC||tim.ruehsen at gmx dot de
--- Comment #23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871
--- Comment #4 from Tim Ruehsen 2012-07-10 07:58:26
UTC ---
(In reply to comment #3)
> I have thought a lot how to attract more and new developers to GCC who will be
> willing to develop things that are not a priority for current developers, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871
--- Comment #2 from Tim Ruehsen 2012-07-09 11:50:19
UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > Obvious endless loops could be reported, e.g. if the loop condition doesn't
> > change and the loop can't be left otherwise.
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871
Bug #: 53871
Summary: Please warn about endless loops if they are obvious
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49748
Tim Ruehsen changed:
What|Removed |Added
CC||tim.ruehsen at gmx dot de
--- Comment #3
29 matches
Mail list logo
