--- Comment #3 from irar at il dot ibm dot com 2010-01-24 07:39 ---
This has already been discussed in PR 41464.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42846
I try to compile the following code:
#include
#include
using std::vector;
int main()
{
vector kdPoints;
vector results;
vector::iterator iter;
vector histogram;
for (long long i = 0; i < 100; i++) kdPoints.push_back(i);
histogram.push_back(0
--- Comment #3 from kargl at gcc dot gnu dot org 2010-01-24 00:57 ---
(In reply to comment #2)
> > In other words, fix your code by putting an & in column 72.
>
> This is not a solution since it makes it invalid fixed-form source:
>
> Error: Syntax error in argument list at (1)
Ye
--- Comment #3 from aph at redhat dot com 2010-01-23 23:18 ---
Subject: Re: error: 'jvariant::jvariant(jbyte)' cannot be
overloaded
On 01/22/2010 11:43 AM, mathieu dot malaterre at gmail dot com wrote:
> --- Comment #2 from mathieu dot malaterre at gmail dot com 2010-01-22
> 11:
--- Comment #2 from bugs at 59A2 dot org 2010-01-23 21:54 ---
> In other words, fix your code by putting an & in column 72.
This is not a solution since it makes it invalid fixed-form source:
Error: Syntax error in argument list at (1)
Not treating the char-73 & specially makes -W
--- Comment #1 from kargl at gcc dot gnu dot org 2010-01-23 21:29 ---
I changed this to a P5 and enhancement request;
although I much more inclined to close this with
a WONTFIX.
Notes in the Standard are non-normative text.
It's clear that there is an assumption in
this Note that a For
gfortran -Wall currently warns about truncated lines even when character 73 is
an ampersand. Observe item (4) of Note 3.10 in the Fortran 2003 standard:
In some circumstances, for example where source code is maintained in an
INCLUDE file for use in programs whose source form might be either
fixed
--- Comment #10 from burnus at gcc dot gnu dot org 2010-01-23 17:59 ---
(In reply to comment #7)
> See previous comment - this should be suspended with PR38471. It puts the
> pressure on me to start on the array descriptor work:-(
I think there are actually two issues - one is the SPAN
Found while looking again as PR 39304. The following program causes an ICE. It
might well be only fixable with the new array descriptor.
The program works with 4.1 and 4.2 (which might well be only by chance) but
fails with 4.3/4.4/4.5 with:
test.f90: In function 'func':
test.f90:7:0: internal co
--- Comment #3 from janus at gcc dot gnu dot org 2010-01-23 17:25 ---
Another related quote from the F2003 standard:
C489 (R457) If derived-type-spec is a type name that is the same as a generic
name, the component-spec-list shall not be a valid actual-arg-spec-list for a
function refer
--- Comment #16 from burnus at gcc dot gnu dot org 2010-01-23 16:57 ---
Reopen the bug. It seems as if there a deeper issue in the caching, which
should be investigated. As the committed patch (limiting fmt-cache size) fixes
the issue for all known test cases, I have removed the dependen
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-23 15:25 ---
Probably related to PR42837.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsT
Executing on host: /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/home
/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../
/home/dave/gnu/gcc/gcc/gcc/testsui
te/g++.dg/abi/forced.C -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux/libst
dc++-v3/include/hppa-linux
-I/home/dave/gnu/gcc/objdir/h
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-01-23 14:09
---
Time constraints, un assigning.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-01-23 14:03
---
As Paul would say, I am flummoxed. In remove_subobject_ref at line expr.c:1159
e->ref = p->ref->next; p->ref is NULL, resulting in the segfault. I have
been unable to conjure a solution.
--
http://gcc.gn
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-01-23 13:43
---
Closing as fixed. See related PR42353
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from toon at moene dot org 2010-01-23 13:24 ---
Tobias,
If we ask a bug submitter for more information, or to confirm our suspicions,
we put the bug report in WAITING.
Note to submitter: bug reports with status WAITING will be closed if not
replied to within 3 months.
K
--- Comment #4 from pault at gcc dot gnu dot org 2010-01-23 12:13 ---
I have just posted a patch for this.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #43 from rguenth at gcc dot gnu dot org 2010-01-23 12:06
---
Well, we run DCE during early optimizations and the CCP that runs before
pass_return_slot and after final inlining removes dead basic-blocks and
trivially dead insns already.
--
rguenth at gcc dot gnu dot org c
--- Comment #4 from steven at gcc dot gnu dot org 2010-01-23 12:06 ---
Don't use pastebin please. It's impossible to see what you dumped there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
--- Comment #3 from dougmencken at gmail dot com 2010-01-23 11:53 ---
May I add that GCC 4.4.3 bootstraps perfectly with the same config without any
single issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-01-23 11:35 ---
Fixed by these patches:
http://gcc.gnu.org/viewcvs?view=revision&revision=156172
http://gcc.gnu.org/viewcvs?view=revision&revision=156189
--
amylaar at gcc dot gnu dot org changed:
What|Removed
--- Comment #28 from amylaar at gcc dot gnu dot org 2010-01-23 11:17
---
Subject: Bug 36101
Author: amylaar
Date: Sat Jan 23 11:17:30 2010
New Revision: 156189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156189
Log:
PR libstdc++/36101, PR libstdc++/42813
* co
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-01-23 11:17 ---
Subject: Bug 42813
Author: amylaar
Date: Sat Jan 23 11:17:30 2010
New Revision: 156189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156189
Log:
PR libstdc++/36101, PR libstdc++/42813
* conf
--- Comment #5 from ktietz at gcc dot gnu dot org 2010-01-23 10:35 ---
Yes, I can confirm this issue, but want to investigate where the underlying
issue really comes from. The interesting issue I found is, that if a
TLS-variable isn't assigned, the values of the addresses in different th
--- Comment #27 from bonzini at gnu dot org 2010-01-23 09:11 ---
Subject: Re: deps on other host libraries incorrect
On 01/22/2010 08:17 PM, amylaar at gcc dot gnu dot org wrote:
> --- Comment #25 from amylaar at gcc dot gnu dot org 2010-01-22 19:17
> ---
> Created an attachm
--- Comment #42 from jakub at gcc dot gnu dot org 2010-01-23 08:13 ---
Well, stdarg wants to be scheduled after some kind of DCE, to avoid making
decisions from dead code. So in that case we'd have to schedule a DCE pass
after retslot (perhaps just for cfun->stdarg functions), then stda
27 matches
Mail list logo
