[Bug libstdc++/39340] unnecessarily strict std::norm implementation

2009-03-03 Thread highegg at gmail dot com
--- Comment #1 from highegg at gmail dot com 2009-03-03 11:49 --- I kindly request to remove this bug report. I've just learned that there are indeed numerical issues that I just failed to see. I'll try to supply a patch eventually. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id

[Bug c++/39340] New: unnecessarily strict std::norm implementation

2009-03-02 Thread highegg at gmail dot com
Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: highegg at gmail dot com GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org

[Bug c++/39270] New: Explicit instantiation rejected

2009-02-22 Thread highegg at gmail dot com
Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: highegg at gmail dot com GCC target triplet: Target: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39270

[Bug fortran/32512] New: efficiency of RESHAPE and SPREAD

2007-06-26 Thread highegg at gmail dot com
Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: highegg at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32512

[Bug fortran/32512] efficiency of RESHAPE and SPREAD

2007-06-26 Thread highegg at gmail dot com
--- Comment #1 from highegg at gmail dot com 2007-06-26 06:36 --- Created an attachment (id=13790) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13790action=view) speedtester of TRANSPOSE, RESHAPE and SPREAD this testcase tests speed of constructing an array via TRANSPOSE, RESHAPE

[Bug fortran/32512] efficiency of RESHAPE and SPREAD

2007-06-26 Thread highegg at gmail dot com
--- Comment #2 from highegg at gmail dot com 2007-06-26 10:56 --- Just an informal note: Apparently (using the testcase), EkoPath 3.0 has a fast RESHAPE but not fast SPREAD, while Intel 9.1 and current g95 have neither. -- highegg at gmail dot com changed: What

[Bug fortran/32217] New: gfortran segfaults on UNPACK with zero-sized arrays

2007-06-05 Thread highegg at gmail dot com
Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: highegg at gmail dot com GCC host triplet: i386-pc-linux-gnu http://gcc.gnu.org

[Bug libfortran/31760] New: missing elemental applicability

2007-04-29 Thread highegg at gmail dot com
AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: highegg at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31760

[Bug libfortran/31760] missing elemental applicability

2007-04-29 Thread highegg at gmail dot com
--- Comment #2 from highegg at gmail dot com 2007-04-29 18:03 --- (In reply to comment #1) Why is this a bug in your opinion? ERF and the Bessel functions are MIL/GNU extensions. I don't think there's a standard that requires these functions to be elemental. Do you think

[Bug libfortran/31760] missing elemental applicability

2007-04-29 Thread highegg at gmail dot com
-- highegg at gmail dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31760