Brendon Costa wrote:
You as an author of a new template class could define it the other way.
The issue here is that doing so restricts usage of the generic
component. In specific cases this may be desirable, but not for generic
components like STL containers or those in boost. For generic
This means that you couldn't use *GCC* if you
did something the FSF found objectionable, closing an easy
work-around.
This doesn't work, because it breaks out of the basic framework of
copyright law. Nobody signs anything or accepts any terms in order to
use gcc. The FSF wants to stop
On Sep 25, 2008, at 3:11 AM, Paolo Bonzini wrote:
This means that you couldn't use *GCC* if you
did something the FSF found objectionable, closing an easy
work-around.
This doesn't work, because it breaks out of the basic framework of
copyright law. Nobody signs anything or accepts any
Hi,
RTEMS has BSPs for a couple of simulators that
do not have a source for clock tick interrupts.
We simulate the passage of time by having a special
IDLE task advance time. This works well enough
when all tasks block but if a test depends on
something like timeslice expiration, that won't
Hi,
For those interested in participating in a two days graphite
development, please consider updating the wiki page adding your name
in the attendees list http://gcc.gnu.org/wiki/Graphite_Workshop_Nov08
We need to know how many developers will attend the workshop for
logistics purposes: the
Well I guess running the ACATS gives a big hint. There were not many
failures on sh-rtems4.10 and some of those were illegal memory accesses.
So only the c4* and cxa* are likely to be related to not having a real
clock tick.
sh-rtems4.10-gcc (GCC) 4.4.0 20080918 (experimental) [trunk revision
ПР0ДАЖА И М0НТАЖ САЙДИНГА И В0Д0СТ0К0В...
- - -
Наша компания продает высококачественный виниловый и цокольный сайдинг
производства Канады, США и России...
ЦЕНЫ на материалы - значительно НИЖЕ рыночных, за счет прямых закупок
у экспортеров и специальных скидок предоставленных для нашей
Hi,
I am trying to run the gcc test suite on h8300-rtems
and getting lots of failures which look like this:
/home/joel/work-gnat/svn/b-gcc1-h8300/gcc/xgcc
-B/home/joel/work-gnat/svn/b-gcc1-h8300/gcc/
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/execute/20001031-1.c
gcc_tg.o -w
Joel Sherrill wrote:
Hi,
I am trying to run the gcc test suite on h8300-rtems
and getting lots of failures which look like this:
/home/joel/work-gnat/svn/b-gcc1-h8300/gcc/xgcc
-B/home/joel/work-gnat/svn/b-gcc1-h8300/gcc/
2008/9/24 Simon Hill:
Brain Dessent wrote:
You're essentially trusting that all
exception specifiers for every function in the program and *all* library
code are always present and always correct which is a huge leap of faith
that I don't think is supported by reality.
I agree that it won't
On Thu, 2008-09-25 at 14:49 -0500, Joel Sherrill wrote:
Well I guess running the ACATS gives a big hint. There were not many
failures on sh-rtems4.10 and some of those were illegal memory accesses.
So only the c4* and cxa* are likely to be related to not having a real
clock tick.
The c4
Snapshot gcc-4.3-20080925 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080925/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
The above works on code::blocks, which uses some form of GCC, and
looks OK to me.
Of course this only works for exactly one exception type.
You'd have to wait for C++0X variadic templates (and hope you can
throw them) if you need zero or more than one.
It's also very verbose, a little
The following code snippet triggers an ICE since GCC 4.1.0:
==
void foo(int i __attribute__((__weakref__ (xyz;
==
bug.c:1: internal compiler error: tree check: expected tree that
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37645
The following invalid code snippet triggers an ICE since GCC 4.2.0:
===
struct A
{
void foo();
void bar(int i)
{
void (*p)() = i ? foo : foo;
}
};
===
bug.cc: In member function 'void A::bar(int)':
bug.cc:7: internal
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37646
The following invalid code snippet triggers an ICE since GCC 4.3.0:
==
struct A
{
A() { void A(); }
};
==
bug.cc: In constructor 'A::A()':
bug.cc:3: error: return type specification for constructor invalid
bug.cc:3: internal compiler error: in
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37647
Consider this program:
-- a.c
#include stdio.h
int main()
{
int a = 10;
printf(%d\n, a);
printf(%0.4d\n, a);
return 0;
}
---
By compiling with:
gcc -Wall a.c
This warning gets displayed:
a.c:7:
The following invalid code snippet triggers an ICE on mainline:
==
struct A
{
templateint struct {};
};
==
bug.cc:3: error: template class without a name
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full
--
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=37649
The following invalid code snippet triggers an ICE since GCC 3.4.0:
=
templateint struct A {};
templatetypename = class A0: struct B {};
=
bug.cc:3: error: an explicit specialization
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37650
--- Comment #59 from l dot lunak at suse dot cz 2008-09-25 09:56 ---
(In reply to comment #58)
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
It seems unreasonable to me that gcc would silently modify
--- Comment #1 from paolo dot carlini at oracle dot com 2008-09-25 10:05
---
Can quickly fix this.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-25 10:28 ---
I guess this is illegal, too:
PROGRAM main
IMPLICIT NONE
CALL test (5, (/ 1, 2, 3, 4, 5, 6, 7, 8, 9 /) )
CONTAINS
SUBROUTINE test (n, arr)
IMPLICIT NONE
INTEGER :: n, arr(:)
INTEGER :: i = 5
--- Comment #44 from pluto at agmk dot net 2008-09-25 13:20 ---
i can reproduce this internal error on both 4.3.1 and 4.3-head.
here's a backtrace:
Breakpoint 1, error_recursion (context=0x10aeb40) at
../../gcc-4_3-branch/gcc/diagnostic.c:637
637 if (context-lock 3)
(gdb) p
--- Comment #2 from sam at gcc dot gnu dot org 2008-09-25 13:47 ---
Kai, I didn't notice that you assigned the bug to yourself. Feel free to
followup on my mail titled [PATCH] ada/37641: Remplace mingw
FILE_WRITE_PROPERTIES by FILE_WRITE_EA sent to gcc-patches.
--
sam at gcc dot gnu
--
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 #2 from burnus at gcc dot gnu dot org 2008-09-25 15:02 ---
Subject: Bug 37504
Author: burnus
Date: Thu Sep 25 15:01:16 2008
New Revision: 140663
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140663
Log:
2008-09-25 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #3 from nightstrike at gmail dot com 2008-09-25 15:04 ---
I think that was a mistake. He was just trying to confirm the PR, and probably
meant to set it to WAITING as opposed to ASSIGNED. I saw your emails to
gcc-patches. If you could commit the change, that'd be awesome.
--- Comment #4 from sam at gcc dot gnu dot org 2008-09-25 15:13 ---
Subject: Bug 37641
Author: sam
Date: Thu Sep 25 15:12:26 2008
New Revision: 140665
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140665
Log:
gcc/ada/
PR ada/37641
* adaint.c
--- Comment #5 from sam at gcc dot gnu dot org 2008-09-25 15:14 ---
Fixed in current SVN trunk, thanks.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2008-09-25 16:20 ---
Subject: Bug 37626
Author: burnus
Date: Thu Sep 25 16:18:45 2008
New Revision: 140667
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140667
Log:
2008-09-25 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #5 from burnus at gcc dot gnu dot org 2008-09-25 16:21 ---
FIXED on the trunk (4.4.0) and on the 4.3 branch.
Thanks for the bug report!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Hello
The result of an expression using pre-decrement or pre-increment such as:
y = x * n * --n;
gives different results in a few cases where x is placed before or after
the rest, or when its value is 1 or not. Please run the program attached
where a comment indicates what we think
Sent from my iPhone
On Sep 25, 2008, at 10:39 AM, Miguel A. Quintans [EMAIL PROTECTED]
wrote:
Hello
The result of an expression using pre-decrement or pre-increment
such as:
y = x * n * --n;
Try turning on warnings. That is -Wsquence-points. The above is
specified behavior
The following example dumps a core if compiled with -march=i586 -fPIC:
#include stdint.h
int main(void)
{
static uint64_t volatile s_u64;
__sync_bool_compare_and_swap(s_u64, 0, 0);
}
The reason is that %ebx will be used as pointer for the memory variable.
I can reproduce this bug so far
The result of an expression using pre-decrement or pre-increment such as:
y = x * n * --n;
gives different results in a few cases where x is placed before or after
the rest, or when its value is 1 or not. Please run the program attached
where a comment indicates what we think works
--- Comment #2 from paolo at gcc dot gnu dot org 2008-09-25 20:39 ---
Subject: Bug 37649
Author: paolo
Date: Thu Sep 25 20:38:32 2008
New Revision: 140670
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140670
Log:
/cp
2008-09-25 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from paolo dot carlini at oracle dot com 2008-09-25 20:41
---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37649
--- Comment #4 from paolo dot carlini at oracle dot com 2008-09-25 20:41
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-25 21:36 ---
I get:
xchgl %ebx, %edi
lock ; cmpxchg8b(%esi)
xchgl %ebx, %edi
Which looks good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37651
__declspec(dllimport) int foo ();
struct S
{
friend __declspec(dllimport) int foo ();
};
This code gives me the following warning:
dllexport_test.cxx:5: warning: 'int foo()' redeclared without dllimport
attribute: previous dllimport ignored
I think it is bogus. I the code clearly declares
--- Comment #2 from brian at dessent dot net 2008-09-25 22:29 ---
Subject: Re: __sync_bool_compare_and_swap creates wrong code
with -fPIC
You get that if the variable is auto, but if it's static the reference
is with a GOTOFF reloc:
xorl%edi, %edi
pushl %ebx
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-25 23:08 ---
Testing the fix right now with the addition assert.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36431
--- Comment #16 from pinskia at gcc dot gnu dot org 2008-09-25 23:24
---
I just ran into this again while working on a patch for fwprop.c and I noticed
that SMALL_REGISTER_CLASSES is true even for x86_64 which seems wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21518
--- Comment #19 from vmakarov at gcc dot gnu dot org 2008-09-26 00:15
---
Subject: Bug 37448
Author: vmakarov
Date: Fri Sep 26 00:14:30 2008
New Revision: 140674
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140674
Log:
2008-09-25 Vladimir Makarov [EMAIL PROTECTED]
--- Comment #7 from drangon dot mail at gmail dot com 2008-09-26 00:33
---
I'm using the win64 native compiler:
E:\codeg++ -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with: ../gcc/configure --host=x86_64-pc-mingw32
--target=x86_64-pc-mi
ngw32 --disable-nls
--- Comment #14 from vmakarov at gcc dot gnu dot org 2008-09-26 00:44
---
Subject: Bug 37535
Author: vmakarov
Date: Fri Sep 26 00:43:11 2008
New Revision: 140679
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140679
Log:
2008-09-25 Vladimir Makarov [EMAIL PROTECTED]
template char I
struct Int2Type
{
enum { value = I };
typedef Int2TypeI type;
typedef typename Int2TypeI+1::type next;
};
int main(void)
{
Int2Type5 i;
}
g++ compiler compiles the above program successfully (as it should) but spits
out the same warning message 5 times. If you
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-26 01:33 ---
Works correctly on the trunk, that is it does not warn at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37653
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-09-26
03:03 ---
I notice that gcj on i686-apple-darwin9 is linked against libintl but gjar
isn't. Could that be the origin of the failure of --help on gjar but not gcj?
--
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-09-26
03:15 ---
*** Bug 37652 has been marked as a duplicate of this bug. ***
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-26
03:15 ---
This is duplicate of 34749
*** This bug has been marked as a duplicate of 34749 ***
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #1 from kkojima at gcc dot gnu dot org 2008-09-26 03:31 ---
I've tried
--- ORIG/trunk/gcc/ira-color.c Wed Sep 17 09:48:49 2008
+++ LOCAL/trunk/gcc/ira-color.c Thu Sep 25 12:09:30 2008
@@ -514,7 +514,9 @@ assign_hard_reg (ira_allocno_t allocno,
#endif
if (!
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-26 05:10 ---
Subject: Bug 37645
Author: jakub
Date: Fri Sep 26 05:09:29 2008
New Revision: 140680
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140680
Log:
PR c/37645
* c-common.c
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-26 05:25 ---
Subject: Bug 37645
Author: jakub
Date: Fri Sep 26 05:23:48 2008
New Revision: 140681
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140681
Log:
PR c/37645
* c-common.c
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-26 05:27 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
60 matches
Mail list logo
