| Message ID | 20220530190911.20843-1-michael@niedermayer.cc |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,1/2] avutil/opt: Alpha workaround | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
Quoting Michael Niedermayer (2022-05-30 21:09:10) > alpha-linux-gnu-gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010 with qemu-alpha version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.39) > trigger a FPE on the DBL_MAX * 90000 operation > > Iam not 100% sure why, but if i mess with mfp-trap-mode the compiler produces internal compiler errors > This issue seems not to affect the fate box with an older compiler > > Ive also tried the gcc 6, gcc 7, gcc 8 packages with no luck Do we event want to keep support for alpha? Does it still have any real-world use? It does not seem productive to spend development time on a dead platform.
On Wed, Jun 01, 2022 at 12:38:05PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2022-05-30 21:09:10) > > alpha-linux-gnu-gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010 with qemu-alpha version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.39) > > trigger a FPE on the DBL_MAX * 90000 operation > > > > Iam not 100% sure why, but if i mess with mfp-trap-mode the compiler produces internal compiler errors > > This issue seems not to affect the fate box with an older compiler > > > > Ive also tried the gcc 6, gcc 7, gcc 8 packages with no luck > > Do we event want to keep support for alpha? I have no opinion here > Does it still have any > real-world use? i do not know > It does not seem productive to spend development time on > a dead platform. Ive had the same thought and actually was a bit angry on myself after i spend too long to get a gcc + qemu + gdb working together to debug this. Felt like i could have done something more productive I think a question is, is there someone who wants to maintain alpha support because it seems it needs some support. If someone does, its no work for me and i certainly dont mind if we keep alpha on the list of supported architectures. If not we can just apply this and pretend its still supported until it breaks again. Though such support would not be with teh toolchain from the ubuntu i used. The old fate box seems to work a lot better Or we can just deprecate it and drop on a future bump dont really have an opinion, but i dont plan to put any significant amount of time in alpha support thx [...]
Quoting Michael Niedermayer (2022-06-01 19:01:27) > On Wed, Jun 01, 2022 at 12:38:05PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2022-05-30 21:09:10) > > > alpha-linux-gnu-gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010 with qemu-alpha version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.39) > > > trigger a FPE on the DBL_MAX * 90000 operation > > > > > > Iam not 100% sure why, but if i mess with mfp-trap-mode the compiler produces internal compiler errors > > > This issue seems not to affect the fate box with an older compiler > > > > > > Ive also tried the gcc 6, gcc 7, gcc 8 packages with no luck > > > > Do we event want to keep support for alpha? > > I have no opinion here > > > > Does it still have any > > real-world use? > > i do not know > > > > It does not seem productive to spend development time on > > a dead platform. > > Ive had the same thought and actually was a bit angry on myself after i spend > too long to get a gcc + qemu + gdb working together to debug this. Felt like > i could have done something more productive > > I think a question is, is there someone who wants to maintain alpha support > because it seems it needs some support. > If someone does, its no work for me and i certainly dont mind if we keep alpha > on the list of supported architectures. > If not we can just apply this and pretend its still supported until it breaks > again. Though such support would not be with teh toolchain from the ubuntu > i used. The old fate box seems to work a lot better > Or we can just deprecate it and drop on a future bump > dont really have an opinion, but i dont plan to put any significant amount > of time in alpha support Sounds reasonable. I would be in favor of deprecating it unless someone volunteers to maintain it.
diff --git a/libavutil/opt.c b/libavutil/opt.c index 8ffb10449b..78968cd894 100644 --- a/libavutil/opt.c +++ b/libavutil/opt.c @@ -101,8 +101,9 @@ FF_ENABLE_DEPRECATION_WARNINGS static int write_number(void *obj, const AVOption *o, void *dst, double num, int den, int64_t intnum) { + int maxcheck = o->max == DBL_MAX ? o->max < num * intnum / den : (o->max * den < num * intnum); if (o->type != AV_OPT_TYPE_FLAGS && - (!den || o->max * den < num * intnum || o->min * den > num * intnum)) { + (!den || maxcheck || o->min * den > num * intnum)) { num = den ? num * intnum / den : (num && intnum ? INFINITY : NAN); av_log(obj, AV_LOG_ERROR, "Value %f for parameter '%s' out of range [%g - %g]\n", num, o->name, o->min, o->max);
alpha-linux-gnu-gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010 with qemu-alpha version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.39) trigger a FPE on the DBL_MAX * 90000 operation Iam not 100% sure why, but if i mess with mfp-trap-mode the compiler produces internal compiler errors This issue seems not to affect the fate box with an older compiler Ive also tried the gcc 6, gcc 7, gcc 8 packages with no luck Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- libavutil/opt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)