[Bug preprocessor/97998] GCC should not complain about double definitions of macros whose names begin with __STDC_

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97998 --- Comment #3 from Zack Weinberg --- Rather than an ever-growing list of macros that need exempting from this rule, I would suggest flipping it around and only complaining about the "standard predefined" and "common predefined" macros (as the

[Bug preprocessor/97998] GCC should not complain about double definitions of macros whose names begin with __STDC_

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97998 --- Comment #1 from Zack Weinberg --- For more information see Autoconf bug report and APR pull request .

[Bug preprocessor/97998] New: GCC should not complain about double definitions of macros whose names begin with __STDC_

Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- Normally, GCC does not warn about a second definition of a preprocessor macro with the exact same

[Bug c/91554] if (!__builtin_constant_p (fn_arg)) warning_function() works in inline when fn_arg is int, not when it is void *

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554 --- Comment #4 from Zack Weinberg --- (In reply to Richard Biener from comment #3) > I guess you want to use > > __builtin_constant_p (b != 0) > > instead. That wouldn't do what I want. The goal is to warn for any argument _other than_ a

[Bug c/91554] if (!__builtin_constant_p (x)) warning_function() works in inline when x is int, not when x is void *

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554 --- Comment #2 from Zack Weinberg --- Additional fun detail: ``` static inline int thefun (void *a, void *b) { if (!__builtin_constant_p((__UINTPTR_TYPE__)b) || b != 0) thefun_called_with_nonnull_arg(); return real_thefun(a, b); }

[Bug c/91554] New: if (!__builtin_constant_p (x)) warning_function() works in inline when x is int, not when x is void *

: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- This snippet ``` extern void thefun_called_with_nonnull_arg (void) __attribute__((__warning__

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885 --- Comment #13 from Zack Weinberg --- Since examples of this error were observed with base 10, I think the warning should cover 10^i for decimal literal i, too. Relatedly, “note: ^ performs exclusive or, not exponentiation” might be a nice

[Bug preprocessor/80005] cpp expands __has_include() filename parts

||2019-06-12 CC||zackw at panix dot com Ever confirmed|0 |1 --- Comment #1 from Zack Weinberg --- Confirming. This has now bitten an attempt to use __has_include in glibc, see discussion starting at https

[Bug middle-end/88576] -fno-math-errno causes GCC to consider that malloc does not set errno

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 --- Comment #14 from Zack Weinberg --- I don't see why it would _ever_ make sense for -fno-alloc-errno to default to the setting of -fno-math-errno. The math functions and the memory allocation functions are independent components of the C

[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 --- Comment #9 from Zack Weinberg --- ... whoops, hit send a little too early. AFAICT, the relevant code is call_may_clobber_ref_p_1 in tree-ssa-alias.c; I would say that the uses of flag_errno_math under the cases BUILT_IN_MALLOC,

[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 Zack Weinberg changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #8

[Bug c/88576] -fno-math-errno causes GCC to consider that malloc does not set errno

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 Zack Weinberg changed: What|Removed |Added CC||zackw at panix dot com --- Comment #5

[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 Zack Weinberg changed: What|Removed |Added CC||zackw at panix dot com --- Comment #26

[Bug rtl-optimization/86028] New: Dead stores created by va_start/va_arg are not fully cleaned up

Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- On any ABI where arguments to a variadic function are passed in the same places that they would be if they were arguments to a non

[Bug c/3885] Incorrect "invalid suffix on integer constant" error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885 Zack Weinberg changed: What|Removed |Added CC||zackw at panix dot com --- Comment #14

[Bug target/84772] powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772 --- Comment #7 from Zack Weinberg --- I no longer remember enough about GIMPLE to comment on your actual proposed fix, but I do have a small nitpick on the test case: +va_arg (ap, long double); /* { dg-bogus "may be used

[Bug target/84772] powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772 --- Comment #4 from Zack Weinberg --- The last actual _change_ in my GCC build is r258315 | denisc | 2018-03-07 04:13:12 -0500 (Wed, 07 Mar 2018) | 9 lines Backport from mainline 2018-02-07 Georg-Johann Lay

[Bug target/84772] powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772 --- Comment #3 from Zack Weinberg --- Created attachment 43607 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43607=edit -fdump-tree-stdarg output for test case from problem compiler I do not entirely understand how to read this (what do

[Bug target/84772] powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772 --- Comment #2 from Zack Weinberg --- You don't appear to have the exact same build as me. But there's something fishy going on with that, because as far as I can tell, SVN rev 258338 is a *trunk* revision, not a gcc-7-branch revision. Anyway,

[Bug target/84772] New: powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)

Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- The following test case is a mechanical reduction from the implementation of vfpri

[Bug tree-optimization/84673] New: Overcomplicated code generation for a chain of mutually exclusive conditions

: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- This function int has_bad_chars(unsigned char *str, __SIZE_TYPE__ len) { for (unsigned char *c = str; c <

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364 --- Comment #30 from Zack Weinberg --- It's been a very long time and I don't know exactly what changed, but GCC 7.3 generates essentially the same code for both of the functions in the "C test case" and I would not describe that code as "bad".

[Bug c/83236] "Did you mean" suggestions maybe shouldn't offer implementation-private names

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83236 --- Comment #5 from Zack Weinberg --- I was just thinking that other language front-ends might want to offer spell-checking suggestions with their own rules for which names are/aren't appropriate to suggest in context, but maybe we can worry

[Bug c/83236] "Did you mean" suggestions maybe shouldn't offer implementation-private names

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83236 --- Comment #3 from Zack Weinberg --- Maybe name_reserved_for_implementation_p should be a langhook?

[Bug c/83236] New: "Did you mean" suggestions maybe shouldn't offer implementation-private names

Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- On Linux/glibc, $ cat > test.c < ino_t inode; EOF $ gcc -std=c89 -fsyntax-only test.c test.c:2:1: error: unknown

[Bug c/82752] Support %OB, %Ob strftime formats

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82752 Zack Weinberg changed: What|Removed |Added CC||zackw at panix dot com --- Comment #1

[Bug c/82134] warn_unused_result triggers on empty structs even when they are used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82134 --- Comment #2 from Zack Weinberg --- The claim in the Stack Overflow post was that this was useful in a scenario involving machine-generated code that couldn't return void for some external reason, but they didn't go into any kind of detail.

[Bug c/82134] New: warn_unused_result triggers on empty structs even when they are used

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- If a function that returns an empty struct is tagged with attribute warn_unused_result, any call will trigger the warning, even

[Bug middle-end/72826] Poor diagnostic for uninitialized structure field

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72826 --- Comment #2 from Zack Weinberg --- I can persuade it to print instead test2.cc:6:9: warning: ‘timer.countdownTimer::started’ is used uninitialized in this function [-Wuninitialized] by using -O1 instead of -O2 or by removing the line

[Bug c++/72826] New: Poor diagnostic for uninitialized structure field

: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- This cut-down test program... extern "C" int puts(const char *); struct countdownTimer { countdownTimer() : paused{ true } {} void start(

[Bug preprocessor/71102] New: _Pragma("GCC warning ...") should concatenate string literals

ty: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- Consider #define warn1(msg) _Pragma (#msg) #define warn(msg) warn1 (GCC warning msg) #define lengthy_explan

[Bug c++/70178] Loop-invariant memory loads from std::string innards are not hoisted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70178 --- Comment #5 from Zack Weinberg --- It seems to me that a pair of extended integer types (signed and unsigned), that are the same size as `char` but don't get the special TBAA treatment for "character types", would be easier to implement and

[Bug c++/70178] Loop-invariant memory loads from std::string innards are not hoisted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70178 --- Comment #2 from Zack Weinberg --- That was my working hypothesis as well. Isn't there some way we can annotate s->data to reassure the compiler that *this* char* doesn't alias? I don't know enough about the guts of std::string to know

[Bug c++/70178] New: Loop-invariant memory loads from std::string innards are not hoisted

-optimization Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- Consider #include #include #include using std::string; inline unsigned char hexval(unsigned

[Bug c++/68265] Arbitrary syntactic nonsense silently accepted after 'int (*){}' until the next close brace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68265 --- Comment #2 from Zack Weinberg --- This problem apparently goes back at least as far as 4.8. Stack Overflow people found a number of variations, please consult https://stackoverflow.com/questions/23033043/is-it-a-new-c11-style-of-comments

[Bug c++/68265] New: Arbitrary syntactic nonsense silently accepted after 'int (*){}' until the next close brace

Keywords: accepts-invalid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- (From https://stackoverflow.com/questions/33614455/ :) The C++ compiler fails

[Bug driver/68038] New: "Internal compiler error: Killed: program cc1" should read "Virtual memory exhausted"

Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Target Milestone: --- 99+% of the time, when the compiler proper dies on signal 9, it's because we're on Linux a

[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #34 from Zack Weinberg zackw at panix dot com --- As I tried to explain, it is currently design decision to have one declaration and one symtam node for one symbol. The one decl rule was introduced by Codesourcery (Zack) in 2003-4

[Bug lto/62249] Spurious FORTIFY_SOURCE warning with -flto, poll

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62249 --- Comment #4 from Zack Weinberg zackw at panix dot com --- The delta-minimized self-contained test case should require only `-O2 -flto` to reproduce the problem. The other test case, however, should require `-D_FORTIFY_SOURCE=2` in addition

[Bug tree-optimization/63271] New: Should commute arithmetic with vector load

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Consider #include emmintrin.h __m128i foo(char C) { return _mm_set_epi8( 0,C, 2*C, 3*C, 4*C, 5*C

[Bug sanitizer/62307] New: -fsanitize=undefined doesn't pay attention to __attribute__((returns_nonnull))

: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com 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

[Bug sanitizer/62307] -fsanitize=undefined doesn't pay attention to __attribute__((returns_nonnull))

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62307 --- Comment #2 from Zack Weinberg zackw at panix dot com --- (In reply to Marc Glisse from comment #1) -fsanitize=null seems to imply -fno-delete-null-pointer-checks, so I assume this is on purpose. It would actually be quite natural

[Bug lto/62249] New: Spurious FORTIFY_SOURCE warning with -flto, poll

: lto Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com Created attachment 33388 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33388action=edit test case (compile on recent glibc system) Compile the attached program on a recent-glibc system

[Bug lto/62249] Spurious FORTIFY_SOURCE warning with -flto, poll

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62249 --- Comment #1 from Zack Weinberg zackw at panix dot com --- Created attachment 33389 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33389action=edit Delta-minimized self-contained test case Requires no headers anymore. Delta-minimization

[Bug lto/62249] Spurious FORTIFY_SOURCE warning with -flto, poll

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62249 --- Comment #2 from Zack Weinberg zackw at panix dot com --- Incidentally, yes, the test case is based on a real program.

[Bug c++/50595] template overload resolution insufficiently sensitive to name dependency?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50595 Zack Weinberg zackw at panix dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug tree-optimization/62112] New: Optimize out malloc when block is unused or write-only

: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com This program #include string.h #include stdlib.h int main(void) { size_t n = 1000; float *x

[Bug tree-optimization/62112] Optimize out malloc when block is unused or write-only

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62112 --- Comment #2 from Zack Weinberg zackw at panix dot com --- I observe that the `memcpy` does get lowered to inline code. Is it just a phase-ordering problem that we then don't detect the stores as dead?

[Bug preprocessor/61638] New: warning: multi-line comment unclear and has false positives

Severity: enhancement Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com The warning for a // comment continued on the next line by a backslash is warning: multi-line comment, which doesn't make

[Bug tree-optimization/57315] LTO and/or vectorizer performance regression on salsa20 core, 4.7-4.8

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57315 --- Comment #2 from Zack Weinberg zackw at panix dot com --- Created attachment 30210 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30210action=edit self-contained test case Here's a self-contained test case. $ gcc-4.7 -std=c99 -O2 -march

[Bug tree-optimization/57315] New: LTO and/or vectorizer performance regression on salsa20 core, 4.7-4.8

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com I'm seeing a significant performance regression from 4.7 to 4.8 (targeting x86-64) on the salsa20 core function (this is a stream cipher). Repro

[Bug tree-optimization/57230] [4.7/4.8/4.9 Regression] tree-ssa-strlen incorrectly optimizes a strlen to 0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57230 --- Comment #5 from Zack Weinberg zackw at panix dot com --- It might be good to include stores to nonzero offsets in the test case, and stores to bytes that used to be internal NULs, something like int main(void) { char s[] = abc

[Bug tree-optimization/57230] [4.7/4.8/4.9 Regression] tree-ssa-strlen incorrectly optimizes a strlen to 0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57230 --- Comment #8 from Zack Weinberg zackw at panix dot com --- (In reply to Jakub Jelinek from comment #6) We have just one strlen pass instance, and even if we optimize the first strlen there, having strlen pass duplicate constant propagation

[Bug tree-optimization/57230] New: tree-ssa-strlen incorrectly optimizes a strlen to 0

Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zackw at panix dot com GCC 4.7 and 4.8 mis-optimize this test case: int main(void) { char pstring[] = hello world; pstring[0] = (char) (__builtin_strlen(pstring) - 1); __builtin_printf(%zd\n

[Bug middle-end/48580] missed optimization: integer overflow checks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 --- Comment #18 from Zack Weinberg zackw at panix dot com 2013-02-02 21:59:37 UTC --- I find it a little disappointing that what should have been a straightforward additional optimization has gotten totally derailed into bikeshedding

[Bug libstdc++/56166] New: std::string::clear() can allocate memory despite being marked noexcept

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166 Bug #: 56166 Summary: std::string::clear() can allocate memory despite being marked noexcept Classification: Unclassified Product: gcc Version: 4.7.2

[Bug libstdc++/56166] std::string::clear() can throw despite being marked noexcept

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166 --- Comment #1 from Zack Weinberg zackw at panix dot com 2013-01-31 18:21:49 UTC --- Created attachment 29320 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29320 test case In case you're wondering, this was an attempt to do

[Bug libstdc++/56166] std::string::clear() can throw despite being marked noexcept

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166 --- Comment #4 from Zack Weinberg zackw at panix dot com 2013-02-01 00:48:43 UTC --- Is vstring going to be promoted to std::string in the *near* future? it doesn't seem done to me, eg there is no stringstream for it, and it appears

[Bug c++/50595] New: template overload resolution insufficiently sensitive to name dependency?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50595 Bug #: 50595 Summary: template overload resolution insufficiently sensitive to name dependency? Classification: Unclassified Product: gcc Version: 4.6.1 Status:

[Bug c++/50436] New: Crash or hang on invalid template code

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50436 Bug #: 50436 Summary: Crash or hang on invalid template code Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Keywords: ice-on-invalid-code

[Bug c++/50436] Crash or hang on invalid template code

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50436 --- Comment #1 from Zack Weinberg zackw at panix dot com 2011-09-16 19:13:13 UTC --- Here's a variant that hangs. template bool struct VI {}; template typename T struct IP { static const bool r = IPT::r; }; template typename T struct V

[Bug c++/50442] New: Constructing T from implicit conversion to T ambiguous in C++0x mode, not C++98

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442 Bug #: 50442 Summary: Constructing T from implicit conversion to T ambiguous in C++0x mode, not C++98 Classification: Unclassified Product: gcc Version: 4.6.1

[Bug rtl-optimization/48580] New: missed optimization: integer overflow checks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 Summary: missed optimization: integer overflow checks Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: rtl-optimization

[Bug rtl-optimization/48580] missed optimization: integer overflow checks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 --- Comment #2 from Zack Weinberg zackw at panix dot com 2011-04-12 20:40:41 UTC --- (In reply to comment #1) Two signed integers given that they are known to be positive, anyway. This may return unexpected results if either or both

[Bug rtl-optimization/48580] missed optimization: integer overflow checks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 --- Comment #4 from Zack Weinberg zackw at panix dot com 2011-04-12 21:03:01 UTC --- On Tue, Apr 12, 2011 at 1:52 PM, joseph at codesourcery dot com gcc-bugzi...@gcc.gnu.org wrote: In the code that this is cut down from, both arguments are known

[Bug rtl-optimization/48580] missed optimization: integer overflow checks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 --- Comment #5 from Zack Weinberg zackw at panix dot com 2011-04-12 21:04:34 UTC --- Addendum: what would *you* describe as the correct C idiom for ensuring that the product of two signed integers was positive and did not overflow the range

[Bug c++/47723] internal compiler: Segmentation fault - gcc 4.5.2 Arch Linux

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47723 --- Comment #1 from Zack Weinberg zackw at panix dot com 2011-02-13 23:27:10 UTC --- I have run the build a second time and it makes it past the point where it segfaulted, This means your problem is almost certainly *not* a bug in GCC

[Bug c/47623] New: false *negative* uninitialized warning

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47623 Summary: false *negative* uninitialized warning Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo:

[Bug c/45861] New: Possible missed optimization - array ops vs shift-and-mask

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45861 Summary: Possible missed optimization - array ops vs shift-and-mask Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: minor Priority: P3

[Bug c/44179] New: warn about sizeof(char)

Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zackw at panix dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179

[Bug c/44179] warn about sizeof(char)

--- Comment #2 from zackw at panix dot com 2010-05-17 23:59 --- So it has to be a little smarter than the obvious, so what else is new. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179

[Bug c/43691] Code segfault when compiled with -Os, -O2, or -O3

--- Comment #4 from zackw at panix dot com 2010-04-08 17:28 --- (In reply to comment #0) When this testcase, using inline assembly, is compiled with -Os, -O2, or -O3 it segfaults. -O0 and -O1 allow it to run correctly. Moving the inline assembly into a separate file and including

[Bug c/43691] Code segfault when compiled with -Os, -O2, or -O3

-- zackw at panix dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43691

[Bug c++/41233] New: Templated conversion operator produces symbol name that won't demangle

++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zackw at panix dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233

[Bug c/37591] suppress signed and unsigned warnings when signed value known to be positive

--- Comment #5 from zackw at panix dot com 2008-09-22 15:46 --- I'm not monitoring consensus of developers anymore, but I think we *should* either move these warnings to the middle end or do some CCP/VRP in the front ends. The -Wuninitialized warnings are a lot less trouble than

[Bug c/37591] New: suppress signed and unsigned warnings when signed value known to be positive

Product: gcc Version: 4.3.2 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zackw at panix dot com http://gcc.gnu.org/bugzilla

[Bug c/37591] suppress signed and unsigned warnings when signed value known to be positive

--- Comment #2 from zackw at panix dot com 2008-09-19 21:28 --- I'd be fine with it being like uninitialized value warnings. The false positives here are *really* annoying. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591

[Bug c++/34470] [4.3 regression] spurious is used uninitialized from auto_ptr

--- Comment #11 from zackw at panix dot com 2008-01-17 00:13 --- Subject: Re: [4.3 regression] spurious is used uninitialized from auto_ptr I'm not convinced it is a duplicate; no one has determined whether or not the EH region in my case is actually dead. -- http://gcc.gnu.org

[Bug c++/34470] [4.3.0 regression] spurious is used uninitialized from auto_ptr

--- Comment #1 from zackw at panix dot com 2007-12-14 21:26 --- Created an attachment (id=14756) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14756action=view) -fdump-tree-optimized output I looked at the -fdump-tree-optimized output (attached) and it makes somewhat more sense

[Bug c++/34470] [4.3.0 regression] spurious is used uninitialized from auto_ptr

--- Comment #2 from zackw at panix dot com 2007-12-14 21:33 --- Ooh, it gets worse. The spurious diagnostic is a symptom of an incorrect optimization. In normal control flow, the result of get_hash is assigned to a synthetic variable, D.13336, and that variable is used to call

[Bug c++/34470] New: [4.3.0 regression] spurious is used uninitialized from auto_ptr

Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zackw at panix dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu

[Bug c++/34470] [4.3.0 regression] spurious is used uninitialized from auto_ptr

--- Comment #4 from zackw at panix dot com 2007-12-14 22:31 --- How do you know whether an EH region is dead? That information does not seem to be in the dumps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34470

[Bug c++/34470] [4.3.0 regression] spurious is used uninitialized from auto_ptr

--- Comment #6 from zackw at panix dot com 2007-12-14 22:45 --- How do you know whether an EH region is dead is still a live question for this bug. Not turning hash$_M_ptr into D.13336 is only a wrong-code bug if the block can be executed. -- http://gcc.gnu.org/bugzilla

[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class

--- Comment #4 from zackw at panix dot com 2007-11-12 19:41 --- I am no C++ expert, so I don't know what new pure (*[3]) actually means, but I am nearly certain it does *not* mean allocate an array of 3 pointers to type pure. That would be new pure *[3] without the parentheses

[Bug driver/30972] Call to _access has invalid parameter when linked with msvcrt (for vista)

--- Comment #5 from zackw at panix dot com 2007-09-06 17:35 --- Nah, probably no one will ever get round to it and it's not that important. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972

[Bug middle-end/32441] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:7109

--- Comment #9 from zackw at panix dot com 2007-07-06 17:59 --- Ian Taylor and I found a simpler patch that does not use langhooks, and also has the virtue of working. ;-) Committed as rev 126424. -- zackw at panix dot com changed: What|Removed

[Bug target/32659] New: abort during reload on (subreg:PSI (reg:DI ...) 4)

ReportedBy: zackw at panix dot com GCC target triplet: m32c-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32659

[Bug target/32659] abort during reload on (subreg:PSI (reg:DI ...) 4)

--- Comment #1 from zackw at panix dot com 2007-07-06 22:12 --- Created an attachment (id=13858) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13858action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32659

[Bug target/32659] abort during reload on (subreg:PSI (reg:DI ...) 4)

--- Comment #2 from zackw at panix dot com 2007-07-07 00:05 --- *** This bug has been marked as a duplicate of 32656 *** -- zackw at panix dot com changed: What|Removed |Added

[Bug middle-end/32656] [4.3 regression] m32c: ICE in smallest_mode_for_size, at stor-layout.c:220

--- Comment #2 from zackw at panix dot com 2007-07-07 00:05 --- *** Bug 32659 has been marked as a duplicate of this bug. *** -- zackw at panix dot com changed: What|Removed |Added

[Bug middle-end/32656] [4.3 regression] m32c: ICE in smallest_mode_for_size, at stor-layout.c:220

--- Comment #3 from zackw at panix dot com 2007-07-07 00:06 --- Created an attachment (id=13859) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13859action=view) Minimized test case Here's a minimal test case (from my duplicate report of this, #32659). I analyzed it a bit

[Bug middle-end/32656] [4.3 regression] m32c: ICE in smallest_mode_for_size, at stor-layout.c:220

--- Comment #4 from zackw at panix dot com 2007-07-07 00:07 --- Adding DJ to cc: list, confirming. -- zackw at panix dot com changed: What|Removed |Added

[Bug middle-end/32656] [4.3 regression] m32c: ICE in smallest_mode_for_size, at stor-layout.c:220

--- Comment #5 from zackw at panix dot com 2007-07-07 00:15 --- Created an attachment (id=13860) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13860action=view) Even smaller test case -- zackw at panix dot com changed: What|Removed |Added

[Bug middle-end/32656] [4.3 regression] m32c: ICE in smallest_mode_for_size, at stor-layout.c:220

--- Comment #6 from zackw at panix dot com 2007-07-07 00:20 --- Created an attachment (id=13861) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13861action=view) and smaller still I can't believe I didn't think of these reductions three hours ago... -- zackw at panix dot com

[Bug c++/17422] Duplicate work, missed optimizations for registration of static destructors

--- Comment #4 from zackw at panix dot com 2007-06-06 00:41 --- Subject: Re: Duplicate work, missed optimizations for registration of static destructors It's better, but build_cleanup is still being called twice in the non-__cxa_atexit case, and I can't tell whether there is any

[Bug libstdc++/31906] -Xcompiler is inserted after -Xlinker when building libstdc++

--- Comment #3 from zackw at panix dot com 2007-05-12 07:34 --- I believe Mike means to suggest you use -Wl,yada,yada,yada instead of -Xlinker yada -Xlinker yada -Xlinker yada. (I also suspect this will help.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906

[Bug driver/30972] Call to _access has invalid parameter when linked with msvcrt (for vista)

--- Comment #3 from zackw at panix dot com 2007-05-10 08:36 --- What the heck are we doing calling access() in the first place? We should just go ahead and try to execute .../cc1.exe for all relevant paths. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972

[Bug preprocessor/11242] [mingw32] #include memory takes my memory directory instead of the standard memory header file

--- Comment #6 from zackw at panix dot com 2007-04-21 02:56 --- I am inclined to think that this is an operating system bug and should be worked around in the mingw32 libraries, not in cpplib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11242

[Bug fortran/31519] spurious ICE messages when module does not compile

--- Comment #6 from zackw at panix dot com 2007-04-15 21:22 --- Bugs where the compiler proper crashes when run under the driver, but not when run directly, can often be reproduced by varying the amount of space taken up by environment variables, e.g. x= while :; do x=x$x X=$x

[Bug libstdc++/31464] New: Extension request: publicly visible forward-declaration headers for string and all STL containers

++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zackw at panix dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31464

  1   2   >