Re: I sent in a bug report and never heard anything back

Re: I sent in a bug report and never heard anything back

[jeff]

Hans-Bernhard Bröker <HBBroeker at t-online dot de> wrote:

Not necessarily. Traditionally the typical reason for GCC internal
compiler errors, particularly if they occur with old source on very new
machines, has been faulty hardware.


My reply:

While it is always possible that there is a hardware issue, I suspect
that is not likely in this case.
The specific notebook dual boots to mageia 5 linux, and using gcc 4.9.2
the code in question compiles and runs without issue. So I suspect it is
more likely a compiler bug.

I can't imagine that I am the only person using cygwin with this issue,
so it might be good for the cygwin people to address it.

Since I sent the bug report in Aug 1, and I have gotten no useful
response from cygwin, I will be reporting the issue directly to the gcc
folks.

jeff

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: I sent in a bug report and never heard anything back

[jeff]

Brian Inglis wrote:

Apparently it's a mobile Broadwell without AVX or AVX2,
which might be assumed present in gcc as compiled,
requiring a custom gcc build to run on that cpu.

My reply:

You are correct. The gcc people replied to my bug report with:

"So the problem is your GMP/MPFR are compiled for one type of CPU and cannot be
copied to other type."

They closed it as a resolved issue.

So the problem is that gcc now requires GMP, and GMP was compiled with options that
are not compatible with my CPU. I can fix the issue for myself by compiling everything
from scratch.

The bigger issue is can cygwin distribute a version of gcc that will work with all modern
processors, including mine, with it's weird lack of AVX and AVX2. Since I ran into the
issue, I suspect anyone else with a mobile processor like mine will run into the issue.
I don't know enough about how cygwin is built and installed to know how different versions
of the GMP library might be distributed for different Intel processors.

But the problem is not going to go away, and really should be addressed in order to make
cygwin run on all reasonable platforms.

jeff




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: I sent in a bug report and never heard anything back

[Brian Inglis]

On 2016-08-27 10:27, jeff wrote:
> Brian Inglis wrote:
> Apparently it's a mobile Broadwell without AVX or AVX2,
> which might be assumed present in gcc as compiled,
> requiring a custom gcc build to run on that cpu.
> My reply:
> You are correct. The gcc people replied to my bug report with:
> "So the problem is your GMP/MPFR are compiled for one type of CPU and cannot be
> copied to other type."
> They closed it as a resolved issue.
> So the problem is that gcc now requires GMP, and GMP was compiled with options that
> are not compatible with my CPU. I can fix the issue for myself by compiling everything
> from scratch.
> The bigger issue is can cygwin distribute a version of gcc that will work with all modern
> processors, including mine, with it's weird lack of AVX and AVX2. Since I ran into the
> issue, I suspect anyone else with a mobile processor like mine will run into the issue.
> I don't know enough about how cygwin is built and installed to know how different versions
> of the GMP library might be distributed for different Intel processors.
> But the problem is not going to go away, and really should be addressed in order to make
> cygwin run on all reasonable platforms.

You could download devel sources for the MPC, MPFR, GMP, ISL, and
CLOOG packages to check what options are used for the builds and
whether AVX options are assumed on Broadwell cpus.

GMP provides a build option, which could cause such a problem:
"Fat binary, --enable-fat
     Using --enable-fat selects a “fat binary” build on x86,
where optimized low level subroutines are chosen at runtime according
to the CPU detected.
This means more code, but gives good performance on all x86 chips.
(This option might become available for more architectures in the future.)"

These libraries should be designed to run code either independent of,
or dependent only on available, cpu features, but checks may not be
sufficiently specific for newer variants.

You may want to try searching for and filing bugs against GMP and/or
MPFR with a link back to the GCC report, unless someone hereabouts
can provide more specific info about a possible failure source.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: I sent in a bug report and never heard anything back

[Brian Inglis]

On 2016-08-27 22:57, Brian Inglis wrote:
> On 2016-08-27 10:27, jeff wrote:
>> Brian Inglis wrote:
>> Apparently it's a mobile Broadwell without AVX or AVX2,
>> which might be assumed present in gcc as compiled,
>> requiring a custom gcc build to run on that cpu.
>> My reply:
>> You are correct. The gcc people replied to my bug report with:
>> "So the problem is your GMP/MPFR are compiled for one type of CPU and cannot be
>> copied to other type."
>> They closed it as a resolved issue.
>> So the problem is that gcc now requires GMP, and GMP was compiled with options that
>> are not compatible with my CPU. I can fix the issue for myself by compiling everything
>> from scratch.
>> The bigger issue is can cygwin distribute a version of gcc that will work with all modern
>> processors, including mine, with it's weird lack of AVX and AVX2. Since I ran into the
>> issue, I suspect anyone else with a mobile processor like mine will run into the issue.
>> I don't know enough about how cygwin is built and installed to know how different versions
>> of the GMP library might be distributed for different Intel processors.
>> But the problem is not going to go away, and really should be addressed in order to make
>> cygwin run on all reasonable platforms.
>
> You could download devel sources for the MPC, MPFR, GMP, ISL, and
> CLOOG packages to check what options are used for the builds and
> whether AVX options are assumed on Broadwell cpus.
>
> GMP provides a build option, which could cause such a problem:
> "Fat binary, --enable-fat
>     Using --enable-fat selects a “fat binary” build on x86,
> where optimized low level subroutines are chosen at runtime according
> to the CPU detected.
> This means more code, but gives good performance on all x86 chips.
> (This option might become available for more architectures in the future.)"
>
> These libraries should be designed to run code either independent of,
> or dependent only on available, cpu features, but checks may not be
> sufficiently specific for newer variants.
>
> You may want to try searching for and filing bugs against GMP and/or
> MPFR with a link back to the GCC report, unless someone hereabouts
> can provide more specific info about a possible failure source.

See also https://gmplib.org/repo/gmp-6.1/rev/30c9cf97935a and
https://www.cygwin.com/ml/cygwin-apps/2015-11/msg00071.html
where GMP enabled avx support on all Broadwell cpus.

If you submit a GMP bug report with /proc/cpuinfo output and
a link to your gcc bug, they should be able to add a case to
support mobile Broadwells without AVX support in a fat binary.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: I sent in a bug report and never heard anything back

[Achim Gratz]

jeff writes:
> You are correct. The gcc people replied to my bug report with:
>
> "So the problem is your GMP/MPFR are compiled for one type of CPU and cannot be
> copied to other type."
>
> They closed it as a resolved issue.

Correct, since it's not their bug.

> So the problem is that gcc now requires GMP, and GMP was compiled with options that
> are not compatible with my CPU. I can fix the issue for myself by compiling everything
> from scratch.
>
> The bigger issue is can cygwin distribute a version of gcc that will work with all modern
> processors, including mine, with it's weird lack of AVX and AVX2. Since I ran into the
> issue, I suspect anyone else with a mobile processor like mine will run into the issue.
> I don't know enough about how cygwin is built and installed to know how different versions
> of the GMP library might be distributed for different Intel processors.

GMP for Cygwin is built as a "fat binary" and choses among different
implementations of their assembly at runtime.  The problem here is that
currently the selection is done per CPU family and not per feature
enabled on that CPU, so when a new CPU comes out that Intel marketing
decides to fuse some features off, there needs to be a fallback
implemented to some older type of CPU that didn't have that feature.

> But the problem is not going to go away, and really should be addressed in order to make
> cygwin run on all reasonable platforms.

I've just released a newer GMP package that might solve that problem,
please report back whether it does.  The fallback in GMP is however
implemented based on the availability of the BMI2 instructions rather
than AVX.  Since in all your mails you still didn't manage to tell us
which exact CPU you're having the problem with I can't tell if that's
going to work in this case, but I suspect that AVX availability should
be coupled with BMI2.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: I sent in a bug report and never heard anything back

[Hans-Bernhard Bröker]

Am 26.08.2016 um 16:30 schrieb jeff@jeffunit.com:

> The issue is the internal compiler error coming from gcc on my dell with a
> specific
> intel processor.

I don't remember you telling one the specifics of that specific 
processor, yet.

> it means the compiler has a bug (which I suspect is related to the
> specific cpu).

Not necessarily.  Traditionally the typical reason for GCC internal 
compiler errors, particularly if they occur with old source on very new 
machines, has been faulty hardware.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: I sent in a bug report and never heard anything back

[Brian Inglis]

On 2016-08-26 11:55, Hans-Bernhard Bröker wrote:
> Am 26.08.2016 um 16:30 schrieb jeff@jeffunit.com:
>
>> The issue is the internal compiler error coming from gcc on my dell
>> with a specific intel processor.
>
> I don't remember you telling one the specifics of that specific
> processor, yet.

Apparently it's a mobile Broadwell without AVX or AVX2,
which might be assumed present in gcc as compiled,
requiring a custom gcc build to run on that cpu.

>> it means the compiler has a bug (which I suspect is related to the
>> specific cpu).
>
> Not necessarily.  Traditionally the typical reason for GCC internal
> compiler errors, particularly if they occur with old source on very
> new machines, has been faulty hardware.

Most common reason appears to be lack of available memory,
requiring 2GB to run comfortably. Allocating a few GB of
paging space (recommend 2x ram) to Windows can allow heavy
crunchers with large data requirements to run more comfortably.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: I sent in a bug report and never heard anything back

[Brian Inglis]

On 2016-08-26 08:30, jeff@jeffunit.com wrote:
> In reference to http://sourceware.org/ml/cygwin/2016-08/msg00261.html
> I wrote:
> I have a small program that generates an internal compiler error.
> This only happens on a new dell notebook with an Intel 3825U pentium .
> The code compiles and runs fine on an older xeon and amd processors.
> Enclosed is the output of cygcheck.
> Here is what happens when I try to compile:
> sh-4.3$ gcc bug_f2.c
> bug_f2.c: In function 'Round':
> bug_f2.c:23:5: internal compiler error: Illegal instruction
>      return floor(d + 0.5);
>      ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> sh-4.3$ exit
> Here is the source code:
> /#include <string.h>             /* strlen */
> #include <math.h>               /* floor */
> #include <limits.h>             /* INT_MAX, INT_MIN */
> #include <assert.h>             /* assert */
> /*+Input:       A double.
>    Output:      Rounded input.
>    Action:      Rounded input. +*/
> extern double Round(double d)
> {
>     return floor(d + 0.5);
> }
> Marco Atzeri wrote:
> the code compile on both 32bit and 64 bit version of gcc
> for me.
> As it is a not stand alone program
>   gcc -c  bug_f2.c
> should be used.
> My reply:
> Thanks for noting the code compiles on 32 and 64 bit architectures.
> The code is over a decade old, and has compiled and worked on many ersions
> of cygwin
> and linux. I specifically mentioned it compiled on cygwin with different
> processors.
> That was never in question.
> The issue is the internal compiler error coming from gcc on my dell with a
> specific
> intel processor. An internal compiler error does not mean the source code
> has a syntax error,
> it means the compiler has a bug (which I suspect is related to the
> specific cpu).
> Based on my experience, the two most likely possibilities are:
> 1) somehow my cygwin installation is bad. That is why I included the
> output of cygcheck.
> 2) there is a cpu specific internal compiler error with gcc.
> If 1) is the case, it is possible there is a bug with the cygwin
> installer. If 2) is the case,
> then the bug should be reported to the gcc maintainers. Since the compiler
> is a bit old,
> I suspect they will say update the compiler, which is likely something
> that cygwin should
> do ao it may benefit everyone, not just me.

Run Cygwin setup to upgrade everything pending, reboot, and retest.
If the compile still fails, provide the info below.

You don't specify or provide many details so add the following
command inputs and outputs to your report here:
* system:		uname -srvmo
* processors:		cat /proc/cpuinfo
* memory:		cat /proc/meminfo
* compiler:		gcc --version
* preprocessed source:	gcc -dM -E bug_f2.c

Report those here, and with your source, description,
and link to your detailed post here, in a bug report at:
https://gcc.gnu.org/bugzilla/
and you may get a better response.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: I sent in a bug report and never heard anything back

[jeff]

In reference to http://sourceware.org/ml/cygwin/2016-08/msg00261.html

I wrote:
I have a small program that generates an internal compiler error.
This only happens on a new dell notebook with an Intel 3825U pentium .
The code compiles and runs fine on an older xeon and amd processors.
Enclosed is the output of cygcheck.

Here is what happens when I try to compile:

sh-4.3$ gcc bug_f2.c
bug_f2.c: In function 'Round':
bug_f2.c:23:5: internal compiler error: Illegal instruction
     return floor(d + 0.5);
     ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
sh-4.3$ exit

Here is the source code:

/#include <string.h>             /* strlen */
#include <math.h>               /* floor */
#include <limits.h>             /* INT_MAX, INT_MIN */
#include <assert.h>             /* assert */


/*+Input:       A double.
   Output:      Rounded input.
   Action:      Rounded input. +*/
extern double Round(double d)
{
    return floor(d + 0.5);
}



Marco Atzeri wrote:

the code compile on both 32bit and 64 bit version of gcc
for me.

As it is a not stand alone program

  gcc -c  bug_f2.c

should be used.

My reply:

Thanks for noting the code compiles on 32 and 64 bit architectures.
The code is over a decade old, and has compiled and worked on many ersions
of cygwin
and linux. I specifically mentioned it compiled on cygwin with different
processors.
That was never in question.

The issue is the internal compiler error coming from gcc on my dell with a
specific
intel processor. An internal compiler error does not mean the source code
has a syntax error,
it means the compiler has a bug (which I suspect is related to the
specific cpu).

Based on myexperience, the two most likely possibilities are:
1) somehow my cygwin installation is bad. That is why I included the
output of cygcheck.
2) there is a cpu specific internal compiler error with gcc.

If 1) is the case, it is possible there is a bug with the cygwin
installer. If 2) is the case,
then the bug should be reported to the gcc maintainers. Since the compiler
is a bit old,
I suspect they will say update the compiler, which is likely something
that cygwin should
do ao it may benefit everyone, not just me.

thanks,
jeff




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: I sent in a bug report and never heard anything back

[Marco Atzeri]

On 16/08/2016 18:07, jeff@jeffunit.com wrote:
> I sent in
> http://sourceware.org/ml/cygwin/2016-08/msg00000.html
>
> about an internal compiler error with gcc.
> It has been about 2 weeks and I have gotten no reply.
> It would be nice to fix this bug.
>
> thanks,
> jeff
>

the code compile on both 32bit and 64 bit version of gcc
for me.

As it is a not stand alone program

   gcc -c  bug_f2.c

should be used.

Regards
Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

I sent in a bug report and never heard anything back

[jeff]

I sent in
http://sourceware.org/ml/cygwin/2016-08/msg00000.html

about an internal compiler error with gcc.
It has been about 2 weeks and I have gotten no reply.
It would be nice to fix this bug.

thanks,
jeff



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple