Gerald Pfeifer wrote:
> On Thu, 11 Oct 2007, [EMAIL PROTECTED] wrote:
>> Snapshot gcc-4.2-20071011 is now available on
>> ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071011/
>> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
>
> I ran this script manually and reenabled the
On Thu, 11 Oct 2007, [EMAIL PROTECTED] wrote:
> Snapshot gcc-4.2-20071011 is now available on
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071011/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
I ran this script manually and reenabled the generation of snapshots off
th
David Daney wrote:
> Mark Mitchell wrote:
> v v
>> GCC 4.3 Stage 1 (ends Jan 20 2007) GCC 4.2.0 release (May 13
>> 2007)
>> |\
>> v v
>> GCC 4.3 Stage 2
Mark Mitchell wrote:
v v
GCC 4.3 Stage 1 (ends Jan 20 2007) GCC 4.2.0 release (May 13 2007)
|\
v v
GCC 4.3 Stage 2 GCC 4.2.1
Bob Wilson wrote:
> Mark Mitchell wrote:
>> When I sent out the notice about GCC 4.2.2 RC1, I failed to note the GCC
>> 4.2 branch should now be considered slushy; please get my explicit
>> approval before check-in. Obviously, there was no way anyone could have
>> known that, so if things have bee
Mark Mitchell wrote:
When I sent out the notice about GCC 4.2.2 RC1, I failed to note the GCC
4.2 branch should now be considered slushy; please get my explicit
approval before check-in. Obviously, there was no way anyone could have
known that, so if things have been checked in since the announc
On Sat, Sep 01, 2007 at 01:43:37PM -0400, Diego Novillo wrote:
>
> Have you considered using the data sharing machinery in OpenMP? We
> simply create a data structure holding all shared variables, allocate
> that in shared memory and re-write all references to shared variables
> as dereferences t
On 9/1/07, Gary Funck <[EMAIL PROTECTED]> wrote:
> All suggestions/help appreciated, - Gary
Have you considered using the data sharing machinery in OpenMP? We
simply create a data structure holding all shared variables, allocate
that in shared memory and re-write all references to shared variabl
On Thu, 17 May 2007, Dave Korn wrote:
>> Should section "GCC 4.2.0 manuals" of
>>
>> http://gcc.gnu.org/onlinedocs/
>>
>> not also list the "GNU OpenMP Manual" that is available for 4.2?
> Yes, it probably should. The released docs have been prepared correctly:
> http://gcc.gnu.org/onlinedo
On Fri, May 25, 2007 at 02:00:35PM +0200, Corinna Vinschen wrote:
> IMHO, this is a bug in g++. The mangled name in DW_AT_MIPS_linkage_name
> is required so that GDB can correctly recognize mangled c++ symbols.
Yes, I think so. Keep in mind that, in turn, the dependency on
DW_AT_MIPS_linkage_na
On 17 May 2007 12:18, Daniel Franke wrote:
> Should section "GCC 4.2.0 manuals" of
>
> http://gcc.gnu.org/onlinedocs/
>
> not also list the "GNU OpenMP Manual" that is available for 4.2?
>
Yes, it probably should. The released docs have been prepared correctly:
http://gcc.gnu.org/onli
On Tuesday 01 of May 2007 20:08:25 Mark Mitchell wrote:
> GCC 4.2 RC2 is now available from:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070430
>
> There is a known serious problem with RC2: Ada does not build.
> Therefore, there will be an RC3 shortly.
there're two more 4.2-only problems w
On 3/25/07, Ryan Hill <[EMAIL PROTECTED]> wrote:
I couldn't find one so I've filed PR #31359. Apologies if it's a duplicate.
I will again say, "undocumented extensions" don't exist (except for
the case where the documentation is in the source and this was not one
of those cases). This was jus
Ian Lance Taylor wrote:
> Ryan Hill <[EMAIL PROTECTED]> writes:
>> Was there ever any action on this? AFAICS consensus was that the trap
>> would be removed and this behaviour be documented as an extension.
>> There was a bit more discussion of how exactly the documentation would
>> be worded[i]
Ryan Hill <[EMAIL PROTECTED]> writes:
> Mark Mitchell wrote:
> > Ian Lance Taylor wrote:
> >
> >> I realized that I am still not stating my position very clearly. I
> >> don't think we should make any extra effort to make this code work:
> >> after all, the code is undefined. I just think 1) we
Mark Mitchell wrote:
> Ian Lance Taylor wrote:
>
>> I realized that I am still not stating my position very clearly. I
>> don't think we should make any extra effort to make this code work:
>> after all, the code is undefined. I just think 1) we should not
>> insert a trap; 2) we should not ICE.
Paolo Bonzini wrote:
> Mark Mitchell wrote:
>> Paolo Bonzini wrote:
>>
>>> IIUC, the problem only manifests while *building* the release candidates,
>>> not for users of the release candidate.
>>>
>>> For 4.2, my suggestion is to just use a bootstrap4 while building the RC.
>> That's an attractive
Mark Mitchell wrote:
> Paolo Bonzini wrote:
>
>> IIUC, the problem only manifests while *building* the release candidates,
>> not for users of the release candidate.
>>
>> For 4.2, my suggestion is to just use a bootstrap4 while building the RC.
>
> That's an attractive idea. But, I'd rather fix
Paolo Bonzini wrote:
For 4.3, we can use --enable-stage1-languages=all when building the RCs.
I can prepare a patch to do that automatically when
--enable-generated-files-in-srcdir
is passed.
That should not be needed on the trunk, as the .y files in question
(gcc/java/parse.y and gcc/java/
Paolo Bonzini wrote:
> IIUC, the problem only manifests while *building* the release candidates,
> not for users of the release candidate.
>
> For 4.2, my suggestion is to just use a bootstrap4 while building the RC.
That's an attractive idea. But, I'd rather fix it correctly, because
distribut
On Fri, 16 Mar 2007, Mark Mitchell wrote:
> I was thinking about trying to fix this by doing something similar --
> but avoiding the copy.
You still need the srcextra rule around to do the copy, for use in
generating gcc.pot without --egfis - or the regeneration instructions
could change to req
> This didn't apply with 4.1 because then, without toplevel bootstrap, all
> files to be copied to the source directory were generated and copied in
> stage 1, so stage 2 and stage 3 both built them from the source directory.
> Now, stage 1 is not only built as C only but the whole stage 1 bui
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
> > "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> >
> >> This is caused by --enable-generated-files-in-srcdir, as used by the
> >> release script, hence not being seen by people configuring normally
> >> without that option.
Ian Lance Taylor wrote:
> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
>
>> This is caused by --enable-generated-files-in-srcdir, as used by the
>> release script, hence not being seen by people configuring normally
>> without that option.
Thanks for the analysis!
> Since we require GNU make,
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> This is caused by --enable-generated-files-in-srcdir, as used by the
> release script, hence not being seen by people configuring normally
> without that option. The first time Java is built (stage 2), the file
> java/parse.c is generated in the
On Tue, 13 Mar 2007, Mark Mitchell wrote:
> The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with:
>
> Comparing stages 2 and 3
> Bootstrap comparison failure!
> ./java/parse.o differs
> ./java/parse-scan.o differs
This is caused by --enable-generated-files-in-srcdir, as used by
On Thu, Mar 15, 2007 at 05:48:12PM -0700, Joe Buck wrote:
> At one point I considered trying a search to see which files get
> miscompiled, by combining stage1 object files from a run with 3.2.3 and
> 3.4.2 and trying to do the rest of the bootstrap with that, then varying
> which .o files come fro
On Thu, Mar 15, 2007 at 05:30:48PM -0700, Mark Mitchell wrote:
> Joe Buck wrote:
>
> >> For what it's worth, I bootstrapped on a few different GNU/Linux
> >> systems with different kernels and base compilers. I only saw
> >> bootstrap comparison failures on one; that one was running Red Hat 9
> >
Joe Buck wrote:
>> For what it's worth, I bootstrapped on a few different GNU/Linux
>> systems with different kernels and base compilers. I only saw
>> bootstrap comparison failures on one; that one was running Red Hat 9
>> and had gcc 3.2.2 installed in /usr/bin. On that one, a bootstrap4
>> wo
On Thu, Mar 15, 2007 at 04:11:29PM -0700, Ian Lance Taylor wrote:
> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
>
> > On Tue, 13 Mar 2007, Mark Mitchell wrote:
> >
> > > The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with:
> > >
> > > Comparing stages 2 and 3
> > > Bootstrap
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> On Tue, 13 Mar 2007, Mark Mitchell wrote:
>
> > The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with:
> >
> > Comparing stages 2 and 3
> > Bootstrap comparison failure!
> > ./java/parse.o differs
> > ./java/parse-scan.o differs
> >
Joseph S. Myers wrote:
> On Tue, 13 Mar 2007, Mark Mitchell wrote:
>
>> The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with:
>>
>> Comparing stages 2 and 3
>> Bootstrap comparison failure!
>> ./java/parse.o differs
>> ./java/parse-scan.o differs
>>
>> Has anyone else seen this?
>
On Tue, 13 Mar 2007, Mark Mitchell wrote:
> The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with:
>
> Comparing stages 2 and 3
> Bootstrap comparison failure!
> ./java/parse.o differs
> ./java/parse-scan.o differs
>
> Has anyone else seen this?
I'm now looking at this (or at a
On Mon, Mar 12, 2007 at 08:32:43AM -0400, Jack Howarth wrote:
> - else if (decl_readonly_section_1 (exp, reloc, MACHOPIC_INDIRECT))
> + else if (decl_readonly_section (exp, reloc))
Not just that. Try this.
* config/darwin.c (machopic_reloc_rw_mask): New.
(machopic_select_sect
It would seem we need to change...
Index: gcc/config/darwin.c
===
/usr/local/bin/gccdiff: line 1: i#!/bin/bash: No such file or directory
--- gcc/config/darwin.c (revision 122839)
+++ gcc/config/darwin.c (working copy)
@@ -1112,7 +
The breakage on powerpc-apple-darwin8 seems to be due
to revision 122782...
PR target/26090
* target.h (targetm.asm.out.reloc_rw_mask): New.
* target-def.h (TARGET_ASM_RELOC_RW_MASK): New.
(TARGET_ASM_OUT): Use it.
* targhooks.c, targhooks.h (default_relo
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
| On Tue, 24 Oct 2006, Robert Schwebel wrote:
| > I don't understand yet how the next steps for 4.2 will look like; will
| > there be further snapshots (ftp://gcc.gnu.org/pub/gcc/snapshots/) of the
| > 4.2 branch, or will the next snapshots be only for 4.
On Tue, 24 Oct 2006, Robert Schwebel wrote:
> I don't understand yet how the next steps for 4.2 will look like; will
> there be further snapshots (ftp://gcc.gnu.org/pub/gcc/snapshots/) of the
> 4.2 branch, or will the next snapshots be only for 4.3?
The GCC 4.2 snapshots will now track the 4.2 rel
On Fri, Oct 20, 2006 at 08:41:37PM -0700, Mark Mitchell wrote:
> I have created the GCC 4.2 branch.
I don't understand yet how the next steps for 4.2 will look like; will
there be further snapshots (ftp://gcc.gnu.org/pub/gcc/snapshots/) of the
4.2 branch, or will the next snapshots be only for 4.3
Daniel Berlin wrote:
Anyway, i made 43changer.pl and ran it, so the bug summaries have been
updated.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
>> As I understand it, it involves editing the mysql database by hand (well
>> by a script) instead of doing it inside bugzilla. Daniel Berlin has
>> done that the last couple of releases.
>
> I have checked in the attached patch to add this step to the branching
> checklist. I will now ask Dani
Mark Mitchell wrote:
Andrew Pinski wrote:
On Sun, 2006-10-22 at 12:58 +, Joseph S. Myers wrote:
All the bugs with "4.2" in their summaries ("[4.1/4.2 Regression]"
etc.) need to have it changed to "4.2/4.3". I don't know the
procedure for this, but perhaps it needs adding to the branching
Andrew Pinski wrote:
On Sun, 2006-10-22 at 12:58 +, Joseph S. Myers wrote:
All the bugs with "4.2" in their summaries ("[4.1/4.2 Regression]" etc.)
need to have it changed to "4.2/4.3". I don't know the procedure for
this, but perhaps it needs adding to the branching checklist.
As I unde
On Sun, 2006-10-22 at 12:58 +, Joseph S. Myers wrote:
> All the bugs with "4.2" in their summaries ("[4.1/4.2 Regression]" etc.)
> need to have it changed to "4.2/4.3". I don't know the procedure for
> this, but perhaps it needs adding to the branching checklist.
As I understand it, it invo
All the bugs with "4.2" in their summaries ("[4.1/4.2 Regression]" etc.)
need to have it changed to "4.2/4.3". I don't know the procedure for
this, but perhaps it needs adding to the branching checklist.
--
Joseph S. Myers
[EMAIL PROTECTED]
On Fri, 20 Oct 2006, Mark Mitchell wrote:
> 2. I have not regenerated {gcc,cpplib}.pot, or sent them off to the
> translation project. Joseph, would you please do that, at your convenience?
Regeneration done. I'll submit the next 4.2 snapshot to the TP.
--
Joseph S. Myers
[EMAIL PROTECTED]
I am also planning to incorporate many Ada improvements (such as
improved support for Ada 2005) and fixes that
I was holding while the 4.2 branch was not created, I assume this is
not an issue (and very localized to the gcc/ada/ directory of course).
Arno
Mark Mitchell <[EMAIL PROTECTED]> writes:
> IMA for C++ is another difficult case. This is unambiguously useful,
> though duplicative of what we're trying to build with LTO.
Although there are some things you can do with LTO that you can also
do with IMA, there are many things that you can do wi
Kaveh R. GHAZI wrote:
The configury bit was approved by DJ for stage1, but do you see any reason
to hold back? Or is this posting sufficient warning that people may need
to upgrade? (I.e. people should start upgrading their libraries now.)
I don't see any reason to hold back.
Thanks,
--
M
On Tue, 17 Oct 2006, Mark Mitchell wrote:
> As Gerald noticed, there are now fewer than 100 serious regressions open
> against mainline, which means that we've met the criteria for creating
> the 4.2 release branch. (We still have 17 P1s, so we've certainly got
> some work left to do before creat
Mark,
I just posted two small patches which together complete the
fix for PR26792. This knocks one blocking PR1 off the list.
Jack
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00906.html
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00908.html
On Wed, 6 Sep 2006, Gerald Pfeifer wrote:
> On Wed, 6 Sep 2006, [EMAIL PROTECTED] wrote:
> > Snapshot gcc-4.2-20060906 is now available on
> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060906/
> > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
>
> In case anybody wonde
On Wed, 6 Sep 2006, [EMAIL PROTECTED] wrote:
> Snapshot gcc-4.2-20060906 is now available on
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060906/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
In case anybody wonders about this: since last weeks snapshot was
broken (on
On Fri, Sep 01, 2006 at 11:51:54AM -0400, Kate Minola wrote:
> Hi!
>
> I like to test the weekly snapshots of the active development
> branch against code that I am particularly interested in.
>
> I realize that snapshots are just that - and so do not
> worry unless I see the same failure a coupl
Andrew Haley wrote:
> Yuri Pudgorodsky writes:
> >
> > > We can say something like:
> > >
> > > "In GNU C, you may cast a function pointer of one type to a function
> > > pointer of another type. If you use a function pointer to call a
> > > function, and the dynamic type of the function po
On Monday 10 July 2006 22:42, [EMAIL PROTECTED] wrote:
> > Snapshot gcc-4.2-20060708 is now available on
> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060708/
>
> something is brkoen here ...
> [~/gcc]
>
> >../gcc-src/gcc-4.2-20060708/gcc/configure
>
ups, should of course have been
../gcc-src/gc
> Snapshot gcc-4.2-20060708 is now available on
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060708/
something is brkoen here ...
[~/gcc]
>../gcc-src/gcc-4.2-20060708/gcc/configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system
Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | The result of calling function pointer casted to sufficiently different
| > | type is
| > | a real example an undefined behavior.
| >
| > As I said earlie
Gabriel Dos Reis wrote:
> Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | The result of calling function pointer casted to sufficiently different
> | type is
> | a real example an undefined behavior.
>
> As I said earlier, it is fruitless to try to impose an ordering on
> the space of
Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
[...]
| The result of calling function pointer casted to sufficiently different
| type is
| a real example an undefined behavior.
As I said earlier, it is fruitless to try to impose an ordering on
the space of undefined behaviour.
-- Gaby
Yuri Pudgorodsky writes:
>
> > We can say something like:
> >
> > "In GNU C, you may cast a function pointer of one type to a function
> > pointer of another type. If you use a function pointer to call a
> > function, and the dynamic type of the function pointed to by the
> > function poin
> We can say something like:
>
> "In GNU C, you may cast a function pointer of one type to a function
> pointer of another type. If you use a function pointer to call a
> function, and the dynamic type of the function pointed to by the
> function pointer is not the same as indicated by the static
Andrew Haley wrote:
> Mark Mitchell writes:
> >
> > I also agree with Gaby that we should document this as an extension. If
> > we go to the work of putting it back in, we should ensure that it
> > continues to work for the foreseeable future. Part of that is writing
> > down what we've dec
Mark Mitchell writes:
>
> I also agree with Gaby that we should document this as an extension. If
> we go to the work of putting it back in, we should ensure that it
> continues to work for the foreseeable future. Part of that is writing
> down what we've decided.
We can't make function po
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Ian Lance Taylor wrote:
|
| > I realized that I am still not stating my position very clearly. I
| > don't think we should make any extra effort to make this code work:
| > after all, the code is undefined. I just think 1) we should not
| > insert a t
Ian Lance Taylor wrote:
> I realized that I am still not stating my position very clearly. I
> don't think we should make any extra effort to make this code work:
> after all, the code is undefined. I just think 1) we should not
> insert a trap; 2) we should not ICE.
I agree. If the inlining
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Andrew Haley <[EMAIL PROTECTED]> writes:
|
| > If we make a change for openssh to allow this undefined behaviour,
| > then do we agree to keep it working or not? If we agree that we will,
| > then we have to at least add some test cases and we have
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
[...]
| I personally don't agree that this needs to be a documented extension.
| I'm simply going on a more general rule which I tried to state above:
| I don't think we should insert a trap call for undefined code.
If it should not a documented exten
Ian Lance Taylor wrote:
Mike Stump <[EMAIL PROTECTED]> writes:
On Jul 4, 2006, at 5:18 PM, Andrew Pinski wrote:
And I posted a patch to do the same in Objective-C mode as C mode :).
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
Is the reason that Objective-C was excl
Mike Stump <[EMAIL PROTECTED]> writes:
> On Jul 4, 2006, at 5:18 PM, Andrew Pinski wrote:
> > And I posted a patch to do the same in Objective-C mode as C mode :).
> > http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
>
> Is the reason that Objective-C was excluded been fixed? If so, while
On Jul 4, 2006, at 5:18 PM, Andrew Pinski wrote:
And I posted a patch to do the same in Objective-C mode as C mode :).
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
Is the reason that Objective-C was excluded been fixed? If so, while
I don't like the semantics in place now, I'd rat
Mark Mitchell wrote:
I'm not sure the number above is in and of itself terribly meaningful,
in part because Volker has been filing many
ICE-on-invalid-after-error-message PRs against the C++ front end. These
don't really even show up for users in releases, due to the "confused by
earlier errors
>
> What happens when a target comes along and passes different pointers
> types
> differently. Like say a floating point pointer in the FP register and an
> pointer to an integer in the general purpose register, wouldn't that also
> break the code in question? Yes this is in theory but still sa
On 05 July 2006 17:12, Andrew Pinski wrote:
> On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote:
>
>> To me this is related to the point I raised at the steering committee
>> panel discussion (I know you weren't there): I think we are too casual
>> about breaking existing working code.
>
> What
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote:
>
> > To me this is related to the point I raised at the steering committee
> > panel discussion (I know you weren't there): I think we are too casual
> > about breaking existing working code.
>
> Wha
On Wed, Jul 05, 2006 at 09:11:32AM -0700, Andrew Pinski wrote:
> What happens when a target comes along and passes different pointers
> types differently. Like say a floating point pointer in the FP
> register and an pointer to an integer in the general purpose
> register, wouldn't that also break
On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote:
To me this is related to the point I raised at the steering committee
panel discussion (I know you weren't there): I think we are too casual
about breaking existing working code.
What happens when a target comes along and passes different po
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > If we make a change for openssh to allow this undefined behaviour,
> > then do we agree to keep it working or not? If we agree that we will,
> > then we have to at least add some test cases and we have to add some
> >
Andrew Haley <[EMAIL PROTECTED]> writes:
> If we make a change for openssh to allow this undefined behaviour,
> then do we agree to keep it working or not? If we agree that we will,
> then we have to at least add some test cases and we have to add some
> internal documentation to gcc. If we don'
> For what it's worth, I tried to recreate the ICE after removing the
> trap insertion, but failed. So I'm not even sure the trap insertion
> is fixing a real problem any more. It works at the moment simply
> because it treats the call through a cast as a call through a function
> pointer, and t
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> I personally don't agree that this needs to be a documented extension.
> I'm simply going on a more general rule which I tried to state above:
> I don't think we should insert a trap call for undefined code.
I realized that I am still not stating my
> What do we do if compiler ICE generating code for valid C syntax with
> defined behavior? Fix it!
> Why should we go another way for valid C syntax with undefined behavior?
The answer is in the question, no?
--
Eric Botcazou
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > If we're going to guarantee this stuff for the future, we'll have
> > to fix the bug, make sure it's doesn't destabilize the compiler
> > and write some test cases. If we're really serious about it we
> > should make
> I apologize for presenting something which appears to be a strawman
> argument. That would never be my intent. Let me restate: I don't
> think gcc should ever insert a trap call for undefined code. We
> should only insert a trap call for code which will provably trap.
>
> We're currently brea
Andrew Haley <[EMAIL PROTECTED]> writes:
> > > keating> Because if you *do* try to inline the call, you will get an ICE.
> >
> > Yes, I agree that the ICE, if it still exists, would have to be fixed,
> > but to me that seems like a separate issue.
>
> No, it isn't a separate issue. We gener
>
> I believe I understand your general objection. I don't feel strongly
> about the current behaviour, except that if it has to change then it
> must be a documented extension.
>
> I don't think we can meaningfully order the space of "undefined
> behaviour" and single out some as are "more un
Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Furthermore, I've read people suggesting that we are gratuitously
| > broking code. That is misleading. The code was invoking undefined
| > behaviour and, before, we did not make any explicit guarantee about
| > the seman
Gabriel Dos Reis wrote:
> Furthermore, I've read people suggesting that we are gratuitously
> broking code. That is misleading. The code was invoking undefined
> behaviour and, before, we did not make any explicit guarantee about
> the semantics.
> It is one thing to argue for changing gear; but
Andrew Pinski wrote:
>
> On Jul 5, 2006, at 2:36 AM, Yuri Pudgorodsky wrote:
>
>> 1) with direct cast: (int (*)(int)) foo
>> - warn/trap since 3.x
>> 2) with cast through void fptr: (int (*)(int)) (int(*)()) foo
>> - warn/trap since 4.2 current
>
> I don't see why you are invoking this undefined be
Andrew Haley <[EMAIL PROTECTED]> writes:
[...]
| If we're going to guarantee this stuff for the future, we'll have to
| fix the bug, make sure it's doesn't destabilize the compiler and write
| some test cases. If we're really serious about it we should make it a
| documented extension to C.
if
On Jul 5, 2006, at 2:36 AM, Yuri Pudgorodsky wrote:
1) with direct cast: (int (*)(int)) foo
- warn/trap since 3.x
2) with cast through void fptr: (int (*)(int)) (int(*)()) foo
- warn/trap since 4.2 current
I don't see why you are invoking this undefined behavior anyways.
What are you trying t
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Ian Lance Taylor writes:
> > > Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
> > >
> > > > Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2
> > > > fortifies its check for function pointer conversi
Andrew Pinski wrote:
>
> On Jul 4, 2006, at 5:07 PM, Yuri Pudgorodsky wrote:
>
>> Can someone make the decision to reopen PR optimization/12085?
>
> And I posted a patch to do the same in Objective-C mode as C mode :).
> http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
>
That indeed will fi
On Jul 4, 2006, at 5:07 PM, Yuri Pudgorodsky wrote:
Can someone make the decision to reopen PR optimization/12085?
And I posted a patch to do the same in Objective-C mode as C mode :).
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
-- Pinski
So that ICE still exist for objective-c and is just hidden with
warn/trap workaround
for c/c++:
double foo(double arg)
{
return arg;
}
int bar(int d)
{
d = ((int (*) (int)) foo)(d);
return d *d;
}
If you compile the above example in objective-c mode (gcc -O3 -x
objective-c),
current mainl
Andrew Haley <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
> > Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
> >
> > > Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2
> > > fortifies its check for function pointer conversion and generates
> > > abort for PEM_read_X50
Ian Lance Taylor writes:
> Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
>
> > Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2
> > fortifies its check for function pointer conversion and generates
> > abort for PEM_read_X509_AUX() and similar wrappers.
>
> Personally speaki
Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
> Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2
> fortifies its check for function pointer conversion and generates
> abort for PEM_read_X509_AUX() and similar wrappers.
Personally speaking, I agree with you that the compiler should
But right now what is given in the bug report is hard to reproduce as there is
no source
Right. I added a short snippet that reproduces the problem.
-BenRI
>
> Ian Lance Taylor wrote:
> > Benjamin Redelings <[EMAIL PROTECTED]> writes:
> >
> >
> >> substitution.o:(.data+0x0): multiple definition of
> >> `_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE'
> >>
> >
> > I can't make sense of that as a mangled name. It has template
1 - 100 of 147 matches
Mail list logo
