http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59349
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364
--- Comment #4 from Conrad ---
Created attachment 31406
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31406&action=edit
reduced test case
Attached reduced_test_case.tar.gz
No need for pre-processed input, as it doesn't include any system h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364
--- Comment #3 from Conrad ---
Reduced test case. Compile with:
g++ a.cpp -c -o a.o -std=c++11
g++ b.cpp -c -o b.o -std=c++11
g++ a.o b.o -o prog -std=c++11
file foo.hpp:
class foo
{
public:
inline foo() {}
inline ~foo() {}
inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58928
chenjinzhi changed:
What|Removed |Added
CC||gnome3fans at gmail dot com
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58640
--- Comment #14 from Jeffrey A. Law ---
Oleg, please open a new bug for the SH problem rather than piggy-backing on
this one as they're clearly distinct issues.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364
--- Comment #2 from Conrad ---
I wouldn't call the method presented in the comments to bug #55800 as a
workaround.
Quote:
"at least adding .globl _ZTWN3xyz3blaE _ZTWN3xyz3blaE = __tls_init manually at
the end of the assembly seems to make the co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488
--- Comment #6 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Dec 10 06:31:41 2013
New Revision: 205848
URL: http://gcc.gnu.org/viewcvs?rev=205848&root=gcc&view=rev
Log:
PR tree-optimization/41488
* tree-ssa-loop-ivopts.c (add_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364
Tom De Caluwé changed:
What|Removed |Added
CC||decaluwe.t at gmail dot com
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59443
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59443
--- Comment #1 from Dennis Yurichev ---
dennis@ubuntu:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59443
Bug ID: 59443
Summary: Passing arguments via stack in x86-64
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55715
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55715
--- Comment #1 from Joseph S. Myers ---
Author: jsm28
Date: Tue Dec 10 01:23:37 2013
New Revision: 205846
URL: http://gcc.gnu.org/viewcvs?rev=205846&root=gcc&view=rev
Log:
PR preprocessor/55715
libcpp:
* expr.c (num_binary_op): Implement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59442
Bug ID: 59442
Summary: movapd tests fail if built with
-fstack-protector-strong/all
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439
--- Comment #4 from Ben Maurer ---
Also, here's where perf says time is being spent. While only 25% is shown as
being in the locale constructor/destructor, I suspect that the time spent in
other methods is actually related to the ping-ponging of c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439
--- Comment #3 from Ben Maurer ---
Created attachment 31405
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31405&action=edit
Benchmark
_build/opt/experimental/bmaurer/benchmark
snprintf
1 threads took 20 ms
2 threads took 20 ms
3 threads to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
--- Comment #8 from H.J. Lu ---
(In reply to Andrew Pinski from comment #3)
> (subreg:DI
> + (match_operand:V4SF 1 "register_operand"
> + "x,x") 0)
>
> That is not a valid subreg and should have be rejected.
This change:
http://
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439
--- Comment #2 from Andrew Pinski ---
Is there a simple performance testcase you could provide?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59426
--- Comment #3 from Paolo Carlini ---
Sorry, I spent too little time on my message. I meant to say that, *in
general*, our intrinsics (modulo bugs, of course) try to track the c++11
semantics of the corresponding C++11 type trait with the same nam
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59441
--- Comment #1 from Marek Polacek ---
Reminder: after fixing this one, make pr59437.C run with -flto again.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59441
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |4.9.0
ugs.html> for instructions.
Target: x86_64-unknown-linux-gnu
Configured with: --disable-bootstrap --enable-languages=c,c++,lto
--enable-checking=yes
gcc version 4.9.0 20131209 (experimental) (GCC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59428
Tobias Burnus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41724
--- Comment #5 from Tobias Burnus ---
Author: burnus
Date: Mon Dec 9 23:17:06 2013
New Revision: 205838
URL: http://gcc.gnu.org/viewcvs?rev=205838&root=gcc&view=rev
Log:
2013-12-10 Tobias Burnus
PR fortran/59428
PR fortran/58
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099
--- Comment #31 from Tobias Burnus ---
Author: burnus
Date: Mon Dec 9 23:17:06 2013
New Revision: 205838
URL: http://gcc.gnu.org/viewcvs?rev=205838&root=gcc&view=rev
Log:
2013-12-10 Tobias Burnus
PR fortran/59428
PR fortran/5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58676
--- Comment #5 from Tobias Burnus ---
Author: burnus
Date: Mon Dec 9 23:17:06 2013
New Revision: 205838
URL: http://gcc.gnu.org/viewcvs?rev=205838&root=gcc&view=rev
Log:
2013-12-10 Tobias Burnus
PR fortran/59428
PR fortran/58
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59428
--- Comment #5 from Tobias Burnus ---
Author: burnus
Date: Mon Dec 9 23:17:06 2013
New Revision: 205838
URL: http://gcc.gnu.org/viewcvs?rev=205838&root=gcc&view=rev
Log:
2013-12-10 Tobias Burnus
PR fortran/59428
PR fortran/58
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59427
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59440
Bug ID: 59440
Summary: [4.9 Regression] ICE in force_decl_die, at
dwarf2out.c:20111 with -g
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59427
--- Comment #2 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Mon Dec 9 23:02:18 2013
New Revision: 205837
URL: http://gcc.gnu.org/viewcvs?rev=205837&root=gcc&view=rev
Log:
2013-12-09 Paolo Carlini
PR libstdc++/59427
* include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59435
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59435
--- Comment #2 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Mon Dec 9 22:59:33 2013
New Revision: 205836
URL: http://gcc.gnu.org/viewcvs?rev=205836&root=gcc&view=rev
Log:
/cp
2013-12-09 Paolo Carlini
PR c++/59435
* parser.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55931
Ryan Mansfield changed:
What|Removed |Added
CC||rmansfield at qnx dot com
--- Comment #9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59437
--- Comment #2 from Marek Polacek ---
Slightly reduced:
template < typename T > struct A
{
T foo ();
};
template < typename T > struct C: virtual public A < T >
{
C & operator<< (C & (C &));
};
template < typename T >
C < T > &endl (C < int >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439
--- Comment #1 from Ben Maurer ---
Facebook is putting a $50 bounty on this bug via bountysource:
https://www.bountysource.com/issues/1350875
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59438
--- Comment #1 from Tobias Burnus ---
Regarding (a): I think we should consider to simply use the same structure of
arrays ("struct array_descr_info") also for scalars. Besides that it already
exists, it is probably also sensible when we will hand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439
Bug ID: 59439
Summary: std::locale uses atomic instructions on construction
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
--- Comment #3 from Stefan Helmert ---
OK, please try this code:
https://github.com/TheTesla/DigiKeyCSV2KiCadSCHpatcher/tree/gcctest
The relevant function is norm_value().
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59426
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59428
--- Comment #4 from Dominique d'Humieres ---
Beware of a TAB in
+real, intent(in) :: x
(comment 2).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35667
--- Comment #9 from dave.anglin at bell dot net ---
On 12/9/2013 5:01 AM, fxcoudert at gcc dot gnu.org wrote:
> Was that fixed with John's commit?
I think so. I believe this was left open because the patch wasn't
back ported.
I could confirm but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59438
Bug ID: 59438
Summary: DWARF: Fortran mishandles ALLOCATABLE/ASSOCIATED in
debug output
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #17 from David Kredba ---
Thank you!
Looks like they are not overweighting it at the Creduce web site, it is way
better then delta. Delta for me ended already 10 times with message that:
"Could not increase granularity; we are done."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59435
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627
Paolo Carlini changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #5 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
Uroš Bizjak changed:
What|Removed |Added
Depends on||58627
--- Comment #5 from Uroš Bizjak ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
--- Comment #3 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #2)
> (gdb) p init
> $1 = (tree) 0x100139a078
> (gdb) p type
> $2 = (tree_node *) 0x101
> (gdb)
FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for exces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[F03] Incorrect warning |[OOP] Incorrect warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59437
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59437
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59437
Bug ID: 59437
Summary: ICE in for g++ -S -fvtable-verify=std -fsanitize=null
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58880
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
--- Comment #2 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #0)
> Created attachment 31403 [details]
> Preprocessed source
>
> Attached testcase randomly fails to compile. Following valgrind error was
> obtained on x86_64-pc-linux-g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
--- Comment #1 from Uroš Bizjak ---
On a related note, without -std=gnu++0x:
$ /ssd/uros/gcc-build/gcc/cc1plus -g -O2 -fpreprocessed -quiet stdc++.ii
In file included from
/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/st
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
Bug ID: 59436
Summary: FAIL: 17_intro/headers/c++200x/stdc++.cc (test for
excess errors)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #16 from Markus Trippelsdorf ---
(In reply to Richard Biener from comment #15)
> Confirmed with 4.7.3 and 4.8.2. Seems to work on the trunk, worked with
> 4.6.4.
>
> Now it would be interesting to bisect what fixed this on the trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59434
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392
--- Comment #2 from roland at gnu dot org ---
Fix posted: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00753.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #27 from Dominique d'Humieres ---
> > Would it be possible to post the fix? TIA.
> Committed upstream as http://llvm.org/viewvc/llvm-project?rev=196779&view=rev
> Feel free to commit the exact same change to gcc
> or wait for the next
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432
--- Comment #1 from Ian Lance Taylor ---
FYI, the point of the test is to get that segmentation violation and ensure
that the signal handler generates a runtime panic as it should. The actual
problem is presumably happening some time later.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56572
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59424
--- Comment #3 from Jean-Marc Valin ---
What's strange is that adding -ffast-math makes gcc use maxss on func3() too,
even though it was already allowed to without -ffast-math. I had the same
problem with absolute value, although in that case fabs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59434
--- Comment #1 from cheparukhin at yandex dot ru ---
I've found out that this is not a bug in the implementation but an issue in the
standard itself:
http://cplusplus.github.io/LWG/lwg-active.html#2106
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59435
Bug ID: 59435
Summary: sizeof...(T) as default value for an argument does not
work
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417
--- Comment #2 from Jakub Jelinek ---
The problem is the uninitialized var t in the testcase, with it apparently
the range info weird and inconsistent, but what sanity can one expect from
uninitialized value, any use of it is invalid.
Before *.co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56572
--- Comment #2 from Aldy Hernandez ---
*** Bug 56573 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56573
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58916
--- Comment #7 from Vladimir Fuka ---
Sorry, didn't remember that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58917
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58916
--- Comment #6 from janus at gcc dot gnu.org ---
*** Bug 58917 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58916
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> Here is a variant without classes:
>
> real, allocatable :: a
> real b(1)
> allocate(a, source=b)
> end
I just noticed that this case has been filed as PR 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59434
Bug ID: 59434
Summary: move_iterator is broken for input iterators with an
rvalue as reference type
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: maj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59433
Bug ID: 59433
Summary: [4.9 regression] Many 64-bit Go tests SEGV on Solaris
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59433
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432
Bug ID: 59432
Summary: [4.9 regression] sync/atomic FAILs on Solaris/x86
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59431
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59431
Bug ID: 59431
Summary: [4.9 regression] runtime FAILs on Solaris
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59430
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59430
Bug ID: 59430
Summary: [4.9 regression] os/user FAILs on Solaris
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Ian Lance Taylor ---
> This problem should be fixed now. Sorry about that.
It does for the vast majority of the 32-bit tests. I'll file separate
bugs for the few
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #77 from Richard Biener ---
Author: rguenth
Date: Mon Dec 9 15:13:07 2013
New Revision: 205808
URL: http://gcc.gnu.org/viewcvs?rev=205808&root=gcc&view=rev
Log:
2013-12-09 Richard Biener
PR middle-end/38474
* tree-ssa-str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48641
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300
--- Comment #15 from Richard Earnshaw ---
Author: rearnsha
Date: Mon Dec 9 14:54:00 2013
New Revision: 205807
URL: http://gcc.gnu.org/viewcvs?rev=205807&root=gcc&view=rev
Log:
PR rtl-optimization/54300
gcc/
PR rtl-optimization/54300
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59424
--- Comment #2 from Richard Biener ---
(In reply to Marek Polacek from comment #1)
> I can observe the same behavior with trunk.
>
> For func2, we compute a < b ? a : b first and then call sqrtf on that, while
> for func3 we have return a < b ? A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59415
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59415
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Mon Dec 9 14:44:03 2013
New Revision: 205805
URL: http://gcc.gnu.org/viewcvs?rev=205805&root=gcc&view=rev
Log:
PR sanitizer/59415
* vtable-verify.c (verify_bb_vtables): Check t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695
--- Comment #4 from janus at gcc dot gnu.org ---
As noted by Dominique in comment 2:
Comment 1 is fixed since 4.8, and out of the three cases in comment 0 only the
second one persists (together with comment 3).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695
--- Comment #3 from janus at gcc dot gnu.org ---
Another example: proc_ptr_result_4.f90 in the testsuite yields the following
error since 4.9 (see also PR59428):
procedure(sin), pointer :: f
1
Error: Procedure p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54779
--- Comment #5 from Eric Botcazou ---
> Eric, to what extent would this patch suffice? It detects situations
> when an array is the only thing preventing a local scalar from being
> totally replaced disappearing and if it also complies with a num
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59428
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> > I will commit the following as obvious to fix it: ...
>
> This doesn't fix the unfriendly error message.
Yes, but there is another PR for this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429
--- Comment #3 from Jan Engelhardt ---
I took it "Component: rtl-optimization" meant Register Transfer Language, not
Runtime Linking. If needed, please reassign to whatever component is actually
applicable. I am looking for a compiler enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429
--- Comment #2 from Jan Engelhardt ---
Suppose all functions are used and taken.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398
--- Comment #5 from Sergio Losilla ---
(In reply to Harald Anlauf from comment #3)
OK, so we seem to agree that gfortran is not assigning the correct bounds,
right?
> shape(-3:3) == shape (-2:4) == shape(1:7)
>
> Shape is UBOUND-LBOUND+1.
Hm,
1 - 100 of 135 matches
Mail list logo
