--- Comment #8 from uros at kss-loka dot si 2006-10-05 07:08 ---
try -O2 -msse2, you get:
_Z8todoubledd:
subl$12, %esp
fldl24(%esp)
faddl 16(%esp)
fstpl (%esp)
movsd (%esp), %xmm0
addl$12, %esp
cvttsd2si
--- Comment #4 from federico dot carminati at cern dot ch 2006-10-05 07:44
---
Subject: Re: Ambiguous warning with -Weffc++
Thanks for your answer. However, if I just code in the following way
int f(a lhc) {
if (lhs) return TRUE;
else if g() return TRUE;
--- Comment #6 from pault at gcc dot gnu dot org 2006-10-05 07:45 ---
(In reply to comment #5)
FX,
When the len in call sub(len) is resolved, it is never given its correct
return type, which leads to the ICE. I still don't understand why the
implicit
none is doing this on
--- Comment #2 from uros at kss-loka dot si 2006-10-05 07:51 ---
(In reply to comment #0)
The mode switching for floating point rounding that the i386 backend does
does not actually place mode switches, but rather the calculation of values
used for mode switches. Not only does that
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-05 08:05
---
(In reply to comment #6)
I am glad to see that you are pursuing that one. I nearly bust my head on it
my notes indicate that I had a fix that broke everything else; no details, so
not much help I'm afraid. I
--- Comment #5 from patchapp at dberlin dot org 2006-10-05 08:07 ---
Subject: Bug number PR27588
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00234.html
--
When I bootstrap gcc with the commands given below I get a testsuite failure
in libstdc++-v3/testsuite/25_algorithms/rotate/1.cc
It might be a pch problem, since that ice does not occur if I compile the
testsuite file without using any library
Michael Cieslinski
Command to build and test gcc:
--- Comment #3 from roberto dot costa at st dot com 2006-10-05 08:15
---
I tested what happens if the first PHI-OPT pass is moved right before the first
VRP pass in gcc/passes.c
It looks like PHI-OPT should be run both before and after VRP and DOM.
The example reported shows that,
--- Comment #14 from carlos at codesourcery dot com 2006-10-05 08:33
---
GCC_EXEC_PREFIX does not control the search directories for header files. Could
you verify that your target actually compiles before applying the patches?
Both gcc and cpp need to be taught taught not to search
--- Comment #5 from markus dot schoepflin at comsoft dot de 2006-10-05
08:49 ---
(In reply to comment #3)
With the attached patch, at least the unmodified boehm-gc 6.7 tested
successfully.
I stumbled accross this bug when investigating why the boost thread library
tests started to
The function seekp(pos_type) fails on an empty stream,
even when the target position is the value returned
by tellp.
---
#include ostream
#include sstream
#include iostream
int
main()
{
std::ios::pos_type const
err =
--- Comment #1 from pcarlini at suse dot de 2006-10-05 09:28 ---
Ok, thanks for the report. The issue is the following: tellp() calls
pubseekoff, whereas seekp() calls pubseekpos. Since we are implementing the
resolution of DR 453, which allows pubseekoff to not fail when the stream is
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #15 from eweddington at cso dot atmel dot com 2006-10-05 12:49
---
(In reply to comment #14)
GCC_EXEC_PREFIX does not control the search directories for header files.
Could
you verify that your target actually compiles before applying the patches?
In the test that I
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
In this code:
typedef class
{
public:
void m();
} C;
void
C::m()
{
}
void
f()
{
C c;
c.m();
}
// { dg-final { scan-assembler (.globl|.global)\[ \t]+[_]+ZN1C1mEv } }
C is a typedef name which accroding to 7.1.3 is used to denote the unnamed
class. 3.5 ; 4, 3rd item, specifies that this
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 14:25 ---
I think
*** This bug has been marked as a duplicate of 7221 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 14:25 ---
*** Bug 29356 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 2006-10-05 14:30 ---
As far as I can tell this has nothing to do with PCH.
It might be a pch problem, since that ice does not occur if I compile the
testsuite file without using any library
What do you mean by this?
--
pinskia at
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-10-05 14:33
---
Subject: Bug 28980
Author: pinskia
Date: Thu Oct 5 14:33:46 2006
New Revision: 117456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117456
Log:
2006-10-05 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-05 14:34
---
Fixed in 4.1 also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from debian-gcc at lists dot debian dot org 2006-10-05
15:13 ---
are other patches than r111381 (trunk) required for a backport of
long-double-128
to the 4.1 branch?
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28701
--- Comment #41 from dje at gcc dot gnu dot org 2006-10-05 15:18 ---
Subject: Bug 27287
Author: dje
Date: Thu Oct 5 15:18:18 2006
New Revision: 117458
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117458
Log:
Backport from mainline
2006-09-11 Guenter Roeck
$rstr7-19b
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-05 15:40
---
This looks related to PR 26926.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-05 15:44 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #42 from pinskia at gcc dot gnu dot org 2006-10-05 15:47
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 15:48 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
the form %c0, as in
asm ( movl $42, %c0(%1) : : i(offsetof(...)), r(...) : memory );
is not documented.
--
Summary: inline asm %c0 template form not documented
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: trivial
--- Comment #1 from avi at argo dot co dot il 2006-10-05 16:05 ---
Created an attachment (id=12384)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12384action=view)
proposed documentation patch
I don't have a coypright assignment, but most of this is copied verbatim from
the
--- Comment #41 from debian-gcc at lists dot debian dot org 2006-10-05
16:06 ---
the patch was applied in the redhat/gcc-4_1-branch, not in the gcc-4_1-branch.
either the target milestone should be changed or the bug reopened.
Matthias
--
debian-gcc at lists dot debian dot org
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-10-05 16:17 ---
Subject: Re: ICE using intrinsics as arguments
FX
That bug is fixed by my submitted patch about INTRINSICS
(http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html).
I'll review it tomorrow - I am going to give
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #5 from daney at gcc dot gnu dot org 2006-10-05 17:02 ---
Another idea:
In the SIGCHLD signal handler record the pid of the process that exited. Then
look it up in the pidToProcess map. If it belongs to the libgcj runtime, then
do waitpid(pid, ...) on it. Otherwise
The following snipped of code compiled with -Wall emits two times the same
warning :
#include stdio.h
#include stdint.h
#include stdlib.h
int main(void)
{
uint32_t foo = 42;
char bar[] = bla;
char *buffer = malloc(10);
snprintf(buffer, 10, %lu %s\n, foo, bar);
free(buffer);
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 17:07 ---
uint32_t is unsigned int on those targets and this is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from joseph at codesourcery dot com 2006-10-05 17:10 ---
Subject: Re: Warning issued two times with snprintf
On Thu, 5 Oct 2006, pinskia at gcc dot gnu dot org wrote:
uint32_t is unsigned int on those targets and this is not a bug.
Did you read the bug report? The
--- Comment #3 from pf dot hugues at gmail dot com 2006-10-05 17:11 ---
I don't contest the warning, but why is it printed 2 times ?!
--
pf dot hugues at gmail dot com changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-05 17:15 ---
(gdb) p debug_tree (function)
addr_expr 0xb7dd60a0
type pointer_type 0xb7dd3900
type function_type 0xb7dae180 type integer_type 0xb7d122a0 int
SI
size integer_cst 0xb7cff380
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-05 17:17 ---
(In reply to comment #2)
Did you read the bug report? The problem is that the warning is issued
twice when it should be issued once.
Woops, I am too tried
I'd guess that the issue that that the system header
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org
|dot org
--- Comment #4 from patchapp at dberlin dot org 2006-10-05 17:32 ---
Subject: Bug number PR fortran/28415
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00258.html
--
--- Comment #9 from patchapp at dberlin dot org 2006-10-05 17:34 ---
Subject: Bug number PR19260
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00255.html
--
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-05 17:54 ---
(In reply to comment #0)
1. Whether a certain minimum version of GMP/MPFR is required to avoid known
bugs, etc.
See my recent patch to toplevel configure.in. THe minimum required
versions should be gmp-4.1.x
I have been encountering the following problem for several weeks. I compile and
create few c++ shared libraries (can happen with just one, so it has nothing to
do with the number). I then attempt to link a program and I get the following
type of segv during the link step:
collect2: ld terminated
--- Comment #1 from jmbnyc at gmail dot com 2006-10-05 18:18 ---
Created an attachment (id=12385)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12385action=view)
gzip'd tar file with README that shows how to reproduce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 18:18 ---
*** This bug has been marked as a duplicate of 29244 ***
*** This bug has been marked as a duplicate of 29244 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05 18:18 ---
*** Bug 29359 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29244
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05 18:19 ---
Didn't I already tell you to post this to binutils?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29359
--- Comment #4 from jmbnyc at gmail dot com 2006-10-05 18:23 ---
(In reply to comment #3)
Didn't I already tell you to post this to binutils?
yes you did and I did what you asked. However, I now believe that the problem
is with the compiler. I also came up with a test case that
--- Comment #5 from jmbnyc at gmail dot com 2006-10-05 18:27 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
Look, I am not trying to be a jerk, but this new filing has a test
case associated with it (another thing that you asked for). In
addition, I took your
--- Comment #6 from jmbnyc at gmail dot com 2006-10-05 18:41 ---
This bug might be a duplicate as you suggest but (my fault for opening new
instead of updating original) it is not 'resolved'. On the original post you
said to report to binutils because you suggested the bug was not in
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-05 18:48 ---
If you disagree with that assertion then please tell me.
Yes I do disagree because GCC only produces a .s file which then binutils
assembles and links.
Then again you are using a GCC and binutils that were modified
--- Comment #8 from jmbnyc at gmail dot com 2006-10-05 18:48 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
One last comment. From the below, I think it is clear that the
compiler is the problem. If I compile with -g then I get the problem,
however if I
--- Comment #9 from jmbnyc at gmail dot com 2006-10-05 18:51 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
Fair enough. I did report it to them, but never heard back. Uli
Drepper is going to try to help me get to the right people. He has
also offered to look
--- Comment #25 from stsp at users dot sourceforge dot net 2006-10-05
19:29 ---
i(var) of course can't work with -fpic,
I tried it on an x86_64 today, and it seems to work.
If I use -m32, then it doesn't. Why?
it would only work at the expense
of text relocations, but those are not
According to 12.2 ; 5, in the following code:
int count;
class C
{
public:
int i;
C() : i(1) { ++count;}
C(const C c) : i(c.i) { ++count;}
~C() { --count;}
};
int
f ()
{
static const C c = C();
return c.i;
}
int
main ()
{
int i = f ();
return count i;
}
the temporary to which
I have some code which when compiled:
Using gcc 4.0.3(ubuntu 4.0.3-lubuntu5) I have no problems.
Using gcc version 4.1.0 (SUSE Linux) and -O2 or -O3, I have no problems.
HOWEVER, using no compile flags, the code seg faults.
Is it worth generating a small test case and test data file?
--
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-10-05 19:58
---
Fixed on mainline by Lee's patch for PR27667.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-10-05 20:31
---
The bug is actually only a 4.2 regression as it only affected mainline
(sorry for the incorrect info).
Yes, indeed affected and not affects: The bug has been fixed by Mark's
patch for PR 29105.
Since the
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-10-05 20:31
---
*** Bug 29021 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 20:36 ---
well a testcase is needed to reproduce the problem in the first place anyways
so yes a testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 20:38 ---
*** This bug has been marked as a duplicate of 20416 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-05 20:38 ---
*** Bug 29360 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The new FC6 eclipse cdt generates a java.lang.NullPointerException everytime it
tries to save the .cdtproject project file. This occurs when changes are made
to a CDT project. For example, adding a new source folder causes the error.
I have isolated the problem to a stand-alone testcase which
--- Comment #1 from jjohnstn at redhat dot com 2006-10-05 20:48 ---
Created an attachment (id=12386)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12386action=view)
Testcase that exhibits problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
--- Comment #10 from drow at gcc dot gnu dot org 2006-10-05 20:49 ---
FYI, the testcase does not build with my system g++ 4.1.2; remove the static
from 'extern C static'. The result does not choke my system's binutils, i.e.
it links successfully.
If I use the provided .s file instead
--- Comment #11 from jmbnyc at gmail dot com 2006-10-05 20:57 ---
Subject: Re: bad relocation section name `' in .o causes segv of ld.
Thanks for looking at it. Uli Drepper helped me to look at the asm and
conclude (just about one hour ago) that indeed the problem is with
as. It
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-10-05 21:00
---
Fixed on mainline by Lee's patch for PR26938.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jjohnstn at redhat dot com 2006-10-05 21:12 ---
Created an attachment (id=12387)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12387action=view)
sample cdtproject file that is used by test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
--- Comment #8 from pault at gcc dot gnu dot org 2006-10-05 21:20 ---
Created an attachment (id=12388)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12388action=view)
A fix for this PR
This checks for the presence of GFORTRAN module as the first utterances in
the .mod file. The
--- Comment #3 from mark at gcc dot gnu dot org 2006-10-05 22:01 ---
Confirmed with classpath CVS:
$ /usr/local/jamvm/bin/jamvm CDescription
java.lang.NullPointerException
at gnu.xml.transform.TransformerImpl.strip(TransformerImpl.java:452)
at
--- Comment #4 from tromey at gcc dot gnu dot org 2006-10-05 22:03 ---
Also happens with gcc svn head.
I was also going to CC dog :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-10-05 23:28
---
Because of Jason's patch for PR 28346 the code is now wrongly accepted
on the 4.0 branch. With a slightly different testcase I can still
trigger the ICE, though:
==
bool b;
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-10-05 23:29
---
I meant Jason's patch for PR 26696, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28346
The following invalid code snippet triggers an ICE on mainline:
==
templateint void foo()
{
throw A();
struct A {} a;
}
template void foo0();
==
bug.cc: In function 'void foo()':
bug.cc:3: error: there are no arguments to 'A' that
--- Comment #5 from gregory dot fruth at aero dot org 2006-10-06 00:04
---
The patch works perfectly in 4.2.0(svn). My application now
builds and runs successfully under gfortran. Thanks, Jakub!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28415
If one compiles
-
module test
implicit none
type epot_t
integer :: c
type(nonexist),pointer :: l
end type epot_t
end module test
-
no error (and no warning) is shown. If one removes the keyword pointer, the
error message Derived type at (1) has not
--- Comment #9 from kargl at gcc dot gnu dot org 2006-10-06 00:33 ---
I have a patch, but it requires libm to have ldexp{f,l}.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-10-06
01:20 ---
The last work on this by Andrew was to propose the code fragment
below for remapping the functions...
static void
darwin_patch_builtin (int fncode)
{
tree fn = built_in_decls[fncode];
const char
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2006-10-06
01:32 ---
Geoff,
This bug is also radar://4759173. I've been asked to...
Please debug and produce a small self-contained (that is, not including
gfortran) testcase showing what goes wrong.
Could you expand in
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-06 02:48 ---
Fixed also on the 4.1 branch now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-06 02:51 ---
Subject: Bug 28349
Author: pinskia
Date: Fri Oct 6 02:51:33 2006
New Revision: 117479
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117479
Log:
2006-10-05 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #7 from kargl at gcc dot gnu dot org 2006-10-06 03:04 ---
(In reply to comment #6)
The last work on this by Andrew was to propose the code fragment
below for remapping the functions...
static void
darwin_patch_builtin (int fncode)
{
}
It is unclear to me where you
On Fri, 2006-10-06 at 03:04 +, kargl at gcc dot gnu dot org wrote:
It is unclear to me where you intend to put this function.
If it is in the gfortran frontend, I will outright reject
the patch and lobby to have it removed if anyone applies.
It should be in darwin.c in the back-end. C
--- Comment #8 from pinskia at physics dot uc dot edu 2006-10-06 03:06
---
Subject: Re: real kind=16 failures on powerpc-darwin
On Fri, 2006-10-06 at 03:04 +, kargl at gcc dot gnu dot org wrote:
It is unclear to me where you intend to put this function.
If it is in the gfortran
--- Comment #9 from kargl at gcc dot gnu dot org 2006-10-06 03:08 ---
Paul,
I read the patch, and think that you can commit it.
gfortran certainly can't recover for a mangled module.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24398
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-06 03:51 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2006-10-06
03:53 ---
Andrew,
Could you flesh out the code fragment a bit so it is clearer exactly how
you intended to hook this into darwin.c? Also, if you could just show how
you were going to handle the table of symbols
--- Comment #5 from robert dot wilhelm at gmx dot net 2006-10-06 04:36
---
valgrind output:
==6316== Invalid read of size 4
==6316==at 0x8598C55: compute_all_dependences (tree-data-ref.c:3975)
==6316== Address 0x44C0D20 is 0 bytes inside a block of size 20 free'd
==6316==at
--- Comment #10 from mrs at apple dot com 2006-10-06 05:46 ---
Apple has no long double library support
This is false. What we don't have is symbol versioning and the `normal' names
refer to an abi different long double, 8 bytes as I recall.
The impact to the fortran frontend should
92 matches
Mail list logo
