https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #61 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #60)
> r242780 works.
>
> With both r243586 and r244391, plus the patch for r245191
> applied, I got numerous failures in the test suite.
>
> Apparently, something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #60 from Thomas Koenig ---
r242780 works.
With both r243586 and r244391, plus the patch for r245191
applied, I got numerous failures in the test suite.
Apparently, something else was wrong for some time, which
blocks the attempt at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #59 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #58)
> (In reply to Thomas Koenig from comment #57)
> > And here comes the first problem...
> >
> > Running with rev 243584 (as a bisection) results in
> > very
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #58 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #57)
> And here comes the first problem...
>
> Running with rev 243584 (as a bisection) results in
> very many failed tests like
*** Error in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #57 from Thomas Koenig ---
And here comes the first problem...
Running with rev 243584 (as a bisection) results in
very many failed tests like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #56 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #55)
> (In reply to Jürgen Reuter from comment #52)
> > I tried again to make a more reduced test case, but I couldn't really
> > separate it from library structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #55 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #52)
> I tried again to make a more reduced test case, but I couldn't really
> separate it from library structure of our code. Do you think you can work
> with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #54 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #53)
> (In reply to Jürgen Reuter from comment #51)
> > (In reply to Thomas Koenig from comment #50)
> > > (In reply to Jürgen Reuter from comment #48)
> > > > (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #53 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #51)
> (In reply to Thomas Koenig from comment #50)
> > (In reply to Jürgen Reuter from comment #48)
> > > (In reply to Thomas Koenig from comment #47)
> > > > I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #52 from Jürgen Reuter ---
I tried again to make a more reduced test case, but I couldn't really separate
it from library structure of our code. Do you think you can work with the given
test case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #51 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #50)
> (In reply to Jürgen Reuter from comment #48)
> > (In reply to Thomas Koenig from comment #47)
> > > I'll try some bisection.
> >
> > Did you get the full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #50 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #48)
> (In reply to Thomas Koenig from comment #47)
> > I'll try some bisection.
>
> Did you get the full tarball running on an x86_64?
Yes, at least up to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #49 from Thomas Koenig ---
(In reply to Bijan Chokoufe from comment #39)
> Configure fails when I set FCFLAGS='-m32' with
> **
> configure: error: Fortran compiler does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #48 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #47)
> I'll try some bisection.
Did you get the full tarball running on an x86_64?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #47 from Thomas Koenig ---
I'll try some bisection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #46 from Thomas Koenig ---
gcc version 7.0.1 20170227 (experimental) (GCC)
also fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #45 from Jürgen Reuter ---
Looking into my backups, it seems that the revision 241975 from Nov 8, 2016 was
still working without the `volatile` hack. Then I upgraded in early February to
revision 245197 where the problem is already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #44 from Bijan Chokoufe ---
Created attachment 41222
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41222=edit
Diff of generalized assembly using extended precision with and without volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #43 from Bijan Chokoufe ---
I actually made the same mistake when generating the diffs. I attach the
correct diff when --with-precision=extended is given to configure. Similar
contents though, as far as I can judge. Strangely, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #42 from Thomas Koenig ---
Using ./configure --with-precision=extended
results in
checking whether gfortran supports c_float128 (a gfortran extension)... yes
checking the requested floating point precision... extended
configure:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #41 from Thomas Koenig ---
Created attachment 41221
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41221=edit
Config log for PowerPC
Here's the config.log for PowerPC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #40 from Dominique d'Humieres ---
> You have to
>
> ./configure --with-precision=extended
I don't think this works on powerpc: no 80-bit fp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #39 from Bijan Chokoufe ---
(In reply to Thomas Koenig from comment #38)
> (In reply to Bijan Chokoufe from comment #37)
> > Concerning your PowerPC compilation: Have you set FCLAGS yourself
>
> No, I didn't.; I just ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #38 from Thomas Koenig ---
(In reply to Bijan Chokoufe from comment #37)
> (In reply to Thomas Koenig from comment #35)
>
> > [tkoenig@gcc1-power7 shower]$ pwd
> > /home/tkoenig/whizard-2.4.1/src/shower
> > [tkoenig@gcc1-power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #37 from Bijan Chokoufe ---
(In reply to Thomas Koenig from comment #35)
> [tkoenig@gcc1-power7 shower]$ pwd
> /home/tkoenig/whizard-2.4.1/src/shower
> [tkoenig@gcc1-power7 shower]$ grep -i volatile *.f90
> [tkoenig@gcc1-power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #36 from Bijan Chokoufe ---
Created attachment 41219
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41219=edit
Diff of generalized assembly with and without volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #35 from Thomas Koenig ---
(In reply to Bijan Chokoufe from comment #34)
> Does mlm_matching_isr.run also work if you remove all uses of volatile in
> src/shower/*f90?
Yes, the test was with the original tarball mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #34 from Bijan Chokoufe ---
(In reply to Thomas Koenig from comment #32)
> Running your testsuite on powerpc64-unknown-linux-gnu
> with a current trunk and "make -k check" gets me
>
> PASS: mlm_matching_isr.run
>
> but also a few
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #33 from Thomas Koenig ---
> Could you tell me how just to run a single testcase?
Well, I figured that one out.
Quite interesting, a different error with valgrind:
| Events: event normalization mode '1'
==49974== Source and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #32 from Thomas Koenig ---
Running your testsuite on powerpc64-unknown-linux-gnu
with a current trunk and "make -k check" gets me
PASS: mlm_matching_isr.run
but also a few more failures:
FAIL: bloch_vectors.run
FAIL: processes.run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #31 from Thomas Koenig ---
(In reply to Bijan Chokoufe from comment #30)
`bzip2 -d diff.bz2`) as I have no idea what to look for:
> https://cloud.bijancn.de/index.php/s/ta2XMIVWhTUGAvX
Thanks. I looked, but didn't find anything...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #30 from Bijan Chokoufe ---
> Could you maybe do the following:
>
> - Use your normal sources
>
> - Change the compilation options to add -fdump-tree-all to the relevant
> file
>
> - Copy all the generated xxx.f90.whatever files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #29 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #24)
> Actually, the volatile attribute conflicts with the intent(in) of the final
> variable. But making the function result variable 'integral' volatile, does
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #28 from Jakub Jelinek ---
(In reply to Jürgen Reuter from comment #27)
> Well, the valgrind output actually exactly that the comparison is optimized
> away.
> I actually would have to regenerate all the debug output, but the point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #27 from Jürgen Reuter ---
Well, the valgrind output actually exactly that the comparison is optimized
away.
I actually would have to regenerate all the debug output, but the point is that
for the first appearance in the random seed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #25 from Dominique d'Humieres ---
AFAICT the IF is already optimized away at r240458. Note that r240271 cannot
use the modules generated by later revisions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #24 from Jürgen Reuter ---
Actually, the volatile attribute conflicts with the intent(in) of the final
variable. But making the function result variable 'integral' volatile, does the
job. Thanks for the suggestion. And sorry again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #23 from Steve Kargl ---
On Thu, Feb 09, 2017 at 10:42:08AM +, bijan at chokoufe dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
>
> --- Comment #19 from Bijan Chokoufe ---
> So in the build with '-O2 -g'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #22 from Dominique d'Humieres ---
> With make -k you continue irrespective of the fact that some targets could
> not have made.
Without '-k' 'make check' stops at
make[5]: *** No rule to make target `test_omega95.f90', needed by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #21 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #20)
> Is this really a regression?
>
> I have run 'make check -k' with gfortran 5.4.0, 6.3.0, and a patched trunk
> at revision r245279. I see respectively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #20 from Dominique d'Humieres ---
Is this really a regression?
I have run 'make check -k' with gfortran 5.4.0, 6.3.0, and a patched trunk at
revision r245279. I see respectively 258, 259, and 199 FAILs, and
mlm_matching_isr is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #19 from Bijan Chokoufe ---
So in the build with '-O2 -g' (default), valgrind tells us
==8214== Conditional jump or move depends on uninitialised value(s)
==8214==at 0x5300201:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
Bijan Chokoufe changed:
What|Removed |Added
CC||bijan at chokoufe dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #17 from Jürgen Reuter ---
(In reply to Jerry DeLisle from comment #16)
> (In reply to Jürgen Reuter from comment #15)
> > With -fcheck=all nothing is flagged, but the test works as expected, as well
> > as if I (independently from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #15 from Jürgen Reuter ---
With -fcheck=all nothing is flagged, but the test works as expected, as well
as if I (independently from the fcheck) compile everything with -fno-inline .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #14 from Steve Kargl ---
On Wed, Feb 08, 2017 at 09:30:45PM +, juergen.reuter at desy dot de wrote:
> >
> > > Indeed, it looks as if kind=10 would be real128, but as you said this
> > > is wrong and was fixed by you (I guess it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #13 from Jürgen Reuter ---
(In reply to Steve Kargl from comment #12)
> On Wed, Feb 08, 2017 at 08:39:43PM +, juergen.reuter at desy dot de
> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
> >
> > --- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #12 from Steve Kargl ---
On Wed, Feb 08, 2017 at 08:39:43PM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
>
> --- Comment #11 from Jürgen Reuter ---
> (In reply to Steve Kargl from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #11 from Jürgen Reuter ---
(In reply to Steve Kargl from comment #10)
> On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de
> which may lead to conforming code suddening becoming nonconforming
> due to violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #10 from Steve Kargl ---
On Wed, Feb 08, 2017 at 07:32:53PM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
>
> --- Comment #8 from Jürgen Reuter ---
> We are defining a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #9 from Jürgen Reuter ---
(In reply to kargl from comment #7)
> (In reply to Jürgen Reuter from comment #6)
> > (In reply to Dominique d'Humieres from comment #5)
> > > What does --with-precision=extended?
> >
> > It sets the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #8 from Jürgen Reuter ---
We are defining a real(default) which could be 4, 8, 10 or 16, as these are the
real kinds supported by gfortran. If default = 10, this happens, but this is
not per se forbidden, is it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #6 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #5)
> What does --with-precision=extended?
It sets the default precision of real and complex floats (kind type parameter)
to 80 bit instead of 64 bit (double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #4 from Jürgen Reuter ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Jürgen Reuter from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > What target is this on?
> >
> > We reproduced it under MAC OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #2 from Jürgen Reuter ---
(In reply to Andrew Pinski from comment #1)
> What target is this on?
We reproduced it under MAC OS X as well as under Ubuntu Linux 14.04 and
Scientific Linux 6.8. x86_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #1 from Andrew Pinski ---
What target is this on?
62 matches
Mail list logo
