Re: gcc/gsl

On Thu, Nov 14, 2024 at 12:23 PM Patrick Dupre via users < users@lists.fedoraproject.org> wrote: > Hello, > > I am sorry, but I think that I solved the issue by running a make clean > Now the generated code is the same on both machines. > > Probably I have an object from a previous version of gsl

Re: gcc/gsl

> > On Wed, Nov 13, 2024 at 11:21:46PM +0100, Patrick Dupre wrote: > > > Subject: Re: gcc/gsl > > > > > > On Wed, Nov 13, 2024 at 10:50:38PM +0100, Patrick Dupre via users wrote: > > > > > > > > > > > On

Re: gcc/gsl

On Thu, Nov 14, 2024 at 09:25:40AM +0100, Patrick Dupre wrote: > No, I do not use such options Then I don't believe you can get different assembly from the same compiler same source same options. GCC ought to produce the same output reproduceably (unless the source uses __DATE__, __T

Re: gcc/gsl

:46 AM > From: "Michael Hennebry" > To: "Community support for Fedora users" > Subject: Re: gcc/gsl > > On Wed, 13 Nov 2024, Roger Heflin wrote: > > > On Wed, Nov 13, 2024 at 4:25?PM Patrick Dupre wrote: > >> > >>> > >>&g

Re: gcc/gsl

On Wed, Nov 13, 2024 at 3:58 PM Jeffrey Walton wrote: > On Wed, Nov 13, 2024 at 1:33 PM Patrick Dupre via users > wrote: > > > > I am not sure this issue is entirely relevant on this mailing list. > > Maybe you could redirect me. > > > > Which one is the good one? > > Why this behavior? > Some

Re: gcc/gsl

I force a compilation in case of an update of a library like gsl? Thank to every body for the help. > Sent: Thursday, November 14, 2024 at 9:56 AM > From: "Jakub Jelinek" > To: "Patrick Dupre" > Cc: "Community support for Fedora users" , > "

Re: gcc/gsl

On Wed, 13 Nov 2024, Roger Heflin wrote: On Wed, Nov 13, 2024 at 4:25?PM Patrick Dupre wrote: How different are the values? How many significant figures match? 0? 5? relatve difference: 2.7e-8 "noise" ~ 1e-35 values < 2e-23 What significant figure is it of the result? Heavy calc

Re: gcc/gsl

On Wed, Nov 13, 2024 at 4:25 PM Patrick Dupre wrote: > > > > > How different are the values? How many significant figures match? 0? > > 5? > relatve difference: 2.7e-8 > "noise" ~ 1e-35 > values < 2e-23 > What significant figure is it of the result? Heavy calculations are sensitive to th

Re: gcc/gsl

mpiled on 2 different machines. > Both F40 (last update) > gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3) > One > Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz > The other one > Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz > Actually, this happens when I use the gsl library. > gs

Re: gcc/gsl

plication (relatively heavy code), provides different values when > it > is run and compiled on 2 different machines. > Both F40 (last update) > gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3) > One > Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz > The other one > Intel(R) Core(TM) i

Re: gcc/gsl

On Thu, 14 Nov 2024, Stephen Morris wrote:     Just my 2 cents worth. I develop at work in a language called SAS, which is interpretive like Python is. I see the sort of precision issues you are highlighting all the time, and the software vendor has written papers (which I can't lay my hands o

Re: gcc/gsl

On Wed, Nov 13, 2024 at 11:21:46PM +0100, Patrick Dupre wrote: > > Subject: Re: gcc/gsl > > > > On Wed, Nov 13, 2024 at 10:50:38PM +0100, Patrick Dupre via users wrote: > > > > > > > > > On 13 Nov 2024, at 18:33, Patrick Dupre via users > >

Re: gcc/gsl

ame compiler + same source + same command line flags should result in identical assembly. If you are using -march=native or -mcpu=native, you've asked for it, you can then use gcc -march=native -v -S -xc /dev/null -o /dev/null 2>&1 | grep cc1 to print what exact flags does that turn.

Re: gcc/gsl

same application (relatively heavy code), provides different values when it is run and compiled on 2 different machines. Both F40 (last update) gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3) One Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz The other one Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz Actually, this

Re: gcc/gsl

sure this issue is entirely relevant on this mailing list. > > Maybe you could redirect me. > > > > The same application (relatively heavy code), provides different values > > when it > > is run and compiled on 2 different machines. > > Both F40 (last update) &g

Re: gcc/gsl

> Subject: Re: gcc/gsl > > On Wed, Nov 13, 2024 at 10:50:38PM +0100, Patrick Dupre via users wrote: > > > > > > > On 13 Nov 2024, at 18:33, Patrick Dupre via users > > > > wrote: > > > > > > > > Why this behavior? > > &g

Re: gcc/gsl

> Sent: Wednesday, November 13, 2024 at 8:58 PM > From: "Jeffrey Walton" > To: "Community support for Fedora users" > Cc: "Patrick Dupre" > Subject: Re: gcc/gsl > > On Wed, Nov 13, 2024 at 1:33 PM Patrick Dupre via users > wrote: > &g

Re: gcc/gsl

the code is run. Is there a way to specify the architecture i7 or i5 ? > > Might be compiler defaults are different. Do you have config for gcc in $HOME > somewhere? No > > Try creating a new user on both machines and see how if the problem > respoduces. > > Barry > &

Re: gcc/gsl

> On 13 Nov 2024, at 18:33, Patrick Dupre via users > wrote: > > Why this behavior? Do both versions produce the same results when copied to the other machine? Might be compiler defaults are different. Do you have config for gcc in $HOME somewhere? Try creating a new user on b

Re: gcc/gsl

> Sent: Wednesday, November 13, 2024 at 8:11 PM > From: "home user via users" > To: users@lists.fedoraproject.org > Cc: "home user" > Subject: Re: gcc/gsl > > On 11/13/24 11:32 AM, Patrick Dupre via users wrote: > > Hello, > > > > I

Re: gcc/gsl

(last update) gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3) One Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz The other one Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz Actually, this happens when I use the gsl library. gsl-devel-2.7.1-8.fc40.x86_64 for integration (gsl_integration_cquad). Before integration, the

gcc/gsl

Hello, I am not sure this issue is entirely relevant on this mailing list. Maybe you could redirect me. The same application (relatively heavy code), provides different values when it is run and compiled on 2 different machines. Both F40 (last update) gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3

Re: compat-gcc-34-g77

On 1/13/22 13:00, Patrick Dupre wrote: I had to remove compat-gcc-34-g77 for (compat-gcc-34-g77-3.4.6-46) to be able to update the last update. How can I replace it? That is incredibly old, there hasn't been a successful build of that since 2018. Since you had to remove it to update,

compat-gcc-34-g77

Hello, I had to remove compat-gcc-34-g77 for (compat-gcc-34-g77-3.4.6-46) to be able to update the last update. How can I replace it? Thanks === Patrick DUPRÉ | | email: pdu...@gmx.com

Re: aarch64 mock gcc/annobin errors

PM dependencies are for? This is the exact problems RPM dependencies are designed to solve. If gcc has a dependency on a specific version of annobin, it should require it. In case of weak dependencies, a declared conflict would, at least, uninstall the incompatible

Re: aarch64 mock gcc/annobin errors

Sam Varshavchik wrote: > Todd Zullinger writes: >> Karma for the annobin release would likely be appreciated by >> the maintainer(s) and anyone else who's running into this >> problem, if you are able to test and confirm it fixes the >> issue(s). :) >> >> ¹ https://bodhi.fedoraproject.org/updates/

Re: aarch64 mock gcc/annobin errors

Todd Zullinger writes: Jerry James wrote: > On Mon, Aug 3, 2020 at 4:25 PM Sam Varshavchik wrote: >> I'm running an F32 aarch64 guest qemu VM on an x86_64 F32 host, and, in that >> VM, I attempted to build something fairly simple via mock. This is my reward: >&

Re: aarch64 mock gcc/annobin errors

Jerry James wrote: > On Mon, Aug 3, 2020 at 4:25 PM Sam Varshavchik wrote: >> I'm running an F32 aarch64 guest qemu VM on an x86_64 F32 host, and, in that >> VM, I attempted to build something fairly simple via mock. This is my reward: >> >> configure:3590: gcc -

Re: aarch64 mock gcc/annobin errors

On Mon, Aug 3, 2020 at 4:25 PM Sam Varshavchik wrote: > I'm running an F32 aarch64 guest qemu VM on an x86_64 F32 host, and, in that > VM, I attempted to build something fairly simple via mock. This is my reward: > > configure:3590: gcc -O2 -g -pipe -Wall -Werror=fo

aarch64 mock gcc/annobin errors

I'm running an F32 aarch64 guest qemu VM on an x86_64 F32 host, and, in that VM, I attempted to build something fairly simple via mock. This is my reward: configure:3590: gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,- D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -f

Kernel gcc mismatch?

Am I misunderstanding something? I'm trying to update my local NVidia binary driver for the latest couple of kernels (5.7.10-201.fc32.x86_64 and later), but it's failing to build because: *** Failed CC version check. Bailing out! *** Recent kernels are still all being buil

Re: Old GCC versions

On 2020-04-19 10:46, Hiisi wrote: > On Sat, Apr 18, 2020 at 1:07 PM Samuel Sieb wrote: >> I deleted the original email, so I'm replying to this one. >> Can't you get an already compiled boost 1.41 from an old Fedora or >> CentOS version and use that? >>

Re: Old GCC versions

On Sat, Apr 18, 2020 at 1:07 PM Samuel Sieb wrote: > > I deleted the original email, so I'm replying to this one. > Can't you get an already compiled boost 1.41 from an old Fedora or > CentOS version and use that? > ___ Where would I get that? I have dow

Re: Old GCC versions

On 4/18/20 6:12 AM, Richard Shaw wrote: On Sat, Apr 18, 2020 at 12:16 AM Hiisi > wrote: I need it to compile boost 1.41. Some old project depends on it. Thank you! I deleted the original email, so I'm replying to this one. Can't you get an already compil

Re: Old GCC versions

On Sat, 18 Apr 2020 at 02:01, Hiisi wrote: > Hello, list! > Back in the day, Fedora had compat-gcc in repos. I can't find it any > longer. How do I install older versions of GCCC now? Say, I need GCC > 4.6. What's the best way of getting it on Fedora 31? > Are you build

Re: Old GCC versions

On Sat, Apr 18, 2020 at 12:16 AM Hiisi wrote: > > I need it to compile boost 1.41. Some old project depends on it. > Thank you! > You could also check CentOS versions... CentOS 7 has 4.8.5 if that's close enough or CentOS 6 has 4.4.7. Thanks, Richard ___

Re: Old GCC versions

On Sat, Apr 18, 2020 at 1:10 AM Ed Greshko wrote: > > Well, GCC 4.6 is quite old. Looks as if it last came with F15/F16 in 2011. > > If I *really* needed to use that version I would create a Virtual Machine > running that older > version of Fedora and use it in the VM.

Re: Old GCC versions

On 2020-04-18 13:01, Hiisi wrote: > Back in the day, Fedora had compat-gcc in repos. I can't find it any > longer. How do I install older versions of GCCC now? Say, I need GCC > 4.6. What's the best way of getting it on Fedora 31? Well, GCC 4.6 is quite old.  Looks as if it las

Old GCC versions

Hello, list! Back in the day, Fedora had compat-gcc in repos. I can't find it any longer. How do I install older versions of GCCC now? Say, I need GCC 4.6. What's the best way of getting it on Fedora 31? -- Hiisi. Registered Linux User #487982. Be counted at: https://linuxcounter.net/

Re: gcc/sort

On Thu, Mar 05, 2020 at 02:22:03PM +0100, Patrick Dupre wrote: > > After sorting the list is: > > 0 -5.5e-06 3 25 56 88 100 > > -5.5e-06 2 3 25 56 88 100 > > > #include > #include > > double values[] = { 88, 56, 100, 0.0, 25, 3, -0.55e-5 }; > double values2 [] = { 88, 56, 100, 2, 25, 3, -0.

Re: gcc/sort

your function indeed needs to return an int, but the computation doesn't look like an int. you will need to compare, and return one of -1,0,1, not subtract the values. On 3/5/20 8:22 AM, Patrick Dupre wrote: Hello, In this example, if I put a 0, the sorting is wrong which must be standard c

gcc/sort

Hello, In this example, if I put a 0, the sorting is wrong which must be standard c > After sorting the list is: > 0 -5.5e-06 3 25 56 88 100 > -5.5e-06 2 3 25 56 88 100 #include #include double values[] = { 88, 56, 100, 0.0, 25, 3, -0.55e-5 }; double values2 [] = { 88, 56, 100, 2, 25, 3,

Re: gcc vs gfortran

OK, it is fixed, I compiled with the option -ff2c This was an error > > in C > > > > double complex a, b, z > > int lnchf ip > > out = conhyp_ (&a, &b, &z, &lnchf, &ip) ; > > The above isn't very close to C, e.g. ; is missing at the end of first line, > , and ; are missing around ip on the second

Re: gcc vs gfortran

On Fri, Dec 06, 2019 at 06:12:28PM +0100, Patrick Dupre wrote: > Actually, this is what I have: > > in C > > double complex a, b, z > int lnchf ip > out = conhyp_ (&a, &b, &z, &lnchf, &ip) ; The above isn't very close to C, e.g. ; is missing at the end of first line, , and ; are missing around i

Re: gcc vs gfortran

On Fri, 6 Dec 2019 18:12:28 +0100 Patrick Dupre wrote: > out = conhyp_ (&a, &b, &z, &lnchf, &ip) ; I don't know what "out" is, but if the return type of a fortran function is some struct-like object (which complex might qualify as), I believe there is a hidden first argument that is a pointer to

Re: gcc vs gfortran

Actually, this is what I have: in C double complex a, b, z int lnchf ip out = conhyp_ (&a, &b, &z, &lnchf, &ip) ; In Fortran: FUNCTION CONHYP (A,B,Z,LNCHF,IP) INTEGER LNCHF,IP COMPLEX*16 CHGF,A,B,Z,CONHYP And what I get is A= b, B=z (the other values are wrong) It means that

Re: gcc vs gfortran

Typo?  From f2c.h:   typedef struct { doublereal r, i; } doublecomplex;     This is f2c, I tried to avoid to use this old package now there is is a complex librairy in gcc which has all the functions for the complex, In my opinion, f2c is only recommanded when you use the converter f2c Ac

Re: gcc vs gfortran

On Fri, 6 Dec 2019 at 06:31, Patrick Dupre wrote: > Hello, > > Several times I called a fortran routine from a c program, it was OK. > I am trying to do the same with complex numbers in the call. > Is it a problem ? > in c, I use double complex > in f95, I use COMPLEX*16 > > Typo? From f2c.h

Re: gcc vs gfortran

On Fri, 6 Dec 2019 11:30:14 +0100 Patrick Dupre wrote: > in c, I use double complex > in f95, I use COMPLEX*16 Never heard of double complex in c. Fortran passes all arguments by reference, so a fortran routine that has a complex*16 arg probably needs something like this in C struct c16 { do

gcc vs gfortran

Hello, Several times I called a fortran routine from a c program, it was OK. I am trying to do the same with complex numbers in the call. Is it a problem ? in c, I use double complex in f95, I use COMPLEX*16 my fortran cade translated to c by f2c does not work I get a segmentation fault: are the

get -m32 flag to work in gcc?

Just wondering what the minimal packages are I need to install to be able to build 32 bit programs in 64 bit fedora 30. Is glibc-devel.i686 the only one, or are other bits and pieces required? ___ users mailing list -- users@lists.fedoraproject.org To un

Re: Can I install gcc-8 from rawhide on F27?

On Fri, 30 Mar 2018, Neal Becker wrote: There's a bug in gcc-7.3.1 that causes a crash on some code I need. Is it safe to install gcc-8 from rawhide on F27? You can try installing the gcc package from rawhide (or probably better the F28 repository, currently at beta), but the usual pr

Re: Can I install gcc-8 from rawhide on F27?

On 30 March 2018 at 07:48, Neal Becker wrote: > There's a bug in gcc-7.3.1 that causes a crash on some code I need. Is it > safe to install gcc-8 from rawhide on F27? > Is there a patch for the bug? You may be better off waiting for an updated gcc-7 as gcc-8 probabl

Re: Can I install gcc-8 from rawhide on F27?

On Fri, 2018-03-30 at 06:48 -0400, Neal Becker wrote: > There's a bug in gcc-7.3.1 that causes a crash on some code I need. Is it > safe to install gcc-8 from rawhide on F27? That would be a question for the Fedora Test list. poc ___ us

Can I install gcc-8 from rawhide on F27?

There's a bug in gcc-7.3.1 that causes a crash on some code I need. Is it safe to install gcc-8 from rawhide on F27? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: dnf installs gcc 7.3.1 but gcc.gnu.org provides only 7.3.0

On Sat, Feb 10, 2018 at 10:26:23AM +0100, Frédéric wrote: > > 7.3.1 is a version used for 7 branch snapshots in between 7.3 and 7.4 > > releases, which is what we are shipping in Fedora. The version also > > includes the date when the snapshot has been made. > > You mean that all snapshots are ca

Re: dnf installs gcc 7.3.1 but gcc.gnu.org provides only 7.3.0

> 7.3.1 is a version used for 7 branch snapshots in between 7.3 and 7.4 > releases, which is what we are shipping in Fedora. The version also > includes the date when the snapshot has been made. You mean that all snapshots are called 7.3.1, only the date differs? F __

Re: dnf installs gcc 7.3.1 but gcc.gnu.org provides only 7.3.0

On Fri, Feb 09, 2018 at 09:39:55PM +0100, Frédéric wrote: > How is it possible that dnf installs gcc 7.3.1 when only 7.3.0 exists > on gcc.gnu.org? Read https://www.gnu.org/software/gcc/develop.html "Version Numbering Scheme for GCC 5 and Up" part? 7.3.1 is a version used for 7

dnf installs gcc 7.3.1 but gcc.gnu.org provides only 7.3.0

How is it possible that dnf installs gcc 7.3.1 when only 7.3.0 exists on gcc.gnu.org? F ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: gcc unsupported version

On 09/21/2017 06:24 AM, Hiisi T wrote: While I have gcc-compat installed and configured the soft to use gcc34 I don't understand why am I getting this? Any advice please? Specifically, how did you configure the process to use gcc34? ___

gcc unsupported version

0/bin/../ targets/x86_64-linux/include/cuda_runtime.h:78:0, from :0: /usr/local/cuda-8.0/bin/../targets/x86_64-linux/include/host_config.h:119:2: error: #error -- unsupported GNU version! gcc versions later than 5 are not supported! #error -- unsupported GNU version! gcc versions later t

libstdc++ and compat-gcc-34-c++

Hello, I tried to install compat-gcc-34-c++ (on f26) But I get Last metadata expiration check: 0:06:48 ago on Mon 24 Jul 2017 05:43:38 PM CEST. Error: Problem: conflicting requests - nothing provides libstdc++ < 7.0.0 needed by compat-gcc-34-c++-3.4.6-41.fc26.x86_64 rpm -q libs

Re: gcc

On 04/22/2017 10:57 AM, Patrick Dupre wrote: Hello, I would like that gcc generates an error (and not a warning), when there is a call to a non predeclared function. How can I do it? You might find that using the switches -Wall -Wextra are useful when you're trying to write code that

Re: gcc

day, April 22, 2017 at 8:05 PM > From: "Jakub Jelinek" > To: "Community support for Fedora users" > Subject: Re: gcc > > On Sat, Apr 22, 2017 at 07:57:17PM +0200, Patrick Dupre wrote: > > Hello, > > > > I would like that gcc generates an error

Re: gcc

On Sat, Apr 22, 2017 at 07:57:17PM +0200, Patrick Dupre wrote: > Hello, > > I would like that gcc generates an error (and not a warning), > when there is a call to a non predeclared function. In C? -Werror=implicit-function-declaration or -pedantic-errors (if in c99 or later mode,

gcc

Hello, I would like that gcc generates an error (and not a warning), when there is a call to a non predeclared function. How can I do it? Thank. === Patrick DUPRÉ | | email: pdu...@gmx.com

Re: gcc warning and errors

On Mon, Jan 09, 2017 at 10:47:30AM +0100, Patrick Dupre wrote: > I have a Makefile (gcc) generating a lot of warnings. Hence, it is difficult > to see the error message. > How can I have the gcc error message in red? GCC does this by default if stderr is a terminal (capable of displayi

gcc warning and errors

Hello, I have a Makefile (gcc) generating a lot of warnings. Hence, it is difficult to see the error message. How can I have the gcc error message in red? Thank. === Patrick DUPRÉ | | email

Re: gcc 4.9

R__ > 9) >> >> #error -- unsupported GNU version! gcc versions later than 4.9 are not >> supported! >> >> #endif /* __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 9) */ >> > [...] > > http://docs.nvidia.com/cuda/cuda-getting-sta

Re: gcc 4.9

On Tue, 2 Aug 2016 02:04:13 + (UTC) "Amadeus W.M." wrote: [snip] > > That's what I thought too, but try this: > > // Compile as > // g++ -o gnuc gnuc.cpp > // then as > // g++ --std=gnu++11 -o gnuc gnuc.cpp > > #include > #include > > using namespace std; > >

Re: gcc 4.9

uot; wrote: >> > [snip] >> >> Unfortunately nothing worked. >> >> >> >> >> >> In the cuda distribution there is a host_config.h file which >> >> contains the following lines: >> >> >> >> #if _

Re: gcc 4.9

> >> > >> > >> In the cuda distribution there is a host_config.h file which > >> contains the following lines: > >> > >> #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 9) > >> > >> #error -- unsupported

Re: gcc 4.9

> the following lines: >> >> #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 9) >> >> #error -- unsupported GNU version! gcc versions later than 4.9 are not >> supported! >> >> #endif /* __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MIN

Re: gcc 4.9

On 08/01/2016 06:30 AM, Amadeus W.M. wrote: > Third, I was only able to find a Fedora-21-Live image and I created a > virtual box from it, booted that up and installed to disk. But, as one > might expect, gnome-boxes only knew about the Live VM, and each time I > would boot it up, it would boot

Re: gcc 4.9

On Mon, 1 Aug 2016 04:30:03 + (UTC) "Amadeus W.M." wrote: > Third, I was only able to find a Fedora-21-Live image and I created a > virtual box from it, booted that up and installed to disk. But, as > one might expect, gnome-boxes only knew about the Live VM, and each > time I would boot it

Re: gcc 4.9

INOR__ > 9) > > #error -- unsupported GNU version! gcc versions later than 4.9 are > not supported! > > #endif /* __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 9) */ > > > This checks the version of the compiler and triggers an error with > gcc-6.

Re: gcc 4.9

On 01.08.2016 06:30, Amadeus W.M. wrote: [...] > In the cuda distribution there is a host_config.h file which contains the > following lines: > > #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 9) > > #error -- unsupported GNU version! gcc versions lat

Re: gcc 4.9

gt; >> > > IIRC the cuda installer lets you override the check for the gcc >> > > version (try running the installer ".run" file with the "--help" >> > > option). >> > > >> > > >> > > Note that overrides th

Re: gcc 4.9

, Rick Stevens wrote: > > >    > > > > > > > > IIRC the cuda installer lets you override the check for the gcc > > > > version (try running the installer ".run" file with the " > > > > --help" > > > > option). > &

Re: gcc 4.9

On Sun, 31 Jul 2016 11:06:18 -0700 stan wrote: > On Sun, 31 Jul 2016 17:24:16 + (UTC) > "Amadeus W.M." wrote: > > > On Sun, 31 Jul 2016 16:36:10 +, Rick Stevens wrote: > > > > > IIRC the cuda installer lets you override the check for the gcc

Re: gcc 4.9

On Sun, 31 Jul 2016 17:24:16 + (UTC) "Amadeus W.M." wrote: > On Sun, 31 Jul 2016 16:36:10 +, Rick Stevens wrote: > > > IIRC the cuda installer lets you override the check for the gcc > > version (try running the installer ".run" file with the &q

Re: gcc 4.9

On Sun, 31 Jul 2016 16:36:10 +, Rick Stevens wrote: > IIRC the cuda installer lets you override the check for the gcc version > (try running the installer ".run" file with the "--help" option). > > > Note that overrides the gcc check during instal

Re: gcc 4.9

IIRC the cuda installer lets you override the check for the gcc version (try running the installer ".run" file with the "--help" option). Note that overrides the gcc check during installation--there's no guarantee that compilations will work. Cuda uses certain gcc fla

gcc 4.9

I want to do some parallel programming on my nvidia GPU, and for that I need cuda. The latest is cuda 7.5 and that requires gcc 4.9. I installed cuda on my machine, but little did I know that fedora 24, which I recently installed, came with gcc 6.1. I wasn't able to compile any of the

Re: F20 install compat-gcc-34-g77 conflicts

On Mon, 6 Jan 2014, Stephen Berg (Contractor) wrote: Trying to get compat-gcc-34-g77 installed for one of my users that is trying out F20 and it's failing. Transaction check error: file /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/crtbegin.o from install of compat-gcc-34-3.4.6-29.fc19.x

Re: F20 install compat-gcc-34-g77 conflicts (worked around)

On Mon, Jan 06, 2014 at 08:12:14AM -0600, Ranjan Maitra wrote: > On Mon, 6 Jan 2014 07:36:13 -0600 "Stephen Berg (Contractor)" > wrote: > > > On 01/06/2014 07:15 AM, Ed Greshko wrote: > > > On 01/06/14 21:00, Stephen Berg (Contractor) wrote: > > >>

Re: F20 install compat-gcc-34-g77 conflicts (worked around)

On Mon, 6 Jan 2014 07:36:13 -0600 "Stephen Berg (Contractor)" wrote: > On 01/06/2014 07:15 AM, Ed Greshko wrote: > > On 01/06/14 21:00, Stephen Berg (Contractor) wrote: > >> Trying to get compat-gcc-34-g77 installed for one of my users that is > >

Re: F20 install compat-gcc-34-g77 conflicts (worked around)

On 01/06/2014 07:15 AM, Ed Greshko wrote: On 01/06/14 21:00, Stephen Berg (Contractor) wrote: Trying to get compat-gcc-34-g77 installed for one of my users that is trying out F20 and it's failing. Transaction check error: file /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/crtbegin.o

Re: F20 install compat-gcc-34-g77 conflicts

On 01/06/14 21:00, Stephen Berg (Contractor) wrote: > Trying to get compat-gcc-34-g77 installed for one of my users that is trying > out F20 and it's failing. > > Transaction check error: > file /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/crtbegin.o from install of > comp

F20 install compat-gcc-34-g77 conflicts

Trying to get compat-gcc-34-g77 installed for one of my users that is trying out F20 and it's failing. Transaction check error: file /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/crtbegin.o from install of compat-gcc-34-3.4.6-29.fc19.x86_64 conflicts with file from package gcc-4.8.2-7

Re: GCC issue

Hi Andrew and Mamoru, On Tue, Oct 08, 2013 at 08:57:29AM +0100, Andrew Haley wrote: > On 10/08/2013 08:30 AM, Suvayu Ali wrote: > > Okay, found my problem. I have to explicitly choose C++11. I did not > > realise C++11 was not the default. Any ideas why? > > We (GCC

Re: GCC issue

On 10/08/2013 08:30 AM, Suvayu Ali wrote: > Okay, found my problem. I have to explicitly choose C++11. I did not > realise C++11 was not the default. Any ideas why? We (GCC maintainers) tend to change defaults when it's what the majority of users want. For most people C++

RE: Re: GCC issue

est_to_string.cc: In function ‘int main()’: > > test_to_string.cc:7:28: error: ‘to_string’ is not a member of ‘std’ > > std::cout realise C++11 was not the default. Any ideas why? Because (gcc says) c++11 support in gcc is still experimental, see: http://gcc.gnu.org/projects/cxx0x.htm

Re: GCC issue

On Tue, Oct 08, 2013 at 09:20:58AM +0200, Suvayu Ali wrote: > > I have a strange problem. When I try to use std::to_string() I get the > following error: > > $ g++ -o test_to_string test_to_string.cc > test_to_string.cc: In function ‘int main()’: > test_to_string.cc:7:28: error: ‘to_string

GCC issue

} --8<--8<-- A quick search does not point me to any error on my part[1]. Is there a bug in Fedora GCC? Thanks for any thoughts. [1] <http://en.cppreference.com/w/cpp/string/basic_string/to_string> -- Suvayu Open source is the future. It sets us free. --

Re: possible gcc bug?

On 07/13/2012 12:26 PM, Skunk Worx wrote: Hi, I have an EPEL 6, 64 bit system (SL6) and an fc17 64 bit system. My shared library uses boost, code synthesis xsd cxx-tree, and xerces-c. There may be a bug in gcc that prevents this shared library from being dlclose()'ed properly :

Re: possible gcc bug?

On 07/14/2012 02:42 AM, Andrew Haley wrote: On 07/13/2012 08:26 PM, Skunk Worx wrote: Do you think this is a "won't fix" or "not a bug"? You've already had the correct answer from Ian Taylor on the gcc-help list. You're not going to get anything more auth

Re: possible gcc bug?

On 07/13/2012 08:26 PM, Skunk Worx wrote: > Do you think this is a "won't fix" or "not a bug"? You've already had the correct answer from Ian Taylor on the gcc-help list. You're not going to get anything more authoritative here. Andrew. -- users mailing

possible gcc bug?

Hi, I have an EPEL 6, 64 bit system (SL6) and an fc17 64 bit system. My shared library uses boost, code synthesis xsd cxx-tree, and xerces-c. There may be a bug in gcc that prevents this shared library from being dlclose()'ed properly : http://gcc.gnu.org/ml/gcc-help/2011-05/msg00403

Re: still having update issues with gcc (solved)

On Mon, 2012-03-26 at 20:42 +0100, James Wilkinson wrote: > les wrote: > > HI, everyone, > > I am still having the update issue with gcc. I will follow this message > > with the error received from "yum update". > > > > Also my processor

  1   2   >