[Bug sanitizer/59275] Document environment variables used by the sanitizers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59275 --- Comment #5 from Tobias Burnus --- Author: burnus Date: Sat Nov 30 09:11:13 2013 New Revision: 205548 URL: http://gcc.gnu.org/viewcvs?rev=205548&root=gcc&view=rev Log: 2013-11-30 Tobias Burnus PR sanitizer/59275 * doc/invoke.texi (-fsanitize=address,leak): Mention the * associated environment variable and link to a list with flags. (-fsanitize=thread): Ditto and update link. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug sanitizer/59275] Document environment variables used by the sanitizers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59275 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tobias Burnus --- Close as sufficiently FIXED. However, on the Wiki side, one should add the missing items, cf. comment 2, to ASAN/TSAN - and LSAN completely misses a flag description. Kostya: What's the best way to get them added to the Wiki pages?
[Bug c++/59352] New: Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59352 Bug ID: 59352 Summary: Internal compiler error Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vinnie.falco at gmail dot com Created attachment 31337 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31337&action=edit Sample code that shows both the line that crashes the compiler and a work-around. A function local variable is initialized using constructor syntax from a template function call. The result is that the compiler crashes with an internal error. However, if the same local variable is constructed using assignment syntax, the internal error disappears. I have a working code sample with no external dependencies. Here is the line that crashes: std::size_t const id (BasicInterface::type_id ()); Changing to the following resolves the issue: std::size_t const id = BasicInterface::type_id (); The only difference is that one uses constructor syntax, and the other uses assignment syntax. This problem happens both in gcc 4.7.3 and also gcc 4.8.1 Tested under Ubunty 12.04
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 --- Comment #18 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #17) > Perhaps add new attribute ssememalign, with default 0, which would be > (maximum for all alternatives) required alignment for memory operands in the > instruction pre-AVX, or 0 for GET_MODE_ALIGNMENT. So, instructions that can > handle completely unaligned loads/stores in all alternatives would have > ssememalign 8, > instructions that require everything properly aligned would have default > ssememalign 0, and say movlps/movhps would have ssememalign 64. The default > would be conservatively correct, so whether instructions would have > ssememalign attribute would be just an optimization issue (but, if it would > be non-zero, it would have to be correct). This sounds like a good approach to me.
[Bug fortran/57445] [4.8/4.9 Regression][OOP] ICE in gfc_conv_class_to_class - for OPTIONAL polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57445 --- Comment #4 from Paul Thomas --- Author: pault Date: Sat Nov 30 10:58:42 2013 New Revision: 205549 URL: http://gcc.gnu.org/viewcvs?rev=205549&root=gcc&view=rev Log: 2013-11-30 Paul Thomas PR fortran/57445 * trans-expr.c (gfc_conv_class_to_class): Remove spurious assert. 2013-11-30 Paul Thomas PR fortran/57445 * gfortran.dg/optional_class_1.f90 : New test Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/optional_class_1.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/trans-expr.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/57445] [4.8/4.9 Regression][OOP] ICE in gfc_conv_class_to_class - for OPTIONAL polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57445 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- Fixed on trunk and 4.8. Thanks for the report Paul
[Bug sanitizer/59353] New: -fsanitize=return is not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59353 Bug ID: 59353 Summary: -fsanitize=return is not documented Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: burnus 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, mpolacek at gcc dot gnu.org Seems as if -fsanitize=return is now supported, but now yet documented in invoke.texi
[Bug sanitizer/59353] -fsanitize=return is not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59353 --- Comment #1 from Tobias Burnus --- And looking at https://code.google.com/p/address-sanitizer/wiki/ExampleUseAfterReturn - it seems as if the options is called -fsanitize=use-after-return with Clang. Having different names for the same feature is a bit unfortunate, too. Especially as GCC -fsanitize= links to Wiki pages which are Clang centric.
[Bug sanitizer/59353] -fsanitize=return is not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59353 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-30 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- As for the doc, I'll do it. But note that -fsanitize=return and -fsanitize=use-after-return are two different options: -fsanitize=return is a part of ubsan and checks that the function doesn't have a missing "return" statement (currently done only for C++). -fsanitize=use-after-return is described in the link you provided and is a part of asan.
[Bug driver/59321] -fuse-ld has no effect on -print-prog-name nor on --with-ld=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321 H.J. Lu changed: What|Removed |Added Summary|-fuse-ld has no effect on |-fuse-ld has no effect on |-print-prog-name nor on |-print-prog-name nor on |--program-prefix= |--with-ld= --- Comment #14 from H.J. Lu --- (In reply to H.J. Lu from comment #13) > When --program-prefix= is used to configure GCC, -fuse-ld > doesn't work since DEFAULT_LINKER is defined. Patch in > comment 12 also fixes collect2. The problem is GCC configured with --with-ld=, which sets DEFAULT_LINKER.
[Bug driver/59321] -fuse-ld has no effect on -print-prog-name nor on --with-ld=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321 H.J. Lu changed: What|Removed |Added Attachment #31336|0 |1 is obsolete|| --- Comment #15 from H.J. Lu --- Created attachment 31338 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31338&action=edit A patch with collect2 and HOST_EXECUTABLE_SUFFIX fixes This patch handles collect2 and HOST_EXECUTABLE_SUFFIX. But HOST_EXECUTABLE_SUFFIX is untested.
[Bug c++/59354] New: Unexpected result in g++ when casting int to char from an stl vector to an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354 Bug ID: 59354 Summary: Unexpected result in g++ when casting int to char from an stl vector to an array Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jori.liesenborgs at gmail dot com Created attachment 31339 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31339&action=edit test code In the test code, the integer values from sixteen 4x4 blocks (in an stl vector) are copied into an unsigned char array for 64x4 values. Using just -O3 this appears to produce an incorrect result. Some remarks: - Adding -mno-sse again yields the right output. - If the vector is replaced by a simple array, the correct result is generated. - For 'xBlocks' less than 16, the correct result is also generated To generate and run the executable: g++ -O3 -o test test.ii ./test Generated output (all four lines should actually be the same): GCC version info: COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/4.8.2/lto-wrapper Target: x86_64-slackware-linux Configured with: ../gcc-4.8.2/configure --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-languages=ada,c,c++,fortran,go,java,lto,objc --enable-threads=posix --enable-checking=release --enable-objc-gc --with-system-zlib --with-python-dir=/lib64/python2.7/site-packages --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose --enable-java-home --with-java-home=/usr/lib64/jvm/jre --with-jvm-root-dir=/usr/lib64/jvm --with-jvm-jar-dir=/usr/lib64/jvm/jvm-exports --with-arch-directory=amd64 --with-antlr-jar=/tmp/gcc/antlr-runtime-3.4.jar --enable-java-awt=gtk --disable-gtktest --disable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux Thread model: posix gcc version 4.8.2 (GCC) Test system was an 8 core slackware 14.0 system, with a /proc/cpuinfo content like this: processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 58 model name: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz stepping: 9 microcode: 0x17 cpu MHz: 2550.000 cache size: 8192 KB physical id: 0 siblings: 8 core id: 0 cpu cores: 4 apicid: 0 initial apicid: 0 fpu: yes fpu_exception: yes cpuid level: 13 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips: 6784.34 clflush size: 64 cache_alignment: 64 address sizes: 36 bits physical, 48 bits virtual power management:
[Bug tree-optimization/59355] New: [4.9 Regression] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fno-devirtualize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59355 Bug ID: 59355 Summary: [4.9 Regression] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fno-devirtualize Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 31340 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31340&action=edit reduced testcase Compiler output: $ gcc -O2 -fno-devirtualize testcase.C testcase.C:10:1: internal compiler error: Segmentation fault } ^ 0xc985ef crash_signal /mnt/svn/gcc-trunk/gcc/toplev.c:336 0xaad8d1 hash_table::find_slot_with_hash(tree_node const*, unsigned int, insert_option) /mnt/svn/gcc-trunk/gcc/hash-table.h:774 0x4c get_odr_type(tree_node*, bool) /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:413 0xaac2e5 possible_polymorphic_call_targets(tree_node*, long, ipa_polymorphic_call_context, bool*, void**) /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:1191 0xaacf8e possible_polymorphic_call_targets /mnt/svn/gcc-trunk/gcc/ipa-utils.h:114 0xaacf8e ipa_devirt /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:1455 0xaacf8e execute /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:1637 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-205547-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-205547-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.9.0 20131130 (experimental) (GCC) Tested revisions: r205547 - crash 4.8 r204890 - OK
[Bug driver/59321] -fuse-ld has no effect on -print-prog-name nor on --with-ld=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321 --- Comment #16 from H.J. Lu --- Created attachment 31341 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31341&action=edit A patch with ChangeLog Add ChangeLog.
[Bug c++/58950] [4.9 Regression] Missing "statement has no effect"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950 --- Comment #7 from Marc Glisse --- Created attachment 31342 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31342&action=edit patch The __builtin_shuffle part of the patch seems fine. For (i+i), I first tried not setting TREE_NOWARNING on things that are not MODIFY_EXPR (as in the C front-end), but apparently that's how the warning for logical ops is disabled for a || (b && c), so that's not ok. The current patch breaks g++.dg/ext/vla13.C (PR 54583), but nothing else covered by the testsuite, so it is tempting to see if there are other ways to fix PR 54583.
[Bug c++/58950] [4.9 Regression] Missing "statement has no effect"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950 --- Comment #8 from Marc Glisse --- (In reply to Eric Botcazou from comment #5) > > For __builtin_shuffle, the issue is that we now call save_expr, which always > > sets TREE_SIDE_EFFECTS to 1. I don't know if it would make sense to > > introduce a maybe_save_expr that is equivalent to save_expr but does not set > > TREE_SIDE_EFFECTS if its argument doesn't have it. > > No, this would defeat the purpose of the SAVE_EXPR, since you could > duplicate the expression or move it at will, leading to nasty order of > evaluation issues. What I meant was, there are many places in the front-end that do: if (TREE_SIDE_EFFECTS (op0)) op0 = save_expr (op0); and I'd like to replace it with op0 = maybe_save_expr (op0); that would do the same thing to begin with. Now, if op0 is a long expression without side-effects, the code I quoted will not call save_expr, it will duplicate the expression and count on CSE for dedup, whereas we could imagine having a single version to start with, that optimizations would still be allowed to duplicate as usual if they consider it worth it. Of course the uses of SAVE_EXPR that require the stronger protection would be left alone. I may still not be making sense, but at least I think I was a little more precise about what I meant ;-)
[Bug c++/58950] [4.9 Regression] Missing "statement has no effect"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950 --- Comment #9 from Eric Botcazou --- > What I meant was, there are many places in the front-end that do: > > if (TREE_SIDE_EFFECTS (op0)) op0 = save_expr (op0); > > and I'd like to replace it with > > op0 = maybe_save_expr (op0); > > that would do the same thing to begin with. Now, if op0 is a long expression > without side-effects, the code I quoted will not call save_expr, it will > duplicate the expression and count on CSE for dedup, whereas we could > imagine having a single version to start with, that optimizations would > still be allowed to duplicate as usual if they consider it worth it. Yes, we do something like that in the Ada front-end, i.e. we call save_expr for complex expressions without side-effects, see e.g. utils2.c:gnat_protect_expr. But once the SAVE_EXPR is built, you *cannot* remove TREE_SIDE_EFFECTS on it, or else you'll run into nasty order of evaluation issues.
[Bug fortran/58410] [4.8/4.9 Regression] Bogus uninitialized variable warning for allocatable derived type array function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410 Paul Thomas changed: What|Removed |Added Priority|P2 |P3 CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- This is not a serious regression and so I have set it to P3. That said, it is a real bug and I am just now regtesting the fix. Assigning myself. Paul
[Bug ada/59356] New: ACATS tests C52102A and C52102C fail on i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59356 Bug ID: 59356 Summary: ACATS tests C52102A and C52102C fail on i686-pc-linux-gnu Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de ,.,. C52102A ACATS 2.5 13-11-30 19:14:40^M C52102A CHECK THAT THE ASSIGNMENT OF OVERLAPPING SOURCE AND TARGET ^M VARIABLES (INCLUDING ARRAYS AND SLICES IN VARIOUS^M COMBINATIONS) SATISFIES THE SEMANTICS OF "COPY"^M ASSIGNMENT (PART 1: STATIC BOUNDS).^M * C52102A WRONG VALUES - I3.^M * C52102A WRONG VALUES - B3.^M C52102A FAILED .^M FAIL: c52102a ,.,. C52102C ACATS 2.5 13-11-30 19:14:54^M C52102C CHECK THAT THE ASSIGNMENT OF OVERLAPPING SOURCE AND TARGET ^M VARIABLES (INCLUDING ARRAYS AND SLICES IN VARIOUS^M COMBINATIONS) SATISFIES THE SEMANTICS OF "COPY"^M ASSIGNMENT WHEN INITIAL ASSIGNMENT VALUES ARE DYNAMIC ^M (PART 1: STATIC BOUNDS).^M * C52102C WRONG VALUES - I3.^M * C52102C WRONG VALUES - B3.^M C52102C FAILED .^M FAIL: c52102c Boot-strapped with current trunk rev. 205509 Apparently all test cases pass on X86_64.
[Bug regression/59320] ftree-vrp breaks simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320 --- Comment #15 from Manuel López-Ibáñez --- (In reply to Joost VandeVondele from comment #14) > (In reply to Manuel López-Ibáñez from comment #13) > > Will -fsanitize=undefined catch these? If so, perhaps the message shown > > before reporting a bug should mention trying this first. > > I guess -fsanitize=address would catch the out-of-bounds access, but I don't > think the message should become too complex (it is already a bit narrow and > C-centric, for example '-fno-strict-aliasing' means nothing for Fortran > programs), and furthermore that option would only be available for a recent > gcc. It would be fine to have per-language recommendations, that is, For C/C++ do, try this. For Fortran, try that. For Ada, try ... It is a waste of effort by everybody when bugs are reported for broken code. It is not like gcc has too few PRs. There are 3268 unconfirmed ones.
[Bug ada/59356] [4.9 regression] ACATS C52102A and C52102C failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59356 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-11/msg03832.htm ||l Last reconfirmed||2013-11-30 CC||ebotcazou at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|ACATS tests C52102A and |[4.9 regression] ACATS |C52102C fail on |C52102A and C52102C |i686-pc-linux-gnu |failures Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Yes, I posted the fix a hours ago.
[Bug c/37743] Bogus printf format warning with __builtin_bswap32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743 Hans-Peter Nilsson changed: What|Removed |Added Last reconfirmed|2009-03-31 20:40:20 |2013-12-1 CC||hp at gcc dot gnu.org --- Comment #9 from Hans-Peter Nilsson --- Not much traffic in this PR. Anyway, I was about to enter a dup but instead I'll reconfirm the issue: still happens with r205550 for cris-elf and also 4.7 and 4.8 branches if there was any doubt.
[Bug preprocessor/59357] New: no documentation of #pragma once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59357 Bug ID: 59357 Summary: no documentation of #pragma once Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: shawn at churchofgit dot com Bug #11569 shows that #pragma once was de-deprecated, and very old cpp docs say it is deprecated, but current docs don't even mention that it exists. e.g. http://gcc.gnu.org/onlinedocs/cpp/Once_002dOnly-Headers.html and http://gcc.gnu.org/onlinedocs/cpp/Pragmas.html
[Bug preprocessor/59357] no documentation of #pragma once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59357 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- It is documented in the next page: http://gcc.gnu.org/onlinedocs/cpp/Alternatives-to-Wrapper-_0023ifndef.html#Alternatives-to-Wrapper-_0023ifndef Another way to prevent a header file from being included more than once is with the ‘#pragma once’ directive. If ‘#pragma once’ is seen when scanning a header file, that file will never be read again, no matter what. ‘#pragma once’ does not have the problems that ‘#import’ does, but it is not recognized by all preprocessors, so you cannot rely on it in a portable program.
[Bug c/59358] New: Infinite loop generated with >=O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59358
Bug ID: 59358
Summary: Infinite loop generated with >=O2
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cJ-gcc at zougloub dot eu
So, we have the following code:
void *lst_realloc(void *, int);
typedef struct smartlist_t {
void **list;
int num_used;
int capacity;
} smartlist_t;
#define MAX_CAPACITY 32
void smartlist_ensure_capacity(smartlist_t *sl, int size) {
if (size > sl->capacity) {
int higher = sl->capacity;
if (size > (int)MAX_CAPACITY/2) {
higher = MAX_CAPACITY;
}
else {
while (size > higher) {
higher *= 2;
}
}
sl->capacity = higher;
sl->list = lst_realloc(sl->list, sl->capacity);
}
}
Compiling that:
$ x86_64-pc-linux-gnu-gcc-4.8.2 -Os -S -o test.s test.c
Gives:
pushq%rbx
cmpl12(%rdi), %esi
movq%rdi, %rbx
jle.L1
cmpl$16, %esi
jg.L3
.L4:
jmp.L4 <- unexpected infinite loop if size <= capacity/2
.L3:
movl$32, 12(%rdi)
movq(%rdi), %rdi
movl$32, %esi
calllst_realloc
movq%rax, (%rbx)
.L1:
popq%rbx
ret
Originally from the smartlist_ensure_capacity() function from TOR:
https://gitweb.torproject.org/tor.git/blob/e65b54ec75e3c9e9ada33c8f3ee868d1bea167f5:/src/common/container.c#l61
TOR bug: https://trac.torproject.org/projects/tor/ticket/10259
Reduced by o11c (https://gist.github.com/o11c/7729355) and got help from
pinskia.
