[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 --- Comment #3 from Yvan Roux --- Validation ends without any regression on ARM targets (armv5, a9, a9hf, a15).
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #11 from Paulo J. Matos --- (In reply to Brooks Moses from comment #10) > Other than the documentation issues, this seems like a non-bug. A non-bug? If you write a memcpy function by hand and call it memcpy, gcc replaces the function body by a call to memcpy which generates an infinite loop. How come it's a non-bug?
[Bug c++/57917] New: -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917
Bug ID: 57917
Summary: -Wuninitialized
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nishant.031 at gmail dot com
Hi,
Please see code snippet below.
g++ -v gave me following output:
g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/gcc-4.2.4/configure --prefix=/usr/local/soft/gcc/4.2.4
--disable-nls --enable-languages=c,c++
Thread model: posix
gcc version 4.2.4
In the code below, class variable isABC is not initialized. We came across a
crash in one particular RHEL machine which got fixed once I initialized this
variable in the class constructor. In another machine, the software started
giving absurd results until I initialized this variable in constructor.
I thought of finding an option in gcc which can report uninitialized variables
in class. I finally came across -Wuninitialized. I compiled this code using:
g++ test.cpp -Wuninitialized -O3
I was not reported any warning in this case. Is this the correct usage? If not,
is there any switch that can report such warning?
=
class A
{
private:
bool isABC;
public:
void setABC(bool);
};
void A::setABC(bool flag)
{
isABC = flag;
}
int main()
{
A a;
return -1;
}
===
But, the following case reports the following warning:
test.cpp: In function 'int main()':
test.cpp:31: warning: 'a.A::a' is used uninitialized in this function
test.cpp:38: note: 'a.A::a' was declared here
--
class A {
bool ggg;
int a;
public:
void mA() {
printf("haha");
++a;
int g = 2/a;
printf("%i\n",g);
}
};
int main() {
A a;
a.mA();
return -1;
}
Thanks.
Please help.
[Bug c++/57917] -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917 Nishant Sharma changed: What|Removed |Added Severity|normal |critical
[Bug fortran/57894] min/max required actual argument missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57894 --- Comment #2 from Tobias Burnus --- Patch: http://gcc.gnu.org/ml/fortran/2013-07/msg00038.html
[Bug libfortran/35862] [F2003] Implement new rounding modes for run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862 --- Comment #25 from Tobias Burnus --- Rounding on input. Patch, which sets the CPU rounding mode and relies on strtof to honour it: http://gcc.gnu.org/ml/fortran/2013-07/msg00042.html
[Bug libstdc++/57916] Improve std::sort paritioning by explicitly employing the pivot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916 --- Comment #1 from Jonathan Wakely --- Thanks for the patch, do you have a GCC opyright assignment in place? Please see http://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html#list.copyright for details on contributing.
[Bug c++/19808] miss a warning about uninitialized members in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 Jonathan Wakely changed: What|Removed |Added CC||nishant.031 at gmail dot com --- Comment #20 from Jonathan Wakely --- *** Bug 57917 has been marked as a duplicate of this bug. ***
[Bug c++/57917] -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Severity|critical|normal --- Comment #1 from Jonathan Wakely --- GCC 4.2 is ancient and no longer supported. This is not "critical", it's your code that has a bug, not the compiler. You don't use A::isABC in the program, so it's a poor testcase. There are lots of existing PRs about this, e.g. PR 2972 and PR 42000 and PR 19808 *** This bug has been marked as a duplicate of bug 19808 ***
[Bug libfortran/35862] [F2003] Implement new rounding modes for run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862 --- Comment #26 from Uroš Bizjak --- (In reply to Tobias Burnus from comment #24) > [Somehow printf doesn't like my long double/__float128 example and prints > 0.0 (long double) or garbage numbers (__float128).] You should use %25.22Lf instead of %25.22lf.
[Bug c++/57917] -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917 --- Comment #2 from Nishant Sharma --- (In reply to Jonathan Wakely from comment #1) > GCC 4.2 is ancient and no longer supported. > > This is not "critical", it's your code that has a bug, not the compiler. > > You don't use A::isABC in the program, so it's a poor testcase. > > There are lots of existing PRs about this, e.g. PR 2972 and PR 42000 and PR > 19808 > > *** This bug has been marked as a duplicate of bug 19808 *** Even if from main, if I execute: a.setABC(false); Then also it does NOT report a warning. This should have worked isn't it? My main intent is to ask how to catch such warnings?
[Bug c++/57917] -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917 Nishant Sharma changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #3 from Nishant Sharma --- Even if from main, if I execute: a.setABC(false); Then also it does NOT report a warning. This should have worked isn't it? What should be done so that compiler treats this as a warning OR do you think this is not a valid case for being reported & if not, then why would compiler not report anything?
[Bug c++/57917] -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Manuel López-Ibáñez --- Nishant, this is not a good testcase because A::isABC is not used. Even if you call a.setABC(false), isABC is only assigned but its uninitialized value is not used. In fact, in your testcase, since 'a' is never used before the program finishes, GCC may just delete it and return -1. Nonetheless, there are many testcases for which GCC fails to provide a warning, check those PRs (bug reports) and make sure that your real testcase is not covered by any of them before opening a new PR. You can find a list of -Wuninitialized PRs here: http://gcc.gnu.org/PR24639 You could add yourself to the CC list of those PRs if you are interested in tracking progress, but more testcases are not really needed. What is needed is people willing to work on fixes.
[Bug c++/57917] -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57917 --- Comment #5 from Jonathan Wakely --- Your code is equivalent to: int i; // uninitialized i = 1; // now it's initialized This should not give a warning.
[Bug other/57918] New: Options -funroll-loops, -funroll-all-loops are described twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57918 Bug ID: 57918 Summary: Options -funroll-loops, -funroll-all-loops are described twice Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Options -funroll-loops, -funroll-all-loops are described twice in gcc info and man, and the descriptions are different. The second description of these options is in the final part of section "Options That Control Optimization", which starts with the following words: "The following options control optimizations that may improve performance, but are not enabled by any ‘-O’ options. This section includes experimental options that may produce broken code."
[Bug c++/56665] -O2 with -fno-strict-aliasing makes boost::spirit::classic::assign_a not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56665 Andre Schmitt changed: What|Removed |Added CC||excitari at gmail dot com --- Comment #3 from Andre Schmitt --- I can confirm this with gcc 4.7.3 -O2 Assign_a is not working within boost spirit classic on ubuntu 13.04.
[Bug fortran/57895] Segmentation fault in gfc_restore_last_undo_checkpoint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57895 --- Comment #3 from Tobias Burnus --- Author: burnus Date: Wed Jul 17 12:57:41 2013 New Revision: 201008 URL: http://gcc.gnu.org/viewcvs?rev=201008&root=gcc&view=rev Log: 2013-07-17 Mikael Morin Tobias Burnus PR fortran/57895 * match.c (gfc_match_name): Ensure that the error message regarding -fdollar-ok gets printed. (gfc_match_common): Avoid multiple freeing. 2013-07-17 Tobias Burnus PR fortran/57895 * gfortran.dg/dollar_sym_3.f: New. * gfortran.dg/dollar_sym_1.f90: Update dg-error. Added: trunk/gcc/testsuite/gfortran.dg/dollar_sym_3.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dollar_sym_1.f90
[Bug fortran/57895] Segmentation fault in gfc_restore_last_undo_checkpoint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57895 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tobias Burnus --- FIXED on the trunk (GCC 4.9). Thanks for the report!
[Bug c++/57919] New: [C++11] Alias templates cause partial specialization to erroneously fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57919 Bug ID: 57919 Summary: [C++11] Alias templates cause partial specialization to erroneously fail Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: cheesear at gmail dot com Created attachment 30516 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30516&action=edit MWE that causes the aforementioned error. The use of alias templates can cause the compiler to think that a valid template class instantiation is ambiguous. The file attached contains an example that, when compiled with g++ (version 4.8.1_1 from Macports), results in the following error: $ g++ -std=c++11 er.cpp er.cpp: In function 'int main()': er.cpp:39:41: error: ambiguous class template instantiation for 'struct foo<1, 1, sequence<> >' using t = typename foo<1, 1, extents<>>::type; ^ er.cpp:26:8: error: candidates are: struct foo...> > struct foo> ^ er.cpp:32:8: error: struct foo...> > struct foo> ^ er.cpp:39:43: error: 'type' in 'struct foo<1, 1, sequence<> >' does not name a type using t = typename foo<1, 1, extents<>>::type; ^
[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 Yvan Roux changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Yvan Roux --- Fix committed at rev. 201005
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #32 from Martin Liška --- Sorry for late answer, proposed patch works for me. Thanks, Martin (In reply to Ian Lance Taylor from comment #10) > Created attachment 30323 [details] > Possible patch > > Can you see if this patch fixes the problem?
[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 --- Comment #6 from Yvan Roux --- Nice feature, I'll try to remember it ;) Thanks
[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 --- Comment #5 from Georg-Johann Lay --- You can write r201005 and bugzilla will link it for you :-)
[Bug libstdc++/57920] New: [c++11] Linux: std::random_device reads too much from /dev/urandom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57920
Bug ID: 57920
Summary: [c++11] Linux: std::random_device reads too much from
/dev/urandom
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
As the test below shows, a single invocation of
std::random_device::operator() reads 4k from /dev/urandom, which is
rather wasteful of the entropy collected in the random device pool.
Of course, in theory, reading 4k and using just 4 bytes of it will
only decrease the entropy by 4 bytes, not 4k, but the kernel can't
know that. When you read 4k from /dev/urandom, it has to assume it
will be used, so it will reduce the entropy by 4k (which is
typically all it has). This means that a subsequent read from
/dev/random (by the same or another process) will block, often
unnecessarily because actually enough entropy was available. This is
particularly annoying since std::random_device is often just used to
seed a PRNG which needs just a few random bytes.
So while buffered reading is almost always a good thing, I contend
it's not in this case. I'd suggest to read unbuffered by default,
which may entail using read() instead of fread().
% cat test.cpp
#include
int main ()
{
std::random_device rd;
rd ();
}
% g++-4.7 -std=c++11 test.cpp
% strace ./a.out
[...]
open("/dev/urandom", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfffec50) = -1 EINVAL (Invalid
argument)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fdf000
read(3, [...], 4096) = 4096
close(3)= 0
[Bug tree-optimization/57523] ICE in merge_assigned_reloads, at reload1.c:6062
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57523 schaiba at gmail dot com changed: What|Removed |Added CC||schaiba at gmail dot com --- Comment #1 from schaiba at gmail dot com --- I can confirm this with OpenSXCE 2013.05 and gcc 3.4.3 (Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs Configured with: /cosmicrescue/code__OpenSXCE/03__SFW/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-20050802) ). Indeed, eliminating -O2 works.
[Bug middle-end/57805] Wasted work in write_roots()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57805 --- Comment #2 from Po-Chun Chang --- Patch sent to gcc-patches@: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00661.html
[Bug rtl-optimization/57810] Wasted work in validate_const_int()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57810 --- Comment #2 from Po-Chun Chang --- Patch sent to gcc-patches@: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00662.html
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #12 from Brooks Moses --- (In reply to Paulo J. Matos from comment #11) > A non-bug? If you write a memcpy function by hand and call it memcpy, gcc > replaces the function body by a call to memcpy which generates an infinite > loop. How come it's a non-bug? Because if you do that you're invoking undefined behavior. There's already a memcpy function in the standard library, so naming your own function memcpy violates the one-definition-per-function rule. Even if it "worked", naming your own function memcpy would likely break other standard library functions that call the "real" memcpy. Now, if this replacement still happens when you compile with -nostdlib, that would be a bug since it becomes legal code in that case. But that's somewhat of a separate issue and should be filed separately if it happens. (We should arguably also have a test for it, if we don't already.)
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #13 from Max Reitz --- (In reply to Brooks Moses from comment #12) > Now, if this replacement still happens when you compile with -nostdlib, that > would be a bug since it becomes legal code in that case. But that's > somewhat of a separate issue and should be filed separately if it happens. > (We should arguably also have a test for it, if we don't already.) Actually, that's why I filed this report in the first place. The test case you request is in fact given in my OP.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #14 from Andreas Schwab --- The relevant option is -ffreestanding, not -nostdlib.
[Bug testsuite/57591] gcc-4.8 libbacktrace btest failure on Linux ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57591 --- Comment #3 from acrux --- same failure with gcc-4.8-20130711
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #15 from Max Reitz --- (In reply to Andreas Schwab from comment #14) > The relevant option is -ffreestanding, not -nostdlib. If you're referring to me, I'll be glad to cite my OP for you :D > Compiling the attached trivial memcpy implementation with -O3 -ffreestanding > -fno-builtin -nodefaultlibs -nostdlib yields a memcpy which calls itself.
[Bug rtl-optimization/57921] Alias change causes perl from SPEC 2006 to abort on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921 --- Comment #1 from Steve Ellcey --- Created attachment 30518 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30518&action=edit What the CSE phase generated after checkin r200133
[Bug rtl-optimization/57921] New: Alias change causes perl from SPEC 2006 to abort on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921 Bug ID: 57921 Summary: Alias change causes perl from SPEC 2006 to abort on MIPS Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Created attachment 30517 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30517&action=edit What the CSE phase generated prior to checkin r200133 With the latest GCC (as of version r200133) the perl benchmark in SPEC 2006 is failing for me on the mips-linux-gnu target. The patch that caused it to start failing is to the alias analysis phase of GCC and it affects the rtl CSE phase of GCC. Before this change CSE was generating this RTL: r234 = address of PL_curpad r211 = mem[r234] . . r215 = $2 (return pointer from a function) r237 = mem[r211] mem[r237+4] = r215 r220 = mem[r237] The important bit is the last statement where r220 is loaded using the address in r237. After the change we have: r234 = address of PL_curpad r211 = mem[r234] . . r215 = $2 (return pointer from a function) r237 = mem[r211] mem[r237+4] = r215 r238 = mem[r211] r220 = mem[238] Instead of reusing r237, we load r238 and use that to load r220. I believe that PL_curpad (address in r234) is set up to have the value of its own address minus 4. That would mean that when we store to 'mem[r237+4]' we changed what r238 has vs. what r237 has. Now this actually seems like it is more correct then the first version, but the first version worked (I could compile and run perl) and the second version does not (perl allocate aborts and goes into an infinite loop). I can see this change in x86 RTL but the change in code on x86 does not seem to cause an outward change in the behaviour of perl. I don't know if GCC is doing something wrong or if the code in perl is wrong. I have attached a cutdown test case from Perl_pp_entersub (pp_hot.c) with this bug report. The code cannot be run but if compiled it shows the RTL differences I describe above.
[Bug rtl-optimization/57921] Alias change causes perl from SPEC 2006 to abort on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921 --- Comment #2 from Steve Ellcey --- Created attachment 30519 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30519&action=edit Test case cut down from perl benchmark in SPEC 2006
[Bug rtl-optimization/57921] Alias change causes perl from SPEC 2006 to abort on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921 Andrew Pinski changed: What|Removed |Added Keywords||alias --- Comment #3 from Andrew Pinski --- This does look like an alias bug in the source code of perl?
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #16 from Andreas Schwab --- That's exactly what I wrote.
[Bug rtl-optimization/57921] Alias change causes perl from SPEC 2006 to abort on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921 --- Comment #4 from Steve Ellcey --- Digging around on the SPEC web page led me to this: http://www.spec.org/cpu2006/Docs/400.perlbench.html Known portability issues There are some known aliasing issues. The internal data structures that represent Perl's variables are accessed in such as a way as to violate ANSI aliasing rules. Compilation with optimizations that rely on strict compliance to ANSI C aliasing rules will most likely produce binaries that will not validate.
[Bug fortran/57922] New: Memory leak with allocatable polymorphics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57922 Bug ID: 57922 Summary: Memory leak with allocatable polymorphics Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Created attachment 30520 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30520&action=edit Example program I'm experiencing a problem with: Using built-in specs. COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper Target: x86_64-apple-darwin11.4.2 Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.9.0 20130404 (experimental) (GCC) The attached example program demonstrates the problem. When f is deallocated, it seems that f%x is not getting deallocated, causing the memory footprint of the program (as reported by the ps syscall) to grow without bound.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #17 from Max Reitz --- (In reply to Andreas Schwab from comment #16) > That's exactly what I wrote. Ah, okay, sorry I misunderstood.
[Bug fortran/57373] ICE on invalid: insert_bbt(): Duplicate key found!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57373 Bud Davis changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #2 from Bud Davis --- 0 0x45f20f60 in exit () from /lib/libc.so.6 #1 0x08161d73 in gfc_internal_error ( format=0x8b5da50 "insert_bbt(): Duplicate key found!") at ../../gcc/gcc/fortran/error.c:1101 #2 0x0813c644 in insert (new_bbt=new_bbt@entry=0x8f844d0, t=0x8f843f0, compare=compare@entry=0x81d5400 ) at ../../gcc/gcc/fortran/bbt.c:119 #3 0x0813c69c in gfc_insert_bbt (root=0x8fc3410, new_node=0x8f844d0, compare=0x81d5400 ) at ../../gcc/gcc/fortran/bbt.c:137 #4 0x081d80b1 in gfc_new_symtree (root=0x8fc3410, name=0xbfffe980 "a") at ../../gcc/gcc/fortran/symbol.c:2384 #5 0x081500bc in get_proc_name (name=name@entry=0xbfffe980 "a", result=result@entry=0xbfffe978, module_fcn_entry=module_fcn_entry@entry=false) at ../../gcc/gcc/fortran/decl.c:943 #6 0x081573db in gfc_match_function_decl () at ../../gcc/gcc/fortran/decl.c:5249 #7 0x081a4a81 in decode_statement () at ../../gcc/gcc/fortran/parse.c:312 #8 0x081a600c in next_free () at ../../gcc/gcc/fortran/parse.c:784 #9 next_statement () at ../../gcc/gcc/fortran/parse.c:977 #10 0x081a6a32 in parse_interface () at ../../gcc/gcc/fortran/parse.c:2384 Is the backtrace in case anyone is interested.
[Bug libstdc++/57916] Improve std::sort paritioning by explicitly employing the pivot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916 --- Comment #2 from Alexey Tourbin --- > Thanks for the patch, do you have a GCC opyright assignment in place? I don't have a copyright assignmet, but I'm willing to undergo the procedure (and perhaps to sign an assignment for all future changes). So how do I proceed?
