[Bug rtl-optimization/25899] [4.2 Regression] ACATS c34006a cc1226b failure on x86
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-01-25 08:01
---
Same problem for cc1226b:
26.life1:
(insn 10 9 11 2 cc1226b.adb:28 (set (strict_low_part (subreg:QI (reg:DI 83 [
D.717 ]) 4))
(const_int 1 [0x1])) 46 {*movstrictqi_1} (insn_list:REG_DEP_TRUE 200
(nil))
(nil))
(insn 11 10 13 2 cc1226b.adb:28 (set (subreg:SI (reg:DI 83 [ D.717 ]) 0)
(const_int 5 [0x5])) 34 {*movsi_1} (insn_list:REG_DEP_TRUE 10 (nil))
(nil))
(insn 13 11 14 2 cc1226b.adb:28 (set (strict_low_part (subreg:QI (reg/v:DI 85 [
pack__ndvar ]) 4))
(subreg:QI (reg:DI 83 [ D.717 ]) 4)) 46 {*movstrictqi_1}
(insn_list:REG_DEP_TRUE 201 (insn_list:REG_DEP_TRUE 11 (nil)))
(expr_list:REG_DEAD (reg:DI 83 [ D.717 ])
(nil)))
(insn 14 13 15 2 cc1226b.adb:28 (set (subreg:SI (reg/v:DI 85 [ pack__ndvar ])
0)
(const_int 5 [0x5])) 34 {*movsi_1} (insn_list:REG_DEP_TRUE 13 (nil))
(nil))
27.combine:
(note 10 9 11 2 NOTE_INSN_DELETED)
(note 11 10 13 2 NOTE_INSN_DELETED)
(note 13 11 14 2 NOTE_INSN_DELETED)
(note 14 13 15 2 NOTE_INSN_DELETED)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug libstdc++/25956] New: Memory error when dynamic linking STL specializations
Summay:
I've found what appears to be a bug when using new basic_string specializations
in dynamically linked code under OS X. The 'bug' exhibits itself when you
create a new string of your custom type with zero length. As you all probably
know, basic_string has a static struct (accessed via _S_empty_rep() ) that it
assigns as the data value when this is the case. The problem is that when the
destructor is called the class is trying to free the placeholder struct
(something that should never happen). It causes the program to output an error
which is as follows:
malloc: *** Deallocation of a pointer not malloced: 0x18078; This could be a
double free(), or free() called with the middle of an allocated block; Try
setting environment variable MallocHelp to see tools to help debug
Steps to Reproduce:
Theu bug can be reproduced by creating a dynamic library (either a framework or
a dylib) with the following code in and then linking to and calling that code
from your main binary:
#include iostream
#include locale
#include ext/pod_char_traits.h
typedef __gnu_cxx::characteruint16_t, int CharType;
typedef std::char_traitsCharType TraitType;
typedef std::basic_stringCharTypeUTFString;
class TestClass
{
public:
UTFString Test();
};
UTFString TestClass::Test( )
{
CharType s1[] = { '\0' };
return s1;
}
I have dug in with the debugger to see what I could find out, and as far as I
can tell there are different instances of _S_empty_rep hanging around when it
is dynamically linked, though Im not entirely certain. Whatever it is,
something is causing the destructor to think that it is not looking at
_S_empty_rep but at a real string.
Expected Results:
No error message from free.
Actual Results:
The above warning is emitted in the console.
Regression:
I have tested the same code on Linux under x86_64 and also 10.4.4 on an Intel
Mac. Neither of those platforms exhibit the same behaviour.
Notes:
I have filed this bug with Apple, and also mailed the developer list for
libstdc++ to see if anyone knows anything.
--
Summary: Memory error when dynamic linking STL specializations
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkp at kirkconsulting dot co dot uk
GCC build triplet: 10.4.4
GCC host triplet: Mac OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25956
[Bug libstdc++/25956] Memory error when dynamic linking STL specializations
--- Comment #1 from jkp at kirkconsulting dot co dot uk 2006-01-25 08:52 --- Created an attachment (id=10726) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10726action=view) XCode project with test case The project includes three targets - the main application, a dylib and a static lib. If you play with the membership of the targets in the main app you can see how staticlly linking the code will make the issue go away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25956
[Bug libfortran/20257] Fortran runtime error: End of record occurs when writing large arrays
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-01-25 09:32 --- (In reply to comment #6) I don't see this problem any more. Was this fixed? Is the default record length an issue any more? Can we close this PR? I wonder if the fix to P25835 fixed this? If so I propose we close this unless it is related to the new PR Janne is working on, large records with little writes, 25949. As I said in comment #5, the limit was just pushed higher, but big writes on preconnected units still fail: $ gfortran a.f90 ./a.out bigfile At line 3 of file a.f90 Fortran runtime error: End of record $ cat a.f90 real :: array(1) array(:) = 0 write(*,*) array end $ ll bigfile -rw-r--r-- 1 coudert users 1.0G Jan 25 10:28 bigfile $ gfortran -v Using built-in specs. Target: i386-linux Configured with: ../gcc/configure --prefix=/tmp/gfortran-20060124/irun --enable-languages=c,fortran --host=i386-linux --with-gmp=/tmp/gfortran-20060124/gfortran_libs Thread model: posix gcc version 4.2.0 20060124 (experimental) You can look at the patch cited in comment #5 for where the problem lies. And this is not really related to Janne's PR, I guess. It's specific to preconnected units. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20257
[Bug libgomp/25910] [4.2 Regression] bootstrap failure
--- Comment #6 from aldot at gcc dot gnu dot org 2006-01-25 10:14 ---
fla=-W -Wall -Wextra -march=pentium4 -mtune=pentium4 -O0 -g -ggdb
BOOT_CC=gcc-4.0 CFLAGS=$fla CXXFLAGS=$fla BOOT_CFLAGS=$fla ../../src/${
what}-${ver}/configure -v --enable-languages=c,c++,fortran,treelang
--prefix=/op
t/gcc-${ver}/ --enable-shared --with-system-zlib
--libexecdir=/opt/gcc-${ver}/li
b --enable-nls --without-included-gettext --enable-threads=posix
--program-suffi
x=-${ver}-HEAD --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-cl
ocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-werror
--enable-check
ing=release --enable-debug i686-linux-gnu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25910
[Bug c/25955] [4.1/4.2 Regression] value computed not used warning with cast return value
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-25 10:44 --- Confirmed. I wouldn't say the cast is an extra computation here - and we don't warn without it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i486-slackware-linux| GCC target triplet|i686-pc-linux-gnu | Keywords||diagnostic Known to fail||4.1.0 4.2.0 Known to work||4.0.2 Last reconfirmed|-00-00 00:00:00 |2006-01-25 10:44:51 date|| Summary|regression: value computed |[4.1/4.2 Regression] value |not used warning with cast |computed not used warning |return value|with cast return value http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25955
[Bug c/25954] external variable address assumed not to be zero
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-25 10:46 --- The address of the variable cannot be zero. If you want to play some dynamic loading trick you have to mark the symbol weak. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25954
[Bug c++/25943] Options added to collect2
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-25 10:48 --- The best way to address this is to try implementing this yourself and post patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25943
[Bug c++/25940] multiple definitions of extern C functions
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-25 10:52 ---
Shorter testcase:
namespace N1 {
extern C int func (int);
int func (int) {}
};
namespace N2 {
extern C int func (int);
int func (int) {}
};
not a regression from anything. Not dependent on weird cross configuration.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|sparc-sun-solaris2.5.1 |
GCC host triplet|i386-pc-mingw32 |
GCC target triplet|powerpc-wrs-vxworks |
Known to fail||3.4.5 4.0.2 4.1.0 4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25940
[Bug middle-end/25957] New: -fstack-protector code on i386/x86-64 can be improved.
Compiling this simple test case with
GNU C version 4.2.0 20060118 (experimental) (x86_64-unknown-linux-gnu)
extern void f2(char *s);
void f(void)
{
char x[100];
f2(x);
}
i get
...
xorq__stack_chk_guard(%rip), %rax
jne .L5
addq$120, %rsp
ret
.L5:
.p2align 4,,5
call__stack_chk_fail
Suggestions for improvement:
- It shouldn't use p2align 4,,5 for the __stack_chk_fail trampoline
because that wastes space in very infrequent code
- It should use jne to jump the function directly because it
should never return (when it is called the stack is compromised
and it would be a security hole)
--
Summary: -fstack-protector code on i386/x86-64 can be improved.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ak at muc dot de
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25957
[Bug ada/18659] [4.2 Regression] ACATS failures c32001e c64105b c95086b
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2006-01-25 11:38 --- Working on it again. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-11-22 10:44:43 |2006-01-25 11:38:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18659
[Bug c/12963] Wrong and misleading warning encourages writing non-portable code
--- Comment #19 from bagnara at cs dot unipr dot it 2006-01-25 11:39
---
Just a small update. On one of our projects we have now thousands of warnings
on the test x 0 for the function below, when Type is instantiated to an
unsigned integral type:
template typename Type
inline Result
sgn_generic(const Type x) {
if (x 0)
return V_LT;
if (x 0)
return V_GT;
return V_EQ;
}
The net result is that some of us started using -w or stopped paying
attention to warnings, and, as a consequence bugs are creeping in at a much
increased rate. Please, give us a way to at least turn off that warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
[Bug c/12963] Wrong and misleading warning encourages writing non-portable code
--- Comment #20 from pcarlini at suse dot de 2006-01-25 12:20 ---
(In reply to comment #19)
Just a small update. On one of our projects we have now thousands of warnings
on the test x 0 for the function below, when Type is instantiated to an
unsigned integral type:
template typename Type
inline Result
sgn_generic(const Type x) {
if (x 0)
return V_LT;
if (x 0)
return V_GT;
return V_EQ;
}
A side remark, about a weird workaround I had to use in the past in the library
(yes the problem is real, I agree, not sure about the best solution, however).
Would boil down to something like (mosulo stupid typos ;)
if (x 0)
return V_GT;
else if (x)
return V_LT;
return V_EQ;
Seems correct to me and doesn't incur in any warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
[Bug c/25955] [4.1/4.2 Regression] value computed not used warning with cast return value
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-25 13:06 --- Actually we want to warn see PR 24900. *** This bug has been marked as a duplicate of 24900 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25955
[Bug middle-end/24900] [4.1 Regression] new value computed is not used warning in gcc 4.1
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-25 13:06 --- *** Bug 25955 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mike at codeweavers dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24900
[Bug middle-end/25957] -fstack-protector code on i386/x86-64 can be improved.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-25 13:21 --- Nope and Nope. The alignment is because well -falign-jumps is default. __stack_chk_fail is a noreturn function so we don't sib call it because it would be too hard for debugging. Second jumping directly via an indirect branch is wrong as jumps only have a certain range. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25957
[Bug rtl-optimization/25899] [4.2 Regression] ACATS c34006a cc1226b failure on x86
--- Comment #20 from hubicka at ucw dot cz 2006-01-25 13:43 ---
Subject: Re: [4.2 Regression] ACATS c34006a cc1226b failure on x86
Very good catch! Here is C testcase. I need to setup testing, then I
will try to debug the problem in combiner.
Honza
struct a
{
int a;
char b,c,d,e;
};
__attribute__ ((noinline))
__attribute__ ((regparm(1))) t(struct a a)
{
if (a.a!=1 || a.b!=1 || a.c!=1)
abort();
}
main()
{
struct a a;
a.c=1;
a.a=1;
a.b=1;
t(a);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug rtl-optimization/25899] [4.2 Regression] ACATS c34006a cc1226b failure on x86
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2006-01-25 13:52 --- Very good catch! Here is C testcase. I need to setup testing, then I will try to debug the problem in combiner. Don't bother, it's duplicate of 25703, assigned to Roger. *** This bug has been marked as a duplicate of 25703 *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug rtl-optimization/25703] [4.2 Regression] ACATS cxa4024 failure
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-01-25 13:52 --- *** Bug 25899 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug objc++/25958] New: [4.2 Regression] Objective-C++ is broken a different way
From http://gcc.gnu.org/ml/gcc/2006-01/msg00953.html: The following: 2006-01-23 Volker Reichelt [EMAIL PROTECTED] * cp-tree.h (do_poplevel): Remove prototype. * semantics.c (do_poplevel): Add prototype. Make static. Is a plain mistake due to: ../.././gcc/objcp/objcp-decl.c: In function 'tree_node* objcp_end_compound_stmt(tree_node*, int)': ../.././gcc/objcp/objcp-decl.c:114: error: 'do_poplevel' was not declared in this scope ../.././gcc/objcp/objcp-decl.c:118: error: 'do_poplevel' was not declared in this scope -- Summary: [4.2 Regression] Objective-C++ is broken a different way Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ 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=25958
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2006-01-25 14:07 --- Subject: Bug 18819 Author: ebotcazou Date: Wed Jan 25 14:06:59 2006 New Revision: 110213 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110213 Log: PR ada/18819 * exp_util.adb (Remove_Side_Effects): Lift enclosing type conversion nodes for elementary types in all cases. Modified: branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/exp_util.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug objc++/25958] [4.2 Regression] Objective-C++ is broken a different way
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25958
[Bug ada/18819] [4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2006-01-25 14:08 --- Should be fixed on 4.1 branch. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | Summary|[4.1/4.2 Regression] ACATS |[4.2 Regression] ACATS |cdd2a01 cdd2a02 fail at |cdd2a01 cdd2a02 fail at |runtime |runtime http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug middle-end/25957] -fstack-protector code on i386/x86-64 can be improved.
--- Comment #2 from ak at muc dot de 2006-01-25 14:15 --- You're wrong. On i386 and x86-64 call and conditional jumps have the same range. That you're using the normal align-jumps for such uncommon code is a bug in my opinion and that is why I opened this request. It is a waste of space for code that is known to be uncommon at compile time like this. The debugging argument seems bogus in this case too. You'll see the original function in the backtrace, but that is ok here. -- ak at muc dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25957
[Bug middle-end/25957] -fstack-protector code on i386/x86-64 can be improved.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-25 14:21 --- Actually you will not see the correct backtrace, you will see the function which calls f and not f itself. The alignment only saves instruction space it does nothing really -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25957
[Bug c++/25959] New: [4.2 Regression] C++ does not build on powerpc-*
rs6000-c.c use default_conversion which was turned into a static function in the C++ front-end by: 006-01-25 Volker Reichelt [EMAIL PROTECTED] * cp-tree.h (get_primary_binfo): Remove prototype. (push_using_decl): Likewise. (current_template_args): Likewise. (more_specialized_class): Likewise. (mark_class_instantiated): Likewise. (default_conversion): Likewise. (pfn_from_ptrmemfunc): Likewise. * class.c (get_primary_binfo): Add prototype, make static, simplify. * name-lookup.c (push_using_decl): Make static. * pt.c (current_template_args): Likewise. (more_specialized_class): Likewise. (mark_class_instantiated): Likewise. * typeck.c (default_conversion): Make static. (pfn_from_ptrmemfunc): Add prototype, make static. -- Summary: [4.2 Regression] C++ does not build on powerpc-* Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: powerpc-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25959
[Bug c++/25959] [4.2 Regression] C++ does not build on powerpc-*
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25959
[Bug other/25925] [meta-bug] 4.2 slush bug
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-25 14:28 --- PR 25959: C++ building on powerpc-* is broken. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25959 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25925
[Bug middle-end/25957] -fstack-protector code on i386/x86-64 can be improved.
--- Comment #4 from ak at muc dot de 2006-01-25 14:30 --- Yes that's the whole point of the bug. To save code space and precious icache. -- ak at muc dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25957
[Bug target/25960] New: __gcc_add doesn't handle -0.0L properly
volatile long double l, m, n;
extern void abort (void);
int
main (void)
{
l = __builtin_copysignl (0.0L, -1.0L);
m = __builtin_copysignl (0.0L, -1.0L);
n = l + m;
if (__builtin_copysignl (1.0L, n) = 0.0L)
abort ();
return 0;
}
fails on ppc*-linux with -mlong-double-128, -0.0 + -0.0 gives 0.0 rather than
expected -0.0.
--
Summary: __gcc_add doesn't handle -0.0L properly
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25960
[Bug middle-end/25957] -fstack-protector code on i386/x86-64 can be improved.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-25 14:33 --- Use -Os for that. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25957
[Bug middle-end/25957] -fstack-protector code on i386/x86-64 can be improved.
--- Comment #6 from ak at muc dot de 2006-01-25 14:38 --- -Os is only when there should be a trade off between size and performance. But there isn't any performance consideration here because this code is only executed on program abort. (is there a button to reassign the bug to a non braindead bugmaster?) -- ak at muc dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25957
[Bug target/25960] __gcc_add doesn't handle -0.0L properly
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-25 14:39 --- Confirmed on powerpc-darwin also which uses IBM's 128bit long double format by default. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||geoffk at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|powerpc*-linux |powerpc*-* Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-01-25 14:39:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25960
[Bug middle-end/25957] -fstack-protector code on i386/x86-64 can be improved.
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-25 14:43 --- The alignment does nothing, repeat nothing even if it is not executed that much, it does not change anything because it is last in the function. Try compiling more than this simple example and you will see that it always last for the emitted asm. Use -fno-align-jumps which is not default on x86. And as I have mentioned before jumping directly to the other function is not useful at all (I already filed that bug and was shot down by RTH). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25957
[Bug middle-end/25957] -fstack-protector code on i386/x86-64 can be improved.
--- Comment #8 from steven at gcc dot gnu dot org 2006-01-25 14:46 --- It seems to me that not aligning jumps for known infrequent jumps may be useful. Especially when you get so many of them as you do with ssp. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25957
[Bug fortran/24557] ICE: PRINTing function result of size depending on assumed length CHARACTER dummy
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-01-25
14:52 ---
The code is really crazy for this example. Please note that I have Jakub's
nongomp type patch in place. This bug is independent of the completeness of
the types, however.
The problem is that the character length of the DUMMY argument is somehow being
referenced in the main program. This aberrant behaviour is somehow associated
with the IO transfer.
MAIN__ ()
{
char a[2][1:4];
static void fun (struct array1_int4 , struct array1_unknown , int4);
{
struct __st_parameter_dt dt_parm.8;
dt_parm.8.common.filename = pr24557.f90;
dt_parm.8.common.line = 5;
dt_parm.8.common.unit = 6;
dt_parm.8.common.flags = 128;
_gfortran_st_write (dt_parm.8);
{
void * D.840;
int4 D.839;
struct array1_int4 atmp.12;
int4 D.837;
int4 D.836;
int4 D.835;
struct array1_unknown parm.11;
int4 D.833;
int4 D.832;
char[0:][1:_arg] * parm.10; /**Here**/
struct array1_unknown * D.830;
struct array1_unknown parm.9;
parm.9.dtype = 305;
parm.9.dim[0].lbound = 1;
parm.9.dim[0].ubound = 2;
parm.9.dim[0].stride = 1;
parm.9.data = (void *) (char[0:][1:4] *) a[0];
parm.9.offset = 0;
D.830 = parm.9;
parm.10 = (char[0:][1:_arg] *) (char[0:][1:4] *) D.830-data; /*Here*/
D.832 = D.830-dim[0].ubound - D.830-dim[0].lbound + 1;
D.833 = -D.830-dim[0].stride;
parm.11.dtype = ((unnamed type) _arg 6) + 49;/***and here***/
D.835 = D.830-dim[0].stride;
parm.11.dim[0].lbound = 1;
parm.11.dim[0].ubound = D.832;
parm.11.dim[0].stride = NON_LVALUE_EXPR D.835;
parm.11.data = (void *) (char[0:][1:_arg] *) (*parm.10)[0]; /*here*/
parm.11.offset = 0;
D.836 = _gfortran_size0 (parm.11);
D.837 = D.836 - 1;
atmp.12.dtype = 265;
atmp.12.dim[0].stride = 1;
atmp.12.dim[0].lbound = 0;
atmp.12.dim[0].ubound = NON_LVALUE_EXPR D.837;
D.839 = NON_LVALUE_EXPR D.837 + 1;
D.840 = _gfortran_internal_malloc (D.839 * 4);
atmp.12.data = D.840;
atmp.12.offset = 0;
atmp.12.dim[0].stride = 0;
fun (atmp.12, D.830, 4);/* After the call, all is well.*/
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24557
[Bug middle-end/25957] -fstack-protector code on i386/x86-64 can be improved.
--- Comment #9 from ak at muc dot de 2006-01-25 14:55 --- Again the alignment wastes precious icache which is enough reason to get rid of it. If there are a lot of such functions it will also lead to worse paging behaviour on big programs. Can you explain again why it was shot down? Because of the missing frame in the stack backtrace or something else? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25957
[Bug rtl-optimization/25899] [4.2 Regression] ACATS c34006a cc1226b failure on x86
--- Comment #22 from hjl at lucon dot org 2006-01-25 14:57 --- Can we add this C testcase to gcc testsuite? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug c++/25959] [4.2 Regression] C++ does not build on powerpc-*
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-25 15:12 --- Fixed by: Revert: * cp-tree.h (do_poplevel): Remove prototype. * semantics.c (do_poplevel): Add prototype. Make static. Revert: * cp-tree.h (default_conversion): Remove prototype. * typeck.c (default_conversion): Make static. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25959
[Bug objc++/25958] [4.2 Regression] Objective-C++ is broken a different way
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-25 15:13 --- Fixed by: Revert: * cp-tree.h (do_poplevel): Remove prototype. * semantics.c (do_poplevel): Add prototype. Make static. Revert: * cp-tree.h (default_conversion): Remove prototype. * typeck.c (default_conversion): Make static. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25958
[Bug c++/25950] [3.4/4.0/4.1] [DR 391] Reference binding and explicit copy constructors
--- Comment #18 from gdr at cs dot tamu dot edu 2006-01-25 15:51 --- Subject: Re: [3.4/4.0/4.1] [DR 391] Reference binding and explicit copy constructors mmitchel at gcc dot gnu dot org [EMAIL PROTECTED] writes: | This is certainly not a P1 for 4.1. If it's a bug (it probably is, but I still | want to think about it more), it's a minor one, in the grand scheme of things. Howard raised the issue on the -core reflector. See c++std-core-11265 when Mike expessed the same opinion as me in previous comments. It is ill-formed in C++03 (GCC behaviour is correct). However, it is no longer the same behaviour after the last changes voted in the working paper. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25950
[Bug testsuite/25590] [4.1/4.2 regression] FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vectorized 1 loops 1
--- Comment #12 from kazu at gcc dot gnu dot org 2006-01-25 16:08 --- Subject: Bug 25590 Author: kazu Date: Wed Jan 25 16:08:26 2006 New Revision: 110215 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110215 Log: PR testsuite/25590 * gcc.dg/tree-ssa/gen-vect-11.c: Add -fwrapv. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25590
[Bug testsuite/25590] [4.1/4.2 regression] FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vectorized 1 loops 1
--- Comment #13 from kazu at gcc dot gnu dot org 2006-01-25 16:11 --- Subject: Bug 25590 Author: kazu Date: Wed Jan 25 16:11:17 2006 New Revision: 110216 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110216 Log: PR testsuite/25590 * gcc.dg/tree-ssa/gen-vect-11.c: Add -fwrapv. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25590
[Bug testsuite/25590] [4.1/4.2 regression] FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vectorized 1 loops 1
--- Comment #14 from kazu at gcc dot gnu dot org 2006-01-25 16:11 --- Just checked in a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25590
[Bug c/25929] ICE with -ftree-loop-linear
--- Comment #3 from uttamp at us dot ibm dot com 2006-01-25 16:56 ---
Reduced test case
int vq_index(float *in, const float *codebook, int len, int entries)
{
int i,j;
int best_index=0;
for (i=0;ientries;i++)
{
float dist=0;
for (j=0;jlen;j++)
{
float tmp = in[j]-*codebook++;
dist += tmp*tmp;
}
if (i==0 || dist0)
{
best_index=i;
}
}
return best_index;
}
$ elm3b11:/home/pawar /opt/gcc-nightly/trunk-20060123/bin/gcc -O1
-ftree-loop-linear -c ccbdYzn2.c
ccbdYzn2.c: In function vq_index:
ccbdYzn2.c:3: internal compiler error: in lambda_loopnest_to_gcc_loopnest, at
lambda-code.c:1982
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25929
[Bug ada/14435] [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
--- Comment #13 from hjl at lucon dot org 2006-01-25 16:56 --- How committed are we to fix this bug? Last time it was closed as WONTFIX. If we are 100% committed to fix this, I can try to come up with something. -- hjl at lucon dot org changed: What|Removed |Added Last reconfirmed|2004-03-05 01:47:05 |2006-01-25 16:56:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
[Bug ada/14435] [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
--- Comment #14 from charlet at adacore dot com 2006-01-25 16:59 --- Subject: Re: [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics How committed are we to fix this bug? Last time it was closed as WONTFIX. If we are 100% committed to fix this, I can try to come up with something. Well, the first thing to do is really to fix the documentation, since GCC_EXEC_PREFIX is mentioned in several places in the documentation, in an inconsistent manner. Some places do document the behavior which the Ada test suite would like to rely upon (GCC_EXEC_PREFIX strictly equivalent to the -B switch), that's basically the old behavior, and some other places don't (that's the new behavior). I would personally vote for fixing things so that GCC_EXEC_PREFIX can be used instead of -B Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
[Bug ada/14435] [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
--- Comment #15 from hjl at lucon dot org 2006-01-25 17:25 --- The gcc 4.2 manual says `GCC_EXEC_PREFIX' If `GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the names of the subprograms executed by the compiler. No slash is added when this prefix is combined with the name of a subprogram, but you can specify a prefix that ends with a slash if you wish. Is gnat1 a subprogram executed by the compiler? If anwser is yes and we agree the manual is correct, I will try to fix the driver. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
[Bug target/14798] [3.4/4.0/4.1/4.2 Regression] In case of SH target with -O2 option #pragma interrupt doesn't get resetted.
--- Comment #19 from amylaar at gcc dot gnu dot org 2006-01-25 17:27 --- There is even more wrong with the way we translate function pro-epilogue affecting pragmas to attributes. When we used only pragmas, the pragma could placed not only in front of the function, but also anywhere within the function, and it would affect the prologue/epilogue generation of that function. In order to restore this behaviour, the pragma hooks should check cfun, and apply the pragma to the current function if cfun is set. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added CC|joern dot rennecke at superh|joern dot rennecke at st dot |dot com |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14798
[Bug ada/14435] [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
--- Comment #16 from charlet at adacore dot com 2006-01-25 17:31 --- Subject: Re: [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics Is gnat1 a subprogram executed by the compiler? If anwser is yes and we agree the manual is correct, I will try to fix the driver. gnat1 is similar to cc1 and cc1plus, i.e. executed by the gcc driver. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
[Bug c/25892] -Wpointer-sign creates problems for Emacs
--- Comment #2 from aoliva at gcc dot gnu dot org 2006-01-25 17:40 --- Mine -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
[Bug libgomp/25910] [4.2 Regression] bootstrap failure
--- Comment #7 from rth at gcc dot gnu dot org 2006-01-25 17:55 --- (In reply to comment #6) fla=-W -Wall -Wextra -march=pentium4 -mtune=pentium4 -O0 -g -ggdb Ah, so it falls into the category of Your Own Fault. Remove those bogus extra warning flags and you won't have this problem. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25910
[Bug ada/18819] [4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #25 from uweigand at gcc dot gnu dot org 2006-01-25 18:03 --- Yes, the patch fixes the problem on s390x. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug c/25892] -Wpointer-sign creates problems for Emacs
--- Comment #3 from aoliva at gcc dot gnu dot org 2006-01-25 18:12 --- Created an attachment (id=10728) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10728action=view) Patch that disables -Wpointer-sign by default, but gets -Wall or -pedantic to imply it This patch implements the suggested (agreed-upon?) semantics. I've only tested it manually so far; bootstrap ongoing, test cycle to follow, will submit formally then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
Re: [Bug c/25892] -Wpointer-sign creates problems for Emacs
--- Comment #3 from aoliva at gcc dot gnu dot org 2006-01-25 18:12 --- Created an attachment (id=10728) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10728action=view) Patch that disables -Wpointer-sign by default, but gets -Wall or -pedantic to imply it I thought it was agreed that -Wall should not enable it either (or maybe I am misrembering). -- Pinski
[Bug c/25892] -Wpointer-sign creates problems for Emacs
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-25 18:13 --- Subject: Re: -Wpointer-sign creates problems for Emacs --- Comment #3 from aoliva at gcc dot gnu dot org 2006-01-25 18:12 --- Created an attachment (id=10728) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10728action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10728action=view) Patch that disables -Wpointer-sign by default, but gets -Wall or -pedantic to imply it I thought it was agreed that -Wall should not enable it either (or maybe I am misrembering). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
[Bug bootstrap/25961] New: Mainline failed to bootstrap on Linux/ia64
I got /export/build/gnu/gcc/build-ia64-linux/./prev-gcc/xgcc -B/export/build/gnu/gcc/build-ia64-linux/./prev-gcc/ -B/usr/gcc-4.2/ia64-unknown-linux-gnu/bin/ -c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -I. -I. -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/. -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/../include -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/../libcpp/include -I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/../libdecnumber -I../libdecnumber insn-automata.c -o insn-automata.o cc1: warnings being treated as errors insn-automata.c: In function internal_insn_latency: insn-automata.c:21461: warning: implicit declaration of function ia64_st_address_bypass_p insn-automata.c:21465: warning: implicit declaration of function ia64_ld_address_bypass_p insn-automata.c: In function print_reservation: insn-automata.c:22483: warning: string length 669 is greater than the length 509 ISO C89 compilers are required to support make[5]: *** [insn-automata.o] Error 1 -- Summary: Mainline failed to bootstrap on Linux/ia64 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC build triplet: ia64-unknown-linux-gnu GCC host triplet: ia64-unknown-linux-gnu GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25961
[Bug c/25892] -Wpointer-sign creates problems for Emacs
--- Comment #5 from aoliva at gcc dot gnu dot org 2006-01-25 18:17 --- All I know is what's in the bug report. It says -Wall or -pedantic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
[Bug bootstrap/25961] [4.2 Regression] Mainline failed to bootstrap on ia64
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-25 18:19 --- Known issue, see http://gcc.gnu.org/ml/gcc/2006-01/msg00982.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|ia64-unknown-linux-gnu | GCC host triplet|ia64-unknown-linux-gnu | GCC target triplet|ia64-unknown-linux-gnu |ia64-* Last reconfirmed|-00-00 00:00:00 |2006-01-25 18:19:09 date|| Summary|Mainline failed to bootstrap|[4.2 Regression] Mainline |on Linux/ia64 |failed to bootstrap on ia64 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25961
[Bug rtl-optimization/25703] [4.2 Regression] ACATS cxa4024 failure
--- Comment #7 from hjl at lucon dot org 2006-01-25 18:19 --- I tried the patch in comment 5. It doesn't fix c34006a and cc1226b on Linux/i686. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug target/25758] gcc.c-torture/compile/20030921-1.c fails at -O0
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-25 18:21 --- New patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01751.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2006- |patches/2006- |01/msg00897.html|01/msg01751.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25758
[Bug c/24453] IMA could be sped up a little more for a lot of files (for setting type context)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-25 18:22 --- I don't have enough time to test this any more. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24453
[Bug rtl-optimization/25703] [4.2 Regression] ACATS cxa4024 failure
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-01-25 18:27 --- I tried the patch in comment 5. It doesn't fix c34006a and cc1226b on Linux/i686. Does it change anything for Jan's testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug target/25758] gcc.c-torture/compile/20030921-1.c fails at -O0
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-25 18:33 --- Subject: Bug 25758 Author: pinskia Date: Wed Jan 25 18:33:14 2006 New Revision: 110219 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110219 Log: 2006-01-25 Andrew Pinski [EMAIL PROTECTED] PR target/25758 * config/i386/i386.c (output_pic_addr_const) case SYMBOL_REF: Use output_addr_const instead of assemble_name. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25758
[Bug target/25758] gcc.c-torture/compile/20030921-1.c fails at -O0
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-25 18:33 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25758
[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-25 18:35 --- (In reply to comment #8) Currently it is not necessary for powerpc, but Apple may indeed change this in a future version of powerpc-darwin. In a way it is already needed for powerpc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
[Bug rtl-optimization/25703] [4.2 Regression] ACATS cxa4024 failure
--- Comment #9 from hjl at lucon dot org 2006-01-25 18:41 --- No, it still needs -mtune=pentiumpro to pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug c/25892] -Wpointer-sign creates problems for Emacs
--- Comment #6 from jbuck at gcc dot gnu dot org 2006-01-25 18:49 --- Alexandre's right, -Wall should enable the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
[Bug rtl-optimization/25703] [4.2 Regression] ACATS cxa4024 failure
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-01-25 18:59
---
No, it still needs -mtune=pentiumpro to pass.
OK, thanks, I see the problem.
Roger, if you haven't already plugged it, the very same hole is present in the
STRICT_LOW_PART case too. For Jan's testcase:
(insn 10 35 12 2 (set (zero_extract:SI (subreg:SI (reg/v:DI 58 [ a ]) 4)
(const_int 8 [0x8])
(const_int 8 [0x8]))
(const_int 1 [0x1])) 53 {movsi_insv_1} (insn_list:REG_DEP_TRUE 35
(nil))
(nil))
(insn 12 10 14 2 (set (subreg:SI (reg/v:DI 58 [ a ]) 0)
(const_int 1 [0x1])) 34 {*movsi_1} (insn_list:REG_DEP_TRUE 10 (nil))
(nil))
(insn 14 12 16 2 (set (strict_low_part (subreg:QI (reg/v:DI 58 [ a ]) 4))
(const_int 1 [0x1])) 46 {*movstrictqi_1} (insn_list:REG_DEP_TRUE 12
(nil))
(nil))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug libgomp/25884] [4.2 Regression] libgomp should not require perl to compile
--- Comment #3 from rth at gcc dot gnu dot org 2006-01-25 19:18 --- Subject: Bug 25884 Author: rth Date: Wed Jan 25 19:17:57 2006 New Revision: 110220 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110220 Log: PR libgomp/25884 * Makefile.am (omp.h, omp_lib.h, omp_lib.f90, libgomp_f.h): Remove. * configure.ac (PERL): Don't set. (gstdint.h, omp.h, omp_lib.h, omp_lib.f90, libgomp_f.h): Create here. (OMP_LOCK_SIZE, OMP_LOCK_ALIGN, OMP_LOCK_KIND, OMP_NEST_LOCK_SIZE, OMP_NEST_LOCK_ALIGN, OMP_NEST_LOCK_KIND): New substitutions. * omp.h.in: Wrap the new configure substitutions with @ characters. * omp_lib.h.in, omp_lib.f90.in, libgomp_f.h.in: Likewise. * aclocal.m4, configure, Makefile.in: Regenerate. * mkomp_h.pl: Delete. Removed: trunk/libgomp/mkomp_h.pl Modified: trunk/libgomp/ChangeLog trunk/libgomp/Makefile.am trunk/libgomp/Makefile.in trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/libgomp_f.h.in trunk/libgomp/omp.h.in trunk/libgomp/omp_lib.f90.in trunk/libgomp/omp_lib.h.in trunk/libgomp/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25884
[Bug libgomp/25884] [4.2 Regression] libgomp should not require perl to compile
--- Comment #4 from rth at gcc dot gnu dot org 2006-01-25 19:18 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25884
[Bug ada/14435] [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
--- Comment #17 from hjl at lucon dot org 2006-01-25 19:28 --- A patch was posted at http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01757.html -- hjl at lucon dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
[Bug rtl-optimization/25703] [4.2 Regression] ACATS cxa4024 failure
--- Comment #11 from roger at eyesopen dot com 2006-01-25 19:52 --- Created an attachment (id=10729) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10729action=view) patch v2 Here's a revised version of the patch that also handles the STRICT_LOW_PART case. My apologies once again for the inconvenience. In the previous version of the patch I'd mistakenly assumed that STRICT_LOW_PART was some indication that the SUBREG only affected the low_part. Investigating Jan's testcase with -mtune=i486, I now understand it really means STRICT_SUB_PART, and actually behaves identically to SUBREG in this optimization, as we preserve all of the unaffected bits anyway! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug rtl-optimization/25703] [4.2 Regression] ACATS cxa4024 failure
--- Comment #12 from hjl at lucon dot org 2006-01-25 20:14 --- Patch in comment 11 looks good. c34006a, cc1226b and Jan's C testcase now pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug rtl-optimization/25703] [4.2 Regression] ACATS cxa4024 failure
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-01-25 20:15 --- My apologies once again for the inconvenience. In the previous version of the patch I'd mistakenly assumed that STRICT_LOW_PART was some indication that the SUBREG only affected the low_part. Investigating Jan's testcase with -mtune=i486, I now understand it really means STRICT_SUB_PART, and actually behaves identically to SUBREG in this optimization, as we preserve all of the unaffected bits anyway! You're right, the manual doesn't seem to allow that kind of STRICT_LOW_PARTs: `(strict_low_part (subreg:M (reg:N R) 0))' This expression code is used in only one context: as the destination operand of a `set' expression. In addition, the operand of this expression must be a non-paradoxical `subreg' expression. The presence of `strict_low_part' says that the part of the register which is meaningful in mode N, but is not part of mode M, is not to be altered. Normally, an assignment to such a subreg is allowed to have undefined effects on the rest of the register when M is less than a word. Is that a typo in the manual? What happens on big-endian? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug c/25861] [4.2 Regression] tree check fail at c-common.c:2430
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-25 20:40 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01762.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg01762.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25861
[Bug libgomp/25865] [4.2 Regression] libgomp incorrectly detects support for TLS
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-25 20:42 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2006-01-24 17:17:03 |2006-01-25 20:42:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #17 from eedelman at gcc dot gnu dot org 2006-01-25 20:46 --- Subject: Bug 25716 Author: eedelman Date: Wed Jan 25 20:46:29 2006 New Revision: 110225 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110225 Log: fortran/ 2005-01-25 Erik Edelmann [EMAIL PROTECTED] PR fortran/25716 * symbol.c (free_old_symbol): New function. (gfc_commit_symbols): Use it. (gfc_commit_symbol): New function. (gfc_use_derived): Use it. * gfortran.h: Add prototype for gfc_commit_symbol. * intrinsic.c (gfc_find_function): Search in 'conversion' if not found in 'functions'. (gfc_convert_type_warn): Add a symtree to the new expression node, and commit the new symtree-n.sym. * resolve.c (gfc_resolve_index): Make sure typespec is properly initialized. testsuite/ 2005-01-25 Erik Edelmann [EMAIL PROTECTED] PR fortran/25716 * gfortran.dg/char_result_11.f90: Make it sensitive to PR 25716 on 32-bit systems too. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_result_11.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug rtl-optimization/25703] [4.2 Regression] ACATS cxa4024 failure
--- Comment #14 from hjl at lucon dot org 2006-01-25 20:47 --- FYI, I got LAST_UPDATED: Wed Jan 25 17:12:12 UTC 2006 (revision 110216) === acats tests === FAIL: c32001e FAIL: c64105b FAIL: c95086b FAIL: cdd2a02 === acats Summary === # of expected passes2312 # of unexpected failures4 Native configuration is i686-pc-linux-gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug other/25925] [meta-bug] 4.2 slush bug
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-01-25 20:50 --- PR 25703: wrong code on x86-linux, there is a C example from the duplicated bug. PR 25961: Bootstrap failure on ia64-* after Zack's patches. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25703, 25961 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25925
[Bug rtl-optimization/25703] [4.2 Regression] ACATS cxa4024 failure
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-01-25 20:54 --- LAST_UPDATED: Wed Jan 25 17:12:12 UTC 2006 (revision 110216) === acats tests === FAIL: c32001e FAIL: c64105b FAIL: c95086b FAIL: cdd2a02 === acats Summary === # of expected passes2312 # of unexpected failures4 Native configuration is i686-pc-linux-gnu Nominal status in 4.1/4.2 when Tree-SRA is enabled. The 4 failures stem from a couple of bad interactions between the Ada front-end and Tree-SRA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug libfortran/24313] complex sqrt function does not return principal value
--- Comment #12 from harald dot vogt at desy dot de 2006-01-25 21:07 --- (In reply to comment #9) Patch for libgfortran http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00626.html It is a useful strategy to use libm but... It seems that glibc has still problems with csqrt. See also http://sources.redhat.com/bugzilla/show_bug.cgi?id=2181 http://sources.redhat.com/bugzilla/show_bug.cgi?id=2182 . Therefore it may be useful to check in intrinsics/configure if libm is broken in the architecture used, and if so use the code in intrinsics/c99_functions.c . A possible solution for csqrt is shown in http://www-zeuthen.desy.de/~hvogt/gfortran/acinclude.m4.diff . It is better to be independend from glibc coming with the OS. This enables to install gcc4(gfortran) without patching libm if it has bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24313
[Bug libfortran/25949] Unbounded I/O buffer memory usage for formatted IO
--- Comment #2 from jb at gcc dot gnu dot org 2006-01-25 21:35 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01765.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25949
[Bug fortran/18540] Jumping into blocks gives error rather than warning
--- Comment #20 from tobi at gcc dot gnu dot org 2006-01-25 22:34 --- Subject: Bug 18540 Author: tobi Date: Wed Jan 25 22:34:17 2006 New Revision: 110228 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110228 Log: PR fortran/18540 * gfortran.dg/goto_1.f: New. Added: trunk/gcc/testsuite/gfortran.dg/goto_1.f Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
[Bug fortran/25953] Help on the solution for the large file unit numbers problem
--- Comment #2 from luiscasinhas at mail dot telepac dot pt 2006-01-25 22:57 --- Sure! I also posted this problem on the redhat bugzilla. One thing though: I donwloaded the gcc source package ( gcc-4.0.2-20051126.tar.bz2) from the GNU site, not from redhat. As i stated on my post, i could not find the fio.h header file that would allow me to fix this problem on the source package from GNU (this is why i actualy posted the problem here and not on redhat. Nevertheless, thanks for your help and atention. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25953
[Bug bootstrap/25859] gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot open
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-25 22:58:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25859
[Bug bootstrap/25859] gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot open
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-01-25 23:02 --- Subject: Bug 25859 Author: ebotcazou Date: Wed Jan 25 23:02:55 2006 New Revision: 110229 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110229 Log: PR bootstrap/25859 * Makefile.in (GCC_LINK): Remove quotes. (tools targets): Link with either $(GNATLINK) --GCC=$(GCC_LINK) or $(GCC_LINK). (powerpc-darwin): Pass -shared-libgcc when building shared library. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25859
[Bug bootstrap/25859] gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot open
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-01-25 23:04 --- Subject: Bug 25859 Author: ebotcazou Date: Wed Jan 25 23:03:55 2006 New Revision: 110230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110230 Log: PR bootstrap/25859 * Makefile.in (GCC_LINK): Remove quotes. (tools targets): Link with either $(GNATLINK) --GCC=$(GCC_LINK) or $(GCC_LINK). (powerpc-darwin): Pass -shared-libgcc when building shared library. Modified: branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25859
[Bug fortran/25953] Help on the solution for the large file unit numbers problem
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-25 23:04 --- (In reply to comment #2) I donwloaded the gcc source package ( gcc-4.0.2-20051126.tar.bz2) from the GNU site, not from redhat. As i stated on my post, i could not find the fio.h header file that would allow me to fix this problem on the source package from GNU (this is why i actualy posted the problem here and not on redhat. Right as mentioned 4.0.0 and above does not have this limitation at all. You should try your program without recompiling GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25953
[Bug bootstrap/25859] gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot open
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-01-25 23:05 --- Should be fixed now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25859
[Bug tree-optimization/25937] ICE with -O2 -ftree-loop-linear
--- Comment #5 from uttamp at us dot ibm dot com 2006-01-25 23:14 --- I put the line numbers in there because I just wanted to point out the different error messages I get with small changes in code. ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25937
[Bug fortran/18540] Jumping into blocks gives error rather than warning
--- Comment #21 from tobi at gcc dot gnu dot org 2006-01-25 23:38 --- Subject: Bug 18540 Author: tobi Date: Wed Jan 25 23:38:34 2006 New Revision: 110232 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110232 Log: backport from r109914 fortran/ PR fortran/18540 * resolve.c (resolve_branch): Allow FORTRAN 66 cross-block GOTOs as extension. testsuite/ PR fortran/18540 * gfortran.dg/goto_1.f: New. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/goto_1.f - copied unchanged from r110228, trunk/gcc/testsuite/gfortran.dg/goto_1.f Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
[Bug tree-optimization/25962] New: Pointer (null) check after the use
In file gcc/cgraphunit.c, function verify_cgraph_node(struct cgraph_node
*node), the input argument 'node' has been dereferenced before doing any
checking till on line 717 with following codition,
...
717 if (!node)
718{
719 error (node not found in DECL_ASSEMBLER_NAME hash);
720 error_found = true;
721}
...
Shouldn't this code be moved at the begining of this function? before
de-referencing it?
Also, on line 789-793, if there is any error, we call dump_cgraph_node(), which
dumps the cgraph node. Shouldn't we do a check for non-null 'node', either here
before calling or in function dump_cgraph_node() itself? This has been,
reported as a possible error by 'coverity prevent tool'.
Any thoughts?
--
Summary: Pointer (null) check after the use
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25962
[Bug tree-optimization/25962] Pointer (null) check after the use
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-26 00:12 --- I noticed something like this in a different place (but only because I actually triped over it). There is another way you can find stuff like this one, by looking at the vrp tree dump :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25962
[Bug c++/25963] New: vector abi decision
Given:
typedef short vSInt16 __attribute__ (( __vector_size__ (16) ));
void f(vSInt16 a) { }
typedef short vSInt8 __attribute__ (( __vector_size__ (8) ));
void f(vSInt8 a) {}
we need to decide what to do with it, what mangling should be used on so on.
The expected result was that the file would compile and assemble, producing an
object file. The two versions of function f would have different names because
their arguments are of different types.
instead we get the following diagnostic from the assembler:
/var/rmp//ccmrZpNN.s:18:FATAL:Symbol __Z1fu8__vectors already defined
--
Summary: vector abi decision
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25963
[Bug c++/25963] vector abi decision
--- Comment #1 from mrs at apple dot com 2006-01-26 01:12 --- radr://4421275 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25963
[Bug c++/25963] vector abi decision
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-26 01:13 --- This is a dup of bug 12909. *** This bug has been marked as a duplicate of 12909 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25963
[Bug c++/12909] ambiguity in mangling vector types
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-26 01:13 --- *** Bug 25963 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
[Bug rtl-optimization/25703] [4.2 Regression] ACATS cxa4024 failure
--- Comment #16 from sayle at gcc dot gnu dot org 2006-01-26 02:48 --- Subject: Bug 25703 Author: sayle Date: Thu Jan 26 02:48:01 2006 New Revision: 110242 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110242 Log: PR rtl-optimization/25703 * combine.c (try_combine): Handle zero_extract and strict_low_part of non-lowpart SUBREGs for constant reg_subword_p set optimization. * gcc.target/i386/20060125-1.c: New test case. * gcc.target/i386/20060125-2.c: New test case. Added: trunk/gcc/testsuite/gcc.target/i386/20060125-1.c trunk/gcc/testsuite/gcc.target/i386/20060125-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug middle-end/25886] [4.2 Regression] up to 256 tree codes for Objective-C++
--- Comment #4 from dnovillo at gcc dot gnu dot org 2006-01-26 02:53 --- Subject: Bug 25886 Author: dnovillo Date: Thu Jan 26 02:53:01 2006 New Revision: 110243 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110243 Log: * tree.h (TREE_RANGE_CHECK): Fix range predicate. (TREE_BLOCK): Add call to EXPR_CHECK. PR 25886 * tree-dump.c (dequeue_and_dump): Handle OMP_CLAUSE. * tree-pretty-print.c (dump_omp_clause): Extract from ... (dump_omp_clauses): ... here. (dump_generic_node): Handle OMP_CLAUSE. * tree.c (omp_clause_num_ops): New. (omp_clause_code_name): New. (tree_code_size): Handle OMP_CLAUSE. (tree_size): Likewise. (make_node): Document handling of OMP_CLAUSE. (tree_node_structure): Handle OMP_CLAUSE. (omp_clause_check_failed): New. (omp_clause_range_check_failed): New. (omp_clause_operand_check_failed): New. (build_omp_clause): New. (walk_tree): Adjust handling of OMP_CLAUSE_* nodes. * tree.h (enum omp_clause_code): Declare. (OMP_CLAUSE_SUBCODE): Define. (OMP_CLAUSE_RANGE_CHECK): Define. (OMP_CLAUSE_ELT_CHECK): Define. (omp_clause_check_failed): Declare. (omp_clause_operand_check_failed): Declare. (omp_clause_range_check_failed): Declare. (OMP_CLAUSE_CHAIN): Do not use TREE_RANGE_CHECK. (OMP_CLAUSE_OPERAND): Use OMP_CLAUSE_RANGE_CHECK. (OMP_CLAUSE_PRIVATE_DEBUG): Use OMP_CLAUSE_SUBCODE_CHECK. (OMP_CLAUSE_LASTPRIVATE): Likewise. (OMP_CLAUSE_IF_EXPR): Likewise. (OMP_CLAUSE_NUM_THREADS_EXPR): Likewise. (OMP_CLAUSE_SCHEDULE_CHUNK_EXPR): Likewise. (OMP_CLAUSE_REDUCTION_CODE): Likewise. (OMP_CLAUSE_REDUCTION_INIT): Likewise. (OMP_CLAUSE_REDUCTION_MERGE): Likewise. (OMP_CLAUSE_REDUCTION_PLACEHOLDER): Likewise. Use tree_node.omp_clause.subcode instead of TREE_COMPLEXITY. (OMP_CLAUSE_SCHEDULE_KIND): Likewise. (OMP_CLAUSE_DEFAULT_KIND): Likewise. (OMP_CLAUSE_CODE): Define. (OMP_CLAUSE_SET_CODE): Define. (OMP_CLAUSE_CODE): Define. (OMP_CLAUSE_OPERAND): Define. (struct tree_omp_clause): Declare. (union tree_node): Add field 'omp_clause'. * treestruct.def (TS_OMP_CLAUSE): Define. * tree.def (OMP_CLAUSE_PRIVATE, OMP_CLAUSE_SHARED OMP_CLAUSE_FIRSTPRIVATE, OMP_CLAUSE_LASTPRIVATE, OMP_CLAUSE_REDUCTION, OMP_CLAUSE_COPYIN, OMP_CLAUSE_COPYPRIVATE, OMP_CLAUSE_IF, OMP_CLAUSE_NUM_THREADS, OMP_CLAUSE_SCHEDULE, OMP_CLAUSE_NOWAIT, OMP_CLAUSE_ORDERED, OMP_CLAUSE_DEFAULT): Remove. (OMP_CLAUSE): Define. * print-tree.c (print_node): Handle OMP_CLAUSE. * omp-low.c: Adapt all uses of OMP_CLAUSE_* nodes. * c-typeck.c: Likewise. * gimplify.c: Likewise. * c-omp.c: Likewise. * tree-nested.c: Likewise. * tree-inline.c: Likewise. * c-parser.c: Likewise. * gimple-low.c (lower_omp_directive): Do not set TREE_BLOCK on clauses. Modified: trunk/gcc/ChangeLog trunk/gcc/c-omp.c trunk/gcc/c-parser.c trunk/gcc/c-typeck.c trunk/gcc/gimple-low.c trunk/gcc/gimplify.c trunk/gcc/omp-low.c trunk/gcc/print-tree.c trunk/gcc/tree-dump.c trunk/gcc/tree-inline.c trunk/gcc/tree-nested.c trunk/gcc/tree-pretty-print.c trunk/gcc/tree.c trunk/gcc/tree.def trunk/gcc/tree.h trunk/gcc/treestruct.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25886
