--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-02-19 05:32
---
I can not reproduce the problem with gfortran 4.5 on Vista. What version pf
gfortran are you using. Post the response to "gfortran -v" please.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43115
--- Comment #10 from hjl dot tools at gmail dot com 2010-02-19 05:28
---
On Linux/x86, I got
[...@gnu-6 gcc]$ ./xgcc -B./
/export/gnu/import/git/gcc/gcc/testsuite/g++.dg/abi/packed1.C -Wpacked -S
/export/gnu/import/git/gcc/gcc/testsuite/g++.dg/abi/packed1.C:7:14: warning:
packed attrib
--- Comment #9 from hjl dot tools at gmail dot com 2010-02-19 05:15 ---
The test failed on Linux/ia32:
FAIL: g++.dg/abi/packed1.C (test for excess errors)
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #10 from manu at gcc dot gnu dot org 2010-02-19 02:03 ---
With my patch, the testcase in PR43113 still looks awful because each single
line is already too long.
Basically, my patch fixes PR23510. The other PRs are different (but related)
problems.
--
http://gcc.gnu.org/
--- Comment #9 from manu at gcc dot gnu dot org 2010-02-19 01:59 ---
Now, I mean a recent GCC (4.5), not my patch.
The testcase for 23510 works ok and the output of my patch is:
pr9335-2.C:7:3: error: expected unqualified-id before template
pr9335-2.C: At global scope:
pr9335-2.C:4:
--- Comment #8 from jason at gcc dot gnu dot org 2010-02-19 01:59 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-19 01:54 ---
However, this particular error has gotten much worse and now we iterate over
the error:
(...skipping a lot of lines...)
pr9335.C: In instantiation of const int X<15>::value:
pr9335.C:2:36: instantiated from const
--- Comment #7 from paolo dot carlini at oracle dot com 2010-02-19 01:54
---
Having this finally fixed would be really great, Manuel!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-19 01:49 ---
The following patch seems to do the trick:
Index: gcc/cp/error.c
===
--- gcc/cp/error.c (revision 150311)
+++ gcc/cp/error.c (working copy)
@@ -
--- Comment #4 from jason at gcc dot gnu dot org 2010-02-19 01:38 ---
This doesn't seem specific to templates. The non-template version
struct B { typedef int type; };
struct D : B {
typedef type type;
};
D cc;
D::type tcc;
deals with the same issue, and is similarly accepted by G+
--- Comment #7 from jason at gcc dot gnu dot org 2010-02-19 01:16 ---
Subject: Bug 42837
Author: jason
Date: Fri Feb 19 01:16:28 2010
New Revision: 156885
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156885
Log:
PR c++/42837
* class.c (create_vtable_ptr): Set D
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-19 01:03
---
Jason, are you willing to analyze a bit this old issue?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #2 from bangerth at gmail dot com 2010-02-19 00:59 ---
Darn, I did not pay attention at all. Scrap the text starting with
"The issue is confusing..." above which is entirely pointless because
the code I pasted is wrong in at least two ways (as the error messages
correctly poi
--- Comment #14 from bangerth at gmail dot com 2010-02-19 00:56 ---
(In reply to comment #13)
> The library issue doesn't exist anymore ;) Thus, let's not be distracted by
> the
> trivial library case, ok?
I see, that's convenient :-)
In any case, in order to keep PRs focused on singl
--- Comment #1 from bangerth at gmail dot com 2010-02-19 00:56 ---
*** Bug 9990 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--
This is the remaining part of PR 9990 that concerns interpretation of
the core language rules. Consider this code snippet:
-
struct B { typedef int type; };
template struct D : B {
typedef typename D::type type;
};
D cc;
D::type tcc;
--
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-02-19 00:53
---
The reason the CR-LF is important is that this is basically the only real
difference between Linux and Windows other than the OS libraries.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43115
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-02-19 00:52
---
I have gfortran freshly compiled on a Vista machine. I will take a look at
this tonight if I can find some time. This may be a target specific bug, but I
can't tell until I observe it first hand. Please attach t
--- Comment #3 from kargl at gcc dot gnu dot org 2010-02-19 00:43 ---
(In reply to comment #2)
> Subject: Re: bug with gfortran on Windows vista, correct on Linux
>
> You have not understand the problem :
> It is a gfortran bug, with and only with Windows, you must test this problem
>
--- Comment #16 from paolo dot carlini at oracle dot com 2010-02-19 00:33
---
Sure, it was a trap ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321
--- Comment #11 from rearnsha at gcc dot gnu dot org 2010-02-19 00:23
---
There are two further targets that define a ..._mark_dllimport function: mcore
and sh (for symbian). The mcore code is the same as arm-pe, but the sh code
does not wrap the symbol inside a MEM operation.
--
--- Comment #15 from hp at gcc dot gnu dot org 2010-02-19 00:17 ---
(In reply to comment #14)
You can't wait until the weekend?
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from rearnsha at gcc dot gnu dot org 2010-02-19 00:13
---
Hmm, sorry about that, yes, I can confirm the bug as reported in comment #5,
also occurs on trunk.
Do you know if this code compiled on older releases of GCC?
--
rearnsha at gcc dot gnu dot org changed:
--- Comment #9 from steven at gcc dot gnu dot org 2010-02-18 23:58 ---
#1 0x00b4717b in assemble_variable (decl=0x77f62000, top_level=0,
at_end=1, dont_output_data=0)
at ../../gcc-4.4.2/gcc/varasm.c:2144
2144 gcc_assert (GET_CODE (XEXP (decl_rtl, 0)) == SYMBOL_REF);
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-18 23:44 ---
I can confirm the second bug, which is a checking failure in varasm.c, with GCC
4.4.2 for arm-wince-pe:
(gdb) run
Starting program: /home/stevenb/devel/build-4.4.2/gcc/cc1 -DCRASH k.c
ff_fill_linesize
Analyzing comp
--- Comment #14 from paolo dot carlini at oracle dot com 2010-02-18 23:36
---
Apparently, nobody is interested in this issue, closing.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-18 23:25 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from cgerdy at wanadoo dot fr 2010-02-18 23:22 ---
Subject: Re: bug with gfortran on Windows vista, correct on Linux
You have not understand the problem :
It is a gfortran bug, with and only with Windows, you must test this problem
with Windows not Linux.
The listing of
--- Comment #1 from bruno at clisp dot org 2010-02-18 23:21 ---
Created an attachment (id=19918)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19918&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43116
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.4.2/configure --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
--prefix=/arch/x86-linux/gnu-inst-gcc/4.4.2 --enable-shared
--enable-version-specific-runtime-libs --enable-nls --enable-th
--- Comment #7 from steven at gcc dot gnu dot org 2010-02-18 23:15 ---
Richard, comment #0 has preprocessed source.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rearnsha at gcc dot gnu dot org 2010-02-18 23:09
---
Please supply pre-processed source that will allow a developer to reproduce the
problem.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #36 from mikestump at comcast dot net 2010-02-18 22:06 ---
I've checked in a slightly updated fix in r156877. Let us know if all the
regressions are fixed now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
--- Comment #24 from paolo dot carlini at oracle dot com 2010-02-18 22:03
---
Richard, can you comment on this issue? Do you think it's currently correct to
have numeric_limits<>:is_modulo == true for all our signed integral types? We
are not making any progress on this issue :(
--
--- Comment #9 from olga at il dot ibm dot com 2010-02-18 21:07 ---
(In reply to comment #8)
> Olga, is this fixed?
I think so.
Olga.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41843
--- Comment #13 from paolo dot carlini at oracle dot com 2010-02-18 20:57
---
The library issue doesn't exist anymore ;) Thus, let's not be distracted by the
trivial library case, ok?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9990
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-18 20:55
---
Bah, I can do the change, sure, but if we are not resolving this issue, we are
not making progress on the number of open, long-standing, Bugzilla entries, and
that is *bad*.
--
http://gcc.gnu.org/bugzilla
--- Comment #11 from bangerth at gmail dot com 2010-02-18 20:53 ---
(In reply to comment #10)
> I'm not sure to fully understand, Wolfgang: you mean, we should change that
> line in the library instead of dealing with a possible C++ issue here? That
> would be easy to do, just tell me th
--- Comment #8 from Zachary_Deretsky at mentor dot com 2010-02-18 20:50
---
With -Wconversion for the assignment to bitfields gcc 4.4.2 gives a
warning, which is impossible to fix.
This BUG (I hope everybody agrees it is a BUG) gives us a lot of
trouble while porting our code (45 devel
--- Comment #4 from jason at gcc dot gnu dot org 2010-02-18 20:47 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-18 20:36
---
I'm not sure to fully understand, Wolfgang: you mean, we should change that
line in the library instead of dealing with a possible C++ issue here? That
would be easy to do, just tell me the exact form you woul
--- Comment #9 from bangerth at gmail dot com 2010-02-18 20:29 ---
(In reply to comment #8)
> For the record, all the compilers I have at hand, EDG based too, accept this
> in
> the most strict mode. I seriously doubt there is really something to fix here.
That said: if it is unclear t
--- Comment #34 from paolo dot carlini at oracle dot com 2010-02-18 20:18
---
Thanks Jason!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-18 20:01 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #33 from jason at gcc dot gnu dot org 2010-02-18 19:59 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #32 from jason at gcc dot gnu dot org 2010-02-18 19:58 ---
Subject: Bug 43108
Author: jason
Date: Thu Feb 18 19:58:41 2010
New Revision: 156874
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156874
Log:
PR c++/43108
* typeck.c (cp_build_binary_op): Ad
--- Comment #6 from jakub at gcc dot gnu dot org 2010-02-18 19:49 ---
I doubt http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077#c4 applies cleanly to
the current tree, as
http://gcc.gnu.org/viewcvs?view=revision&revision=156693
changed the same spot as the second hunk. Will need to see
--- Comment #5 from steven at gcc dot gnu dot org 2010-02-18 19:48 ---
Olga, is this fixed?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #21 from mark at codesourcery dot com 2010-02-18 19:47 ---
Subject: Re: warnings about 'mangling of 'va_list' has changed
in GCC 4.4' not suppressed in sytem headers
manu at gcc dot gnu dot org wrote:
> In any case, using diagnostic_report_warnings_p (location) should fix
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41843
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-18 19:46 ---
Olga, is this fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41843
--- Comment #20 from manu at gcc dot gnu dot org 2010-02-18 19:44 ---
(In reply to comment #15)
> Subject: Re: warnings about 'mangling of 'va_list' has changed
> in GCC 4.4' not suppressed in sytem headers
>
> manu at gcc dot gnu dot org wrote:
>
> > Why is this a note and not simpl
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-18 19:20 ---
Subject: Bug 43070
Author: jason
Date: Thu Feb 18 19:20:21 2010
New Revision: 156872
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156872
Log:
PR c++/43070
* semantics.c (finish_goto_stmt): Do
--- Comment #44 from dominiq at lps dot ens dot fr 2010-02-18 19:10 ---
The patch in comment #43 with the fix in comment #44 works for the limited
tests I am able to do right now. I can do a "full" test with a fresh bootstrap
of gcc and fortran, but it will take a full day, so I'ld pref
--- Comment #23 from bkoz at redhat dot com 2010-02-18 19:09 ---
Subject: Re: man page errors for generated libstdc++
man pages
> 2010-02-17 09:36 --- So... shall we close this as fixed?
Remaining item is doxygen function markup is not working for man pages.
But this is an upstr
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-18 18:46 ---
Hmm, this code is undefined first but that does not matter. The issue comes
down to return statements not being combined into just one return statement. I
don't know if this is supposed to happen this way or not.
--- Comment #43 from dominiq at lps dot ens dot fr 2010-02-18 18:44 ---
The compilation of gcc/regrename.c fails with
...
cc1: warnings being treated as errors
../../gcc-4.5-work/gcc/regrename.c: In function 'build_def_use':
../../gcc-4.5-work/gcc/regrename.c:1113:6: error: array subscr
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-18 18:42 ---
(In reply to comment #3)
> #8 0x0253271e in create_single_exit_edge (region=0x47afff8) at
> /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:965
> 965 forwarder = make_forwarder_block
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-18 18:39 ---
#8 0x0253271e in create_single_exit_edge (region=0x47afff8) at
/home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:965
965 forwarder = make_forwarder_block (exit, &sd_region_without_exit
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-18 18:38 ---
Confirmed backtrace:
#0 0x00801625 in link_block (b=0x7f9f943dcaf8, after=0x7f9f943dc138)
at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfg.c:153
#1 0x012b8fb6 in create_bb (h=0x0, e=0x0, after=0x7f9f
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-18 18:36 ---
Happens on x86_64-linux-gnu also even without -ftree-vectorize.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-18 18:31 ---
(gdb) p debug_gimple_stmt (new_stmt)
# DEBUG p => &s
This was caused by the introduction of debug statements.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from kargl at gcc dot gnu dot org 2010-02-18 18:15 ---
Please attach the files to the PR. Cut and paste from
bugzilla will mangle the files; particularly, if it is
a CRLF problem.
Also, try removing your iostat usage and see if the
the operating system generates an erro
--- Comment #42 from bernds_cb1 at t-online dot de 2010-02-18 18:13 ---
Created an attachment (id=19917)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19917&action=view)
Another test patch that attempts to fix the problem.
Could you test whether this fixes it?
--
bernds_cb1 at
listing of the gfortran program whith the bug
use iso_fortran_env
implicit none
integer,parameter:: mligne = 1,n2 = 10
character(len = n2 + 2):: ligne ! the bug is here : 2 is not necessary
for reading essai.f95 : 10 max character per line
! character(len = n2)::
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-18 17:42 ---
The problem turns out to be that the patch for PR 6196 was wrong;
ext/label[12].C are ill-formed, as both are trying to goto the address of an
array rather than an element.
--
jason at gcc dot gnu dot org changed:
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #8 from paolo dot carlini at oracle dot com 2010-02-18 16:56
---
For the record, all the compilers I have at hand, EDG based too, accept this in
the most strict mode. I seriously doubt there is really something to fix here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #31 from jason at gcc dot gnu dot org 2010-02-18 16:52 ---
Performance regression.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Keyw
--- Comment #5 from matz at gcc dot gnu dot org 2010-02-18 16:50 ---
That leaves 'c' which isn't printed, because the setup of c (a stackslot)
is schedules to be part of the function call setup, the breakpoint is before
that setup, and hence the location of 'c' does point to the correct
--- Comment #4 from matz at gcc dot gnu dot org 2010-02-18 16:40 ---
Created an attachment (id=19916)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19916&action=view)
do reg elimination
This will fix some more of the var[bc] references by eliminating
all registers in DEBUG_INSN_P.
--- Comment #15 from jason at gcc dot gnu dot org 2010-02-18 16:28 ---
Fixed for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #14 from jason at gcc dot gnu dot org 2010-02-18 16:28 ---
*** Bug 43101 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-18 16:28 ---
*** This bug has been marked as a duplicate of 26261 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from jason at gcc dot gnu dot org 2010-02-18 16:27 ---
Subject: Bug 26261
Author: jason
Date: Thu Feb 18 16:27:18 2010
New Revision: 156865
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156865
Log:
PR c++/26261
PR c++/43101
* pt.c (tsubst
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-18 16:27 ---
Subject: Bug 43101
Author: jason
Date: Thu Feb 18 16:27:18 2010
New Revision: 156865
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156865
Log:
PR c++/26261
PR c++/43101
* pt.c (tsubst_
--- Comment #1 from jason at gcc dot gnu dot org 2010-02-18 16:27 ---
Subject: Bug 43109
Author: jason
Date: Thu Feb 18 16:27:07 2010
New Revision: 156864
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156864
Log:
PR c++/43109
* semantics.c (begin_class_definitio
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-18 16:19 ---
Another request for this feature:
http://gcc.gnu.org/ml/fortran/2010-02/msg00144.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209
--- Comment #3 from matz at gcc dot gnu dot org 2010-02-18 16:12 ---
At least varb isn't printed in fn3, because dse2 (after prologue_epilogue)
makes the expressions in the debug_insn be (clobber 0). Presumably because
frame elimination rewrites the address-takings, but not the debug in
--- Comment #41 from dominiq at lps dot ens dot fr 2010-02-18 15:59 ---
Created an attachment (id=19915)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19915&action=view)
.rnreg for -fdbg-cnt=rnreg:138
Command line
gfc -fdump-rtl-rnreg-details -fdbg-cnt=rnreg:138 -m64 -O1 -frename
--- Comment #40 from dominiq at lps dot ens dot fr 2010-02-18 15:58 ---
Created an attachment (id=19914)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19914&action=view)
.rnreg for -fdbg-cnt=rnreg:137
Command used
fc -fdump-rtl-rnreg-details -fdbg-cnt=rnreg:137 -m64 -O1 -frename-
--- Comment #39 from bernds_cb1 at t-online dot de 2010-02-18 15:52 ---
(In reply to comment #36)
> > Could you attach the .rnreg dumps
>
> How do I get them?
>
-fdump-rtl-rnreg-details
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-18 15:46 ---
Created an attachment (id=19913)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19913&action=view)
gcc45-pr43077-test.patch
Here is a guality testcase for it. Before the patch there is just lots of
FAILs, with t
--- Comment #38 from dominiq at lps dot ens dot fr 2010-02-18 15:41 ---
Created an attachment (id=19912)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19912&action=view)
Assembly for -fdbg-cnt=rnreg:138
Command line
gfc -S -fdbg-cnt=rnreg:138 -m64 -O1 -frename-registers
/opt/gcc/
--- Comment #37 from dominiq at lps dot ens dot fr 2010-02-18 15:40 ---
Created an attachment (id=19911)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19911&action=view)
Assembly for -fdbg-cnt=rnreg:137
Command used
gfc -S -fdbg-cnt=rnreg:137 -m64 -O1 -frename-registers
/opt/gcc/
--- Comment #5 from hjl dot tools at gmail dot com 2010-02-18 15:40 ---
Revision 156792:
http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00375.html
made ICE disappear. I don't know if it really fixes
the bug or just hides it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
--- Comment #36 from dominiq at lps dot ens dot fr 2010-02-18 15:38 ---
> Could you attach the .rnreg dumps
How do I get them?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #35 from bernds_cb1 at t-online dot de 2010-02-18 15:32 ---
Okay, great. Could you attach the .rnreg dumps and assembly output for both
values?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #19 from paolo dot carlini at oracle dot com 2010-02-18 15:24
---
Ok, it's just an handful of files, after all. If Julian wants to add the
pragmas, the change is pre-approved, otherwise, just let me know when you have
the other issues under control, and I'll do it.
--
h
--- Comment #18 from mmitchel at gcc dot gnu dot org 2010-02-18 15:13
---
Paolo --
I think libsupc++ is just as much a "system library" as libstdc++. It doesn't
have an ISO-standard API, of course, but that's not the point; it's just as
much a part of the system/implementation as libs
--- Comment #1 from matz at gcc dot gnu dot org 2010-02-18 15:13 ---
Created an attachment (id=19910)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19910&action=view)
candidate fix
Try this. I don't know how to write guality tests, but I think it has the
effects you look for, at
--- Comment #34 from dominiq at lps dot ens dot fr 2010-02-18 15:08 ---
And the winner is N=137!
[karma] f90/bug% gfc -fdbg-cnt=rnreg:137 -m64 -O1 -frename-registers
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90
dbg_cnt 'rnreg' set to 137
[karma] f90/bug% a.out
[
--- Comment #10 from jakub at gcc dot gnu dot org 2010-02-18 15:04 ---
Created an attachment (id=19909)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19909&action=view)
gcc45-pr42233-2.patch
Trunk patch that seems to fix this together with the previous patch.
Going to bootstrap/re
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-02-18 14:53 ---
Subject: Bug 43066
Author: jamborm
Date: Thu Feb 18 14:53:05 2010
New Revision: 156863
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156863
Log:
2010-02-18 Martin Jambor
PR tree-optimization/430
--- Comment #33 from dominiq at lps dot ens dot fr 2010-02-18 14:22 ---
> Sorry about that. Yes, you'll need to add that in dbgcnt.def, or just apply
> this additional patch.
This recompiles most of gcc!-(it will take a couple hours on my poor G5!-).
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-18 14:18
---
*** Bug 43113 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-18 14:18
---
*** This bug has been marked as a duplicate of 9335 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #32 from bernds_cb1 at t-online dot de 2010-02-18 14:17 ---
Created an attachment (id=19908)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19908&action=view)
Additional patch on top of the previous one
Sorry about that. Yes, you'll need to add that in dbgcnt.def, or j
1 - 100 of 131 matches
Mail list logo
