http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58793
--- Comment #7 from Tobias Burnus ---
(In reply to Paul Thomas from comment #5)
> Created attachment 31054 [details] - Fix for the PR
which was committed as follows. Comment 6 is about one side issue found during
review; pending is a patch for a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58793
--- Comment #6 from Tobias Burnus ---
Author: burnus
Date: Wed Oct 23 05:44:02 2013
New Revision: 203945
URL: http://gcc.gnu.org/viewcvs?rev=203945&root=gcc&view=rev
Log:
2013-10-23 Tobias Burnus
PR fortran/58793
* interface.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #13 from Michi Henning ---
Just had a collegue of mine reproduce the problem with the attached archive on
a machine that was installed from the Saucy .iso image, so I think this bug is
real. It's not just something on my machines.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #12 from Michi Henning ---
Output from gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
Michi Henning changed:
What|Removed |Added
Attachment #31066|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #10 from Michi Henning ---
Created attachment 31078
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31078&action=edit
main.ii illustrating the segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
Michi Henning changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
Michi Henning changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58850
Bug ID: 58850
Summary: Conversion error in chrono
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Ass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58700
--- Comment #3 from Paolo Carlini ---
Pending patch here: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00880.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58607
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58647
--- Comment #2 from Paolo Carlini ---
Pending patch here: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01659.html
(alternately the check could be inside cxx_eval_component_reference itself)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58810
--- Comment #2 from Paolo Carlini ---
Pending patches (two options) here:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01737.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58724
--- Comment #6 from Paolo Carlini ---
Pending patch here: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01166.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56552
--- Comment #6 from Steve Ellcey ---
Created attachment 31076
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31076&action=edit
Proposed patch I tested
Andrew, is this still on your TODO list? I have attached a patch that I have
tested here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58849
Andrew Pinski changed:
What|Removed |Added
Target||mingw32
Component|c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58849
Bug ID: 58849
Summary: complex number, memory is corrupted
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58842
--- Comment #1 from Dominique d'Humieres ---
The error "GNU Fortran is not working" is often related to problems with one
(or several) of the gmp, mpfr, or mpc libraries. You may have a look at the
following PRs: pr30960, pr34207, pr34242, pr36586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58831
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58806
--- Comment #5 from Marc Glisse ---
Created attachment 31074
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31074&action=edit
experimental patch
This optimizes the testcase in comment #0 if I mark g with the attribute
"no_global_write" and u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
--- Comment #15 from Paolo Carlini ---
A maintainer is also needed in order to *categorize* those potential issues and
plan the work: for example C++11 (+ C++14), which are the primary standards
which we are implementing, don't know about decimal,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58848
--- Comment #1 from mib.bugzilla at gmail dot com ---
Created attachment 31073
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31073&action=edit
simpler test case gets compilation error (good)
both test cases should get a compilation error bec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58848
Bug ID: 58848
Summary: constexpr function allows throw
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
As
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
--- Comment #14 from ulf ---
i am happy with the explicit operator in std::decimal for now. however sooner
or later there will be another one who puzzels over other issues (traits,
limits, and all the functions that dont know std::decimal).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58779
--- Comment #9 from Uroš Bizjak ---
Fixed on trunk sofar.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58779
Uroš Bizjak changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58779
--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct 22 18:35:53 2013
New Revision: 203935
URL: http://gcc.gnu.org/viewcvs?rev=203935&root=gcc&view=rev
Log:
PR target/58779
* config/i386/i386.c (put_condition_code) :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58838
David Edelsohn changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
--- Comment #13 from Paolo Carlini ---
Thus, let's make a decision: either this is a bug, importance as
submitted, about conversions to integer, as appeared to be, or it's a catch all
bug about all the issues with the TR decimal + all the work to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58838
--- Comment #3 from David Edelsohn ---
Created attachment 31071
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31071&action=edit
Disable mullw. dot form in 64 bit mode
Revised patch that also disables splitters.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58838
--- Comment #2 from David Edelsohn ---
Index: rs6000.md
===
--- rs6000.md (revision 203930)
+++ rs6000.md (working copy)
@@ -2699,7 +2699,7 @@
(match_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58838
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
--- Comment #12 from Janis Johnson ---
I obviously don't know C++ very well and the decimal float support in libstdc++
is very ugly. It would be nice if someone rewrites it in actual C++ someday;
the tests should help with that effort.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
--- Comment #11 from ulf ---
i see evil implicit conversion.
i modified lines 254, 337 and 421 to
explicit operator long long() const { return (long long)__val; }
like suggested in n3407.
#include
int main(){
std::decimal::decimal32 x(10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58813
--- Comment #8 from Vittorio Zecca ---
If I use the option -fmax-errors=1 the ICE disappears, but using this
option as a default
would potentially increase the time needed to get an error free code.
A code containing many errors would require as m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
--- Comment #9 from Janis Johnson ---
I haven't paid attention to decimal float since leaving IBM, so it was very
interesting to see the updated C++11 working paper. It makes sense to me to
use C++11 functionality in the GNU C++ decimal float sup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58847
Bug ID: 58847
Summary: ARM: emit NEON alignment hints for 32/16-bit accesses
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58806
--- Comment #4 from Marc Glisse ---
(In reply to Marc Glisse from comment #3)
> I should look at where exactly the difference between memcpy and init plays a
> role.
It is in call_may_clobber_ref_p_1 that memcpy takes a shortcut: it only checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
--- Comment #18 from Jakub Jelinek ---
(In reply to Kai Tietz from comment #17)
> What optimization you expect here? I see by the new type-demotion pass some
> changes in optimized tree-output:
This one is for vectorization, try it with -O3 -mav
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
--- Comment #17 from Kai Tietz ---
What optimization you expect here? I see by the new type-demotion pass some
changes in optimized tree-output:
foo ()
{
int i;
short int _4;
char _5;
unsigned short _6;
unsigned short _8;
short int _
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58830
--- Comment #2 from Mikael Pettersson ---
Started with r193882.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
--- Comment #16 from Jakub Jelinek ---
Another testcase:
short a[1024], b[1024];
void
foo (void)
{
int i;
for (i = 0; i < 1024; i++)
{
short c = (char) a[i] + 5;
long long d = (long long) b[i] + 12;
a[i] = c + d;
}
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58846
Bug ID: 58846
Summary: [4.7/4.8/4.9 Regression] ICE redeclaring __dso_handle
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589
Szikra István changed:
What|Removed |Added
CC||steven.spark+dev at gmail dot
com
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58813
--- Comment #7 from Steve Kargl ---
On Tue, Oct 22, 2013 at 06:40:22AM +, zeccav at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58813
>
> --- Comment #6 from Vittorio Zecca ---
> I found that
> export MALLOC_PERTURB_=2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58833
--- Comment #2 from Stefan Teleman ---
Hi Eric,
Thank you very much for answering so quickly!
--Stefan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
Volker Reichelt changed:
What|Removed |Added
Keywords||ice-on-invalid-code,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
Bug ID: 58845
Summary: Operator || and && broken for vectors
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
Volker Reichelt changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
Bug ID: 58844
Summary: [4.8/4.9 Regression] ICE with invalid use of ##
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58830
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58839
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58843
Bug ID: 58843
Summary: [4.7/4.8/4.9 Regression] ICE with broken destructor
call
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58816
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58816
--- Comment #6 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Oct 22 11:46:59 2013
New Revision: 203919
URL: http://gcc.gnu.org/viewcvs?rev=203919&root=gcc&view=rev
Log:
2013-10-22 Paolo Carlini
PR c++/58816
* pt.c (apply_l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841
Paolo Carlini changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58806
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> You cannot find the PR because it's already implemented via the "fn spec"
> attribute (conveniently not user-accessible because bike-shedding about
> whether separa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58839
Paolo Carlini changed:
What|Removed |Added
CC||jwakely.gcc at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58842
Bug ID: 58842
Summary: libgfortran configuration error in 32-bit mode for GCC
4.8 with MacPorts "universal installation"
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841
Bug ID: 58841
Summary: std::bad_alloc not thrown with -fsanitize=address
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58840
Bug ID: 58840
Summary: Problem compiling gcc 4.7.3 using gcc 4.4.6
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58839
Bug ID: 58839
Summary: Regression: dereferencing void in
shared_ptr(unique_ptr&& u) constructor
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58791
Jakub Jelinek changed:
What|Removed |Added
Attachment #31043|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58772
--- Comment #9 from Paolo Carlini ---
Personally, I would not object to experimentation like that in PR55727, but it
should happen in a separate allocator, not new_allocator. Still, I'm under the
impression that N3396 is superseding a lot of libra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58772
--- Comment #8 from Marc Glisse ---
(In reply to Richard Biener from comment #3)
> Paolo, does libstdc++ provide a custom allocator for aligned memory?
PR 55727
> Is this issue going to be resolved with C++1y?
There is a NB comment requesting t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
--- Comment #8 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #6)
I also would like to encourage using explicit conversion functions. This is
explicitly suggested in the updated C++11 integration document:
http://www.open-std.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
--- Comment #7 from Paolo Carlini ---
Something like:
Index: include/decimal/decimal
===
--- include/decimal/decimal(revision 203915)
+++ include/decimal/decimal(working copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58815
--- Comment #6 from Paolo Carlini ---
Thanks Janis. In C++11 we have *explicit* conversion operators. Would they
help? A safe approach woould providing the operators only in c++11 mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58816
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #7 from Paolo Carlini ---
Ok, thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #6 from Michi Henning ---
My apologies, I'm a newbie in the gcc bug world. Will try to mend my ways!
Cheers,
Michi.
PS: I'll work on this more tomorrow, but I'm pretty sure that gcc is not to
blame. There is some stale header kickin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58834
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #1 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #5 from Paolo Carlini ---
Thanks. Note that, in general, tarballs, using make, etc, is not fine:
http://gcc.gnu.org/bugs/#report Please, just a single preprocessed .ii file.
I'm keeping the bug open for now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58817
--- Comment #3 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #1)
> Transforming VLAs that way isn't a good idea, at least if the size isn't
> really small, at least when the VLA isn't in a scope that dies at the
> function's end (or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #4 from Michi Henning ---
Hmmm... Trying this on a different machine, it works perfectly. It looks like
there is something screwed up with the gcc installation on the machine where
I'm seeing this.
So, please hold off putting any work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742
--- Comment #6 from Marc Glisse ---
Thanks. For reference, as noted by Jakub and confirmed by Richard, we will also
need at some point a gimple version for:
int *
fx (int *b, int *e)
{
ptrdiff_t p = e - b;
return b + p;
}
(or s/ptrdiff_t/lon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58833
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58838
Bug ID: 58838
Summary: mullw sets condition code incorrectly.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58779
--- Comment #6 from Uroš Bizjak ---
Created attachment 31067
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31067&action=edit
Proposed patch that removes MINUS overflow checks
Patch in testing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58779
--- Comment #5 from Uroš Bizjak ---
combine pass is converting:
(insn 21 20 22 4 (parallel [
(set (reg:SI 73)
(minus:SI (reg:SI 64 [ a.2 ])
(reg:SI 59 [ iftmp.3 ])))
(clobber (reg:CC 17
81 matches
Mail list logo
