> PR 22111 is about libstdc++-v3 being built with binutils 2.15, while
> 2.15.90 or later are required by the patch.
I say we solve this instead by enabling the abi checking rule only for
those platforms that are using symbol versioning. In addition, we try
to come up with an autoconf macro that
[Gaby wants Vincent to explain:]
Vincent Lefevre <[EMAIL PROTECTED]> writes:
# This is complete non-sense. One doesn't prepare a patch for an invalid
# bug.
[Michael tries to interpret Vincent:]
| I think that what Vincent meant was:
| "One doesn't prepare a patch for a PR marked as INVALID"
On Jun 20, 2005 09:51 AM, Michael Veksler <[EMAIL PROTECTED]> wrote:
> Despite being descriptive and friendly, bug masters
> frustrate me and other users by being too eager
> to close the PR. I would suggest a policy change,
> a PR should be closed (as duplicate or as INVALID)
> only after discuss
On Sun, Jun 19, 2005 at 06:49:32PM -0400, Bill wrote:
> Below is the error I receive when attempting to run a newly installed
> version of netscape 4.79 on centOS 4.0 (RHEL 3), which is my personal
> computer at home. This is the only browser that works on linux that is
> compatible with the Thori
Steven Bosscher <[EMAIL PROTECTED]> wrote on 20/06/2005 11:13:35:
> On Jun 20, 2005 09:51 AM, Michael Veksler <[EMAIL PROTECTED]> wrote:
>
> > Despite being descriptive and friendly, bug masters
> > frustrate me and other users by being too eager
> > to close the PR. I would suggest a policy c
Paul Schlie wrote on 20/06/2005 08:55:20:
> y = z ? z + x;// y == [INT_MIN+1, INT_MAX+2]
Invalid syntax, what did you mean?
> I guess I simply believe that optimizations should never alter the
logical
> behavior of a specified program relative to it's un-optimized form unless
> explic
Mike Stump <[EMAIL PROTECTED]> writes:
> On Friday, June 17, 2005, at 07:13 AM, Sergei Organov wrote:
> > The first thing I'd like to get some advice on is which codebase do I
> > use, gcc-4_0-branch?
>
> No, mainline. If it doesn't work there, is won't work anyplace else. :-(
> Once you get it
Paul Schlie wrote:
My position is simply that an optimization should never remove a specified
operation unless it is known to yield logically equivalent behavior, as
producing a program which does not behave as specified is not a good idea
That may be your position, but it is not the position
Robert Dewar wrote:
That may be your position, but it is not the position of the standard, and
indeed it is not a well-formed position. Why, because the whole point is
that
when the behavior is undefined, then the change DOES yield a logically
equivalent behavior, because undefined means undef
On Mon, 20 Jun 2005, Mark Williams (MWP) wrote:
> >
> > >
> > > Yes i did... i always do and have never had a problem doing so before.
> > > I will try building in a different directory though and report back.
> >
> > http://gcc.gnu.org/install/configure.html
> >
> > To be honest I'm always su
> From: Michael Veksler <[EMAIL PROTECTED]>
> Paul Schlie wrote on 20/06/2005 08:55:20:
>> y = z ? z + x;// y == [INT_MIN+1, INT_MAX+2]
> Invalid syntax, what did you mean?
Sorry, meant:
y = z + x; // y == [INT_MIN, INT_MAX] + [1, 2] == [INT_MIN+1, INT_MAX+2]
>> I guess I simply believe t
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>
>> My position is simply that an optimization should never remove a specified
>> operation unless it is known to yield logically equivalent behavior, as
>> producing a program which does not behave as specified is not a good idea
>
>
> From: Robert Dewar <[EMAIL PROTECTED]>
> Robert Dewar wrote:
>
>> That may be your position, but it is not the position of the standard, and
>> indeed it is not a well-formed position. Why, because the whole point is
>> that
>> when the behavior is undefined, then the change DOES yield a logical
Paul Schlie wrote:
As in my mind, the semantics of foo() dictate that it print the value of
the storage location which was allocated to the variable "a", where unless
"a" is initialized with an explicit value, may be arbitrary. So I've got no
problem with arbitrary results or behavior, I just si
Paul Schlie wrote:
I too believe I understand your position, however don't believe it's the
compiler's job to make life for the programmer harder than it need be when
a program may contain an undefined behavior; but agree it would likely
always be helpful to for it to point them out when identif
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>
>> As in my mind, the semantics of foo() dictate that it print the value of
>> the storage location which was allocated to the variable "a", where unless
>> "a" is initialized with an explicit value, may be arbitrary. So I've got no
>
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>
>> I too believe I understand your position, however don't believe it's the
>> compiler's job to make life for the programmer harder than it need be when
>> a program may contain an undefined behavior; but agree it would likely
>> alw
Michael Veksler <[EMAIL PROTECTED]> writes:
| [Gaby wants Vincent to explain:]
| Vincent Lefevre <[EMAIL PROTECTED]> writes:
| # This is complete non-sense. One doesn't prepare a patch for an invalid
| # bug.
|
| [Michael tries to interpret Vincent:]
| | I think that what Vincent meant was:
| |
Paul Schlie <[EMAIL PROTECTED]> wrote on 20/06/2005 14:03:53:
> > From: Michael Veksler <[EMAIL PROTECTED]>
...
> > Almost any optimization over line 8 will change the
> > behavior of line 4. I believe that you did not intend to
> > cover this case in your requirement. Maybe you would
> > like
Paul Schlie wrote:
- You may be correct, although it's not obviously the case? (As requiring
all undefined behavior be encapsulated between sequence points already
seems implied to me, as I don't see any explicit counter examples
requiring otherwise.
There don't need to be examples. The
Michael Veksler wrote:
Getting a consistent definition of "bounded side-effects"
is a nontrivial task. Simply hacking and patching the
definition does not work. Trust me, I've been there done
that, got burnt and are still paying for my sins.
Indeed! I think anyone who has been involved in the
Paul Schlie wrote on 20/06/2005 14:13:33:
> > From: Robert Dewar <[EMAIL PROTECTED]>
...
> > Note that in the cases where something is statically optimized away
(these
> > are the easy cases), it is nice if the compiler warns that this is
happening
> > (that would certainly be the case in Ada
Michael Veksler wrote:
As for overflow, you can say that you want instead of "undefined"
to treat is "unspecified".
In Ada 95 we introduced a new category of behavior, called a bounded
error. We tried to recategorize as many erroneous (= C undefined)
cases as possible to bounded error.
A bou
> From: Robert Dewar <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>
>> - You may be correct, although it's not obviously the case? (As requiring
>> all undefined behavior be encapsulated between sequence points already
>> seems implied to me, as I don't see any explicit counter examples
>> requ
> From: Michael Veksler <[EMAIL PROTECTED]>>
>> Paul Schlie wrote on 20/06/2005 14:13:33:
>>> From: Robert Dewar <[EMAIL PROTECTED]>
> ...
>>> Note that in the cases where something is statically optimized away
>>> (these are the easy cases), it is nice if the compiler warns that this
>>> is happen
I checked in the following patch to fix PR 1022.
H.J.
2005-06-20 H.J. Lu <[EMAIL PROTECTED]>
PR 1022
* elf32-hppa.c (elf32_hppa_check_relocs): Handle indirect
symbol.
--- bfd/elf32-hppa.c.got2005-05-19 06:51:55.0 -0700
+++ bfd/elf32-hppa.c2005-
Paul Schlie wrote:
There don't need to be examples. The as-if rule always applies, if you cannot
write a legitimate C program that shows the difference between two possible
implementations, then both are correct.
??? as-if means they're logically equivalent (i.e. there is no logical
differenc
Paul Schlie wrote:
- yes, effectively I don't perceive any necessity for undefined, vs
unspecified; as I don't perceive any necessity to give the compiler
the freedom to treat generate an arbitrary program which may contain
a potentially ambiguous specific and isolatable behavior.
OK, then you
Robert Dewar wrote:
> Yes, absolutely, a compiler should generate warnings as much as possible when
> it is making these kind of assujmptions.
Then, you will like the following kind of patches:
Index: tree-data-ref.c
===
RCS file: /c
Hi,
Using gcc compiled from gcc-4_0-branch, in an attempt to see which
particular optimization option makes my test case to be mis-optimized, I
try to replace -O1 (which toggles on the problem) with corresponding set
of -fxxx optimization options. I first compile my code like this:
gcc -v -save-t
Sergei Organov writes:
> Hi,
>
> Using gcc compiled from gcc-4_0-branch, in an attempt to see which
> particular optimization option makes my test case to be mis-optimized, I
> try to replace -O1 (which toggles on the problem) with corresponding set
> of -fxxx optimization options.
In gener
Sergei Organov wrote:
> Using gcc compiled from gcc-4_0-branch, in an attempt to see which
> particular optimization option makes my test case to be mis-optimized,
This sort of problem is exactly what my Acovea program was designed for;
it will identify the pessimistic option by analyzing GCC's co
On Jun 20, 2005, at 10:04 AM, Andrew Haley wrote:
How one finds out what optimization pass misbehaves?
Look at the dumps. If you use the gcc option -da you'll get a full
set of RTL dump files.
And -fdump-tree-all for the tree dumps.
Thanks,
Andrew Pinski
Andrew Haley <[EMAIL PROTECTED]> writes:
> Sergei Organov writes:
> > Hi,
> >
> > Using gcc compiled from gcc-4_0-branch, in an attempt to see which
> > particular optimization option makes my test case to be mis-optimized, I
> > try to replace -O1 (which toggles on the problem) with corresp
On Jun 20, 2005, at 9:38 AM, Sergei Organov wrote:
2. The resulting assembly is different from what I get with -O1 and
doesn't contain the mis-optimization I'm trying to debug though it
doesn't seem to have anything to do with loops. For reference, the
code I'm trying to compile is:
Paul Schlie <[EMAIL PROTECTED]> wrote on 20/06/2005 16:09:16:
> > From: Michael Veksler <[EMAIL PROTECTED]>>
> > As for overflow, you can say that you want instead of "undefined"
> > to treat is "unspecified". Where each architecture / opsys / compiler
> > must consistently define what happens
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 10:04 AM, Andrew Haley wrote:
> >> How one finds out what optimization pass misbehaves?
> >
> > Look at the dumps. If you use the gcc option -da you'll get a full
> > set of RTL dump files.
>
> And -fdump-tree-all for the tree dumps.
Richard Henderson <[EMAIL PROTECTED]> wrote on 20/06/2005 01:13:11:
> On Sun, Jun 19, 2005 at 11:46:52PM +0300, Dorit Naishlos wrote:
> > The thought was to supply an API that would let the vectorizer ask for
the
> > minimal capability it needs - if all we need is a vector shift of a
> > consta
On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when
-O1
is turned on. Seems to be something at tree-to-RTX conversion time.
Constant folding?
No, it would mean that the target says that this is not a small data.
Also try it
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 9:38 AM, Sergei Organov wrote:
>
> > 2. The resulting assembly is different from what I get with -O1 and
> >doesn't contain the mis-optimization I'm trying to debug though it
> >doesn't seem to have anything to do with loops.
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
>
> > so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
>
> > is turned on. Seems to be something at tree-to-RTX conversion time.
> > Constant folding?
>
> No, it would mean th
On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
Andrew Pinski <[EMAIL PROTECTED]> writes:
On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when
-O1
is turned on. Seems to be something at tree-to-RTX conversion time.
C
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
>
> > Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> >>
> >>> so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
>
> >>
On Jun 20, 2005, at 11:39 AM, Daniel Berlin wrote:
This is blocking me fixing the structure aliasing regressions.
This was caused by:
2005-06-15 Joseph S. Myers <[EMAIL PROTECTED]>
* c-tree.h (default_function_array_conversion): Declare.
* c-typeck.c (default_function_array
> It is my strong preference to not do macro defines in c++config.h as
> per your last patch.
Strike this, it's incorrect. Sorry Jakub.
If doing this gets around the bad link behavior, at this point, I'm
for it. I suggest you put in a link to 22109 to your patch. Then, the
patches for 22109 and
On Jun 20, 2005, at 11:39 AM, Daniel Berlin wrote:
This is new, i assume.
This is blocking me fixing the structure aliasing regressions.
I've attached pex-unix.i. Compile with -pendantic to see the crash.
Here is a reduced testcase:
typedef union
{
union wait *__uptr;
int *__iptr
On Mon, 20 Jun 2005, Daniel Berlin wrote:
> The crash line is
> 3729 if (pedantic && !DECL_IN_SYSTEM_HEADER (fundecl))
>
> Here, fundecl is null.
Any problem with fundecl being null should also be reproducible with a
call through a function pointer where fundecl would never have b
On Mon, 2005-06-20 at 16:05 +, Joseph S. Myers wrote:
> On Mon, 20 Jun 2005, Daniel Berlin wrote:
>
> > The crash line is
> > 3729 if (pedantic && !DECL_IN_SYSTEM_HEADER (fundecl))
> >
> > Here, fundecl is null.
>
> Any problem with fundecl being null should also be reproducibl
> Knowing that you do regular Cygwin builds of gcc, I wonder can you advise
> me, please? For the better part of a month, I have not succeeded in
> building gcc from the CVS tree under Cygwin_NT-5.1 for one reason or
> another.
That's PR 21766 (appropriately named "Bootstrap failure on
i686-pc-cy
Thanks Francois-Xavier and Andrew for replying,
That's PR 21766 (appropriately named "Bootstrap failure on
i686-pc-cygwin"). Opened almost a month ago. GCC mainline doesn't
build on cygwin or mingw since that time.
Seeing that almost no comment had been made by the maintainers on it,
and no c
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
>
> > Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> >>
> >>> so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
>
> >>
> From: Michael Veksler <[EMAIL PROTECTED]>
>> Paul Schlie <[EMAIL PROTECTED]> wrote on 20/06/2005 16:09:16:
>>> From: Michael Veksler <[EMAIL PROTECTED]>>
>>> As for overflow, you can say that you want instead of "undefined"
>>> to treat is "unspecified". Where each architecture / opsys / compiler
> Then, you will like the following kind of patches:
>
> + warning (0, "%H undefined behavior if loop runs for more than %qE
> iterations",
> +find_loop_location (loop), estimation);
I think we would like them better if you could choose to silence them,
especially when people u
I checked in the following patch to fix other targets.
H.J.
2005-06-20 H.J. Lu <[EMAIL PROTECTED]>
PR 1025
* elf-m10300.c (mn10300_elf_check_relocs): Handle indirect
symbol.
* elf32-arm.c (elf32_arm_check_relocs): Likewise.
* elf32-avr.c (elf32_avr_
[EMAIL PROTECTED] (Tommy Vercetti) wrote on 19.06.05 in <[EMAIL PROTECTED]>:
> I was looking on different ones, for C, that claimed to have ability to find
> security problems. One that I found the best, is splint. But it's still not
> able to find such obvious problem:
Did you look at sparse? T
[EMAIL PROTECTED] (Robert Dewar) wrote on 19.06.05 in <[EMAIL PROTECTED]>:
> Kai Henningsen wrote:
>
> > But at least, in that case, the compiler could easily issue the
> > (presumably not required by the standard) warning that the else branch is
> > "unreachable code".
>
> Yes, absolutely, a com
On Monday 20 June 2005 10:12, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Tommy Vercetti) wrote on 19.06.05 in
<[EMAIL PROTECTED]>:
> > I was looking on different ones, for C, that claimed to have ability to
> > find security problems. One that I found the best, is splint. But it's
> > still not a
On Jun 16, 2005, at 3:06 PM, Mike Stump wrote:
Actually, by try, I meant try your application. :-)
I can't seem to build any 64-bit shared library on powerpc-apple-
darwin8.1.0, although I can now run the test suite more effectively; see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
General note, please, this list is for developers of gcc to develop
gcc. Using it as a way to teach yourself how to read the C standard,
isn't ok, please stop.
On Saturday, June 18, 2005, at 07:15 AM, Paul Schlie wrote:
Maybe I didn't phrase my statement well;
I think you did, you are j
On Jun 18, 2005, at 11:50 AM, Paul Schlie wrote:
[ curiously can't find any actual reference stating that integer
overflow
is specifically results in undefined behavior, although it's
obviously ill defined?
Every operation that isn't defined is undefined. Only the operations
that are de
Hi Ayal,
Thanks for the inputs, I will try this on GCC 4.0, which sounds quite
interesting.
regards,
Vasanth
On 6/15/05, Ayal Zaks <[EMAIL PROTECTED]> wrote:
>
>
>
>
> > Vasanth <[EMAIL PROTECTED]>
>
> > I am using powerpc-eabi-gcc (3.4.1) and trying to retarget it for a
> > fully pipelined
61 matches
Mail list logo
