The code is awful, but
c/src/../../cpukit/libfs/src/dosfs/msdos_conv.c:452:48: warning: 'c' may be
used uninitialized in this function [-Wmaybe-uninitialized]
is a false positive. On which target and GCC version do you get this warning?
--
Sebastian Huber, embedded brains GmbH
Address :
Assuming this fixes a warning, commit it.
I will review the logs and answer your other question when I get to the
workshop this morning. That requires a computer.
I will also revert my change to rfs and start another build sweep so please
commit this.
On September 11, 2014 7:06:17 AM EDT,
On 10/09/14 15:12, Daniel Cederman wrote:
Invalidation of data cache lines might cause data written to the stack
to get lost.
---
testsuites/smptests/smpcache01/init.c | 45 +++
testsuites/smptests/smpcache01/smpcache01.doc | 2 --
On Sep 10, 2014, at 09:53 , Peter Dufault dufa...@hda.com wrote:
My client is having problems similar to that described here:
http://www.rtems.org/rtems/maillistArchives/rtems-users/2011/march/msg00228.html
I don't understand the details, or why one needs to limit the I/O size based
on
On 9/11/2014 5:21 AM, Sebastian Huber wrote:
The code is awful, but
c/src/../../cpukit/libfs/src/dosfs/msdos_conv.c:452:48: warning: 'c' may be
used uninitialized in this function [-Wmaybe-uninitialized]
is a false positive. On which target and GCC version do you get this warning?
$ grep
These flags are obsolete with the EABI based ARM tool chain.
---
c/src/lib/libbsp/arm/csb336/make/custom/csb336.cfg| 2 +-
c/src/lib/libbsp/arm/csb337/make/custom/csb337.cfg| 2 +-
c/src/lib/libbsp/arm/edb7312/make/custom/edb7312.cfg | 2 +-
On Sep 11, 2014, at 07:47 , Peter Dufault dufa...@hda.com wrote:
So currently:
- I/O is not limited to the file system block size;
- The mounted block size is ignored and nfsStBlksize is used, which defaults
to 4K.
I meant 8K above. Anyway, looking through the code and the associated
Hi
Replying to myself. I grabbed the preprocessed source and
used shorter command lines on it. It is -Os vs -O2 on multiple
but not all targets.
[joel@rtbf64a libfs]$ arm-rtems4.11-gcc -Wall -O2 -c unused.c
[joel@rtbf64a libfs]$ arm-rtems4.11-gcc -Wall -Os -c unused.c
This may actually be a problem in inttypes.h.
---
cpukit/libfs/src/rfs/rtems-rfs-buffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
index 4192b21..3d89f5f 100644
---
On 11/09/14 15:28, Joel Sherrill wrote:
+ printf (% PRIuPTR , ((intptr_t) buffer-user));
Typo, PRIuPTR vs. PRIiPTR?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail :
Hi
Since Sebastian investigated the msdos_conv.c and says it is a false
positive, I wanted to pass along that that makes the third set of warnings
that are upstream issues.
msdos_conv.c - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224
This one is new. No feedback.
mathf -
On 11/09/14 15:58, Peter Dufault wrote:
In nfs_dir_read() I see:
/* align + round down the buffer */
count = ~ (DIRENT_HEADER_SIZE - 1);
di-len = count;
Then later:
if (count NFS_MAXDATA)
count = NFS_MAXDATA;
di-readdirargs.count = count;
Can someone who
Invalidation of entire data cache might cause data written to the stack
to get lost.
---
testsuites/smptests/smpcache01/init.c | 47 +++
testsuites/smptests/smpcache01/smpcache01.doc | 1 -
testsuites/smptests/smpcache01/smpcache01.scn | 18 --
3 files
13 matches
Mail list logo