I understand and can support (up to a point) the desire of distributors to
continue working within GPLv2 and I know that's why the 4.1 branch is in
this situation. However IMHO this position is in tension with the
interests of users who don't get gcc from distributors (think
non-linux-gnu
On Sun, 16 Mar 2008, Zdenek Dvorak wrote:
Hi,
A statistics event consists of a function (optional), a statement
(optional) and the counter ID. I converted the counters from
tree-ssa-propagate.c as an example, instead of
prop_stats.num_copy_prop++;
On 3/15/08, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
On Sat, 15 Mar 2008, NightStrike wrote:
On 3/15/08, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
How complicated is the
On 3/16/08, Eric Botcazou [EMAIL PROTECTED] wrote:
I understand and can support (up to a point) the desire of distributors to
continue working within GPLv2 and I know that's why the 4.1 branch is in
this situation. However IMHO this position is in tension with the
interests of users who
* Basile STARYNKEVITCH wrote on Wed, Mar 12, 2008 at 07:57:33AM CET:
So I tried to add to gcc/configure.ac the following lines (which exist
in libmudflap/configure.ac)
AC_LIBTOOL_DLOPEN
AM_PROG_LIBTOOL
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
and it does not work:
(cd
On Sun, Mar 16, 2008 at 9:33 AM, Eric Botcazou [EMAIL PROTECTED] wrote:
I understand and can support (up to a point) the desire of distributors to
continue working within GPLv2 and I know that's why the 4.1 branch is in
this situation. However IMHO this position is in tension with the
Now lets take a simple built.
gcc -c test1.c
gcc -c test2.c
gcc test1.o test2.o -o final
--test1.c--
/* of course in real world this would be some complex but solveable function */
int test (int a) {
a=a+1;
}
--test2.c--
#include stdio.h
int test(int a); /* normally in a header somewhere not
Richard Guenther wrote:
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
I strongly object to moving the 4.1 brach to GPLv3.
I too think that it would be a bad idea to switch the 4.1 branch to
GPLv3, and, therefore, I think
Manuel López-Ibáñez wrote:
That is a good point. The underlying mechanism can be fine tuned
later. What would be the main problems to get caret diagnostics in
trunk? The most common issue is probably bad locations but I don't see
that as a major problem. On the contrary, the only reliable way
This command
$(CC) -M $(HOST_CFLAGS) $(CPPFLAGS) -MQ $@ include/common.h [EMAIL PROTECTED]
is generating following error:
here cc is xscale-elf-gcc
and target is autoconf.mk
Generating include/autoconf.mk
xscale-elf-gcc: compilation of header file requested
any tips.
Regards
On 3/16/08, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
I strongly object to moving the 4.1 brach to GPLv3.
I too think that it would be a bad idea to
Jeff, DJ and Richard,
Richard Sandiford and I have taken on the task of trying to fully
explain subregs in the gcc docs. This is an area where that
traditionally has been very confusing to outsiders and even insiders who
were not rtl maintainers. As the community of active developers has
NightStrike wrote:
What exactly is the downside to upgrading the license? I'm not
familiar with the implications of doing so.
As I understand it, the concern is that many distros use the 4.1 branch
as the base for their main gcc system compiler. If suddenly the branch
gets upgraded to GPLv3
I have been working on AVR port and have come across many instances
where poor code is produced due to the absence of effective forward
propagation of operands before register allocation.
The AVR target in particular benefits from register lowering pass as
many physical registers and
It is seldom necessary to wrap hard registers in @code{subreg}s;
such registers would normally reduce to a single @code{reg} rtx.
Are these valid? I know we've gone back and forth, but I thought the
current position is that SUBREGs of hard regs are only allowed
transitorily (e.g., during
Peter Dolding [EMAIL PROTECTED] writes:
Since test is in a different object file it gets completely skiped
from optimising even that it should be optimised out.
http://gcc.gnu.org/wiki/LTO_Driver
Ian
Ian Lance Taylor wrote:
Peter Dolding [EMAIL PROTECTED] writes:
Since test is in a different object file it gets completely skiped
from optimising even that it should be optimised out.
http://gcc.gnu.org/wiki/LTO_Driver
Ian
Ok that is half my idea. Let it sort out at link stage.
On Sun, 16 Mar 2008, Mark Mitchell wrote:
Richard Guenther wrote:
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
I strongly object to moving the 4.1 brach to GPLv3.
I too think that it would be a bad idea to switch
On Sun, 16 Mar 2008, Kaveh R. GHAZI wrote:
However there is a class of users who don't get their compiler from
distributors, but who also want the safety of using official releases and
not some random svn checkout. These users are missing one year's worth of
bugfixes. They may not want to
On Wed, Mar 12, 2008 at 10:44:48PM +1100, Greg Schafer wrote:
Currently, -B doesn't add the multilib search paths when processing
startfile_prefixes. For example, -B $prefix/lib/ doesn't find startfiles in
$prefix/lib/../lib64
Most other calls to add_prefix() in gcc.c that refer to
--- Comment #7 from gschafer at zip dot com dot au 2008-03-16 06:41 ---
(In reply to comment #6)
As a workaround can you try using all of the sysroot framework?
Thanks for looking at this Carlos. But the sysroot stuff is not really suited
to a non /usr layout. For example, with my
--- Comment #7 from pault at gcc dot gnu dot org 2008-03-16 07:15 ---
(In reply to comment #6)
You r 'this' is better than my 'Think' Passed regression testing here on
x86-64.
Jerry,
I did not see that you were working on it - sorry that I trampled on your toes.
I took a copy of
This problem can be seen by compiling testsuite/gfortran.dg/g77/ndrm2.f. The
label reference (after x87 stack compensation edge is inserted) is updated only
in final jump insn, but other references to the same label are left untouched.
We enter stack pass with:
(insn:TI 19 20 18 4 dnrm2.f:33
This problem can be seen by compiling testsuite/gfortran.dg/g77/ndrm2.f. The
label reference (after x87 stack compensation edge is inserted) is updated only
in final jump insn, but other references to the same label are left untouched.
We enter stack pass with:
(insn:TI 19 20 18 4 dnrm2.f:33
Compiling this simple C++ file:
#pragma weak my_weak_function
extern C void my_function_to_be_renamed (void) asm (my_renamed_function);
gives me the warning
foo.cc:2: warning: asm declaration ignored due to conflict with previous rename
This does not make sense, as there is no previous rename.
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-03-16 10:06 ---
Subject: Bug 35582
Author: dfranke
Date: Sun Mar 16 10:05:18 2008
New Revision: 133270
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133270
Log:
2008-03-16 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-03-16 10:07 ---
Added testcase to testsuite. Backport unlikely as 4.3.0 (which works) is
released and manpower is limited. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 10:57 ---
*** This bug has been marked as a duplicate of 35604 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 10:57 ---
*** Bug 35605 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35604
extern void (*__fini_array_start []) (void);
extern void (*__fini_array_end []) (void);
void
__libc_csu_fini (void)
{
__SIZE_TYPE__ i = __fini_array_end - __fini_array_start;
while (i-- 0)
(*__fini_array_start [i]) ();
}
./cc1 -quiet elf-init.i -O
elf-init.i: In function
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 11:45 ---
force_gimple_operand doesn't gimplify
__fini_array_start[(unsigned int) D.1189_5]
because is_gimple_min_invariant returns true for it.
And the verification failure is just an artifact of that. I have a patch.
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-16 11:47 ---
Hm, no. This address isn't invariant at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35607
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-16 12:20 ---
This invariantness of (unsigned int) D.1189_5 in
__fini_array_end.0_2 = (int) __fini_array_end;
__fini_array_start.1_3 = (int) __fini_array_start;
D.1188_4 = __fini_array_end.0_2 - __fini_array_start.1_3;
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-16 12:23 ---
The concrete problem with allowing foo[(int)z_4] in a PHI node argument is
that we cannot cope with immediate uses in PHI nodes and thus DCE z_4 and
end up with a reference to a deleted SSA_NAME during expansion
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-16 12:32 ---
One solution is to, in expand_simple_operations, expand all TREE_INVARIANT
operations so we end up with
# ivtmp.16_1 = PHI ivtmp.16_11(5), __fini_array_start[(unsigned int)
(((int) __fini_array_end - (int)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-03-16 13:01 ---
$ gfortran-svn -v
Target: i686-pc-linux-gnu
gcc version 4.4.0 20080315 (experimental) (GCC)
$ gfortran-svn -g -Wall -W transfer_assumed_size_1.f90
$ valgrind --tool=memcheck --leak-check=full a.out
[...]
==6291==
--- Comment #1 from dominiq at lps dot ens dot fr 2008-03-16 13:46 ---
Reduced test case:
program prandtl meyer
implicit none
integer :: i, j
integer, parameter :: imax = 100
integer, parameter :: jmax = 40
real, dimension(0:jmax,0:imax) :: f1,
com
GCC build triplet: 4.4.0 20080316 (experimental) (GCC)
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35608
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-16 15:45 ---
Subject: Bug 35607
Author: rguenth
Date: Sun Mar 16 15:45:09 2008
New Revision: 133273
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133273
Log:
2008-03-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from danglin at gcc dot gnu dot org 2008-03-16 15:48 ---
Subject: Bug 31510
Author: danglin
Date: Sun Mar 16 15:48:09 2008
New Revision: 133274
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133274
Log:
PR debug/31510
* dbxout.c (dbxout_expand_expr,
--- Comment #7 from danglin at gcc dot gnu dot org 2008-03-16 15:50 ---
Subject: Bug 31510
Author: danglin
Date: Sun Mar 16 15:49:55 2008
New Revision: 133275
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133275
Log:
PR debug/31510
* dbxout.c (dbxout_expand_expr,
--- Comment #8 from danglin at gcc dot gnu dot org 2008-03-16 15:51 ---
Fixed by change.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-16 15:55 ---
What is the excess error (look in the gcc/testsuite/gcc/gcc.log file)? usually
this test blows memory/stack, so possibly just gets killed by the kernel.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35608
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-03-16 15:55 ---
function func2()
type(bar) func2
allocate(func1%baz(1))
end function
In primary.c(match_variable), case FL_PROCEDURE, we here have a function that
satisfies the first if-clause, but does not trigger the
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-03-16 15:55 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jrp at dial dot pipex dot com 2008-03-16 16:07 ---
PASS: gcc.c-torture/compile/limits-structnest.c -O1 (test for excess errors)
Executing on host: /home/jrp/build/gcc/xgcc -B/home/jrp/build/gcc/ -O2 -w
-fn
o-show-column -c -o limits-structnest.o
--- Comment #18 from danglin at gcc dot gnu dot org 2008-03-16 16:27
---
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/pr34999.c -O2
-freorder-blocks-a
nd-partition -fprofile-use -D_PROFILE_USE
--- Comment #2 from mikpe at it dot uu dot se 2008-03-16 16:49 ---
(In reply to comment #1)
This happens with 4.1, 4.2 and trunk on old ABI. Apparently it doesn't
happen with EABI.
I see the problem too, on Linux/ARM/OABI with gcc-4.1.2.
However, the problem is in the test case
--- Comment #12 from danglin at gcc dot gnu dot org 2008-03-16 16:49
---
On hppa64-hp-hpux11.11,
FAIL: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized
conststa
ticvariable 1
The tree dump is the same as for darwin. This target is always pic.
--
danglin at gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Priority|P4
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.0
Priority|P4 |P5
--- Comment #3 from schwab at suse dot de 2008-03-16 17:17 ---
Not a bug.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-03-16 17:17 ---
What is the status on the 4.3 branch and the trunk?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.0
Priority|P4 |P5
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.0
Priority|P4 |P5
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.0
Priority|P4 |P5
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.2.0 4.2.1 4.2.2 |4.2.0 4.2.1 4.2.2 4.2.3
Priority|P1
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-03-16 17:29
---
This will not be fixed on the 4.2 branch. Closing as fixed in 4.3.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-16 17:32 ---
This will not be fixed on the 4.2 branch. Closing as fixed for 4.3.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.4 |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.3
Known to work||4.3.0
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |tree-optimization
Priority|P3 |P2
--- Comment #8 from pault at gcc dot gnu dot org 2008-03-16 19:15 ---
Subject: Bug 35470
Author: pault
Date: Sun Mar 16 19:14:17 2008
New Revision: 133279
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133279
Log:
2008-03-16 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from pault at gcc dot gnu dot org 2008-03-16 19:15 ---
Fixed on trunk
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-- snip --
$ cat test.c
int foo, bar;
void decode_reloc(int reloc, int *is_alt)
{
if (reloc = 20)
*is_alt = 1;
else if (reloc = 10)
*is_alt = 0;
}
void testfunc()
{
int alt_reloc;
decode_reloc(foo, alt_reloc);
if (alt_reloc)
bar = 42;
}
$ gcc -O2 -Wall -c test.c
some athwartanyone it apportion
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3/4.4 Regression] bogus |[4.3/4.4 Regression] is
|is used uninitialized in
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-16 21:30 ---
So Jump threading comes along and threads the jump for some reason makes the
PHI node go away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35609
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-16 21:32 ---
The warning works as designed, the PHI node in question that causes the
warning only has a single incoming edge:
testfunc ()
{
int alt_reloc;
int foo.0;
bb 2:
foo.0_1 = foo;
if (foo.0_1 19)
goto bb 5;
--- Comment #11 from gnu_andrew at member dot fsf dot org 2008-03-16 22:29
---
Created an attachment (id=15332)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15332action=view)
Move towards a CPStringBuilder-using code base
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
MSVC++ from 2003 to 2008 and comeau compiler v4.9.3b gives no errors about
that:
//-
#define CAT(a,b) a ## b
void foo(int a) {}
void foo(int a,int b) {}
int main() {
CAT(foo,(1)); //error
CAT(foo,(1,2)); //error
return 0;
}
--- Comment #12 from gnu_andrew at member dot fsf dot org 2008-03-16 22:45
---
Created an attachment (id=15333)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15333action=view)
Move towards a CPStringBuilder-using code base
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-16 22:46 ---
Yes and GCC behavior is correct. pasting foo and ( don't make a valid
preprocessing token.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-16 22:49 ---
## only works to form a valid token, if it does not, then the code is invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35610
--- Comment #1 from starlight at binnacle dot cx 2008-03-16 22:49 ---
Hit this same issue. The problem is likely that the -fvisibility=hidden
option is also on the compile line. Removing it makes the problem go
away, at least for single-threaded mudflap.
Produced with gcc 4.2.3,
--- Comment #3 from andry at inbox dot ru 2008-03-16 22:56 ---
(In reply to comment #2)
## only works to form a valid token, if it does not, then the code is invalid.
When i can understand which token is valid then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35610
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-16 23:06 ---
(In reply to comment #3)
When i can understand which token is valid then?
By reading the C/C++ standards :). But basically in this case foo and ( are
two different tokens. Examples of valid tokens: -, foo, ., ,,
--- Comment #13 from gnu_andrew at member dot fsf dot org 2008-03-16 23:37
---
Created an attachment (id=15334)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15334action=view)
Move towards a CPStringBuilder-using code base
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
--- Comment #14 from gnu_andrew at member dot fsf dot org 2008-03-17 00:37
---
Created an attachment (id=15335)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15335action=view)
Abstract reflection elements of CPStringBuilder to a VM class
--
--- Comment #15 from gnu_andrew at member dot fsf dot org 2008-03-17 01:30
---
Created an attachment (id=15336)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15336action=view)
Move towards a CPStringBuilder-using code base
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
Executing on host: /home/dave/gnu/gcc-4.4/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4.4/objdir/gcc/
/home/dave/gnu/gcc-4.4/gcc/libgomp/testsuite/libgomp.c/omp-nested-1.c
-B/home/dave/gnu/gcc-4.4/objdir/hppa-linux/./libgomp/
-I/home/dave/gnu/gcc-4.4/objdir/hppa-linux/./libgomp
--- Comment #1 from danglin at gcc dot gnu dot org 2008-03-17 02:16 ---
The test didn't fail in revision 133125.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35611
--- Comment #2 from danglin at gcc dot gnu dot org 2008-03-17 02:29 ---
Same failure is also present on hppa2.0w-hp-hpux11.11 (4.3.1) and
hppa64-hp-hpux11.11 (4.4.0). There are quite a few other libgomp
fails that are probably the same bug.
--
danglin at gcc dot gnu dot org
bind_c_usage_8.f03 in gcc/testsuite/gfortran.dg contains:
! PR fortran/32797
!
MODULE ISO_C_UTILITIES
USE ISO_C_BINDING
implicit none
CHARACTER(C_CHAR), DIMENSION(1), SAVE, TARGET, PRIVATE :: dummy_string=?
CONTAINS
FUNCTION C_F_STRING(CPTR) RESULT(FPTR)
use, intrinsic ::
bind_c_usage_8.f03 in gcc/testsuite/gfortran.dg contains:
! PR fortran/32797
!
MODULE ISO_C_UTILITIES
USE ISO_C_BINDING
implicit none
CHARACTER(C_CHAR), DIMENSION(1), SAVE, TARGET, PRIVATE :: dummy_string=?
CONTAINS
FUNCTION C_F_STRING(CPTR) RESULT(FPTR)
use, intrinsic ::
Traditionally it is accepted to pug GNU library info documentation files into
Libraries category. libgomp info file goes into GNU Libraries category.
The following patch fixes the bug:
--- libgomp.texi.old2008-03-17 00:07:13.0 -0400
+++ libgomp.texi2008-03-17 00:07:25.0
--
petrosyan at gmail dot com changed:
What|Removed |Added
Severity|normal |trivial
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35614
88 matches
Mail list logo
