Bug#905266: gfortran: Write and read arrays in unformatted files do not work properly
Package: gfortran Version: 4:8.1.0-1 Severity: important Dear Maintainer, I'm running a fortran hydrodynamic model. Here we have a routine writing an unformatted file with an header and a real array with the following code: write(30,iostat=ierr) time,ivar,m,lmax + ,(((vals(l,j,i) + ,l=1,ll(j)) + ,j=1,jj) + ,i=1,m) and a second routine this file with: read(20,iostat=ierr) time,ivar,m,lmax + ,(((vals(l,j,i) + ,l=1,ll(j)) + ,j=1,jj) + ,i=1,m) where vals is a real array. The problem is that if I write the file and then I read it and I print "vals" it contains 0.00 values. If I set ll(j) = 1 and I write in both the routines: + ,l=1,1) the code works. With old gfortran versions the code worked, as well as with other compilers. Thank you -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (300, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gfortran depends on: ii cpp 4:8.1.0-1 ii gcc 4:8.1.0-1 ii gfortran-8 8.2.0-1 gfortran recommends no packages. Versions of packages gfortran suggests: pn gfortran-doc pn gfortran-multilib -- no debconf information
Bug#1021673: Wrong __cplusplus definition when using -std=c++20
Package: g++ Version: 4:10.2.1-1 In bullseye: $ echo | g++ -dM -E -x c++ -std=c++20 - |grep _cplusplus #define __cplusplus 201709L It should instead be: #define __cplusplus 202002L
Bug#1021673: Acknowledgement (Wrong __cplusplus definition when using -std=c++20)
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93821 Upstream commit fixing this is https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=libcpp/init.c;h=445430e16bd08ade34637d2346ded40dd49de508
Bug#171689: libstdc++3 depends on gcc-3
Package: libstdc++3 Version: 1:3.0.4-13 Severity: minor I do not know the usual behaving in Debian, but I do not understand why the library should depend on the gcc-compiler. I'm not using gcc-3.0 any more, but I can not uninstall it, because some pacages depend on libstdc++3 which depends on gcc-3.0. But the binaries should not depend on the compiler... -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux debian 2.4.19-piccolo-2 #1 lun dic 2 16:13:19 CET 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages libstdc++3 depends on: hi gcc-3.0-base 1:3.0.4-12 The GNU Compiler Collection (base hi libc6 2.3.1-3GNU C Library: Shared libraries an ii libgcc1 1:3.2.1-1 GCC support library. -- no debconf information
Re: Switch on compiler hardening defaults
On Oct 25, Kees Cook wrote: > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > uses[2]. Seconded. hardening-wrapper does not looks like a solution to me since it execs perl for each call to gcc and ld when installed (even when inactive). And as you noticed, nobody uses it (starting with me). -- ciao, Marco signature.asc Description: Digital signature
Bug#552778: udev: preinst fails to detect kernel symbols ???sys_inotify_init??? and ???sys_signalfd???
On Oct 28, Ben Finney wrote:
Does anybody know why, and if ther are other architecture-specific
cases I need to care about? I checked pescetti.d.o which is powerpc,
but it has regular symbols.
As a workaround you can create /etc/udev/kernel-upgrade and then
manually stop/restart udevd.
> The symbols *do* appear in the kernel symbol table, but they are named
> with a leading period (I don't know why), so the following regex
> succeeds in matching the symbols:
>
> =
> $ needed_symbols='sys_inotify_init sys_signalfd'
> $ for symbol in $needed_symbols; do egrep "^[a-fA-F0-9]+ T \.${symbol}$"
> /proc/kallsyms; done
> c0170e00 T .sys_inotify_init
> c0172e84 T .sys_signalfd
> $
> =
> Kernel: Linux 2.6.30-2-powerpc64 (SMP w/2 CPU cores)
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: gfdl gcc documentation packages for non-free: update
On Sep 21, Matthias Klose <[EMAIL PROTECTED]> wrote: > - the man pages (all except gfortran.1) are not built from >source. -> RC As long as the source is available in the package this is not a bug at all. -- ciao, Marco signature.asc Description: Digital signature
Re: Increasing minimum 'i386' processor
On Nov 19, Ben Hutchings wrote: > I think it is time to increase the minimum requirement to 586-class, if > not for wheezy then immediately after. I agree, it's time to weight the costs and benefits of supporting obsolete hardware at the expense of most users. > (Later it should be increased > further, and eventually i386 should be reduced to a partial architecture > that may be installed on amd64 systems.) Yes, but how much later? :-) -- ciao, Marco signature.asc Description: Digital signature
Bug#323016: ICE while compiling tin on m68k
Package: gcc-4.0
Version: 4.0.0-12
Severity: important
Compiling tin 1.7.10+20050727 on m68k fails.
gcc -DHAVE_CONFIG_H -I. -I../include -I/usr/include
-DLOCALEDIR=\"/usr/share/locale\" -I../include -DUSE_CANLOCK -D_GNU_SOURCE -g
-O2 -c ./save.c
./save.c: In function 'uudecode_line':
./save.c:1053: error: unable to find a register to spill in class 'ADDR_REGS'
./save.c:1053: error: this is the insn:
(insn 22 21 23 0 ./save.c:1031 (set (reg/v:SI 12 %a4 [orig:40 n.152 ] [40])
(plus:SI (subreg:SI (mem:QI (reg/v/f:SI 10 %a2 [orig:46 buf ] [46]) [0
S1 A8]) 0)
(const_int 32 [0x20]))) 95 {*addsi3_internal}
(insn_list:REG_DEP_TRUE 13 (nil))
(nil))
./save.c:1053: confused by earlier errors, bailing out
make: *** [save.o] Error 1
How to reproduce:
$ apt-get unpack tin
$ ./debian/rules configure
$ cd build-tree/tin-1.7.10/src/
$ make save.o
Using -O1 fixes it, and if I move uudecode_line() alone to a new file
I cannot reproduce the bug (so I cannot provide a simple test case).
I do not think that this function has changed in the last few years, so
it's probably a gcc 4.0 regression.
--
ciao,
Marco
signature.asc
Description: Digital signature
Best Med,cine deals
Your favorite medcation -> 70% 0FF Sa1e (limitd. time only) V1AGRA from $62 VAL1UM from $70 AMB1EN from $64 C1AL1S from $90 XANX from $70 + M0RE.. 0RDER N0W & GET SHIPPlNG AT NO C0ST.. http://781.net.besentby.com
Re: Best way to wrap gcc/g++ calls?
On Jan 01, Adeodato Simó <[EMAIL PROTECTED]> wrote: > I wouldn't mess with the real /usr/bin/* binaries/symlinks, and would > do something similar to what ccache does. have a look at /usr/lib/ccache. > (so, apt-build would prepend /usr/lib/apt-build or similar to the PATH.) Agreed. This is what cross-compilers do as well. -- ciao, Marco signature.asc Description: Digital signature
Bug#288739: gcc optimization bug
Package: gcc
Version: 2.95.4 20011002
following function compiled w/ gcc -O
int foo(unsigned int a)
{
if(a * sizeof(int) / sizeof(int) != a)
return -1;
return 0;
}
results in:
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 31 c0 xor%eax,%eax
5: c9 leave
6: c3 ret
7: 90 nop
gcc optimizes the arithmetic overflow check away!
Debian GNU/Linux 3.0
vanilla kernel 2.2.26
libc6 Version: 2.2.5-11.5
Regards,
Marco Fabbricatore
--- "Smith & Wesson: The original point and click interface." ---
Bug#288739: gcc optimization bug
Well this means that all debian 3.0 packages which have been compiled w/
gcc 2.95 might contain serious integer overflow problems regardless one
thinks he does secure programming.
marco
Falk Hueffner wrote:
Marco Fabbricatore <[EMAIL PROTECTED]>, [EMAIL PROTECTED] schrieb am 05.01.05
14:08:32:
Package: gcc
Version: 2.95.4 20011002
following function compiled w/ gcc -O
int foo(unsigned int a)
{
if(a * sizeof(int) / sizeof(int) != a)
return -1;
return 0;
}
gcc optimizes the arithmetic overflow check away!
Indeed. This is fixed in the 3.x series. I suggest upgrading, since it seems
unlikely
that somebody will find and backport the fix...
Falk
Bug#292958: gcc 3.3 on powerpc miscompiles BIND 9.3
Package: gcc-3.3 Version: 3.3.5-6 Severity: normal gcc 3.3 apparently does not compile correctly lib/dns/rbt.c from BIND 9.3, which then will die on startup with an assertion failure. Workarounds known to fix this: - compiling rbt.c without -O2 - removing "inline" from rotate_left() and rotate_right() - using gcc 3.4 Let me know if you need assistance debugging this. I can also provide a set of BIND configuration files which can reliably trigger the bug. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.6-b50 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#255800: gcj-3.3: manpage doesn't mention all available options
Package: gcj-3.3 Version: 1:3.3.4-1 Severity: minor The manpage is very sparse, it doesn't mention for example the -c and -S switches. There are also others. These are shown with gcj --help, but people expect a manpage to show all available options. Marco -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.25 Locale: LANG=C, [EMAIL PROTECTED] Versions of packages gcj-3.3 depends on: ii g++-3.3 1:3.3.4-1The GNU C++ compiler ii gcc-3.3-base1:3.3.4-1The GNU Compiler Collection (base ii java-common 0.22 Base of all Java packages ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libgcc1 1:3.3.4-1GCC support library ii libgcj4 1:3.3.4-1Java runtime library for use with ii zlib1g 1:1.2.1.1-3 compression library - runtime -- no debconf information
Bug#265555: /usr/share/doc/cpp/cpp is a link to itself
Package: gcc Version: 4:3.3.4-2 Severity: minor The file /usr/share/doc/cpp/cpp is a link to itself. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-k7 Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 Versions of packages gcc depends on: ii cpp 4:3.3.4-2 The GNU C preprocessor (cpp) ii cpp-3.3 1:3.3.4-6sarge1 The GNU C preprocessor ii gcc-3.3 1:3.3.4-6sarge1 The GNU C compiler -- no debconf information
