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 e
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 many
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 `/home/ig25/Downloads/
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 of
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 giv
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 rep
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 tr
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 tarba
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 point
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 pr
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&action=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 cod
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: err
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&action=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 "./configure
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 showe
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 showe
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&action=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
comment
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 mo
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 destin
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 i
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 #26
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 for
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' (de
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
`te
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 25
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 always
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: __shower_core_MOD_shower_generate_next_isr_branching
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 th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
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 i
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 f
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 o
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 real(default)
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 default
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
--- C
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) o
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 X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #3 from Andrew Pi
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
