[Bug c++/36549] offsetof defined as function in contravention of ISO/IEC 14882:1998 17.4.1.2 para 5

[schwab at suse dot de]

--- 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 |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36549

[Bug c++/36549] offsetof defined as function in contravention of ISO/IEC 14882:1998 17.4.1.2 para 5

[ajrobb at bigfoot dot com]

--- 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 "rejects-legal" class is
wrong. Thank you.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36549

[Bug middle-end/36550] New: Wrong "may be used uninitialized" warning

[aldot at gcc dot gnu dot org]

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 bail(void) __attribute__((noreturn));
unsigned check(void);
int pr(char**argv)
{
char *bug;
if (check()) {
if (*argv)
bug = *++argv;
} else {
bug = *argv++;
if (!*argv)
bail();
}
/* now bug is set except if (check() && !*argv) */
if (check()) {
if (!*argv)
return 0;
}
/* if we ever get here then bug is set */
return *bug != 'X';
}


-- 
   Summary: Wrong "may be used uninitialized" warning
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
OtherBugsDependingO 24639
 nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550

[Bug middle-end/36550] Wrong "may be used uninitialized" warning

[belyshev at depni dot sinp dot msu dot ru]

--- 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

[Bug middle-end/36550] Wrong "may be used uninitialized" warning

[aldot at gcc dot gnu dot org]

--- 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 compile } */
/* { dg-options "-Os -Wuninitialized" } */
void bail(void) __attribute__((noreturn));
unsigned once(void);
int pr(char**argv)
{
char *bug;
unsigned check = once();
if (check) {
if (*argv)
bug = *++argv;
} else {
bug = *argv++;
if (!*argv)
bail();
}
/* now bug is set except if (check && !*argv) */
if (check) {
if (!*argv)
return 0;
}
/* if we ever get here then bug is set */
return *bug != 'X';
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550

[Bug tree-optimization/36493] [4.3/4.4 Regression] vectorizer aliasing bug

[irar at il dot ibm dot com]

--- 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 |RESOLVED
   Priority|P1  |P3
 Resolution||FIXED
   Target Milestone|4.3.2   |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36493

[Bug target/36551] New: Failure to compile __thread variable.

[carlos at systemhalted dot org]

Steps to reproduce:

cat >> test.c  for instructions.

Expected:
- Compiler correctly compiles the code.

Observed:
- ICE trying to compile code with __thread keyword.

hppa does have support for thread local storage, but it's never been tested on
the 64-bit compiler.

I came across this error while trying to port glibc to hppa64-linux-gnu during
a 64-bit userspace bring-up.


-- 
   Summary: Failure to compile __thread variable.
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlos at systemhalted dot org
 GCC build triplet: hppa-linux-gnu
  GCC host triplet: hppa64-linux-gnu
GCC target triplet: hppa64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36551

[Bug middle-end/36550] Wrong "may be used uninitialized" warning

[pinskia at gcc dot gnu dot org]

--- 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

   Severity|normal  |enhancement


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550

[Bug target/36450] [4.4 Regression] ICE in insert_restore/insert_save with GET_MODE_ALIGNMENT mem

[aldot at gcc dot gnu dot org]

--- 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/
-B/opt/i686/gcc-4.4.orig//i686-linux-gnu/lib/ -isystem
/opt/i686/gcc-4.4.orig//i686-linux-gnu/include -isystem
/opt/i686/gcc-4.4.orig//i686-linux-gnu/sys-include -O2 -march=pentium4
-mtune=pentium4 -pipe -DIN_GCC -mpreferred-stack-boundary=2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc
-I../../../../src/gcc-4.4.orig/libgcc -I../../../../src/gcc-4.4.orig/libgcc/.
-I../../../../src/gcc-4.4.orig/libgcc/../gcc
-I../../../../src/gcc-4.4.orig/libgcc/../include
-I../../../../src/gcc-4.4.orig/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS -DUSE_TLS -o bid64_div.o -MT bid64_div.o -MD -MP -MF
bid64_div.dep -c ../../../../src/gcc-4.4.orig/libgcc/config/libbid/bid64_div.c
In file included from
../../../../src/gcc-4.4.orig/libgcc/config/libbid/bid64_div.c:62:
../../../../src/gcc-4.4.orig/libgcc/config/libbid/bid_div_macros.h: In function
‘__div_256_by_128’:
../../../../src/gcc-4.4.orig/libgcc/config/libbid/bid_div_macros.h:542:
internal compiler error: in insert_save, at caller-save.c:787
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [bid64_div.o] Error 1


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||build


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450

[Bug c++/33435] internal compiler error with templates and openmp

[E dot Kuemmerle at fz-juelich dot de]

--- 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

 Status|WAITING |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33435

[Bug target/36512] relocation overflow

[kate01123 at gmail dot com]

--- 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

[Bug middle-end/36548] likely integer codegen bug

[pinskia at gcc dot gnu dot org]

--- 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 || code == ROUND_MOD_EXPR)
  && TREE_CODE (TREE_OPERAND (t, 1)) == INTEGER_CST
  && integer_zerop (const_binop (TRUNC_MOD_EXPR, op1, c, 0)))
return omit_one_operand (type, integer_zero_node, op0);


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|c   |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36548

[Bug middle-end/36548] remainder gives the wrong result for wrapping case with unsigned types

[pinskia at gcc dot gnu dot org]

--- 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

   Keywords||wrong-code
Summary|likely integer codegen bug  |remainder gives the wrong
   ||result for wrapping case
   ||with unsigned types


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36548

[Bug c++/36530] ptrdiff_t undefined if is included after and

[faridz at apache dot org]

--- 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 .  */
#define __need_wint_t
#include 
...
---

Here after that lines should be "#undef __need_wint_t"...


-- 

faridz at apache dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36530

[Bug libstdc++/36552] New: includes itself: ext/pb_ds/detail/left_child_next_sibling_heap_/null_metadata.hpp

[gcc at abeckmann dot de]

The ext/pb_ds/detail/left_child_next_sibling_heap_/null_metadata.hpp header has
a line

#include 

which attempts to include the file itself for no good reason.
Either some other header was meant to be included and this should be fixed or
this superfluous #include should be dropped completely in order not to confuse
people (or scripts trying to find #include cycles).

Andreas


-- 
   Summary: includes itself:
ext/pb_ds/detail/left_child_next_sibling_heap_/null_meta
data.hpp
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at abeckmann dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36552

[Bug fortran/36553] New: [4.4 Regression] regression due to revision 136821

[dominiq at lps dot ens dot fr]

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 a module.

!  contains

function CHECK_INTEGER4_RANK1 (EXPECTED, COMPUTED)
  integer(4), dimension(:), intent(in) ::  EXPECTED, COMPUTED
  logical  :: CHECK_INTEGER4_RANK1
  CHECK_INTEGER4_RANK1 = all(COMPUTED == EXPECTED)
end function CHECK_INTEGER4_RANK1

!end module CHECK_SEM

program array_test
!use CHECK_SEM
logical :: CHECK_INTEGER4_RANK1

  integer,dimension(-1:1,-1:1)  :: mis1=1.1 
  logical,dimension(-1:1,-1:1)  :: ml2=.true.

  print *, CHECK_INTEGER4_RANK1 (sum(mis1,dim=1,mask=ml2), (/8,5,12/))

end program array_test

gives a "Bus error". The executable runs fine if I revert the patch.


-- 
   Summary: [4.4 Regression] regression due to revision 136821
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553

[Bug ada/36554] New: [4.4 regression] verify_flow_info ICE can not throw but has EH edges

[laurent at guerby dot net]

This doesn't ICE with gcc 4.3.1, may be by luck.

$ cat pt.ads
package PT is

   function S (V : in Long_Float) return String;

end PT;
$ cat pt.adb
package body Pt is

   function Long_Float_Is_Valid (X : in Long_Float) return Boolean is
  Is_Nan : constant Boolean := X /= X;
  Is_P_Inf : constant Boolean := X > Long_Float'Last;
  Is_M_Inf : constant Boolean := X < Long_Float'First;
  Is_Invalid : constant Boolean := Is_Nan or Is_P_Inf or Is_M_Inf;
   begin
  return not Is_Invalid;
   end Long_Float_Is_Valid;

   function S (V : in Long_Float) return String is
   begin
  if not Long_Float_Is_Valid (V) then
 return "INVALID";
  else
 return "OK";
  end if;
   exception
  when others =>
 return "ERROR";
   end S;

end Pt;
$ gcc -c -O2 pt.adb
pt.adb: In function 'Pt.S':
pt.adb:12: error: BB 2 can not throw but has EH edges
pt.adb:12: 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 detected around pt.adb:12  |


-- 
   Summary: [4.4 regression] verify_flow_info ICE can not throw but
has EH edges
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
  GCC host triplet: x86_64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36554

[Bug middle-end/36554] [4.4 regression] verify_flow_info ICE can not throw but has EH edges

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|ada |middle-end
   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36554

[Bug c/36555] New: #pragma omp sections reduction-clause causes internal error

[david dot mcnamara at crescentbaysoftware dot com]

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
gcc version 4.3.1 (GCC)
COLLECT_GCC_OPTIONS='-c' '-fopenmp' '-v' '-mtune=generic' '-pthread'
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.1/cc1 -fpreprocessed D2.i -quiet
-
dumpbase D2.i -mtune=generic -auxbase D2 -version -fopenmp -o /tmp/ccznaeOg.s
GNU C (GCC) version 4.3.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.3.1, GMP version 4.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 48b3416203e404802ac950ddf1fef393
a219.c: In function âmainâ:
a219.c:38: internal compiler error: in expand_omp_sections, at omp-low.c:3431
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Test case follows:


# 1 "a219.c"
# 1 ""
# 1 ""
# 1 "a219.c"
# 13 "a219.c"
# 1 "/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.1/include/omp.h" 1 3 4
# 37 "/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.1/include/omp.h" 3 4
typedef struct
{
  unsigned char _x[4]
__attribute__((__aligned__(4)));
} omp_lock_t;

typedef struct
{
  unsigned char _x[8]
__attribute__((__aligned__(4)));
} omp_nest_lock_t;
# 57 "/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.1/include/omp.h" 3 4
extern int omp_get_thread_num (void) __attribute__((__nothrow__));


# 14 "a219.c" 2

int shrd;
int prvt, fprvt, lprvt, rdct;
main ()
{
  fprvt = -1;
  rdct = 0;
#pragma omp parallel
  {
int id = omp_get_thread_num ();
#pragma omp sections reduction(+:rdct)
{
#pragma omp section
  {
prvt = id;
rdct += 1;
lprvt = id;
  }
#pragma omp section
  {
prvt = id;
rdct += 1;
lprvt = id;
shrd = id;
  }
}
  }
}


-- 
   Summary: #pragma omp sections reduction-clause causes internal
error
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot mcnamara at crescentbaysoftware dot com
 GCC build triplet: ../configure --program-suffix=-4.3.1
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36555

[Bug c/36555] #pragma omp sections reduction-clause causes internal error

[david dot mcnamara at crescentbaysoftware dot com]

--- 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=15775&action=view)
preprocessed test case

-fopenmp option causes internal error due to reduction-clause on #pragma omp
sections.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36555

[Bug fortran/36366] [4.3/4.4 Regression] ICE in gfc_conv_component_ref

[pault at gcc dot gnu dot org]

--- 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=gcc&view=rev&rev=136871
Log:
2008-06-17  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/34396
* resolve.c (add_dt_to_dt_list):  New function.
(resolve_fl_derived): Call new function for pointer components
and when derived type resolved.

2008-06-17  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/36366
* gfortran.dg/used_types_20.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/used_types_20.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36366

[Bug fortran/34396] Length of substrings defined by expressions not correctly computed in constructors

[pault at gcc dot gnu dot org]

--- 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=gcc&view=rev&rev=136871
Log:
2008-06-17  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/34396
* resolve.c (add_dt_to_dt_list):  New function.
(resolve_fl_derived): Call new function for pointer components
and when derived type resolved.

2008-06-17  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/36366
* gfortran.dg/used_types_20.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/used_types_20.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34396

[Bug other/31400] enable static linking of support libraries through -static-libXY

[hjl dot tools at gmail dot com]

--- 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

 CC||ian at airs dot com
Version|4.3.0   |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400

[Bug c/36556] New: OpenMP: incorrect 'not specified in enclosing parallel'

[david dot mcnamara at crescentbaysoftware dot com]

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 parallel
D.c:15: error: enclosing parallel


-- 
   Summary: OpenMP: incorrect 'not specified in enclosing parallel'
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot mcnamara at crescentbaysoftware dot com
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36556

[Bug c/36556] OpenMP: incorrect 'not specified in enclosing parallel'

[david dot mcnamara at crescentbaysoftware dot com]

--- 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=15776&action=view)
preprocessed test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36556

[Bug fortran/36553] [4.4 Regression] regression due to revision 136821

[pault at gcc dot gnu dot org]

--- 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 org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553

[Bug target/36557] New: -m32 -mpowerpc64 produces better code than -m64 for a!=0

[pinskia at gcc dot gnu dot org]

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
xor 3,0,3
subf 3,3,0
rldicl 3,3,33,63
blr
But since m_pAttachedTo is passed as a zero extended 64bit we should be able to
produce:
addic 9,3,-1
subfe 0,9,3
blr
As we do for -m32 and also for 64bit unsigned integers with -m64.


-- 
   Summary: -m32 -mpowerpc64 produces better code than -m64 for a!=0
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36557

GCC error while compiling my server.c program using MySQL

[linuxfan84]

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
client-server,I'm getting the following gcc compiler errors that I didn't
get before.Please help me out. 

[EMAIL PROTECTED]:~/Desktop/project$ gcc -I./mysql/include -L./mysql/lib
server.c -o server lmysqlclient 
gcc: -I./mysql/include: No such file or directory 
gcc: -L./mysql/lib: No such file or directory 
gcc: -o: No such file or directory 
gcc: server: No such file or directory 
gcc: lmysqlclient: No such file or directory 
server.c:13:19: error: mysql.h: No such file or directory 
server.c:21: error: expected ?? ?? ?? 멲sm?or ?_attribute__?before ??token 
server.c: In function 몀ain? 
server.c:47: error: 멝YSQL?undeclared (first use in this function) 
server.c:47: error: (Each undeclared identifier is reported only once 
server.c:47: error: for each function it appears in.) 
server.c:47: error: 몀ysql?undeclared (first use in this function) 
server.c:48: error: 멝YSQL_RES?undeclared (first use in this function) 
server.c:48: error: 몉esult?undeclared (first use in this function) 
server.c:142: error: 멝YSQL_ROW?undeclared (first use in this function) 
server.c:142: error: expected ??before 몉ow?
server.c:143: error: 몉ow?undeclared (first use in this function) 

Please note that I've already run the command "sudo apt-get build-essentail"
The above command to compile mysql server worked like a breeze before but
now it's giving me the above errors.I'm really concerned about the gcc
errors as remaining errors depend on that.Please help me out guys.Thanks. 

-- 
View this message in context: 
http://www.nabble.com/GCC-error-while-compiling-my-server.c-program-using-MySQL-tp17936404p17936404.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug fortran/36112] Bounds-checking on character length not working for array-constructors

[domob at gcc dot gnu dot org]

--- 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=gcc&view=rev&rev=136872
Log:
2008-06-17  Daniel Kraft  <[EMAIL PROTECTED]>

PR fortran/36112
* array.c (gfc_resolve_character_array_constructor):  Check that all
elements with constant character length have the same one rather than
fixing it if no typespec is given, emit an error if they don't. 
Changed
return type to "try" and return FAILURE for the case above.
(gfc_resolve_array_constructor):  Removed unneeded call to
gfc_resolve_character_array_constructor in this function.
* gfortran.h (gfc_resolve_character_array_constructor):  Returns try.
* trans-array.c (get_array_ctor_strlen):  Return length of first
element
rather than last element.
* resolve.c (gfc_resolve_expr):  Handle FAILURE return from
gfc_resolve_character_array_constructor.

2008-06-17  Daniel Kraft  <[EMAIL PROTECTED]>

PR fortran/36112
* gfortran.dg/bounds_check_array_ctor_1.f90:  New test.
* gfortran.dg/bounds_check_array_ctor_2.f90:  New test.
* gfortran.dg/bounds_check_array_ctor_3.f90:  New test.
* gfortran.dg/bounds_check_array_ctor_4.f90:  New test.
* gfortran.dg/bounds_check_array_ctor_5.f90:  New test.
* gfortran.dg/bounds_check_array_ctor_6.f90:  New test.
* gfortran.dg/bounds_check_array_ctor_7.f90:  New test.
* gfortran.dg/bounds_check_array_ctor_8.f90:  New test.
* gfortran.dg/arrayio_0.f90:  Fixed invalid array constructor.
* gfortran.dg/char_cons_len.f90:  Ditto.
* gfortran.dg/char_initializer_actual.f90:  Ditto.
* gfortran.dg/pr15959.f90:  Ditto.
* gfortran.dg/transfer_simplify_2.f90:  Ditto.
* gfortran.dg/char_length_1.f90:  Changed expected error messages.


Added:
trunk/gcc/testsuite/gfortran.dg/bounds_check_array_ctor_1.f90
trunk/gcc/testsuite/gfortran.dg/bounds_check_array_ctor_2.f90
trunk/gcc/testsuite/gfortran.dg/bounds_check_array_ctor_3.f90
trunk/gcc/testsuite/gfortran.dg/bounds_check_array_ctor_4.f90
trunk/gcc/testsuite/gfortran.dg/bounds_check_array_ctor_5.f90
trunk/gcc/testsuite/gfortran.dg/bounds_check_array_ctor_6.f90
trunk/gcc/testsuite/gfortran.dg/bounds_check_array_ctor_7.f90
trunk/gcc/testsuite/gfortran.dg/bounds_check_array_ctor_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/arrayio_0.f90
trunk/gcc/testsuite/gfortran.dg/char_cons_len.f90
trunk/gcc/testsuite/gfortran.dg/char_initialiser_actual.f90
trunk/gcc/testsuite/gfortran.dg/char_length_1.f90
trunk/gcc/testsuite/gfortran.dg/pr15959.f90
trunk/gcc/testsuite/gfortran.dg/transfer_simplify_2.f90


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36112

[Bug fortran/36112] Bounds-checking on character length not working for array-constructors

[domob at gcc dot gnu dot org]

--- 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 |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36112

[Bug inline-asm/36558] New: "V" inline asm constraint not working on sparc64

[jakub at jermar dot eu]

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$ /usr/local/sparc64/bin/sparc64-linux-gnu-gcc -c test.c
test.c: In function 'main':
test.c:9: error: inconsistent operand constraints in an 'asm'

Even though the use of the "m" constraint will fix this testcase, "m" cannot be
used in general, because it allows the operand to be offsetable.  The casx
instruction will not tolerate an offset. According to gcc info page, "V" should
be just like "m", but not offsetable. Wonder why "V" does not work when "m"
does in this case.

Moreover, there are more or less ugly workarounds for this, but this has been
bugging me for some time and I think it should be fixed.

The gcc has been configured using:
configure --target=sparc64-linux-gnu --prefix=/usr/local/sparc64
--program-prefix=sparc64-linux-gnu- --with-gnu-as --with-gnu-ld --disable-nls
--disable-threads --enable-languages=c,objc,c++,obj-c++ --disable-multilib
--disable-libgcj --without-headers --disable-shared

Thanks,
Jakub


-- 
   Summary: "V" inline asm constraint not working on sparc64
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at jermar dot eu
 GCC build triplet: 4.3.1
  GCC host triplet: i486-linux-gnu
GCC target triplet: sparc64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36558

[Bug c/36559] New: Softfloat library support absent for Coldfire

[luigi dot mantellini at idf-hit dot com]

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 configure.

Thanks a lot,

luigi


-- 
   Summary: Softfloat library support absent for Coldfire
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: luigi dot mantellini at idf-hit dot com
  GCC host triplet: x86-pc-linux-gnu
GCC target triplet: m68-uclinux-


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36559

[Bug libstdc++/36552] includes itself: ext/pb_ds/detail/left_child_next_sibling_heap_/null_metadata.hpp

[paolo dot carlini at oracle dot com]

--- 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

 CC||bkoz at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36552

[Bug target/36559] Softfloat library support absent for Coldfire

[luigi dot mantellini at idf-hit dot com]

--- 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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36559

[Bug fortran/36553] [4.4 Regression] regression due to revision 136821

[dominiq at lps dot ens dot fr]

--- 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.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

  GCC build triplet||i686-apple-darwin9
   GCC host triplet||i686-apple-darwin9
 GCC target triplet||i686-apple-darwin9


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553

[Bug target/36559] Softfloat library support absent for Coldfire

[luigi dot mantellini at idf-hit dot com]

--- 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"
/mnt/devel/openwrt/OpenWRT.git/build_dir/toolchain-m68k_gcc4.3.1/gcc-4.3.1/configure
--prefix=/mnt/devel/openwrt/OpenWRT.git/staging_dir/toolchain-m68k_gcc4.3.1
--build=i486-linux-gnu --host=i486-linux-gnu --target=m68k-linux-uclibc
--enable-languages=c --disable-shared
--with-sysroot=/mnt/devel/openwrt/OpenWRT.git/build_dir/toolchain-m68k_gcc4.3.1/uClibc_dev/
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-nls
--disable-libmudflap --disable-multilib

uClibc-0.9.29


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36559

[Bug target/36559] Softfloat library support absent for Coldfire

[pinskia at gcc dot gnu dot org]

--- 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

[Bug target/36559] Softfloat library support absent for Coldfire

[luigi dot mantellini at idf-hit dot com]

--- 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 "-msoft-float" option. Using this
option a lot of refs remain no resolved, of course. I think that the actual
freescale kernel doesn't manage the fpu.

thanks,

luigi


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36559

[Bug target/36559] Softfloat library support absent for Coldfire

[pinskia at gcc dot gnu dot org]

--- 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 ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36559

[Bug target/36559] Softfloat library support absent for Coldfire

[luigi dot mantellini at idf-hit dot com]

--- 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 fp registers ...
> 

Yes. Anyway, the kernel is not able to make a context switching when fp
registers are used... this is a kernel bug of course, whatever the software fp
should be offered to cover these situations.

luigi


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36559

[Bug target/36551] Failure to compile __thread variable.

[dave at hiauly1 dot hia dot nrc dot ca]

--- 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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36551

[Bug fortran/36553] [4.4 Regression] regression due to revision 136821

[jvdelisle at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-06-18 00:18:57
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553

[Bug tree-optimization/36561] New: store using long array index not hoisted out of loop

[hutchinsonandy at gcc dot gnu dot org]

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;
  arr[b+9].X += i;
}
}

Richard Guenther indicates:
> This is because the alias-oracle for store-motion doesn't handle conversions
> to sizetype well in the offset disambiguation.


-- 
   Summary: store using long array  index not hoisted out of loop
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hutchinsonandy at gcc dot gnu dot org
GCC target triplet: avr-unkown-none


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36561

[Bug target/36551] Failure to compile __thread variable.

[carlos at systemhalted dot org]

--- 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.


-- 

carlos at systemhalted dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36551

[Bug ada/36562] New: gnatmake not processing shared library projects

[chrisp_42 at bigpond dot com]

The changes described in
 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.
This results in a softlink from mlib-tgt-specific.adb in the tools build
directory to a non-existent file.  When gnatmake is built the default
mlib-tgt-specific.adb file is used.  Any attempt to use the new gnatmake to
build against a library project results in a failure with an error message
stating libraries are not supported on this platform.

The fix is to change all occurrences of mlib-tgt-x.adb to
mlib-tgt-specific-.adb in gnatlib/configure.ac and to regenerate
gnatlib/configure.  Additionally two occurrences where not updated in
gcc/ada/Makefile.in (*86 kfreebsd and sh4 linux).

A more interesting question (which I have not explored yet) is why the build
silently ignores the bad symlink, and continues on using a default file from
further down the search list.


-- 
   Summary: gnatmake not processing shared library projects
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chrisp_42 at bigpond dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36562

[Bug fortran/36553] [4.4 Regression] regression due to revision 136821

[jvdelisle at gcc dot gnu dot org]

--- 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 -m64,  there are a large
number of variables that change from kind=4 with -m32 to kind=8 with -m64. 
Something is definitely out of whack.

This is looking like a Hiesenbug.  I am going to need help to find this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553

[Bug fortran/36553] [4.4 Regression] regression due to revision 136821

[jvdelisle at gcc dot gnu dot org]

--- 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' (0/3329063047920841327)

$ gfc -m32 -fbounds-check pr36553.f90
$ ./a.out 
 T


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553

[Bug fortran/36553] [4.4 Regression] regression due to revision 136821

[burnus at gcc dot gnu dot org]

--- 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__ (test.f90:29)
==3145==by 0x8048AF8: main (fmain.c:21)

However, this is not different from 4.3. Using NAG f95, I get:
  Warning: line 26: REAL value for INTEGER PARAMETER
  Error:Explicit interface required for CHECK_INTEGER4_RANK1 from ARRAY_TEST -
argument EXPECTED (no. 1) is an assumed-shape array

And for the contained procedure, I don't see any valgrind errors.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553

[Bug c++/36563] New: g++ compiling virtual method

[zlupin at 21cn dot com]

See the result of a3->a3();


#include 
#include 

class A1
{
  private:
char data[100];
  public:
virtual void a1()=0;
};
class A2
{
  private:
char data[33];
  public:
virtual void a2()=0;
};
class A3
{
  private:
char data[10];
  public:
virtual void a3()=0;
};
class B: public A1, public A2
{
  private:
char data[100];
  public:
virtual void a1(){ std::cout<<"B:A1"a2();
  a3->a3();

  return 0;
}


[EMAIL PROTECTED] multid]# ./a.out
b=0x8049290, a1=0x8049290, a2=0x80492f8, a3=0x8049290
B:A1
B:A2
B:A1


-- 
   Summary: g++ compiling virtual method
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zlupin at 21cn dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36563