Re: [ANNOUNCE]: clang compiling ports, take 2
Ivan Klymenko wrote on 04.09.2011 11:12: В Sun, 04 Sep 2011 10:42:07 +0400 Ruslan Mahmatkhanovcvs-...@yandex.ru пишет: Roman Divacky wrote on 25.07.2011 19:59: Hi! Flz@ just run another exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/ Since the last run we've managed to fix the biggest offenders but that uncovered others that need fixing. The Reason column was extended and now shows assumes_gcc which is the lowest hanging fruit :) A lot of these failures are trivial to fix (ie. assumes_gcc reason) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us again! Roman Divacky Hi, i maintain port (sysutils/rdup) that is failing with clang: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/rdup-1.1.11_1.log But it's hard to realize to me how to fix this. I've tried irc (#freebsd-clang and #freebsd-ports on irc.oftc.net) - and nobody hangs there. Can please anybody help? Maybe this will help: *rdup_entry = *rdup_entry; Thank you all for suggestions, i already wrote to an rdup author and waiting for response. -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
Michel Talon wrote on 04.09.2011 11:29: Ruslan wrote: Hi, i maintain port (sysutils/rdup) that is failing with clang: I have looked at the problem, it is indeed in rdup source. If you look at rdup git history for rdup-tr.c you will see remove rdup_entry_c from the code, totally unneeded in this modification, the line rdup_entry_c = rdup_entry; which makes sense is (probably automatically) replaced by the line rdup_entry = rdup_entry; which is superfluous. gcc doesn't bark at that while clang does. Thanks, i'll look at this. As i understand, all will be fine if i just revert this line. -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
Roman Divacky wrote on 25.07.2011 19:59: Hi! Flz@ just run another exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/ Since the last run we've managed to fix the biggest offenders but that uncovered others that need fixing. The Reason column was extended and now shows assumes_gcc which is the lowest hanging fruit :) A lot of these failures are trivial to fix (ie. assumes_gcc reason) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us again! Roman Divacky Hi, i maintain port (sysutils/rdup) that is failing with clang: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/rdup-1.1.11_1.log But it's hard to realize to me how to fix this. I've tried irc (#freebsd-clang and #freebsd-ports on irc.oftc.net) - and nobody hangs there. Can please anybody help? -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
Ruslan wrote: Hi, i maintain port (sysutils/rdup) that is failing with clang: I have looked at the problem, it is indeed in rdup source. If you look at rdup git history for rdup-tr.c you will see remove rdup_entry_c from the code, totally unneeded in this modification, the line rdup_entry_c = rdup_entry; which makes sense is (probably automatically) replaced by the line rdup_entry = rdup_entry; which is superfluous. gcc doesn't bark at that while clang does. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
В Sun, 04 Sep 2011 10:42:07 +0400 Ruslan Mahmatkhanov cvs-...@yandex.ru пишет: Roman Divacky wrote on 25.07.2011 19:59: Hi! Flz@ just run another exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/ Since the last run we've managed to fix the biggest offenders but that uncovered others that need fixing. The Reason column was extended and now shows assumes_gcc which is the lowest hanging fruit :) A lot of these failures are trivial to fix (ie. assumes_gcc reason) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us again! Roman Divacky Hi, i maintain port (sysutils/rdup) that is failing with clang: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/rdup-1.1.11_1.log But it's hard to realize to me how to fix this. I've tried irc (#freebsd-clang and #freebsd-ports on irc.oftc.net) - and nobody hangs there. Can please anybody help? Maybe this will help: *rdup_entry = *rdup_entry; ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
Am 04.09.2011 05:09, schrieb Gerald Pfeifer:
On Mon, 25 Jul 2011, Matthias Andree wrote:
Namely: if a port sets USE_GCC=4.2+ (for instance, sysutils/busybox does
that), the Pointyhat build does not install GCC. I think the bug is in
ports/Mk/bsd.gcc.mk which is unaware that there are newer clang-based
9-CURRENT systems without gcc.
I hope we can have another -exp run soon that addresses this.
Matthias, sorry for not getting to this earlier. If you look at
Mk/bsd.port.mk, there is a line
GCCVERSION_040200= 700042 99 4.2
which indicates that GCC 4.2 has been in the base system starting
with FreeBSD 7.0 (and that magic 42 marker) until the rest of times.
Can you advise which value of __FreeBSD_version to use? The official
list at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html
does not have a reference from what I can see.
Gerald,
I'm not sure if checking one of the OS Version features will be
sufficient. I am unaware of how exactly the Clang switchover is going
to happen, and how we detect it.
Possibly we need to check if ${CC} is part of the base system, and if it
isn't, install a GCC port, at least for now.
Best,
Matthias
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
Am 04.09.2011 08:42, schrieb Ruslan Mahmatkhanov: Roman Divacky wrote on 25.07.2011 19:59: Hi! Flz@ just run another exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/ Since the last run we've managed to fix the biggest offenders but that uncovered others that need fixing. The Reason column was extended and now shows assumes_gcc which is the lowest hanging fruit :) A lot of these failures are trivial to fix (ie. assumes_gcc reason) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us again! Roman Divacky Hi, i maintain port (sysutils/rdup) that is failing with clang: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/rdup-1.1.11_1.log But it's hard to realize to me how to fix this. I've tried irc (#freebsd-clang and #freebsd-ports on irc.oftc.net) - and nobody hangs there. Can please anybody help? Solution: (Have the author) fix the code to not do stupid things like this: clang -Wall -W -Werror -O2 -pipe -fno-strict-aliasing -I/usr/local/include -DHAVE_CONFIG_H -DLOCALEROOTDIR=\/usr/local/share/locale\ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -Os -Wpointer-arith -Wstrict-prototypes -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -c rdup-tr.c rdup-tr.c:205:14: error: explicitly assigning a variable of type 'struct rdup *' to itself [-Werror,-Wself-assign] rdup_entry = rdup_entry; ~~ ^ ~~ 1 error generated. gmake: *** [rdup-tr.o] Error 1 It's probably a logic error, or mistyped. Clang also states that the error manifests itself by: -Wself-assign is part of -Wall or -W (didn't check which one) that triggers this warning -Werror turns all warnings into errors Workarounds are: add -Wno-self-assign, omit -Werror. I don't recommend either. Also ask the author to make sure that -Werror is accompanied by -pedantic during development upstream so that all mandatory diagnostics are actually enabled, and possibly also with -std=c99 or -std=c89 unless GNU extensions are used. HTH Matthias ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
On Sun, Sep 04, 2011 at 05:09:05AM +0200, Gerald Pfeifer wrote: Can you advise which value of __FreeBSD_version to use? The official list at http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html does not have a reference from what I can see. There is no version of FreeBSD that has the gcc build turned off AFAIK. Nor is there one where cc is clang by default; again AFAIK. You can, of course, create a userland that has clang but not gcc if you manually configure it. Please someone correct me if I am wrong. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
В Sun, 04 Sep 2011 09:34:33 +0200 Matthias Andree mand...@freebsd.org пишет: Am 04.09.2011 09:12, schrieb Ivan Klymenko: Maybe this will help: *rdup_entry = *rdup_entry; This is just guessing and probably triggers the same warning unless it's volatile. Have the original author look at it. This is not guesswork. All is going without any errors and warnings. setenv |grep clang CC=clang CXX=clang++ cd /usr/ports/sysutils/rdup make patch rdup_entry = rdup_entry; = *rdup_entry = *rdup_entry; make build.log ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
Am 04.09.2011 10:45, schrieb Ivan Klymenko: В Sun, 04 Sep 2011 09:34:33 +0200 Matthias Andree mand...@freebsd.org пишет: Am 04.09.2011 09:12, schrieb Ivan Klymenko: Maybe this will help: *rdup_entry = *rdup_entry; This is just guessing and probably triggers the same warning unless it's volatile. Have the original author look at it. This is not guesswork. It is DANGEROUS guesswork. Assigning stuff to itself is pointless, so this is a code bug. The only valid exception I know is if you're writing back data to a command register in a peripheral device, which isn't the case here. Fix the bug, not the symptom! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
Am 04.09.2011 10:48, schrieb Mark Linimon: On Sun, Sep 04, 2011 at 05:09:05AM +0200, Gerald Pfeifer wrote: Can you advise which value of __FreeBSD_version to use? The official list at http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html does not have a reference from what I can see. There is no version of FreeBSD that has the gcc build turned off AFAIK. Nor is there one where cc is clang by default; again AFAIK. You can, of course, create a userland that has clang but not gcc if you manually configure it. Please someone correct me if I am wrong. Basically USE_GCC=4.2+ was trying to sidestep clang issues in my ports in the -exp runs, and in this situation, USE_GCC=4.2+ was not installing gcc. How do I do that? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
On Sun, 04 Sep 2011 12:22:35 +0200 Matthias Andree mand...@freebsd.org wrote: Am 04.09.2011 10:45, schrieb Ivan Klymenko: В Sun, 04 Sep 2011 09:34:33 +0200 Matthias Andree mand...@freebsd.org пишет: Am 04.09.2011 09:12, schrieb Ivan Klymenko: Maybe this will help: *rdup_entry = *rdup_entry; This is just guessing and probably triggers the same warning unless it's volatile. Have the original author look at it. This is not guesswork. It is DANGEROUS guesswork. Assigning stuff to itself is pointless, so this is a code bug. The only valid exception I know is if you're writing back data to a command register in a peripheral device, which isn't the case here. Fix the bug, not the symptom! I agree, but I can think of another valid exception. System with Hamming correction on the memory, gets a single bit (correctable) error. Need to rewrite the memory contents to reset all the parity bits! (sorry for the drift...) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: reasons for rewriting regular memory (was: [ANNOUNCE]: clang compiling ports, take 2)
I agree, but I can think of another valid exception. System with Hamming correction on the memory, gets a single bit (correctable) error. Need to rewrite the memory contents to reset all the parity bits! That's a matter of the EDAC stuff, not the business of applications. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: reasons for rewriting regular memory (was: [ANNOUNCE]: clang compiling ports, take 2)
Matthias Andree matthias.and...@gmx.de wrote: I agree, but I can think of another valid exception. System with Hamming correction on the memory, gets a single bit (correctable) error. Need to rewrite the memory contents to reset all the parity bits! That's a matter of the EDAC stuff, not the business of applications. True, but it may explain why clang does not flag *x = *x; when it does flag x = x;. A compiler cannot know the context in which the compiled code will be used. BTW I agree that an understanding is needed of _why_ the code in question was included. I have seen x = x; -- x being a formal parameter -- used to prevent an unused argument warning in a function which did not in fact need the argument in question, but had to declare it for uniformity with other functions pointed to by the same function pointer type. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
On Mon, 25 Jul 2011, Matthias Andree wrote: Namely: if a port sets USE_GCC=4.2+ (for instance, sysutils/busybox does that), the Pointyhat build does not install GCC. I think the bug is in ports/Mk/bsd.gcc.mk which is unaware that there are newer clang-based 9-CURRENT systems without gcc. I hope we can have another -exp run soon that addresses this. Matthias, sorry for not getting to this earlier. If you look at Mk/bsd.port.mk, there is a line GCCVERSION_040200= 700042 99 4.2 which indicates that GCC 4.2 has been in the base system starting with FreeBSD 7.0 (and that magic 42 marker) until the rest of times. Can you advise which value of __FreeBSD_version to use? The official list at http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html does not have a reference from what I can see. Gerald ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
On Mon, Jul 25, 2011 at 8:06 PM, George Liaskos geo.lias...@gmail.com wrote: Hello! I added some jquery for sorting / searching at the latest clang exp run. http://cybertron.gr/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/index.html I hope you 'll find it useful. The table should be sortable already, just click on the column name. -- Florent Thoumie f...@freebsd.org FreeBSD Committer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
Am 25.07.2011 17:59, schrieb Roman Divacky: Hi! Flz@ just run another exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/ Since the last run we've managed to fix the biggest offenders but that uncovered others that need fixing. The Reason column was extended and now shows assumes_gcc which is the lowest hanging fruit :) A lot of these failures are trivial to fix (ie. assumes_gcc reason) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Greetings, there is one serious issue that spoilt (as discussed with kwm and rene on IRC) a major part of this -exp run. Namely: if a port sets USE_GCC=4.2+ (for instance, sysutils/busybox does that), the Pointyhat build does not install GCC. I think the bug is in ports/Mk/bsd.gcc.mk which is unaware that there are newer clang-based 9-CURRENT systems without gcc. I hope we can have another -exp run soon that addresses this. Thanks. Best regards, Matthias ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[ANNOUNCE]: clang compiling ports, take 2
Hi! Flz@ just run another exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/ Since the last run we've managed to fix the biggest offenders but that uncovered others that need fixing. The Reason column was extended and now shows assumes_gcc which is the lowest hanging fruit :) A lot of these failures are trivial to fix (ie. assumes_gcc reason) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us again! Roman Divacky pgp0lXrHcNdQ3.pgp Description: PGP signature
Re: [ANNOUNCE]: clang compiling ports, take 2
On Mon, Jul 25, 2011 at 05:59:20PM +0200, Roman Divacky wrote: Hi! Flz@ just run another exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/ It would be good to also do an exp run on i386. I ran into one port that compiled fine with clang on amd64, but failed under i386. (inline asm error) - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
On Mon, Jul 25, 2011 at 6:59 PM, Roman Divacky rdiva...@freebsd.org wrote: Hi! Flz@ just run another exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/ Since the last run we've managed to fix the biggest offenders but that uncovered others that need fixing. The Reason column was extended and now shows assumes_gcc which is the lowest hanging fruit :) A lot of these failures are trivial to fix (ie. assumes_gcc reason) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us again! Roman Divacky Hello! I added some jquery for sorting / searching at the latest clang exp run. http://cybertron.gr/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/index.html I hope you 'll find it useful. Regards, George ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
Roman Divacky rdiva...@freebsd.org writes: Hi! Flz@ just run another exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/ qt4-webkit seems to trigger a clang bug, but the description for clang bug only says See (TBA) for further information. Is there anything we (as in kde@) should do? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports, take 2
Hi--
On Jul 25, 2011, at 4:31 PM, Raphael Kubo da Costa wrote:
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/
qt4-webkit seems to trigger a clang bug, but the description for clang
bug only says See (TBA) for further information. Is there anything we
(as in kde@) should do?
From:
http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/qt4-webkit-4.7.3.log
Clang is failing with an internal assertion failure, seems like it's not
parsing something correctly in RenderSlider.cpp, and hitting EOF:
Assertion failed: (FieldNo FieldCount Invalid Field No), function
getFieldOffset, file
/a/portbuild/amd64/9-exp/builds/20110616185105/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include/clang/AST/RecordLayout.h,
line 121.
Stack dump:
0. Program arguments: /usr/bin/clang++ -cc1 -triple
x86_64-unknown-freebsd9.0 -emit-obj -disable-free -main-file-name
RenderSlider.cpp -pic-level 2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64
-momit-leaf-frame-pointer -coverage-file .obj/release-shared/RenderSlider.o
-resource-dir /usr/bin/../lib/clang/3.0 -D QT_SHARED -D BUILDING_QT__=1 -D
WTF_USE_ACCELERATED_COMPOSITING -D NDEBUG -D QT_NO_CAST_TO_ASCII -D
QT_ASCII_CAST_WARNINGS -D QT3_SUPPORT -D QT_MOC_COMPAT -D
QT_USE_FAST_OPERATOR_PLUS -D QT_USE_FAST_CONCATENATION -D HAVE_PTHREAD_NP_H -D
BUILD_WEBKIT -D BUILDING_QT__ -D BUILDING_JavaScriptCore -D BUILDING_WTF -D
ENABLE_VIDEO=1 -D ENABLE_JAVASCRIPT_DEBUGGER=1 -D ENABLE_DATABASE=1 -D
ENABLE_EVENTSOURCE=1 -D ENABLE_OFFLINE_WEB_APPLICATIONS=1 -D
ENABLE_DOM_STORAGE=1 -D ENABLE_ICONDATABASE=1 -D ENABLE_CHANNEL_MESSAGING=1 -D
ENABLE_ORIENTATION_EVENTS=0 -D ENABLE_SQLITE=1 -D ENABLE_DASHBOARD_SUPPORT=0 -D
ENABLE_FILTERS=1 -D ENABLE_XPATH=1 -D ENABLE_WCSS=0 -D ENABLE_WML=0 -D
ENABLE_SHARED_WORKERS=1 -D ENABLE_WORKERS=1 -D ENABLE_XHTMLMP=0 -D
ENABLE_DATAGRID=0 -D ENABLE_RUBY=1 -D ENABLE_SANDBOX=1 -D ENABLE_PROGRESS_TAG=1
-D ENABLE_BLOB_SLICE=0 -D ENABLE_3D_RENDERING=1 -D ENABLE_SVG=1 -D
ENABLE_SVG_FONTS=1 -D ENABLE_SVG_FOREIGN_OBJECT=1 -D ENABLE_SVG_ANIMATION=1 -D
ENABLE_SVG_AS_IMAGE=1 -D ENABLE_SVG_USE=1 -D ENABLE_DATALIST=1 -D
ENABLE_TILED_BACKING_STORE=1 -D ENABLE_NETSCAPE_PLUGIN_API=1 -D
ENABLE_WEB_SOCKETS=1 -D ENABLE_XSLT=0 -D ENABLE_QT_BEARER=1 -D
ENABLE_TOUCH_EVENTS=1 -D XP_UNIX -D SQLITE_CORE -D SQLITE_OMIT_LOAD_EXTENSION
-D SQLITE_OMIT_COMPLETE -D QT_NO_DEBUG -D QT_GUI_LIB -D QT_NETWORK_LIB -D
QT_CORE_LIB -D QT_HAVE_AVX -D _LARGEFILE64_SOURCE -D _LARGEFILE_SOURCE -I
../../../../include/Qt -I ../../../../include -I /usr/local/include/freetype2
-I /usr/local/share/qt4/mkspecs/freebsd-clang -I . -I
../../../../include/QtCore -I ../../../../include/QtNetwork -I
../../../../include/QtGui -I ../../../../include -I bridge/qt -I page/qt -I
platform/graphics/qt -I platform/network/qt -I platform/qt -I ../WebKit/qt/Api
-I ../WebKit/qt/WebCoreSupport -I . -I accessibility -I bindings/js -I bridge
-I bridge/c -I bridge/jsc -I css -I dom -I dom/default -I editing -I history -I
html -I html/canvas -I inspector -I loader -I loader/appcache -I loader/archive
-I loader/icon -I notifications -I page -I page/animation -I platform -I
platform/animation -I platform/graphics -I platform/graphics/filters -I
platform/graphics/transforms -I platform/image-decoders -I platform/mock -I
platform/network -I platform/sql -I platform/text -I plugins -I rendering -I
rendering/style -I storage -I svg -I svg/animation -I svg/graphics -I
svg/graphics/filters -I websockets -I wml -I workers -I xml -I generated -I
../JavaScriptCore -I ../../webkit -I ../JavaScriptCore/assembler -I
../JavaScriptCore/bytecode -I ../JavaScriptCore/bytecompiler -I
../JavaScriptCore/debugger -I ../JavaScriptCore/interpreter -I
../JavaScriptCore/jit -I ../JavaScriptCore/parser -I ../JavaScriptCore/pcre -I
../JavaScriptCore/profiler -I ../JavaScriptCore/runtime -I
../JavaScriptCore/wtf -I ../JavaScriptCore/wtf/symbian -I
../JavaScriptCore/wtf/unicode -I ../JavaScriptCore/yarr -I
../JavaScriptCore/API -I ../JavaScriptCore/ForwardingHeaders -I
../JavaScriptCore/generated -I ../include/QtWebKit -I
../../../../include/QtWebKit -I .rcc/release-shared -I ../../sqlite -I
../../../../include/phonon -I /usr/local/include -I .moc/release-shared -I
/usr/local/include -O2 -Wall -W -fdeprecated-macro -ferror-limit 19
-fmessage-length 0 -fvisibility hidden -fvisibility-inlines-hidden
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -o
.obj/release-shared/RenderSlider.o -x c++ rendering/RenderSlider.cpp
1. eof parser at end of file
2. rendering/RenderSlider.cpp:43:11: LLVM IR generation of declaration
'WebCore'
3. rendering/RenderSlider.cpp:81:26: Generating code for declaration
'WebCore::SliderThumbElement::defaultEventHandler'
4. rendering/RenderSlider.cpp:82:1: LLVM IR generation of compound
statement ('{}')
In file
Re: [ANNOUNCE]: clang compiling ports
Mark Linimon wrote: On Mon, Jun 20, 2011 at 06:21:26PM -0500, Mark Linimon wrote: A permanent URL to this run is: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/ That will stick around even if we use amd64-9-exp for something else. I have updated the errorlog-classifier script and re-run the analysis. Most of the false positives for process failed being actually inability to find C compiler are now flagged as assumes_gcc. The linker_error case has been expanded (again, while these can happen in regular runs, they are much more prevalent in the clang runs.) A few other cases have been tightened up as well. Is there a new link for the new results? Or did you use the link above? b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Thu, Jun 30, 2011 at 9:19 AM, b. f. bf1...@googlemail.com wrote: Mark Linimon wrote: On Mon, Jun 20, 2011 at 06:21:26PM -0500, Mark Linimon wrote: A permanent URL to this run is: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/ That will stick around even if we use amd64-9-exp for something else. I have updated the errorlog-classifier script and re-run the analysis. Most of the false positives for process failed being actually inability to find C compiler are now flagged as assumes_gcc. The linker_error case has been expanded (again, while these can happen in regular runs, they are much more prevalent in the clang runs.) A few other cases have been tightened up as well. Is there a new link for the new results? Or did you use the link above? I'll start a new run and will report the results in a day or two. -- Florent Thoumie f...@freebsd.org FreeBSD Committer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Thu, Jun 30, 2011 at 08:19:05AM +, b. f. wrote: Is there a new link for the new results? Or did you use the link above? same link. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Thu, Jun 30, 2011 at 3:18 PM, Koop Mast k...@rainbow-runner.nl wrote: I need to review the patches mentioned on the end of that wiki page. But I have currently a couple of deadlines I need to do work for, so that takes priority atm. If I find anything that is still needed, I will let the responsible people now. oh, found it. that patch is obsolete. qt4 is now able to build (theoretically) with any compiler from ports and base -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Mon, Jun 20, 2011 at 06:21:26PM -0500, Mark Linimon wrote: A permanent URL to this run is: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/ That will stick around even if we use amd64-9-exp for something else. I have updated the errorlog-classifier script and re-run the analysis. Most of the false positives for process failed being actually inability to find C compiler are now flagged as assumes_gcc. The linker_error case has been expanded (again, while these can happen in regular runs, they are much more prevalent in the clang runs.) A few other cases have been tightened up as well. Of course, a large number of ports have been fixed since this run, so check CVS first before you send-pr. Thanks. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
Quoting Mark Linimon lini...@lonesome.com (from Mon, 20 Jun 2011 18:21:26 -0500): On Mon, Jun 20, 2011 at 05:37:53PM +0200, Roman Divacky wrote: Flz@ just ran an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A permanent URL to this run is: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/ That will stick around even if we use amd64-9-exp for something else. It may be beneficial for such kind of exp runs to have a list which is sorted by number of affected ports. Bye, Alexander. -- So... did you ever wonder, do garbage men take showers before they go to work? http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Mon, 20 Jun 2011 17:37:53 +0200, Roman Divacky wrote: Hi! Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us! Roman Divacky I have tried to fix most of my ports, I now have a problem which seem to appear quite often : local symbol 5: discarded in section `.text._ZN6icu_4815MaybeStackArrayIcLi40EE13orphanOrCloneEiRi' from udata.o local symbol 6: discarded in section `.text._ZNK6icu_4813UnicodeStringeqERKS0_' from messagepattern.o local symbol 7: discarded in section `.text._ZN6icu_4815MaybeStackArrayIcLi40EED1Ev' from locutil.o [...] local symbol 96: discarded in section `.text._ZN6icu_4815MaybeStackArrayIcLi40EE12releaseArrayEv' from servrbf.o local symbol 97: discarded in section `.text._ZN6icu_4815MaybeStackArrayIcLi40EE12aliasInsteadEPci' from servrbf.o local symbol 98: discarded in section `.text._ZN6icu_4815MaybeStackArrayIcLi40EE6resizeEii' from servrbf.o local symbol 99: discarded in section `.text._ZN6icu_4815MaybeStackArrayIcLi40EE13orphanOrCloneEiRi' from servrbf.o clang++: error: linker command failed with exit code 1 (use -v to see invocation) To test I'm using CC=clang CXX=clang++ on a FreeBSD8-stable box (1 week old) using clang from ports: 2.9. does anyone have a clue for that? Am I doing something wrong? regards, Bapt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Tue, Jun 21, 2011 at 8:41 AM, Alexander Leidinger alexan...@leidinger.net wrote: Quoting Mark Linimon lini...@lonesome.com (from Mon, 20 Jun 2011 18:21:26 -0500): On Mon, Jun 20, 2011 at 05:37:53PM +0200, Roman Divacky wrote: Flz@ just ran an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A permanent URL to this run is: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/ That will stick around even if we use amd64-9-exp for something else. It may be beneficial for such kind of exp runs to have a list which is sorted by number of affected ports. Fixed now. Florent ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
Roman Divacky ha scritto: It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. I have patches for my ports, can I send them to anyone to test them? -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
Am 21.06.2011 12:15, schrieb Alex Dupre: Roman Divacky ha scritto: It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. I have patches for my ports, can I send them to anyone to test them? Do something similar to this: 1. install port-tools and portlint unless you already have them 2. move gcc out of the way: cd /usr/bin for i in cc c89 c99 gcc g++ ; do mv $i $i.off done 3. test your port(s): cd /usr/ports/some/port port test -- CC=clang CXX=clang++ 4. move gcc back into place: cd /usr/bin for i in cc c89 c99 gcc g++ ; do mv $i.off $i done It's not exactly what 9-exp has been trying (and will miss, for instance, header differences that trip up clang), but close enough for many ports. HTH ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
Matthias Andree ha scritto: I have patches for my ports, can I send them to anyone to test them? Do something similar to this: Thanks for the instructions, but currently I haven't a -current ready for testing, this is the reason of my question :-) -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
Am 21.06.2011 12:29, schrieb Alex Dupre: Matthias Andree ha scritto: I have patches for my ports, can I send them to anyone to test them? Do something similar to this: Thanks for the instructions, but currently I haven't a -current ready for testing, this is the reason of my question :-) Are the faults you're fixing specific to -CURRENT, like affecting features or changes specific to 9-CURRENT? If not, try -STABLE in the way I've proposed -- you need to do that twice: 1 - before your fixes and see if the problem reproduces; and 2 - if it does, try again after your fixes -- if your fixes solve the problem on -STABLE, that will likely work with -CURRENT too. HTH ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Tue, 21 Jun 2011 12:39:18 +0200, Matthias Andree wrote:
Am 21.06.2011 12:29, schrieb Alex Dupre:
Matthias Andree ha scritto:
I have patches for my ports, can I send them to anyone to test
them?
Do something similar to this:
Thanks for the instructions, but currently I haven't a -current
ready
for testing, this is the reason of my question :-)
Are the faults you're fixing specific to -CURRENT, like affecting
features or changes specific to 9-CURRENT?
If not, try -STABLE in the way I've proposed -- you need to do that
twice:
1 - before your fixes and see if the problem reproduces; and
2 - if it does, try again after your fixes -- if your fixes solve the
problem on -STABLE, that will likely work with -CURRENT too.
HTH
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
freebsd-ports-unsubscr...@freebsd.org
Just be aware that stable clang has some issue with the stable
binutils, to fix this make sure to use binutils from ports.
To be able to test on stable:
export CC=clang
export CXX=clang++
PATH=/usr/local/bin:${PATH} make -C myport
the ld from localbase is found first so clang uses it.
currently from my testing everything that succeed compiling with this
also succeed on current
and everything that fail on current also fails this way.
regards,
Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
Am 21.06.2011 12:43, schrieb Baptiste Daroussin:
Just be aware that stable clang has some issue with the stable binutils,
to fix this make sure to use binutils from ports.
To be able to test on stable:
export CC=clang
export CXX=clang++
PATH=/usr/local/bin:${PATH} make -C myport
the ld from localbase is found first so clang uses it.
currently from my testing everything that succeed compiling with this
also succeed on current
and everything that fail on current also fails this way.
Thanks, however, this misses one particular error case, namely,
hardwired compiler names such as cc, c89, c99, gcc -- because these
remain in PATH. Possibly we can just create a dummy directory and stuff
all gcc-related tool names as hard links to [/usr]/bin/false in there
and stuff that early in the path, too, so you see if a port uses gcc.
For instance, the security/openvpn plugins did that.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[ANNOUNCE]: clang compiling ports
Hi! Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us! Roman Divacky pgpFKX1RRwGhM.pgp Description: PGP signature
Re: [ANNOUNCE]: clang compiling ports
On 2011-06-20 17:37, Roman Divacky wrote: Hi! Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us! Roman Divacky Would it be helpful to add a wiki page where people can annotate failed ports etc.? Much like what was done for the update to gmake... Regards -- Niclas ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
Hi, Roman. Can you specify what environment and which make options
where used? I'm somewhat confused because of log [1]: the Makefile
basically does the compiling this way:
${MAKE} PROG=lemon NOMAN=1 NO_MAN=1 \
CFLAGS=-g ${CFLAGS} \
-f /usr/share/mk/bsd.prog.mk
Since bsd.prog.mk does respect CC, and the log says that cc was
invoked, it must follow that CC is cc (or empty). What am I missing?
[1]
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/lemon-1.69.log
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On 06/20/2011 11:22 AM, Niclas Zeising wrote: On 2011-06-20 17:37, Roman Divacky wrote: Hi! Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us! Roman Divacky Would it be helpful to add a wiki page where people can annotate failed ports etc.? Much like what was done for the update to gmake... Regards What I would like is a primer on how to suppress all the warnings and errors created by KR code. Also, why is this an error: error: non-void function 'top_button_cross' should return a value [-Wreturn-type] when most everything else is a warning. (See http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/xppaut-5.99.log.) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Jun 20, 2011, at 9:35 AM, Stephen Montgomery-Smith wrote: What I would like is a primer on how to suppress all the warnings and errors created by KR code. OK: http://clang.llvm.org/docs/UsersManual.html#cl_diagnostics Of course, you can only suppress warnings; you cannot suppress actual errors. clang doesn't currently support -traditional aka pure KR C. It's possible that compiling with -ansi aka -std=c89 might help-- at least you should get -Wno-implicit-function-declaration and maybe -Wno-implicit-int. Also, why is this an error: error: non-void function 'top_button_cross' should return a value [-Wreturn-type] when most everything else is a warning. (See http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/xppaut-5.99.log.) top_button_cross() probably should be declared as returning void. What's presumably happening is that it gets a default return type of int since it doesn't otherwise specify a return type, and then fails to have an explicit return, which is an error. Regards, -- -Chuck ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On 06/20/2011 12:59 PM, Chuck Swiger wrote: On Jun 20, 2011, at 9:35 AM, Stephen Montgomery-Smith wrote: What I would like is a primer on how to suppress all the warnings and errors created by KR code. OK: http://clang.llvm.org/docs/UsersManual.html#cl_diagnostics Yes, I did see that. Of course, you can only suppress warnings; you cannot suppress actual errors. clang doesn't currently support -traditional aka pure KR C. It's possible that compiling with -ansi aka -std=c89 might help-- at least you should get -Wno-implicit-function-declaration and maybe -Wno-implicit-int. Also, why is this an error: error: non-void function 'top_button_cross' should return a value [-Wreturn-type] when most everything else is a warning. (See http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/xppaut-5.99.log.) top_button_cross() probably should be declared as returning void. What's presumably happening is that it gets a default return type of int since it doesn't otherwise specify a return type, and then fails to have an explicit return, which is an error. Is a return with no value, from a function of type int, meant to be an error in KR code? If so, I will change the code so that return becomes return 0. Otherwise, I think the clang compiler should be changed so that this is a warning, not an error. Or at least an error that can be switched off with -Wno-return-type. I will say that I have no desire to put ansii patches into working KR code. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Jun 20, 2011, at 12:09 PM, Stephen Montgomery-Smith wrote: top_button_cross() probably should be declared as returning void. What's presumably happening is that it gets a default return type of int since it doesn't otherwise specify a return type, and then fails to have an explicit return, which is an error. Is a return with no value, from a function of type int, meant to be an error in KR code? I don't believe so, but pure KR didn't require compilers to perform any sanity checking of function return types. This led to all sorts of bugs, which is why lint was invented and why ANSI-C compilers do expect function prototypes and perform function return-type checking. If so, I will change the code so that return becomes return 0. Otherwise, I think the clang compiler should be changed so that this is a warning, not an error. Or at least an error that can be switched off with -Wno-return-type. I will say that I have no desire to put ansii patches into working KR code. It sounds like you want Clang to support -traditional. It explicitly does not do so, although there is a bug filed as: http://llvm.org/bugs/show_bug.cgi?id=4557 The best course is to convert KR C code to C89/ANSI; failing that, perhaps use gcc for things which require -traditional instead of Clang (although GCC seems to be depreciating -traditional also). Regards, -- -Chuck ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On 06/20/2011 02:28 PM, Chuck Swiger wrote: On Jun 20, 2011, at 12:09 PM, Stephen Montgomery-Smith wrote: top_button_cross() probably should be declared as returning void. What's presumably happening is that it gets a default return type of int since it doesn't otherwise specify a return type, and then fails to have an explicit return, which is an error. Is a return with no value, from a function of type int, meant to be an error in KR code? I don't believe so, but pure KR didn't require compilers to perform any sanity checking of function return types. This led to all sorts of bugs, which is why lint was invented and why ANSI-C compilers do expect function prototypes and perform function return-type checking. If so, I will change the code so that return becomes return 0. Otherwise, I think the clang compiler should be changed so that this is a warning, not an error. Or at least an error that can be switched off with -Wno-return-type. I will say that I have no desire to put ansii patches into working KR code. It sounds like you want Clang to support -traditional. It explicitly does not do so, although there is a bug filed as: http://llvm.org/bugs/show_bug.cgi?id=4557 The best course is to convert KR C code to C89/ANSI; failing that, perhaps use gcc for things which require -traditional instead of Clang (although GCC seems to be depreciating -traditional also). This is someone else's code in math/xppaut. I have no desire to write extensive patches to his code. It would be a nightmare to maintain. I'll go with return 0. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
Roman Divacky rdiva...@freebsd.org writes: Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. Any extra libtool patches? I'm curious how did you work around ports/155157 foo.o: relocation R_X86_64_PC32 against symbol `bar' can not be used when making a shared object; recompile with -fPIC due to failing lt_cv_prog_compiler_pic_works check on clang warnings. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On 06/20/2011 02:44 PM, Stephen Montgomery-Smith wrote: On 06/20/2011 02:28 PM, Chuck Swiger wrote: On Jun 20, 2011, at 12:09 PM, Stephen Montgomery-Smith wrote: top_button_cross() probably should be declared as returning void. What's presumably happening is that it gets a default return type of int since it doesn't otherwise specify a return type, and then fails to have an explicit return, which is an error. Is a return with no value, from a function of type int, meant to be an error in KR code? I don't believe so, but pure KR didn't require compilers to perform any sanity checking of function return types. This led to all sorts of bugs, which is why lint was invented and why ANSI-C compilers do expect function prototypes and perform function return-type checking. If so, I will change the code so that return becomes return 0. Otherwise, I think the clang compiler should be changed so that this is a warning, not an error. Or at least an error that can be switched off with -Wno-return-type. I will say that I have no desire to put ansii patches into working KR code. It sounds like you want Clang to support -traditional. It explicitly does not do so, although there is a bug filed as: http://llvm.org/bugs/show_bug.cgi?id=4557 The best course is to convert KR C code to C89/ANSI; failing that, perhaps use gcc for things which require -traditional instead of Clang (although GCC seems to be depreciating -traditional also). This is someone else's code in math/xppaut. I have no desire to write extensive patches to his code. It would be a nightmare to maintain. I'll go with return 0. After all my fussing, I tried clang out, and -Wno-return-type kills the error message. So I am OK. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
Pan Tsu iny...@gmail.com writes: Roman Divacky rdiva...@freebsd.org writes: Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. Any extra libtool patches? I'm curious how did you work around ports/155157 foo.o: relocation R_X86_64_PC32 against symbol `bar' can not be used when making a shared object; recompile with -fPIC due to failing lt_cv_prog_compiler_pic_works check on clang warnings. Looking closely at the logs it uses full path to the compiler. I tried same and the error is gone. Apparently, smth is broken on my box when clang is used together with ccache. $ /usr/bin/clang -c -fPIC -DPIC -DPIC foo.c $ CCACHE_RECACHE=1 ccache /usr/bin/clang -c -fPIC -DPIC -DPIC foo.c clang: warning: argument unused during compilation: '-D PIC' clang: warning: argument unused during compilation: '-D PIC' Sorry for the noise. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Mon, Jun 20, 2011 at 05:37:53PM +0200, Roman Divacky wrote: Flz@ just ran an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A permanent URL to this run is: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/ That will stick around even if we use amd64-9-exp for something else. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
