Since this is working again, I backed out b86b86ad4b23 here:
https://hg.savannah.gnu.org/hgweb/octave/rev/5f536c6a9bd6

I wanted to do that a while back. But then forgot about it...

Passes all tests for me with CLI and GUI with GCC and Clang. Looks more stable certainly.

Oops. I crossed with jwe's message.

I pushed a change to stable here that should be fixing this:
https://hg.savannah.gnu.org/hgweb/octave/rev/84fa12727b43

It is essentially the same as the change jwe proposed. But I believe, we don't need to get the `min` because we return early on `(r_nd < x_nd)` a few lines before.

Marking as ready for test (again).

This is the Octave equivalent of "OpenOffice.org will not print on Tuesdays" (https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28).

For what it's worth, I get the error in both GUI and CLI, but adding disp statements makes it work properly in both. Also, recompiling with optimization set to "-O0" does not make a difference. It's the same behavior with "-O3" and "-O0" for both CLI and GUI. Using gcc 11.2.0 and clang 13.0.1.

readline issue? (8.1 on Fedora)

Dmitri.
--

For me:

$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.2.0-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Ubuntu 11.2.0-7ubuntu2)

There are a few configure flags containing "libstdcxx". But tbh, I don't know what they mean or whether they could have any effect here...

Hu?
That also failed on the buildbots. But it works for me on Ubuntu 21.10 (and on Windows). I can't get it to fail no matter how hard I try. No `disp` or omitting `disp` makes it fail for me.

Maybe compiler version specific?
Here:

$ g++ --version
g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Template magic that is interpreted differently in different versions?

Or the standard libraries?

I'll check out again and try from a clean start.

Works for me with Octave 7.1.0 on Ubuntu 21.10 and Windows 11.
It looks like this has been fixed by some change in the past.

I added some BISTs here so this doesn't break again accidentally:
https://hg.savannah.gnu.org/hgweb/octave/rev/a4ed2fed7dfa

Marking as ready for test.

This isn't platform specific so I changed the OS to "Any".

Oops this bug is for Linux only.
My results were using mac.

version 6.1.0

a = ones(2, 2, 2);
b = ones(2, 1);
a .*= b
a =

ans(:,:,1) =

   1   1
   1   1

ans(:,:,2) =

   1   1
   1   1

a = a .* b
a =

ans(:,:,1) =

   1   1
   1   1

ans(:,:,2) =

   1   1
   1   1

No errors or warnings.

In 4.0.0 also the problem is still there:

a = ones(2, 2, 2);
b = ones(2, 1); # compatible with a, and smaller
a .*= b
yields an error

while
a = a .* b
runs fine

If a .*= b were just syntactic sugar for a = a .* b,
than there should not be any error, right ?

Please note that in this example a is larger than b.
in this case the operation could be done in-place, for better performance. The size of a is not changed at all.

Of course, for b .*= a (where b is smaller than a .* b), the operation could not be done in-place. In this case, b should just receive a .* b.

As a side note
a(:, :, :) .*= b
works, but I suspect there are no optimizations in this case (with respect to a = a .* b) ?

In Octave, all "A op= B" operators are just syntactic sugar for "A = A op B", so some can change the size of A:

octave:1> A = [1,2,3;4,5,6];
octave:2> B = [1,2;3,4;5,6];
octave:3> A *= B
A =

   22   28
   49   64

That's the expected result and makes sense given the simple rule that A op= B is exactly the same as A = A op B.

Actually, wait. I remember now. I deliberately did it this way, thinking that a .*= b shouldn't change a's size, thinking that broadcasting this way should work in-place without allocating temporaries or more memory. In particular, since it must be in-place, it can't change size(a).

But jwe thinks that a .*= b should be syntactic sugar for a = a .* b and shouldn't attempt to do any sort of tricks like this. At the moment, there is some code, not a lot, that actually attempts to be more efficient with the a OP= b operations than a = a OP b. What do you think should happen?

line 3 should broadcast, as on the next line.

octave:1> a = ones(2, 2, 2);
octave:2> b = ones(2, 1);
octave:3> a .*= b
error: .*=: nonconformant arguments (op1 is 2x2x2, op2 is 2x1)
octave:3> a = a .* b
warning: product: automatic broadcasting operation applied
a =

ans(:,:,1) =

   1   1
   1   1

ans(:,:,2) =

   1   1
   1   1

hg id -in
8366bc871d45 16188

It might be related to bug #35787