[Bug c++/35145] New: Mozilla stable branch (1.8) fails to build with gcc 4.3.0

2008-02-08 Thread kengert at redhat dot com
OS environment: Latest Fedora Rawhide nightly tree.
cpp-4.3.0-0.7.i386
libgcc-4.3.0-0.7.i386
libstdc++-4.3.0-0.7.i386
gcc-4.3.0-0.7.i386
gcc-c++-4.3.0-0.7.i386

Attempting to build SeaMonkey 1.1.8, which uses the same tree as stable Firefox
2.0.0.x. (The failure is in the early core components of Mozilla, so the actual
Mozilla variation should be irrelevant)

I don't know yet where the cause of the problem is, it might be in gcc, or it
might be bad Mozilla code.

To make people aware, I have filed additional bugs here:
  https://bugzilla.redhat.com/show_bug.cgi?id=432138
  https://bugzilla.mozilla.org/show_bug.cgi?id=416463


-- 
   Summary: Mozilla stable branch (1.8) fails to build with gcc
4.3.0
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kengert at redhat dot com
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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



[Bug c++/35145] Mozilla stable branch (1.8) fails to build with gcc 4.3.0

2008-02-08 Thread kengert at redhat dot com


--- Comment #2 from kengert at redhat dot com  2008-02-09 05:32 ---
It appears there is some sort of visibility issue, I should have had this idea
earlier because of the "hidden symbol" message shown in the build output.

The mozilla build system has a configuration option to disable the visibility
feature, as I understand it.

Once I pass 
  ac_cv_visibility_pragma=no
to the mozilla configure scripts, it works.

(FYI the comments for that mozilla build option point to gcc bug 26905 and gcc
bug 20297.)


-- 


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



[Bug c++/35145] Mozilla stable branch (1.8) fails to build with gcc 4.3.0

2008-02-14 Thread kengert at redhat dot com


--- Comment #4 from kengert at redhat dot com  2008-02-14 21:35 ---
Andrew, thanks a lot for your comments.
It turns out the bug was indeed caused by Mozilla code, see the Mozilla bug.
Closing as INVALID.


-- 

kengert at redhat dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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



[Bug c/35213] New: 1 << -1 inconsistent across platforms

2008-02-15 Thread kengert at redhat dot com
I personally would never dare to write any code that could result in an
expression like:
  1 << -1

Unfortunately I found some code that uses it.

Eventually I learned that the following code behaves differently on i386 and
ppc64:

  #include 
  int main(int argc, char *argv[])
  {
int shifter = 0;
unsigned int target = 0;
target |= (1 << (shifter -1));
printf("%x\n", target);
  }

On i386, it prints 8000.
On ppc64, it prints 0.


Should gcc be changed to be consistent across platforms?
It might help those that platforms that are being used less frequently.


-- 
   Summary: 1 << -1 inconsistent across platforms
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: kengert at redhat dot com
 GCC build triplet: ppc64-yellowdog-linux
  GCC host triplet: ppc64-yellowdog-linux
GCC target triplet: ppc64-yellowdog-linux


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