Class: rejects-legal
Release: gcc (GCC) 4.2.3
Description:
like bug 14932 - 4.2.3 c++ does not allow variable array index in macro
offsetof
it looks like offsetof maps to a builtin function:
#define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)
This appears to be in
--- Comment #1 from schwab at suse dot de 2008-06-17 07:42 ---
The macro is correctly defined. According to 7.17 of the C standard, ((struct
A)t).array[x] shall evaluate to an address constant, which it doesn't.
--
schwab at suse dot de changed:
What|Removed
--- Comment #2 from ajrobb at bigfoot dot com 2008-06-17 08:15 ---
While I am not convinced that offsetof isn't effectively being implemented as a
function (OK it is defined as a function call and not a function reference), I
accept that we cannot use variable array indexing, so
Yet another one. It behaves the same for 4.1.2 and current trunk.
$ gcc -Os -Wuninitialized -c uninit-J.c
uninit-J.c: In function 'pr':
uninit-J.c:7: warning: 'bug' may be used uninitialized in this function
$ cat uninit-J.c
/* { dg-do compile } */
/* { dg-options -Os -Wuninitialized } */
void
--- Comment #1 from belyshev at depni dot sinp dot msu dot ru 2008-06-17
10:40 ---
check() can return 1 on the first call and 0 on the second and if *argv is NULL
then then bug will be used uninitialized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550
--- Comment #2 from aldot at gcc dot gnu dot org 2008-06-17 10:46 ---
(In reply to comment #1)
check() can return 1 on the first call and 0 on the second and if *argv is
NULL
then then bug will be used uninitialized.
right, but this doesn't matter here. Better testcase:
/* { dg-do
--- Comment #5 from irar at il dot ibm dot com 2008-06-17 11:49 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
Steps to reproduce:
cat test.c EOF
__thread int foo;
void bar (void) {
foo = 2;
}
EOF
hppa64-linux-gnu-gcc-4.3.1 -S test.c
test.c: In function 'bar':
test.c:5: error: unrecognizable insn:
(insn 6 5 7 3 test.c:4 (set (reg:DI 67)
(unspec:SI [
(const_int 0 [0x0])
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-06-17 13:24 ---
This really needs conditional phis so ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from aldot at gcc dot gnu dot org 2008-06-17 13:54 ---
boostrapping pristine trunk still fails with:
/scratch/obj.i686/gcc-4.4.orig/./gcc/xgcc
-B/scratch/obj.i686/gcc-4.4.orig/./gcc/
-B/opt/i686/gcc-4.4.orig//i686-linux-gnu/bin/
--- Comment #6 from E dot Kuemmerle at fz-juelich dot de 2008-06-17 14:06
---
I tried gcc 4.4.0 20080613 (experimental):
indeed, it works now!
--
E dot Kuemmerle at fz-juelich dot de changed:
What|Removed |Added
--- Comment #2 from kate01123 at gmail dot com 2008-06-17 14:10 ---
I can build gcc-4.3.1 using bootstrap compiler gcc-4.2.3.
If I use gcc-4.3.0 as the bootstrap compiler, I get the build
error that I reported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36512
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-17 14:18 ---
/* We have a special case here if we are doing something like
(C * 8) % 4 since we know that's zero. */
if ((code == TRUNC_MOD_EXPR || code == CEIL_MOD_EXPR
|| code == FLOOR_MOD_EXPR
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-17 14:20 ---
That is only true for where overflow is undefined IIRC. So if wrapping happens
this is not true ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from faridz at apache dot org 2008-06-17 15:03 ---
You're right, the problem in Ubuntu's /usr/include/wctype.h header file:
---
...
/* Get wint_t from wchar.h. */
#define __need_wint_t
#include wchar.h
...
---
Here after that lines should be #undef
The ext/pb_ds/detail/left_child_next_sibling_heap_/null_metadata.hpp header has
a line
#include ext/pb_ds/detail/left_child_next_sibling_heap_/null_metadata.hpp
which attempts to include the file itself for no good reason.
Either some other header was meant to be included and this should be
At revision 136821 the following code:
!module CHECK_SEM
! Submitted by Walt Brainerd, The Fortran Company
! GNU Fortran 95 (GCC 4.1.0 20050322 (experimental))
! Windows XP
! Produces a.exe has encountered a problem window.
! Same problem if comments are removed so that
!the function is in
: error: BB 3 can not throw but has EH edges
+===GNAT BUG DETECTED==+
| 4.4.0 20080617 (experimental) [trunk revision 136861]
(x86_64-unknown-linux-gnu) GCC error:|
| verify_flow_info failed |
| Error
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Following test cases cases internal error -- dependent on having reduction
clause (other clauses -- private, firstprivate, etc... seem OK).
(140) gcc-4.3.1 -c -fopenmp -v D2.i
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --program-suffix=-4.3.1
Thread model: posix
--- Comment #1 from david dot mcnamara at crescentbaysoftware dot com
2008-06-17 18:03 ---
Created an attachment (id=15775)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15775action=view)
preprocessed test case
-fopenmp option causes internal error due to reduction-clause on
--- Comment #4 from pault at gcc dot gnu dot org 2008-06-17 18:09 ---
Subject: Bug 36366
Author: pault
Date: Tue Jun 17 18:08:24 2008
New Revision: 136871
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136871
Log:
2008-06-17 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #11 from pault at gcc dot gnu dot org 2008-06-17 18:09 ---
Subject: Bug 34396
Author: pault
Date: Tue Jun 17 18:08:24 2008
New Revision: 136871
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136871
Log:
2008-06-17 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from hjl dot tools at gmail dot com 2008-06-17 18:16 ---
I can contribute a patch for -static-libc++/-static-libstdc++.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
An incorrect error message is generated when a #pragma omp for
firstprivate(var) is enclosed in an #pragma omp parallel -- region and the
'var' is not specified on that pragma. Example in specs explicitly states this
is OK.
D.c: In function âtestâ:
D.c:23: error: âsâ not specified in enclosing
--- Comment #1 from david dot mcnamara at crescentbaysoftware dot com
2008-06-17 19:00 ---
Created an attachment (id=15776)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15776action=view)
preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36556
--- Comment #1 from pault at gcc dot gnu dot org 2008-06-17 19:33 ---
(In reply to comment #0)
At revision 136821 the following code:
Dominique,
It runs fine for me on x86_ia64 - did you use any options?
I've CC'd Jerry, since 136821 was his.
Paul
--
pault at gcc dot gnu dot
Testcase:
unsigned char f(unsigned int m_pAttachedTo)
{
return m_pAttachedTo != 0;
}
When merging the PS3 specific changes up to 4.3.0, I Noticed that -m32
-mpowerpc64 produces better code in some cases than -m64, this is one such
case.
Right now with -m64 we produce:
srawi 0,3,31
Hello friends,
I had installed Ubuntu hardy Heron 8.04 on my laptop using Wubi to compile
some server.c and client.c projects for my socket programming project on
Linux OS.I was able to view the desired results with the following
commands.It's only that when I re-installed Ubuntu and MySQL
--- Comment #6 from domob at gcc dot gnu dot org 2008-06-17 20:25 ---
Subject: Bug 36112
Author: domob
Date: Tue Jun 17 20:24:20 2008
New Revision: 136872
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136872
Log:
2008-06-17 Daniel Kraft [EMAIL PROTECTED]
PR
--- Comment #7 from domob at gcc dot gnu dot org 2008-06-17 20:26 ---
Fixed.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
The following program:
--
static volatile long last;
main()
{
long a, b;
a = last;
b = a + 1;
asm volatile (casx %0, %2, %1\n : +V (last), +r (b) :r (a));
}
--
will not compile. The error message printed is:
[EMAIL PROTECTED]:~/x$
Hi,
I'm compiling a gcc4.3 based toolchain for m68k/coldfire architecture and
uclibc library. After compilation I can use the -msoft-float but I cannot
resolve the symbols of float emulated functions beacause libgcc.a doesn't
contain any support for float.
The --with-float=soft is absent in
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-17 21:47
---
Let's CC Benjamin instead of just removing the include.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from luigi dot mantellini at idf-hit dot com 2008-06-17
21:57 ---
Additional information: I'm bulding my toolchain using OpenWRT environment
(with patch to include m68k arch) and gcc patches from buildroot git.
ask me for any other information.
luigi
--
--- Comment #2 from dominiq at lps dot ens dot fr 2008-06-17 22:04 ---
(In reply to comment #1)
It runs fine for me on x86_ia64 - did you use any options?
I have set the build to i686-apple-darwin9. The bus error comes with default
(-m32 and no options), the test passes with -m64.
--- Comment #2 from luigi dot mantellini at idf-hit dot com 2008-06-17
22:08 ---
configure call:
cd
/mnt/devel/openwrt/OpenWRT.git/build_dir/toolchain-m68k_gcc4.3.1/gcc-4.3.1-initial;
rm -f config.cache; SHELL=/bin/bash
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-06-17 22:11 ---
Doesn't all Coldfire have FPUs (not the 68887 one)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36559
--- Comment #4 from luigi dot mantellini at idf-hit dot com 2008-06-17
22:17 ---
(In reply to comment #3)
Doesn't all Coldfire have FPUs (not the 68887 one)?
I don't know if all CF have FPUs, but the actual linux kernel 2.6.23 for
547x/5445x shipped by Freescale requires
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-06-17 22:18 ---
I don't know if all CF have FPUs, but the actual linux kernel 2.6.23 for
547x/5445x shipped by Freescale requires -msoft-float option.
That is make sure it does not use the fp registers ...
--
--- Comment #6 from luigi dot mantellini at idf-hit dot com 2008-06-17
22:24 ---
(In reply to comment #5)
I don't know if all CF have FPUs, but the actual linux kernel 2.6.23 for
547x/5445x shipped by Freescale requires -msoft-float option.
That is make sure it does not use the
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-17
23:42 ---
Subject: Re: New: Failure to compile __thread variable.
hppa64-linux-gnu-gcc-4.3.1 -S test.c
There is no TLS support for the 64-bit compiler. This is an enhancement
request.
Dave
--
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-06-18 00:18
---
I can reproduce this on x86-64-linux by using the -m32 option.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Testsuite test gcc.dg/tree-ssa/loop35.c fails for avr target for test3().
This test uses long array index. Tests with int or char index get hoisted as
expected.
void test3(unsigned long b)
{
unsigned i;
/* And here. */
for (i = 0; i 100; i++)
{
arr[b+8].X += i;
--- Comment #2 from carlos at systemhalted dot org 2008-06-18 02:35 ---
Yes, I just realized there were no TARGET_64BIT TLS patterns in
config/pa/pa.md.
I'm closing the bug as invalid. I'll take this up seperately. We'll have to
define call sequences for the 64-bit address loads etcs.
The changes described in
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00607.html entitled More code
clean up in mlib-tgt-* changes/renames a number of files from the form
mlib-tgt-xx.adb to mlib-tgt-specific-xx.adb.
However the corresponding changes were not made to gnatlib/configure.ac.
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-06-18 04:27
---
When I revert just the files in my patch, the test case passes with -m32 and
segfaults on -m64 at run time. I don't think this is related to 136821
directly.
Looking at the -fdump-tree-original between -m32 and
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-06-18 04:57
---
OK, with r136820
$ gfc -m64 -fbounds-check pr36553.f90
$ ./a.out
At line 17 of file pr36553.f90
Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of
array 'expected'
--- Comment #6 from burnus at gcc dot gnu dot org 2008-06-18 05:33 ---
I get in valgrind (trunk revision 136838) with -m32 and -m64 on x86-64-linux:
==3145== Invalid read of size 4
==3145==at 0x804876D: check_integer4_rank1_ (test.f90:14)
==3145==by 0x80489E1: MAIN__
49 matches
Mail list logo
