Matthias Klose writes:
> peter green writes:
>> >Next GCC 4.2 will be prepared to be included in unstable; a current
>> >issue is http://sourceware.org/bugzilla/show_bug.cgi?id=4302 which has
>> >to be resolved before g++-4.2 can enter unstable.
>> That bug is marked as "resolved invalid" with a re
Ludovic Brenta writes:
> Matthias Klose writes:
> > peter green writes:
> >> >Next GCC 4.2 will be prepared to be included in unstable; a current
> >> >issue is http://sourceware.org/bugzilla/show_bug.cgi?id=4302 which has
> >> >to be resolved before g++-4.2 can enter unstable.
^^^
The removal of the email address:
[EMAIL PROTECTED]
>From the mailing list:
Al-Manahel Newsletter List
is all set.
Date of this removal: Thu Apr 19 02:18:07 2007
Please save this email message for future reference.
--
>So? Does that mean the bug doesn't affect GCC 4.1? In that case, I
>believe Peter is correct that the bug must be resolved before GCC 4.2
>can enter unstable. Do you agree?
That wasn't text i wrote it was text i was quoting.
I was just asking if anyone knew if there was a bug report on the iss
The subscription of the email address:
[EMAIL PROTECTED]
To the mailing list:
Al-Manahel Newsletter List
is all set. Thanks for subscribing!
Date of this subscription: Thu Apr 19 07:51:25 2007
Please save this email message for future reference.
-
--
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
Processing commands for [EMAIL PROTECTED]:
> forwarded 382153 http://gcc.gnu.org/PR31638
Bug#382153: (ia64) libstdc++6-4.1-dev: needed when including
Noted your statement that Bug has been forwarded to http://gcc.gnu.org/PR31638.
> thanks
Stopping processing here.
Please contact me if you need
forwarded 382153 http://gcc.gnu.org/PR31638
thanks
* Margarita Manterola <[EMAIL PROTECTED]> [2006-09-11 16:35]:
> I had submitted two testcases to show the problem in the stdc++
> library, but I forgot to add that this bug only turns up with a
> certain warning
Thanks, I've reported this upstrea
Your message dated Thu, 19 Apr 2007 16:51:56 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not t
--
tbm at cyrius dot com changed:
What|Removed |Added
CC||debian-gcc at lists dot
||debian
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-20 00:49 ---
I think this is really the same as PR 19495.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone
Processing commands for [EMAIL PROTECTED]:
> retitle 395533 ICE: s390_expand_setmem, at config/s390/s390.c:3559
Bug#395533: stlport5.1 - FTBFS: internal compiler error
Changed Bug title to ICE: s390_expand_setmem, at config/s390/s390.c:3559 from
stlport5.1 - FTBFS: internal compiler error.
> --
* Sam Hocevar <[EMAIL PROTECTED]> [2007-01-29 02:52]:
>The way I understand the -maltivec flag is "make the compiler aware
> of AltiVec instructions and the vector type, but only generate AltiVec
> code if the intrinsics are being used", whereas -mabi=altivec
> means "generate AltiVec code whe
* Falk Hueffner <[EMAIL PROTECTED]> [2007-03-01 18:46]:
> > [...]
> > The bug is not reproducible, so it is likely a hardware or OS problem.
> This means it is actually quite likely to bve a hardware problem. Can
> you reproduce it on another machine?
Diego, can you still reproduce this issue?
--
* Alex Romosan <[EMAIL PROTECTED]> [2006-11-02 09:54]:
> if i try to compile vamos from cvs i get:
...
> the code seems to be okay, and compiling with -O0 works so it's probably
> gcc's fault. compiling with O2 used to work but it broke somewhere along
> the way (unfortunately i can't remember for
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-10-14 23:25]:
> * Richard B. Kreckel <[EMAIL PROTECTED]> [2006-10-14 22:14]:
> > Setting CXXFLAGS to -O instead of -O2 at least makde the package
> > compile. (I don't suppose that g++-4.1_4.1.1-16 made a difference.)
>
> It compiles fine on my ARM box
tags 416819 + fixed-upstream
retitle 416819 [fixed in SVN] internal compiler error: in tsubst, at
cp/pt.c:7226
thanks
* Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-30 19:59]:
> > Please too note that it is 100% a Debian/gcc bug, hence I've just
> > downloaded gcc version 4.1.2, and it works lik
Processing commands for [EMAIL PROTECTED]:
> tags 416819 + fixed-upstream
Bug#416819: gcc-4.1: internal compiler error
There were no tags set.
Tags added: fixed-upstream
> retitle 416819 [fixed in SVN] internal compiler error: in tsubst, at
> cp/pt.c:7226
Bug#416819: gcc-4.1: internal compiler e
Processing commands for [EMAIL PROTECTED]:
> forwarded 401496 http://gcc.gnu.org/PR31639
Bug#401496: gfortran-4.1 bug / ICE in gfc_conv_constant at
fortran-trans-const.c:348
Noted your statement that Bug has been forwarded to http://gcc.gnu.org/PR31639.
> thanks
Stopping processing here.
Please
On Thu, Apr 19, 2007, Martin Michlmayr wrote:
> 01:06 any comment on
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408918
> 01:06 yes it is not a bug
> 01:08 why?
> 01:08 because -maltivec enables altivec usage in general
> 01:09 "Generate code that uses (does not use) AltiVec
> inst
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> * Alex Romosan <[EMAIL PROTECTED]> [2006-11-02 09:54]:
>> if i try to compile vamos from cvs i get:
> ...
>> the code seems to be okay, and compiling with -O0 works so it's probably
>> gcc's fault. compiling with O2 used to work but it broke somewhere
forwarded 401496 http://gcc.gnu.org/PR31639
thanks
* Jonathan Stott <[EMAIL PROTECTED]> [2006-12-03 22:56]:
> The source code below generates an internal compiler error. The error
> is somehow related with to the two initialization of the two constants
> n1 and n2. The exact command-line argumen
--
tbm at cyrius dot com changed:
What|Removed |Added
CC||debian-gcc at lists dot
||debian
--- Comment #1 from brooks at gcc dot gnu dot org 2007-04-20 01:52 ---
This is invalid code, since initialization expressions must be constants, and
the length of an assumed-length string argument is not a constant. Regardless,
we shouldn't be ICE'ing on it.
--
brooks at gcc dot gnu
* Sam Hocevar <[EMAIL PROTECTED]> [2007-04-20 02:52]:
>Do you know how the GCC developers would suggest handling vector
> types in a C structure or C++ object that are only used by functions
> called if AltiVec support was detected at runtime? Because you currently
> cannot do that without "con
To confirm Martin's comment: This is indeed invalid. In Fortran, when a
local variable in a function is initialized in its declaration, that means
that it is initialized only once when the program starts (or effectively
so), and its value is then SAVE'd to subsequent calls of that
function. T
retitle 396292 [fixed in 4.2/4.3] gfortran-4.1: ICE when mistyping NULL() as
NULL
thanks
* Ming Hua <[EMAIL PROTECTED]> [2006-11-22 01:53]:
> I've tested with gcc-snapshot 20061022-1 with the same test case, and it
> seems to be fixed in upstream now.
Yeah, it's fixed in both gcc 4.2 and 4.3. T
On 4/19/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
* Sam Hocevar <[EMAIL PROTECTED]> [2007-04-20 02:52]:
>Do you know how the GCC developers would suggest handling vector
> types in a C structure or C++ object that are only used by functions
> called if AltiVec support was detected at ru
Processing commands for [EMAIL PROTECTED]:
> retitle 396292 [fixed in 4.2/4.3] gfortran-4.1: ICE when mistyping NULL() as
> NULL
Bug#396292: gfortran-4.1: ICE when mistyping NULL() as NULL
Changed Bug title to [fixed in 4.2/4.3] gfortran-4.1: ICE when mistyping NULL()
as NULL from gfortran-4.1:
* Alex Romosan <[EMAIL PROTECTED]> [2007-04-19 17:52]:
> compiling with -gstabs+ and -O2 still causes g++ to crash.
Really? With g++-4.1 4.1.1-21, or which version do you have?
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubsc
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.1.2 4.3.0 |4.1.2 4.2.0 4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639
Hi Martin,
On 19 April 2007 at 16:51, Martin Michlmayr wrote:
| * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-08-15 17:29]:
| > Package: g++-4.1
| > Version: 4.1.1-5
| >
| > I understand that it is fixed in unstable, but as the toolchain is
| > frozen (or being frozen) I just want to make sure e
Dirk,
* Dirk Eddelbuettel <[EMAIL PROTECTED]> [2007-04-19 20:44]:
> No beans. I was just discussing with Kurt Hornik, one of the R Core
> developers, and CRAN maintainers, why building of my RQuantLib /
> r-cran-quantlib takes so long. The issue is not solved as far as I can
> tell. The linking o
Martin Michlmayr <[EMAIL PROTECTED]> writes:
> * Alex Romosan <[EMAIL PROTECTED]> [2007-04-19 17:52]:
>> compiling with -gstabs+ and -O2 still causes g++ to crash.
>
> Really? With g++-4.1 4.1.1-21, or which version do you have?
yes. this is on amd64 with g++ 4.1.1-21. you need to add -gstabs+ t
34 matches
Mail list logo
