--- Comment #1 from kristian dot spangsege at gmail dot com 2008-01-17
07:37 ---
Just tested it on the latest release 4.2.2 build from source with no patches
and the ICE is still there.
System:
g++ (GCC) 4.2.2
Linux localhost.localdomain 2.6.20-1.2952.fc6 #1 SMP Wed May 16 18:59:18 EDT
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-17 07:31 ---
Can you show in an RTL dump why you are sure that the branch probabilities are
lost?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from eres at il dot ibm dot com 2008-01-17 07:21 ---
Created an attachment (id=14955)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14955&action=view)
The testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34826
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-17 07:19 ---
Subject: Bug 34429
Author: pault
Date: Thu Jan 17 07:19:04 2008
New Revision: 131592
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131592
Log:
2008-01-17 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-17 07:19 ---
Subject: Bug 34471
Author: pault
Date: Thu Jan 17 07:19:04 2008
New Revision: 131592
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131592
Log:
2008-01-17 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-17 07:19 ---
Subject: Bug 34431
Author: pault
Date: Thu Jan 17 07:19:04 2008
New Revision: 131592
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131592
Log:
2008-01-17 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
Running the attached testcase with trunk r131577 on SPU
with -dm -fmodulo-sched -O2 flags (which enables also do-loop optimization)
demonstartes the fact that the branch probability is not reserved with do-loop
optimization.
This causes a major preformance regression (of about 40%) when tested with
gcc reports ICE when compiling SVMlight software package
(http://svmlight.joachims.org/) on x86_64 with -funsafe-math-optimizations.
The following is the reduced code from the svm_hideo.c in SVMlight 6.01.
Occurs on: gcc-4.2.2 on x86_64, gcc-4.3.0 on x86_64,
gcc-4.2.3 on i386, gcc-4.3
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-17 06:42
---
Interestingly, we are getting a spurious FMT_COLON token which is causing a
premature exit from the formatted transfer function and a miscalculation of the
maximum position, resulting in a truncation of the output
--- Comment #28 from tbm at cyrius dot com 2008-01-17 06:26 ---
(In reply to comment #21)
> Please give specifics, including what bug reports and what headers. Your
> experience is much different from my datapoint, which is Jakub building fedora
> with gcc-43. I see 8 fails 5118 packages
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-17 06:23 ---
Toon,
I do not have time to fix this in the next day or two but this is a work
around:
type(grid_index_region),intent(out)::iregion(:)
I'll bet that with dimension nproc that no descriptor is being bui
--- Comment #5 from jv244 at cam dot ac dot uk 2008-01-17 06:12 ---
with allocatable structure components, this likely is not a 'f95 only' bug
(PR32834).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34820
The following small test case causes GCC to ICE:
struct A;
struct B
{
B(A const &);
explicit B(B const &);
};
struct A
{
A(B) {}
};
B f(A const &a) { return B(a); }
Same result (ICE) on the following two systems:
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
gcc (GCC) 4.1.1 2
--- Comment #3 from bje at gcc dot gnu dot org 2008-01-17 05:27 ---
I cannot reproduce this using either r131302 (a revision close to 2008-01-04)
or today's head revision. Can you please check again using an updated source
tree?
>From the paths listed in your bug report, it appears tha
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-17
03:37 ---
Subject: Re: FAIL:
gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
execution
The above change fixes a problem noticed in debugging this PR -- two
versions of libm were being use
--- Comment #17 from bergner at gcc dot gnu dot org 2008-01-17 03:28
---
Ok, after talking with Kenny offline, we agreed to commit Janis' patch that
changed xmalloc to xcalloc. As the comment I added to the changes says, if
future users of this code see a performance issue, we can revi
--- Comment #16 from bergner at gcc dot gnu dot org 2008-01-17 03:22
---
Subject: Bug 33796
Author: bergner
Date: Thu Jan 17 03:21:36 2008
New Revision: 131589
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131589
Log:
PR rtl-optimization/33796
* sparseset.c (sp
--- Comment #2 from swadams at ca dot ibm dot com 2008-01-17 03:06 ---
Subject: Re: Floating point rounding mode error in inline asm
code, linux/cell be cross compiler
I will attempt to generate a testcase for you. I tried useing the
-savetemps and only got the .s outputs, which spe
--- Comment #3 from danglin at gcc dot gnu dot org 2008-01-17 03:00 ---
Subject: Bug 34699
Author: danglin
Date: Thu Jan 17 02:59:16 2008
New Revision: 131588
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131588
Log:
PR libgfortran/34699
* pa-hpux.h (LINK_SPEC):
--- Comment #2 from danglin at gcc dot gnu dot org 2008-01-17 02:56 ---
Subject: Bug 34699
Author: danglin
Date: Thu Jan 17 02:55:48 2008
New Revision: 131587
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131587
Log:
PR libgfortran/34699
* pa-hpux.h (LINK_SPEC):
--- Comment #1 from danglin at gcc dot gnu dot org 2008-01-17 02:49 ---
Subject: Bug 34699
Author: danglin
Date: Thu Jan 17 02:48:20 2008
New Revision: 131586
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131586
Log:
PR libgfortran/34699
* pa-hpux.h (LINK_SPEC):
--- Comment #16 from pinskia at gcc dot gnu dot org 2008-01-17 02:19
---
*** Bug 34822 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-17 02:19 ---
*** This bug has been marked as a duplicate of 24791 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-17 01:44 ---
> using spu-gcc linux to cell BE cross compiler v4.1.1 under Fedora release 7
> Kernel: 2.6.21-1.3194.fc7. I am uncertain of the hardware specs.
Stop right there, this is an IBM provided spu-gcc. I should know I h
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||gcc-bugs at gcc dot gnu dot
|
Testcase (runme.cxx):
template
struct DiffImContainer {
int id;
static short xyz;
};
template short DiffImContainer::xyz = 0;
int main() {
DiffImContainer d;
d.id = 20;
return 0;
}
[EMAIL PROTECTED]:~/temp/compile$ gcc-4.2 -v -save-temps runme.cxx
Using built-in specs.
Targe
--- Comment #11 from zackw at panix dot com 2008-01-17 00:13 ---
Subject: Re: [4.3 regression] spurious "is used uninitialized" from auto_ptr
I'm not convinced it is a duplicate; no one has determined whether or
not the EH region in my case is actually dead.
--
http://gcc.gnu.org/
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-01-16 23:47
---
(In reply to comment #3)
> You need C to support libgfortran so my question here is still valid. What is
> sizeof(char) for your target?
>
> Seriously if the target does not define sizeof(char) as 1, it is broke
--- Comment #3 from kargl at gcc dot gnu dot org 2008-01-16 23:43 ---
>
> Code snippit
> program foo
> implicit none
> integer index /0/
> undeclared_variable(index)=0.0
> another_variable(1)=0.0
> stop
> end
>
With trunk I get,
troutmask:sgk
--- Comment #27 from bkoz at gcc dot gnu dot org 2008-01-16 23:41 ---
> My -- possibly incorrect -- understanding is that in this case the
> problem with the old headers is not that it prevents implementation of
> an ISO-conformant C++ library, but just that they're a pain to keep
> a
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
--- Comment #6 from reichelt at gcc dot gnu dot org 2008-01-16 23:06
---
This is still not fixed.
The testcase in the testsuite - trunk/gcc/testsuite/g++.dg/cpp0x/vt-34055.C -
is only covers the original testcase (which was fixed quite a while ago).
The other two testcases from comment
--- Comment #1 from hp at gcc dot gnu dot org 2008-01-16 23:04 ---
The .logs show that the failing tests error with:
xgcc: unrecognized option '-pthread'
That's because cris-elf does not support pthreads (being a bare-iron/simulator
target).
The bug is due to spop's patch below; it sho
--- Comment #10 from ian at airs dot com 2008-01-16 22:49 ---
Created an attachment (id=14953)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14953&action=view)
Possible patch
This untested patch fixes the problem with the test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-16 22:46 ---
(In reply to comment #2)
> > How is char defined for your target? sizeof(char) needs to be 1 to be
> > complaint to C.
>
> C is most likely fine, but I don't care too much about C.
You need C to support libgfortra
--- Comment #11 from amacleod at redhat dot com 2008-01-16 22:44 ---
One could also argue that this exposes two bugs.
First, the const function should not be returning true for tree_could_throw_p()
second, SCCVN and PRE don't agree on whether an expression that can throw can
be regenera
--- Comment #2 from anlauf at gmx dot de 2008-01-16 22:41 ---
(In reply to comment #1)
> I don't think you can disable these types. If your target does not support
> them, something is wrong.
The target (if you refer to it as the underlying processor) does support
these types; at lea
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-16 22:39
---
Sure, but I still see hpux11.11 in the list of secondary platforms. OTOH, if
nobody is going to invest the time to fix this we can as well close this issue.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-16 22:36 ---
Here's a real test case:
program main
real, dimension(2,2) :: a
logical(kind=4), dimension(2) :: b
integer, dimension(2) :: i
equivalence (b,i)
data a /1.0, 2.0, -0.1, -0.2 /
i = 16843009 ! Initialize i
--- Comment #2 from harry dot rockefeller at gmail dot com 2008-01-16
22:35 ---
(In reply to comment #0)
> gcc-3.x gives this information but gcc-4.2 does not.
> In the shell snippit below, the unknown symbol name should be
> embedded in the gcc-4.2 error lines as it is done in gcc-3.4.
--- Comment #26 from pinskia at gcc dot gnu dot org 2008-01-16 22:34
---
I should make a mention, that I added for the GCC 4.1.1 based PS3 toolchain an
option to give source compatibility for GCC 4.0.2, if anyone wants the patch, I
can provide it. It was mostly C++ front-end changes to
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-16 22:29 ---
*** Bug 34470 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-16 22:29
---
dup. don't count this twice.
*** This bug has been marked as a duplicate of 34196 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #25 from mark at codesourcery dot com 2008-01-16 22:27 ---
Subject: Re: [4.3 Regression] Revision 129442 breaks
libstc++ API
bkoz at gcc dot gnu dot org wrote:
> I believe there is a bit of a bias here, in that it's OK to make FE changes,
> but even well-documented and wa
--- Comment #34 from rguenth at gcc dot gnu dot org 2008-01-16 22:23
---
We should possibly split this bug into two, one for the inconsitencies that
can be observed with accepted asms comparing -O0 to -O and one for the
bug that we reject(ed) "i"(&var + 1) with optimization.
Or declare
--- Comment #24 from fang at csl dot cornell dot edu 2008-01-16 22:21
---
A compromise might be to provide the headers only if specifically requested,
say, by -fbackward-headers (something more specific than -fpermissive). So by
default, the compiler/preprocessor will now error out, bu
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2008-01-16
22:19 ---
Also wrong with Debian's 4.2.3 prerelease.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34820
Before revision 131573 these tests passed. With revision 131577, these tests
fail.
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ...
FAIL: gcc.dg/tree-ssa/parallelization-1.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/reduc-1.c (test for excess errors)
FAIL: gcc.dg
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-16 22:11 ---
Reduced test case; works if one removes the INTENT(OUT).
module grid_io
type grid_index_region
integer, allocatable::lons(:)
end type grid_index_region
contains
subroutine read_grid_header()
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-01-16 22:09
---
Fixed.
Probably by the patch for PR34751.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-16 21:54
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-16 21:54 ---
Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00208.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-16 21:52 ---
Subject: Bug 32628
Author: rguenth
Date: Wed Jan 16 21:51:57 2008
New Revision: 131579
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131579
Log:
2008-01-16 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-16 21:50 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2008-01-16
21:49 ---
Does fail on x86-64-unknown-gnu-linux and OSX ppc (probably not relevant).
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
-
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-01-16 21:48
---
Although PR34314 has been fixed, the testcase here still crashes.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2008-01-16
21:47 ---
Created an attachment (id=14952)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14952&action=view)
Tar file with sources to evoke problem
The test case.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
The attached gzipped tar file unpacks in a directory gf.
If the definition in the Makefile of F95 is changed to invoke the latest
gfortran-4.3.0, one gets the following error message:
grid_io.f90: In function 'read_grid_header':
grid_io.f90:40: internal compiler error: in gfc_conv_descriptor_data
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.3.0
http://gcc
--- Comment #15 from ubizjak at gmail dot com 2008-01-16 21:36 ---
Fixed again.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|WAITING
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34752
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-01-16 21:35
---
Fixed. Probably by the patch for PR34751.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from amit dot mitkar at gmail dot com 2008-01-16 21:28
---
Am seeing the same problem. I understand that its not a bug with g++ but what
about the resolution. How should one get around the issue ?
In yanliu's second comment the said program doesn't directly reference th
--- Comment #10 from amacleod at redhat dot com 2008-01-16 21:27 ---
Sure, if that the case, then the bug is in tree_could_throw_p() and we can fix
it there :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
--- Comment #14 from uros at gcc dot gnu dot org 2008-01-16 21:21 ---
Subject: Bug 34249
Author: uros
Date: Wed Jan 16 21:20:39 2008
New Revision: 131578
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131578
Log:
PR debug/34249
* dwarf2out.c (output_call_frame_in
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-16 21:20 ---
See also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f014195ccf7b93e6/
for some other possible diagnostic issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547
--- Comment #9 from rguenther at suse dot de 2008-01-16 21:18 ---
Subject: Re: [4.3 Regression] ICE in
find_or_generate_expression
On Wed, 16 Jan 2008, amacleod at redhat dot com wrote:
> --- Comment #8 from amacleod at redhat dot com 2008-01-16 20:53 ---
> Created an attach
--- Comment #8 from amacleod at redhat dot com 2008-01-16 20:53 ---
Created an attachment (id=14951)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14951&action=view)
proposed patch for sccvn
I did some analysis, and then verified with dberlin that I was on the right
track.
The ro
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-16 20:46 ---
>Also fails in 4.3.0 20070713.
that 4.3 is way old, over 6 months old now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34819
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-01-16 20:45
---
*** Bug 34819 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-16 20:45 ---
*** This bug has been marked as a duplicate of 32295 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
$ cat t.c
enum e ve;
void f0 (int i)
{
ve + i;
}
$ gcc -c t.c
enum.c: In function f0:
enum.c:6: internal compiler error: in create_tmp_var, at gimplify.c:368
Please submit a full bug report,
with preprocessed source if appropriate.
Works in c++:
/tmp/t.c:1: error: use of enum e without prev
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-01-16 20:36 ---
> function func2()
> type(bar) func2
> allocate(func1%baz(1))
> end function
Here, func1 needs to be func2 to be correct. Confirmed.
Backtrace:
(gdb) bt
#0 fancy_abort (file=0x87d843c "../../../gcc/gcc/fortran
>From fink, I have gmp 4.1 in /sw/{lib,include}, but mpfr is ancient. I put a
new mpfr in $HOME, and tried to build with:
../gcc-4.3-20080111/configure --with-gmp=/sw --with-mpfr=$HOME
Unfortunately, that tells me that my mpfr is too old.
The order of the flags does not matter; I always get, in
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-01-16 20:29 ---
Could you also add an exemplary code snippet, please?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from hjl at lucon dot org 2008-01-16 20:17 ---
(In reply to comment #12)
> Created an attachment (id=14949)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14949&action=view) [edit]
> Patch to fix issue in Comment #8
>
> H.J, could you test if attached patch fixes th
--- Comment #3 from dick dot hendrickson at gmail dot com 2008-01-16 20:07
---
Subject: Re: defined assignment not allowed to vector subscripted array
Why not put this one on hold for a while. I'll check some more.
There never was a
formal interpretation request. It's kind of odd, b
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last re
Seems I missed a case in my patch for PR 34671:
program main
real, dimension(2,2) :: a
logical, dimension(2) :: b
integer, dimension(2) :: i
equivalence (b,i)
data a /1.0, 2.0, -0.1, -0.2 /
i = 16843009 ! Initialize i to put junk into b
call random_number(a)
b = any(a>0.5,dim=1)
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-16 20:01 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
The patch for PR 34671 created an optimization opportunity that
is currently missed.
The "any" and "all" functions with dim=1 now accept an argument that
can be any logical type. Only the lowest-order byte is used for
evaluation.
Now consider the following:
program main
logical(kind=1), dimen
--- Comment #23 from rguenther at suse dot de 2008-01-16 19:40 ---
Subject: Re: [4.3 Regression] Revision 129442 breaks
libstc++ API
On Wed, 16 Jan 2008, bkoz at gcc dot gnu dot org wrote:
> --- Comment #21 from bkoz at gcc dot gnu dot org 2008-01-16 19:22 ---
>
> > old dep
--- Comment #22 from pinskia at gcc dot gnu dot org 2008-01-16 19:27
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34778 is one example, this example
just came into today. There are many more. A lot of the windows/xbox360 based
games use the deprecated headers also.
--
http://g
--- Comment #21 from bkoz at gcc dot gnu dot org 2008-01-16 19:22 ---
> old deprecated headers all over the place
Please give specifics, including what bug reports and what headers. Your
experience is much different from my datapoint, which is Jakub building fedora
with gcc-43. I see 8
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-16 19:18 ---
This sounds like an exact duplicate of PR 31944 which was just fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34815
--- Comment #20 from pinskia at gcc dot gnu dot org 2008-01-16 19:06
---
I still see people use the old deprecated headers all over the place, even in
newer bug reports. So it is hard to think they will be removed any time soon.
I am sorry but from a QA point of view, they should be a
--- Comment #19 from bkoz at gcc dot gnu dot org 2008-01-16 18:58 ---
I'm asking for a libstdc++ maintainer vote on this issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
--- Comment #18 from bkoz at gcc dot gnu dot org 2008-01-16 18:46 ---
The ammount of breakage for this change is IMHO tolerable and will within the
tolerances of other breakages that nobody is talking about reverting, and
furthermore solutions for the API change are well documented. Cer
--- Comment #1 from debian-gcc at lists dot debian dot org 2008-01-16
18:38 ---
Created an attachment (id=14950)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14950&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34815
[forwarded from http://bugs.debian.org/440287]
seen with current 4.1 and 4.2 branches, not seen on the trunk.
Matthias
While trying to compile the 2.6.23-rc4 snapshots from buildserver.net on hppa,
gcc went in some kind of endless loop over the following command
hppa64-linux-gnu-gcc-4.1 -Wp,-
--- Comment #12 from ubizjak at gmail dot com 2008-01-16 18:25 ---
Created an attachment (id=14949)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14949&action=view)
Patch to fix issue in Comment #8
H.J, could you test if attached patch fixes the problem from Comment #8?
--
ht
--- Comment #11 from hjl at lucon dot org 2008-01-16 18:23 ---
(In reply to comment #9)
>
> GNU ld version 2.17.50.0.3-6 20060715
>
Your linker doesn't issue the error since it is too old. See
http://sourceware.org/bugzilla/show_bug.cgi?id=4454
--
hjl at lucon dot org changed:
--- Comment #1 from bergner at gcc dot gnu dot org 2008-01-16 17:51 ---
I'll be posting a proposed patch today or tomorrow. The patch will allow us to
be binary compatible with XLC which is producing binaries that follow the ABI.
There have been some reload issues which have made this
--- Comment #10 from ubizjak at gmail dot com 2008-01-16 17:44 ---
(In reply to comment #9)
> .LASFDE3:
> .long .LASFDE3-.Lframe1
> .long .LFB15
> - .long .LFE15-.LFB15
> + .long .LHOTB1
> + .long .LHOTE1-.LHOTB1
> + .long .LCOLDB1
>
--- Comment #8 from tsarkov at cs dot man dot ac dot uk 2008-01-16 17:39
---
This is fixed in current mainline GCC (as per
http://gcc.gnu.org/gcc-4.3/porting_to.html).
--
tsarkov at cs dot man dot ac dot uk changed:
What|Removed |Added
---
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-16 17:33 ---
This regression enters between 4.1/20050803 and 4.2/20061221.
gfc_check_constructor_type is applying the wrong type, because the intrinsic
has not been resolved. (This is called from gfc_match_init_expr via
gfc_resolv
--- Comment #9 from ubizjak at gmail dot com 2008-01-16 17:25 ---
(In reply to comment #8)
> It isn't fixed. The error went from as to ld:
Here is my log:
Executing on host: /home/uros/gcc-build-all/gcc/xgcc
-B/home/uros/gcc-build-all/gcc/ /home/uros/gcc-svn/trunk/gcc/
testsuite/gcc.dg
--- Comment #21 from tsarkov at cs dot man dot ac dot uk 2008-01-16 17:19
---
(In reply to comment #20)
> Changing to NEW based on
> http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00858.html
>
Shouldn't the PR be closed now, after committing the patch from
http://gcc.gnu.org/ml/gcc-patc
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-16 16:46
---
Last time I looked into it, it was code
alignment affected by inlining in the string matching loop (longest_match).
This code is very atypical, since the internal loop com
1 - 100 of 161 matches
Mail list logo
