Re: FW: RE gcc plans for the lenny cycle

[Ludovic Brenta]

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 reply "Those symbols are
>> for glibc. Why do they have libstdc++ version names? I think it is a gcc 
>> bug. Please open a gcc bug instead."
>> 
>> Does anyone know if such a bug has been filed and if so where?
>
> the upstream gcc-4_1-branch doesn't include the ldbl changes.

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?

-- 
Ludovic Brenta.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FW: RE gcc plans for the lenny cycle

[Matthias Klose]

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.

^^^

> >> That bug is marked as "resolved invalid" with a reply "Those symbols are
> >> for glibc. Why do they have libstdc++ version names? I think it is a gcc 
> >> bug. Please open a gcc bug instead."
> >> 
> >> Does anyone know if such a bug has been filed and if so where?
> >
> > the upstream gcc-4_1-branch doesn't include the ldbl changes.
> 
> 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?

see above. what needs clarifying? if you have any pointers where the
problem actually is, please say so.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Al-Manahel Newsletter List Unsubscription

[munir]

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.

---

You may automatically subscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 



- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FW: RE gcc plans for the lenny cycle

[Peter Green]

>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 issue
that hasn't been rejected by those it was reported to. A quick check
doesn't seem to find anything in the gcc or debian bugtrackers.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Welcome to Al-Manahel Newsletter List

[munir]

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. 

---

You may automatically unsubscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 



- 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug target/28623] [4.1/4.2/4.3 regression] ICE in extract_insn, at recog.c:2077 (nrecognizable insn) [alpha]

[rth at gcc dot gnu dot org]

-- 

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 |
 Status|NEW |ASSIGNED
   Last reconfirmed|-00-00 00:00:00 |2007-04-19 18:18:30
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28623

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#382153: Compiling line

[Debian Bug Tracking System]

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 assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#382153: Compiling line

[Martin Michlmayr]

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 upstream.
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#383251: marked as done (g++-4.1: FTBFS for RQuantLib on i386/testing)

[Debian Bug Tracking System]

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 the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---

Package: g++-4.1
Version: 4.1.1-5
Severity: important

The g++ version that recently entered testing exhibits the same problem I had
been reported to the hppa maintainers -- and which Randolph report upstream
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28620 .

I understand that it is fixed in unstable, but as the toolchain is frozen (or
being frozen) I just want to make sure everyone is on the same page:  the
current 'testing' version of g++ will not cut it for release.

The code below is from the current sources my rquantlib package which I
intend to send to unstable later today. It does build on unstable but fails
on testing showing that testing isn't quite there at the moment.

Hope this helps, Dirk


* Installing *source* package 'RQuantLib' ...
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking for quantlib-config... yes
Building libRcpp.a in RcppSrc...
g++ -I/usr/share/R/include -I/usr/share/R/include  -DUSING_QUANTLIB 
-I/usr/include   -fpic  -g -O2 -c Rcpp.cpp -o Rcpp.o
ar crs libRcpp.a Rcpp.o
checking for Boost development files... yes
checking Boost version... yes
configure: creating ./config.status
config.status: creating src/Makevars
Completed configuration and ready to build.
** libs
g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB 
-I/usr/include -I../RcppSrc -fpic  -g -O2 -c barrier_binary.cpp -o 
barrier_binary.o
g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB 
-I/usr/include -I../RcppSrc -fpic  -g -O2 -c bermudan.cpp -o bermudan.o
g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB 
-I/usr/include -I../RcppSrc -fpic  -g -O2 -c curves.cpp -o curves.o
g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB 
-I/usr/include -I../RcppSrc -fpic  -g -O2 -c discount.cpp -o discount.o
g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB 
-I/usr/include -I../RcppSrc -fpic  -g -O2 -c implieds.cpp -o implieds.o
g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB 
-I/usr/include -I../RcppSrc -fpic  -g -O2 -c utils.cpp -o utils.o
g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB 
-I/usr/include -I../RcppSrc -fpic  -g -O2 -c vanilla.cpp -o vanilla.o
g++ -shared  -o RQuantLib.so barrier_binary.o bermudan.o curves.o discount.o 
implieds.o utils.o vanilla.o -L../RcppSrc -lRcpp -L/usr/lib -lQuantLib-0.3.13   
-L/usr/lib/R/lib -lR
bermudan.o:(.data+0x0): multiple definition of 
`_ZN8QuantLib8McPricerIT_T0_E10minSample_E'
barrier_binary.o:(.data+0x0): first defined here
bermudan.o:(.data+0x4): multiple definition of 
`_ZN8QuantLib12McSimulationIT_T0_E10minSample_E'
barrier_binary.o:(.data+0x4): first defined here
curves.o:(.data+0x0): multiple definition of 
`_ZN8QuantLib8McPricerIT_T0_E10minSample_E'
barrier_binary.o:(.data+0x0): first defined here
curves.o:(.data+0x4): multiple definition of 
`_ZN8QuantLib12McSimulationIT_T0_E10minSample_E'
barrier_binary.o:(.data+0x4): first defined here
discount.o:(.data+0x0): multiple definition of 
`_ZN8QuantLib8McPricerIT_T0_E10minSample_E'
barrier_binary.o:(.data+0x0): first defined here
discount.o:(.data+0x4): multiple definition of 
`_ZN8QuantLib12McSimulationIT_T0_E10minSample_E'
barrier_binary.o:(.data+0x4): first defined here
implieds.o:(.data+0x0): multiple definition of 
`_ZN8QuantLib8McPricerIT_T0_E10minSample_E'
barrier_binary.o:(.data+0x0): first defined here
implieds.o:(.data+0x4): multiple definition of 
`_ZN8QuantLib12McSimulationIT_T0_E10minSample_E'
barrier_binary.o:(.data+0x4): first defined here
utils.o:(.data+0x0): multiple definition of 
`_ZN8QuantLib8McPricerIT_T0_E10minSample_E'
barrier_binary.o:(.data+0x0): first defined here
utils.o:(.data+0x4): multiple definition of 
`_ZN8QuantLib12McSimulationIT_T0_E10minSample_E'
b

[Bug libstdc++/31638] [4.0/4.1/4.2/4.3 Regression] string usage leads to warning with -Wcast-align

[tbm at cyrius dot com]

-- 

tbm at cyrius dot com changed:

   What|Removed |Added

 CC||debian-gcc at lists dot
   ||debian dot org
Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2/4.3 Regression]
   |string usage leads to   |string usage leads to
   |warning with -Wcast-align   |warning with -Wcast-align


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 who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug libstdc++/31638] [4.0/4.1/4.2/4.3 Regression] string usage leads to warning with -Wcast-align

[pinskia at gcc dot gnu dot org]

--- 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 who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: better title

[Debian Bug Tracking System]

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.

> --
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#408918: [powerpc] -maltivec generates AltiVec code when not asked to

[Martin Michlmayr]

* 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 wherever possible".
> 
>However, the following code, which doesn't even include ,
> generates AltiVec code with gcc-4.0 and gcc-4.1:

I asked a GCC developer about this:

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
  instructions, and also enable the use of built-in functions that
  allow more direct access to the AltiVec instruction set.  You may
  also need to set -mabi=altivec to adjust the current ABI with AltiVec
  ABI enhancements." [that's from the docs]
01:11  and it has been this way since at least 4.0.4
01:14  also the reason why memset generates altivec is
  because it is faster than using scalars anyways

-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#412997: gcc-4.1: Segmentation fault compiling linux-source-2.6.18

[Martin Michlmayr]

* 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?
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#396745: regression on amd64 with optimazation enabled

[Martin Michlmayr]

* 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 what version number this
> happened).

Can you still reproduce this problem?  It works for me with g++-4.1
4.1.1-21
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#392054: ginac: FTBFS on arm

[Martin Michlmayr]

* 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 with -O2, using 4.1.1-13+b1 and 4.1.1-16.
> 
> I suspect a temporary problem.

I guess you could trying removing the CXXFLAGS workaround to see if it
compiles.

-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#416819: gcc-4.1: internal compiler error

[Martin Michlmayr]

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 like a charm.
> OK, I can confirm that this doesn't show up with gcc 4.1 from current
> SVN, but shows up with SVN 20061114-r118779 (just before the current
> gcc-4.1 release).  So this bug is fixed in SVN.

For the record, the ICE is tsubst, at cp/pt.c:7226.   A reduced testcase
is below.

-- 
Martin Michlmayr
http://www.cyrius.com/
extern "C"
{
  typedef unsigned int size_t;
  typedef struct
  __sigset_t;
};
extern "C"
{
  typedef int int16_t __attribute__ ((__mode__ (__HI__)));
  typedef int int32_t __attribute__ ((__mode__ (__SI__)));
}
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
template < class FIRST, class SECOND > class Ident
{
};
template < class TYPE > class Less
{
};
template < class NUM, int DIM, class TOL > class Pixel
{
};
typedef Pixel < uint8_t, 1, int32_t > PixelY;
template < class ACCUM_NUM, class PIXEL_NUM, int DIM, class PIXEL =
  Pixel < PIXEL_NUM, DIM, ACCUM_NUM > >class ReferencePixel
{
};
typedef ReferencePixel < uint16_t, uint8_t, 1, PixelY > ReferencePixelY;
template < class REFERENCEPIXEL, class PIXELINDEX,
  class FRAMESIZE > class ReferenceFrame
{
};
typedef ReferenceFrame < ReferencePixelY, int16_t, int32_t > ReferenceFrameY;
template < class INDEX, class SIZE > class Region2D
{
public:class Extent
  {
  };
};
template < class TYPE, size_t SIZES > class Allocator
{
};
template < class KEY, class VALUE, class KEYFN, class PRED > class SkipList
{
private:struct Node
  {
  };
  enum
  {
HEADERCHUNK = 10
  };
public:typedef Allocator < Node, HEADERCHUNK > Allocator;
  static Allocator sm_oNodeAllocator;
};
template < class TYPE, class PRED = Less < TYPE > >class Set
{
public:typedef SkipList < TYPE, TYPE, Ident < TYPE, TYPE >, PRED > Imp;
public:typedef typename Imp::Allocator Allocator;
};
template < class INDEX, class SIZE > class SetRegion2D:public Region2D < INDEX,
  SIZE >
{
private:typedef Region2D < INDEX, SIZE > BaseClass;
public:typedef typename BaseClass::Extent Extent;
  typedef Set < Extent > Extents;
public:typedef typename Extents::Allocator Allocator;
  class FloodFillControl;
};
template < class INDEX, class SIZE > class SetRegion2D < INDEX,
  SIZE >::FloodFillControl
{
private:typedef SetRegion2D < INDEX, SIZE > Region_t;
public:Region_t m_oToDo;
  typedef typename Region_t::Allocator Allocator;
};
template < class PIXEL_NUM, int DIM, class PIXEL_TOL, class PIXELINDEX,
  class FRAMESIZE, PIXELINDEX PGW, PIXELINDEX PGH, class SORTERBITMASK,
  class PIXEL = Pixel < PIXEL_NUM, DIM, PIXEL_TOL >, class REFERENCEPIXEL =
  ReferencePixel < PIXEL_TOL, PIXEL_NUM, DIM, PIXEL >, class REFERENCEFRAME =
  ReferenceFrame < REFERENCEPIXEL, PIXELINDEX,
  FRAMESIZE > >class MotionSearcher
{
  typedef SetRegion2D < PIXELINDEX, FRAMESIZE > Region_t;
  class MatchThrottleFloodFillControl:public Region_t::FloodFillControl
  {
  private:typedef typename Region_t::FloodFillControl BaseClass;
  public:  MatchThrottleFloodFillControl (typename BaseClass::
 Allocator & a_rAllocator =
 Region_t::Extents::Imp::
 sm_oNodeAllocator);
  };
  MatchThrottleFloodFillControl m_oMatchThrottleFloodFillControl;
};
class MotionSearcherY:public MotionSearcher < uint8_t, 1, int32_t, int16_t,
  int32_t, 4, 2, uint16_t, PixelY, ReferencePixelY, ReferenceFrameY >
{
};

Processed: Re: Bug#416819: gcc-4.1: internal compiler error

[Debian Bug Tracking System]

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 error
Changed Bug title to [fixed in SVN] internal compiler error: in tsubst, at 
cp/pt.c:7226 from gcc-4.1: internal compiler error.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#401496: gfortran-4.1 bug / ICE in gfc_conv_constant at fortran-trans-const.c:348

[Debian Bug Tracking System]

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 contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#408918: [powerpc] -maltivec generates AltiVec code when not asked to

[Sam Hocevar]

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
>   instructions, and also enable the use of built-in functions that
>   allow more direct access to the AltiVec instruction set.  You may
>   also need to set -mabi=altivec to adjust the current ABI with AltiVec
>   ABI enhancements." [that's from the docs]

   Thanks, I can certainly live with this not being a bug as long as
it's well known.

   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 "contaminating" each and every object using these
types with AltiVec instructions all over the place.

Regards,
-- 
Sam.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#396745: regression on amd64 with optimazation enabled

[Alex Romosan]

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 along
>> the way (unfortunately i can't remember for what version number this
>> happened).
>
> Can you still reproduce this problem?  It works for me with g++-4.1
> 4.1.1-21

i can compile vamos now, apparently the -gstabs+ option caused the
compilation not to work and it got removed from the Makefiles a few
weeks ago. compiling with -gstabs+ and -O2 still causes g++ to crash.

--alex--

-- 
| I believe the moment is at hand when, by a paranoiac and active |
|  advance of the mind, it will be possible (simultaneously with  |
|  automatism and other passive states) to systematize confusion  |
|  and thus to help to discredit completely the world of reality. |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401496: gfortran-4.1 bug / ICE in gfc_conv_constant at fortran-trans-const.c:348

[Martin Michlmayr]

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 arguments used appear to be irrelevant.
> 
> Gfortran version report and compiler error are in the code comments.

Thanks, I've forwarded this to the GCC folks.  An inital comment I
received was that it's not clear whether that's actually valid code.
"Initialization expressions have to have constant values, and the
length of an assumed-length string argument isn't constant."  But I
don't know anything about Fortran so please don't ask me.

In any case, this issue is now at http://gcc.gnu.org/PR31639

-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len

[tbm at cyrius dot com]

-- 

tbm at cyrius dot com changed:

   What|Removed |Added

 CC||debian-gcc at lists dot
   ||debian dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len

[brooks at gcc dot gnu dot org]

--- 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 dot org changed:

   What|Removed |Added

 CC||brooks at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
  Known to fail||4.1.2 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-04-20 01:52:43
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#408918: [powerpc] -maltivec generates AltiVec code when not asked to

[Martin Michlmayr]

* 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 "contaminating" each and every object using these
> types with AltiVec instructions all over the place.

Andrew, can you comment?
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401496: gfortran-4.1 bug / ICE in gfc_conv_constant at fortran-trans-const.c:348

[Brooks Moses]

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.  Thus, the initialization must be a constant value that does not 
depend on the arguments of the function, because there are no arguments 
when the initial value is computed.


This is quite unlike C, where "int i = 1" just shorthand for "int i; i = 1".

My guess is the original code this was reduced from wouldn't do what you 
want even if it did compile, because of the fact that the initialization is 
only run once and then the final value SAVE'd until the next 
iteration.  This seems to be a fairly common bug.


Regardless, this obviously should be reporting a proper error message 
rather than ICE'ing.  Thanks for forwarding it along!


- Brooks Moses (GFortran maintainer)



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#396292: fixed in gcc-snapshot 20061022-1

[Martin Michlmayr]

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.  The bug is still there in
SVN for 4.1, but I won't report it to the GCC folks as I was told it's
unlikely to get fixed for 4.1.

This bug should be closed when 4.2 is the default compiler.
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#408918: [powerpc] -maltivec generates AltiVec code when not asked to

[Andrew Pinski]

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 runtime? Because you currently
> cannot do that without "contaminating" each and every object using these
> types with AltiVec instructions all over the place.

Andrew, can you comment?


Yes use a seperate file.  This is the same method as required by
MMX/SSE/SSE2 and any option which might change use of the ISA also.

-- Andrew


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#396292: fixed in gcc-snapshot 20061022-1

[Debian Bug Tracking System]

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: ICE when mistyping NULL() as NULL.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#396745: regression on amd64 with optimazation enabled

[Martin Michlmayr]

* 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 "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len

[brooks at gcc dot gnu dot org]

-- 

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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing

[Dirk Eddelbuettel]

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 everyone is on the
| > same page:  the current 'testing' version of g++ will not cut it for
| > release.
| 
| This bug was fixed in 4.1.1-9 afaik, and etch shipped with 4.1.1-21.

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 of complicated / templated C++ code can still take
aaggee --- around 20 minutes on recent hardware, around 28
minutes on my somewhat dated by largeish memory server.

I wouldn't close the bug. But I have too little time for follow-ups to reopen
it, I simply CC the BTS here.

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing

[Martin Michlmayr]

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 of complicated / templated C++ code can still take
> aaggee --- around 20 minutes on recent hardware, around 28
> minutes on my somewhat dated by largeish memory server.

I was talking about the original bug you reported - the multiple
definitions on hppa.

As to the slow linking, I'm afraid there's little that can be done
with a reasonable small testcase.
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#396745: regression on amd64 with optimazation enabled

[Alex Romosan]

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+ to
get the compiler to crash (fro the latest vamos from cvs):

Car.cc: In constructor 'Vamos_Body::Car_Reader::Car_Reader(std::string, 
std::string, Vamos_Body::Car*)':
Car.cc:604: internal compiler error: output_operand: invalid expression as 
operand
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Preprocessed source stored into /tmp/cccRMnPW.out file, please attach this to 
your bugreport.

remove -gstab+ or change -O2 to -O0 and the file compiles just fine.

--alex--

-- 
| I believe the moment is at hand when, by a paranoiac and active |
|  advance of the mind, it will be possible (simultaneously with  |
|  automatism and other passive states) to systematize confusion  |
|  and thus to help to discredit completely the world of reality. |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]