--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-06 09:46 ---
Created an attachment (id=17404)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17404&action=view)
gcc44-pr39372.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-06 09:48 ---
Subject: Bug 39387
Author: jakub
Date: Fri Mar 6 09:48:25 2009
New Revision: 144666
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144666
Log:
PR debug/39387
* dwarf2out.c (dwarf2out_imported_
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-06 10:01 ---
Indeed. 0 shouldn't match T U::*
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-06 10:31 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from balrogg at gmail dot com 2009-03-06 10:34 ---
(In reply to comment #2)
> You need to use a "memory" clobber instead. "=X" (params[1]) says to GCC
> that the asm operand 0 should be stored to params[1], which it does
> (it allocates %eax to it).
Note that "=r" doesn'
--- Comment #9 from rob1weld at aol dot com 2009-03-06 11:07 ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
After the workaround we get 10 failures on i686 and 33 failures
on x86_64 when compiling trunk revision 144629, results here:
Results for 4.
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-06 12:48 ---
The problem is that mark_all_vars_used only marks blocks used by actual code,
but on the testcase the only reference to a one BLOCK is from TYPE_MAX_VALUE
(TYPE_DOMAIN (type)) containing a PLUS_EXPR with that BLOCK as
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-06 12:58 ---
Yeah, we should drop TREE_BLOCK from anything not in stmts. Definitely for
expressions in the types sizes and domains.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39367
Another problem with aliasing: The following code snippet triggers a bogus
warning when compiled on trunk with "-O -Wall":
==
#include
struct A
{
A() : i() {}
int i;
};
struct B
{
bool operator() (const A& x, const A&
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39390
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-03-06 13:10
---
Created an attachment (id=17405)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17405&action=view)
Partially reduced testcase
Somewhat reduced testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=393
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-03-06 13:27
---
Oops, typo: I meant the bug is triggered with "-O3 -Wall".
The reduced testcase already triggers the warning with "-O2 -Wall" thanks to
some additional "inline"s.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-06 13:36 ---
Confirmed with the reduced testcase only, at -O2 -Wall. The warning happens
after PTA triggered by SRA.
Relevant constraints:
__y_7 = &s.64+64
D.2839_21 = __y_7
__x.8_43 = D.2839_21
and code:
D.2839_21 = &__y_
ref iec/iso c++ section 3.4.2
gcc correctly reports an error when the argument is one of the fundamental type
and the associated namespace is empty. like the call to 'f' in the attached
example.
However if the argument is a pointer to function the associated name space
should be the one associate
--- Comment #1 from chrbr at gcc dot gnu dot org 2009-03-06 14:05 ---
Created an attachment (id=17406)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17406&action=view)
Example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39391
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-06 14:06 ---
Normally TYPE_MAX_VALUE etc. shouldn't contain anything but constants or
VAR_DECLs after gimplification, gimplify_type_sizes is supposed to take care of
this.
The problem here is that build_new_1 when it creates its VL
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-03-06 14:16 ---
Scheduling another pass_phi_only_cprop after VRP removes the single-argument
PHI nodes (I think that really cfg-cleanup should do this, as they usually
result from edge removal). While this is reasonably cheap it do
--- Comment #6 from algrant at acm dot org 2009-03-06 14:44 ---
Right. The existence of a statically initialized object whose size can
be determined at compile-time to be larger than the (notional) type size,
is specific to GCC. Here's another thing: the assembler output shows
--- Comment #9 from jakub at gcc dot gnu dot org 2009-03-06 15:06 ---
Created an attachment (id=17407)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17407&action=view)
gcc44-pr39367.patch
Patch I'm going to bootstrap/regtest now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-03-06 15:12 ---
Well, the issues in driver seems to be related to pexecute in protoize.c. On a
first glance, I noticed that here for pid's an 'int' type is used (btw in
libiberty a 'long' is used for keeping the pids, which is for w6
--- Comment #47 from alexandre dot nunes at gmail dot com 2009-03-06 15:29
---
Any news on the subject?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-06 15:39 ---
Smaller testcase:
static int a[] = { 1 };
static inline void
bar (int **x)
{
static int *c[2] = { 0, a };
*x = c[1];
}
int
foo (int **x)
{
bar (x);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
--- Comment #48 from amylaar at gcc dot gnu dot org 2009-03-06 15:54
---
Created an attachment (id=17408)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17408&action=view)
patch to take POST_DEC and POST_MODIFY into account
The Copyright assignment issue has been resulved now.
Th
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-06 17:24 ---
I think it is the new:
3384 if (TREE_STATIC (var) && !TREE_ASM_WRITTEN (var))
3385{
3386 if (var_ann (var) && referenced_var_check_and_insert (var))
3387cfun->local_decls = tree_cons (
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-03-06 17:27 ---
Reopening.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #9 from hubicka at ucw dot cz 2009-03-06 17:30 ---
Subject: Re: [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563
> part. So, either tree-inline.c needs to do the same, or it can't use
> referenced_vars bit as a test whether it has been queued already onto
>
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-06 17:53 ---
To "do the same" the easiest would be probably change add_referenced_var to
return bool, whatever referenced_var_check_and_insert returned, and use
add_referenced_var instead of referenced_var_check_and_insert in
expa
Trying to compile latest ffmpeg (ffmpeg-checkout-2009-03-06) Using
mingw-w64-bin_i686-mingw_20090303 I get an ICE on mingw compiling for x64.
$ make
x86_64-pc-mingw32-gcc -DHAVE_AV_CONFIG_H -I. -I"/c/ffmpeg-checkout-2009-03-06"
-D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -std=c99 -D_FILE_OFFSET_BITS
--- Comment #1 from jkolb at wsi dot com 2009-03-06 18:00 ---
Created an attachment (id=17409)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17409&action=view)
Offending Source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
--- Comment #2 from jkolb at wsi dot com 2009-03-06 18:01 ---
Created an attachment (id=17410)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17410&action=view)
#included by h264.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
--- Comment #3 from jkolb at wsi dot com 2009-03-06 18:02 ---
Created an attachment (id=17411)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17411&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-06 18:16 ---
Most likely a duplicate of bug 39360.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39392
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-06 19:11 ---
Created an attachment (id=17412)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17412&action=view)
gcc44-pr39360.patch
Patch I'm bootstrapping/regtesting now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #9 from v dot merkatz at gmx dot net 2009-03-06 22:06 ---
Works fine with gcc 4.3.2.
--
v dot merkatz at gmx dot net changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-06 22:47 ---
Jason, if you think you can fix this by not using a VLA at all, please take
this bug over.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-06 22:49 ---
Subject: Bug 39372
Author: jakub
Date: Fri Mar 6 22:49:39 2009
New Revision: 144682
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144682
Log:
PR debug/39372
* dwarf2out.c (add_abstract_origin
--- Comment #12 from jakub at gcc dot gnu dot org 2009-03-06 22:51 ---
Subject: Bug 39360
Author: jakub
Date: Fri Mar 6 22:51:28 2009
New Revision: 144683
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144683
Log:
PR middle-end/39360
* tree-flow.h (add_reference
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-06 22:52 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #13 from jakub at gcc dot gnu dot org 2009-03-06 22:53 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from paolo at gcc dot gnu dot org 2009-03-06 23:52 ---
Subject: Bug 33492
Author: paolo
Date: Fri Mar 6 23:52:02 2009
New Revision: 144686
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144686
Log:
/cp
2009-03-06 Paolo Carlini
PR c++/33492
* e
--- Comment #7 from paolo dot carlini at oracle dot com 2009-03-06 23:53
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #14 from linuxl4 at sohu dot com 2009-03-07 00:12 ---
thanks a lot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39360
On an x86_64 bit machine, if an attempt to compile code containing an invalid
instruction is attempted, an error will correctly occur:
cat /etc/testasm.c
int main(void)
{
asm("cpuid"); /* Invalid on the i386 */
}
gcc -march=i386 -Wa,-march=i386 testasm.c
Error: `cpuid' is not support
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-07 01:01 ---
Since this is an inline-asm, it gets processed by the assembler and not GCC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-07 01:31 ---
(In reply to comment #0)
> On an x86_64 bit machine, if an attempt to compile code containing an invalid
> instruction is attempted, an error will correctly occur:
>
> cat /etc/testasm.c
> int main(void)
> {
> a
--- Comment #20 from hjl at gcc dot gnu dot org 2009-03-07 01:47 ---
Subject: Bug 37520
Author: hjl
Date: Sat Mar 7 01:47:25 2009
New Revision: 144692
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144692
Log:
2009-03-06 H.J. Lu
PR c++/37520
* cp-tree.h: Che
--- Comment #21 from hjl dot tools at gmail dot com 2009-03-07 01:48
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from markhobley at yahoo dot co dot uk 2009-03-07 02:40
---
Subject: Re: invalid instructions accepted in inline assembly language on 32
bit machines
--- On Sat, 7/3/09, hjl dot tools at gmail dot com
wrote:
> I got
>
> h...@gnu-9 tmp]$ gcc -march=i386 -Wa,-march=i3
--- Comment #16 from galtgendo at o2 dot pl 2009-03-07 04:30 ---
OK, I've done a little test and I'd like to know,
if it's results actually mean anything:
I've compiled freeciv with CFLAGS="-O2 -finline-functions
-fno-guess-branch-probability" and it did not crash.
Does the above confir
Sent from my iPhone
On Mar 6, 2009, at 8:30 PM, "galtgendo at o2 dot pl" > wrote:
--- Comment #16 from galtgendo at o2 dot pl 2009-03-07 04:30
---
OK, I've done a little test and I'd like to know,
if it's results actually mean anything:
I've compiled freeciv with CFLAGS="-O2 -f
--- Comment #17 from pinskia at gmail dot com 2009-03-07 04:35 ---
Subject: Re: gcc 4.3.3 miscompiles when -finline-small-functions is used
Sent from my iPhone
On Mar 6, 2009, at 8:30 PM, "galtgendo at o2 dot pl" wrote:
>
>
> --- Comment #16 from galtgendo at o2 dot pl 2009-0
gfaults at argp-help.c
It has been like that for about two weeks. This machine attempts to compile
gcc-svn and glibc daily. Sometimes it works sometimes not.
I tested with glibc 2.9 and gcc appears to still segfault.
--
Summary: gcc 4.4.0 20090306 segfaults at argp-help.c in
53 matches
Mail list logo
