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
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
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/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=edit
700mb output reproducer
c++file `cat slow-u
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 part
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=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=edit
Patch proposal to fix the is
: 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
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
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 gcc` doesn't
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
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=edit
Small test code
It would be nice to a warning (option) if accidenta
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #42 from Tim Ruehsen tim.ruehsen at gmx dot de ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #28 from Tim Ruehsen tim.ruehsen at gmx dot de ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Tim Ruehsen tim.ruehsen at gmx dot de changed:
What|Removed |Added
CC||tim.ruehsen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871
--- Comment #4 from Tim Ruehsen tim.ruehsen at gmx dot de 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871
--- Comment #2 from Tim Ruehsen tim.ruehsen at gmx dot de 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
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 tim.ruehsen at gmx dot de changed:
What|Removed |Added
CC||tim.ruehsen at gmx
29 matches
Mail list logo
