[Bug middle-end/32441] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:7109

2007-07-06 Thread zack at gcc dot gnu dot org 


--- Comment #8 from zackw at panix dot com  2007-07-06 17:58 ---
Subject: Bug 32441

Author: zack
Date: Fri Jul  6 17:57:58 2007
New Revision: 126424

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126424
Log:
2007-07-06  Ian Lance Taylor  <[EMAIL PROTECTED]>
Zack Weinberg  <[EMAIL PROTECTED]>

PR middle-end/32441
* builtins.c (std_expand_builtin_va_start): Don't use make_tree.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c


-- 


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

[Bug middle-end/18897] [4.0 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: putchar (first referenced in build/gengenrtl.o) (data)

2004-12-17 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2004-12-18 06:42 
---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)

2005-01-06 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2005-01-07 07:10 
---
Joseph - I never properly answered your question in comment #7, although
arguably the answer is already in comment #4.

I should mention I take as a basic premise that without exception, a sequence of
UCNs and a sequence of extended-source-character-set characters (which both
encode the same sequence of ISO10646 code points) should be treated identically.
 Therefore, I'm going to talk exclusively about code points below.

The scenario that causes ABI breakage is as follows:

1) A shared library author gives an exported interface function a name
containing, for instance, U+212B ANGSTROM SIGN.

2) This is compiled with a compiler that, hewing to the letter of the standard, 
does not perform any normalization.  The shared library's symbol table therefore
also contains U+212B.  That code point is now part of the library ABI.

3) A program that uses this library is compiled with the same compiler; it
expects a symbol containing U+212B.

4) Later, someone recompiles the library with a compiler that applies NFC to all
identifiers.  The library now exports a symbol containing U+00C5 LATIN CAPITAL
LETTER A WITH RING ABOVE.  The program compiled in step 3 breaks.

An obvious rebuttal to this is that the compiler used in step 4 is broken.  As
you say, the C standard references ISO10646 not Unicode and the concept of
normalization does not exist in ISO10646, and this could be taken to imply that
no normalization shall occur.  However, there is no unambiguous statement to
that effect in the standard, and there is strong quality-of-implementation
pressure in the opposite direction.  Put aside the standard for a moment: are
users going to like a compiler that insists that "Å" (U+00C5) and "Å" 
(U+212B)
are not the same character?  [It happens that on my screen those are ever so
slightly different, but that's just luck - and X11 will only let me type U+00C5;
I resorted to hex-editing to get the other.]

Furthermore, I can easily imagine someone writing a Unicode-aware text editor
and thinking it's a good idea to convert every file to NFC when saved.  Making
some unrelated change to the file defining the symbol with U+212B in it, with
this editor, would trigger the exact same ABI break that the hypothetical
normalizing compiler would.  This possibility means that a WG14/21
no-normalization mandate would NOT prevent silent ABI breakage.  And the
existence of this possibility increases the QoI pressure for a compiler to do
normalization, as a defensive measure against such external changes.  You could
argue that this is just another way for C programmers to shoot themselves in the
foot, but I don't think the myriad ways that already exist are a reason to add 
more.

For these reasons I see no safe way to implement extended identifiers except to
persuade both WG14 and WG21 to mandate use of UAX#15 annex 7, instead of the
existing lists of allowed characters.  I'm willing to consider other
normalization schemas and sets of allowed characters (as long as C and C++ are
consistent with each other) but not plans which don't include normalization.  To
address the concern about requiring huge tables, perhaps the standards could say
that it is implementation-defined whether extended characters are allowed at 
all.

-- 


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

[Bug c++/19583] New: Incorrect diagnostic: control may reach end of non-void function '...' being inlined

2005-01-22 Thread zack at gcc dot gnu dot org 
$ /scratch/zack/i/gcc-vanilla/bin/g++ -v
Using built-in specs.
Configured with: /home/zack/src/gcc/HEAD/vanilla/configure
--prefix=/scratch/zack/i/gcc-vanilla --disable-checking --enable-languages=c,c++
--disable-multilib
Thread model: posix
gcc version 4.0.0 20050122 (experimental)

$ /scratch/zack/i/gcc-vanilla/bin/g++ -S -O2 -W -Wall testcase.cc
testcase.cc: In function ‘void finalize()’:
testcase.cc:29: warning: control may reach end of non-void function ‘bool
N::operator!=(N) const’ being inlined

I will attach the testcase.

-- 
   Summary: Incorrect diagnostic: control may reach end of non-void
function '...' being inlined
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: minor
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zack at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/19583] Incorrect diagnostic: control may reach end of non-void function '...' being inlined

2005-01-22 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2005-01-23 05:08 
---
Created an attachment (id=8039)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8039&action=view)
test case


-- 


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

[Bug c++/19583] Incorrect diagnostic: control may reach end of non-void function '...' being inlined

2005-01-22 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2005-01-23 05:11 
---
Created an attachment (id=8040)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8040&action=view)
shorter test case


-- 
   What|Removed |Added

Attachment #8039 is|0   |1
   obsolete||


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

[Bug rtl-optimization/17958] New: expand_divmod fails to optimize division of 64-bit quantity by small constant when BITS_PER_WORD is 32

2004-10-12 Thread zack at gcc dot gnu dot org 
expand_divmod cannot optimize code such as

long long div10(long long n) { return n / 10; }

when BITS_PER_WORD is 32.  A call to __divdi3 gets generated.  By contrast, when
BITS_PER_WORD is 64, this is optimized to a multiply and a shift.  I noticed
this problem on powerpc32, but it ought to affect any 32-bit target.

-- 
   Summary: expand_divmod fails to optimize division of 64-bit
quantity by small constant when BITS_PER_WORD is 32
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: rtl-optimization
AssignedTo: roger at eyesopen dot com
ReportedBy: zack at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-*-*


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

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

2004-10-27 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2004-10-27 17:18 ---
(From update of attachment 7415)
fix mime type, mark as patch


-- 
   What|Removed |Added

   Attachment #7415|text/x-patch|text/plain
  mime type||
Attachment #7415 is|0   |1
  patch||


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

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

2004-10-27 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2004-10-27 17:31 ---
fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug java/17265] [4.0 Regression] Libjava doesn't build

2004-10-27 Thread zack at gcc dot gnu dot org 


-- 
Bug 17265 depends on bug 18075, which changed state.

Bug 18075 Summary: [4.0 Regression] #pragma implementation broken in presence of 
#pragma ident
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18075

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug debug/18199] [4.0 Regression] AIX XCOFF debugging broken

2004-10-28 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2004-10-28 21:01 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/6123] __pic__/__PIC__ not defined when -fpic/-fPIC is specified

2004-11-08 Thread zack at gcc dot gnu dot org 


-- 
   What|Removed |Added

  BugsThisDependsOn||18382


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

[Bug c/18382] New: define __pic__ and/or __PIC__ in c-cppbuiltins.c instead of scattershot in target config

2004-11-08 Thread zack at gcc dot gnu dot org 
The __pic__ and __PIC__ macros are currently defined scattershot in target
configuration files, some using specs %{pic:-D...} notation and some using
builtin_define() from TARGET_*_CPP_BUILTINS.  It would be better to define
them in a consistent fashion (__pic__ only if -fpic, both if -fPIC) in
c-cppbuiltin.c.  See bug 6123 for examples of what this would help.

I'm tasking myself with this, but I'm not going to do it until 4.1.

-- 
   Summary: define __pic__ and/or __PIC__ in c-cppbuiltins.c instead
of scattershot in target config
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: c
AssignedTo: zack at gcc dot gnu dot org
ReportedBy: zack at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: *-*-*
OtherBugsDependingO 6123
 nThis:


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

[Bug c/18382] define __pic__ and/or __PIC__ in c-cppbuiltins.c instead of scattershot in target config

2004-11-08 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2004-11-08 20:36 
---
accept, set milestone.

Just to be clear, I'm not doing this until 4.1 because global changes to target
configury would be too destabilizing right now.  We can live with scattershot
for one more release.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-08 20:36:12
   date||
   Target Milestone|--- |4.1.0


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

[Bug target/6123] __pic__/__PIC__ not defined when -fpic/-fPIC is specified

2004-11-08 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2004-11-08 20:37 
---
I've filed bug 18382 for the general solution to this problem.

-- 


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

[Bug c/14411] Request for setjmp/longjmp attributes

2004-11-29 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2004-11-30 07:47 
---
+kw, milestone; assigning to myself for commitment once 4.1 opens.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |zack at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Keywords||patch
   Target Milestone|--- |4.1.0


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

[Bug bootstrap/18804] [4.0 Regression] lib2funcs.vis:1: Error: unknown pseudo-op: `.hidden'

2004-12-03 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2004-12-04 03:38 
---
The question is then why -fvisibility=hidden -Werror does not cause the compiler
to exit unsuccessfully.  libgcc.mk uses that incantation to determine whether
.hidden is supported.


-- 


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

[Bug middle-end/17982] stop calling assemble_external before final assembly output time

2004-12-08 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2004-12-08 22:04 
---
Uh, no, it's not fixed.  It is, however, papered over adequately for 4.0.  I'm
turning this into a 4.1 enhancement PR.

http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00491.html explains what needs to
happen for 4.1.

-- 
   What|Removed |Added

OtherBugsDependingO|18632   |
  nThis||
   Severity|critical|enhancement
 Status|RESOLVED|REOPENED
   Keywords|patch, wrong-code   |
 Resolution|FIXED   |
Summary|[4.0 regression] asm|stop calling
   |declaration ignored due to  |assemble_external before
   |conflict with previous  |final assembly output time
   |rename  |
   Target Milestone|4.0.0   |4.1.0


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

[Bug middle-end/17982] stop calling assemble_external before final assembly output time

2004-12-08 Thread zack at gcc dot gnu dot org 

--- Additional Comments From zack at gcc dot gnu dot org  2004-12-08 22:05 
---
... and assigning to self.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |zack at gcc dot gnu dot org
   |dot org |
 Status|REOPENED|ASSIGNED


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