[Bug c/72783] New: Fortify scanf %s, %[ conversion specifiers

Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- A somewhat common source of buffer overflows are %s and %[ conversions in scanf parsers, where the input string (and the extracted region

[Bug c++/36159] C++ compiler should issue a warning with missing new operator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159 Florian Weimer changed: What|Removed |Added See Also||https://sourceware.org/bugz

[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445 --- Comment #15 from Florian Weimer --- There is now a proposal to revert the glibc change instead: https://sourceware.org/ml/libc-alpha/2016-06/msg00339.html

[Bug c/71255] Implement #pragma may_alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 --- Comment #28 from Florian Weimer --- We can put such a version check into the glibc headers and see how it works out in practice. As long as there is consensus to fix any related breakage (related to the attribute and forward declarations)

[Bug c/71255] Implement #pragma may_alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 --- Comment #25 from Florian Weimer --- (In reply to Manuel López-Ibáñez from comment #23) > (In reply to Florian Weimer from comment #22) > > (In reply to Marek Polacek from comment #21) > > > The testcase in Comment 14 should now compile fine.

[Bug c/71255] Implement #pragma may_alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 --- Comment #22 from Florian Weimer --- (In reply to Marek Polacek from comment #21) > The testcase in Comment 14 should now compile fine. What's the best way to detect that a compiler has this fix? We cannot use a configure check. Is there

[Bug c/71255] Implement #pragma may_alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 --- Comment #20 from Florian Weimer --- (In reply to rguent...@suse.de from comment #19) > On Fri, 27 May 2016, fw at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 > > > > --- Comment

[Bug c/71255] Implement #pragma may_alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 --- Comment #18 from Florian Weimer --- (In reply to rguent...@suse.de from comment #17) > On Fri, 27 May 2016, fw at gcc dot gnu.org wrote: > > I think the real question is whether it matters anywhere if a pointer to an > > in

[Bug c/71255] Implement #pragma may_alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 --- Comment #16 from Florian Weimer --- (In reply to Marek Polacek from comment #15) > Yeah, only the C++ side was changed. I think it's wrong that we reject the > testcase in Comment 14 in C (I have a fix for that). Good. > But even with

[Bug c/71255] Implement #pragma may_alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 --- Comment #14 from Florian Weimer --- I believe the equivalent C test case: #include struct sockaddr; struct sockaddr *f(); struct __attribute__((may_alias)) sockaddr {}; struct sockaddr *f() { return NULL; } still does not work:

[Bug c/71255] Implement #pragma may_alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 --- Comment #9 from Florian Weimer --- (In reply to rguent...@suse.de from comment #8) > While a pragma might work I'd say for the case in question we'd like to > have a "tentative" forward declaration that can be merged with subsequent >

[Bug c/71255] Auto-annotate sockaddr related structs with may_alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 --- Comment #5 from Florian Weimer --- (In reply to Marek Polacek from comment #4) > Can you provide an example how do you envision such a pragma? Should it > only have an effect on "sockaddr{,_*}"-named structs? I expect that we'd put

[Bug c/71255] Auto-annotate sockaddr related structs with may_alias

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #3

[Bug sanitizer/71160] New: libasan: Backport support for malloc within dlsym

: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org 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 Target Milestone: --- Please backport this ASAN

[Bug c/70753] missing diagnostic in C11 mode: sizeof, _Alignof of function type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70753 --- Comment #2 from Florian Weimer --- (In reply to Marek Polacek from comment #1) > Why would it have to be error? If you want errors instead of warnings, use > -pedantic-errors. I did not know about -pedantic-errors. It is extremely

[Bug c/70753] New: missing diagnostic in C11 mode: sizeof, _Alignof of function type

-invalid Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- GCC accepts this code, but sizeof of a function type is invalid in C11 (and likely earlier

[Bug c/70458] Function and function pointers that, when called, imply an optimization barrier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70458 --- Comment #3 from Florian Weimer --- (In reply to Richard Biener from comment #2) > I also seriously question > > "The glibc consensus is to keep such calls." > > can you provide a reference to the relevant discussion?

[Bug c/70458] New: Function and function pointers that, when called, imply an optimization barrier

: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- In glibc, we have a few cases where we call a function through an inappropriately typed function pointer, or from a different

[Bug c++/70126] VLA accepted in sizeof and typedef, allowing integer overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70126 --- Comment #1 from Florian Weimer --- There seems to be a fundamental incompatibility here with supporting the GNU CC VLA extension and this new (and apparently dead) C++ VLA specification. I wonder how much existing G++ code applies sizeof to

[Bug c/66298] -Wmisleading-indentation should also detect missing indentation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66298 --- Comment #1 from Florian Weimer --- Other examples. All should receive warnings. while (check_something()) // do_something(); (commented out) do_something(); if (check_something()) #include "/dev/null" do_something(); if

[Bug c++/69843] C++: Inconsistent treatment of may_alias attribute and forward declarations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69843 --- Comment #2 from Florian Weimer --- (In reply to Jakub Jelinek from comment #1) > Is the forward declaration here in glibc headers? > If yes, using __attribute__((may_alias)) there too wouldn't hurt. > Or do you mean users forward declare

[Bug c++/69843] New: C++: Inconsistent treatment of may_alias attribute and forward declarations

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- This is a bit inconsistent. I would expect an error on the definition because it is inconsistent with the forward declaration

[Bug middle-end/69537] New: Incorrect -Wmaybe-uninitialized warning with enum variable

Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- gcc -O2 -Wall yields: t.c: In function ‘yp_update’: t.c:27:3: warning: ‘master’ may be used uninitialized in this function [-Wmaybe

[Bug tree-optimization/69359] Warn about constant comparisons between pointers and arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69359 --- Comment #2 from Florian Weimer --- (In reply to Jakub Jelinek from comment #1) > I'd find warning about p <= weird, warning about p < a makes sense, as well > as e.g. > int g (void) > { > int a[3], b; > int *p = f (a, ); > return (p <

[Bug tree-optimization/69359] New: Warn about constant comparisons between pointers and arrays

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- This code fragment should result in a warning because p < a can never be true. int *f (int *); int g (void) { int a[3]; int

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69002 --- Comment #5 from Florian Weimer --- (In reply to Marek Polacek from comment #4) > The footnote to 6.5.2.3/5 says "Members can be safely accessed using a > non-atomic object which is assigned to or from the atomic object." Does it > mean that

[Bug c/69002] C front end should warn about undefined access to atomic structure or union

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69002 --- Comment #2 from Florian Weimer --- (In reply to Martin Sebor from comment #1) > I actually wouldn't want to see GCC start issuing warnings for this code > because it has well-defined semantics there. Unfortunately, the generated code is

[Bug c/69002] New: C front end should warn about undefined access to atomic structure or union

: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- The following code currently compiles without warnings (apart from the -Wunused-but-set-parameter warning), but the standard says

[Bug tree-optimization/68680] New: On-stack VLA does not cause instrumentation with -fstack-protector-strong

: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Target: x864_64-redhat-linux-gnu This test case int process(char *); int uses_vla(unsigned long sz

[Bug rtl-optimization/68537] Vectorizer possibly miscompiles dynamic linker with -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68537 --- Comment #8 from Florian Weimer --- (In reply to Markus Trippelsdorf from comment #7) > Well, only Haskell programs crash. This is a valid point. You can open a GHC ticket in Trac, after registering:

[Bug tree-optimization/68537] Vectorizer possibly miscompiles dynamic linker with -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68537 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #1

[Bug tree-optimization/68537] Vectorizer possibly miscompiles dynamic linker with -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68537 --- Comment #3 from Florian Weimer --- (In reply to Markus Trippelsdorf from comment #0) > rbp0x7fffa148 0x7fffa148 (In reply to Markus Trippelsdorf from comment #2) > 1470 <_dl_lookup_symbol_x>: > 1470:

[Bug rtl-optimization/68537] Vectorizer possibly miscompiles dynamic linker with -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68537 --- Comment #6 from Florian Weimer --- (In reply to Markus Trippelsdorf from comment #5) > Ok. Well, I'm running GHC version 7.10.2, which is the latest. > (Not sure how to report this issue to the ghc folks). To be honest, if Richard thinks

[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #14 from Florian Weimer --- (In reply to Szabolcs Nagy from comment #13) > if gcc treats p-q as (ssize_t)p-(ssize_t)q and makes > optimization decisions based on signed int range then > that's broken and leads to wrong code gen.

[Bug c/67999] Wrong optimization of pointer comparisons

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 Florian Weimer changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug c/67999] Wrong optimization of pointer comparisons

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 --- Comment #11 from Florian Weimer --- (In reply to Daniel Micay from comment #9) > I don't think there's much of a use case for allocating a single >2G > allocation in a 3G or 4G address space. The main OpenJDK heap (well, it was Java back

[Bug c/67999] Wrong optimization of pointer comparisons

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #7

[Bug c/67999] Wrong optimization of pointer comparisons

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 --- Comment #12 from Florian Weimer --- (In reply to Daniel Micay from comment #10) > (In reply to Florian Weimer from comment #7) > > If this is not a GCC bug and it is the responsibility of allocators not to > > produce huge objects, do we

[Bug c/67999] Wrong optimization of pointer comparisons

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 --- Comment #8 from Florian Weimer --- (In reply to Alexander Cherepanov from comment #4) > Am I right that the C standards do not allow for such a limitation (and > hence this should not be reported to glibc as a bug) and gcc is not >

[Bug libstdc++/65142] std::random_device Ignores Read Return Code (CVE-2015-5276)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142 --- Comment #15 from Florian Weimer --- (In reply to Jonathan Wakely from comment #14) > Do we want this on gcc-4_9-branch too? Yes, I think so. It's non-invasive, and it's not in templates/inline functions, so those who use dynamic linking

[Bug rtl-optimization/8537] Optimizer Removes Code Necessary for Security

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537 Florian Weimer fw at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |INVALID

[Bug ada/57902] Bugbox in Ada 95 mode, at ada/gcc-interface/decl.c:342

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57902 Florian Weimer fw at gcc dot gnu.org changed: What|Removed |Added Attachment #30507|0 |1

[Bug ada/57902] New: Bugbox in Ada 95 mode, at ada/gcc-interface/decl.c:342

Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Host: amd64-debian-linux-gnu Target: amd64-debian-linux-gnu Build: amd64-debian-linux-gnu Created attachment 30507 -- http://gcc.gnu.org/bugzilla

[Bug other/54411] libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411 --- Comment #5 from Florian Weimer fw at gcc dot gnu.org 2012-09-18 08:34:12 UTC --- Author: fw Date: Tue Sep 18 08:34:05 2012 New Revision: 191413 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191413 Log: PR other/54411: integer overflow

[Bug other/54411] New: libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411 Bug #: 54411 Summary: libiberty: objalloc_alloc integer overflows (CVE-2012-3509) Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED

[Bug other/54411] libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411 Florian Weimer fw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last

[Bug other/54411] libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411 --- Comment #3 from Florian Weimer fw at gcc dot gnu.org 2012-08-29 19:18:58 UTC --- (In reply to comment #2) You do realise that pretty much nothing in the toolchain checks for overflows in calculating allocation sizes? bfd_alloc2 (bfd's

[Bug c++/19351] [DR 624] operator new[] can return heap blocks which are too small

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351 --- Comment #27 from Florian Weimer fw at gcc dot gnu.org 2012-08-20 21:13:29 UTC --- Author: fw Date: Mon Aug 20 21:13:23 2012 New Revision: 190546 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190546 Log: Fix PR C++/19351: integer

[Bug c++/19351] [DR 624] operator new[] can return heap blocks which are too small

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351 Florian Weimer fw at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED

[Bug c++/53972] New: array constant expression expression not valid as template argument

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53972 Bug #: 53972 Summary: array constant expression expression not valid as template argument Classification: Unclassified Product: gcc Version: 4.8.0 Status:

[Bug target/52554] Variable called $1 causes invalid asm to be generated

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52554 Florian Weimer fw at gcc dot gnu.org changed: What|Removed |Added Keywords|accepts-invalid, wrong-code

[Bug c++/19351] operator new[] can return heap blocks which are too small

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351 --- Comment #24 from Florian Weimer fw at gcc dot gnu.org 2011-05-24 19:54:47 UTC --- (In reply to comment #23) Florian, your patch seems to have gone unreviewed, could you ping it? Jason reviewed it and Ian, too (off-list). I haven't yet

[Bug c++/19351] operator new[] can return heap blocks which are too small

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351 Florian Weimer fw at gcc dot gnu.org changed: What|Removed |Added CC||fw at gcc dot

[Bug other/39933] make clean fails in libgcc

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933 Florian Weimer fw at gcc dot gnu.org changed: What|Removed |Added CC||fw at gcc dot

[Bug c++/41874] Incorrect dereferencing type-punned pointer will break strict-aliasing rules warning

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874 Florian Weimer fw at gcc dot gnu.org changed: What|Removed |Added CC||fw at gcc dot

<    1   2   3   4   5