--- Comment #3 from jean-marc dot valin at usherbrooke dot ca 2005-11-01
00:20 ---
Can you send a link to a tarball of the compiler you want me to try?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24601
--- Comment #7 from jsm28 at gcc dot gnu dot org 2005-11-01 00:25 ---
diagnostic.c gets #include stack information from input_file_stack. cpplib
gets it from source_locations. With --enable-mapped-location, this regression
could be fixed by diagnostic.c getting it from source_locations
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-01 00:33 ---
This is a true C++ front-end problem, in that the seg fault is due to a stack
overflow in the C++ front-end. I think this is a regression but I have not
tried to reduce it yet.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-01 00:36 ---
I think this is a dup of bug 22044.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
namespace std6
{
int j;
}
namespace std = std6;
%g++ -c test.cc
test.cc:7: error: conflicting declaration 'namespace std = std6;'
:0: error: 'std' has a previous declaration as `namespace std { }'
test.cc:7: error: declaration of `namespace std = std6;'
:0: error: conflicts with previous decla
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-01 00:46 ---
The error message suggest that you are using a pre 4.0 compiler. As the
mainline and 4.0.0 gives only one error message:
earth:~>gcc t.cc
t.cc:6: error: conflicting declaration 'namespace std = std6;'
:0: error: 's
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-01 00:52 ---
http://gcc.gnu.org/ml/gcc/2005-10/msg01152.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24601
gcc -c -DU_HAVE_INTTYPES_H solveHestonVol.ii gives a segmentation fault.
gcc info from the full source compile:
Reading specs from /gcc-3.4/lib/gcc/i686-pc-cygwin/3.4.5/specs
Configured with: ../gcc/configure --prefix=/gcc-3.4
--enable-languages=c,c++,f77 --verbose --enable-nls --without-included
--- Comment #1 from ron_hylton at hotmail dot com 2005-11-01 01:04 ---
Created an attachment (id=10093)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10093&action=view)
bz2 compressed .ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24605
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-01 01:10 ---
There is at least a 4.1 regression here as we ICE after an error.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from wilson at gcc dot gnu dot org 2005-11-01 01:16 ---
I see that we are using the priority field now, so let's put the 4.1 target
milestone back and set priority to p4 to indicate this is a regression, but not
a serious one blocking the release.
--
wilson at gcc dot
--- Comment #4 from hnakamur at good-day dot co dot jp 2005-11-01 01:48
---
You are correct that IANA character-sets file only contains
two "EUC-JP" aliases: csEUCPkdFmtJapanese and EUC-JP.
But actually there are many non-Java programs which use other aliases and
do not accept above al
--- Comment #6 from law at redhat dot com 2005-11-01 01:56 ---
Subject: Re: [4.1 Regression] jump threading
causing excessive code duplication
On Mon, 2005-10-31 at 03:43 +, mmitchel at gcc dot gnu dot org
wrote:
>
> --- Comment #5 from mmitchel at gcc dot gnu dot org
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
||do
--- Comment #82 from pcarlini at suse dot de 2005-11-01 02:21 ---
To clarify: I have unassigned myself from this bug because I don't consider
myself sufficiently competent in this area to evaluate all the possible trade-
offs of the issue and don't want to block in any way the work of kn
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-01 02:22 ---
With the source here, I was able to find a different issue which I will be
posting soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24602
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-01 02:23 ---
Note the backtrace for the orginal issue is:
#28 0x0040bb94 in convert_like_real (convs=Variable "convs" is not
available.
) at /home/pinskia/src/newtest/trunk/gcc/cp/call.c:4379
#29 0x0040c241 in bui
--- Comment #5 from wilson at gcc dot gnu dot org 2005-11-01 02:44 ---
Even at -O0, we notice that main ends with a call to a function that does not
return, so the epilogue gets optimized away, and the last instruction in the
main function is the call to abort.
gdb is naively using retu
Testcase:
template
void for_each(_Function __f)
{
__f(1);
}
class locale{};
template
void trim(SequenceT& Input, const locale& Loc=locale());
int main()
{
for_each(trim);
}
---
I don't know if this is valid or not but guess what ICC also ICEs on this
testcase too.
--
Summ
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-01 03:09 ---
PR 24606 is the other issue I found.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #83 from bkoz at gcc dot gnu dot org 2005-11-01 03:59 ---
I agree Geoff, we should hold off on this for 4.1, and try to hit 4.2. If
things get solid sooner, maybe this can be reconsidered. Adding this patch to
4.0.x is out of the question, it has the potential to change too
--- Comment #2 from bkoz at gcc dot gnu dot org 2005-11-01 04:05 ---
Oh, ok, whatever. It's still unfortunate for my twisted purposes.
I can see why this is not allowed in practice, since then namespace could be
aliased all over the place, but at least the error message should make sen
--- Comment #84 from geoffk at geoffk dot org 2005-11-01 04:30 ---
Subject: Re: libstdc++ headers should have pop/push of the visibility around
the declarations
On 31/10/2005, at 7:59 PM, bkoz at gcc dot gnu dot org wrote:
> Geoff, it's not as simple as just marking throwable types,
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-01 04:36 ---
Reduced testcase:
struct string;
struct _Deque_iterator {
string &operator*() const;
};
template void for_each(_Function __f) {
_Deque_iterator __first1;
__f(*__first1);
}
struct locale {
loc
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-01 04:45 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg6.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
template class A{};
template class B{};
template class C{};
template class D{};
template class E{};
template void f() {
typedef A > > > foo;
}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `void f()':
foo.cc:7: error: template argument 1 is invalid
foo.cc:7: error: ISO C++ forbid
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-01 05:31 ---
If we used the caret way of doing things it would just work.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
This test case causes the same value to be consistently stored in two different
registers. This happens when compiling at -O2.
extern int abs (int __x);
extern int bar (short*, short, int);
struct s
{
short int* top;
short int* left;
short int* diag;
};
int
foo (int *a, struct s* p, short
--- Comment #2 from pault at gcc dot gnu dot org 2005-11-01 05:53 ---
Subject: Bug 21565
Author: pault
Date: Tue Nov 1 05:53:29 2005
New Revision: 106317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106317
Log:
2005-11-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2005-11-01 05:53 ---
Subject: Bug 18737
Author: pault
Date: Tue Nov 1 05:53:29 2005
New Revision: 106317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106317
Log:
2005-11-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-01 05:53 ---
Subject: Bug 14994
Author: pault
Date: Tue Nov 1 05:53:29 2005
New Revision: 106317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106317
Log:
2005-11-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from ian at airs dot com 2005-11-01 06:02 ---
Created an attachment (id=10095)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10095&action=view)
.s file from gcc -S -O2
For reference, here is the complete .s file I get from gcc -S -O2.
--
http://gcc.gnu.org/bugz
--- Comment #6 from wilson at gcc dot gnu dot org 2005-11-01 06:38 ---
Short story...
Your kernel code is broken. init functions go in .init.text, but init data
goes in .init.data, not .init.text. See the
Documentation/Docbook/kernel-hacking.tmpl file in any recent kernel.
Long story.
--- Comment #10 from wilson at gcc dot gnu dot org 2005-11-01 07:19 ---
On mainline, this appears to be fixable with a one line patch.
We are failing in should_stack_file because we have a _cpp_file struct with
buffer=0 and buffer_valid=1. We call read_file which immediately returns
be
--- Comment #11 from wilson at gcc dot gnu dot org 2005-11-01 07:22 ---
Created an attachment (id=10096)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10096&action=view)
clear buffer_valid when clearing buffer
Untested patch for mainline which makes the testcase work.
--
wilso
--- Comment #12 from wilson at gcc dot gnu dot org 2005-11-01 07:25 ---
The patch should use false instead of 0. These new fangled boolean types keep
messing me up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24202
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
It's true that the arm comment start symbol is '@', but GCC will generate some
assembler code end with a '@' and a comment without a separator so it can't be
parsed by gas.
For example, I compile the libgcc2.c:__gcc_bcmp with xgcc, it failed:
___
--- Comment #12 from rth at gcc dot gnu dot org 2005-11-01 07:35 ---
Frankly, this smells like a plain old-fashioned reload bug to me.
There's no reason this insn couldn't have been rendered as
movl %esi,%eax
movbl %al,%eax
Investigating further to see how nasty it might be...
--
101 - 139 of 139 matches
Mail list logo
